Interview: Usability für Open Source

Usability-Expertin Ellen Reitmayr im Interview. Am 3. November 2005 ist World Usability Tag mit zahlreichen Veranstaltungen, eine davon beschäftigt sich in Berlin mit dem Thema "Offene Usability". Denn gerade in Open-Source-Projekten kommt der Aspekt der Benutzerfreundlichkeit häufig noch zu kurz, wird sich doch vornehmlich auf die technische Entwicklung konzentriert. Die Berliner Relevantive AG widmet sich nicht nur dem Thema Usability, sondern auch den Themen Linux und Open Source und hat dazu das Projekt "Open Usability" initiiert. Ellen Reitmayr von der Relevantive AG steht so nicht nur hinter dem Projekt, das Entwickler und Usability-Experten zusammenführen will, sondern ist auch an der Entwicklung der "Human Interface Guidelines" für KDE 4 beteiligt. Golem.de sprach mit ihr über das OpenUsability-Projekt und die Bedeutung von Usability für Open Source.

3. November 2005 um 12:28 Uhr / Julius Stiebert

Golem.de: Das OpenUsability-Projekt möchte Usability-Expterten und Open-Source-Entwicklern eine gemeinsame Plattform bieten, um Entwicklern so Hilfestellung zu geben. Andererseits soll den Usablity-Experten die Möglichkeit geboten werden, etwas zu Open Source beizusteuern. Wie sind die Ziele des Projektes definiert?

Ellen Reitmayr: Das Projekt hat mehrere Ziele: Zum einen soll die Nutzungsfreundlichkeit von Open-Source-Projekten verbessert werden, indem interessierte Projekte mit Usability-Experten in Kontakt gebracht werden. Zum anderen soll aber auch ganz allgemein die Wahrnehmung von Usability in den Open-Source-Projekten, wie auch in der breiten Öffentlichkeit, verbessert werden. Im Gegensatz zu vielen Auftragsarbeiten hat man als Usability-Experte in Open-Source-Projekten die Möglichkeit, die eingesetzten Methoden, sowie ihre Kosten und ihren Nutzen öffentlich darzustellen. Das fördert die Transparenz des eher abstrakten Begriffs "Usability". Als Entwickler weiß ich, was ich zu erwarten habe, wenn ich Usability-Experten konsultiere. Als Usability-Experte oder -Nachwuchs, sehe ich, wie andere es machen, kann mich fortbilden und neue Methoden offen ausprobieren. Zuletzt soll die Plattform Usability-Tools bereitsstellen, so arbeiten wir momentan an einem Card-Sorting-Tool, oder stellen einen NX-Server zum Evaluieren der tagesaktuellen Development-Versionen von Software zur Verfügung.

Golem.de: Worin unterscheidet sich die Herangehensweise an Usability bei proprietärer Software gegenüber Open Source?

Reitmayr: Auf der Plus-Seite steht – wie bereits gesagt – die Möglichkeit, Ergebnisse ohne Einschränkungen veröffentlichen zu können. Im Usability-Prozess selbst haben wir die Erfahrung gemacht, dass Entwickler in Open-Source-Projekten, sobald sie sich "für Usability" entschlossen haben, unheimlich motiviert und zeitnah an die Umsetzung unserer Vorschläge machen. Das ist als Usability-Experte natürlich ein tolles Gefühl, da man in Firmen oft sogar um kleine Änderungen kämpfen muss.

Als Nachteil ist die vor allem in kleineren Open-Source-Projekten zu findende diskontinuierliche Entwicklung zu sehen, die es manchmal schwer macht, einen echten Usability-Prozess einzuführen. Auch fehlen oft Vorstellungen von der anvisierten Nutzergruppe, geschweige denn Informationen über die tatsächlichen Nutzer. Dieses Wissen ist jedoch die Grundlage der Usability-Arbeit, da sie immer nur im Kontext der zukünftigen Nutzer, ihrer Aufgaben und ihres Arbeitskontextes zu sehen ist.

Golem.de: Wie funktioniert eine Zusammenarbeit im Bereich Usability, die ja nur selten in direktem Kontakt möglich ist.

Reitmayr: Wir verwenden die in Open-Source-Projekten üblichen Informationskanäle wie Mailinglisten, Foren oder IRC. Außerdem sind wir auf möglichst vielen Konferenzen präsent, um den persönlichen Kontakt herzustellen.

Golem.de: Für KDE 4 wurden Human Interface Guidelines entwickelt, die zu einer besseren Benutzerfreundlichkeit beitragen sollen. Was legen diese fest?

Reitmayr: Human Interface Guidelines sollen den Entwicklern helfen, eine Anwendung zu entwickeln, die konsistent mit dem "Look & Feel" der restlichen Anwendungen einer Desktop-Umgebung ist. Definiert werden einerseits spezifische Dinge wie Menü-Anordnungen und Toolbars, Layout innerhalb von Dialogen, Arten und Inhalte von Feedback oder Drag-and-Drop-Verhalten. Gleichzeitig werden aber auch generellere Guidelines wie "Design for your user" und "Know your user" erklärt und an Beispielen illustriert.

Human Interface Guidelines sind jedoch kein Allheilmittel – sie tragen zwar zur Konsistenz von "Look & Feel" bei, können jedoch kein maßgeschneidertes Interaktionsdesign bieten, das heißt eine Dialogabfolge, die die Denkweise des Nutzers widerspiegelt.

Golem.de: Ist es bis zur vollständigen Umsetzung noch ein weiter Weg, verglichen mit der aktuellen KDE-Version?

Reitmayr: Die KDE 4 Human Interface Guidlines sind noch nicht vollständig und noch nicht offiziell publiziert. Von daher können viele Anwendungen die Guidelines noch gar nicht berücksichtigen. Ich bin aber zuversichtlich, dass – wie in Gnome – ein Großteil der KDE Anwendungen mit einer Latenz von einem Jahr nach Veröffentlichung der Guidelines weitgehend konform sein wird.

Golem.de: Sind diese Richtlinien – zumindest in Bezug auf KDE4 – für die Entwickler verpflichtend oder steht es ihnen frei, sich daran zu halten?

Reitmayr: Soviel ich weiß steht es ihnen frei. Es wird aber automatisierte Guidelines-Checks geben, die das Aufspüren und Fixen von Problemen erleichtern.

Golem.de: Es heißt, die HIGs des Gnome-Projektes seien so umfangreich, dass sie keiner liest. Wie verfährt man bei den auf OpenUsability.org gehosteten Gnome-Projekten, dienen diese Richtlinien als Orientierung?

Reitmayr: Selbstverständlich. Eine Anwendung muss immer im Kontext der für sie geltenden Richtlinien bewertet werden – eine Web-Anwendung hat andere UI Elemente als eine Apple-, KDE- oder Gnome-Anwendung. Natürlich stimmen sie in den Grundsätzen überein. Details sind jedoch "Flavour", die den Charme einer Umgebung ausmachen. Und das soll auch so bleiben! So umfangreich sind die Gnome-Richtlinien aber auch wieder nicht – man bräuchte nur eine Suchfunktion...

Golem.de: Welche konkreten Erfolge kann das OpenUsability-Projekt bisher vorweisen?

Reitmayr: Wir arbeiten eng mit KDE zusammen, zum Beispiel KDE PIM, Appeal, KPDF, Kopete, Kivio, DigiKam, KDE-edu und vielen mehr. Dort sind zahlreiche kleinere und größere Verbesserungen zu finden, aber auch konzeptuelle Arbeit für Neuerungen in KDE 4. GIMP hat seit seiner Anmeldung auf OpenUsability großen Zuwachs an Usability-Experten und rege Diskussionen, und wir werden vor dem nächsten Release einen zweiten Usability-Test mit GIMP durchführen. Mehrere Content-Management-Systeme wie Typo3, Drupal und Backend-CMS haben sich auf OpenUsability angemeldet und wir sind neben spezifischer Unterstützung dabei, allgemeine User-Interface-Guidelines fuer Content-Management-Systeme in Web-Umgebungen zu schreiben. Dann gibt es natürlich noch eine ganze Menge Erfolge, von denen ich gar nichts weiß, da ich nicht unmittelbar in die Projektarbeit integriert bin.

Golem.de: Häufig ist Open Source von Techniker für Techniker entwickelt, zumindest, wenn man einem weit verbreiteten Vorurteil glauben darf. Wie groß ist die Bereitschaft seitens der Entwickler generell, sich Gedanken über Benutzerfreundlichkeit zu machen?

Reitmayr: Wie gesagt – wenn die Bereitschaft da ist, dann ist sie mit großer Begeisterung da. Insgesamt scheint OpenUsability das Ziel, die Wahrnehmung von Usability in der OSS-Gemeinde zu stärken, zu erreichen. Das zeigt die große Zahl an Projekten auf OpenUsability, momentan sind es 95.

Eine ähnliche Initiative sollten wir jetzt fuer Accessibility in Angriff nehmen: Hier scheint es den Entwicklern noch nicht ganz so klar zu sein, warum gerade ihre Software "accessible" sein soll...

Golem.de: Was haltet Ihr von Novells " Better Desktop "?

Reitmayr: Super! Wir haben einige Male mit Anna Dirks und Pete Goodall (Usability-Experten bei Novell, Anm. d. Red.) gesprochen und Pete auf der KDE Konferenz in Malaga getroffen. "Better Desktop" bietet auch eine schöne Auswahl an Artikeln, wie man als Entwickler Usability-Tests durchführen kann – also genau die Howtos, die auf OpenUsability noch fehlen.

Bei "Better Desktop" fehlt uns jedoch eine qualitative Analyse der Ergebnisse, die in die Projekte zurückfließen kann. Also z.B. statt der Aufgabenzeiten sollten Gründe gegeben werden, warum User an welchen Stellen Probleme hatten, und was man dagegen tun kann. Genau diese praktische Hilfe ist das Ziel von OpenUsability.

Golem.de: Die geringere Verbreitung von Open-Source-Software dürfte nur zu einem kleinen Teil daran liegen, dass sie nicht benutzerfreundlich ist. Meint Ihr dennoch, die Verbreitung durch eine gesteigerte Usability erhöhen zu können?

Reitmayr: Sicherlich – sofern der Nutzer die freie Wahl hat. Es gibt verschiedene Akzeptanz-Modelle (z.B. Venkatesh, 2000 ), die das ganz gut veranschaulichen: Die wahrgenommene Einfachheit einer Software beeinflusst die wahrgenommene Nützlichkeit, und die wiederum die Bereitschaft, eine Software zu nutzen. Je einfacher also eine Software, umso eher nutze ich sie.

Golem.de: Anders als bei proprietärer Software ist im Open-Source-Bereich zu Beginn der Entwicklung häufig nicht völlig klar, für welche Zielgruppe man da programmiert. Wie begegnet Ihr in Hinblick auf die Benutzerfreundlichkeit dieser Problematik, nicht zu wissen, wer später mit der Software arbeiten soll?

Reitmayr: Ja, das ist ein Problem, wie schon beschrieben. Wir arbeiten im Rahmen von OpenUsability daran, eine Nutzerbasis aufzubauen und Umfragetools zur Verfügung zu stellen. Das ist jedoch noch Zukunftsmusik.

So lange geben wir uns mit imaginären Nutzern, sogennanten "Personas", zufrieden, die wir als prototypische Nutzer definiert haben. Außerdem stellen wir den Projekten immer zu allererst die Frage "Wer sind eure Nutzer?" Erst wenn sie die befriedigend beantwortet haben, machen wir uns an die weitere Arbeit.