Det är En paradox att många utvecklare som har stort intresse av design och underhållsvänliga applikationer ofta säger något i stil med:
”Vem som helst kan ta användargränssnittet, det går inte att ställa till så mycket skada där ändå.”
En del av paradoxen är att den största kodmängden, den fulaste koden och därmed också det största underhållsproblemet har en tendens att hamna just i användargränssnittet.
En annan del av paradoxen är att en applikations framgång till stor del beror av användarupplevelsen. Visst, ju bättre den kod/design som användargränssnittet konsumerar är, desto större är chansen att användargränssnittet också kan bli bra. Men det sker inte av sig självt. Tvärtom.
Kanske du känner igen något av följande exempel?
- Användargränssnittsrendering och logik har blandats i en enda soppa. När renderingen ska bytas så blir det mycket påtagligt att även logiken påverkas.
- I den stora applikationen har man med framgång delat upp logiken väl i olika delar, till exempel efter ändringstakt. Undantaget är användargränssnittet som är en enda stor monolit där det är mycket svårt att ändra de olika delarna separat.
- Efter mycket möda och stort besvär har man börjat dra stor nytta av automatiserad testning. Förutom för användargränssnittet, vilket ofta har stort behov av refaktorisering och därmed det skyddsnät som automatiska tester innebär.
- Bra design används för till exempel domänmodellen så att den med lite kod och rätt abstraktioner väl beskriver problemets lösning. Men användargränssnittet är gjort med ”brute force”, nästan helt utan abstraktioner.
De flesta utvecklare är tåliga, lite för tåliga faktiskt. Jag tycker inte vi bör acceptera det vi får från verktygsleverantörerna rakt upp och ner. Ofta är det snarare att betrakta som plattformar som man kan bygga specifika ramverk ovanpå.
Om man gör som leverantören föreslår får man ofta räkna med pratighet i koden och stora och svårunderhållna kodbaser. Oftast har leverantören inte ätit sin egen hundmat. Det är först när verktyget används i verkliga projekt som erfarenheten och kunskapen växer fram om vad som är bra eller dåligt – och hur det som är bra också används på ett bra sätt.
En indikation på problemet är att design för de flesta betyder ganska olika saker i till exempel domänmodellen och i användargränssnittet. Det är naturligtvis extremt nyttigt med god programvaruutvecklingsdesign även i användargränssnittet (och inte bara ”look-and-feel”-design)!
Användargränssnittet har alltid varit viktigt, men har ofta blivit styvmoderligt behandlat. I användargränssnittet finns ofta den största underhållsflaskhalsen. Nu och framöver kräver och förtjänar det området stort fokus.
En intressant ansats är ramverksorienterad användargränssnittsprogrammering. Det är allt annat än trivialt att utföra bra. Potentialen är enorm!
…om tunga teknikfrågor, varannan gång kopplade till systemutveckling och varannan till it-säkerhet. Varje månad kan du läsa Jimmy Nilsson, Tomas Djurling, Ola Bini och Anne-Marie Eklund Löwinder.