Share
È stato ampiamente accettato che uno dei maggiori vantaggi di WordPress rispetto ai suoi concorrenti è la sua interfaccia utente di amministrazione. È, nel complesso, molto facile e intuitivo da usare. Inoltre viene costantemente perfezionato e migliorato, con lo schermo di caricamento dei media ora una delle tante cose sotto esame. Sfortunatamente, c'è qualcosa che il team di WordPress-UI non ha il controllo su, che annulla costantemente tutto il loro duro lavoro: plugin e temi.
L'interfaccia utente del tuo plug-in (userò il termine plug-in in questo articolo, ma lo stesso vale per l'interfaccia utente del tuo tema) è uno degli aspetti più importanti del tuo plug-in. Definisce il modo in cui le persone interagiscono con esso, quanto sia facile da usare e forse anche quanto essi godere usandolo. Questo è lo scopo ultimo del tuo plugin: rendere un compito o attività particolare, più facile per il tuo utente finale (in realtà questo è l'obiettivo apparentemente dimenticato dei computer stessi). L'interfaccia utente dovrebbe essere attraente, ma alla fine dovrebbe essere funzionale. Quando decidi come impaginare il tuo plugin, devi decidere come rendere il tuo plug-in facile da usare - meglio ancora, ottenere feedback - questo è essenzialmente ciò che WordPress sta facendo.
Nelle ultime settimane e mesi ci sono state molte discussioni su come l'usabilità di WordPress potrebbe essere migliorata, dai miglioramenti dell'interfaccia utente generale all'accessibilità (se non pensi che l'accessibilità sia un problema per WordPress o per il tuo plugin, ti consiglio di controllare l'eccellente discorso di Graham Armfield da WordCamp Edinburgh). Più recentemente, Tom McFarlin ha suscitato molte discussioni sull'integrazione con l'interfaccia utente di WordPress. La discussione si è spostata sulla necessità di una linea guida per l'interfaccia utente per gli autori di plugin per aiutarli a garantire che il loro plug-in si integrasse perfettamente in WordPress. Questa linea guida sta prendendo forma sotto forma di linee guida per l'interfaccia utente di WordPress.
In questa serie esamineremo i passaggi che è possibile adottare per integrare il plug-in nell'interfaccia utente di WordPress. In questo articolo, ci concentreremo su alcune linee guida di base, nonché alcune delle API dell'interfaccia utente disponibili. Si prega di notare che queste linee guida non sono assolutamente 'ufficiali'. Negli articoli successivi vedremo altri esempi "pratici", tra cui l'utilizzo di metabox nelle pagine di amministrazione personalizzate e l'uso dei puntatori admin di WordPress.
Questa è la ragione più importante. Lo scopo principale sia dell'interfaccia utente di WordPress che del tuo plug-in o tema è facilitare la gestione e la produzione dei contenuti per l'utente finale. È per consentire all'utente di raggiungere uno scopo specifico. Se il tuo plugin o tema introduce un'interfaccia utente che è molto diversa da WordPress, allora stai costringendo l'utente a imparare un'interfaccia completamente nuova. In tal modo stai rendendo più difficile per loro e probabilmente disinstalleranno il tuo plugin e ne troverai un altro. La coerenza è la chiave qui.
In secondo luogo, è solo brutto quando un plugin o un tema sporge come un pollice dolente. L'admin di WordPress è (per lo più) magnificamente coerente - e i plugin che non si adattano sono solo un fastidio. Questo non vuol dire nemmeno che l'interfaccia utente del plugin sia particolarmente brutta. Potrebbe anche darsi che l'interfaccia del plugin sia slick, ma continuerà a sembrare fuori dal contesto.
Il migliore i plug-in si adattano perfettamente a WordPress nella misura in cui è quasi impossibile dire dove si ferma WordPress stesso e il plugin inizia. Sono questi plugin che piace agli utenti, in gran parte perché sembrano destinati a essere lì. I plugin dovrebbero estendere WordPress - non farlo diventare un CMS che il Dr. Frankenstein produrrebbe.
WordPress offre molti modi per aiutarti a "integrarsi" con WordPress. Fornisce anche molti CSS nelle pagine di amministrazione da cui puoi trarre vantaggio. Fare entrambe le cose è un modo efficace di "verifica futura" dell'interfaccia utente del tuo plug-in. Eventuali modifiche apportate a WordPress si rifletteranno anche sul tuo plugin. D'altra parte se si 'va tutto da solo' con l'interfaccia utente di amministrazione - ogni aggiornamento di WordPress porta con sé una maggiore possibilità che l'interfaccia utente del tuo plug-in sia in conflitto con WordPress. Utilizzando gli stili e i layout di WordPress, rendi la vita un po 'più facile per te e per i tuoi utenti.
Potresti pensare che il tuo plugin sia la cosa più importante nel repository, e potrebbe essere il migliore del suo genere là fuori. Ma lo fa veramente bisogno di un primo posto nel menu di amministrazione? Un aspetto importante di qualsiasi interfaccia utente è una semplicità che consente agli utenti di trovare rapidamente ciò che desiderano. Il disordine del menu è l'opposto di questo.
Il tuo plugin potrebbe non avere nemmeno bisogno della sua pagina secondaria. A tutte le pagine delle impostazioni predefinite possono essere aggiunte delle sezioni. Se il tuo plugin ha solo alcune impostazioni e non sarebbero fuori posto in una pagina delle impostazioni esistente, dovresti prendere in considerazione questo.
Se il tuo plugin richiede un posto nel menu di primo livello, pensa attentamente a dove dovrebbe andare. Il menu di amministrazione è suddiviso in tre sezioni: la dashboard, la gestione dei contenuti e le impostazioni. Dove dovrebbe andare la tua voce di menu di primo livello dipende da quale sia lo scopo principale del tuo plugin. Se sta producendo, modificando e gestendo il contenuto, dovrebbe andare nel mezzo. Se il suo scopo è la manutenzione, le prestazioni o la configurazione (ad esempio l'integrazione con software di terze parti, cache o plug-in di backup), questi dovrebbero probabilmente andare in basso.
Infine, il tuo plugin non dovrebbe imporsi troppo. Sporcare il tuo plugin con link "donate", pubblicità o feed dal tuo blog non renderà il tuo plugin ai tuoi utenti. Plugin 'branding' dovrebbe essere evitato, o almeno abbastanza discreto da non entrare in conflitto con l'interfaccia utente di WordPress.
Sebbene ciò non influenzi l'usabilità del plug-in, l'integrazione nell'aspetto di WordPress offre un'esperienza utente perfetta e migliore. Non è che il marchio del plugin possa essere terribile (alcuni sembrano fantastici) - ma più che sembrano fuori luogo.
La maggior parte degli autori di plug-in, comprensibilmente, desidera che il proprio plug-in faccia appello a un numero più ampio di utenti possibile. Uno sfortunato effetto collaterale è che l'utente viene presentato con una scelta di opzioni. Parte della filosofia di WordPress sono le decisioni e non le opzioni:
Come sviluppatori a volte riteniamo che fornire opzioni per tutto sia una buona cosa, non si possono mai avere troppe scelte, giusto? Alla fine queste scelte finiscono per essere tecniche, scelte a cui l'utente medio non ha interesse. È nostro dovere, in quanto sviluppatori, prendere decisioni di progettazione intelligenti ed evitare di attribuire il peso delle scelte tecniche ai nostri utenti finali.
Ci sono due cose che devono essere bilanciate: da un lato si desidera che gli utenti siano in grado di modificare il comportamento del proprio plugin. Dall'altro, troppe opzioni possono rendere difficile la ricerca di una di esse e possono lasciare l'utente sconcertato e frustrato. Non esiste una taglia unica per tutti, ed è un giudizio che dovrebbe essere fatto sulle tue esperienze di ciò che chiedono i tuoi utenti.
Tuttavia, le opzioni non sono l'unico modo per consentire al tuo plug-in di essere ottimizzato:
La voce del menu impostazioni? O il tuo menu di primo livello? Ne ho già trovati alcuni nella voce di menu 'Plugin' prima d'ora. C'è un sacco di dibattito su questo. Per la maggior parte dei plugin, che non hanno bisogno del proprio menu di primo livello, la decisione è presa per loro. Ma per quanto riguarda i plugin che fanno? Posso solo dare la mia opinione qui. Un punto convincente è che alcuni utenti aspettarsi per trovare le impostazioni del plugin sotto il menu del plugin. In alcuni casi, penso che questo esponga un uso improprio del menu di amministrazione: il menu non dovrebbe essere il "menu del plugin", ma un menu associato a qualche tipo di attività (come la creazione e la modifica di post, la visualizzazione di commenti, ecc.). Proprio come WordPress separa le attività dalle impostazioni, quindi anche i plugin.
In secondo luogo, la modifica delle impostazioni è un'attività a sé stante, una che viene eseguita raramente, spesso solo dopo aver installato WordPress o un plug-in. Poiché non è visitato regolarmente, posizionandolo sotto la voce di menu Impostazioni riordina il sottomenu del tuo plugin per l'uso quotidiano.
Se vuoi assicurarti che la tua pagina delle impostazioni non sia persa, ti incoraggio ad aggiungere un link sotto il nome del tuo plug-in sulla pagina 'Plugin'. Questa è la pagina su cui l'utente attaccherà quando attivano il plugin, e così renderà le tue impostazioni molto più semplici.
Ecco un esempio di come ottenere questo:
Accentsconagua
add_filter ('plugin_action_links', 'wptuts_plugin_settings_link', 10, 2); function wptuts_plugin_settings_link ($ links, $ file) if ($ file == 'myplugin / myplugin.php') / * Inserisci il link alla fine * / $ links ['settings'] = sprintf ('% s', admin_url ('options-general.php? page = my_plugin_settings'), __ ('Impostazioni', 'plugin_domain')); return $ links; Se le impostazioni del tuo plug-in non si adattano comodamente a una pagina, dovresti prendere in considerazione l'uso di schede per suddividerle. WordPress utilizza le schede nella pagina Aspetto -> Temi e queste possono essere aggiunte alle tue impostazioni (o alle pagine di amministrazione personalizzate, se necessario). Quando si utilizzano le schede di pagina ci sono poche ragioni per non usare le schede di WordPress. Come fare questo è stato descritto nella serie Impostazioni API di Tom McFarlin qui su Wptuts+.
Ma cosa succede se hai bisogno di troppe schede? Le schede orizzontali non si adattano particolarmente bene e le schede traboccanti possono sembrare confuse e brutte. Questo plugin fa un buon tentativo di gestire molte pagine di impostazioni, ma le linee di impostazioni lo rendono ancora travolgente:
Supponiamo che tutte queste schede siano necessarie (che probabilmente non lo sono), quindi potresti decidere che le schede verticali sono una soluzione più adatta. Ho visto alcuni temi implementare schede verticali (spesso scarsamente), in genere utilizzando il proprio stile. Mentre WordPress non usa le tabulazioni verticali (ad eccezione delle schede di aiuto), dovresti basare i tuoi disegni su ciò che è a tua disposizione. Sentiti libero di sperimentare, ma cerca di mantenerlo simile a WordPress: sarà interessante vedere che cosa viene in mente alla gente.
WordPress ha due tipi di avvisi di amministrazione: avvisi generali e messaggi di errore, rispettivamente con lo styling giallo e rosso. Se il tuo plugin deve mostrare un avviso all'utente, dovresti usare l'uno o l'altro a seconda del contesto del messaggio.
L'uso dell'API di notifica di WordPress è un modo molto semplice per offrire all'utente un'esperienza coerente. Un esempio di come fare questo è:
/ * * Messaggio di amministrazione nag - visualizza un messaggio * / / * Visualizza un avviso che può essere rimosso * / add_action ('admin_notices', 'wptuts_admin_notices'); function wptuts_admin_notices () printf (' %S
', esc_html __ (' Questo è un avviso giallo ',' plugin_domain ')); printf (' %S
', esc_html __ (' Questo è un avviso di errore rosso ',' plugin_domain ')); Ovviamente, dovresti solo visualizzare i messaggi che sono rilevanti, il che significa mostrare in modo condizionale le tue notifiche solo su determinati schermi e per determinati utenti. Per fare questo puoi usare get_current_user_id () e get_current_screen ():
function wptuts_admin_notices () // Visualizza avviso se l'utente ha '_wptuts_display_notice' memorizzato e sullo schermo con id 'portfolio' $ screen_id = get_current_screen () -> id; $ display_notice = get_user_meta (get_current_user_id (), '_wptuts_display_notice', true); if ($ display_notice && 'portfolio' == $ screen_id) // Visualizza avvisi
Per le comunicazioni persistenti è necessario includere un link di eliminazione per consentire all'utente di nascondere il messaggio. Come nell'esempio seguente:
/ * Avviso di visualizzazione condizionale * / add_action ('admin_notices', 'wptuts_persistant_notice'); function wptuts_persistant_notice () / * Verifica che l'utente non abbia ancora cliccato per ignorare il messaggio * / if (! get_user_meta (get_current_user_id (), '_wptuts_hide_notice', true)) printf (' % 1 $ s | % 3 $ s
', __ ("Questo è un avviso persistente. Per nasconderlo, fai clic su" ignora "", "plugin_domain"), esc_url (add_query_arg (' wptus_nag ', wp_create_nonce (' wptus_nag '))), __ (' Elimina ',' plugin_domain ')); / * Nascondi avviso * / add_action ('admin_init', 'wptuts_hide_notice'); function wptuts_hide_notice () if (! isset ($ _GET ['wptus_nag'])) return; // Controlla nonce check_admin_referer ('wptus_nag', 'wptus_nag'); // meta utente aggiornato per indicare avviso ignorato update_user_meta (get_current_user_id (), '_wptuts_hide_notice', 1); Puoi anche usare ajax per eliminare le notifiche di amministrazione, ma dovresti anche fornire un fallback non JavaScript.
WordPress offre uno stile per due "tipi" di pulsanti: "primario" e "secondario". Il primo appare come un pulsante blu e dovrebbe esserci sempre uno solo di questi pulsanti su una determinata pagina. Il pulsante secondario è un pulsante bianco. WordPress offre un paio di funzioni di supporto per la creazione di pulsanti: get_submit_button () / submit_button () funzioni.
submit_button (__ ('Submit text', 'plugin_domain'), 'primary', 'submit'); Le azioni "distruttive", ad esempio un collegamento che elimina qualcosa, dovrebbero essere rosse. Ci sono spesso classi che puoi usare (come spazzatura) che lo farà per te. Per altri collegamenti, WordPress imposta automaticamente i colori e questo non dovrebbe essere sovrascritto.
I collegamenti su tabelle (come la tabella dei post) dovrebbero filtrare la tabella e non reindirizzare l'utente. L'eccezione è "link di azione", che appaiono quando si passa il mouse su una riga (ad esempio i link "modifica" e "cestino").
Puoi (e dovresti) usare le icone delle pagine nelle tue pagine di amministrazione. Idealmente questi dovrebbero essere personalizzati (evitare di riutilizzare le stesse icone per scopi diversi). Per cambiare l'icona per un tipo di messaggio personalizzato puoi (condizionatamente) stampare CSS nell'amministratore per sovrascrivere l'immagine dell'icona predefinita.
Devi assicurarti di farlo solo per le pagine del tuo post-tipo, in modo da non sovrascrivere le icone su altre pagine. Ecco un esempio di come:
post_type; if ('evento' == $ post_type) ?> Per le pagine di amministrazione personalizzate puoi anche utilizzare screen_icon (). Questo stampa l'HTML per le icone dello schermo. Prende un argomento (facoltativo): una stringa (utilizzata nell'attributo ID del contenitore di icone) o un oggetto schermo che viene utilizzato per creare un attributo ID appropriato. Per esempio: screen_icon ( 'myplugin'); stamperà qualcosa come:
Usando il admin_head agganciare come sopra, puoi scegliere come bersaglio # Icona-myplugin e fornire un'immagine di sfondo.
Per i tipi di post personalizzati, è possibile specificare il menu quando si registra il tipo di post:
register_post_type ('event', array (... 'menu_icon' => plugin_dir_url (__FILE__). 'css / images / icon-32.png'; ...)); Per le schede aggiunte al menu usando add_menu_page puoi specificare l'icona come uno degli argomenti:
add_menu_page (__ ('Titolo pagina', 'plugin_domain'), // Usato per i tag title della pagina __ ('Titolo pagina', 'plugin_domain'), // Pagina come appare nel menu 'manage_options', / / Possibilità di accedere a questa pagina 'wptuts_custom_page_callback', // Callback che stampa il contenuto della pagina plugin_dir_url (__FILE__). 'Css / images / icon-32.png'); Le icone dello schermo e del menu dovrebbero essere in scala di grigi. Un'icona di menu colorata più chiaramente sporge, e sembra 'strano' per non dire altro. Indipendentemente da quanto sia buona l'icona, rovina l'estetica della barra laterale dell'amministratore. Peggio ancora, un'icona colorata del menu mi dice che non sei preoccupato di 'giocare bene' con l'interfaccia utente di WordPress, quindi ho il sospetto che il codice del plugin non 'gioca bene' con WordPress.
Ricorda che l'icona dello schermo deve funzionare bene su tre sfondi diversi:
È sempre una buona idea dare ai tuoi utenti una guida in più nel caso in cui ne abbiano bisogno. Tuttavia, includendolo nella pagina si può creare confusione, (e il testo di aiuto non è mai un'alternativa alla progettazione dell'interfaccia utente intuitiva). WordPress ti consente di aggiungere contenuti alla scheda "Guida" che appare in alto a destra sullo schermo. (Le opzioni di schermo e le schede di aiuto possono essere spesso trascurate dagli utenti, tuttavia ci sono discussioni iniziali su come migliorarle. Si prega di notare che si tratta solo di discussioni e non è stato deciso nulla).
La possibilità di aggiungere "aiuto contestuale" è in circolazione dal 2.7, ma dal 3.3 la scheda della guida ha avuto un po 'di rinnovamento, introducendo una barra di aiuto a schede.
È possibile aggiungere la propria scheda con il seguente codice. È importante aggiungere la guida contestuale solo nelle schermate appropriate. Si dovrebbe anche verificare che il metodo WP_Screen :: add_help_tab esiste, altrimenti le versioni precedenti di 3.3 di WordPress genererebbero un errore fatale.
add_filter ('contextual_help', 'wptuts_contextual_help', 10, 3); function wptuts_contextual_help ($ contestual_help, $ screen_id, $ screen) // Aggiungi solo a determinati schermi. La funzione add_help_tab per lo schermo è stata introdotta in WordPress 3.3. if ($ screen_id! = 'screen_id' ||! method_exists ($ screen, 'add_help_tab')) restituisce $ contextual_help; $ screen-> add_help_tab (array ('id' => 'wptuts-overview-tab', 'title' => __ ('Panoramica', 'plugin_domain'), 'contenuto' => ''. __ ('Qualche testo di aiuto qui', 'plugin_domain'). '
',)); restituisce $ contextual_help; Quando si utilizzano le tabelle sul lato amministratore del proprio plug-in, è quasi sempre preferibile utilizzare lo stesso stile utilizzato da WordPress per le sue tabelle. Il layout e l'aspetto sono ideali per presentare dati quali vendite di prodotti, registri delle attività, ecc., Fornendo agli utenti un'interfaccia coerente. È importante sottolineare che gli utenti si aspettano istintivamente che il passaggio del mouse su una riga rivelerà "link di azione" e che i collegamenti nelle colonne filtreranno la tabella. Non aver paura di adattare il tuo tavolo alle tue esigenze specifiche (cambiando la larghezza delle colonne, lo stile personalizzato per le immagini nella colonna, ecc.) - ma è importante presentare i tuoi dati in un modo che sarà ampiamente familiare e intuitivo per i tuoi utenti.
Di gran lunga il modo più semplice per replicare la tabella di amministrazione di WordPress è estendere il WP_List_Table classe. Ci sono numerosi articoli che spiegano come farlo - ma il miglior 'tutorial' è il plug-in Custom List Table, che fornisce un esempio funzionante ed è incredibilmente ben commentato. Tuttavia, sappiate che sebbene il Codex dica il WP_List_Table la classe è adatta per essere estesa dagli sviluppatori, il codice sorgente reale segna questa classe come 'Privata'. Potenzialmente, WordPress potrebbe cambiare la classe - e se tali cambiamenti dovessero accadere dovresti controllare che non rompano la tua tabella.
Tutta l'interfaccia utente di jQuery è fornita in WordPress (e se il tuo plugin ne usa, dovrebbe usare gli script forniti da WordPress). Sfortunatamente, non ci sono necessariamente gli stili CSS corrispondenti. Questo è attualmente lasciato disponibile per i plugin. Tuttavia, c'è la possibilità che questo cambi con questo biglietto Trac. Helen Hou Sandi, sviluppatore core di WordPress, ha lavorato su due temi dell'interfaccia utente jQuery che completano WordPress (uno per ogni schema di colori amministratore). Non c'è alcuna garanzia che ciò avvenga in WordPress * - ma in ogni caso, devi scaricare entrambi i temi e usarli con i tuoi plugin.
Un plug-in demo può essere scaricato qui. Da ciò puoi anche estrarre i due temi:
Inseriscili nella cartella dei plugin. Quando registri gli script, usa il tema selezionato dall'utente:
add_action ('wp_enqueue_scripts', 'wptuts_register_scripts'); function 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'); Quindi puoi chiamare wp_enqueue_style ('wptuts-plugin-jquery-ui-css') dove è necessario (ovviamente, si dovrebbe dare agli stili un diverso handle, unico per il proprio plugin). Questo da solo può fare molto per aiutare a dare al tuo plugin un aspetto coerente con WordPress.
* Se lo fa in WordPress, puoi rimuovere il precedente dal tuo plugin e usare invece lo stile fornito da WordPress.
Non tutto il contenuto in WordPress è un post, un commento o un allegato e talvolta l'interfaccia utente esistente non fornisce ciò che ti serve. In questi casi non è appropriato imporre su di esso le strutture "post" esistenti in modo nativo. Ad esempio, Gravity Forms è un plug-in che ti consente di aggiungere e gestire moduli al tuo sito. Se si limitavano all'interfaccia utente di WordPress nativa, presentando i moduli quasi come i post, ad esempio, il risultato sarebbe un'esperienza utente peggiore e un minor numero di vendite per Gravity Forms.
Dare ai tuoi utenti la migliore UX non è semplicemente mettere tutto dentro elenchi e metabox. Se il tuo plugin deve presentare le informazioni in modo estraneo all'interfaccia utente di WordPress nativa, sentiti libero di essere creativo e di sperimentare. Ma come si disegna la linea tra l'essere creativi e l'integrazione con l'interfaccia utente di WordPress? Questo è stato sollevato nei commenti del post di Tom menzionato in precedenza. La verità è che si tratta di giudizio personale e di sperimentazione per vedere cosa funziona. Le forme di gravità, nel complesso, fanno bene questo:
È importante sottolineare che, sebbene l'interfaccia utente di WordPress potrebbe non fornire esattamente ciò di cui hai bisogno, c'è molto da cui trarre ispirazione. Ad esempio, se vuoi che i tuoi utenti siano in grado di trascinare e rilasciare gli oggetti, puoi consultare la pagina Menu come guida. Non devi scartare completamente l'interfaccia utente di amministrazione. Alcuni "principi" dell'interfaccia utente di amministrazione (alcuni sopra elencati) sono traducibili indipendentemente da ciò che si sta tentando di ottenere, ad esempio: l'uso di colori, collegamenti, pulsanti e icone. E i dettagli contano: ottenere i gradienti, il raggio e il font giusti è importante per mantenere la coerenza, in particolare quando si sta facendo qualcosa di "diverso". Per l'esempio di trascinamento della selezione, è possibile riutilizzare il segnaposto grigio con un bordo tratteggiato.
Questa attenzione ai dettagli potrebbe sembrare difficile, ma farla correttamente è in realtà la cosa pigra (e in questo caso, appropriatamente) da fare. WordPress aggiunge un sacco di stile alla pagina di amministrazione - e per la maggior parte questo sarà ereditato automaticamente dal tuo plugin. In altri casi è solo questione di aggiungere le classi giuste ai tuoi elementi.
I seguenti articoli di questa serie saranno molto più "pratici", ma si spera che questo articolo abbia illustrato alcuni passaggi immediati e facili per fornire agli utenti un amministratore più coerente. Le linee guida qui elencate non sono in alcun modo ufficiali, né sono esaurienti - e gradirei discussioni e suggerimenti!
