Share
Het is al lang algemeen aanvaard dat een van de grootste voordelen van WordPress ten opzichte van zijn concurrenten de gebruikersinterface van de beheerder is. Het is over het algemeen heel gemakkelijk en intuïtief in gebruik. Verder wordt het voortdurend verfijnd en verbeterd, met het media-uploadscherm nu een van de vele dingen die onder de loep worden genomen. Helaas is er iets waar het WordPress-UI-team geen controle over heeft, wat consequent al hun harde werk ongedaan maakt: plug-ins en thema's.
De gebruikersinterface van uw plug-in (ik gebruik de term plugin in dit artikel, maar hetzelfde geldt voor de gebruikersinterface van uw thema) is een van de belangrijkste aspecten van uw plug-in. Het definieert hoe mensen ermee omgaan, hoe gemakkelijk het is om te gebruiken en misschien zelfs hoeveel ze gebruiken genieten het gebruiken. Dit is het uiteindelijke doel van uw plug-in: een bepaalde taak of taken eenvoudiger maken voor uw eindgebruiker (in feite is dit het schijnbaar vergeten doel van computers zelf). De gebruikersinterface moet aantrekkelijk zijn, maar uiteindelijk moet deze functioneel zijn. Wanneer u besluit hoe u uw plug-in wilt indelen, moet u beslissen hoe u uw plug-in gemakkelijk kunt gebruiken - beter nog, feedback krijgen - dit is in wezen wat WordPress doet.
In de afgelopen weken en maanden is er veel discussie geweest over hoe de bruikbaarheid van WordPress kan worden verbeterd - van algemene UI-verbeteringen tot toegankelijkheid (als u denkt dat toegankelijkheid geen probleem is voor zowel WordPress als uw plug-in, raad ik aan om te controleren het uitstekende gesprek van Graham Armfield uit WordCamp Edinburgh). Meer recent leidde Tom McFarlin tot veel discussie over integratie met de gebruikersinterface van WordPress. De discussie verlegde de noodzaak van een UI-richtlijn voor plug-in-auteurs om hen te helpen ervoor te zorgen dat hun plug-in naadloos werd geïntegreerd in WordPress. Deze richtlijn begint vorm te krijgen in de vorm van de gebruikersinterfacierichtlijnen van WordPress.
In deze serie zullen we stappen bekijken die u kunt nemen om uw plug-in te integreren in de gebruikersinterface van WordPress. In dit artikel zullen we ons concentreren op enkele basisrichtlijnen, evenals enkele van de UI API die voor u beschikbaar is. Houd er rekening mee dat deze richtlijnen op geen enkele manier 'officieel' zijn. In de volgende artikelen zullen we meer 'praktische' voorbeelden bekijken, waaronder het gebruik van metaboxen op aangepaste beheerderspagina's en het gebruik van WordPress 'beheerdersaanwijzingen.
Dit is de belangrijkste reden. Het belangrijkste doel van zowel de WordPress UI als uw plug-in of thema is het faciliteren van content management en productie voor de eindgebruiker. Het is om de gebruiker in staat te stellen een specifiek doel te bereiken. Als uw plug-in of thema een UI introduceert die sterk verschilt van die van WordPress, dwingt u de gebruiker om een volledig nieuwe interface te leren. Daarmee maakt u het moeilijker voor hen en zij zullen waarschijnlijk uw plug-in verwijderen en een andere vinden. Consistentie staat hierbij centraal.
Ten tweede is het gewoon lelijk als een plug-in of een thema eruit springt als een pijnlijke duim. De WordPress-beheerder is (meestal) mooi consistent - en plug-ins die niet passen, zijn slechts een oogpijn. Dit wil niet zeggen dat de eigen gebruikersinterface van de plug-in bijzonder lelijk is. Het is best mogelijk dat de interface van de plug-in gelikt is - maar deze zal nog steeds uit de context lijken.
De het beste plug-ins passen naadloos in WordPress in de mate waarin het bijna onmogelijk is om te voorspellen waar WordPress zelf stopt en de plug-in begint. Het zijn deze plug-ins die gebruikers graag gebruiken, grotendeels omdat ze eruit zien alsof ze er zijn. Plugins zouden WordPress moeten uitbreiden - niet het tot een CMS maken dat Dr. Frankenstein zou produceren.
WordPress biedt veel manieren om je te laten 'passen' in WordPress. Het biedt ook veel CSS op de beheerderspagina's waar u van kunt profiteren. Beide doen is een effectieve manier om de gebruikersinterface van uw plug-in 'toekomstvast te maken'. Alle wijzigingen die in WordPress worden aangebracht, worden ook weergegeven in uw plug-in. Aan de andere kant, als u het alleen doet met uw beheerdersinterface - elke WordPress-update brengt een verhoogde kans met zich mee dat uw gebruikersinterface voor plug-ins conflicteert met WordPress. Door de stijlen en lay-outs van WordPress te gebruiken, maakt u het uzelf, maar ook uw gebruikers een beetje gemakkelijker.
Je zou denken dat je plugin het belangrijkste is in de repository, en het is misschien wel de beste in zijn soort daar. Maar doet het werkelijk Heb je een prime spot nodig in het admin-menu? Een belangrijk aspect van elke gebruikersinterface is een eenvoud waarmee gebruikers snel kunnen vinden wat ze willen. Overdrijven van het menu is het tegenovergestelde hiervan.
Uw plug-in heeft misschien zelfs geen eigen subpagina nodig. Op alle pagina's met standaardinstellingen kunnen secties worden toegevoegd. Als uw plug-in maar een paar instellingen heeft en deze zouden niet misstaan op een bestaande instellingenpagina, moet u dit overwegen.
Als uw plug-in een plaats in het hoofdmenu vereist, moet u goed nadenken over waar hij naartoe moet gaan. Het beheerdersmenu is opgesplitst in drie secties: het dashboard, contentbeheer en instellingen. Waar uw menu-item op het hoogste niveau moet gaan, hangt af van wat het primaire doel van uw plug-in is. Als het inhoud produceert, bewerkt en beheert, moet het in het midden staan. Als het doel onderhoud, prestaties of configuratie is (bijvoorbeeld integratie met software van derden, cachegeheugen of back-upplug-ins), moeten deze waarschijnlijk onderaan gaan.
Ten slotte zou je plugin zichzelf niet meer moeten opleggen. Het plaatsen van uw plug-in met 'doneer' links, advertenties of feeds van uw blog zal uw plugin niet geliefd maken bij uw gebruikers. Plugin 'branding' moet worden vermeden, of op zijn minst subtiel genoeg om niet in conflict te komen met de gebruikersinterface van WordPress.
Hoewel dit de bruikbaarheid van de plug-in niet kan beïnvloeden, zorgt de integratie in het uiterlijk van WordPress voor een naadloze en betere gebruikerservaring. Het is niet dat het merk van de plug-in vreselijk is (sommige zien er fantastisch uit), maar meer dat ze niet op hun plaats lijken.
De meeste plugin-auteurs willen begrijpelijk dat hun plug-in zo breed mogelijk gebruikers aanspreekt. Een ongelukkig neveneffect is dat de gebruiker een cock-pit met opties krijgt aangeboden. Onderdeel van de filosofie van WordPress zijn beslissingen en geen opties:
Als ontwikkelaars denken we soms dat het bieden van opties voor alles een goede zaak is, je kunt nooit teveel keuzes hebben, toch? Uiteindelijk zijn deze keuzes uiteindelijk technische, keuzes waar de gemiddelde eindgebruiker geen interesse in heeft. Het is onze plicht als ontwikkelaars om slimme ontwerpbeslissingen te nemen en te voorkomen dat we technische gebruikers bewust maken van onze eindgebruikers.
Er zijn twee dingen die moeten worden uitgebalanceerd: aan de ene kant wilt u dat gebruikers de manier kunnen aanpassen waarop uw plug-in zich gedraagt. Aan de andere kant kunnen te veel opties het moeilijk vinden om ze te vinden en kunnen ze de gebruiker verbijsterd en gefrustreerd maken. Er is hier geen one-size-fits-all, en het is een oordeel dat moet worden gemaakt over uw ervaringen met wat uw gebruikers vragen.
Opties zijn echter niet de enige manier om uw plug-in te laten aanpassen:
Het menu-item instellingen? Of uw eigen hoofdmenu? Ik heb zelfs eerder een aantal gevonden in het menu-item 'Plug-ins'. Er is veel discussie hierover. Voor de meeste plug-ins, die geen eigen menu op het hoogste niveau nodig hebben, is de beslissing voor hen genomen. Maar hoe zit het met plug-ins die dat doen? Ik kan hier alleen mijn mening geven. Een overtuigend punt is dat sommige gebruikers verwachten om de plug-in-instellingen te vinden onder het menu van de plug-in. In sommige gevallen denk ik dat dit een verkeerd gebruik van het admin-menu blootlegt - het menu moet niet het "plug-insmenu" zijn, maar een menu dat is gekoppeld aan een soort taak (zoals het maken en bewerken van berichten, het bekijken van reacties, enz.). Net zoals WordPress taken scheidt van instellingen, moeten plugins ook.
Ten tweede is het veranderen van instellingen een op zichzelf staande taak - een taak die zelden wordt uitgevoerd, vaak pas na het installeren van WordPress of een plug-in. Omdat het niet regelmatig wordt bezocht, zorgt het plaatsen onder het menu-item Instellingen ervoor dat het submenu van uw plug-in voor dagelijks gebruik wordt opgeruimd.
Als je zeker wilt zijn dat je instellingenpagina niet wordt gemist, moedig ik je aan om een link ernaar toe te voegen onder de naam van je plugin op de 'Plug-ins' pagina. Dit is de pagina waarop de gebruiker terechtkomt wanneer deze de plug-in activeert, en dus het vinden van uw instellingen veel eenvoudiger wordt.
Hier is een voorbeeld van hoe dit te bereiken:
Accentsconagua
add_filter ('plugin_action_links', 'wptuts_plugin_settings_link', 10, 2); functie wptuts_plugin_settings_link ($ links, $ bestand) if ($ bestand == 'myplugin / myplugin.php') / * Voeg de link aan het einde toe * / $ links ['settings'] = sprintf ('% s', admin_url ('options-general.php? page = my_plugin_settings'), __ ('Instellingen', 'plugin_domain')); return $ links; Als uw plugin-instellingen niet gemakkelijk op één pagina passen, kunt u overwegen tabbladen te gebruiken om ze op te splitsen. WordPress gebruikt tabbladen op de pagina Uiterlijk -> Thema's en deze kunnen aan uw instellingen worden toegevoegd (of aangepaste beheerderspagina's, indien nodig). Bij het gebruik van paginatabs is er heel weinig reden om de tabbladen van WordPress niet te gebruiken. Hoe dit te doen werd behandeld in de Settings API-serie van Tom McFarlin hier op Wptuts+.
Maar wat als u te veel tabbladen nodig heeft? Horizontale tabbladen schalen niet bijzonder goed - en overlopende tabbladen kunnen verwarrend en lelijk lijken. Deze plug-in is een goede poging om veel instellingenpagina's aan te pakken, maar de regels maken het nog steeds overweldigend:
Laten we aannemen dat al deze tabbladen nodig zijn (wat ze waarschijnlijk niet zijn), dan zou je kunnen besluiten dat verticale tabbladen een geschiktere oplossing zijn. Ik heb een paar thema's gezien die verticale tabs implementeren (vaak slecht), meestal met behulp van hun eigen stijl. Hoewel WordPress geen verticale tabbladen gebruikt (met uitzondering van de hulptabbladen), moet u uw ontwerpen baseren op wat voor u beschikbaar is. Experimenteer gerust, maar probeer het native te laten lijken op WordPress - het zal interessant zijn om te zien wat mensen bedenken.
WordPress kent twee soorten beheerdersmeldingen: algemene mededelingen en foutmeldingen - ze worden respectievelijk geel en rood weergegeven. Als uw plug-in een kennisgeving voor de gebruiker moet weergeven, moet u de ene of de andere gebruiken, afhankelijk van de context van het bericht.
Het gebruik van de Notice API van WordPress is een zeer eenvoudige manier om de gebruiker een consistente ervaring te bieden. Een voorbeeld van hoe dit te doen is:
/ * * Admin notice nag - geeft een bericht weer * / / * Toon een bericht dat kan worden verworpen * / add_action ('admin_notices', 'wptuts_admin_notices'); function wptuts_admin_notices () printf (' % s
', esc_html __ (' Dit is een gele mededeling ',' plugin_domain ')); printf (' % s
', esc_html __ (' Dit is een rode foutwaarschuwing ',' plugin_domain ')); U moet natuurlijk alleen berichten weergeven die relevant zijn - wat betekent dat u uw kennisgevingen op bepaalde schermen en voor bepaalde gebruikers voorwaardelijk laat zien. Om dit te doen, kunt u gebruiken get_current_user_id () en get_current_screen ():
function wptuts_admin_notices () // Bericht weergeven als gebruiker '_wptuts_display_notice' heeft opgeslagen en op scherm met 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) // Displaymeldingen
Voor persistente kennisgevingen moet u een link om te verwijderen opnemen zodat de gebruiker het bericht kan verbergen. Zoals het volgende voorbeeld:
/ * Voorwaardelijke kennisgeving * / add_action ('admin_notices', 'wptuts_persist_notice'); function wptuts_persistant_notice () / * Controleer of de gebruiker nog niet heeft geklikt om het bericht te negeren * / if (! get_user_meta (get_current_user_id (), '_wptuts_hide_notice', true)) printf (' % 1 $ s | % 3 $ s
', __ ("Dit is een blijvende melding. Om het te verbergen, klik je op' sluiten '",' plugin_domain '), esc_url (add_query_arg (' wptus_nag ', wp_create_nonce (' wptus_nag '))), __ (' Dismiss ',' plugin_domain ')); / * Verberg kennisgeving * / add_action ('admin_init', 'wptuts_hide_notice'); function wptuts_hide_notice () if (! isset ($ _GET ['wptus_nag'])) return; // Controleer nonce check_admin_referer ('wptus_nag', 'wptus_nag'); // bijgewerkte gebruikersmeta om verworpen melding update_user_meta (get_current_user_id (), '_wptuts_hide_notice', 1) aan te geven; U kunt ook ajax gebruiken om beheerdersmededelingen te verwijderen, maar u moet ook een niet-JavaScript-fallback opgeven.
WordPress biedt styling voor twee 'typen' knoppen: 'primair' en 'secundair'. De eerste wordt weergegeven als een blauwe knop en er mag alleen een van deze knoppen op een bepaalde pagina staan. De secundaire knop is een witte knop. WordPress biedt een aantal hulpfuncties voor het maken van knoppen: get_submit_button () / verzendknop() functies.
submit_button (__ ('Submit text', 'plugin_domain'), 'primary', 'submit'); Acties die 'destructief' zijn, bijvoorbeeld een link die iets verwijdert, moeten rood zijn. Er zijn vaak klassen die je kunt gebruiken (zoals uitschot) die dit voor je zal doen. Voor andere links stelt WordPress automatisch de kleuren in en dit mag niet worden genegeerd.
Koppelingen op tabellen (zoals de tabel met posts) moeten de tabel filteren en de gebruiker niet omleiden. De uitzondering is 'actiekoppelingen' die worden weergegeven wanneer u de muisaanwijzer over een rij beweegt (bijvoorbeeld de koppelingen 'bewerken' en 'prullenbak').
U kunt (en zou moeten) paginapictogrammen gebruiken op uw beheerderspagina's. Idealiter zouden deze op maat gemaakt moeten zijn (vermijd het opnieuw gebruiken van dezelfde pictogrammen voor verschillende doeleinden). Als u het pictogram voor een aangepast berichttype wilt wijzigen, kunt u (voorwaardelijk) CSS in de beheerderskop afdrukken om de standaardpictogramafbeelding te overschrijven.
U moet ervoor zorgen dat u dit alleen doet voor de pagina's van uw posttypen, zodat u pictogrammen op andere pagina's niet overschrijft. Hier is een voorbeeld van hoe:
post_type; if ('event' == $ post_type) ?> Voor aangepaste beheerderspagina's kunt u ook gebruiken screen_icon (). Hiermee wordt de HTML afgedrukt voor de schermpictogrammen. Er is één (optioneel) argument nodig: een tekenreeks (gebruikt in het ID-kenmerk van de pictogramcontainer) of een schermobject dat wordt gebruikt om een geschikt ID-kenmerk te maken. Bijvoorbeeld: screen_icon (myplugin); zal iets als afdrukken afdrukken:
De ... gebruiken admin_head haak zoals hierboven, je kunt richten # Icon-myplugin en geef een achtergrondafbeelding.
Voor aangepaste berichttypen kan het menu worden opgegeven wanneer u het berichttype registreert:
register_post_type ('event', array (... 'menu_icon' => plugin_dir_url (__FILE__). 'css / images / icon-32.png'; ...)); Voor tabbladen die aan het menu zijn toegevoegd met add_menu_page u kunt het pictogram als een van de argumenten opgeven:
add_menu_page (__ ('Paginatitel', 'plugin_domain'), // Gebruikt voor de title-tags van de pagina __ ('Paginatitel', 'plugin_domain'), // Pagina zoals deze wordt weergegeven in het menu 'manage_options', / / Mogelijkheid om deze pagina te openen 'wptuts_custom_page_callback', // Terugbellen waarmee de inhoud van de pagina plugin_dir_url (__FILE__) wordt afgedrukt. 'Css / images / icon-32.png'); Scherm- en menupictogrammen moeten grijswaarden zijn. Een kleurrijk menupictogram steekt duidelijker uit en ziet er op zijn zachtst gezegd 'vreemd' uit. Ongeacht hoe goed het pictogram is, het ruïneert de esthetiek van de admin-zijbalk. Erger nog, een kleurrijk menupictogram zegt me dat je niet de moeite neemt om 'leuk te spelen' met de gebruikersinterface van WordPress, dus ik vermoed dat de code van de plug-in 'niet leuk' speelt met WordPress.
Vergeet niet dat het schermpictogram goed moet werken op drie verschillende achtergronden:
Het is altijd een goed idee om uw gebruikers wat extra begeleiding te geven voor het geval ze het nodig hebben. Het opnemen op de pagina kan echter rommel opleveren (en helptekst is nooit een alternatief voor intuïtieve UI-ontwerp). Met WordPress kunt u inhoud toevoegen aan het tabblad 'Help' dat rechtsboven op het scherm wordt weergegeven. (Schermopties en Help-tabbladen kunnen vaak over het hoofd worden gezien door gebruikers, maar er zijn vroege discussies over hoe ze te verbeteren. Let op: dit zijn alleen discussies en er is niets besloten).
De mogelijkheid om 'contextuele hulp' toe te voegen bestaat al sinds 2.7, maar sinds 3.3 is de help-tab een beetje opgeknapt, met een hulpbalk met tabbladen.
U kunt uw eigen tabblad toevoegen met de volgende code. Het is belangrijk dat u alleen de contextuele hulp toevoegt op de juiste schermen. Je moet ook controleren of de methode WP_Screen :: add_help_tab bestaat, omdat anders pre-3.3 versies van WordPress een fatale fout zullen veroorzaken.
add_filter ('contextual_help', 'wptuts_contextual_help', 10, 3); functie wptuts_contextual_help ($ contextual_help, $ screen_id, $ screen) // Alleen toevoegen aan bepaalde scherm (en). De add_help_tab-functie voor scherm werd geïntroduceerd in WordPress 3.3. if ($ screen_id! = 'screen_id' ||! method_exists ($ screen, 'add_help_tab')) return $ contextual_help; $ scherm-> add_help_tab (array ('id' => 'wptuts-overview-tab', 'title' => __ ('Overzicht', 'plugin_domain'), 'content' => ''. __ ('Enkele helptekst hier', 'plugin_domain'). '
',)); return $ contextual_help; Bij het gebruik van tabellen aan de adminzijde van uw plug-in is het bijna altijd beter om dezelfde stijl te gebruiken die WordPress voor zijn tabellen gebruikt. De lay-out en het uiterlijk zijn ideaal voor het presenteren van gegevens zoals productverkoop, activiteitenlogboeken, enzovoort, zodat uw gebruikers een consistente interface krijgen. Belangrijk is dat de gebruikers instinctief verwachten dat het zweven boven een rij 'actielinks' zal onthullen en dat links in de kolommen de tabel zullen filteren. Wees niet bang om uw tabel aan te passen aan uw specifieke behoeften (het veranderen van de breedte van kolommen, aangepaste styling voor afbeeldingen in de kolom, etc.) - maar het is belangrijk om uw gegevens te presenteren op een manier die algemeen bekend en intuïtief is voor uw gebruikers.
Verreweg de gemakkelijkste manier om de admin-tabel van WordPress te repliceren is door de WP_List_Table klasse. Er zijn talloze artikelen waarin wordt uitgelegd hoe dit moet worden gedaan, maar de beste 'zelfstudie' is de plug-in Aangepaste lijsttabel, die u een goed voorbeeld geeft en ongelooflijk goed wordt becommentarieerd. Wees echter gewaarschuwd, hoewel de Codex zegt dat WP_List_Table klasse is geschikt om door ontwikkelaars te worden uitgebreid, de eigenlijke broncode markeert deze klasse als 'Privé'. Potentieel kan WordPress de klasse veranderen - en als dergelijke wijzigingen gebeuren, moet u controleren of ze uw tabel niet breken.
De volledige gebruikersinterface van jQuery wordt aangeboden in WordPress (en als uw plug-in er een gebruikt, moet deze de door WordPress meegeleverde scripts gebruiken). Helaas zijn er niet noodzakelijk de bijbehorende CSS-stijlen. Dit wordt momenteel overgelaten aan plug-ins om te voorzien. Met dit Trac-ticket kan dit echter veranderen. Helen Hou Sandi, de belangrijkste ontwikkelaar van WordPress, heeft gewerkt aan twee jQuery UI-thema's die een aanvulling vormen op WordPress (één voor elk admin-kleurenschema). Er is geen garantie dat dit in WordPress * zal terechtkomen - maar in ieder geval zou u beide thema's moeten downloaden en ze met uw plug-ins moeten gebruiken.
Een demo-plug-in kan hier worden gedownload. Daaruit kun je ook de twee thema's extraheren:
Plaats deze in uw plugin-map. Wanneer u scripts registreert, gebruikt u het thema dat door de gebruiker is geselecteerd:
add_action ('wp_enqueue_scripts', 'wptuts_register_scripts'); functie 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'); Dan kun je bellen wp_enqueue_style ('wptuts-plugin-jquery-ui-css') waar je moet zijn (uiteraard moet je de stijlen een ander handvat geven, uniek voor je plug-in). Dit alleen al kan een lange weg helpen om uw plug-in een uiterlijk te geven dat consistent is met WordPress.
* Als het in WordPress terecht komt, kun je het bovenstaande uit je plug-in verwijderen en in plaats daarvan de door WordPress geleverde styling gebruiken.
Niet alle inhoud in WordPress is een bericht, opmerking of bijlage en soms biedt de bestaande gebruikersinterface niet wat u nodig hebt. In deze gevallen is het gewoon niet gepast om het de 'post'-structuren op te leggen die in eigen land bestaan. Gravity Forms is bijvoorbeeld een plug-in waarmee u formulieren aan uw site kunt toevoegen en beheren. Als ze zich beperkten tot de native WordPress UI, waardoor formulieren bijna net zo zouden zijn als posts, zou het resultaat een slechtere gebruikerservaring zijn en minder verkopen voor Gravity Forms.
Uw gebruikers de beste UX geven, is niet simpelweg alles in lijsten en metaboxen plaatsen. Als uw plug-in informatie moet presenteren op een manier die vreemd is aan de native WordPress UI, voel u dan vrij creatief te worden en te experimenteren. Maar hoe trek je de grens tussen creatief zijn en integreren met de gebruikersinterface van WordPress? Dit was iets dat werd genoemd in de opmerkingen van Tom's eerder genoemde functie. De waarheid is dat het erop aan komt persoonlijk te oordelen en te experimenteren om te zien wat werkt. Zwaartekrachtvormen doen het over het algemeen goed:
Belangrijk is dat, hoewel de gebruikersinterface van WordPress niet precies biedt wat u nodig hebt, er veel is om inspiratie uit te halen. Als u bijvoorbeeld wilt dat uw gebruikers items kunnen verslepen en neerzetten, kunt u voor begeleiding naar de pagina Menu's gaan. U moet de beheerdersinterface niet volledig verwijderen. Sommige 'principes' van de beheerdersinterface (sommige hierboven genoemd) zijn vertaalbaar, ongeacht wat u probeert te bereiken, zoals: het gebruik van kleur, links, knoppen en pictogrammen. En de details zijn belangrijk - de gradiënten, radius en het lettertype goed zijn belangrijk om de consistentie te behouden, vooral wanneer u iets 'anders' doet. Voor het voorbeeld van slepen en neerzetten wilt u de grijze plaatshouder mogelijk opnieuw gebruiken met een gestreepte rand.
Deze aandacht voor detail lijkt misschien moeilijk - maar om het goed te doen is eigenlijk het luie (en in dit geval, passend) te doen ding. WordPress voegt veel styling toe aan de beheerderspagina - en voor het grootste deel wordt dit automatisch overgenomen door je plug-in. In andere gevallen is het gewoon een kwestie van de juiste klassen aan uw elementen toevoegen.
De volgende artikelen in deze serie zullen een stuk 'praktischer' zijn, maar hopelijk heeft dit artikel enkele directe en eenvoudige stappen geïllustreerd om uw gebruikers een consistentere beheerder te bieden. De richtlijnen die hier worden opgesomd, zijn op geen enkele manier officieel en ook niet exhaustief - en ik zou graag de discussie en suggesties toejuichen!
