Onze werkwijze uitgelegd voor WordPress professionals

Onlangs hebben we praktische tools voor WordPress professionals besproken. Maar welke werkwijze hanteren we eigenlijk bij het gebruik van die tools voor de ontwikkeling van WordPress websites? In dit artikel leggen we aan WordPress professionals en geïnteresseerden uit hoe wij het proces van WordPres website ontwikkeling aanpakken.

Inhoud

[toc heading_levels=”2″]

Hack het ontwikkelproces

Wanneer we een website ontwikkelen houden we niet vast aan de traditionele software development methodology. Deze methode kenmerkt zich door een intensieve voorbereiding met het opstellen van een functioneel, technisch en grafisch ontwerp, gevolgd door een lang ononderbroken ontwikkel-traject. De veronderstelling is dat het mogelijk moet zijn om vooraf tot een gezamenlijk begrip te komen van hoe de website moet worden, door alle wensen en eisen van de klant vast te leggen in een document.

In de praktijk merken we juist dat je dit gezamenlijk begrip steeds meer met elkaar opbouwt door voortschrijdend inzicht tijdens het gehele ontwikkelproces. Voor een optimaal eindresultaat betekent dit dus dat er ín het proces ruimte moet zijn voor koerswijzigingen wat betreft de layout, structuur, content, usability en techniek. Zo’n koerswijziging beïnvloedt ook andere aspecten in de ontwikkeling. De keuze om een hoofdmenu bijvoorbeeld alsnog onder te verdelen in meerdere submenu’s, heeft ook impact op de vormgeving, content en usability.

Daarom – en dat is heel belangrijk – moeten alle trajecten naast elkaar, door elkaar en achterstevoren kunnen lopen. We noemen dit het openbreken van het proces, of hacking the process. Verderop zul je zien dat WordPress zich uitermate goed leent voor deze open methodiek. Dat is een afwijkende aanpak ten opzichte van bijv. Agile/Scrum, dat een proces wel in stukken hakt, maar alsnog vasthoudt aan een lineaire aanpak, waarbij fase na fase wordt gestart en afgesloten.

Maar hoe zorg je ervoor dat er tegelijkertijd gewerkt kan worden aan de invoer van content en aan de vormgeving? Hoe behoud je de flexibiliteit om de pagina- en menustructuur in de loop van het ontwikkelproces nog aan te passen? En hoe implementeer je een technische oplossing om enkel even na te gaan of dat is wat de klant wil, zonder dat dit zwaar op de begroting drukt?

Vermijd maatwerk

Het is dé valkuil voor veel ontwikkelaars: dingen op maat willen maken. Wij proberen maatwerk zoveel mogelijk te vermijden. Onze uitdaging is om de wensen van onze klanten te vertalen naar bestaande plugins en themes. Maatwerk leveren we alleen als het niet anders kan.

Een groot voordeel van WordPress is dat er ontzettend veel professionele plugins en themes kant en klaar beschikbaar zijn. Die kun je op een slimme manier uitproberen en weer weggooien. Waarom het wiel opnieuw uitvinden als er al wielen in allerlei soorten en maten te verkrijgen zijn? Zo bouw je op de kracht WordPress, in plaats van in WordPress.

Natuurlijk heeft het ook voordelen om aan maatwerk te doen. Je kunt code volledig naar eigen hand zetten, de opdracht van de klant tot op de komma nauwkeurig uitvoeren en je hebt iets gemaakt dat je in eigen beheer houdt, bijvoorbeeld een eigen plugin of een uniek thema. Maar het heeft ook nadelen; het is heel erg lastig om in te schatten hoeveel werk zoiets kost, je moet garantie en onderhoud blijven leveren, en je maakt iets dat je zelf waarschijnlijk slecht kunt hergebruiken (want het is helemaal afgestemd op de wensen van één specifieke klant). En dat terwijl 99% van de oplossingen vaak al kant en klaar op je ligt te wachten in één van de vele online WordPress repositories en marktplaatsen.

Kies een solide theme framework

Voor het grafisch ontwerp van je website geldt dat je met WordPress echt niet van de grond af aan hoeft te beginnen. Met de inzet van een child theme kun je de vormgeving van een bestaand theme goed naar eigen hand zetten. Een goed WordPress theme (zoals Enfold) kun je daarom eigenlijk meer zien als een grid / framework dan als een vastgetimmerde layout waar je niets meer aan kunt doen. Je bouwt eigenlijk wireframes die gelijk te vullen zijn met content en waarbij je meteen in de context van de gehele website kunt zien of ze goed overkomen.

Natuurlijk is het wel van belang dat je het juiste theme kiest. Waar moet je zoal op letten?

• Sluit de vormgeving aan bij de wensen van je klant? Hoe minder je hoeft te sleutelen aan de layout, hoe efficiënter je proces.
• Hoe staat het theme er technisch voor? Geloof het of niet, maar er zijn nog steeds themes te koop die niet responsive zijn. Let daar dus op, maar controleer ook of het theme alle browsers ondersteunt die voor jou van belang zijn.
• Wordt het theme goed onderhouden, komen er regelmatig updates uit en geeft de ontwikkelaar goede support? Dit zijn allemaal signalen aan de hand waarvan je kunt inschatten of je de komende jaren nog plezier van het theme zult hebben, of dat de levensduur al op z’n einde is.
• Staar je niet blind op de grote hoeveelheid mogelijkheden die sommige themes bieden. Veel beter is het om je af te vragen welke features je écht nodig hebt. Voor veel websites geldt dat je bijna alle pagina’s kunt opmaken met een mooie header, tekst, afbeeldingen en een sterke call-to-action. Allerlei andere features – zoals parallax backgrounds, sliders, masonry galleries, etc. – zijn wellicht leuke hebbedingetjes, maar ze worden in de praktijk zelden ingezet voor het doel van de website.
• Hoe scoort het theme qua performance? Sommige themes zien er prachtig uit, maar wegen door hun opzet zwaar op de laadtijd van je website.

Geef content meer prioriteit dan design

Het proces van grafisch ontwerp en de invoer van content dient gelijk met elkaar op te trekken. In de praktijk ontstaat echter de neiging om de aandacht aan grafisch ontwerp naar voren te trekken, en om het genereren van content uit te stellen. Dat is goed om te weten, want dat betekent dat je tegen die neiging in mag gaan; daag je klant voortdurend uit om met content aan de slag te gaan en geef het grafisch ontwerp pas prioriteit richting het einde van het ontwikkelproces.

Het mooie van WordPress is dat je met de klant vanaf het begin al aan de slag kunt met de content. Content is bovendien meer dan tekst alleen: goede foto’s zijn minstens zo belangrijk. Vaak is dat dan ook het eerste huiswerk dat we onze klant geven: huur een goede fotograaf in en geef die fotograaf een goede briefing. Naast foto’s kunnen ook video’s een enorme toevoeging zijn.

Wanneer een tekst eenmaal staat in een website, komt het toch heel anders over dan de eerste schets in een Word-document. Een gevaar is bijvoorbeeld dat teksten al snel veel te lang en wollig geschreven zijn. En dat terwijl online teksten juist concreet en gericht op de zoeker mogen zijn.

Wij hebben de beste ervaring met het invoeren van content wanneer dit met de klant erbij gebeurt. Ga naast elkaar zitten en loop pagina na pagina door. Door er samen naar te kijken kom je al heel snel tot een stramien dat goed te dupliceren is voor elke andere pagina.

Een voorbeeld van een vast stramien kan zijn: Altijd openen met een grote titel en een korte tagline. Daarna een foto met drie uitgelichte kenmerken. Vervolgens in twee alinea’s de uitleg, met in de tekst belangrijke zoekwoorden verwerkt. En onderaan een duidelijke call to action met een knop naar bijv. de contactpagina.

Houd het simpel

Met WordPress kan alles: met tienduizenden plugins en themes binnen handbereik is bijna elke wens van je klant te realiseren zonder zelf een regel code te programmeren. Voor je het weet heb je tientallen plugins geïnstalleerd op je WordPress website. Omdat alle plugins op elkaar ingrijpen zijn de gevolgen bij een grote update niet meer te overzien. Gebruik daarom heel selectief plugins. Doe hetzelfde met minder hulpmiddelen.

Hoe krijg je je klanten mee in deze visie? Een belangrijk aspect is je vermogen het ontwikkelproces de juiste richting op te sturen. Veel WordPress professionals gaan in relatie tot hun klant in een uitvoerende rol zitten: ‘U vraagt, wij draaien’. Je sturende rol is echter minstens zo belangrijk, omdat je dan bij kan dragen aan een efficiënt ontwikkelproces waarin het doel voor ogen wordt gehouden. Dat helpt bij het nemen van slimme beslissingen. Op verschillende momenten in het ontwikkelproces kun je jezelf profileren in die rol:

• Doelen bepalen
  Bespreek met je opdrachtgever niet de wensen voor de website, maar de doelen. Denk vervolgens na welke betrouwbare plugins en themes helpen om die doelen te bereiken. Met die tools in je achterhoofd stel je aan je klant de werkwijze voor die bijdraagt aan het bereiken van de doelen.
• Vraag altijd door
  Op verschillende momenten vraagt je klant ‘kan dit misschien ook …?’. En het antwoord in WordPress-land is bijna altijd ‘ja’, want bijna alles kan. Maar dat iets kan betekent niet dat het nuttig is. Vraag daarom door op zo’n moment: ‘Welk doel dient deze functionaliteit?’, ‘Is dit een primair doel?’ en ‘Is hetzelfde doel op een eenvoudigere manier te bereiken?’.

Als je je klant mee kunt nemen in het idee dat het bereiken van de doelen belangrijker is dan hoe je klant iets in gedachten heeft, dan kun je WordPress uitermate efficiënt inzetten. Zo kom je mogelijk tot de conclusie dat een ingewikkelde wens voor de website misschien wel leuk is, maar absoluut niet bijdraagt aan betere conversie. Lees bijvoorbeeld hoe we zo bijna de helft van de plugins hebben verwijderd tijdens de optimalisatie van een meertalige WordPress webshop, zonder negatieve beïnvloeding van de verkoopcijfers.

Ontwikkel duurzaam

Natuurlijk ontkom je er niet altijd aan om maatwerk te leveren. Maar maatwerk dát we doen, doen we duurzaam! Tijdens de ontwikkeling van WordPress websites houden we er bijvoorbeeld al rekening mee dat we de core, alle plugins en het theme in de toekomst kunnen blijven updaten (lees ook welke tools we gebruiken voor WordPress onderhoud & beheer). Dit betekent dat we nu al slimme keuzes maken als het gaat om maatwerk, want als we een gedrocht opleveren dat uit elkaar valt zodra iemand op ‘update’ klikt, snijden we onszelf in de vingers. Waar kun je zoal aan denken:

• Child theme
  Wijzigingen aan de layout doen we nooit in het theme zelf, maar brengen we onder in het child theme. Zo blijft het thema te updaten. Het maakt ons ook kritisch over de wijzigingen die we doen; te veel afwijken van de thema-basis kan in de toekomst voor problemen zorgen.
• Plugins
  Sleutelen aan bestaande plugins is uit den boze. Mocht je het verloop van een plugin willen wijzigen, dan hebben de betere ontwikkelaars bijna altijd support voor hooks ingebouwd, waardoor je buiten de plugin invloed kunt uitoefenen op bepaalde processen in de plugin. Zeker de grotere plugins, zoals Yoast SEO, WooCommerce, WPML, Advanced Custom Fields, etc. bieden zeer uitgebreide ondersteuning voor hooks. Het project hookr.io probeert om alle beschikbare WordPress hooks te documenteren. Zijn hooks nog helemaal nieuw voor je? Maak jezelf dan wegwijs door eerst het verschil tussen actions en filters te begrijpen.
• Core
  Voor de WordPress core geldt hetzelfde als voor plugins: niet aanzitten! Gebruik hooks waar nodig en maak gebruik van de vele API’s die inmiddels voor de core beschikbaar zijn. Maak, om te bouwen op WordPress bijvoorbeeld gebruik van $wpdb, in plaats van direct de database aan te spreken. En gebruik de Options API, in plaats van zelf een settings-pagina te knutselen.

Wees gestructureerd én flexibel

Eén van onze grootste technische uitdagingen is om de balans te houden tussen ‘gestructureerd teamwerk’ en ‘snel kunnen schakelen’. Gestructureerd teamwerk vraagt om planning, support tickets, versiebeheer, acceptatie-omgevingen en sprints. ‘Snel kunnen schakelen’ betekent dat je een klant aan de telefoon hebt en je tijdens het gesprek al de wijziging aan een pagina of CSS-file hebt gedaan.

De kracht van WordPress is dat je snel kunt schakelen. Dit verhoogt je reactiesnelheid, maar maakt het soms lastiger om kwaliteit te waarborgen. Gestructureerd teamwerk verhoogt de kwaliteit en het overzicht, maar vertraagt juist weer je reactiesnelheid. Een juiste balans is dus erg belangrijk! Verschillende technieken helpen ons om die balans te behouden.

• LESS
  Wijzigingen aan stylesheets proberen we onder te brengen in een LESS-bestand. LESS is een CSS-preprocessor die je helpt om veel CSS op een efficiëntere en overzichtelijkere manier op te schrijven. Het LESS-bestand wordt gecompileerd naar een CSS-bestand dat je kunt gebruiken in je child theme. Een goed (en nog populairder) alternatief van LESS is SASS, al staat LESS bekend om de betere documentatie voor beginners.
• Git
  Git is heel krachtig voor versiebeheer van je code, maar werkt het ook goed met WordPress samen? Het versiebeheer van complete WordPress websites heeft in elk geval heel wat haken en ogen, alleen al omdat een database zich lastig in commits laat opsplitsen (de startup VersionPress doet hier trouwens wel een dappere poging toe). Wel gebruiken we Git als plugin- en theme-repository. Door de update procedure voor eigen plugins en themes iets aan te passen, wordt er niet alleen naar updates gezocht op de WordPress repository, maar ook op onze eigen repository.
• wp-admin
  Je zou het bijna vergeten, maar werken met WordPress is een hele krachtige manier om snelle wijzigingen te kunnen doen. Titel aanpassen? Zo gedaan. Afbeelding van links naar rechts, of toch maar vervangen? In een handomdraai. We kunnen de gevallen al lang niet meer op één hand tellen dat we een klant dankzij de wp-admin al konden helpen terwijl we ze nog aan de lijn hadden.
• FTP
  Via FTP kun je heel snel een kleine wijziging doen aan een bestand. Het werken met FTP is ook een typisch geval van ‘snel kunnen schakelen’, omdat je wijziging meteen live staat. Het kan – net als werken via de wp-admin – helpen om een klant snel te helpen. Wel is het belangrijk om wijzigingen goed te voorzien van commentaar, of om de bestanden daarna alsnog in versiebeheer onder te brengen, mocht dat gebruikt worden. Wanneer we merken dat de vraag – en dus het risico – van de klant te groot is, dan gebruiken we liever de staging-methode (zie hieronder).
• Staging
  Wanneer je aan een bestaande website werkt, is het altijd verstandig om een staging-omgeving te hebben. Hosting partijen zoals WpEngine bieden de mogelijkheid om een complete kopie van je website te maken met één klik. Zo kun je veilig werken zonder een live website onderuit te halen. Wanneer je klaar bent zet je de staging omgeving terug naar de live site. Let er wel op dat niemand wijzigingen doet aan de live site terwijl jij op staging bezig bent, en dat je de database-opslag van tussentijdse formulier-inzendingen in de live website mogelijk kwijt bent.
• Online vs. lokaal ontwikkelen
  Om de klant continu mee te laten kijken kiezen we er voor om te ontwikkelen op een online webserver (zie ook ons blog over goede WordPress hosting). Dat bevordert het teamwerk ook. Maar als je in je eentje ontwikkelt, of als je voor een specifieke opdracht diep in de code moet duiken, dan kan het prettiger zijn om lokaal te werken. De meest bekende lokale webserver is waarschijnlijk XAMPP, maar je kunt ook kiezen voor een gevirtualiseerde webserver met Vagrant (met VVV) of Wocker. Het voordeel daarvan is dat je de configuratie van je lokale omgeving gelijk kunt houden aan die van je uiteindelijke webserver. Er zijn zelfs al standaard omgevingen te downloaden zoals Mercury voor WpEngine.

Ben je op zoek naar meer plugins en tools die aansluiten bij bovenstaande technieken? Lees ons artikel met tips en tools voor WordPress professionals.

Tot slot

In dit artikel hebben we onze werkwijze besproken voor de ontwikkeling van WordPress websites. De twee belangrijke uitgangspunten zijn daarbij dat WordPress de mogelijkheid biedt om niet vast te houden aan traditionele ontwikkelprocessen, en dat je jezelf altijd moet blijven herinneren aan de vuistregel: keep it simple. Ben je op zoek naar ontwikkeltools die aansluiten op deze werkwijze? Lees dan ook ons artikel over tools voor WordPress professionals.

Reageer!

Pak jij de ontwikkeling van een WordPress website anders aan? Wat zijn de voor- en nadelen daarvan? Laat het ons weten in een reactie!