HCI

Martin hat in seinem Blog einen englischsprachigen Artikel What makes a “lightweight” desktop environment lightweight? geschrieben. In ihm kommt er zu dem Schluss, dass das Attribut "leichtgewichtig" willkürlich sei und eigentlich keine Bedeutung habe.

Ich mag den Artikel. Martin tut so, als würde er den Begriff nicht verstehen, und ich glaube, dass er sich da bewusst seiner eigenen instinktiven Deutung des Begriffes widersetzt - und er übersieht völlig die mich sehr erheiternde Ironie darin, wenn ausgerechnet ein KDE-Entwickler mit dem Bild leichter Software nichts anfangen kann (was ich tatsächlich nicht böse meine). Aber zusammen mit seinem Ausschlussverfahren, das ziemlich gut beschreibt, was leichte Software ist (nur zum gegenteiligen Schluss kommt), und den Kommentaren ergibt sich ein gutes Gesamtbild, das in meinen Augen den Begriff wirklich schön zeichnet. Ich nehme das mal und mische es hier mit meiner eigenen Definition.

1. Leichte Software ist subjektiv

Offensichtlich geht es nicht um das Gewicht der Software und nicht um die Größe des Codes. Software mit einem Gewicht zu belegen kann angesichts ihrer inhärenten Gewichtslosigkeit nur ein emotionaler Begriff sein, der eine Brücke schlägt zu Erfahrungen im rl. Und das ist ein guter Anhaltspunkt bei der Deutung des Begriffes. Wenn etwas im echten Leben schwer ist, tragen wir schwer daran, haben Probleme, es zu bewegen, beschleunigt es nicht so schnell wie ein leichteres Objekt mit der gleichen Antriebskraft; alles geeignete Analogien zu unserer jeweiligen subjektiven Erfahrung mit Software.

Martin begab sich auf die Suche einer festen Definition von leichter Software und scheiterte daran, eine solche zu finden. Wenn Software auf der und der Hardware so und so gut läuft, dann ist die Software leichtgewichtig - das wird man seltenst irgendwo lesen. Da es ein Attribut ist, das die Bewertung des Nutzers wiedergibt, ist es für jeden Nutzer eine andere Hardware und eine andere Eigenschaft, die das Attribut rechtfertigt. Das kann der Start der Software selbst sein: Wenn eine Desktopumgebung mehrere Sekunden zum Starten braucht, fühlt sich das nicht schnell, nicht leicht an. Es kann aber auch wesentlich weiter gehen. Es kann sogar technisch versierte Nutzer geben, welche die Abhängigkeiten oder den Code selbst heranziehen - das dürfte die Ausnahme sein, soll hier aber Beispiel dafür sein, wie subjektiv die Klassifikation sein kann.

2. Leichte Software ist effizient

Aber es gibt durchaus offizielle Definitionen der Benutzbarkeit von Software, die mit dem Begriff leichtgewichtiger Software verknüpfbar sind. Nach ihnen hat Martin seiner Beschreibung nach nur nicht gesucht und sie auch nicht zufällig gefunden.

Sie verbirgt sich in Effektivität, Effizenz und Nutzerzufriedenheit, dem Dreiklang der HCI nach DIN ISO 9241.

Effektivität:

Die Möglichkeit, mit dem Werkzeug eine Aufgabe überhaupt zu erledigen.

Effizienz:

Wie schnell und wie einfach die Aufgabe zu erledigen ist.

Nutzerzufriedenheit:

Der Begriff erklärt sich selbst, wird von den vorherigen Faktoren beeinflusst, aber nicht alleine von ihnen bestimmt.

Eine Kategorisierung von Software als leicht ist nun eine Einstufung dieser Software in der zweiten Kategorie, Effizenz. Denn vergleicht man zwei verschiedene Programme und hält das eine für leichtgewichtig, das andere aber nicht, impliziert man damit meist, dass beide der gleichen Aufgabe dienen. Effektivität kann es also nicht sein. Und Zufriedenheit ist zuwenig mit der eigentlichen funktionalen Eigenschaft der Software verknüpft, um das zu beschreiben (auch wenn das sicher mit hereinspielt). Es geht also darum, wie einfach und wie schnell etwas zu machen ist. Und klar: Geht etwas mit wenigen Klicks in einer überschaubaren Oberfläche und ohne störende Ruckler, geht es in der Regel effizienter, als sei dem nicht so. Und genau das kann leichte Software sein: Solche, die nicht ruckelt und solche, die eine Aufgabe schnell und einfach erledigen lässt.

3. Was leicht ist, wird relativ zur Hardware definiert

Wenn eine Desktopumgebung dazu führt, dass der Browser nur träge reagiert - dieser aber unter einer anderen annehmbar schnell läuft - ist sie sicher nicht leicht. Dieses Phänomen kann ich wunderbar auf dem Thinkpad R50 mit Unity und E17 beobachten. Während sich unter Unity alles zäh und träge anfühlt, beim Fenstermanagement, beim Aufruf des Dashs und den Hovereffekten des Docks, aber auch beim Surfen im Browser, ist es unter E17 gut erträglich, flüssig sogar, sodass man einwandfrei mit ihm arbeiten kann (ich hatte ihn z.B. auf dem ictf dabei). Offensichtlich ist Unity derart fordernd, dass die Oberfläche langsam gerendert wird und für die eigentliche Aufgabe nicht genug Ressourcen übrig bleiben. Das Gegenteil leichter Software.

4. Leichte Software hat keinen (wahrnehmbaren) bloat

Aber auch, wenn die GUI der Software viele Elemente hat und überladen wirkt, kann das zu dem Nutzereindruck führen, nicht leichtgewichtig zu sein. Das war nebenbei ja schon immer eine Lektion, die KDE nicht lernen wollte. Zum einen, weil leichte Software ein emotionaler Begriff und eine Analogie ist, zum anderen, weil es um die Effizenz beim Ausführen einer Aufgabe geht, ist es nicht alleine Geschwindigkeit der Software - eine Kerbe, in die Martin gerne schlägt, wenn er von Optimierungen für neue Hardware redet. Es geht um die Aufgabe und den Weg dahin, und eine klar steuerbare (noch so ein HCI-Begriff) GUI hilft dem Nutzer dabei, eine Aufgabe effizient zu erledigen.

Es geht hier wohlgemerkt nicht um Konfigurierbarkeit. IceWM und viele andere kleine, leichte Fenstermenager sind stärker konfigurierbar als jede Desktopumgebung. Trotzdem wirken sie leichter, schon weil sie in jeder Hinsicht schneller sind - und auch, weil ihre Konfigurationsmöglichkeiten in Textdateien versteckt sind.

Wobei sich das nicht auf GUIs beschränkt: Die Komplexität der Konfiguration und die Performance des Tools können auch bei Programmen mit Text-UI bewirken, nicht als leichtgewichtig wahrgenommen zu werden. Programmiersprachen sind gar ein völlig eigenes Kapitel.

Zusammenfassend: Leichte Software ist viel und wenig

Viele Programme können leicht wirken und viele Faktoren wirken sich hier aus. Der Eindruck kann sich ergeben, wenn etwas besonders flüssig läuft. Eine gute Energieeffizienz kann helfen, wenn der Nutzer gerade darauf achtet, z.B. weil unter Linux im Gegensatz zu Windows der Lüfter des Laptops nur in Ausnahmefällen zu hören ist oder der Akku länger hält. Wenn Software auf vielen alten System läuft, ist sie leicht, bzw diese ist es, die auf der alten Hardware am besten/schnellsten/flüssigsten läuft - aber nicht solche Software, die sich erstmal an einem 5-minütigen Splashfenster abrackert (übrigens ein Anti-Pattern in der Interfacegestaltung).

