Einfach nicht gewünscht

In sei­nem Arti­kel „Why Free Soft­ware has poor usa­bi­li­ty, and how to impro­ve it“ beschreibt Matthew Paul Tho­mas die Pro­ble­me, die freie Soft­ware mit dem The­ma Usa­bi­li­ty hat. War­um sind so vie­le freie Pro­gram­me so schwie­rig zu bedie­nen und was kann man dage­gen tun.

Eini­ge der von Tho­mas genann­ten Punk­te sind mir aktu­ell in Zusam­men­hang mit ver­schie­de­nen Open-Source-Pro­jek­ten aufgefallen:

Coding before design

Die meis­ten Open­So­ur­ce-Pro­jek­te wer­den im Kopf eines Pro­gram­mie­rers gebo­ren: Der hat ein Pro­blem und eine Idee, wie er es mit­tels Soft­ware lösen kann. Also baut er sich eine Lösung, die mit mög­lichst wenig Auf­wand sein Pro­blem löst. Und weil Pro­gram­mie­rer so welt­frem­de Men­schen sind, stellt er sein Tool der Welt nicht nur kos­ten­los, son­dern auch noch frei zur Ver­fü­gung. Und schon fängt der Ärger an…

Zu viele Köche

Ande­re grei­fen die Arbeit auf und rei­chen Ihre Ände­run­gen ein. Die sind dann oft nicht abgesprochen.

Zu wenig Designer

Gute, ehren­amt­li­che Desi­gner sind so rar, dass die meis­ten Pro­jek­te ohne einen aus­kom­men müs­sen. Wenig Pro­gram­mie­rer sind gleich­zei­tig gute Designer.

Den Großen folgen

Der Man­gel an Desi­gner führt im bes­ten Fall dazu, dass die Pro­gram­mie­rer ver­su­chen komm­zi­el­le Soft­ware in der Bedie­nung zu imi­tie­ren. Die ist aber oft kein gutes Vor­bild und die Pro­gram­mie­rer brin­gen sich damit um die Chan­ce bes­ser zu sein.

Release early, Release often

In der Open Source Sze­ne gilt das Mot­to: „ver­öf­fent­li­che früh und häu­fig“. Davon ver­spricht man sich eine sta­bi­le­re Ent­wick­lung, weil mit jedem Ver­si­ons­schritt nur klei­ne Ände­run­gen vor­ge­nom­men wer­den, die dann jeweils von den Benut­zern getes­tet wer­den können.

Das bringt aber auch das Pro­blem, dass frü­he Ent­schei­dun­gen für eine bestimm­te Art der Bedie­nung spä­ter schlecht geän­dert wer­den kann, weil die Benut­zer sich nicht umge­wöh­nen wol­len – egal wie kom­pli­ziert die Bedie­nung frü­her war. Da wer­den dann sogar abstru­se Bedie­nungs­kon­zep­te vehe­ment verteidigt.

Modulare Mittelmäßigkeit

Pro­gram­mie­rer ste­hen auf Modu­la­ri­tät und gera­de in Open Source Pro­jek­ten lohnt es sich, Tei­le unab­hän­gig von ein­an­der ent­wi­ckeln zu kön­nen. Meis­tens sit­zen die ver­schie­de­nen Frei­zeit­ent­wick­ler ja nicht im glei­chen Büro zur ein­fa­chen Absprache.

Dadurch sind die Kom­po­nen­ten aber oft auch nicht auf­ein­an­der abge­stimmt und es gibt kei­ne kon­sis­ten­te Bedienung.

Usability ist schwer zu messen

Jeder Pro­gram­mie­rer hat sei­ne eige­ne Vor­stel­lung davon, was ein­fach zu bedie­nen ist. Und weil natür­lich jeder Ent­wick­ler sei­ne eige­ne Soft­ware regel­mä­ßig benutzt, ist jeder selbst ein Power-User, dem die frü­hen Hür­den gar nicht mehr auffallen.

Kleine Fehler sind egal

Ent­wick­ler wol­len, dass ihre Soft­ware funk­tio­niert. Des­we­gen fürch­ten sie vor allem Feh­ler, die dafür sor­gen, dass ihre Soft­ware nicht funk­tio­niert. Das gilt dann als „Bug“ und muss „gefixt“ wer­den. Schlech­te Bedien­bar­keit ist kein Feh­ler, kein Bug und kann auch erst­mal unge­fixt blei­ben. Wenn man es nur rich­tig macht, funk­tio­niert die Soft­ware ja.

Jeder ist sich selbst am nächsten

Ent­wick­ler bau­en zu aller­erst die Funk­tio­nen in eine freie Soft­ware, die sie selbst benö­ti­gen. So wächst das ursprüng­lich klei­ne Pro­gramm­chen zu einem Mons­ter, aus lau­ter Funk­tio­nen, die irgend­wann ein­ge­fügt wur­den, ohne dass man jemand einen Schritt zurück getre­ten ist um das Gesamt­bild zu betrach­ten. „Ist das Bedien­kon­zept noch angebracht?“

Designvorschläge sind nicht gerne gesehen

Pro­ble­me mit der Bedie­nung einer Soft­ware haben meis­tens die Anfän­ger – wenn aber von denen einer ankommt und auf die Pro­ble­me hin­weist kri­ti­siert die frei­wil­li­ge, unbe­zahl­te, hoch­wer­ti­ge und mühe­vol­le Arbeit der Ent­wick­ler. „Soll der Anfän­ger doch froh sein, dass es die Soft­ware über­haupt gibt!“

Dann ist es auch egal, ob der Anfän­ger Vor­schlä­ge zur Ver­bes­se­rung macht oder nicht – macht er wel­che, hat er ein­fach die Soft­ware noch nicht ver­stan­den und soll­te die Feh­ler bei sich selbst suchen. Macht er kei­ne Vor­schlä­ge, dann gilt er nur als Mäk­ler, der es aber auch nicht bes­ser weiß.

Lei­der habe ich auch die Erfah­rung gemacht, dass das The­ma „Usa­bi­li­ty“ ziem­lich schwie­rig ist. Ich befürch­te, dass die Vor­schlä­ge, die Tho­mas zur Lösung die­ser Pro­ble­me im San­de ver­lau­fen, wenn das The­ma „Usa­bi­li­ty“ nicht gene­rell mehr Aner­ken­nung fin­det. Usa­bi­li­ty ist ein Qua­li­täts­merk­mal. Zur Zeit gilt eher noch: Wenn etwas schwer zu erler­nen ist, muss es hoch­wer­tig sein: Ein Kla­vier ist auch schwie­ri­ger zu bedie­nen als ein CD-Play­er. Wer aber nur Musik hören will, soll­te nicht 5 Jah­re Unter­richt neh­men müssen.

Foto: Patrick Sie­gen­tha­ler

Links

• „Why Free Soft­ware has poor usa­bi­li­ty, and how to impro­ve it“, Matthew Paul Thomas
• via elfisk.dk