Verbeterde leesbaarheid van EULAs

| AE 1835 | Informatiemaatschappij | 45 reacties

eula-ridge-trail-bordje-sign-flickr-oregon-brandon.jpgAfgelopen weekend beklaagde Willem Kossen zich over de (on)leesbaarheid van de EULA. Nou erger ik me ook regelmatig aan rare passages, maar zijn insteek is toch net even anders:

Eula’s often contain a lot of legal jargon, which usually is gibberish to ordinary human beings. The question is, do they have to be this difficult to read?

Natuurlijk hoeft dat niet, dus waarom gebeurt het toch? Ik geloof er niets van dat juridische teksten moeilijk leesbaar moeten zijn. Mijn theorie daarover is dat mensen die EULAs schrijven geen feedback krijgen zoals ze dat bij ‘echte’ contracten wel krijgen. Als je een onbegrijpelijke exoneratie schrijft in een duur contract, zal de tegenpartij daar wat van zeggen en dan wordt het aangepast. Of op zijn minst verduidelijkt. Maar een EULA wordt door niemand beoordeeld voordat ‘ie online (of in het product) gaat, dus daar blijven de onbegrijpelijke items gewoon staan.

Willem wijst op een aantal formules waarmee de leesbaarheid van teksten automatisch berekend kan worden. Die gaan uit van de Flesch Reading Ease test voor leesbaarheid. Deze test is kort gezegd gebaseerd op het aantal woorden per zin en het aantal lettergrepen per woord. Op basis van een aantal taalafhankelijke constanten komt er dan een getal uit dat de leesbaarheid representeert.

Er zijn diverse tools die dit voor de Engelse taal doen, maar voor Nederlands kan ik er geen vinden. Ik vond wel de constanten voor Nederlands, zodat in ieder geval in theorie de leesbaarheid van een Nederlandse tekst berekend kan worden. En wel als volgt:

fleisch-bouma-formule.gif

De leesbaarheid G wordt vervolgens gegeven door deze tabel:

Leesbaarheid GStijlOvereenkomstige schoolopleiding
90 – 100zeer gemakkelijkgroep 6
80 – 90gemakkelijkgroep 7
70 – 80vrij gemakkelijkgroep 8
60 – 70standaardvbo
50 – 60vrij moeilijkMAVO, onderbouw HAVO/VWO
30 – 50moeilijkbovenbouw HAVO/VWO
0 – 30zeer moeilijkuniversiteit

Is er iemand met Perl- of andere relevante ervaring die deze formule in een script kan gooien en hieronder wil posten? Ik zit met name aan te hikken tegen hoe je een Nederlands woord in lettergrepen opsplitst, daar lijkt niet echt een standaardbibliotheek voor te zijn.

Arnoud<br/> Foto: Oregon Brandon, Flickr

