HCI

Eine von mir lange gehaltene Überzeugung, die ich hier endlich aufschreiben werde: Manchmal profitieren Softwareprojekte davon, wenn die Entwicklungsarbeit nicht per Pullrequests eingesendet wird, sondern wenn die Entwickler direkt den Masterbranch ändern. Es erleichtert das Testen und ermächtigt Entwickler.

Erklärungen vorab

Programmierern dürfte der Großteil in diesem Abschnitt klar sein, aber um so viele mitzunehmen wie möglich und Missverständnisse zu vermeiden:

Bei der Arbeit an Software wird inzwischen fast immer Git als Versionsverwaltung eingesetzt. Im üblichen und meiner Erfahrung nach von Firmen ausschließlich genutzten Nutzungsmodus erstellen Entwickler für ihre Aufgaben immer neue Kopien als Grundlage für ihre Änderungen (Branches, dann Featurebranches genannt), die sie dann als Pullrequest an das Projekt schicken. Ein anderer Entwickler prüft die Änderungen in einem mehr oder weniger ausgiebigen Codereview, danach werden sie dem gemeinsamen Entwicklungsbranch hinzugefügt. Wenn zwischendurch andere Codestellen verändert wurden kann oft genug Git die Änderungen zusammenbringen, gibt es aber einen direkten Konflikt müssen die Entwickler diesen manuell auflösen (und entsprechend testen). Diese Nutzungsweise gibt es in mehreren Varianten, eine davon wird Gitflow genannt, nutzt permanent mehrere Branches (mindestens master und dev) und war lange ziemlich populär.

Beim kürzlich wiederaufgekommenen Trunk-based development – vom Namen her ein Verweis auf Entwicklungsweisen vor Git, so war Trunk der Name für den Hauptbranch beim alten Versionsverwaltungssystem CVS – entfallen laut der verlinkten Definition die mehreren Branches, alles liefe schnell im Master zusammen. Aber es gäbe so wie sich das dort liest immer noch die PRs. Laut anderen Definitionen entfallen die ganz, senden Entwickler ihre Änderungen direkt in den gemeinsamen Masterbranch. Und dann sind wir bei meinem Thema.

Vorteile davon, ohne PRs zu arbeiten

Es sind dabei vor allem zwei Punkte, die ich beim direkten Ändern des Masterbranches positiv sehe.

Und zwar primär (und nur tautologisch klingend), dass Änderungen direkt im Masterbranch landen. Das macht sie sichtbarer: Denn anstatt in einem eigenen Branch auf Reviewer und Tester zu warten, wird in manchen Projekten der neue Code im Masterbranch viel eher wahrgenommen. Nämlich immer dann, wenn einzelne Nutzer nicht auf Releases warten, sondern den Code direkt nutzen. Das machen zum Beispiel bei Serendipity ein paar Nutzer mit ihren Blogs. Die akademische Literatur zu FOSS würde sie als Nutzerchampions bezeichnen: Als Nutzer, deren Engagement über das normale Maß hinausgeht und die so die Entwicklung beeinflussen, ohne notwendigerweise selbst Code zu schreiben. Der Masterbranch (aber eben nur der) wird durch sie ausgiebig getestet und Probleme an die Entwickler gemeldet.

Genauso stolpern auch andere Entwickler direkt über den neuen Code, wenn er direkt im Master landet. Es besteht kaum mehr die Gefahr, dass Arbeit gedoppelt wird oder zwei Entwickler in ihren eigenen Branches inkompatible Systeme bauen. Auch Mergekonflikte werden seltener.

Dieser Vorteil wird nochmal wichtiger, wenn PRs lange liegenbleiben können. Wieder Serendipity als Beispiel, das jQuery-Upgrade wäre garantiert nicht fünf Jahre liegengeblieben wenn sein Ansatz schnell im Master gelandet wäre. Wir hätten so bemerkt, dass die gröbsten vermeintlichen Inkompatibilitäten gar nicht an der Javascriptseite hingen (zumindest ist das mein derzeitiger Stand). Das ist übrigens kein Problem nur mit freien Projekten, auch in Firmen mit proprietärer Software habe ich mehrfach erlebt, dass PRs lange liegenbleiben und teils sogar verrotten, also am Ende nicht mehr gebraucht werden konnten weil sich um sie herum zu viel geändert hatte.

Zweitens ist das direkte Ändernkönnen des Masterbranches eine Ermächtigung des Entwicklers. Es bedeutet, dass das Projekt zumindest soweit auch ihm gehört, dass er nicht jede Änderung von anderen absegnen lassen muss. Wenn mal etwas nicht passt, kann das später immer noch geändert werden – bei einer vertrauensvollen Zusammenarbeit eines fähigen Teams ist das auch für niemanden ein Problem. Mit PRs als notwendigen Zwischenschritt ist stattdessen immer die Zustimmung eines Reviewers notwendig (wobei diese Anforderung formell oder informell sein kann), der einzelne Entwickler daher immer sehr viel abhängiger von anderen. Keine gute Voraussetzung, um sich als (Mit-)Ent­schei­der zu fühlen.

Diese Abhängigkeit ist natürlich wieder besonders problematisch, wenn PRs liegenbleiben können. Das muss ja – anders als beim Beispiel mit jQuery oben – gar nicht an konstatierten Problemen liegen, sondern in vielen FOSS-Projekten ist es schlicht Zeitmangel. Und selten ist ein eigener PR den anderen genau so wichtig wie einem selbst. Dann wird die Abhängigkeit von den anderen zu einer frustrierenden Blockade der Entwicklungsarbeit.

Tatsächlich würde (und tue) ich mischen

Pragmatisch ist das Mischen von beiden Ansätzen, und ich fahre damit schon eine Weile meiner Wahrnehmung nach ganz gut. Während das komplizierte Branchmanagement von Gitflow generell abzulehnen ist, haben Pullrequests klare Vorteile. Und die kann man auch dann nutzen, wenn man sonst direkt in den Masterbranch pusht: Immer, wenn Änderungen Abstimmungsbedarf haben, macht man dann eben doch einen PR auf. Zum Beispiel wenn die zu nutzende Version der Programmiersprache sich ändert und dafür große Codeänderungen nötig sind. Sowas landet in einem PR, damit die anderen Entwickler draufschauen und bei der Migration helfen können.

Und wenn mal solch ein PR zu lange braucht und das die eigene Motivation zu ersticken droht? Dann drückt man eben selbst auf den Mergebutton, akzeptiert den eigenen PR auf eigene Kappe. Die anderen hatten dann wenigstens eine Chance gehabt, vorher Rückmeldung zu geben. Sollten in den späteren Tests die Änderungen Probleme machen kann man so oder so immer noch entscheiden, ob an ihnen weitergefeilt werden sollte oder ob sie zurückzunehmen sind.

Klar: Wenn ein Entwickler von außerhalb des Projekts Änderungen einsenden will – wie es bei FOSS-Projekten hoffentlich häufig geschieht – dann wird es völlig unabhängig von allen Überlegungen der internen Arbeit ein PR, der zu reviewen ist. Will man auch in dem Szenario trotzdem PRs soweit möglich vermeiden kann man so jemanden ja schnell ins eigene Team einladen, das mit dem direkten Zugriff auf den Masterbranch entwickelt sich dann meist nach etwas Zögern ganz natürlich.

Das ganze ist ein Balanceakt zwischen Qualität und Entwicklungsgeschwindigkeit, Motivation des Einzelnen und Einflussnahmemöglichkeiten der Gruppe. Man kann damit auf die Nase fallen, man kann aber auch schmerzhafte Blockaden lösen und Projekte besser am Laufen halten. Wichtig ist bei solchen Freiheiten besonders, dass das Entwicklungsteam sich ziemlich vertraut.

Auch ist es wichtig, dass keiner im Team ist, der vor sich hinstümpert und dauernd unlesbaren Code direkt in den Master pusht, am besten noch ohne erkennbare Commitstruktur. Solches Verhalten würde den Ansatz natürlich direkt kaputtmachen und dann braucht es unbedingt die Struktur von PRs und Codereviews, um das Projekt zu schützen. Wobei solche Entwickler dann meiner Erfahrung nach auch mit Codereviews nicht zu bändigen sind, aber das ist ein Thema für sich.

Eure Erfahrungen würden mich interessieren: Habt ihr selbst schon in Teamprojekten ohne PRs gearbeitet, und hat es gut funktioniert?

Agiles Management und ungewollte Bürokratisierung - mit diesem Untertitel hatte mich Schattenorganisation gepackt. Denn ich war entsetzt darüber und ziemlich ratlos, wie starr und insgesamt negativ Scrum im neuen Entwicklerteam der Käuferfirma umgesetzt wurde, während meine Firma die Methodik zuvor so positiv genutzt hatte. "Ungewollte Bürokratisierung" schien mir dabei genau das Problem zu beschreiben.

Schattenorganisation aber spricht zu diesem Thema nur indirekt. Statt Scrum, Kanban oder anderen gängigen Praktiken in Entwicklerteams wird über die mir vorab völlig unbekannte Holokratie berichtet. Das ist eine Organisationsform für gesamte Organisationen, bei der softwareunterstützt haarklein aufgeschrieben wird welche Rollen es gibt und wie sie arbeiten, daraufhin Arbeiter gerne auch mehreren Rollen zugeordnet werden und das ganze in Kreisen von Rollen organisiert wird, bei denen es keinen klaren Chef gibt. Bilden sich Abweichungen zu den niedergeschrieben Arbeitswegen, sollen diese direkt formal aufgeschrieben werden, die Rollenbeschreibungen, welche Rollen es gibt und wer sie besetzt ändere sich dadurch ständig. Nie wirklich groß, war es wohl doch in entsprechenden Kreisen eine Mode und ein paar Firmen, die man kennt, hatten versucht sich so zu organisieren, beispielsweise Medium.

Kühl zerlegt dieses Konzept in seine Einzelteile. Durch seine Einordnung in organisationswissenschaftliche Modelle und seine Aufarbeitung, wie diese Methode am Ende wirklich gelebt wird (nicht, die informelle Ebene bildet sich immer wieder), blieb von der Holokratie am Ende zumindest bei mir kein positives Bild über. Kühl selbst positioniert sich nicht klar zu dem Konzept, dass diese Wahrnehmung nicht unbeabsichtigt ist kann ich nur mutmaßen.

Für Scrum etc gab mir Schattenorganisation keine klare Antworten, aber am Ende doch ein paar Ideen. Wenn Holokratie durch eine maßlose, detaillierte Bürokratisierung Agilität herstellen will, ist das bei Scrum mit seinen Ritualen und festen Rollen gar nicht sehr anders. Die vermeintliche agile Softwareentwicklung nach Scrum wäre also – so ausgestaltet, wie ich es erlebte – in Wirklichkeit eine stark formalisierte, eben bürokratische Methode; und eben nicht die Annäherung an die "natürliche" Entwicklungsform, die FOSS-Projekte und entwicklerbestimmte Teams ohne formalisierenden Manager im Rücken wählen würden. Und wie es dazu kommen konnte, wie auch dieser Gedankengang von Agilität durch Bürokratie bzw Formalisierung funktioniert, dafür gibt der Blick auf die Holokratie dann eben doch ein paar Einblicke.

Schattenorganisation zu lesen war also keine totale Zeitverschwendung. Angesichts meiner Fragen hätte ich aber zu einem anderen Buch greifen sollen. Ich finde es schade, dass Kühl nicht über die eine Erwähnung im Nebensatz hinaus im Buch selbst den Bogen geschlagen hat, war Holokratie doch auf dem Klappentext nichtmal erwähnt und sind Scrum sowie Kanban die Arbeitsweisen, an die das Stichwort agil direkt denken lässt. Aber vielleicht stimmt das außerhalb meiner Nische eben nicht, oder war das relevante Stichwort hier eben Management, nicht alleine agil.

Ich habe hier jetzt viel über Usability geschrieben und wer mir folgte weiß jetzt so einiges. Wir wissen, was Usability ist, können Usability von UX unterscheiden und haben Beispiele für diese Prinzipien anhand von Alltagsbeispielen gesehen. Vor einer Weile schrieb ich sogar schon über typische konkrete Hürden bei der Softwarenutzung. Aber wenn ich jetzt eine neue Anwendung bauen will, wie beachte ich dann dieses ganze Wissen und erbaue die Anwendung mit guter Usability? Die Antwort: Indem im wie auch immer gearteten Entwicklungsprozess Usability explizit berücksichtigt wird.

Eine Prozessblaupause

Es geht dabei ausdrücklich nicht darum, einen bestimmten Entwicklungsprozess vorzuschreiben. Es ist egal, ob das Wasserfall, Scrum, agile Entwicklung oder eine Mischform ist. Es gibt nur zwei Kernbedingungen, die meist hinzugefügt werden müssen: Die Nutzungsanforderungen müssen möglichst früh erhoben und die Usability der Software muss mit echten Zielgruppennutzern getestet werden.

In irgendeiner Form sollte dabei dieser modisch als Kreislauf gezeichnete Prozess abgebildet werden:

Den Kreislauf als Teil des eigentlichen Prozesses beginnt man möglichst früh und hört erst auf, wenn die Lösung sich in einer Evaluation bewährt hat. Für jeden dieser Schritte gibt es eine Menge an Werkzeugen, die üblichsten liste ich hier auf:

1. Nutzungskontext erheben

Wir erinnern uns: Den Nutzungskontext brauchen wir, weil wir Usability immer im Kontext einer bestimmten Nutzung für eine bestimmte Aufgabenerledigung betrachten. Ohne den Kontext können wir ins Blaue designen und testen, reduzieren damit aber eben erheblich die Chance für die Zielnutzung eine gute Lösung zu finden. Um den Kontext zu erheben greife ich üblicherweise auf Nutzerinterviews zurück. Was auch gehen könnte: Beobachtungen. Die sind aber meist schwer umzusetzen. Fokusgruppen wären auch denkbar, verleiten aber dazu, die tatsächliche Nutzungspraxis in der Diskussion durch Gruppendynamiken zu verdecken.

Bei Interviews ist es dann noch wichtig, tatsächlich mit Nutzern zu reden und nicht mit Leuten, die über Nutzer sprechen. Lass dir von ihnen ihre tatsächliche Praxis beschreiben. Aus den Interviews lassen sich dann die Nutzungsanforderungen ableiten.

2. Nutzeranforderungen spezifizieren

Wie das genau aussieht folgt aus dem vorherigen Schritt. Habe ich Interviews gewählt und transkribiert, leite ich aus diesen Texten Anforderungen ab und packe sie in ein Dokument. Oder man muss sich die Videos anschauen, oder die eigenen Beobachtungsnotizen durchforsten. Egal wie: Am Ende diesen Schrittes sollte eine Liste von Anforderungen an die Lösung stehen, die bei deren Entwurf zu berücksichtigen ist.

3. Lösung implementieren

Mit den Anforderungen in der Hand kann nun die Lösung gebaut werden. Je nachdem, in welchem Entwicklungsstand man ist und was man am Ende baut wird das völlig unterschiedlich aussehen. Bei Software starte ich eventuell mit einem Papier-Prototyp, oder einer Prototyp-Software. Später ist die Umsetzung schlicht Softwareentwicklung. Vielleicht aber stellt man mit den Anforderungen in der Hand fest, dass Software gar nicht die Lösung ist, sondern eine Prozessänderung oder ein Echtwelt-Artefakt bauen die beste Lösung wäre.

4. Lösung evaluieren