Das kann man umdrehen: Wenn ein Programm eine simple, klare Oberfläche mit wenigen Elementen hat, kann dies den Eindruck leichter Software hervorrufen. Verstärkt noch, wenn der Stil der Software schlicht ist - und meinem Eindruck nach insbesondere, wenn die Oberfläche zwar schlicht, aber gleichzeitig hübsch und auch noch responsiv ist. Sind die Hardwareanforderungen gering, ist Software leicht. Erfordert die Software wenig Vorwissen, ist die Software ebenfalls leicht - auch so kann man den Begriff anwenden, wobei hier sich leicht als einfach mit leicht als leichtgewichtig vermengt

Man kann das alles in eine vereinfachende Faustregel als Fazit zusammenpacken: Läuft Software schnell auf alter und neuer Hardware des Nutzers und hat keine Oberfläche, die eine gegenteilige Atmosphäre schafft (z.B. durch langsame Animationen oder der Komplexität des Workflows), dann wird sich beim Nutzer der Eindruck ergeben, dass die Software leichtgewichtig ist.

Webseiten von Verkehrsbetrieben sind ja desöfteren nicht gerade toll zu bedienen. Die des VRS funktioniert aber eigentlich ganz gut. Besonders schön ist die Ajax-Autokorrektur der angegebenen Stationsnamen, die auch noch tatsächlich die richtigen auswählte. Auch die Liste der möglichen Abfahrten ist überschaubar. Doch dann gibt es noch diese Karte:

Die Karte zur Anzeige der Stationen ist etwas, was diese Webseiten besonders häufig nicht hinkriegen. Wahrscheinlich verhindern es die Kosten gute Karten zu beschaffen, ist es aufwändig, das Nutzerinterface zum Navigieren gut hinzubekommen und verhindern es Datenschutzbedenken, einfach Google Maps zu verwenden (wobei das ja inzwischen auch kostet und man das Interface ebenfalls nicht toll finden muss).

Aber diese Karte ist besonders schlimm:

1. In einer sowieso recht rötlichen Karte, auf der die Gebiete und einige Strecken (oder Staßen?) rot markiert sind, ist die Farbe zum Highlighten der gewählten Strecke - natürlich rot.
2. Diese überhaupt wahrzunehmen wird nicht einfacher durch den Sprung, den die rote Markierungslinie von der blauen Station zur Straßenbahnlinie über eine vermeintliche Autostraße hinweg macht.
3. Die Straßenbahnhaltestellen, um die es auf der Karte hauptsächlich geht, sind kaum zu erkennen und nur ganz vage beschriftet. Sie reagieren auch nicht auf den Mauszeiger. Wer erkennt sofort, auf welche Haltestelle die Karte zentriert ist?
4. Die gesamte Bildqualität ist schlecht. Nicht nur ästhetisch ist die Farbwahl unschön, auch ist die Schrift kaum zu lesen, wie richtig schlecht gedruckt.

Besonders schade, weil der Rest der Seite recht hübsch und klar strukturiert ist und besonders in das Eingabefeld scheinbar richtig Arbeit gesteckt wurde.

Ich war die Tage bei einem Vortrag über Gimp von Simon (Nomis) im Hackerspace Siegen. Ging mehr um die grundlegenden Fähigkeiten von Gimp und wie man sie nutzt, aber über die Neuausrichtung kam er auch zur für mich spannenderen und momentan immer noch aufflackernden Diskussion über den neuen Speicherndialog.

Gimp 2.8 ändert diesen (nach Spezifikation), sodass man nur noch in .xcf speichern kann und für alles andere den Exportieren-Dialog nutzen muss. Motto: GIMP opens and saves GIMP files and imports/exports the rest.

Der Grund für diese Änderung: Gimp will professionelle Nutzer ansprechen, diese arbeiten viel mit Ebenen und sollen auf keinen Fall diese und das Originalbild verlieren, wenn es durch Speichern in png/jpg mit den Ebenen verschmolzen wird. Außerdem (das kommt aus der Spezifikation) soll verhindert werden, dass bei verlustbehafteten Formaten wiederholt gespeichert wird.