Deel dit artikel

  1. In principe kan je alle woorden inclusief het aantal lettergrepen (het aantal ?’s) van http://woordenlijst.org/ scrapen en die dan in een database zetten. Vervolgens kan je daarna gewoon per woord een match zoeken in je database en alles bij elkaar optellen. Voeg er nog een crowdsourcingtooltje aan toe waarmee mensen woorden die niet in de database staan zelf kunnen toevoegen en er is weer een leuk tooltje op internet bij. Misschien waag ik wel een poging binnenkort :).

  2. Lijkt me een onzuiver criterium.

    Ik lees regelmatig teksten die geheel bestaan uit “woorden” met maar een lettergreep die totaal onleesbaar zijn. Overigens zitten er dan meestal ook geen hoofdletters en leestekens in, moet ik eerlijk toegeven. Dus het aantal zinnen wordt dan ??n. Maar gelukkig is het aantal woorden dan in de regel weer zo klein dat de (on)leesbaarheid er niet echt onder lijdt. ๐Ÿ˜‰

  3. De vraag is in hoeverre een je een exacte oplossing wilt? Ik denk dat een benadering voldoende is. Een oplossing als die van Blijbol komt dan dicht in de buurt. De enkele keer dat je woorden als koeienuier of zee?endeneieren in je tekst hebt is dan jammer, maar zal (denk ik) geen grote invloed hebben op de tekst als geheel. Daarnaast, hoe groter je tekst, hoe kleiner de invloed zal zijn (en hoe groter de kans dat er meer van dit soort woorden in je tekst zitten, maar dat even terzijde).

  4. van wikipedia: Lettergrepen bestaan uit een sonore en accentdragende kern of nucleus, die vaak maar niet altijd wordt voorafgegaan door een onset en gevolgd door een coda. Het begin van de lettergreep (de onset) en coda bestaan uit medeklinkers, de kern is een enkele klinker, tweeklank of hoog-sonore medeklinker. Volgens mij zou het te doen moeten zijn als je een lijst met letters op sonoriteit gesorteerd hebt.

  5. Leesbaarheid wordt door veel meer aspecten bepaald dan in deze formule zijn opgenomen. Het lijkt me daarom niet zo’n nuttig tijdverdrijf om dit te programmeren. Het kan zelfs een negatief gevolg hebben, namelijk dat mensen zich op de score gaan richten in plaats van de ontvanger.

    Zaken als interpunctie en “moeilijke” woorden (niet beperkt tot jargon) hebben een veel grotere impact op de leesbaarheid, en EULA’s zitten vol met woorden die je in een normaal gesprek niet snel tegenkomt.

  6. @Juerd: daar heb je natuurlijk gelijk in, maar ik denk dat het wel een aardige vuistregel is. Misschien is het ding nog uit te breiden met wat juridisch-specifieke zaken, zoals een zwarte lijst met verboden woorden (“exoneratie”(*), “desalniettegenstaande”, “deze” enzovoorts).

    (*) Juridisch voor “uitsluiting van aansprakelijkheid”. Ironisch genoeg is het jargon dus leesbaarder dan de gewone termen.

    En ik hoor net dat ik de twee constanten 77 en .93 heb omgewisseld. Implementatiedetail ๐Ÿ™‚

  7. Bedankt Chris! Dat is handig. De eerste drie regels zijn eenvoudig te implementeren denk ik, maar de vierde (“Kunnen we de lettergreep makkelijk uitspreken?”) wordt lastig. Hoewel ik me afvraag of die nodig is bij deze situatie, omdat het zo te zien niet in meer of minder lettergrepen resulteert maar alleen in andere plekken waar de scheiding valt.

    • ambtenaar amb-te-naar niet: am-bte-naar

    Wie verveelt zich en bouwt even een Perlscript? ๐Ÿ™‚

  8. @6: ook het woord koeienuier kan correct worden ge?nterpreteerd zonder woordenlijst. Neem de groep klinkers ‘oeie’. Als is geprogrammeerd dat ‘oei’ een samengestelde klinker is en ‘e’ ook, dan zullen er vanzelf twee lettergrepen geteld worden.

    Ik zal anders wel even kijken of ik er een scriptje van kan maken.

  9. Ok?, dat helpt. Ik heb nu de co?ffici?nten in orde (tenminste, als dit klopt: 206.84 – 0.93 * $aantalwoorden / $aantalzinnen – 77 * $aantallettergrepen / $aantalwoorden) en nu komen er normale resultaten uit. De score wordt nu ook omgezet in het opleidingsniveau volgens je tabel.

    Dit heb ik er alvast doorheengehaald:

    • Disclaimer/privacybeleid van mijn eigen website: 45
    • Licentie van deze blog (CC-BY-SA 2.5): 36
    • Algemene voorwaarden van Google AdSense: 33

    Werkt verslavend dit. ๐Ÿ˜› Overigens wel moeilijk om een goede score te halen. Met mijn eigen score heb ik eigenlijk nog valsgespeeld omdat er webadressen in staan waardoor het aantal zinnen te hoog wordt ingeschat. ๐Ÿ˜€

  10. Ik heb een heel simpele implementatie op pastebin gezet (code hier op Iusmentis posten wordt geblokkeerd). Iedere groep van opeenvolgende klinkers wordt als lettergreep geteld. Een zin eindigt op ‘.’, ‘?’ of ‘!’ gevolgd door een spatie. De lettergreeptelling gaat de mist in bij woorden als beoordelen en online, en ook klinkers met accenten worden niet herkend. Er valt dus nog wel wat aan te schaven, maar met de meeste teksten op deze webpagina werkt ’t script.

  11. Het groene boekje heeft een lijst met klinkers die een trema en/of een koppelteken krijgen waar het weglaten tot verwarring over de uitspraak kan leiden. Het complement daarvan zijn alle combinaties van klinkers die naast elkaar geplaatst altijd op een dubbele lettergreep wijzen.

    (Er zullen vast uitzonderingen op zijn: is een beamer iets dat beamt of iemand die beaamt?)

    De apostrof kan trouwens ook op een ontbrekende klinker wijzen (’s lands wijs en zo).

  12. Een programma maken die dit even analyseert zou niet moeilijk moeten zijn, maar zonder woordkennis is een dergelijk criterium onbetrouwbaar. Het programma hoeft niet de betekenis van de woorden te kennen, maar moet wel weten hoe ieder woord in correcte lettergrepen moet worden opgedeeld. Dit kan namelijk niet simpel op basis van klinkers en medeklinkers scheiden. Een woord als “eeneiig” is drie lettergrepen. En “ion” (geladen deeltje) is twee lettergrepen. En hoewel dit soort woorden niet erg vaak voorkomen, kan het wel een kleine afwijking veroorzaken waardoor een tekst moeilijker (of minder moeilijk) lijkt dan het is.

  13. Een aantal jaar terug schreef ik deze tool voor mijn vader gebaseerd op zijn onderzoek aan de Universiteit van Tilburg. Deze tool is eigenlijk alleen bruikbaar voor teksten van basisschoolniveau, maar geeft een idee van de complexiteit van het probleem van het inschatten van de moeilijkheid van teksten.

    Veel woorden hebben meerdere betekenissen (loop: ik loop, de loop van de rivier, de loop van een geweer, in de loop van de geschiedenis, etc.) en het bepalen van de achterliggende betekenis is essentieel om de moeilijkheid van de tekst als geheel te kunnen bepalen. Zonder hier rekening mee te houden kan je enkel een schatting maken van de moeilijkheidsgraad. Niet dat een schatting niet nuttig kan zijn, maar het lijkt me belangrijk te benadrukken wat de beperkingen van zo’n meting zijn.

    (De MLR van deze tekst is tussen de 9.53 en de 21.83. Indicatie benodigde woordvoorraad tussen de 9.53 x 1000 en de 21.83 x 1000 woorden)

  14. Normen als aantal lettergrepen per woord en aantal woorden per zin zeggen slechts in beperkte mate iets over leesbaarheid, wat mensen hiervoor al opgemerkt hebben. Van veel grotere invloed zijn de bekendheid met de woorden, de opbouw en zinsconstructies. Als je echter alleen maar naar droge cijfertjes gaat kijken ontstaat er een situatie waarin mensen op kunstmatige wijze de cijfertjes omlaag gaan brengen, bijvoorbeeld door zinnen op te breken terwijl dat niet hoort, wat alleen maar leidt tot minder leesbare teksten. Slecht plan dus.

    Het echte probleem is natuurlijk dat er geen feedback gegeven wordt. Overigens lijkt dit me niet alleen een taalkundig maar ook een juridisch probleem: waarom heeft alleen de opsteller wat in te brengen in zo’n “overeenkomst”? Hoor je er als gebruiker niet ook iets over te kunnen zeggen? Misschien moeten we EULA’s laten keuren door een soort organisatie, de consumentenbond of zo. Zij zouden op zijn minst de taalkundige kwaliteiten ervan kunnen toetsen, maar misschien tegelijkertijd ook de juridische.

  15. @Theezakje:

    Slecht plan dus.
    Maar… er is toch helemaal geen “plan”? Slechts een paar opmerkingen over hoe EULAs duidelijker zouden moeten zijn — en een formule die een indicatie voor leesbaarheid geeft. (En die, zoals meedere malen hierboven is opgemerkt, achteraf moet worden toegepast en geen doel op zich moet zijn.)

    Kan (onnodig) moeilijke taal een reden zijn om een contract/EULA, die wel correct is en op zich ook wel redelijk, ongeldig te laten verklaren?

  16. Hans, allemaal woorden met twee lettergrepen: pi-oen, pi-on, i-on, ki-osk, bi-os.

    Het echte probleem is natuurlijk dat er geen feedback gegeven wordt.

    Het echte probleem is dat het schrijven niet aan professionals wordt overgelaten, om twee redenen. In de eerste plaats vanwege de kosten, maar in de tweede plaats ook omdat de opdrachtgever denkt dat schrijven makkelijk is, dat het iets is wat elke idioot kan. (En iets wat elke idioot kan heeft de neiging te leiden tot producten die duidelijk door idioten in elkaar zijn gezet.)

    Moet een advocaat dan maar een copywriter inhuren? Waarom niet? Om het geld hoeft ‘ie het niet te laten. Laatst vroeg ik een advocaat wat zijn uurtarief was. Toen ik weer bijkwam… maar dat is voor een andere keer.

    Arnout gaf overigens niet aan waarom hij leesbaarheid wil kunnen meten, dus concluderen (of suggereren) dat hij deze maat wil gebruiken om leesbaardere EULA’s te produceren is wellicht wat voorbarig.

  17. Je kan in Microsoft Word inderdaad de leesbaarheid laten weergeven (of wat daar op lijkt). Alleen moet je dat vast instellen, en dat is minder… want nu krijg ik na elke spellingscontrole een venster met het resultaat ๐Ÿ˜ niet echt gebruiksvriendelijk als je het mij vraagt.

    “Omdat PHP nog harder zuigt en ik geen andere talen ken waarin je een beetje effici?nt dingen kunt bouwen om strings te manipuleren.” Je bedoeld zeker het UTF-8 probleem? ๐Ÿ™‚ Perl is een prima taal, maar een hel om te leren. En je kan toch prima PHP gebruiken, als het maar werkt ๐Ÿ˜‰

    Ik wil geen flamewar starten of iets maar, maar waarom dan perse Perl en niet C of iets ๐Ÿ™‚ dus vandaar.

  18. Volgens mij gaat dit in Nederland niet werken omdat steeds meer mensen niet weten hoe ze samenvoegingen moeten schrijven. Je ziet tegenwoordig overal “hotel eigenom”, “zwerf afval” en (jaja) “spatie gebruik”. Meer woorden, minder lettergrepen per woord en een tekst die daardoor echt niet eenvoudiger is.

  19. Ik was het eigenlijk alweer vergeten maar al een tijdje geleden kwam ik dit tegen. http://code.google.com/p/hyphenator/

    Als je woorden moet breken over verschillende regels krijg je soms vreemde afbrekingen als ‘afb-rekingen’, je kan een woord alleen afbreken op lettergreep. In het Engels worden deze afbrekingen Hyphens genoemd ๐Ÿ™‚ de Hyphenator heeft een grote collectie woorden met de juiste afbreking, en dus lettergrepen van een woord (niet alles overigens).

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS