Share
Det har länge varit allmänt accepterat att en av de största fördelarna som WordPress har över sina konkurrenter är dess användargränssnitt. Det är överlag mycket lätt och intuitivt att använda. Dessutom blir det ständigt raffinerat och förbättrat, med media uppladdning skärmen nu en av de många saker som granskas. Tyvärr finns det något som WordPress-UI-teamet inte har kontroll över, vilket konsekvent försvinner allt sitt hårda arbete: plugins och teman.
Din plugin-användargränssnitt (jag ska använda termen plugin i den här artikeln, men detsamma gäller ditt temans gränssnitt) är en av de viktigaste aspekterna av ditt plugin. Det definierar hur människor interagerar med det, hur lätt det är att använda, och kanske till och med hur mycket de är njut av använder det. Det här är det ultimata målet för din plugin: Att göra en viss uppgift eller uppgifter lättare för din slutanvändare (i själva verket är detta det till synes glömda målet med datorer själva). Användargränssnittet ska vara attraktivt, men i slutändan bör det vara funktionellt. När du bestämmer dig för hur du ska layouta ditt plugin måste du bestämma hur du gör din plugin lätt att använda - ännu bättre, få feedback - det är i huvudsak vad WordPress gör.
Under de senaste veckorna och månaderna har det skett mycket diskussion om hur WordPress användbarhet kan förbättras - allt från allmänna användargränssnitt förbättringar till tillgänglighet (om du inte tror att tillgänglighet är ett problem för antingen WordPress eller din plugin, rekommenderar jag att du kontrollerar ut Graham Armfields utmärkta samtal från WordCamp Edinburgh). Mer nyligen frågade Tom McFarlin en hel del diskussion om att integrera med WordPress 'användargränssnitt. Diskussionen rörde sig för behovet av en gränssnitt för plugin-författare för att hjälpa dem att se till att deras plugin integreras sömlöst i WordPress. Denna riktlinje börjar ta form i form av riktlinjerna för WordPress User Interface.
I denna serie tittar vi på steg som du kan ta för att hjälpa dig att integrera din plugin i WordPress-användargränssnittet. I den här artikeln kommer vi att fokusera på några grundläggande riktlinjer, liksom några av de användargränssnitt API som är tillgängliga för dig. Observera att dessa riktlinjer inte på något sätt är "officiella". I de efterföljande artiklarna ser vi på fler "praktiska" exempel, bland annat genom att använda metaboxer på anpassade adminsidor och användningen av WordPress 'adminpekare.
Detta är den viktigaste anledningen. Kärnan med både WordPress-gränssnittet och ditt plugin eller tema är att underlätta innehållshantering och produktion för slutanvändaren. Det är att göra det möjligt för användaren att uppnå ett specifikt syfte. Om ditt plugin eller tema introducerar ett användargränssnitt som är väsentligt annorlunda än WordPress ', tvingar du användaren att lära sig ett helt nytt gränssnitt. Då gör du det svårare för dem och de kommer förmodligen att avinstallera ditt plugin och hitta en annan. Konsistens är nyckel här.
För det andra är det bara ful när ett plugin eller tema sticker ut som en öm tumme. WordPress-administratören är (mestadels) vackert konsekvent - och plugins som inte passar in är bara ett ögon öm. Detta säger inte ens att pluginens egna användargränssnitt är särskilt fult. Det kan väl vara så att pluginens gränssnitt är slickt - men det kommer fortfarande att se ut ur sammanhanget.
De bäst plugins passar sömlöst i WordPress i den utsträckning där det är nästan omöjligt att berätta var WordPress stannar och plugin startar. Det är dessa plugins som användarna tycker om att använda, till stor del för att de ser ut som de är avsedda att vara där. Plugins bör förlänga WordPress - gör det inte till ett CMS som Frankenstein skulle producera.
WordPress erbjuder många sätt att hjälpa dig att passa in med WordPress. Det ger också mycket CSS på admin sidor som du kan dra nytta av. Att göra båda dessa är ett effektivt sätt att "framtida proofing" ditt plugin-användargränssnitt. Eventuella ändringar som görs till WordPress kommer att återspeglas i ditt plugin också. Å andra sidan om du "går ensam" med din administratörsgränssnitt - varje WordPress-uppdatering medför en ökad chans att din plugin-gränssnitt kommer att störa konflikten med WordPress. Genom att använda WordPress 'stilar och layouter, gör du livet enklare för dig själv, såväl som dina användare.
Du kanske tror att din plugin är den viktigaste i förvaret, och det kan vara det bästa av sitt slag där ute. Men gör det verkligen Behöver du bra plats på adminmenyn? En viktig aspekt av alla användargränssnitt är en enkelhet som gör att användarna kan hitta vad de vill ha snabbt. Cluttering upp menyn är motsatsen till detta.
Din plugin kanske inte ens behöver en egen undersida. Alla standardinställningar sidor kan ha avsnitt tillagda till dem. Om din plugin bara har några inställningar, och de skulle inte vara borta på en befintlig inställningssida, bör du överväga detta.
Om din plugin kräver en plats på översta menyn, tänk noggrant på var den ska gå. Admin-menyn är uppdelad i tre sektioner: instrumentbrädan, innehållshantering och inställningar. Var din menyalternativ på toppnivå ska gå beror på vad det primära syftet med din plugin är. Om det producerar, redigerar och hanterar innehåll - det ska gå i mitten. Om dess syfte är underhåll, prestanda eller konfiguration (till exempel integration med programvara för tredje parts programvara, cachning eller backup) ska dessa antagligen gå längst ner.
Slutligen bör din plugin inte överföra sig. Att kasta ditt plugin med "donera" -länkar, annonser eller flöden från din blogg kommer inte att göra ditt plugin till dina användare. Plugin "branding" borde undvikas, eller åtminstone subtil nog att inte störa konflikten med WordPress 'gränssnitt.
Även om det här inte kan påverka pluginets användbarhet, kan integrering i utseendet på WordPress göra en sömlös och bättre användarupplevelse. Det är inte så att plugins varumärke kan vara hemskt (vissa ser fantastiska ut) - men mer att de ser ut ur sin plats.
De flesta pluginförfattare vill förstå att deras plugin ska vädja till så många användargränssnitt som möjligt. En olycklig bieffekt är att användaren presenteras med en kukpit av alternativ. En del av WordPress-filosofin är beslut inte alternativ:
Som utvecklare känner vi oss ibland att det är bra att erbjuda alternativ till allt, du kan aldrig ha för många val, eller hur? I slutändan hamnar dessa val på att vara tekniska, val som den genomsnittliga slutanvändaren inte har intresse av. Det är vår plikt som utvecklare att fatta smarta designbeslut och undvika att lägga vikten av tekniska val på våra slutanvändare.
Det finns två saker som måste balanseras: Å ena sidan vill du att användarna ska kunna tweak hur ditt plugin beter sig. Å andra sidan kan för många alternativ göra det svårt för någon, och kan lämna användaren förvirrad och frustrerad. Det finns ingen storlek i alla storlekar, och det är en dom som bör göras på dina erfarenheter av vad dina användare ber om.
Alternativen är dock inte det enda sättet att låta din plugin vara tweaked:
Menyalternativet Inställningar? Eller din egen högsta menyn? Jag har även hittat några i menyposten "Plugins" innan nu. Det är mycket debatt om detta. För de flesta plugins, som inte behöver sin egen toppnivå meny, fattas beslutet för dem. Men hur är det med plugins som gör? Jag kan bara ge min åsikt här. En övertygande punkt är att vissa användare förvänta för att hitta plugin-inställningarna under plugin-menyn. I vissa fall men jag anser att det är ett missbruk av adminmenyn - menyn ska inte vara "plugin menyn", men en meny som är kopplad till någon typ av uppgift (som att skapa och redigera inlägg, visa kommentarer etc.). Precis som WordPress separerar uppgifter från inställningar, så borde plugins.
För det andra är ändrade inställningar en uppgift i sig - en som görs sällan, ofta bara efter installationen av WordPress eller ett plugin. Eftersom det inte besöks regelbundet, placeras det under menyalternativet Inställningar, städar undermenyns undermeny för daglig användning.
Om du vill se till att din inställningssida inte saknas, uppmanar jag dig att lägga till en länk till den under ditt plugin namn på sidan Plugins. Det här är den sida som användaren kommer att landa på när de aktiverar pluginet, och det gör det lättare att hitta dina inställningar.
Här är ett exempel på hur man åstadkommer detta:
Accentsconagua
add_filter ('plugin_action_links', 'wptuts_plugin_settings_link', 10, 2); funktionen wptuts_plugin_settings_link ($ links, $ file) if ($ file == 'myplugin / myplugin.php') / * Sätt in länken i slutet * / $ links ['settings'] = sprintf ('% s' admin_url ('options-general.php? page = my_plugin_settings'), __ ('Inställningar', 'plugin_domain')); returnera $ länkar; Om dina plugininställningar inte passar bekvämt på en sida, bör du överväga att använda flikar för att dela upp dem. WordPress använder flikar på sidan Utseende -> Teman, och dessa kan läggas till i dina inställningar (eller anpassade administratorsidor, om det behövs). När du använder sidflikar finns det mycket lite anledning att inte använda WordPress-flikar. Hur man gör detta var täckt i Tom McFarlin Inställningar API-serien här på Wptuts+.
Men vad händer om du behöver för många flikar? Horisontella flikar skala inte särskilt bra - och överflödiga flikar kan se förvirrande och fula ut. Denna plugin gör ett bra försök att hantera många inställningssidor - men inställningslinjerna gör det fortfarande överväldigande:
Låt oss anta att alla dessa flikar är nödvändiga (vilket de förmodligen inte är), så kan du bestämma att vertikala flikar är en lämpligare lösning. Jag har sett några teman implementera vertikala flikar (ofta dåligt), vanligtvis med egen styling. Medan WordPress inte använder vertikala flikar (med undantag för hjälpflikarna) - du borde basera dina mönster på vad som är tillgängligt för dig. Känn dig fri att experimentera, men försök att hålla den ser naturlig ut i WordPress - det blir intressant att se vilka människor som kommer med.
WordPress har två typer av administrativa meddelanden: allmänna meddelanden och felmeddelanden - styling dem gult respektive rött respektive. Om ditt plugin måste visa ett meddelande till användaren bör du använda den ena eller den andra, beroende på meddelandets sammanhang.
Använda WordPress 'meddelande API är ett mycket enkelt sätt att ge användaren en konsekvent upplevelse. Ett exempel på hur man gör det här är:
/ * * Admin meddelande natt - visar ett meddelande * / / * Visa ett meddelande som kan avfärdas * / add_action ('admin_notices', 'wptuts_admin_notices'); funktion wptuts_admin_notices () printf (' % s
', esc_html __ (' Detta är ett gult meddelande ',' plugin_domain ')); printf (' % s
', esc_html __ (' Detta är en röd felvarning ',' plugin_domain ')); Du ska självklart bara visa meddelanden som är relevanta - vilket innebär att dina meddelanden skickas på endast vissa skärmar och för vissa användare villkorligt. För att göra detta kan du använda get_current_user_id () och get_current_screen ():
funktion wptuts_admin_notices () // Visa meddelande om användaren har _wptuts_display_notice lagrad och på skärmen med id 'portfölj' $ screen_id = get_current_screen () -> id; $ display_notice = get_user_meta (get_current_user_id (), '_wptuts_display_notice', true); om ($ display_notice && 'portfölj' == $ screen_id) // Visningsanvisningar
För uthålliga meddelanden bör du inkludera en avvisningslänk för att tillåta användaren att dölja meddelandet. Gilla följande exempel:
/ * Villkorligt visa meddelande * / add_action ('admin_notices', 'wptuts_persistant_notice'); funktionen wptuts_persistant_notice () / * Kontrollera att användaren inte redan har klickat för att ignorera meddelandet * / if (! get_user_meta (get_current_user_id (), '_wptuts_hide_notice', true)) printf (' % 1 $ s | % 3 $ s
', __ ("Detta är ett bestående meddelande. För att gömma det klickar du på" avvisa "," plugin_domain "), esc_url (add_query_arg (' wptus_nag ', wp_create_nonce (' wptus_nag '))), __ (' Dismiss ',' plugin_domain ')); / * Dölj meddelande * / add_action ('admin_init', 'wptuts_hide_notice'); funktion wptuts_hide_notice () if (! isset ($ _GET ['wptus_nag'])) return; // Kontrollera nonce check_admin_referer ('wptus_nag', 'wptus_nag'); // uppdaterad användarmetod för att ange avvisad meddelande update_user_meta (get_current_user_id (), '_wptuts_hide_notice', 1); Du kan också använda ajax för att avvisa administrativa meddelanden, men du bör också tillhandahålla en icke-JavaScript-återgång.
WordPress ger styling för två "typer" av knappar: "primär" och "sekundär". Den förra visas som en blå knapp och det ska bara vara en av dessa knappar på en viss sida. Sekundärknappen är en vit knapp. WordPress ger ett par hjälparfunktioner för att skapa knappar: get_submit_button () / skickaknapp() funktioner.
submit_button (__ ('Skicka text', 'plugin_domain'), 'primary', 'submit'); Åtgärder som är "destruktiva", till exempel en länk som raderar något, ska vara röda. Det finns ofta klasser du kan använda (som skräp) som kommer att göra det här för dig. För andra länkar ställer WordPress automatiskt in färgerna och detta bör inte överskridas.
Länkar på tabeller (t.ex. inläggstabellen) ska filtrera bordet och inte omdirigera användaren. Undantaget är "åtgärdslänkar" som visas när du svävar över en rad (till exempel länkarna "redigera" och "skräp").
Du kan (och borde) använda sidikonikoner på dina administratorsidor. Idealiskt bör dessa vara anpassade (undvik att återanvända samma ikoner för olika ändamål). Om du vill ändra ikonen för en anpassad posttyp kan du (skickligt) skriva ut CSS i adminhuvudet för att åsidosätta standardikonbilden.
Du måste se till att du bara gör det för dina eftertyps sidor, för att inte åsidosätta ikoner på andra sidor. Här är ett exempel på hur:
post_type; om ('händelse' == $ post_type) ?> För anpassade admin sidor kan du också använda screen_icon (). Detta skriver ut HTML för skärmikonen. Det tar ett (valfritt) argument: antingen en sträng (används i ID-attributet för ikonbehållaren) eller ett skärmobjekt som används för att skapa ett lämpligt ID-attribut. Till exempel: screen_icon ( 'myplugin'); kommer att skriva ut något som:
Använda admin_head krok som ovan kan du rikta in dig # Ikon myplugin och ge en bakgrundsbild.
För anpassade posttyper kan menyn anges när du registrerar posttypen:
register_post_type ('event', array (... 'menu_icon' => plugin_dir_url (__FILE__). 'css / images / icon-32.png'; ...)); För flikar som läggs till i menyn med add_menu_page du kan ange ikonen som en av argumenten:
add_menu_page (__ ('Sida titel', 'plugin_domain'), // Används för titelens taggar på sidan __ ('Sida titel', 'plugin_domain'), // Sida som det visas på menyn 'manage_options', / / Möjligheter att komma åt denna sida 'wptuts_custom_page_callback', // Återuppringning som skriver ut innehållet på sidan plugin_dir_url (__FILE__). 'Css / images / icon-32.png'); Skärmen och menyikonen ska vara gråskala. En färgstark menyikon stannar uppenbarligen och ser sämre ut. Oavsett hur bra ikonen är, ruinerar den estetiken i admin sidobaran. Ännu värre säger en färgstark menyikon att du inte har störd om att spela bra med WordPress-gränssnittet, så jag kommer att misstänka att plugins kod inte spelar bra med WordPress antingen.
Kom ihåg att skärmikonen behöver fungera bra på tre olika bakgrunder:
Det är alltid en bra idé att ge dina användare lite extra vägledning om de behöver det. Men inklusive det på sidan kan införa röran, (och hjälptext är aldrig ett alternativ till intuitiv användargränssnitt). WordPress kan du lägga till innehåll på fliken "Hjälp" som visas längst upp till höger på skärmen. (Skärmalternativ och hjälpflikar kan ofta förbises av användarna, men det finns tidiga diskussioner om hur man förbättrar dem. Observera att det bara är diskussioner och ingenting har bestämts).
Möjligheten att lägga till "kontextuell hjälp" har funnits sedan 2,7, men sedan 3.3 fick hjälpfliken lite av en nyhet, introducerande en flikad hjälpbar.
Du kan lägga till din egen flik med följande kod. Det är viktigt att du bara lägger till den kontextuella hjälpen på lämpliga skärmar. Du bör också kontrollera att metoden WP_Screen :: add_help_tab existerar, annars kommer före 3.3 versioner av WordPress att kasta ett dödligt fel.
add_filter ('contextual_help', 'wptuts_contextual_help', 10, 3); funktion wptuts_contextual_help ($ contextual_help, $ screen_id, $ skärm) // Lägg bara till vissa skärm (er). Add_help_tab-funktionen för skärmen introducerades i WordPress 3.3. om ($ screen_id! = 'screen_id' ||! method_exists ($ screen, 'add_help_tab')) returnera $ contextual_help; $ screen-> add_help_tab (array ('id' => 'wptuts-överblick-flik', 'title' => __ ('Översikt', 'plugin_domain'), 'content' => ''. __ ("En del hjälptext här", "plugin_domain"). '
',)); returnera $ contextual_help; När du använder tabeller på administratörssidan av ditt plugin är det nästan alltid bättre att använda samma stil som WordPress använder för sina tabeller. Layouten och utseendet är idealiskt för att presentera data som produktförsäljning, aktivitetsloggar mm, vilket ger användarna ett konsekvent gränssnitt. Det är viktigt att användarna instinktivt förväntar sig att svängning över en rad kommer att avslöja "åtgärdslänkar", och att länkar i kolumnerna kommer att filtrera bordet. Var inte rädd för att anpassa ditt bord till dina specifika behov (ändra bredden på kolumnerna, anpassad stilering för bilder i kolumnen osv.) - men det är viktigt att presentera dina data på ett sätt som är allmänt känt och intuitivt för dina användare.
Det enklaste sättet att kopiera WordPress 'adminstabell är överlägset WP_List_Table klass. Det finns många artiklar som förklarar hur man gör det här - men den bästa "handledningen" är plugin för anpassad lista tabell, som ger dig ett fungerat exempel och är otroligt bra kommenterat. Men varnas, att även om Codex säger WP_List_Table klassen är lämplig att utökas av utvecklare, den verkliga källkoden markerar den här klassen som "Privat". Potentiellt kan WordPress ändra klassen - och om sådana förändringar händer måste du kontrollera att de inte brister ditt bord.
Alla jQuery-användargränssnitt tillhandahålls i WordPress (och om ditt plugin använder något, ska det använda WordPress-skript). Tyvärr finns det inte nödvändigtvis motsvarande CSS-format. Det här är för närvarande kvar för plugins att tillhandahålla. Det finns dock möjlighet att ändra med denna Trac-biljett. Helen Hou Sandi, kärnan WordPress-utvecklare, har arbetat med två jQuery-användargränssnitt som kompletterar WordPress (ett för varje administratörsfärgschema). Det finns ingen garanti för att detta kommer att göra det till WordPress * - men i alla fall borde du ladda ner båda teman och använda dem med dina plugins.
En demo-plugin kan laddas ner här. Därifrån kan du också extrahera de två teman:
Placera dessa i din plugin-mapp. När du registrerar skript använder du det tema som användaren valt:
add_action ('wp_enqueue_scripts', 'wptuts_register_scripts'); funktion wptuts_register_scripts () if ('classic' == get_user_option ('admin_color')) wp_register_style ('wptuts-plugin-jquery-ui-css', plugin_dir_url (__FILE__). 'jquery-ui-classic.css'); else wp_register_style ('wptuts-plugin-jquery-ui-css', plugin_dir_url (__FILE__). 'jquery-ui-fresh.css'); Då kan du ringa wp_enqueue_style ('wptuts-plugin-jquery-ui-css') var du behöver (självklart bör du ge stilar ett annat handtag, unikt för ditt plugin). Detta ensam kan gå långt för att hjälpa till att ge din plugin en titt i överensstämmelse med WordPress.
* Om det gör det till WordPress, kan du ta bort ovanstående från ditt plugin och använda WordPress-stilen istället.
Inte allt innehåll i WordPress är en post, kommentar eller bilaga och ibland ger inte det befintliga användargränssnittet det du behöver. I dessa fall är det bara inte lämpligt att pålägga den "posten" strukturer som existerar nationellt. Gravity Forms är till exempel ett plugin som låter dig lägga till och hantera formulär på din webbplats. Om de begränsade sig till det inbyggda WordPress-gränssnittet, presenterade formulär som nästan som inlägg, skulle resultatet till exempel vara en sämre användarupplevelse och färre försäljningar för Gravity Forms.
Att ge dina användare det bästa UX sätter inte helt enkelt allt inuti listor och metaboxer. Om ditt plugin måste presentera information på ett sätt som är främmande för det inbyggda WordPress-gränssnittet - kan du bli kreativ och experimentera. Men hur ritar du linjen mellan att vara kreativ och integrera med WordPress-gränssnittet? Detta var något som togs upp i kommentarerna från Toms post som nämnts tidigare. Sanningen är att det kommer ner till personlig bedömning och experimenterar för att se vad som fungerar. Gravity former, i det stora hela, gör det bra:
Viktigt, även om WordPress-gränssnittet inte kan ge exakt vad du behöver - det finns mycket att dra inspiration från. Om du till exempel vill att dina användare ska kunna dra och släppa objekt - kan du titta på menysidan för vägledning. Du bör inte kassera admin-användargränssnittet helt. Vissa "principer" för admin-användargränssnittet (vissa listade ovan) kan översättas oberoende av vad du försöker uppnå, till exempel: användning av färg, länkar, knappar och ikoner. Och detaljerna sakar - att få gradienter, radie och typsnitt rätt är viktiga för att upprätthålla konsistens, särskilt när du gör något "annorlunda". För drag-och-släpp-exemplet kanske du vill återanvända den grå platshållaren med en streckad kant.
Denna uppmärksamhet på detaljer kan tyckas svårt - men att få det rätt är faktiskt det lata (och i det här fallet lämpligt så) sak att göra. WordPress lägger till mycket stilering på administratörssidan - och för det mesta kommer detta att ärftas automatiskt av ditt plugin. I andra fall handlar det bara om att lägga till de rätta klasserna i dina delar.
Följande artiklar i den här serien kommer att vara mycket mer praktiska, men förhoppningsvis har den här artikeln visat några omedelbara och enkla steg för att ge dina användare en mer konsekvent admin. Riktlinjerna som anges här är inte på något sätt officiella, och de är inte heller uttömmande - och jag skulle välkomna diskussioner och förslag!
