Share
Det er lenge blitt allment akseptert at en av de største fordelene som WordPress har over sine konkurrenter, er dets admin brukergrensesnitt. Det er i det hele tatt veldig enkelt og intuitivt å bruke. Videre blir det hele tiden raffinert og forbedret, med medieopplastingsskjermbildet nå en av de mange tingene som er under kontroll. Dessverre er det noe som WordPress-UI-teamet ikke har kontroll over, som konsekvent forstyrrer alt hardt arbeid: plugins og temaer.
Pluginets brukergrensesnitt (jeg skal bruke termen plugin i denne artikkelen, men det samme gjelder temaet ditt) er et av de viktigste aspektene av plugin-modulen din. Det definerer hvordan folk interagerer med det, hvor lett det er å bruke, og kanskje selv hvor mye de Nyt bruker det. Dette er det endelige målet med pluginet ditt: Å gjøre en bestemt oppgave eller oppgaver enklere for sluttbrukeren din (faktisk er dette tilsynelatende glemt målet med datamaskiner selv). Brukergrensesnittet bør være attraktivt, men til slutt bør det være funksjonelt. Når du bestemmer deg for hvordan du skal legge ut pluginet ditt, må du bestemme hvordan du gjør pluginet enkelt å bruke - bedre ennå, få tilbakemelding - dette er egentlig hva WordPress gjør.
I de siste ukene og månedene har det vært mye diskusjon om hvordan WordPress 'brukervennlighet kunne forbedres - alt fra generelle brukergrensesnittforbedringer til tilgjengelighet (hvis du ikke tror tilgjengeligheten er et problem for enten WordPress eller pluginet ditt, vil jeg anbefale å sjekke ut Graham Armfields utmerkede snakk fra WordCamp Edinburgh). Mer nylig spurte Tom McFarlin mye diskusjon om integrering med WordPress 'brukergrensesnitt. Diskusjonen flyttet på behovet for en brukergrensesnitt for pluginforfattere for å hjelpe dem å sikre at pluginene integreres sømløst i WordPress. Denne retningslinjen begynner å ta form i form av WordPress brukergrensesnittretningslinjer.
I denne serien ser vi på trinn som du kan ta for å bidra til å integrere pluginet i WordPress 'brukergrensesnitt. I denne artikkelen vil vi fokusere på noen grunnleggende retningslinjer, så vel som noen av brukergrensesnitt-API'en tilgjengelig for deg. Vær oppmerksom på at disse retningslinjene på ingen måte er "offisielle". I de etterfølgende artiklene ser vi på flere "praktiske" eksempler, inkludert bruk av metaboxer på egendefinerte admin sider, og bruken av WordPress 'admin pointers.
Dette er den viktigste grunnen. Kjerneformålet med både WordPress brukergrensesnittet og plugin eller tema er å legge til rette for innholdsstyring og produksjon for sluttbrukeren. Det er å gjøre det mulig for brukeren å oppnå et bestemt formål. Hvis plugin eller tema introduserer et brukergrensesnitt som er svært forskjellig fra WordPress ', tvinger du brukeren til å lære et helt nytt grensesnitt. Da gjør du det vanskeligere for dem, og de vil sannsynligvis avinstallere pluginet ditt og finne en annen. Konsistens er nøkkelen her.
For det andre er det bare stygg når et plugin eller tema stikker ut som en sår tommel. WordPress-administrasjonen er (for det meste) vakkert konsistent - og plugins som ikke passer inn er bare øye sår. Dette er ikke engang å si at pluginets eget brukergrensesnitt er spesielt styggt. Det kan vel være at pluginets grensesnitt er slank - men det vil fortsatt se ut av konteksten.
De beste plugins passer sømløst inn i WordPress i den grad det er nesten umulig å fortelle hvor WordPress selv stopper og plugin starter. Det er disse pluginene som brukerne liker å bruke, hovedsakelig fordi de ser ut som de er ment å være der. Plugins bør utvide WordPress - ikke gjøre det til et CMS Dr. Frankenstein ville produsere.
WordPress gir mange måter å hjelpe deg med å "passe inn" med WordPress. Det gir også mye CSS på admin sidene som du kan dra nytte av. Å gjøre begge disse er en effektiv måte å "fremtidig proofing" på pluginens brukergrensesnitt. Eventuelle endringer som gjøres til WordPress, blir reflektert på pluginet ditt også. På den annen side, hvis du går alene med admin-brukergrensesnittet ditt, gir hver WordPress-oppdatering en økt sjanse for at plugin-grensesnittet ditt kommer i konflikt med WordPress. Ved å bruke WordPress 'stiler og layouter, gjør du livet enklere for deg selv, så vel som brukerne.
Du kan tenke at pluginet ditt er det viktigste i lagringsplassen, og det kan være det beste i sitt slag der ute. Men gjør det egentlig trenger du prime spot på admin-menyen? Et viktig aspekt av ethvert brukergrensesnitt er en enkelhet som lar brukerne finne det de vil ha raskt. Cluttering opp menyen er motsatt av dette.
Pluggen din trenger ikke engang en egen underside. Alle standardinnstillingssider kan ha seksjoner lagt til dem. Hvis din plugin har bare noen få innstillinger, og de ikke ville være ute av plass på en eksisterende innstillingsside, bør du vurdere dette.
Hvis pluginet ditt krever et sted på toppmenyen, tenk nøye på hvor det skal gå. Admin-menyen er delt opp i tre seksjoner: dashbordet, innholdshåndtering og innstillinger. Hvor menyelementet på toppnivå skal gå, avhenger av hva hovedformålet med plugin er. Hvis den produserer, redigerer og administrerer innhold - det skal gå i midten. Hvis dens formål er vedlikehold, ytelse eller konfigurasjon (for eksempel integrering med tredjeparts programvare, caching eller backup plugins), bør disse trolig gå på bunnen.
Til slutt bør pluginet ditt ikke overføre seg selv. Littering pluginet ditt med "donate" -koblinger, annonser eller feeds fra bloggen din, vil ikke ende opp med pluginet ditt til brukerne. Plugin 'branding' bør unngås, eller i det minste subtil nok til ikke å være i konflikt med WordPress 'brukergrensesnitt.
Selv om dette ikke kan påvirke brukervennligheten av plugin-modulen, integreres i utseendet på WordPress for en sømløs og bedre brukeropplevelse. Det er ikke at pluggens merke kan være forferdelig (noen ser fantastisk ut) - men mer at de ser ut av sted.
De fleste pluginforfattere har forståelig nok at deres plugin skal appellere til så mange brukergrupper som mulig. En uheldig bivirkning er at brukeren presenteres med en kukpit av alternativer. En del av WordPress-filosofien er avgjørelser ikke alternativer:
Som utviklere føler vi noen ganger at det er bra å gi alternativer til alt, du kan aldri ha for mange valg, ikke sant? Til slutt blir disse valgene tekniske, valg som den endelige sluttbrukeren ikke har interesse for. Det er vår plikt som utviklere å ta smarte designbeslutninger og unngå å legge vekten på tekniske valg på våre sluttbrukere.
Det er to ting som må balanseres: På den ene siden vil du at brukerne skal kunne justere måten din plugin oppfører seg på. På den annen side kan for mange alternativer gjøre det vanskelig å finne noen av dem, og lar brukeren bli forvirret og frustrert. Det finnes ingen størrelse i alle størrelser, og det er en vurdering som bør gjøres på dine erfaringer med hva brukerne ber om.
Alternativer er imidlertid ikke den eneste måten å tillate at pluginet ditt skal tweaked:
Innstillingsmenyelementet? Eller din egen toppmeny? Jeg har til og med funnet noen i menypunktet "Plugins" før nå. Det er mye diskusjon om dette. For de fleste plugins, som ikke trenger sin egen toppnivå meny, er det besluttet for dem. Men hva med plugins som gjør? Jeg kan bare gi min mening her. Et overbevisende punkt er at noen brukere forvente for å finne plugininnstillingene under plugin-menyen. I noen tilfeller, selv om jeg synes dette viser en misbruk av administrasjonsmenyen, må menyen ikke være "plugin-menyen", men en meny knyttet til en slags oppgave (som å lage og redigere innlegg, vise kommentarer etc). Akkurat som WordPress skiller oppgaver fra innstillinger, så bør plugins.
For det andre er endring av innstillinger en oppgave i seg selv - en som gjøres sjelden, ofte bare etter at du har installert WordPress eller et plugin. Fordi det ikke blir besøkt regelmessig, plasserer du det under Innstillinger-menyelementet og rydder på undermenyen for plugin for daglig bruk.
Hvis du vil forsikre deg om at innstillingssiden ikke blir savnet, oppfordrer jeg deg til å legge til en lenke til den under navnet på plugin-modulen på siden Plugins. Dette er siden brukeren vil lande på når de aktiverer pluginet, og det vil gjøre det enklere å finne innstillingene dine.
Her er et eksempel på hvordan du skal oppnå dette:
Accentsconagua
add_filter ('plugin_action_links', 'wptuts_plugin_settings_link', 10, 2); funksjon wptuts_plugin_settings_link ($ links, $ file) if ($ file == 'myplugin / myplugin.php') / * Sett inn linken på slutten * / $ links ['settings'] = sprintf ('% s' admin_url ('options-general.php? page = my_plugin_settings'), __ ('Innstillinger', 'plugin_domain')); returner $ linker; Hvis plugininnstillingene dine ikke passer godt til en side, bør du vurdere å bruke faner for å dele dem opp. WordPress bruker faner på siden Utseende -> Temaer, og disse kan legges til dine innstillinger (eller tilpassede administrasjons sider, hvis det er nødvendig). Når du bruker sidefaner, er det svært liten grunn til ikke å bruke WordPress-faner. Slik gjøres dette dekket i Tom McFarlin's Settings API-serien her på Wptuts+.
Men hva om du trenger for mange faner? Horisontale faner skala ikke spesielt godt - og overfylte faner kan se forvirrende og stygg. Dette pluginet gjør et godt forsøk på å håndtere mange innstillingssider - men innstillingslinjene gjør det fortsatt overveldende:
La oss anta at alle disse kategoriene er nødvendige (som de sannsynligvis ikke er), da kan du bestemme at vertikale faner er en mer egnet løsning. Jeg har sett noen temaer implementere vertikale faner (ofte dårlig), vanligvis ved hjelp av egen styling. Mens WordPress ikke bruker vertikale faner (med unntak av hjelpeflikene) - du bør basere designene dine på hva som er tilgjengelig for deg. Du er velkommen til å eksperimentere, men prøv å holde den ser innfødt til WordPress - det vil være interessant å se hva folk kommer opp med.
WordPress har to typer admin merknader: generelle meldinger og feilmeldinger - styling dem henholdsvis gul og rød. Hvis pluginet ditt skal vise varsel til brukeren, bør du bruke den ene eller den andre, avhengig av meldingenes sammenheng.
Bruke WordPress 'varsel API er en veldig enkel måte å gi brukeren en konsekvent opplevelse. Et eksempel på hvordan du gjør dette er:
/ * * Administrasjonsvarsel nag - viser en melding * / / * Vis et varsel som kan avvises * / add_action ('admin_notices', 'wptuts_admin_notices'); funksjon wptuts_admin_notices () printf (' % s
', esc_html __ (' Dette er en gul beskjed ',' plugin_domain ')); printf (' % s
', esc_html __ (' Dette er en rød feilvarsel ',' plugin_domain ')); Du bør åpenbart bare vise meldinger som er relevante - noe som betyr betinget visning av meldingene dine bare på enkelte skjermer og for enkelte brukere. For å gjøre dette kan du bruke get_current_user_id () og get_current_screen ():
funksjon wptuts_admin_notices () // Vis beskjed hvis brukeren har _wptuts_display_notice 'lagret og på skjermen med id' portefølje '$ screen_id = get_current_screen () -> id; $ display_notice = get_user_meta (get_current_user_id (), '_wptuts_display_notice', true); hvis ($ display_notice && 'portefølje' == $ screen_id) // Skjermvarsler
For vedvarende merknader bør du inkludere en avvisningslink for å tillate brukeren å skjule meldingen. Som følgende eksempel:
/ * Vilkårlig visning varsel * / add_action ('admin_notices', 'wptuts_persistant_notice'); funksjon wptuts_persistant_notice () / * Kontroller at brukeren ikke allerede har klikket for å ignorere meldingen * / if (! get_user_meta (get_current_user_id (), '_wptuts_hide_notice', true)) printf (' % 1 $ s | % 3 $ s
', __ ("Dette er en vedvarende varsel. For å skjule det klikker du på" avvis "," plugin_domain "), esc_url (add_query_arg (' wptus_nag ', wp_create_nonce (' wptus_nag '))), __ (' Dismiss ',' plugin_domain ')); / * Skjul varsel * / add_action ('admin_init', 'wptuts_hide_notice'); funksjon wptuts_hide_notice () if (! isset ($ _GET ['wptus_nag'])) return; // Sjekk nonce check_admin_referer ('wptus_nag', 'wptus_nag'); // oppdatert bruker meta for å angi avvist varsel update_user_meta (get_current_user_id (), '_wptuts_hide_notice', 1); Du kan også bruke ajax til å avvise administrasjonsmeldinger, men du bør også gi et tilbakebetaling av ikke-JavaScript.
WordPress gir stil for to "typer" knapper: "primær" og "sekundær". Den tidligere vises som en blå knapp, og det bør bare være en av disse knappene på en hvilken som helst side. Den sekundære knappen er en hvit knapp. WordPress gir et par hjelpefunksjoner for å lage knapper: get_submit_button () / submit_button () funksjoner.
submit_button (__ ('Send inn tekst', 'plugin_domain'), 'primary', 'submit'); Handlinger som er "ødeleggende", for eksempel en lenke som sletter noe, skal være rød. Det er ofte klasser du kan bruke (som søppel) som vil gjøre dette for deg. For andre lenker, ordner WordPress automatisk fargene, og dette bør ikke overskrides.
Lenker på tabeller (for eksempel innleggstabellen) skal filtrere tabellen, og ikke omdirigere brukeren. Unntaket er 'handlingskoblinger', som vises når du svinger over en rad (for eksempel koblingen 'rediger' og 'søppel').
Du kan (og bør) bruke sidenikoner på adminssidene dine. Ideelt sett bør disse være tilpassede (unngå å bruke de samme ikonene til forskjellige formål). For å endre ikonet for en egendefinert innleggstype kan du (betinget) skrive ut CSS i administrasjonshodet for å overstyre standardikonbildet.
Du må sørge for at du bare gjør dette på posttypens sider, for ikke å overstyre ikoner på andre sider. Her er et eksempel på hvordan:
post_type; hvis ('event' == $ post_type) ?> For egendefinerte admin sider kan du også bruke screen_icon (). Dette skriver ut HTML for skjermikonene. Det tar et (valgfritt) argument: enten en streng (brukt i ID-attributtet til ikonbeholderen) eller et skjermobjekt som brukes til å opprette et passende ID-attributt. For eksempel: screen_icon ( 'myplugin'); vil skrive ut noe som:
Bruker admin_head krok som ovenfor, kan du målrette # Icon-myplugin og gi et bakgrunnsbilde.
For egendefinerte innleggstyper kan menyen angis når du registrerer posttypen:
register_post_type ('event', array (... 'menu_icon' => plugin_dir_url (__FILE__). 'css / images / icon-32.png'; ...)); For faner lagt til i menyen med add_menu_page Du kan angi ikonet som et av argumentene:
Add_menu_page (__ ('Sidetittel', 'plugin_domain'), // Brukes til tittel-kodene på siden __ ('Sidetittel', 'plugin_domain'), // Side som det vises på menyen 'manage_options', / / Muligheter for å få tilgang til denne siden 'wptuts_custom_page_callback', // Tilbakering som skriver ut innholdet på siden plugin_dir_url (__FILE__). 'Css / images / icon-32.png'); Skjerm- og menyikoner skal være gråskala. Et fargerikt menyikon stikker mer tydeligvis ut, og ser ut som "merkelig" for å si mildt. Uansett hvor godt ikonet er, ødelegger det estetikken til admin sidebaret. Enda verre, et fargerikt menyikon sier til meg at du ikke er plaget om å leke med WordPress-brukergrensesnittet, så jeg mistenker at pluginens kode ikke 'spiller bra' med WordPress heller.
Husk at skjermikonet må fungere godt på tre forskjellige bakgrunner:
Det er alltid en god ide å gi brukerne litt ekstra veiledning hvis de trenger det. Imidlertid, inkludert den på siden, kan du introdusere rot, (og hjelpetekst er aldri et alternativ til intuitivt brukergrensesnitt). WordPress lar deg legge til innhold på "hjelp" -fanen som vises øverst til høyre på skjermen. (Skjermalternativer og hjelpefaner kan ofte overses av brukere, men det er tidlige diskusjoner om hvordan du kan forbedre dem. Vær oppmerksom på at dette kun er diskusjoner og ingenting er avgjort).
Muligheten til å legge til «kontekstuell hjelp» har eksistert siden 2,7, men siden 3.3 ble hjelpefanen litt oppdatert, og det ble innført en hjelpelinje.
Du kan legge til din egen kategori med følgende kode. Det er viktig at du bare legger til kontekstuell hjelp på de aktuelle skjermbildene. Du bør også sjekke at metoden WP_Screen :: add_help_tab eksisterer, da ellers pre-3.3 versjoner av WordPress vil kaste en dødelig feil.
add_filter ('contextual_help', 'wptuts_contextual_help', 10, 3); funksjon wptuts_contextual_help ($ contextual_help, $ screen_id, $ skjerm) // Bare legg til til bestemte skjermbilder. Add_help_tab-funksjonen for skjermen ble introdusert i WordPress 3.3. hvis ($ screen_id! = 'screen_id' ||! method_exists ($ skjerm, 'add_help_tab')) returnere $ contextual_help; $ screen-> add_help_tab (array ('id' => 'wptuts-oversikt-fan', 'title' => __ ('Oversikt', 'plugin_domain'), 'content' => ''. __ ('Noen hjelpetekst her', 'plugin_domain'). '
',)); returner $ contextual_help; Når du bruker tabeller på admin siden av pluginet ditt, er det nesten alltid bedre å bruke den samme stylingen som WordPress bruker for sine tabeller. Oppsettet og utseendet er ideelt for å presentere data som produktsalg, aktivitetslogger osv., Som gir brukerne et konsistent grensesnitt. Det er viktig at brukerne instinktivt forventer at sveve over en rad vil avsløre "handlingskoblinger", og at koblinger i kolonnene vil filtrere tabellen. Ikke vær redd for å tilpasse bordet ditt til dine spesifikke behov (endre bredden på kolonner, tilpasset styling for bilder i kolonnen osv.) - men det er viktig å presentere dataene dine på en måte som er bredt kjent og intuitiv til brukerne dine.
Langt den enkleste måten å replikere WordPress 'adminstabell er ved å utvide WP_List_Table klasse. Det er mange artikler som forklarer hvordan du gjør dette - men det beste "opplæringen" er pluginet for tilpasset liste-tabell, som gir deg et bearbeidet eksempel og er utrolig godt kommentert. Vær imidlertid advart, at selv om Codex sier WP_List_Table klassen er egnet til å bli utvidet av utviklere, den faktiske kildekoden markerer denne klassen som "Privat". Potensielt kan WordPress endre klassen - og hvis slike endringer skjer, må du sjekke at de ikke bryter bordet ditt.
Alle jQuery brukergrensesnitt er gitt i WordPress (og hvis pluginet ditt bruker noen, bør det bruke WordPress-skriptene). Dessverre er det ikke nødvendigvis de tilsvarende CSS-stilene. Dette er foreløpig igjen for plugins å gi. Det er imidlertid potensial for at dette endres med denne Trac-billetten. Helen Hou Sandi, kjernen WordPress utvikler, har jobbet med to jQuery UI temaer som utfyller WordPress (en for hver admin fargeskjema). Det er ingen garanti for at dette vil gjøre det til WordPress * - men i alle fall bør du laste ned begge temaene og bruke dem med pluginene dine.
En demo plugin kan lastes ned her. Derfra kan du også trekke ut de to temaene:
Plasser disse i plugin-mappen din. Når du registrerer skript, bruker du temaet valgt av brukeren:
add_action ('wp_enqueue_scripts', 'wptuts_register_scripts'); funksjon 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'); ellers wp_register_style ('wptuts-plugin-jquery-ui-css', plugin_dir_url (__FILE__). 'jquery-ui-fresh.css'); Så kan du ringe wp_enqueue_style ('wptuts-plugin-jquery-ui-css') hvor du trenger (åpenbart, du bør gi stilene et annet håndtak, unikt for pluginet ditt). Dette alene kan gå langt i å hjelpe til med å gi pluginet ditt en titt i samsvar med WordPress.
* Hvis det gjør det til WordPress, kan du fjerne ovenstående fra pluginet ditt og bruke WordPress-stilen i stedet.
Ikke alt innhold i WordPress er et innlegg, en kommentar eller et vedlegg, og noen ganger gir det eksisterende brukergrensesnittet ikke det du trenger. I disse tilfellene er det bare ikke hensiktsmessig å pålegge den "posten" strukturer som eksisterer innfødt. Gravity Forms er for eksempel et plugin som lar deg legge til og administrere skjemaer på nettstedet ditt. Hvis de begrenser seg til det innfødte WordPress brukergrensesnittet, presenterer skjemaer som nesten som innlegg, vil resultatet for eksempel være en verre brukeropplevelse og færre salg for Gravity Forms.
Å gi brukerne det beste UX, er ikke bare å sette alt inne i lister og metaboxer. Hvis pluginet ditt trenger å presentere informasjon på en måte som er fremmed til det opprinnelige WordPress brukergrensesnittet - kan du ikke bli kreativ og eksperimentere. Men hvordan tegner du linjen mellom å være kreativ og integrere med WordPress brukergrensesnittet? Dette var noe brakt opp i kommentarene til Toms post nevnt tidligere. Sannheten er at det kommer ned til personlig vurdering og eksperimenterer for å se hva som fungerer. Tyngdekraften danner i det hele tatt godt:
Viktig, selv om WordPress UI kanskje ikke gir akkurat det du trenger - det er mye å trekke inspirasjon fra. Hvis du for eksempel vil at brukerne skal kunne dra og slippe elementer - kan du se på menyen for å få veiledning. Du bør ikke kaste bort administrasjonsgrensesnittet helt. Noen "prinsipper" av admin-brukergrensesnittet (noen oppført ovenfor) kan oversettes uansett hva du prøver å oppnå, for eksempel: bruk av farge, lenker, knapper og ikoner. Og detaljene saken - å få gradienter, radius og font høyre er viktige for å opprettholde konsistens, spesielt når du gjør noe "annerledes". For drag-og-slipp-eksemplet vil du kanskje bruke den grå stedholderen med en stiplet kantlinje.
Denne oppmerksomheten på detaljer kan virke vanskelig - men å få det riktig er faktisk lat (og i dette tilfellet, riktig så) ting å gjøre. WordPress legger til mye styling på admin siden - og for det meste vil dette bli arvet automatisk av plugin. I andre tilfeller handler det bare om å legge til de riktige klassene til elementene dine.
Følgende artikler i denne serien vil være mye mer "praktiske", men forhåpentligvis har denne artikkelen vist noen umiddelbare og enkle trinn for å gi brukerne en mer konsistent admin. Retningslinjene som er oppført her, er på ingen måte offisielle, og de er heller ikke uttømmende - og jeg ønsker velkommen diskusjon og forslag!