Am Ende des iterativen Prozess steht dieser allerwichtigste Schritt: Die Evaluierung der Lösung mittels Nutzungstests.

Dabei ist es völlig egal was gebaut wurde. Und selbst wenn alles andere ignoriert wurde: Echte Nutzungstests mit echten Nutzern bringen so viele Erkenntnisse, dass sie auf jeden Fall durchgeführt werden sollten. Dabei liegt die Betonung auf "echte". Es bringt nichts, mit Leuten zu testen die später die Lösung gar nicht benutzen sollen, beispielsweise anderen Softwareentwicklern eine neue Nähmaschine vorzusetzen. Es bringt genausowenig falsch zu testen, also nicht Nutzer die konkrete Aufgabenerledigung durchspielen zu lassen und dabei Probleme zu beobachten, sondern ihre Meinung zur Hintergrundfarbe der Titelleiste zu erfragen.

Nein, echte Nutzungstests spielen mit echten Zielgruppennutzern ihre Aufgabenerledigung nach. Dafür hat der Nutzer meist einen Testleitfaden, der die Aufgaben vorgibt. Der Tester sitzt daneben oder am anderen Ende der Telefonleitung und schaut mit auf den Bildschirm. Was ihn ausschließlich interessiert sind Momente, in denen der Nutzer irritiert ist oder nicht weiterkommt. Solche Critical Incidents (CIs) können immer auf die Verletzung von Dialogprinzipien zurückgeführt werden. Eine so generelle Aussage mag überraschen, aber die Prinzipien sind dafür wirklich ausreichend umfassend und aussagestark. Die CIs zu protokollieren und einzuordnen motiviert dann die nächste Iterationsrunde des Prozess. Mit besserem Verständnis des Nutzungskontexts bzw. der eigenen gebauten Lösung muss die nun angepasst werden, sodass die CIs beim nächsten Test nicht mehr auftreten.

Und wenn es keine CIs gab oder sie die Aufgabenerledigung nur unwesentlich behinderten? Dann sind wir mit der Usabilityarbeit fertig.

Der Prozess in der Praxis

Das oben beschriebene ist keine akademische Fingerübung. Es wird tatsächlich in der Praxis umgesetzt und es funktioniert wirklich. Klar: Niemand und kein Prozess kann garantieren, dass egal welche Hürden es gibt das Endergebnis super wird. Aber Usability mittels dieser Prozesselemente zu beachten vermeidet effektiv, am Ende Nutzern ein Produkt vorzusetzen, mit dem sie schlicht nichts anfangen können. Schon das richtige Testen alleine verhindert das. Denn wenn die Lösung nichts taugt, merkt man das in professionellen Nutzungstests zu 100%. Das Management darf diese Ergebnisse dann nur nicht ignorieren, aber das ist ein Thema für sich.

Praktisch läuft das so ab: Bei der Produktentwicklung gibt es immer ein Entwicklungsteam und Entwicklungsleiter. Dieses Team hat irgendeinen Prozess, mit dem es Lösungen entwirft und umsetzt. Diesem Prozess fügt man nun Usability-Experten hinzu. Man kann einen Usability-Experten als Consultant anheuern, eine Usability-Agentur beauftragen oder einen Usability-Experten einstellen – ob der dann Teil eines Designteam wird oder Teil des Entwicklerteams, gar ein vorheriges Entwicklungsteamitglied mit neuer Zusatzausbildung ist, ist erstmal egal.

Ich habe alle drei Lösungen in der Praxis erlebt. Meinem Eindruck nach funktioniert das Einbinden des Usability-Experten in das Softwareentwicklungsteam am besten, aber dafür muss man nunmal einen der seltenen Usabilityleute finden, die auch Softwareentwickler sind. Hier sollte ich erwähnen: Dieser mein Eindruck könnte daher kommen, dass ich eben selbst einer dieser Usability-Softwareentwickler bin. Die direkte Einbindung hat aber nunmal den Vorteil, dass in einer solchen Konstruktion die Usabilityexpertise sehr nah am Entwicklungsteam lebt und mühelos berücksichtigt werden kann. Wenn stattdessen eine externe Agentur die Usability-Analyse übernimmt, macht die ihre Arbeit und wirft schlimmstenfalls am Ende eine 300-seitiges Ergebnisdokument über den Zaun, von dem das Management nur die Zusammenfassung liest und das dann vom Entwicklerteamleiter im internen Wiki einer Unterseite als .doc angehängt wird, auf dass es keiner der praktischen Entwickler jemals auch nur aufmache. Aber vielleicht funktioniert es manchmal besser.

Egal welche Konstruktion es wird ist dies der Wunsch: Die Leute mit Usability-Expertise erheben den Nutzungskontext (wenn er noch nicht bekannt ist) und erstellen (oder ergänzen die bestehenden) Nutzungsanforderungen. Oberflächen und Funktionalität wird mit den Anforderungen vor Augen designt – prototypisch oder direkt in Zielform –, dann mit Nutzern getestet, schließlich wird auf die CIs reagiert. Und dann wird das wiederholt, wobei Kontexterhebung in späteren Iterationen meist übersprungen wird.

In irgendeiner Form muss das in jeden Entwicklungsprozess einzubauen sein. Am einfachsten ist es wohl bei echter agiler Entwicklung, bei dem die Entwickler zusammen mit den Designern je nach Prozessstand den nächsten Zeitabschnitt der anstehenden Aufgabe widmen. Also zum Beispiel nach der Entwicklung der ersten Alpha-Version im nächsten Wochensprint Nutzungstests durchführen, und im folgenden Sprint je nach Ergebnis entweder nochmal Designworkshops abhalten oder entdeckte Bugs wie Problemstellen in der Software reparieren.

Und das wärs. Usability mit all den dahinterstehenden Konzepten wird zu Prozesselementen, die Entwicklungsfirmen in den ihren einbauen können. Das zu tun verbessert ihre Produkte, vermeidet Kosten und hilft so der Firma. Nebenbei macht es die Entwicklung angenehmer: Bei Nutzungstests die Reaktionen der Nutzer mitzukriegen und Produkte daraufhin verbessern zu können, sodass Nutzer auf einmal mit ihnen gut zurechtkommen, ist auch für klassische Entwickler toll.
Usability im Entwicklungsprozess zu berücksichtigen ist eine wirklich gute Idee. Es ist wohl der einzige Weg, nicht einfach Glück haben zu müssen, sondern bei der Entwicklung einer neues Anwendung eine gute Usability gezielt herstellen zu können.

Auch wenn Usability normalerweise die Benutzbarkeit von Software meint: Man muss es wirklich nicht auf Software beschränken. Die Dialogprinzipien passen auch sehr gut zu Gegenständen, Usability als Konzept sowieso. Und bei Alltagsgegenständen finden sich viele Designprinzipien, die entweder gut angewandt werden oder eben merklich fehlen. Mein Haushalt hat ein paar schöne Beispiele. Natürliches Mapping ist eines davon.

Beispiel 1: Der Herd und das Mapping

Natürliches Mapping habe ich in dieser Artikelserie noch gar nicht erwähnt. Es ist ein Konzept, um die Funktion von Knöpfen zu vermitteln. Findet sich oft bei Software, aber ist im Haushalt schöner zu erklären. Zum Beispiel mit dem Herd. Der hat ja meistens 4 oder 5 Kochfelder, die in einem Rechteck angeordnet sind.

Wenn dann das Bedienfeld so aussieht:

Welcher Regler kontrolliert dann welches Kochfeld? Das bleibt völlig unklar. Man kann es erlernen, Symbole könnten es erklären, aber es ist nicht intuitiv direkt ersichtlich.

Wenn die Bedienknöpfe dagegen in der gleichen Logik angeordnet sind wie die Kochfelder selbst, also so:

Dann wird auf einen Blick klar, welcher Regler welches Kochfeld kontrolliert. Vorausgesetzt, man schafft es zu ignorieren, dass sich in diesem Foto des Kochfelds die Dunstabzugshaube spiegelt.
Touchscreens in der Küche mag ich eigentlich nicht, aber hier wird ihr Vorteil – der geringe Platzbedarf – effektiv genutzt.

Natürliches Mapping ist eines der wenigen universellen Instrumente, mit denen klar verständliche Oberflächen und Kontrollelemente geschaffen werden können.

Beispiel 2: Dunstabzugshaube und Designerknöpfe

Der Herd macht eine Sache richtig, die Dunstabzugshaube bei uns in der Küche ist dagegen ein Negativbeispiel. Sie hat diese Knöpfe:

Auf den ersten Blick komisch ist die Einreihung des Lichts ganz rechts. Da der Knopf etwas ganz anders macht wäre es hilfreich, wenn er sich anders anfühlte oder nicht mit den anderen drei in einer Reihe angeordnet wäre. Etwas Abstand dazwischen wäre gut. So würde die verschiedene Funktionalität getrennt werden.

Richtig seltsam aber wird es, wenn man die Knöpfe drückt:

1, 2 und 3 regelt die Stärke, das ist soweit klar. Aber statt dass es exklusive Radiobuttons sind, können sie zusammen gedrückt werden. Richtig wäre, wenn ein eingedrückter Knopf wieder hochgeht sobald der nächste gedrückt wird. Stattdessen bleibt er hier einfach in Position. Und es zählt immer der stärkste. Im Beispielbild ist also welche Stärke ausgewählt? 2, denn 1 und 2 sind beide gedrückt.

Es sei nur Stärke 3 ausgewählt. Will ich jetzt von Stärke 3 auf 1 wechseln kann ich nicht einfach auf 1 drücken, sondern muss auch auf 3 drücken um diesen Knopf zu deaktivieren. Wie umständlich!

Eine Umsetzung ohne Sinn und Verstand, bei der nur darauf geachtet wurde, dass das Bedienfeld schön symmetrisch ist. Statt Produktdesign und Usability stand visuelles Design im Fokus. Das mag ein Aspekt der Benutzererfahrung sein, aber wenn Usabilitykriterien so komplett missachtet werden ist die Gesamterfahrung trotz eines ansehnlichen Aussehens immer negativ. Diese Dunstabzugshaube hätte ich mir nie ausgesucht.

Beispiel 3: Mikrowelle und Konventionen

Unsere Mikrowelle habe ich selbst ausgesucht und ich hatte ein ziemlich simples Auswahlkriterium: Ich will sie bedienen können.

Die billigsten Mikrowellen machen das oft am besten. Sie haben einen Scheibenregler für die Stärke und einen zweiten für die Dauer. Natürliches Mapping ist da kein Thema, aber es ist schnell erlernbar und einfach zu verstehen. Stärke einstellen, Dauer einstellen – ich muss nur wissen wie lange mein Essen normalerweise braucht. Und das weiß ich, bei 900W sind die Nudeln etwa in zwei Minuten aufgewärmt. So sieht das bei unserer aus, die ich selbst gebraucht gekauft und dann in die Küche getragen habe:

Der Stärkeregler ist leicht verkompliziert wegen der Grillfunktion, aber selbst das wird durch die Symbole verständlich und die Bedienung bleibt simpel genug.

Ich hätte auch so etwas kaufen können:

Und hätte mich bei jeder Benutzung geärgert, warum ich nicht einfach und schnell Stärke und Zeit auswählen kann.

Mikrowellen sind ein Beispiel dafür, dass simple Konventionen die besten sein können. Sie sind leicht erlernbar und gute Konventionen führen zu einer effizienten Bedienung. Aber der Markt ist erstaunlich fähig, sie zu ignorieren. Um eine 200€-Mikrowelle zu verkaufen darf die ja nicht so aussehen wie die 20€-Mikrowelle vom Supermarkt, entsprechend werden Funktionen draufgepackt. Dann passen die simplen Scheibenregler nicht mehr. Ergebnis: Die Produkte werden ohne Studieren der Bedienungsanleitung unbenutzbar, jede normale Benutzung dauert länger.

Beispiel 4: Waschbecken und fehlende Aufgabenangemessenheit

Ich habe noch ein Beispiel für Verschlechterung – unser Waschbecken:

Und zwar geht es um den Stöpsel. Normalerweise – so kenne ich das – wäre hinter dem Wasserhahn ein Metallhebel, mit dem der Verschluss gesenkt oder gehoben werden kann. Es gibt aber (seit einer Weile?) auch dieses Prinzip, bei dem der Stöpsel selbst bewegt wird. Meiner Wahrnehmung nach besonders häufig in schicken Hotels, aber eben auch bei uns im Bad.

Das hat ja seinen Reiz: Anstatt dass ein völlig entferntes Bedienelement erlernt werden muss, ist das zu bewegende Teil direkt beweglich. Das ist noch besser als natürliches Mapping. Der Stöpsel vermittelt durch den Greifer in der Mitte auch direkt, dass er beweglich ist – bei Interfaces spricht man da von der Affordance. Ein Button muss die Affordance haben klickbar zu sein, der Stöpsel hier, senk- und hebbar zu sein. Die Selbstbeschreibungsfähigkeit ist dadurch gegeben, der Aspekt funktioniert.

Doch ist die Lösung völlig aufgabenunangemessen, was das wichtigere Prinzip ist. Wenn das Wachbecken voll ist, muss der Nutzer jetzt in die Drecksbrühe greifen um das Wasser ablaufen zu lassen. Der Greifer hinter dem Wachbecken mag nicht schick sein, er kann kaputt gehen und die Metallverbindung unter dem Wachbecken würde Platz kosten. Aber er ist trotzdem insgesamt die viel bessere Lösung, weil nur er die Aufgabe richtig löst: Das Wasser im Waschbecken ablassen zu können, ohne ins Wasser greifen zu müssen.

Usability betrifft unseren Alltag öfter als man vielleicht zuerst glaubt. Selbst Alltagsgegenstände können in ihrer einfachen Benutzbarkeit stark variieren. Dabei ist absolut nicht gegeben, dass teure Produkte eine bessere Usability haben.

Küchen sind da besonders anfällig, weil die Leute sie basierend auf einem Ersteindruck kaufen. Aber auf den ersten Blick werden ungeschulten Augen Usabilityprobleme selten direkt auffallen. Und dann ärgert man sich jahrelang mit schlechten Lösungen rum – zum Beispiel mit der Mikrowelle, die keiner im Haus wirklich bedienen kann. Und sucht dann im Zweifel die Schuld bei sich selbst, anstatt zu erkennen, dass die Mikrowelle einfach schlecht gemacht ist.

Da beim Kauf mehr drauf zu achten lohnt sich. Einem Produkt mit guter Usability den Vorzug zu geben kann für viele Jahre einen kleinen Aspekt des Alltags etwas angenehmer machen.

Im allgemeinen Sprachgebrauch, selbst in der Industrie, wird Usability und User-Experience oft vermischt. Da wird dann ein UX-Consultant gesucht, der für die reibungslose Nutzung sorgen soll (dabei ist das viel mehr Usability) oder es wird erwartet, dass der Usability-Experte mit einem neuen Farbschema für die Software ankommt (dabei ist das visuelles Design und mehr ein Teil von UX). Tatsächlich ergänzen sich die beiden Disziplinen, aber sie reden nicht über das gleiche und haben unterschiedliche Methoden.

Definitionen

Usability haben wir hier im Blog gerade erst ausführlich definiert. Zu UX gibt es wieder eine Norm, DIN EN ISO 9241-210. Sie ist demnach abhängig von den Reaktionen des Nutzers, seinen Emotionen, psychologischen und physiologischen Reaktionen. Das kann von allem möglichen abhängen: Ja, auch von der Usability der Software, aber auch vom visuellen Design oder mit ihr verbundenen Statusgefühlen. UX ist demnach viel breiter als Usability.

