Opdrachtgevers raken altijd enthousiast en opgewonden van het idee dat alles straks met een druk op de knop geregeld is. Hun visie is gebaseerd op dat voornemen. Maar soms is dat niet optimaal. In zo’n geval loopt het raderwerkje in hun hoofd al snel volledig vast.

Met een druk op de knop

ITers automatiseren jouw functie weg waar je bij staat. Als opdrachtgever moet het lijken alsof er geen eind komt aan de mogelijkheden van automatiseren van hele ketens van bedrijfsprocessen. Je begint met het digitaal verwerken van de inkoopfactuur, maar als je de ITers hun gang laat gaan blijkt dat je je inkoopfacturen al digitaal kunt ontvangen. Nee, wacht! Je kunt het inkoopproces zèlf automatiseren op basis van de (te automatiseren) voorraadinformatie. En ga zo maar door…

Wat vroeger tijd, opleiding en een hoop papier kostte gaat nu sneller, goedkoper en is eigenlijk …best stoer! Al die grafiekjes op je scherm! Machtig spul, software. Alles geregeld met een druk op de knop.

De doe-wat-ik-wil-knop

Tijdens mijn informaticastudie volgde ik het college User Interfaces.

“De ideale user-interface heeft eigenlijk maar 1 knop, de doe-wat-ik-wil-knop.”

Professor Paul de Bra nam toen een gewichtige adempauze, keek met twinkelende oogjes het publiek in en liet ons zijn wijsheid op ons eigen tempo waarderen. Toen de meeste studenten begonnen te knikken in overeenstemming, ging hij verder

“Maar als het systeem dan zo precies weet wat ik wil, waarom moet ik dan nog op die knop drukken? Die knop is dan overbodig.”

Mijn ontwerp van de kinderversie.

Mijn scherm of jouw scherm?

Mijn klanten hebben meestal een toekomstvisie voor hun systemen rondom een soort gravitatiecentrum: hun eigen computerscherm.

En hoe kun je een ITprobleem binnen dat referentiekader anders oplossen dan door de toevoeging van een knop die je probleem oplost? Natuurlijk is “knop” wat te smal: het omvat ook dat extra rapport, de extra checkbox die je afvinkt, of dat nieuwe formulier (boven de knop) dat je online bezoekers laat invullen. Maar in wezen is dit hetzelfde: je lost het probleem op binnen een scherm, er zal iemand op klikken, in typen, of het zien op het scherm. Vervelend (invul-)werk schuift dan naar andermans scherm, leuke dingen zoals goedkeuring zijn welkom op ons eigen scherm. Software bouwen met de strategie van je one-night-stands. De hamvraag is: Wordt het op mijn scherm of op jouw scherm?

Headless killer-apps

Applicaties zonder scherm noemt men headless. Deze metafoor vindt zijn oorsprong in de opstelling van je desktopcomputer vroeger: de monitor (zo’n toeter) was altijd het rustende hoofd bovenop de schouders van je brommende computerdoos (desktop). Maar deze onthoofding is veel minder gruwelijk…

Het grootste deel van de ècht belangrijke, grootschalige applicaties zijn headless. Banktransactiesystemen, het WWW en eindeloze digitale infrastructuur zijn slimmer en nauwkeuriger juist doordat ze niet wachten tot iemand op het juiste moment op een knop duwt. Ze functioneren goed, zonder knop: je start ze op en ze blijven draaien tot de stroom uitgaat.
Vrij letterlijk zijn veel van deze headless applicaties zó belangrijk, dat ze killer apps genoemd mogen worden, als die stroom inderdaad uitvalt.

Extra scherm extra ballast

Minder risicovolle applicaties, zoals dat hippe, automatische teleconferentiesysteem, of dat evenzo gave projectplanningssyteem kunnen enorm baat hebben van zulke onthoofding. Door zo’n applicatie niet weer een nieuw, eigen gezicht (‘head’) te geven, maar het in de duisternis te laten werken, hoeven gebruikers niet ‘nog een nieuwe user interface’ te gebruiken, die niet werkt in hun InternetExplorer of waarvan ze de URL niet kunnen vinden.