Der Flamewar, der aus einer ernsthaften Diskussion entstand, war natürlich vorhersehbar. Die Änderung erfordert eine Umstellung, was für Nutzer immer ärgerlich ist, und sie ist unbequem:

• Man bemerkt sie erst, wenn man schon im Speichern-Dialog ist und den dann mühsam abbrechen muss
• Sie verhindert bestehende Workflows
• Sie kostet Flexibilität, der Speichern-Dialog kann nun schlicht weniger (und damit der Nutzer)

Ich würde behaupten, dass die Änderung gegen ein paar Usability-Kriterien verstößt (z.B. Steuerbarkeit), was man abwägen muss gegen die erwünschte Fehlervermeidung. Für mich ist sie vermutlich ärgerlich, da ich Gimp hauptsächlich zum Verkleinern von Bildern nutze und das nun ein paar Schritte mehr erfordert. Zum Erstellen von Screenshots und dem Vergleichen der Formate wirkte sie bisher eher hilfreich.

Aber genau das ist der Punkt, man sieht es an dem was ich mit Gimp mache: Ich bin nicht in der Zielgruppe.

Da Gimp professionelle Nutzer ansprechen will ist es für das Projekt nur sinnvoll, Funktionen einzubauen die dieser Nutzergruppe helfen. Wenn eine dabei nötige Änderung dann andere Nutzergruppen stört, kann das schulterzuckend ignoriert werden. Der hinter der jetzigen stehende Gedankengang wirkt klar und sie könnte wirklich eine Hilfe sein. Aber: Nirgendswo kann ich eine Bestätigung der These finden, dass professionelle Nutzer die neue Situation gut finden und nur die anderen nicht.

So könnte es nämlich sein, dass gerade professionelle Nutzer verärgert werden, weil sie genau wissen was sie tun, vorher bewusst Exporte mit "Save a Copy" angelegt haben und nun einfach weniger flexibel speichern können, weniger schnell den vielleicht doch auch bei ihnen stattfinden Fall "ein jpeg nur kurz abändern" erledigen können.

In der Spezifikation ist kein Verweis auf eine Befragung oder Beobachtung. Es wirkt, als ob das alles einem Gedankenmodell entsprungen ist und nicht validiert wurde. Wenn dem so ist, macht das die Argumentation natürlich schwer und verhindert es, die Diskussion mit einem klaren "Wir machen das, weil es unserer Zielnutzergruppe hilft, wie wir so und so eindeutig herausgefunden haben" zu steuern.

PS: Wen das Verhalten wirklich stört, kann sich mit einem Plugin helfen.

Dirk schrieb:

Vorab: Ich bin ganz bestimmt kein Psychologe und auch ganz bestimmt kein Philosoph. Die folgenden Bemerkungen entbehren jeder wissenschaftlichen Grundlage und stellen nur meine Gedanken dar. Wobei mich schon interessieren würde, ob es zu den Themen wissenschaftliche Veröffentlichungen gibt (die ich vermutlich nicht verstehen würde, weil mir das Fachvokabular fehlt).

Diese Folge des Datenkanals beschäftigt sich mit Desktops unter Linux. Dort habe ich gerade erstmalig den Begriff Baby-Duck-Syndrom gehört. Eine Baby Ente folgt dem ersten Tier, das sie sehen kann und erkennt es als Mutter an.

Genau so stellt es sich mit dem Beurteilen von Oberflächen bei Computern dar. Wenn das erste, was man gesehen hat, Windows ist, wird jedes weitere System daran gemessen bzw. wird dieses System als Mass für alles herangezogen. Wenn Windows sich auf die eine "Art und Weise" verhält, erwartet man das gleiche Verhalten auch bei anderen grafischen Oberflächen. Das hat was.

...

Tatsächlich ist das ein Phänomen, das im HCI-Bereich vielleicht nicht ausgiebig von uns untersucht, aber auf jeden Fall besprochen und anerkannt wird.