Gleichzeitig passt sie gut in das kleine Stufenmodell, das bei Usability benutzt wird. Effektivität, Effizienz und Zufriedenstellung, die aufeinander aufbauenden Softwarequalitätsebenen. Zu Zufriedenstellung hat Usability nicht viel zu sagen – zu Effektivität schon mehr, vor allem aber zur Effizienz mittels der Dialogprinzipien. UX lebt aber geradezu auf der Zufriedenstellungsebene. Auch hier muss man sich vorher mit den Grundlagen beschäftigt haben. Aber wie dann tatsächlich die Zufriedenstellung erreicht wird, das wäre in meinen Augen der Fokus von UX.

Abgrenzung

Wobei, kurz eingeschoben, das ist kein Nachteil von Usability. Es kommt mehr aus dem Umstand, dass Usability ein klares Methodenset und ein klares Ziel vor Augen hat, während die Ganzheitlichkeit der UX eben auch Beliebigkeit bedeuten kann. Eine Beliebigkeit, die auch dafür sorgen kann, dass ein vermeintlicher UX-Experte sehr wohl Usability-Arbeit macht, womöglich ohne dass er den Unterschied so wahrnimmt wie ich.

Nehmen wir als Abgrenzungsbeispiel Apple. Apple-Produkte werden oft gepriesen für ihre tolle Benutzbarkeit. Gleichzeitig finden sich unzählige Beispiele, in denen das System nicht besonders aufgabenangemessen, die Selbstbeschreibungsfähigkeit gar nicht da ist und die Erlernbarkeit auch fehlt. Natürlich gibt es schlimmere Systeme, aber Apple-Software ist doch voller Usability-Probleme. Trotzdem gibt es eine riesige Gruppe, die Apple-Produkte quasi-religiös verehrt und sie ganz toll findet. Eine Diskrepanz für Usability, da hier Zufriedenstellung von Effektivität und Effizienz abhängt und wir generell fokussiert von einer konkreten Aufgabenerledigung reden. Erklärbar mit UX, wenn dort das visuelle Design, Marketing und Statusdenken mitbeachtet wird.

Doch es geht zusammen

Usability und UX schließen sich nicht aus. In der Praxis werden die Definitionen vermischt, meine trennende Perspektive hier könnte im Laufe der Zeit von immer weniger Menschen geteilt werden. Aber aus Sicht eines Usability-Experten sind die beiden Disziplinen nicht auf der gleichen Ebene. Usability würde mit Nutzertests die effiziente Aufgabenerledigung testen wollen, die weitere Wirkung des Produkts wäre ein per Umfrage abgedeckter Nachgedanke (aber zur Methodensammlung kommen wir noch). UX dagegen würde diese Umfrage zur emotionalen Wirkung ins Zentrum stellen und dann im Zweifel darauf hinwirken, dass das visuelle Design angepasst wird.

Normalerweise versteht man unter Usability die einfache Benutzbarkeit von Software. Tatsächlich aber hat Usability eine genormte Definition nach DIN EN ISO 9241-11 und ist nach meinem Stand der Grad, zu dem ein Werkzeug in einem bestimmten Kontext bei bestimmten Nutzern eine bestimmte Aufgabe effektiv, effizient und zufriedenstellend erledigt. Da steckt ein bisschen mehr drin als bei der ersten Definition, die die meisten von uns im Kopf haben dürften.

Usability nach Norm

Erstens geht es dann nicht mehr nur um Software, sondern um jedes Werkzeug oder Produkt. Zweitens geht es nicht mehr um generelle Einfachheit, sondern um die Eignung in definierten Anwendungsfällen. Und drittens gibt es nach dieser Definition mit effektiv, effizient und zufriedenstellend Gradmesser der Usability, wobei damit konkret gemeint ist:

1. Effektiv kann das Werkzeug die Aufgabe überhaupt erledigen (viele Dinge hämmern)
2. Dabei ist es mehr oder weniger effizient (der Hammer hämmert besser als das Telefon)
3. Nach dem ganzen ist der Nutzer mehr oder weniger zufrieden, vielleicht sogar sehr, wenn der Hammer super effektiv und effizient war, minimalen Kraftaufwand braucht und gleichzeitig dem Handwerker Komplimente macht.

Bewaffnet mit dieser Definition gibt es gerade in Deutschland eine (kleine?) Industrie, die Fortbildungen anbietet und (normalerweise) Software auf diese Kriterien abklopft. Mein vorheriger Job war genau in dem Bereich – führte mich also vom breiteren Studium der Mensch-Computer-Interaktion (HCI) zurück zu sehr viel konkreterer angewandter Usability, genau was mich an HCI genug fasziniert hatte um es als Master zu wählen.

Hilfreicher: Grundlagen der Dialoggestaltung

Aber von wegen angewandt: Natürlich ist die Definition trotz allem reindefinierten viel zu abstrakt, um damit viel konkretes anzufangen. Um Software zu bewerten geht man daher einen Schritt weiter und schaut sich die Grundlagen der Dialoggestaltung (ISO 9241-110) an:

Aufgabenangemessenheit

Kann die Aufgabe angemessen erledigt werden? Ja, man kann mit Paint eine Doktorarbeit schreiben, aber der Aufwand ist unnötig hoch.

Selbstbeschreibungsfähigkeit

Ist der Zweck jedes Interfaceelements direkt ersichtlich? Typisches Problem hier sind Icons, deren Bedeutung unklar bleibt oder Buttons, die nicht wie Buttons aussehen (Flat-Design!).

Steuerbarkeit

Kann man (z.B. in einem Wizard) wieder zurückgehen?

Erwartungskonformität

Ist alles konsistent mit der Nutzungserwartung? Darüber schrieb ich hier im Blog schonmal bezüglich des prägenden Einflusses des ersten Kontakts mit einem Systems.

Fehlertoleranz

Verzeiht das System Falscheingaben des Nutzers und bewahrt ihn vor solchen?

Individualisierbarkeit

Beispiel Schriftgröße – kann das System an die Bedürfnisse des Nutzers angepasst werden? Hier geht es dann ganz schnell auch um Accessibility

Lernförderlichkeit

Kann der Nutzer die Software erlernen und hilft sie dabei? Markierungen für Tastenkürzel in Menüs gehen z.B. in die Richtung.

Das sind schon besser greifbare Kriterien, mit denen man Software auf der Effizienzebene bewerten kann und dann rausbekommt, welche Probleme sie hat.

Diese Grundlagen wurden übrigens vor kurzem überarbeitet. Unter anderem wurde laut Wiki Benutzerbindung – System ist einladend und motivierend hinzugefügt. Das ist Unsinn, weil es dem Prinzip hinter ihnen zuwider läuft, klar definierbare Eigenschaften von Dialogen auf der Effizienzebene abzudecken und stattdessen der schwer greifbaren Zufriedenstellung oder User-Experience entspricht (zur Abgrenzung von UX und Usability will ich später noch etwas schreiben). Du könntest also an anderen Stellen eine andere Definition finden, solltest die aber ignorieren. Die oben gezeigte ist die richtige.

Testbarkeit, Einstellungssache und Anwendbarkeitsprobleme

Mir ist wichtig etwas zu betonen, was bei den ganzen Definitionen vielleicht nicht direkt klar wird: Usability ist die Antithese zu RTFM. Dieses elitäre Gehabe, das zumindest vor Ubuntu im Linuxumfeld zu finden war und immer noch in einigen Bereichen zu finden sein wird, hat als Kern den Anspruch, dass bei Problemen der Nutzer schuld ist und er sich anpassen muss. Usability gibt dagegen ein Werkzeugset, mit dem man schauen kann wie Software so gebaut wird, dass zumindest die Zielnutzergruppe ihre Aufgabe gut erledigen kann. Was Anleitunglesen nur dann einschließt, wenn es die übliche Praxis der Zielgruppe ist.

