Maatwerk software

Als de wifi uitvalt, begint de echte test pas

Waarom software ook moet kloppen op een nat sportpark, in een loods of aan het begin van een cacaoketen

Kay van Soest Kay van Soest
4 min. leestijd

Op kantoor werkte de app perfect. Snelle wifi, opgeladen apparaten en een developer binnen roepafstand. Toen namen we hem mee naar de plek waarvoor hij bedoeld was.

Daar stond een vrijwilliger op een nat sportpark, met koude vingers, een halflege iPad en een verbinding die precies wegviel toen de volgende wedstrijd moest worden ingepland.

Welkom in de echte wereld.

Internet is geen natuurwet

Veel bedrijfssoftware wordt ontworpen alsof een stabiele verbinding altijd aanwezig is. Dat is begrijpelijk: tijdens ontwikkeling en testen is dat meestal zo. Maar gebruikers werken ook in magazijnen met dikke muren, op bouwplaatsen, tijdens drukke evenementen, onderweg en in gebieden waar mobiel internet niet vanzelfsprekend is.

Kijk bijvoorbeeld naar de cacaoketen van Tony’s Chocolonely. Tony’s Open Chain werkt met coöperaties in onder meer Ghana en registreert de herkomst en beweging van cacao via BeanTracker. De openbare informatie zegt niet dat die specifieke software offline werkt. Maar de keten maakt de ontwerpvraag wel glashelder: wat moet software doen wanneer belangrijke gegevens ontstaan op een plek waar je niet blind op wifi kunt vertrouwen?

“Probeer het later opnieuw” is dan geen oplossing. De vrachtwagen, speler of medewerker wacht niet tot het bereik terug is.

Een app die alleen onder ideale omstandigheden werkt, is een demo. Geen product.

Offline is meer dan gegevens bewaren

Een app offline laten openen is niet zo moeilijk. De echte uitdaging begint zodra mensen iets mogen veranderen.

Stel dat een medewerker van een coöperatie een levering registreert terwijl er geen verbinding is. De app bewaart het gewicht, het tijdstip en de leverancier lokaal. Even later past een collega op een ander apparaat dezelfde levering aan. Wanneer beide apparaten weer online komen, bestaan er twee versies van de waarheid.

Welke wint?

De nieuwste? Dat kan verkeerd zijn als één apparaat een onjuiste klok heeft. De eerste? Dan verdwijnt mogelijk een bewuste correctie. Beide bewaren? Dan staat dezelfde levering dubbel in de keten.

Offline-first software heeft daarom regels nodig voor conflicten, niet alleen een lokale database.

De gebruiker moet weten waar hij aan toe is

Slechte offline software doet alsof alles gelukt is en meldt uren later dat synchronisatie onmogelijk bleek. De gebruiker is dan allang met iets anders bezig en weet niet meer welke invoer gecontroleerd moet worden.

Goede software maakt de status zichtbaar:

  • deze actie staat veilig op het apparaat;
  • deze gegevens zijn nog niet verzonden;
  • deze wijziging botst met informatie van een collega;
  • deze actie vraagt aandacht zodra er weer verbinding is;
  • en dit is de laatste keer dat alle gegevens volledig zijn bijgewerkt.

Dat hoeft niet technisch te voelen. Een simpel icoon, duidelijke kleur en menselijke tekst kunnen genoeg zijn. De techniek mag ingewikkeld zijn. De ervaring niet.

Offline-first betekent keuzes maken

Niet iedere functie hoeft offline beschikbaar te zijn. Een uitslag registreren op een sportpark kan essentieel zijn. Een uitgebreid rapport exporteren kan wachten. Een magazijnmedewerker moet een artikel kunnen scannen, maar hoeft misschien niet het complete klantdossier te wijzigen.

Bij Byte Me bepalen we daarom per handeling:

  • moet dit zonder verbinding kunnen?
  • welke gegevens zijn daarvoor lokaal nodig?
  • hoe gevoelig zijn die gegevens als een apparaat kwijtraakt?
  • wat gebeurt er bij conflicten?
  • hoeveel tijd mag tussen invoer en centrale verwerking zitten?

Offline-first is geen vinkje in de technische architectuur. Het is een reeks productbeslissingen.

Test waar het pijn doet

Een offline scenario test je niet door in het kantoor de wifi één minuut uit te zetten. Je test met een apparaat dat uren geen bereik heeft. Met twee gebruikers die hetzelfde aanpassen. Met een batterij die uitvalt tijdens opslag. Met een synchronisatie die halverwege stopt.

En vooral: met de mensen die het onder die omstandigheden moeten gebruiken.

Hoe de praktijk op een sportpark de software bepaalt, lees je in ons verhaal over Match Me op het ICGT-toernooi.

Wij bouwen software graag voor de plek waar zij waarde moet leveren. Niet alleen voor de vergaderruimte waarin zij wordt gepresenteerd. Soms betekent dat een fel buitenscherm op een sportpark. Soms een interface met extra grote knoppen. En soms betekent het dat gegevens lokaal veilig doorwerken tot het internet terugkomt.

Want de echte kwaliteitsvraag is niet hoe snel een app reageert op kantoor.

De vraag is wat er overblijft wanneer de wifi verdwijnt.

Veelgestelde vragen

Wat betekent offline-first software?

Bij offline-first software ontwerp je essentiële handelingen zo dat gebruikers ook zonder verbinding kunnen doorwerken. Daarbij horen lokale opslag, zichtbare synchronisatiestatussen en afspraken over het verwerken van wijzigingen zodra de verbinding terugkomt.

Wat gebeurt er als twee mensen offline dezelfde gegevens aanpassen?

Dan moet de software een conflict herkennen en volgens vooraf gekozen regels afhandelen. Automatisch de nieuwste wijziging kiezen is niet altijd betrouwbaar. Soms is beoordeling door een medewerker nodig.

Moet iedere functie van een app offline werken?

Nee. Bepaal welke handelingen op locatie noodzakelijk zijn en welke kunnen wachten. Test die keuzes ook met langdurig verbindingsverlies, lege batterijen en synchronisatie die halverwege stopt.