Det känns som att allt vi berör är noggrant utformat: webbplatser, telefoner, tunnelbanekartor och så vidare. Även de saker som vi brukade ta för givet: termostater, rökdetektorer och bilens instrumentpaneler får nu en noggrann användarupplevelsebehandling.
Design handlar inte bara om utseende och känsla: det handlar om att överväga alla sätt som en användare behöver interagera med vår enhet / verktyg / skärm / objekt.
Detta gäller även programmering.
Programmeringsspråk är stora, komplicerade världar. Även PHP, som många programmeringssnobb tror är för "lätt", är faktiskt en ganska komplicerad mix av funktioner och klasser som uppträder på mycket inkonsekvent sätt.
Syntaxen, metoderna och namnen har utvecklats under många år över miljontals olika användare och applikationer. De flesta tenderar att reflektera den underliggande konstruktionen av internalerna - inte nödvändigtvis hur du skulle vilja använda den.
När jag började skriva JavaScript tillbaka 2006 eller så var det en röra. Så här hittade jag en tagg med en viss klass och flytta den runt DOM då:
var uls = getElementsByTagName ("ul"); var classToSearch = "matar"; för (var i = 0; i < uls.length; i++) var classes = uls[i].getClasses(); for (var j = 0; j < classes.length; j++) if (classes[j] == classToSearch) myUL = uls[i]; var $li = document.createElement('li'); $li.innerHTML = 'Steak'; myUL.innerHTML += $li;
Gjort!
jQuery gjorde JavaScript roligt igen. I slutet av 2000-talet var effekten så dramatisk att jag kommer ihåg min pappa frågar mig om "lite jkwery sak" han läste om i Wall Street Journal. Men trots den stora effekten har inte jQuery lagt till några "nya funktioner" för JavaScript. Det tog bara de saker som utvecklare hade att göra och bröt det ner i riktigt tydliga mönster.
I stället för att återuppfinna hur man hittar saker på sidan, utnyttjade de vad folk redan visste: CSS-väljare. Då handlade det bara om att samla in många av de gemensamma åtgärderna och organisera dem till några dussin funktioner. Låt oss försöka det tidigare exemplet igen, nu med jQuery:
var $ li = $ ('
Under 2006 köpte jag en 680 sidbok på Ajax. Med jQuerys stora API ersattes det ganska mycket av detta:
$ .Post ();
Även om API har kommit för att beteckna "tredjepartstjänst" betyder det helt enkelt att programmeringsgränssnittet ska prata med ett system. Precis som det finns ett Twitter API eller ett Facebook API finns ett WordPress API. Du gör inte råa databasfrågor för att skapa ett inlägg, eller hur? Du använder wp_insert_post
.
Men massor av designhål plågar WordPress API. Du kan använda get_the_title
men get_the_permalink
genererar ett fel du använder get_permalink
. Hej, när du har ett decennier långt open-source-projekt med tusentals människor kod och miljontals användare: du kommer att få några särdrag.
Du kan spara mycket tid genom att maskera dessa quirks och skriva till vanor och beteenden hos programmeraren du skriver för (vilket kan vara du). Här kan du designa rätt gränssnitt för att programmera plugins och teman som du gör varje dag.
För att påskynda vårt arbete och skära ner på repetitiva uppgifter har jag skapat bibliotek för att hantera kommandon och anpassningar jag behöver hela tiden.
Ta till exempel källa till en postens miniatyrbild. Visas där finns ingen inbyggd WordPress-funktion för att fånga en miniatyrbild baserat på ett inläggs ID (endast bilaga ID).
Vilket innebär att jag ofta tycker att jag gör det här:
$ thumb_id = get_post_thumbnail_id (get_the_ID ()); $ src = wp_get_attachment_thumb_url ($ thumb_id); eko "';
Men det måste bli ett bättre sätt!
funktion get_thumbnail_src ($ post) $ thumb_id = get_post_thumbnail_id ($ post); $ src = wp_get_attachment_thumb_url ($ thumb_id); returnera $ src; eko';
Mycket bättre! Faktum är att du själv använder det hela tiden och sedan delar med andra utvecklare i ditt företag.
Din vän har problem med det, så han ringer dig för att felsöka och du ser:
eko "';
Så det verkar som om han av misstag använt get_post
istället för get_the_ID
. Du skriker på honom. Men vänta en sekund, varför inte gör det mer accepterande?
Kanske kan vi justera vår funktion så att den kan ta en WP_Post
objekt och ge fortfarande användaren vad de förväntar sig. Låt oss gå tillbaka till den funktionen:
funktion get_thumbnail_src ($ post) om (is_object ($ post) && isset ($ post-> ID)) $ post = $ post-> ID; annars om (is_array ($ post) && isset ($ post ['ID'])) $ post = $ post ['ID']; $ thumb_id = get_post_thumbnail_id ($ post); $ src = wp_get_attachment_thumb_url ($ thumb_id); returnera $ src;
Så om de skickar en WP_Post
objekt eller En grupp, din funktion hjälper fortfarande dem att få vad de behöver. Det här är en stor del av ett framgångsrikt API: gömmer den röriga tarmarna. Du kan skapa separata funktioner för get_thumbnail_src_by_post_id
och get_thumbnail_src_by_wp_post_object.
Faktum är att för mer komplicerade omvandlingar kan det vara att föredra, men du kan förenkla gränssnittet genom att ha en enda funktionsväg till rätt underrutin. Oavsett vad användaren skickar returnerar funktionen konsekvent en sträng för bildkällan.
Låt oss fortsätta: Vad händer om de skickar ingenting?
funktion get_thumbnail_src ($ post = false) if (false === $ post) $ post = get_the_ID (); annars om (is_object ($ post) && isset ($ post-> ID)) $ post = $ post-> ID; annars om (is_array ($ post) && isset ($ post ['ID'])) $ post = $ post ['ID']; $ thumb_id = get_post_thumbnail_id ($ post); $ src = wp_get_attachment_thumb_url ($ thumb_id); returnera $ src;
Vi har förenklat än en gång så användaren behöver inte skicka ett inlägg eller även ett post-ID. När i slingan behövs allt som behövs:
eko "';
Vår funktion kommer som standard till nuvarande postens ID. Detta blir till en riktigt värdefull funktion. För att se till att det här kommer att fungera snyggt, låt oss sätta det in i en klass så att det inte förorenar det globala namnutrymmet.
/ * Plugin Name: JaredTools Beskrivning: Min verktygslåda för WordPress-teman. Författare: Jared Novack Version: 0.1 Författare URI: http://upstatement.com/ * / class JaredsTools offentlig statisk funktion get_thumbnail_src ($ post = false) if (false === $ post) $ post = get_the_ID ; annars om (is_object ($ post) && isset ($ post-> ID)) $ post = $ post-> ID; annars om (is_array ($ post) && isset ($ post ['ID'])) $ post = $ post ['ID']; $ thumb_id = get_post_thumbnail_id ($ post); $ src = wp_get_attachment_thumb_url ($ thumb_id); returnera $ src;
Och snälla du förklara inte din klass med WP
. Jag gör detta till en statisk statisk funktion eftersom jag vill ha den tillgänglig överallt, och den ändras inte: inmatningen eller exekveringen ändrar inte funktionen eller objektet.
Det sista samtalet till denna funktion är:
eko "';
Låt oss gå vidare på ett mer komplicerat behov. När jag skriver plugins finner jag alltid att jag ska skapa olika typer av fel och / eller uppdatera meddelanden.
Men den händelsebaserade syntaxen har alltid bugged mig:
add_action ('admin_notices', 'show_my_notice'); functon show_my_notice () echo '';Dina saker har blivit uppdaterade
Det finns många bra skäl att WordPress följer den här händelsebaserade arkitekturen. Men det är inte intuitivt, om du inte vill sitta och memorera olika filter och åtgärder.
Låt oss göra den här matchen det enklaste användningsfallet: Jag måste visa ett administrativ meddelande. Jag gillar att utforma det här API-först: där hittar jag det bästa sättet att hänvisa till funktionen i min kod. Jag skulle vilja läsa så här:
funktion thing_that_happens_in_my_plugin ($ post_id, $ värde) $ updated = update_post_meta ($ post_id, $ value); om ($ uppdaterad) JaredsTools :: show_admin_notice ("Dina saker har uppdaterats") else JaredsTools :: show_admin_notice ("Fel vid uppdatering av din sak", "fel");
När jag har slutpunkten utformad kan jag uppfylla designkravet:
klassen JaredsTools public static function show_admin_notice ($ message, $ class = 'updated') add_action ('admin_notices', funktion () använd ($ message, $ class) echo ''; );'$ Budskap.'
Mycket bättre! Nu behöver jag inte skapa alla dessa extrafunktioner eller kom ihåg gale kroknamn. Här använder jag PHP anonyma funktioner (kallas även "stängningar") som låter oss knyta en funktion direkt till en åtgärd eller ett filter.
Detta sparar dig från att ha en massa extra funktioner som flyter runt dina filer. De använda sig av
kommandot låter oss överföra argument från föräldrafunktionen till barns stängning.
Nu ringer en annan medarbetare dig över. Hon vet inte varför hennes administrativa meddelande inte blir röd:
JaredsTools :: show_admin_notice ("Fel vid uppdatering av din sak", "röd");
Det beror på att hon skickar "röd" (vilket hon förväntar sig skulle vända rutan röd) när hon i själva verket skulle skicka namnet på klass den där triggers röd. Men varför inte göra det lättare?
offentlig statisk funktion show_notice ($ message, $ class = 'updated') $ class = trim (strtolower ($ class)); om ("gul" == $ klass) $ class = 'updated'; om ('röd' == $ klass) $ class = 'error'; add_action ("admin_notices", funktion () använd ($ text, $ class) echo ''; );'. $ text. '
Vi har nu accepterat mer användartolerans som gör det lättare att dela och för oss när vi kommer tillbaka för att använda det månader från och med nu.
Efter att ha byggt ett antal av dessa, här är några av de principer jag har lärt mig att göra dessa verkligen användbara för mitt team och jag.
1. Design först och låt funktionens bygga matcha hur folk vill använda den.
2. Spara ditt tangentbord! Gör genvägar för vanliga uppgifter.
3. Ge förnuftiga standardvärden.
4. Var minimal. Låt ditt bibliotek hantera behandlingen.
5. Var förlåtande på inmatning, men exakt på produktionen.
6. Att sagt använda så få funktionsargument som möjligt är fyra en bra max. Därefter bör du göra det till en alternativmatris.
7. Organisera ditt bibliotek i separata klasser för att täcka olika områden (administratör, bilder, anpassade inlägg etc.).
8. Dokument med exempelkod.
Vid Upstatement gör våra bibliotek för Timber det enklare att bygga teman och Jigsaw ger tidsbesparande genvägar för att anpassa varje installering.
De tidsbesparingar som dessa verktyg ger, ger oss möjlighet att spendera mer tid på att bygga de nya och innovativa delarna av varje webbplats eller app. Genom att ta de kommandon som annars är esoteriska (som att lägga till en kolumn till admin posten tabeller) och göra enkla gränssnitt: någon designer eller utvecklare hos vårt företag kan fullt ut anpassa varje webbplats med samma makt som en proffsutvecklare av WordPress..