Es gibt da z.B. das Erklärungsmodell von Norman (besonders in Design of Everyday Things). Der Designer eines Systems macht/hat ein bestimmtes mentales Modell des Systems, wie es funktioniert, und designt es entsprechend. Der Nutzer macht sich dann ebenfalls ein solches Modell und bedient es entsprechend. Meistens jedoch sind diese mentalen Modelle nicht identisch.

Sowas kann man immer gut beobachten kann, wenn die Erwartung, wie etwas bedient werden müsste, beim Nutzer anders ist als die Software es zulässt, und dann mit technischen Gründen erklärt werden muss, warum dem so ist.

Es gibt dann verschiedene Möglichkeiten, dem Nutzer trotz dieser unterschiedlichen Grundlagen zu helfen. Man kommt dann gerne in den Usability-Bereich und versucht, Anwendungen so simpel wie möglich zu machen. Doch was heißt simpel? Teilweise eben, die Modelle im Kopf der Nutzer möglichst dem Modell des Designers anzugleichen. Das kann durch Hinweise und Anleitungen erfolgen, was unschön ist. Es kann aber auch auf Metaphern beruhen: Wenn etwas so funktioniert, wie es der Nutzer schon kennt, dann kann er es verstehen.

Das ist das schöne beim WIMP-Modell, überhaupt beim ganzen Desktop mit seinen Ordnern, Papierkörben, Fenstern, Ausschaltern usw: Das heutige Modell der PC-Oberfläche ist eine einzige Metapher und eine Sammlung von Metaphern. Wenn man jemandem unbedarften die PC-Bedienung erklären soll, kann man sich vieler Dinge bedienen, die derjenige kennt. Man sitzt dann vll da und redet von Dateien und Ordnern, und Dateien seien wie Papier oder Fotos die man in ... Ordner eben steckt. Und schon hat der neue Nutzer eine vage Ahnung eines bestimmten Modells, wie das alles hier funktionieren könnte.

Eigentlich sollte ich in Vergangenheitsform schreiben, denn teilweise sind die neuen Oberflächen wie Unity, Metro und auf Smartphones sowieso eine Abkehr von dieser Metapher und vielleicht auch deshalb für viele alteingesessene Nutzer so schmerzhaft.

Genau das führt zum Thema Konsistenz. So wie eine Metapher eine Verbindung zu etwas anderem ist, ist Konsistenz das ebenfalls. Bin ich einmal gewohnt, etwas bestimmtes so und nicht anders zu machen - z.B. ein Fenster auf der rechten Seite oben mit einem "X" zu schließen - überrascht mich ein System, das anders funktioniert. Es ist nicht mehr konsistent zu anderen Systemen und auch nicht konsistent mit den Erwartungen und dem Modell des Nutzers. Es überrascht ihn. Und er hasst es (immer), überrascht zu werden.

Das erklärt den Vorteil des ersten Betriebssystems mit der ersten Oberfläche. Es hatte nur mit dem neuen mentalen Modell des Nutzers zu kämpfen, damit, die Metaphern ordentlich zu nutzen oder wie auch immer es sich verständlich machen wollte. Das zweite und jedes weitere System muss dann nicht nur das tun, sondern ebenfalls die Konsistenzhürde zum vorherigen überwinden.

Der Import an sich funktioniert, abgesehen von dem Gesichter-Bug, komfortabel über das Menü. Aber die Voraussetzung dafür ist, dass ME2 noch auf dem PC installiert ist. Bei mir sind 3 PCs, 4 Wohnungen und 2 Windows-Installationen seit dem Durchspielen des Vorgängers vergangen und alle Dateien des Speicherstands sind bei Google hochgeladen, haben nur deshalb überlebt.

Es gibt aber keinen Ordner-Auswählen-Dialog, auch nicht im Konfigurationstool. Es ist unmöglich, vom Spiel selbst aus anzugeben, wo die Speicherstände aufbewahrt sind.

Was man machen muss: Den Dateibaum nachbauen. Man muss manuell diesen Ordner erstellen:

"C:\Dokumente\ und\ Einstellungen\BENUTZER\Documents\BioWare\Mass Effect 2\Save\Shephard_12_Soldier_230212"

und dort die Speicherdateien hineinkopieren. Ich weiß nicht, ob man den Namen den Speicherständen entsprechend anpassen muss. Erst danach taucht der alte Speicherstand zum Import im Menü auf.

Die Importfunktion ist der wichtigste Bestandteil des Spiels. Für Kenner der Serie geht es vor allem darum, das Ende der Geschichte und die Auswirkungen des eigenen Handelns zu sehen. Es muss Unmengen an Arbeit in die Berücksichtigung aller möglichen Entscheidungen geflossen sein.

Völlig unverständlich, warum nach all der Arbeit vergessen wurde, dass man den zu importierenden Speicherstand dem Spiel geben muss.

Diese Einschätzung ist etwas weniger eindeutig als die davor. Chromium ist etwas schwierig zu bewerten. Mit seinem Versuch, möglichst viel Ballast vom Browserinterface zu entfernen, hat er alle Browser erheblich beeinflusst - und sicher sehr positiv. Demgegenüber stehen unselige Entscheidungen wie seine eigenen Fensterkontrollen, wodurch Chrome zwar gut aussieht, aber die Konsistenz auf dem Desktop zerstört. Ich glaube, dass diese hier auch ein Fehler ist:

Das Plus im Icon für "Neues Tab öffnen" wurde entfernt. So sah das vorher aus:

Ich glaube nicht, dass das furchtbar schlimm ist. Wahrscheinlich kann man das austesten und die meisten Nutzer, die Tabs verstanden haben, kommen trotzdem zurecht. Trotzdem sprechen Gründe dagegen:

• Durch das fehlende Plus ist nicht auf einen Blick klar, was der Button macht
• Da der Wandel plötzlich geschah, dachten einige Nutzer, dass etwas kaputt wäre. Es wurde sogar Bugreports eröffnet.

Wichtiger als die Gründe dagegen sind die Gründe für die Änderung: Es gibt keine. Zumindest habe ich keine gefunden und kann mir keine vorstellen. Google+ differenzieren zu wollen ist kein Argument, das zählt.

Dieses Fundstück ist von Robert.

Die Suche von Windows 7 ist manchmal etwas seltsam, funktioniert aber im Grund recht solide. Hier geht es um die Anzeige des Dateinamens:

Normalerweise zeigt eine Suche den Teil des Dokuments, der das gefundene Wort umgibt. Bei Dateinamen vorne anzufangen ist eine verständliche Entscheidung. Es wird aber eine unglückliche, wenn die angezeigten Namensbestandteile generisch sind, z.B. wie hier nur den Sänger und das Album anzeigen, statt den gesuchten Liedtitel.

Da rechts noch ganz viel Platz ist, könnte dieser genutzt und der Name einfach voll angezeigt werden.

Ein Design richtig zu testen ist nicht einfach. Aber offensichtliche Fehler zu finden ist es. Deshalb starte ich hiermit eine kleine Serie von gesammelten Usability-Problemen.

BSCW

BSCW ist eine Kollaborationsplattform. Das heißt es ist ein Server, auf den Dozenten Folien hochladen und Studenten sich anmelden können, um diese Folien sehen zu dürfen.

Ich bin bei sowas öfter ein bisschen widerspenstig. Meiner Meinung nach braucht es für sowas kein spezialisiertes Tool, sondern eine stinknormale Webseite mit hochgeladenen Folien. Und evtl. ein Forum zum diskutieren. Dementsprechend habe ich den Server einmal benutzt und daraufhin meine Zugangsdaten vergessen. Ist natürlich kein echtes Problem, man kann ja das Passwort zurücksetzen. In der Registrierungsmail steht:

1. Für den Fall, dass Sie Ihr Passwort vergessen haben, registrieren Sie

sich einfach erneut mit der URL:

<https://bscw.wineme.fb5.uni-siegen.de/pub/bscw.cgi?op=rmail>

Bitte geben Sie Ihre E-Mail-Adresse name@student.uni-siegen.de in dem dann

angezeigten Formular an.

Gesagt, getan: