Van uitdaging naar oplossing

Al bijna 3 jaar als Front-end Developer ben ik verantwoordelijk voor de gebruikersinterface of in de Engelse term GUI (Graphical User Interface, uitgesproken als “goewie”). Ik heb gemerkt dat bijvoorbeeld het verplaatsen of veranderen van een knop veel impact kan hebben. Zelfs meer impact dan het veranderen van een volledig scherm. In deze blog vertel ik hoe een dergelijke wijziging tot stand komt en hoe het uiteindelijk geïmplementeerd wordt in Faster Forward Elements.

Faster Forward Elements is een software pakket dat al ruim 10 jaar bestaat. Dat betekent vanzelf dat er al meer dan 10 jaar aan ontwikkeld is. Natuurlijk heeft de techniek niet stil gestaan en zijn er nieuwe mogelijkheden geboren in deze periode. Denk alleen maar aan de vlucht die de internetbrowsers hebben genomen. “Vroeger” werkten we nog met Netscape Navigator en Internet Explorer 4, nu hebben we keuze uit Chrome, Firefox, Internet Explorer, Edge en Safari. Met deze moderne browsers zijn er nieuwe (technische) mogelijkheden gekomen die het gebruik van Elements vereenvoudigen.

Sommige van deze nieuwe technische mogelijkheden merkt een eindgebruiker niet eens. Dat zijn aanpassingen in de “motor” van Elements, waardoor het betrouwbaarder en beter zijn werk doet. Wat de gebruiker echt merkt, zijn wijzigingen in de GUI.

Begrijpen – Uitzoeken wat er aan de hand is

Naast het moderniseren van de GUI heeft een grafische wijziging vaak een ander doel. Een scherm moet voor een gebruiker logisch en vriendelijk aanvoelen. Wanneer een scherm niet duidelijk is, heeft het gebruik ervan een grote leercurve: het is niet intuïtief.

Een GUI die niet intuïtief is nodigt niet uit tot gebruik, daarnaast vergeet men vaak de werking ervan. Het is aan mij dan de taak om uit te zoeken waar het probleem ligt. Het in kaart brengen van een beoogd proces kan daarbij helpen. Door zaken visueel in kaart te brengen, maak je inzichtelijk waar een gebruiker tegen aanloopt.

In de foto hierboven zie je het resultaat van het uitzoeken van een bepaald proces binnen Elements. Nadat ik een proces heb besproken met de betrokken partijen, maak ik op grote flip-overvellen de verschillende stappen die een gebruiker moet doorlopen inzichtelijk. Met een marker heb ik vervolgens aangegeven waar een gebruiker iets moet invullen en hoe het klikpad door Elements is. Het resultaat bespreek ik vervolgens weer met de betrokken partijen en op basis van dat laatste gesprek begin ik aan een ontwerp.

Ontwerpen & Realiseren – Een passende oplossing bedenken

Ontwerp is in die zin een erg breed woord, omdat men meestal direct aan een grafische oplossing denkt bij ontwerp. Niets is (in dit geval) minder waar, de echt grafische oplossing is pas de laatste stap in het ontwerpproces.

Eerst ga ik na wat het begin- en eindpunt moet zijn van een bepaald proces. Een gebruiker zet een actie met een doel, bijvoorbeeld: “Ik klik op verwijderen, omdat ik dit bestand wil verwijderen.” Deze actie lijkt zeer eenvoudig, maar roept al verschillende vragen bij mij op:

• Is het een bestaande functionaliteit?
• Moet het bestand direct verwijderd worden, of wordt er eerst om bevestiging gevraagd?
• Gaan we een button gebruiken of een tekst?
• Waar wordt deze actie ingezet?
• Wat is de stap na deze actie?

Deze vragen hebben in dit geval een hoge “ja duh!”-factor, maar bij ingewikkelde processen zijn ze van groot belang. Met de antwoorden op deze vragen is het mogelijk om een processchema te maken. Deze processtappen zie je hieronder weergegeven.

Afhankelijk van het proces maak ik ook een analyse van de gegevens die per scherm ingevoerd moeten worden.

Op basis van deze processtappen en data-analyse maak ik vervolgens een schets van een mogelijke oplossing (of in technische termen wireframe). Voorheen deed ik dat met papier maar nu volledig digitaal.

Door het volledig digitaal te schetsen is het relatief eenvoudig om een werkend prototype te maken, dat al matcht met de vormgeving van Elements. De stap naar werkbare test is een stuk kleiner hierdoor. De functionaliteit en vormgeving van dit prototype bespreek ik met de betrokken partijen. Voor nieuwe functionaliteiten doen we dat vooral intern, maar bijvoorbeeld met de aanpassingen op de e-mailclient in Elements hebben we een gebruikerspanel geraadpleegd.

Wanneer de betrokken partijen en ik het eens zijn met ontwerp en de werking, maak ik een zogenaamd proof-of-concept in de daadwerkelijke Elements-code. Dat wil zeggen dat ik van de afbeeldingen een werkende versie ga maken in Elements.

Uiteindelijk bepaal ik samen met de andere developers of de code goed opgezet is en akkoord is om in een release opgenomen te worden.

Testen – Aan de eisen voldoen

Eenmaal opgenomen in de release krijgt de (nieuwe) functionaliteit dezelfde behandeling als alle andere punten in de release. De code wordt opgenomen in de broncode van Elements. Daarna is een van de developers verantwoordelijk voor het controleren van de code. Met deze controle garanderen we de kwaliteit van de code.

Uiteindelijk komt de functionaliteit bij onze tester, die de werking doorloopt en controleert of het aan de wensen van de verschillende partijen voldoet.

Wanneer alle partijen tevreden zijn wordt de release uitgevoerd en kan de eindgebruiker voor het eerst de nieuwe functionaliteit proberen. Dat is voor mij altijd een spannend moment!

Releasen – De eindgebruiker gaat ermee aan de gang

De eerste uren na een release waarbij veel grafische punten of een nieuwe GUI is opgenomen heb ik nauw contact met onze support afdeling. Mochten er ondanks het vele testen en controleren toch nog problemen zijn, wil ik dat zo snel mogelijk opgelost hebben natuurlijk.

Soms zijn er klachten, omdat een gebruiker moet wennen aan een nieuwe vormgeving. Ik maak tijdens de eerste uren verschil tussen acute problemen en smaakverschillen. Acute problemen ga ik direct oplossen. Met de smaakverschillen ga ik pas iets doen wanneer veel klanten hetzelfde signaleren. Dan betekent het dat ik echt een verkeerde keuze gemaakt heb. Ik ga dan opzoek naar een beter passende oplossing en probeer die zo snel mogelijk live te krijgen.

Evalueren – De meningen zijn gegeven

Na de release ga ik met de verschillende partijen bespreken of het proces goed verlopen is en waar ik bij een volgend traject beter op moeten letten. Zodat iedere keer wanneer we een dergelijk proces doorlopen het steeds gestroomlijnder gaat.

Tot slot

Op deze manier nemen we een (nieuwe) functionaliteit onderhanden en zorgen ervoor dat deze een aanvulling heeft op het dagelijks gebruik van Elements. Het venijn zit hem soms in de details, maar dat maakt het werken aan een GUI ook zo uitdagend! Het is heel leuk om van een schematische weergave te werken naar een werkende functionaliteit in Elements en als onze klanten er uiteindelijk veel gebruik van maken, dan is wat mij betreft het doel bereikt!