Recentelijk ontwierp ik bijvoorbeeld een scherm waarop iemand een PDF kon downloaden, zoals de klant vroeg. De gebruiker zou de link naar dat scherm via e-mail ontvangen.
Uiteindelijk heb ik klant en gebruiker dat hele scherm bespaard: we hechten de PDF nu gewoon aan die mail!

Ik vergeet soms zelf voldoende afstand te nemen om op te kunnen merken dat je schermfuncties kunt weglaten. Maar vaker wìl de klant er gewoon niet aan: de radertjes in zijn/haar hoofd lopen vast als je het scherm uit het plan haalt.

Mashups in duisternis

Web2.0 was bracht ons Mashups: een nieuw schermpje door de koppeling van onafhankelijke, bestaande webapplicaties. Iedereen was er dolenthousiast over. Maar het koppelen is interessanter dan de mashups! Steeds meer bestaande applicaties faciliteren headless uitbreidingen. Zo kun je weer werk verzetten zònder dat iemand zich ermee bemoeit, in een soort digitale duisternis. Dàt is pas echt automatiseren: Zònder user interface werken systemen … vanzelf.

Jan, gebruiker

In softwaremaatwerkland lijdt Jan-op-de-werkvloer onder conventionele wijsheid van zijn manager, die een IT systeem laat bouwen voor Jans afdeling. Het meest storende gevolg vind ik de datamodelgedreven interactie waarmee Jan opgezadeld wordt.

Laat ik eerst uitleggen wat datamodellen zijn.

Datamodellen

Tegenwoordig slaan vrijwel alle zakelijke applicaties hun gegevens op in SQL databases. Het principe daarvan is niets meer dan een verzameling tabellen, bestaande uit kolommen met ruwe data (je geboortedatum, je naam, de productcode) en speciale kolommen met regelnummers uit andere,soortgelijke tabellen.

IT managers met een opleiding in de jaren 70/80 (of autodidact) hebben geleerd om databases te ‘modelleren‘. Dat is het zo handig mogelijk opdelen van bedrijfsgegevens in tabellen. Modelleren is een truucje: als je het doorhebt is het eigenlijk heel simpel.

De opdrachtspecificatie van maatwerk bestaat, omdat dat dat nu immers het domein is van voornoemde demografische groep, dan ook meestal vooral uit database-velden: de kolommen van de tabellen. Daar wordt lang en zwaarwichtig over gediscussieerd. Daar voelt men zich veilig en gezaghebbend bij. En dat vindt iedereen tenslotte prettig!

Datamodelgedreven interactie

De inhoud van de SQL tabellen zit diep verborgen onder de motorkap van de applicatie. Echter, door de grote nadruk die managers/klanten leggen op het opslagformaat (de kolommen en tabellen) zetten zij software-ontwikkelaars impliciet onder druk om, op het scherm, te tonen dat de applicatie inderdaad voldoet aan een datamodel.  Zo wordt elk scherm een afspiegeling van de tabelvorm van zijn onderliggende gegevens.  Daarom zien bijna alle schermen eruit als een Excel-blad: een schermvullende tabel.

De knoppen waarop je klikt en de invoervelden zijn later toegevoegd, volgens conventies. Het gevolg is dat de applicatie de acties wel uitvoert zoals gespecificeerd, maar op een hele saaie, inefficiënte en bovenal verwarrende manier. Immers, het conceptueel model van de interactie is gebaseerd op machine-efficiënte gegevensopslag, niet op efficiënt applicatiegebruik of een prettige ervaring. Of om het anders te zeggen: Het is een chassis zonder interieur, zonder pedalen en vooral zonder een stuurwiel. Geen wonder dat het oncomfortabel voelt.

Herken datamodelgedreven interactie

Hoe herken je nu datamodelgedreven interactie? Welnu, ten eerste natuurlijk aan de overdaad aan tabellen, vooral met veel kolommen die je nu niet nodig hebt: je moet dus turen naar welke kolom de gegevens bevat die jij zoekt voor je taak. Als het niet op het scherm past maken we de letters gewoon wat kleiner…

Maar er is nog een teken aan de wand: Bij het uitvoeren van je taak doorkruis je meerdere schermen, waarbij je op elk scherm een ander stukje informatie aan het systeem moet voeren.

Voorbeeld:

Je systeem registreert de teams van de voetbalvereniging. Het datamodel bewaart leden en teams gescheiden, elk in hun eigen tabel. Elk seizoen wijzigt de teamindeling en de klasse van elk team. Dat levert je veel werk op, want je moet

1. het bestaande team opzoeken (scherm 1) en dat “archiveren”
2. een nieuw team aanmaken van de juiste speelklasse(scherm 2) en dat “starten”
3. een teamlid opzoeken (scherm 3) op naam
4. het teamlid toevoegen aan het nieuwe team (scherm 4)
5. voor alle andere 10 spelers stap 3 en 4 herhalen (schermen 5..24)
6. voor alle andere 6 teams stap 1/tm 5 herhalen (schermen 25..144)

Geen wonder dat je daar tegenop ziet!

NB. Ik laat het aan u over zelf een slimmere, gecombineerde manier te bedenken zodat de taak in 1 of 2 schermen klaar is. Hint: teams veranderen relatief weinig.

Datamodellen zijn een ’solution’

De datamodellen in de specificatie zijn zelf een ’solution’: een IT oplossing op zoek naar een probleem. Het probleem van gegevensopslag speelt namelijk nog helemaal niet tijdens de eerste vergaderingen over een mogelijk nieuw IT systeem. De wereld is veranderd sinds de jaren ‘80: het datamodel is meestal onbelangrijk.

In plaats van te vergaderen over datamodellen zou de IT manager moeten praten over

1. welke acties de mensen op de werkvloer met de applicatie moeten uitvoeren en
2. hoe de daarbij benodigde informatie gecondenseerd en in de juiste context aan hen gepresenteerd wordt.

En als je iemand betrapt op het voornemen vooral tabellen te gebruiken, “lekker makkelijk, zoals iedereen gewend is, van Excel”, bedenk dan dat dat eigenlijk zonde is van duur maatwerk: dat kan vrijwel gratis met gespecialiseerde tools en zelfs – hoe kan het ook anders – met Excel zelf!

Het hoeft niet. Tegen een kleine investering irriteert u uw eigen webbezoeker/-klant niet meer. En het levert nog gigantische besparingen op ook.

Zet uw adres op de stippellijn

Het meest voorkomend gegeven dat ik invul op webformulieren is mijn e-mail adres. Grappig genoeg is dat dus ook meteen hetgeen dat ik het minst snel weggeef. En als ik het moet invullen vink ik vooral geconcentreerd de vinkjes “geen e-mail nieuwsbrief” aan. Maar dan komt de lol pas. Mijn postadres is ook een gewild informatie-item. Het kan meestal in het volgende vakje…

straat, huisnummer, postcode, woonplaats, toch?

Het adres bestaat in Nederland uit 4 onderdelen:

standaard adresinvoer

1. de straatnaam
2. het huisnummer, extra vakje voor de “toevoeging”
3. de postcode, meestal 2 vakjes, of 1 vakje waarbij de laatste letter net onleesbaar wordt
4. de woonplaats

Dus de standaard is dat ik 6 velden *verplicht invul om – schoorvoetend – mijn adres te geven. Telkens weer opnieuw. Het is geestdodende routine. En dan heet ik uit pure wanhoop al snel Donald Duck.

Soms wens ik  – gewoon voor de afwisseling – dat ik een postbus of een antwoordnummer tot mijn beschikking had, zodat 99% van de formulieren onbruikbaar zouden worden… Want er is minder aan een Nederlands adres, dan de “grote vier”.

fout! postcode en huisnummer

Afgezien van de telkens terugkerende ellende met het postcodeveld dat te klein is, of – vaker nog – te dom om te ’snappen’ dat ik met het menselijke “5612 WH” hetzelfde bedoel als “5612WH”, zonder spatie, wat schijnbaar de standaard is in computerland (of juist vice versa? Het is mij een raadsel), ziet adresformulier bouwend softwareland (waarde collega’s) een veel groter verbeterpunt over het hoofd: de postcode en huisnummer zijn je volledige adres:

1. de postcode, in 1 vakje inclusief letters: “5612 WH” en zonder protest ook “5612WH”
2. het huisnummer, in 1 vakje, dat eventuele toevoegingen negeert

Maak uw bezoekers blij en neem een (betaald) abonnement op een postcodetabel, er zijn vele aanbieders van. Ik tik mijn postcode en huisnummer en floeps! Mijn volledige adres staat ter controle op de site. Wat een heerlijk gevoel.

En contact met de aanbieder van zo’n tabel behoedt u meteen voor kopzorgen over Internationale adressen, want die ellende heb we nog niet eens aangeroerd. Het postcode + huisnummer concept werkt namelijk lang niet voor alle landen van de wereld. Een gespecialiseerde dataleverancier weet hoe het zit.

De bonus

Wilt u helemaal de blits maken en uw site-bezoeker een plezierig formulier bieden? Bouw het kreng dan niet zelf, maar hergebruik het beste formulier van een webservice, dat

• perfect omgaat met alle invoer-eigenaardigheden en
• minder Donald Ducks en Jan de Vriesen verwerkt, of ze eruit filtert
• netjes past in uw huisstijl en
• in alle denkbare talen vertaald is voor uw Internationale bezoeker.

Een kleine investering die zichzelf dubbel en dwars terugbetaalt in gewonnen merkimago en gebruiksgemak.

De jackpot: Standaard gegevensbronnen zijn te goedkoop om zelf te onderhouden

Postcodes zijn het topje van de ijsberg van gegevensbronnen die niemand in het dagelijks leven kan omzeilen. Naast het comfort, biedt een specialistisch gegevensleverancier informatie inzichtelijk en aantrekkelijk aan. Maar uw systeem wordt vooral beheersbaar: Onderschat niet de enorme administratieve last van het actualiseren van een persoonsbestand, voor welk doeleinde dan ook. Dat kun je tegenwoordig goedkoper uitbesteden dan zelf doen. Een klantenbestand van 1000 klanten actualiseren kan al voor €170,- Daar doe je het zelf niet voor.

De angst voor online gegevensbronnen is niet meer van deze tijd. Voor een prikkie zet u (of erger nog: uw concurrent) een leverancier in. Investeer dus niet àlles in het mooiste web-formulier, maar laat een restje om uw systemen te koppelen met zulke diensten.

"Beste ___, 

mijn commentaar in jouw tekst, in rood".

Dit is niet alleen psychologische kwetsing van de ontvanger, het is ook crimineel: u pleegt fraude. 

Bovenal is elke e-mail een communicatie tussen mensen. Het grootste probleem is dus dat uw “commentaar in rood” vijandigheid oproept bij degene met wie u e-mailt. Daarnaast is het inefficiënt en tenslotte een vorm van fraude.

Vijandigheid? Alleen de juf mag schrijven met rood!

Rood is een alarmkleur. Hij trekt niet alleen de aandacht (gevaar/bloed), maar het is ook de kleur waarmee strepen gezet worden door onschuldige ideeën. De psychologische gevolgen van de rode correctiepen worden zelfs erkend op basisscholen: steeds minder meesters en juffen gebruiken een rode correctiepen.

We geven het niet graag toe, maar iedere kenniswerker reageert als een stier bij rood commentaar op eigen werk. Wie denk je wel niet dat je bent!?

Inefficiënt. Wie zei nou wàt?

“Mijn commentaar in jouw tekst” werkt maar één keer. Wanneer je e-mail conversatie in een groep mensen gevoerd wordt, dwingt men elkaar telkens nieuwe kleuren toe te voegen om zich te onderscheiden. In de regenboog van (vaak vloekende) kleuren is het snel niet meer duidelijk wie nu wàt zei. Met name degene die abusievelijk een te lichte kleur kiest, zal genegeerd worden.

Schrijven in mijn woorden is fraude

Door te citeren en het citaat aan te passen pleeg je plagiaat en verdraait de woorden, zonder toestemming van de zender. E-mail is tegenwoordig een gerechtelijk bindend “schriftelijk” medium. Door de nieuwe status van e-mail is mutatie van zulke tekstfragmenten eigenlijk fraude: Een citaat behoort men in tact te laten en te voorzien van een bronvermelding. Omdat op Internet veel e-mails verstuurd worden, is een tijdstip eigenlijk ook nodig in die bronvermelding.

Hoe moet het wel?

Sinds jaar en dag is er internationaal geaccepteerde netiquette: gedragsregels op Internet, onder andere voor e-mail. Het komt op het volgende neer:

1. Spring in, citeer met een duidelijke markering  ( ‘>’ ) van elke citaatregel en vermeld duidelijk de bron.

2. Stap 1 gaat automatisch. Klaag bij de leverancier van uw e-mail software als u niet weet hoe 

3. Gebruik een e-mail programma van hogere kwaliteit indien stap 1 onmogelijk is met uw software

Nog een laatste vuistregel: Het gebruik van kleur in e-mail dient alleen decoratieve doeleinden. Het mag niet de inhoud van de boodschap beïnvloeden.

De goeie ouwe tijd

Toen computers een gebruiker voor het eerst in staat stelden om zonder hulp van een beheerder gegevens op te slaan, onderscheiden de makers van de ondersteunende software hun produkten door een knop te maken die die kracht representeerde: SAVE

opslaan in knopvorm

Het opslaan op schijf vierde hoogtij en al snel kwam de volgende doorbraak: keuze uit verschillende opslagmedia (harde schijf en floppy disk). De geboorte van “SAVE AS..” een ongemakkelijke mengelmoes van Hernoemen en Dupliceren.

Software die even dom doet als de hardware

Maar de tijden zijn veranderd. Bedrijfscomputers hebben eigenlijk nog maar 1 opslagmedium: het netwerk. Maar nog steeds zit iedereen de hele dag op SAVE te drukken, als Pavlov’s hond.

De software slaat namelijk je wijzigingen pas op als je hem daar apart opdracht toe geeft. Veel van uw collega’s zweren bij een vast ritme van elke 5 minuten op SAVE duwen. Dat de computer (hardware) pas iets opslaat als hij daartoe opdracht krijgt is vanzelfsprekend, maar waarom doet onze software net zo dom? Welke zinvolle keus maak ik nog als ik op SAVE druk? 

Het is een teken aan de wand dat kinderen op de middelbare school tijdens de informaticalessen het OPSLAAN wel snappen, maar het icoon ervoor (floppy disk) niet kunnen plaatsen. Het is een behoorlijk opgave om ergens een floppy disk vandaan te halen om ze uit te leggen wat dat is!

De transitie: ‘reservekopie’

De frustratie van gebruikers met verloren gegane documenten en -wijzigingen dwong softwareleveranciers naar dit probleem te kijken en ze kwamen met een tussenoplossing: het programma bewaart met een vast ritme een reservekopietje van uw werk. Dit is auto-save. Een lifesaver voor velen, maar nog steeds niet je-van-het: het slaat alleen de laatste versie op.

Toch was het goed dat de softwarebouwers SAVE niet meteen elimineerden: Gebruikers waren inmiddels gewend aan het SAVE concept, dus dat werd behouden. De wet van de remmende voorsprong aan het werk. Maar tijd schrijdt voort…

Wen er maar aan: save-version-while-you-type 

Steeds meer applicaties, zelfs die via het web, breken nu met SAVE: Alles wat je typt bewaart de software meteen, maar alle tussenliggende versies van je werk blijven beschikbaar. Met de mooiste software navigeer je zelfs door de tijd als een film: “the making of this document“. 

Wen er maar aan! Al zal dat makkelijk gaan hoor…

Ontwikkelaars zien er altijd stevig tegenop om dit te maken, maar het moet nu echt afgelopen zijn met die nodeloze knop. In een webapplicatie dient hij geen doel meer. Dit mag best wat meer kosten, nu nog. Maar let wel: Het laatste jaar om die reden aan te dragen is nu aangebroken.

Opslaan verdwijnt, delen verschijnt

De SAVE knop gaat verdwijnen, maar door al dat netwerken krijgen we er wel een knop voor in de plaats. We beslissen daarmee om ons werk te publiceren, te delen met anderen. En die knop druk je gewoon 1 keer in. Geen nerveus Pavlovgedrag daar.

Iedereen wil een inlogscherm, of niet?

Bijna elke klant met wie ik werk vraagt op een gegeven moment letterlijk om een inlogscherm. Ik reageer consequent met: “Ben je zo dol op inloggen dan? Geniet je van dat proces?” Meestal levert dit niks dan vertwijfelde gezichten op. 

Iedereen heeft juist een hekel aan al dat inloggen. Je moet wachtwoorden onthouden en de ideale login  is al vergeven aan een andere “Jan”. Maar zo werkt het toch nu eenmaal?

Niet per se. Er zijn alternatieven, maar laten we hier kijken naar het probleem zelf. Gebruikersnaam en wachtwoord zijn beveiliging. Zou je je niet eerst afvragen of je wat van waarde te beveiligen hebt? Niet alle informatie hoeft geheim te zijn.

Een inlogscherm als voordeur geeft de eerste indruk van de applicatie beroerd karma. Vaak is dat niet nodig en kun je gebruikers beschouwen als ‘gast’, totdat beveiliging noodzakelijk wordt. Gasten behandel je met respect en koester je. Neem een voorbeeld aan internetwinkels: je hoeft niet in te loggen om te kiezen uit  het aanbod en je mandje te vullen. Je logt pas in als je risico loopt om bestolen te worden van je creditcardgegevens.

Treindeuren die voor je neus sluiten

Maar het tegenovergestelde gaat ook mis.. Eerst een verhaaltje:

Als ik me door regen, hordes forenzen en een volle roltrap heb gered op weg naar mijn trein doet het veel erger pijn dat de deuren voor mijn neus sluiten voor ik instap, dan wanneer ik zie dat de trein wegrijdt vlak voor ik het station binnenloop. De opgelopen vertraging is in beide gevallen gelijk, maar de pijniging niet.

Weinig softwarebouwers houden rekening met dergelijke psychologische investeringsgevolgen: Ik moet bij MijnPostbank inloggen, doorklikken en mijn overschrijving invoeren – samen een goede 5 minuten werk – om pas bij het versturen ervan te horen dat “er momenteel geen overschrijvingen mogelijk zijn“. Hadden ze dat nou gezegd op de beginpagina!

Net zoals je sommige informatie niet hoeft te beveiligen en kunt wachten met het vrijgeven van de beveiligde informatie is het in andere gevallen juist fijn als je vanaf de eerste interactie met een systeem de kans hebt om de trein in de verte te zien vertrekken.

Mijn creditcardnummer heeft spaties

Persoonsgegevens zoals postcodes, creditcardnummers en telefoonnummers zijn vaak essentieel om het beoogde doel te realiseren. Als je ze niet invult kan de postbode je niet vinden, krijgt de winkel zijn geld niet of kan niemand je bellen. Dat zo’n invulveld verplicht is (met de uitstekende conventie van het * symbool om het te onderscheiden) snappen we wel.

Maar waarom kan ik de spaties in mijn creditcardnummer niet invoeren? Het staat toch zo op mijn kaart? En mijn telefoonnummer heeft een streepje! En mijn postcode heeft een spatie tussen de cijfers en het letterduo. En als ik een rond bedrag bedoel, schrijf ik “-” op de plek van de decimalen.

De irritante conventie is dat de applicatie ons niet toestaat om streepjes, spaties en andere tekens te gebruiken en ze terugspuwt in ons gezicht. Of ik me maar even wil aanpassen, want de “validatie is gefaald”. Niet alleen is dit onbeschoft en heeft het systeem ongelijk -mijn creditcard heeft spaties- maar er is vooral ook een (reëel) risico: namelijk dat een potentiele klant hierdoor wegloopt, omdat het haar allemaal te lang gaat duren.

Geen technische beperking!

Ik garandeer dat deze drie irritante conventies geen technische beperking zijn. Het is pure luiheid. Sommige programmeurs vinden het niet stoer om hieraan te werken, maar de meesten kijken er niet eens naar om. Laat je niet beetnemen: het kan best.