Üblicherweise macht man diese Prüfung mit Nutzungstests. Da spielt das ganze "definierter Nutzer, Kontext und Aufgabe" der Usabilitydefinition mit rein. Natürlich kann auch ich mich vor eine Software setzen und gucken, welche Probleme mir auffallen – das ist sogar ein valides erstes Testmittel, mit einer Expertenevaluation finden sich viele typische Probleme. Aber dem Atomkraftwerksingenieur, der normalerweise vor der Software sitzt, dem werden noch ganz andere Dinge auffallen und wichtig sein. Wenn ich also ihn bei seiner Aufgabenerledigung beobachten kann wird viel wahrscheinlicher, dass die wichtigen Probleme auftreten und analysiert werden können.
Hier im Blog hatten wir das auch schonmal in einem schönen Beispiel bei der kleinen Kontroverse um Gimps Umbau des Speicherdialogs, denn dort war der springende Punkt, dass es eben darauf ankommt was die eigentlichen Nutzer während der echten Arbeit davon halten – wobei bei Gimp das eben sehr viele Nutzer mit unterschiedlichen Anforderungen sein können.

Man sieht da ein Problem: Usability nach Normdefinition eignet sich besser für kleinere Nutzergruppen, vor allem für Angestellte in Unternehmen. Wenn ich weiß, dass alle meine Techniker eine bestimmte alte Software beherrschten und grundsätzlich diese X Dinge über das verkaufte Produkt wissen, dann kann ich die Nachfolgesoftware gut mit denen testen. Wenn ich alle Menschen auf der Erde ansprechen will, geht all der definierte Kontext aus der Definition den Bach runter. Als Usability-Experte kann ich dann immer noch mit Tests arbeiten, Konsistenz herstellen und mir Zielnutzergruppen raussuchen, für die meine Software besonders gut funktionieren wird – aber da kommt man immer an die Grenze des machbaren, an der dann schon der kulturelle Unterschied zu groß ist um ihnen allen eine gute Usability zu bieten.
An ähnliche Probleme kommt man, wenn die Software eine schwierig zu definierende Aufgabe hat. Versuch mal, Facebook auf eine einzelne Aufgabenerledigung runterzubrechen.

Manchmal geht das dann schief und Software wird im Auftrag der Designer kaputtsimplifiziert. Etwas einfach zu halten kann helfen möglichst viele mögliche Nutzer nicht vor Probleme zu stellen, kann aber eben auch die Aufgabenerledigung für die anderen (im Zweifel: Die echten und bestehenden Nutzer) behindern. Windows 8 kann man so einordnen. Generell im Zweifel alles, wo Oberflächen für beschränkte Medienkonsumierungsgeräte wie Smartphones und Tablets auf PCs übertragen werden. Aber auch die misslungene Umstellung des Fedora-Installers von einem simplen linearen Wizard auf eine komplizierte Menüstruktur im Namen der vermeintlich zugänglichen modernen GUI schlägt in diese Kerbe

Mehr als eine Norm: Usability für alles

Gut, dass es wirklich nicht nur um Software geht und Usability mehr ist als nur unsympathisch hinter Zahlschranken versteckte DIN-Normen. Das Buch The Design of Everyday Things von Don Norman zeigt das besonders stark. Norman sammelt darin sehr viele Beispiele von Alltagsgegenständen, deren Usability schlecht ist. Tolles Beispiel sind Türen: Schonmal vor einer gestanden und nicht gewusst, ob man ziehen oder drücken muss? Auch das wird zu einer grundsätzlichen Einstellungsfrage: Die meisten Menschen fühlen sich blöd, wenn sie falsch lagen. Dabei ist es doch nicht ihr Fehler, wenn die Tür so gestaltet ist, dass ihre Bedienung unklar ist! Mit den Dialogprinzipien von oben würde man sagen: Die Selbstbeschreibungsfähigkeit war ungenügend.
Ich habe das Buch vor kurzem verliehen und als Fazit zurückbekommen, dass es anfangs sehr gut und überzeugend ist, aber nach eine Weile sich zu wiederholt. Das stimmt wohl, aber es hat auch viele gute Beispiele und bringt bis dahin Usability als Denkansatz gut rüber. Es geht über die Normen hinaus und gibt weitere Erklärungen, was gute Usability ausmacht und Beobachtungen, wie Nutzer Probleme angehen: Hilfreiche Dinge wie mentale Modelle und Seven stages of action.

Usability ist ein relativ weites Feld und HCI ist noch viel weiter. Aber gerade Usability ist faszinierend, weil es so wunderbar anwendbar und hilfreich ist. Und ich empfand immer eine große Anziehungskraft des Begriffs: Als jemand, der damals Software zu schreiben lernte wollte ich doch natürlich auch wissen, wie diese Software für gute Benutzbarkeit gestaltet zu sein hat. Auch heute ist das mein Anspruch.

Doch hier im Blog habe ich nur selten darüber geschrieben, selbst die fast allumfassende HCI-Kategorie ist relativ ungefüllt. Ich habe mir daher vorgenommen, noch etwas mehr über Usability zu schreiben. Vor allem, wie man dieses Konstrukt konkret nutzen kann um benutzbare Software zu gestalten.

Ubuntu 20.04 integriert Snaps stärker als zuvor in das Gesamtsystem. Während Ubuntu wie Debian eigentlich .debs benutzt, um Programme und Updates zu verteilen, werden jetzt mehr Teile per Snap ausgeliefert. Und das ist eigentlich eine tolle Sache: Denn Snaps sind nicht auf Ubuntu beschränkt. Sie können auch auf anderen Distributionen laufen. Zudem enthalten sie ihre Abhängigkeiten, dass Software im Laufe der Zeit auf neuen Linuxumgebungen nicht mehr startet wird dadurch gelöst oder zumindest minimiert. Zudem waren .debs nicht besonders einfach zu bauen. In der Hinsicht sind Snaps ähnlich wie Flatpaks oder das hervorragende AppImage eine gute Verbesserung. Ich bin ein Fan des Konzepts.

Aber es gibt auch Nachteile. Manche sind konzeptbedingt, andere betreffen speziell die Umsetzung von snap. Um die soll es hier gehen.

Die Problematik

Es gab jetzt in kurzer Zeit mindestens zwei populäre Artikel samt Thread auf Hacker News, die zusammen Probleme mit Snaps überzeugen vortragen. Der erste war Disabling Snaps in Ubuntu 20.04 mit dieser Diskussion, der zweite war Ubuntu 20.04 LTS’ snap obsession has snapped me off of it mit dieser.

Das Hauptproblem sind die Autoupdates. Snaps auf Ubuntu aktualisieren sich selbst. Sicherheitstechnisch begrüßenswert hat das einen Rattenschwanz von Problemen:

1. Snaps können ohne Vorwarnung und Lösung kaputtgehen. Wenn ein Snap-Ersteller ein fehlerhaftes Update veröffentlicht, bricht die Software bei all ihren Nutzern, ohne dass Nutzer das Update verhindern können.
2. Wie immer bei Autoupdates können sie im falschen Zeitpunkt auftauchen. Während einer wichtigen Präsentation beispielsweise soll der dafür genutzte Browser besser nicht updaten und dann einen Neustart einfordern. Mitten im Arbeitsflow gilt das gleiche für jede andere Software.
3. Nicht immer ist Traffic unbegrenzt verfügbar. Hänge ich am mobilen Internet, will ich wohl kaum, dass mein begrenztes Volumen von Snaps aufgefressen wird.

Diese Argumente sind für mich völlig überzeugend. Snaps, da jetzt Teil des Distribution, sollten genau wie .debs nur auf Nutzeranforderung (zu der das System eventuell aufforderte) aktualisiert werden. Leider verweigert sich das Projekt dagegen. kikoreis nennt drei Argumente pro autoupdates:

1. Browsers machen das sowieso schon.
2. Ubuntu macht das sowieso schon, seit 16.04 LTS
3. Snaps brauchen keine Rootrechte und ihre Updates sind daher weniger problematisch

Alle diese Argumente sind nicht korrekt. Browsers updaten sich selbst, aber eben nicht unter Linux – da macht das die Paketverwaltung unter Kontrolle des Nutzers. Ubuntu auf meinem Laptop im Büro hatte mich auch nach 2016 noch wegen der Updates gefragt. Und ob Updates mit oder ohne Rootrechte durchgeführt werden ändert an ihrer Problematik rein gar nichts.

Vor allem geht es am Thema vorbei: die Argumente adressieren keines der Probleme. Das Ursprungsproblem ist fehlende Konfigurierbarkeit. Um Nutzerbedürfnisse zu befriedigen und die Probleme zu lösen müssten die Autoupdates konfigurierbar sein. Sind sie es nicht, ist die Lösung ungeeignet.

In den Diskussionen kristallisieren sich weitere Probleme heraus. Eines davon finde ich beachtenswert: Ubuntu legt ~/snap an. Zwar ist klar, dass Snap ins Benutzerverzeichnis schreiben muss. Aber andere Software und auch proprietäre wie Steam ist wesentlich höflicher und versteckt sich, denn das Benutzerverzeichnis und sein Inhalt gehört dem Nutzer, der seine Organisation weitestgehend frei wählen darf. So liegt Steam unter ~/.local/share/Steam/. Genauso hätte es sich für Snap gehört.

Ubuntu hat weiterhin ein Problem mit fehlender Nutzerzentrierung

Es ist so schade, dass Canonical weiterhin seine Nutzerfeindlichkeit pflegt. Es war ja mal ganz anders: Linux for human beings wurde als Auftrag an größtmögliche Nutzerfreundlichkeit verstanden. Im Laufe der Zeit wurde daraus ein immer wieder durchschimmerndes Wir wissen es besser und eine Orientierung am unmündigsten aller Nutzer, um eigene Vorstellungen vorzugeben. Beispiel: Die Fensterverwaltungsbuttons nach links zu verschieben und damit die Nutzererwartung zu missachten wäre schon seltsam gewesen, sich dann aber sogar zu weigern die Seite grafisch konfigurierbar zu machen war einfach nur feindselig.

Genau diese Haltung bedroht jetzt auch Snaps: Denn eigentlich sind die eine gute Sache, gerade auch für Entwickler wie mich. Aber sie zu benutzen, um Zwangsupdates wie bei Windows durchzudrücken? Etwas, weswegen ein beachtlicher Teil der Linuxnutzer von Windows weggewechselt ist? Das missachtet grob Usability-Kriterien, hier vor allem die Aufgabenangemessenheit, und macht damit im Zweifel ein System für Nutzer unbenutzbar. Und das, obwohl Ubuntu 20.04 selbst wohl ein ziemlich gutes Release geworden ist.

Es erzeugt zudem völlig unnötigerweise einen Konflikt zwischen den Nutzern und den Machern des Systems.

Canonical hat gezeigt, dass sie es besser können. Die Fensterverwaltungsbuttonsseite war irgendwann wieder offiziell konfigurierbar, dann war auch die Standardeinstellung wieder korrekt. Aus Unity wurde mit solchen Verbesserungen im Laufe der Zeit eine gute Desktopumgebung, sodass als Ubuntu schließlich aufgab und zu Gnome wechselte dies bedauerlich war. Ich hoffe, dass die Organisation immer noch die Vernunft und die Kraft hat, auf die Kritik richtig zu reagieren. Dass Snaps konfigurierbar gemacht werden, wieder ultimativ der Nutzer sein System seinen Anforderungen entsprechend verwalten kann. Das wäre erfüllt, sobald Autoupdates optional werden und der sichtbare Snapordner verschwindet. Gut wäre es auch, wenn problemlos alte Snapversionen zurückgespielt werden können.

Weil das System zu oft zurückspringt, dabei nicht konsistent ist und dem Nutzer nicht genug Steuerungsmöglichkeiten gibt. In Usability-Sprech: Das Prinzip der Steuerbarkeit und der Erwartungskonformität ist verletzt, so stark, dass die Aufgabenangemessenheit gefährdet ist. Ein Nachtrag mit Beispielvideos zu meiner Besprechung vom letzten Jahr.

Smartwatches zeigen die Uhrzeit, können aber noch viel mehr. Dafür startet man zumindest bei Google auch mit ihnen Apps, wie bei Telefonen. Aber bei den Uhren wird nach wenigen Sekunden der Bildschirm wieder dunkler. Und dann können zwei verschiedene Dinge passieren:

1. Manche Apps schalten in einen Ambiance-Modus. Sie werde farblos, um die Batterie zu schonen, aber sie bleiben aktiv:

2. Andere unterstützen diesen Modus nicht. Sie schließen sich ganz, es geht zurück zum Startbildschirm. Das ist ungeheuer nervig.

Vor allem, weil die große Frage dann ist: Wie kommt der Nutzer wieder zu der App zurück, die er eben noch nutzen wollte? Antwort: Er weiß es nicht.

Manchmal reicht es, den Bildschirm der Uhr wieder zu berühren. Dann wird er wieder hell und die App erscheint:

Aber das funktioniert nicht immer. Oft genug – je nach Speicherverwaltung? Wartezeit? – bleibt WearOS dann bei der Uhrzeitanzeige stehen:

Das passiert auch dann, wenn der Nutzer per Knopfdruck zur Uhrzeitanzeige gewechselt ist. Kein Berühren des Bildschirms und keiner der beiden Knöpfe führt dann zur vorher geöffneten App zurück:

Was man hier auch schön sieht: Wie viele meiner Wischgesten ignoriert werden. Auch das macht die Benutzung der Uhr frustrierend.

Die Bedienung der Uhr leidet schon unter anderen Erschwernissen. Die Oberfläche stockt gerne mal, der Bildschirm ist klein, damit auch die Bedienfläche. Das ist aber nicht das Hauptproblem: Es macht es nur noch unangenehmer, immer wieder in das Menü gehen und Apps neustarten zu müssen. Das eigentliche Problem ist die fehlende Task/App/Fensterverwaltung im Bedienkonzept. Das erinnert mich ein bisschen an die Anfangszeit von Android auf den Smartphones, als es ebenfalls genau in dieser Disziplin schwächelte und das später kopierte webOS zeigte, wie es richtig geht. Bei Smartwatches muss diese Inspiration wohl noch gefunden werden.

Teil meiner derzeitigen Arbeit ist es, Software zu testen. Weniger, ob sie funktioniert, sondern ob Nutzer mit ihr zurechtkommen. Wenn ein Unternehmen eine neue Lagerverwaltungssoftware einführt könnte es uns beauftragen, zu testen ob die Angestellten im Lager mit dieser Software zurechtkommen. Oft geschieht das dann mit einem Nutzertest, in dem die Testnutzer mehrere typische Aufgaben zu erledigen versuchen.

Wenn die Aufgabe nicht erledigt werden kann, woran scheitern die Leute? Eigentlich nie an sich selbst, der Fehler liegt fast immer bei der Software. Und viele Probleme sind typisch, sie finden sich immer wieder. Hier ist eine Auswahl:

1. Flat Design

Ist dieser Designtrend nicht längst vorbei? Doch trotzdem sehe ich es noch, und alle damit verbundenen Probleme. Das Problem ist das Weglassen von Tiefeninformationen – Flatness eben. Wird das schlecht umgesetzt, sehen Buttons nicht mehr wie Buttons aus, sondern es werden einfach die Symbole, die sonst in den Buttons wären, auf der Oberfläche verteilt.

Doch ein Symbol hat keine Affordance. Ein Button schon. Sieht ein Nutzer einen Button weiß er: Da kann ich draufklicken! Er weiß nicht unbedingt was der Button dann bewirken wird, aber zumindest die Bedienung ist klar. Bei schlecht umgesetztem Flat Design ist nicht klar, welche Symbole angeklickt werden können. Effekt: Der Nutzer sitzt ratlos vor dem Bildschirm und weiß nicht was er tun soll.

Diese Kritik ist so alt wie der Designtrend selbst. Doch sie ist nicht theoretisch, sondern vielfach beobachtete Realität.

2. WTF-Momente

Stell dir vor, du willst ein Bild des Firefox-Logos speichern. Du gehst auf die Webseite, rechtsklickst, wählst Speichern unter, vergibst einen Namen und drückst auf Speichern. Doch mitnichten: Stattdessen taucht eine Meldung auf, "Der Dateiname muss mit Bild oder Textdatei beginnen." Absurd? Ja, ein echter WTF-Moment. In einer ähnlichen Situation innerhalb der getesteten Software weigerten sich die Testnutzer, der Meldung glauben zu schenken. Sie wurde gelesen und ignoriert und nach einer anderen Möglichkeit gesucht, das Element zu speichern. Bis wir eingriffen und erklärten, dass der Meldung wirklich gefolgt werden muss.

Die Nutzer konnten Deutsch, sie hätten die Meldung verstehen können. Aber ihr Inhalt war so abstrus, dass die Nutzer sie instinktiv ignorierten. Bewegt sich Software so völlig außerhalb des Erwartbaren, hören Nutzer auf zu denken und verweigern die Kooperation.

3. Falsche Führung

Eine Liste mit wichtigen Messwerten, ein neuer Wert soll eingetragen werden. Das ist nicht ganz einfach: Ein per Flat Design versteckter Hinzufügen-Knopf am äußersten Rand muss gefunden werden. Was ist einfacher? Einen Listeneintrag anklicken. Wodurch ein neues Formular aufgeht, in dem ein Wert eintragbar ist, der dann aber den alten Messwert überschreibt. Völlig ohne Warnung.

Die Firma hätte massenhaft an Daten verloren. Da die falsche Interaktion einfach war, und die richtige schwieriger.

4. Fehlende Führung

Problematisch ist auch, wenn einfach nicht klar ist wie die Aufgabe zu erledigen ist. Das passiert gerne bei Software, die im Grunde eine Aneinanderreihung von Formularen ist, aber auch wenn etwas erschaffen werden kann. Wie fange ich an? Wo muss ich hin? Besonders wenn die Oberfläche sowieso schon kompliziert ist sollte zumindest das deutlich sein.

5. Einklappbare Elemente

Das verbindet sich manchmal mit Flat Design, ist aber auch ansonsten problematisch. UI-Elemente wegklappen zu können funktioniert nicht. Bei Zusatzinformationen noch angemessen, gibt es manchmal Interfaces, in denen ganze Abschnitte ein- und ausgeklappt werden können. Spart Platz und macht die Software anpassbarer, aber die Orientierung gerade am Anfang sehr viel schwieriger.

6. Text als Eingabewidget

Ich meine damit diese Formulare, in denen die Eingabefelder als Text angezeigt werden, erst bei Hovern und Anklicken werden sie transformiert. Sehr verwirrend, weil nicht klar wird welche Texte Eingabefelder und welche einfach nur Labels sind. Die Affordances werden verschluckt. Dann muss einzeln gelernt werden, wie das Formular aufgebaut ist, anstatt es auf einen Blick erkennen zu können.

7. Und besonders: Falsche Benennung

Das ist das wirklich große Problem: Nicht die Sprache der Nutzer sprechen. Wenn ich in einer Bahnapp meine Bahntickets suche, schaue ich unter Tickets. Nicht unter Ressourcenbelegungen. Gerade wenn schon bestehende Software abgelöst werden soll oder wenn es feststehende Begrifflichkeiten gibt macht die falsche Sprache die Nutzung von Software sehr schwierig. Das geht dann so weit, dass in manche Programmpunkte nicht hineingeschaut wird, weil es so falsch benannt ist, dass es in den Augen der Nutzer etwas ganz anderes sein muss. Ich würde ja auch nicht unter Kalender nach meinen gekaufen Bahntickets suchen.

Wie gesagt, nur ein Auszug. Es gibt noch eine Reihe typischer Probleme mehr – nicht zurückgehen können zum Beispiel, Übergänge nicht anzeigen, aber auch wenn Software schlicht zu langsam ist. Für mich war es interessant zu sehen wie die Probleme sich ähneln und wie verdammt effektiv es ist, in relativ einfachen Tests echte Nutzer vor die Software zu setzen. Alle diese Benutzungsprobleme lassen sich dann finden. Man muss nur vorher herausfinden, welche Aufgabe mithilfe der Software erledigt werden soll.

Ich kannte die Anwendung theoretisch schon, hatte sie aber nie in der Praxis benutzt. Gestern wurde ich in einem Workshop dazu gezwungen und fand die App ziemlich nett. Mit POP (was dann wohl von Marvel aufgekauft wurde) kann man auf dem Handy simple Prototypen bauen. Viel besser, man kann seine Papierprototypen abfotografieren und dann klickbare Bereiche definieren, die zu den anderen Screens führen.

Unser Testfall war ein Online-Supermarkt. Simpel an sich, aber wir hatten in kurzer Zeit eine ganze Reihe von Nutzungsanforderungen abzudecken. So wurde zum einen schnell klar, wie hilfreich es ist das auf Papier zu machen. In einem zweiten Schritt wurde aber auch deutlich, dass es sehr viel überzeugender wirkt diese Papierzeichnungen dann in POP zu verlinken. Das hilft sehr beim Erklären.

Nett auch, dass eine teilbare URL bei rauskommt. Um den Prototyp vom Android-Smartphone auf das an den Präsentierlaptop angeschlossene iPhone zu kriegen brauchte es nur eine SMS.

Ein einziges Projekt pro Nutzer ist leider zu wenig, um die Software mit dem freien Account für mehr als einen kurzen Test zu nutzen.

Gibt es eigentlich irgendeine freie und unter Linux lauffähige Prototyp/Wireframe-Anwendung?

Die Nachbarhälfte der Abteilung hat eine für meine Ohren ziemlich nett klingende kleine Konferenz organisiert:

Uns erwarten Autos, die Entscheidungen treffen, und Roboter, die uns versorgen. Autonome Systeme sind keine bloßen Werkzeuge mehr. Usability zu fordern, greift zu kurz: Wir müssen vielmehr dafür sorgen, dass autonome Systeme uns als fühlenden und sozialen Wesen gerecht werden. Nicht nur gebrauchstauglich, sondern menschentauglich müssen sie sein. Durch diese Brille möchten wir mit Ihnen in unsere technologische und menschliche Zukunft blicken.

Ich denke, dass bei diesen Themen freie Software eine wichtige Rolle spielen wird. Denn wie sonst können wir menschentaugliche Software schaffen? Gleichzeitig sind wahrscheinlich einige Interessierte an freie Software auch generell an Technikzukunft interessiert, daher erlaube ich mir hier diesen Hinweis.

12. April, bei Bonn, 245€ Teilnahmegebühr. Mehr im Flyer.

The goal is to catch users before they abandon the site, to show them something they may have missed, or to provide one final appeal to capture their attention. And, according to the logic of exit popups, who cares if this appeal doesn’t work and users are annoyed? There’s nothing to lose, because they’re leaving anyway, right?

Wrong. When users engage in page parking, they systematically move between opened tabs, saving their place to return later. The code behind exit popups doesn’t know if a user is moving the mouse to:

• close the tab,
• temporarily move to another tab, or
• open a new tab.

Nielsen über Exit-Popups.

Übrigens einer der Nerv-Faktoren der von mir sonst geschätzten Zeit.de.

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.