Waarom Microsoft een stijlboek nodig heeft

Wanneer ik artikelen schrijf over hoe ik denk dat softwareontwikkelaars nog wat bijles van Microsoft-developers kunnen gebruiken, komt dat vaak op gepeperde reacties te staan. Niet iedereen is het met me eens dat Microsoft een rolmodel is. Maar ook Microsoft kan nog wat leren wanneer je serieus nadenkt over de praktijk en processen van softwareontwikkeling.

Ik kom op dit punt omdat ik afgelopen week de vierde editie van het boek "Microsoft Manual of Style" op mijn bureau aantrof. De "Microsoft Manual of Style" is een stijlgids voor schrijvers. Het doel is om hiermee eenduidig te schrijven wanneer het aankomt op stijl en taalgebruik. Is het bijvoorbeeld 'e-mail' of schrijven we liever 'email', zoals de Amerikanen doen? Schrijf je USB in hoofdletters of kleine letters? En is een CD-ROM een 'disc' of een 'disk'? Je begrijpt wat ik bedoel.

Veel uitgevers maken intern gebruik van stijlboeken. De meeste tijdschriften en kranten hebben er een. Ook binnen ons concern IDG circuleren ze. Wat het stijlboek van Microsoft echter zo interessant maakt, is dat het van toepassing is op alle officiële communicatie. De doelgroep bestaat niet alleen uit schrijvers van handleidingen, artikelen en advertenties, maar ook uit ontwerpers en ontwikkelaars die werken aan de software van het bedrijf.

Niet alleen handig om jargon en ongepaste teksten te voorkomen

Waarom hebben softwareontwikkelaars een stijlboek nodig? Om meer redenen dan je op voorhand zou denken. Zo'n handleiding beslaat de typische redactionele aanbevelingen, zoals het gebruik van eenduidige stijl en terminologie, liever actieve vorm dan passieve vorm en het voorkomen van seksistisch taalgebruik en overmatig technisch jargon. Maar het bevat ook een wereld aan tips die unieke kansen bieden voor moderne vormen van softwareontwikkeling.

De crux van veel van het advies dat Microsoft geeft is dat de relatie van de eindgebruiker met de computersoftware een unieke is, en dat het daarom belangrijk is dat de taal van software gebruiksinterfaces (UI) daarop aansluit. "We hebben verantwoordelijkheden die verder gaan dan het produceren van geweldige software", legt de handleiding uit. "We denken na over hoe onze commentaren worden gelezen."

Veel van hoe eindgebruikers software ervaren wordt bepaald door de toon van de geschreven tekst in een gebruiksinterface. Microsoft adviseert ontwikkelaars om een toon aan te slaan die "beleefd, ondersteunend en bemoedigend" is en benadrukt wat eindgebruikers kunnen doen met de software, in plaats van de onmogelijkheden te benadrukken.

Lees de gebruiker niet de les

Tegelijkertijd mag de software niet belerend overkomen. Vertel de gebruiker niet hoe gemakkelijk, snel of leuk de software is; als een procedure in werkelijkheid lastig, traag en frusterend is, gaan je gebruikers zich groen en geel ergeren. Probeer niet grappig te zijn en doe geen aannames over de gedachten van je gebruikers - bijvoorbeeld dat je ze vertelt dat ze zich geen zorgen hoeven te maken. Ook moet je voorkomen dat je in de valkuil stapt van het in detail uitleggen van waar de software toe in staat is.

Misschien is het beste advies dat Microsoft geeft dat je in een vroeg stadium zou moeten beginnen met het schrijven van teksten voor de gebruiksinterface, omdat een vreemde UI tekst diepere problemen met de software kan aanduiden. Maak niet de vergissing van het vertrouwen op gedetailleerde user prompts en helpteksten die ontwerpfouten moeten verhullen.

Gezien de snelle uitbreiding van de wereldwijde markt voor software, is internationalisatie een van de grootste problemen wanneer het aankomt op UI-design. Voor veel ontwikkelaars betekent internationalisatie simpelweg het vertalen van de teksten binnen software in andere talen. Maar zoals Microsofts handleiding duidelijk aangeeft, moeten ontwikkelaars eerst nadenken over de verschillende internationale markten voordat ze halsoverkop aan het vertalen beginnen.

Kom snel tot je punt

Zo moeten UI-ontwerpers geschoold zijn in het schrijven van helder en beknopt Nederlands. Het schrijven van beknopte teksten is belangrijk voor de leesbaarheid, maar het maakt zinnen ook eenvoudiger te vertalen. Dit is voornamelijk van toepassing wanneer automatische vertalingen worden toegepast om snel meerdere markten te kunnen bedienen.

Wanneer je iets schrijft voor buitenlandse gebruikers, is dat net zo belangrijk als dat je dat doet in je eigen moedertaal. Vergeet daarom niet de culturele verschillen mee te nemen, zoals dat Australiërs kerst in de zomer vieren en niet in de winter. Ook kleuren hebben voor ieder land een andere politieke of religieuze betekenis.

Vooral lastig zijn de woorden die onderdeel uit zijn gaan maken van het standaard computerjargon. Zo spreekt men van een DMZ (Demilitarized Zone) wanneer het gaat over een subnetwerk dat bloot staat aan het publieke internet. Maar deze term gebruik je in door oorlogen geteisterde landen liever niet. Ook de relatie tussen USB- of IDE-apparatuur, waar met master/slave-constructies wordt gewerkt, kan gevoelig liggen.

'Hey bitch, druk op deze knop'

Soms zijn de adviezen die het stijlboek van Microsoft doet ronduit absurd. Zo zou je kunnen denken dat het voor de hand ligt dat ontwikkelaars zich niet bedienen van straattaal als 'hoer' of 'pimp', maar toch wordt dit expliciet in de handleiding vermeld.

Ook maakt de handleiding van Microsoft duidelijk dat de lijn van het bedrijf altijd gevolgd dient te worden. Zo mag een officieel artikel van Microsoft nooit de term 'blue screen' gebruiken om een crash aan te duiden. En Internet Explorer mag nooit afgekort worden tot enkel IE. Wanneer Microsoft spreekt over hackers, gaat het hierbij altijd om de kwaadwillenden, de 'black-hats'. "Schrijf nooit over een 'hack' als het over een oplossing voor een softwareprobleem gaat Schrijf nooit 'hacker' op wanneer je een amateurprogrammeur bedoelt."

Ook voor begeleidende teksten achter de schermen

Toch is zijn de adviezen die je in de "Microsoft Manual of Style" kunt terugvinden nuttig en behulpzaam voor iedere softwareontwikkelaar, of het nu gaat om een ZZP'er of een groot softwarebureau. De adviezen gaan niet alleen over de teksten die de gebruiker ziet, maar ook over commentaren die geschreven worden in SDK- en API-documentatie. En vergeet dit niet: onafhankelijke ontwikkelaars die Microsofts linguïstische adviezen tot zich hebben genomen, hebben een streepje voor op concurrenten die dat niet hebben gedaan.

Het grootste voordeel van dit boek is dat het programmeurs tot nadenken aanzet over de taal die gebruikt wordt bij softwareontwikkeling. Daar kan de hele industrie van leren. We leven immers in een informatie-economie. Hoe je informatie communiceert is minstens zo belangrijk als het verwerken ervan.