rss feed articles activities all_comments

indeedgeek.de

Florian Eitel

Gedanken über User Interfaces - 1

Ich hasse GUI's

“Ich hasse GUI’s” – Den Satz werden die meisten von mir kennen. Ja, es stimmt, ich kann grafische User Interfaces nicht leiden. Und doch: Eigentlich stimmt es nicht ganz. Eigentlich glaube ich, man kann die UI’s auch brauchbar gestalten – Ich habe nur noch keines gesehen.

Wie ich ohne GUI mit meinem Computer bediene? Also primär indem ich Befehle eingebe. Ich habe wohl auch ein Dateimanager oder einen Texteditor installiert aber die werden nur in bestimmten Ausnahme-Situationen benutzt. Im täglichen Gebrauch sind eigentlich nur eine Hand voll Programme wie Browser oder Mail mit UI. Ansonsten nutze ich nur Programme auf der Konsole wie zum vim oder mpd. Nicht das ich nicht gewillt bin, eine GUI zu verwenden. Programme wie zenmap starte ich eigentlich immer mit grafischen Interface, da ich es zu selten brauche um mit alle Optionen zu merken. Es ist viel mehr die Art und Weise wie einem die User Interfaces im Weg stehen.

Erst mal vorne weg: Wir haben Ahnung! Ich würde behaupten wir haben ein gewisses Grundverständnis von Computern. Nehmen wir mal als Beispiel Mail raus: Ich glaube (hoffe) jeder von uns ist im Stande sich über SMTP mit seinem Mailserver zu unterhalten. Wir wissen was im Hintergrund passiert. Zur Not verschicke ich eben meine Mails mit netcat. Nicht das ich öfters so Mails versenden möchte, aber es ist festzuhalten: Wir könnten es! (Und manchmal ist es so einfach schneller als erst Thunderbird zu starten)

Nun kommt da jemand her und macht sich die Arbeit und schreibt ein Mail-Client (danke dafür!). In meinem Fall nutze ich zum Beispiel Thunderbird. Und doch ärgere ich mich jeden Tag erneut darüber. Ich denke das Problem liegt daran, dass die Entwickler versuchen alles möglichst einfach und abstrahiert zu halten. Das ist ja eigentlich auch ganz gut damit Anfänger damit zurecht kommen. ABER: ICH weiß wie es funktioniert. Wie soll es also möglich sein ein Interface für jemanden zu gestalten, der weiß was er will? Und noch viel schwieriger: Wie soll jemand das bedienen können, der es eben nicht weiß? Ich denke man kann nicht beides über ein Interface abdecken.

Machen wir ein Beispiel: Ich behaupte mal, ein normaler Mail-Nutzer hat ein SMTP und einen IMAP Server. Alles kommt zur INBOX rein der Client macht vielleicht zwei, drei Filter und erkennt Spam. Noch ein paar lustige Smilies-Bildchen und der Nutzer ist zufrieden. Mein Wunsch-Setup wäre so: Mein Mailserver macht Spam-Erkennung und kennzeichnet die Mail entsprechend. Anschließend wird sie in den IMAP-Server gepackt der ein SIEVE Script drüber laufen lässt. Dieses wertet alle Informationen aus und Tagged die Nachricht entsprechend mit IMAP-Flags. Anschließend landet alles in meiner INBOX. Der Mail-Client kann nun anhand der FLAGS virtuelle Ordner darstellen. So wäre auch ein Trash einfach zu implementieren da einfach dieser alle Nachrichten mit \Deleted enthalten würde. So und nun bringt mal beide User-Gruppen dazu den selben Client zu benutzen… Ich denke an diesem Beispiel sieht man recht gut die völlig unterschiedlichen Ansprüche an ein Stück Software.

Meistens hat die Software sogar irgendwie die Features die ich bräuchte aber sie sind nicht nutzbar. Gerade die Konfiguration steht einem ständig im Weg. Im Beispiel des Trash-Ordners ist es unter Thunderbird leider nicht möglich nach dem Tag \Deleted zu suchen da in der Suche einfach eine Drop-Down Box zu finden ist, die das nicht zur Auswahl stellt. Technisch ist es überhaupt kein Problem da ich nach anderen Tags suchen kann. Oder anders Beispiel: Möchte man sich zu einer Nachricht den kompletten Thread als Baum darstellen lassen muss man zwingend Indizierung global in allen Konten aktivieren. WARUM? (Da bin ich auch erst durch den Source-Code drauf gekommen.)

Ok, nun sagt ihr vielleicht so viele Features um jeden zufrieden zu stellen kann man gar nicht einbauen. Korrekt! Muss man auch nicht. Zum einen sollte erst einmal alles was nicht zum Programm gehört raus schmeißen. Für was braucht mein Mail-Client ein Editor? Warum kann er nicht meinen Standard-Editor starten bei dem alles perfekt eingerichtet ist? Bei dem ich Rechtschreibprüfung, Autovervollständigung, Shortcuts, einfach alles habe? Nein statt dessen bekomme ich ein blödes Textfeld präsentiert. Genauso Password-Management, Notifications, Adressbuch, …? Warum überlässt man das nicht den Programme die es auch vernünftig können?

Manche Programme bieten eine Schnittstelle für Plugins an um Usern zu ermöglichen das Interface anzupassen. So möchte man das haben! Ein schmales Programm und Erweiterungsmöglichkeiten. Aber meistens ist es so kompliziert da was rein zu basteln (wenn das gewünschte Feature überhaupt zugänglich ist), das man dann doch wieder das Rad neu erfinden muss.

Was man möchte, ist eine einfache Schnittstelle, die den gesamten Status und alle Features zugänglich macht. Ich würde hier, im Gegensatz zu Plugins, dahin unterscheiden, dass ich bei einer Schnittstelle frei bin, wie und mit was ich dagegen programmiere. Einige bessere Programme bieten Hooks an um so etwas zu realisieren. Also zum Beispiel kann man ein Programm angeben was aufgerufen wird wenn eine Email eintrifft. Am besten wird diesem dann noch Infos wie die Email selbst übergeben. Das Programm kann man dann in seiner bevorzugten Programmiersprache schreiben und dort alle erdenklichen Features ausnutzen.

Zum Beispiel möchte ich ein Adressbuch haben in dem sowohl Emails auch Verlauf von Instant Messaging aggregiert wird. Die Kontaktdaten sollen über GroupDav mit meinem Server gesynced werden. Zusätzlich wird der Verlauf über meine server side history von Jabber abgefragt. Zudem der aktuelle online Status vom IM-Client erfragt werden. (man kann das noch entsprechend weiter treiben… man denke nur an Twitter oder Facebook) Thunderbird hätte nun zum Beispiel die Hooks “email2name” oder find “contact” welches einfach Programme in einem bestimmten Ordner sein können. Diese werden mit definierten Parametern aufgerufen und geben ein bestimmtes Format als Rückgabe zurück. Und nun versucht das mal in euer Mail-Programm abzubilden. Thunderbird scheitert ja schon wenn ein Kontakt mehr als zwei Email-Adressen hat.

Das Problem was man mit Hooks hat: Wenn man extrem viele von ihnen hat, wird es übersichtlich da man im Grunde für jeden Hook ein eigenes Script angeben muss. Zusätzlich ist es fraglich wie die Hooks an die benötigten Daten kommen. Einige wenige Parameter kann man mitgeben oder über ein einfaches Protokoll nach STDIN pipen aber meistens benötigt man noch eine zusätzliche Möglichkeit weitere Daten zu erfragen. Zudem kommt der Rückkanal: Wie kann der Hook Daten verändern? Der Pendant zum STDIN ist natürlich STDOUT oder über einen simplen return Wert lässt sich auch schon einiges sagen. Ein Beispiel für ein derartiges System ist Munin, was eigentlich nur mit STDIN und STDOUT funktioniert.

Ein weiterer Ansatz ist zum Beispiel D-Bus, welches in letzter Zeit sehr viel Zulauf bekommt. Dies ist eine Middleware im Desktop-Umfeld welche für IPC gedacht ist. Das bekannteste Beispiel sind sicherlich die Notifications welche von der Applikation an einen Notification-Daemon geschickt werden, der diese dann anzeigt. Man kann nun einfach den Daemon austauschen und so das Verhalten ändern ohne das man die Clients anfassen muss. Allerdings geht D-Bus noch weiter und teilt ganze Applikationen nach UI und Funktion. Zum Beispiel Telepathy in Kombination mit Empathy hat so seinen Durchbruch geschafft. Die Idee ist einfach und genial: Telepathy besitzt verschiedene Server-Komponenten die Instant Messaging über verschiedene Protokolle (IRC, XMPP, SILC, SIP …), Kontakte verwalten etc. Diese werden über D-Bus von verschiedenen UI’s angesprochen. So muss der Messenger Empathy nur noch das UI implementieren und die Funktionen weiter reichen. Ganz so einfach ist es nicht und die Vielzahl von Schnittstellen machen es auch nicht so einfach. Aber zumindest ein Ansatz in die richtige Richtung finde ich.

Generell kann man sagen, dass Server-Client-Strukturen vom Prinzip immer zu bevorzugen sind. Wenn ich euch nun an dieser Stelle sage das ihr unbedingt Implementierung und UI trennen sollt werdet ihr wohl lachen und dies für selbstverständlich abtun. Schließlich bekommt man es ständig vorgepredigt. Aber tut ihr es auch? Nehmen wir einen Music-Player als Beispiel. Würdet ihr diesen wirklich in UI und Funktion teilen? Ich kenne eigentlich nur ein Projekt was dies (sehr erfolgreich) getan hat: MPD. Hier gibt es einen Music-Player-Daemon dem ich sagen kann er soll zum Beispiel ein Lied abspielen, stoppen, die Playlist wechseln oder mit Daten über das aktuelle Lied geben. Mehr tut das Programm nicht. Nun kann ich mir einfache Clients schreiben die auf diese einfache API aufsetzen. So habe ich vier völlig verschiedene Clients im Einsatz die angefangen von Notifications über ein CLI und GUI bis hin zum Webinterface genau das bieten was ich gerade brauche. Selbst übers Netzwerk.

Warum macht das sonst keiner? Warum braucht mein Browser eine Bookmark-Verwaltung? Warum mein Mail-Client ein Adressbuch? Warum mein Messenger eine Passwortverwaltung? Oder um es auf die Spitze zu treiben: Warum weiß mein Music-Player etwas von Dateien?

Ok, ich schweife ein kleines bisschen ab, aber indirekt hat das genau mit dem Problem zu tun: Viele versuchen EINE Anwendung zu machen die alles kann. Die hat dann EINE GUI und mit viel Glück eine verkrüppelte Plugin-Architektur. Anwendungen ohne GUI können dies per Design schon mal nicht. Sie müssen in irgendeiner Art und Weise Schnittstellen anbieten (und wenn es nur STDIN und STDOUT ist was man über PIPE-AND-FILTER zumindest weiterverarbeiten kann).

Nun wird sicher der eine oder andere kommen und das Totschlag Argument der Portabilität auspacken. Dazu sage ich nur: Vergesst es! Portabilität ist ein Mythos! In dem Moment, in dem man Features weglässt oder neu erfindet nur um portabel zu sein ist es schon zum scheitern verurteilt! Ich will kein Browser der auf Linux UND Mac läuft. Das kann gar nicht brauchbar funktionieren. Mac ist von Grund auf anders. Die gesamte Bedienung, das gesamte Framework und Infrastruktur, ja selbst die Mentalität ist eine andere! Wie völlig verblendet kann man sein und denken ich schreibe jetzt ein Programm was alles kann und überall läuft? Dann kommt so fruchtbares Zeug raus wie bei den Mozilla-Jungs die das Rad mit jeder Programmzeile neu erfinden (Notifications, Password-Storage, UI, …) und trotzdem überall graußam zu bedienen sind. Man kann sich nicht einfach auf einen minimalen Konsens einigen. “Popup-Fenster gibt’s aber doch überall..” – NEIN! Mein Window Manager kennt zwar zwangsläufig das Konzept von Fenstern (mehr oder weniger) aber jedes neue Fenster muss erst an die korrekte Position gebracht werden – was bei Popups echt furchtbar ist! Vor allem was ich auch nie verstehen werde: Warum sperrt man die gesamte Anwendung wenn ein Fenster geöffnet wird? Schon mal bei Firefox versucht etwas zu konfigurieren und gleichzeitig zu suchen wie die Option heißt? Warum peinigt man seine Nutzer mit solchen nutzlosen Restriktionen? Und kommt mir bei einer solchen geistigen Verwirrung nicht mit dem Argument, dass dies von der Usability besser ist.

Fassen wir zusammen: GUI’s sind nicht schlecht. Zumindest nicht per Definition. Ich wehre mich nur gegen monolithische Anwendungen, schlechte Schnittstellen, Portabilität auf kosten von Integration und Funktion und Bevormundung von Usern. Sicher machen einfache Anwendungen Sinn, aber es muss auch möglich sein Programme sinnvoll zu nutzen.

Bis hier her gekommen? Problem erkannt? Gut, dann stellt sich vielleicht die Frage: Wie macht man es besser? Ich habe glaube ich ein Rezept gefunden welches für mich funktioniert. Aber da der Post schon wieder viel zu lang ist gibts den in den nächsten Tagen. So lange freue ich mich über eure Meinung in den Kommentaren!

Comments:

(howto comment?)