UI abschleifen
(blog.jim-nielsen.com)- Die Qualität einer UI steigt nicht direkt nach der Implementierung, sondern durch den tatsächlichen wiederholten Prozess des ständigen Durchklickens; der Artikel vergleicht das mit dem Schleifen im Holzhandwerk
- Seitenwechsel und Navigation sollten über mehrere Einstiegspfade geprüft werden, etwa per Klick, Zurück-Button des Browsers, Rechtsklick „Back“, Zurück-Navigation in der App und Tastenkürzel
- Als
labelundinput type="radio"mit flexbox ausgerichtet und mitgapversehen wurden, zeigte sich der Bereich zwischen Radio-Button und Label als Dead Zone, in der Klicks nicht reagieren - Die Lösung bestand darin,
gapzu entfernen und demlabelPadding zu geben; der visuelle Abstand blieb erhalten, während die klickbare Fläche größer wurde - Auch kleine Interaktionsmängel können sich summieren und die User Experience beeinträchtigen; deshalb sollte man die UI wiederholt benutzen und sie verfeinern, bis keine „Splitter“ mehr spürbar sind
Durch wiederholtes Klicken raue Stellen in der UI finden
- UI-Arbeit ähnelt einem Kreislauf: etwas bauen, viel klicken, ändern und dann wieder klicken
- Bei Seitenwechseln reicht es nicht, nur einen Ablauf zu prüfen; man sollte auf verschiedene Arten zurückgehen und sie untersuchen
- Nach dem Klick den Zurück-Button des Browsers verwenden
- Nach dem Klick im Rechtsklick-Kontextmenü „Back“ verwenden
- Die Zurück-Navigation innerhalb der App verwenden
- Per Tastenkürzel zurückgehen
- Dieser Prozess ähnelt zwar dem QA-Ansatz, „durch Klicken etwas kaputtzumachen“, fühlt sich aber eher an wie das Schleifen mit Sandpapier im Holzhandwerk, bei dem man raue Stellen und Splitter aufspürt
- Da Software-UIs sehr viele Zustände und Variablen haben können, verfeinert man sie durch wiederholte Nutzung, bis keine „Splitter“ mehr spürbar sind
Die durch flexbox-gap entstandene Klick-Dead-Zone
- In einer Liste von Radio-Optionen wurden ein mit
<label>verknüpftes<input type="radio">in derselben Zeile platziert - Das CSS war eine einfache Struktur mit
display: flex,flex-direction: row,align-items: centerundgap: .5remauf dem Container - Beim wiederholten Klicken wurde entdeckt, dass das Control nicht umschaltet, wenn man auf den Bereich zwischen Radio-Button und Label klickt — ein Dead Spot
- Ursache war
gapin flexboxgapmacht visuelle Abstände einfach- wird aber nicht Teil der klickbaren Fläche des Labels oder Eingabeelements und erzeugt so eine leere Interaktionsfläche
- Die Lösung bestand darin,
gapzu entfernen und demlabelPadding zu geben- Der Abstand bleibt erhalten
- Die klickbare Fläche des Labels wird größer, sodass die Dead Zone verschwindet
- Ein einzelner kleiner Mangel wirkt vielleicht unbedeutend, doch wenn sich viele solcher „kleinen Splitter“ ansammeln, kann die UI-Erfahrung schmerzhaft werden
1 Kommentare
Hacker-News-Kommentare
Wenn ein Entwickler auch ein intensiver Nutzer des Produkts ist, das er baut, ist das ein großer Vorteil, um solche kleinen Probleme zu finden.
Denn dann bemerkt der Entwickler kleine Reibungen selbst, bevor Nutzer darüber stolpern, und sitzt zugleich direkt an der Stelle, an der sie behoben werden können.
Deshalb scheinen kleine Teams mit starkem Ownership-Gefühl effektiv zu sein. Wenn man ein Gefühl von Eigentümerschaft für das Produkt hat, fühlen sich selbst kleine Unannehmlichkeiten der Nutzer wie die eigene Angelegenheit an, und die UX so reibungslos wie möglich zu machen wird zu einer Frage des eigenen Stolzes.
Außer bei Fällen wie Enterprise-Produkten, die intern schwer zu verwenden sind, entsteht selbst dann, wenn die direkte Eigentümerschaft schwächer ist, zumindest ein Eigeninteresse am Erfolg des Produkts.
Ich frage mich, was die am besten polierte UI ist.
Bei FAANG würde man wegen des vielen Geldes eine ziemlich gute UI/UX erwarten, aber wer Amazon.com, AWS, GCP oder Azure benutzt hat, dürfte das anders sehen.
Ich persönlich halte mcmaster.com für die am besten polierte UI/UX. Man findet dort in wenigen Minuten, was man braucht.
Auf den Websites großer Handelsketten wie Home Depot oder Lowe’s dagegen braucht man 10 bis 15 Minuten, um etwa Schrauben oder Holz in der exakt richtigen Größe zu finden, und auf Mobilgeräten ist es noch schlimmer.
Unglaublich schlicht und praktisch, aber dennoch ziemlich leistungsfähig. Man kann Teile schrittweise eingrenzen oder suchen, Preisvergleiche passieren automatisch, und die Kategorien für Preis/Qualität sind sinnvoll gruppiert.
Wenn man eine Teilenummer findet, sieht man Baujahr/Hersteller/Modell-Kompatibilität, eine kurze Beschreibung, Fotos und sogar, ob sie aus demselben Lager verschickt wird wie andere Teile im Warenkorb. Das alles funktioniert auf einer einzigen Seite ohne Reibung und auf jeder Plattform sehr schnell.
Es reagiert extrem schnell, und ich habe bei der Nutzung nie einen Bug gesehen. Es hat meine Erwartungen daran, was mit einer Web-App möglich ist, höher gesetzt.
Es gab dort sogar eine eigene Phase, in der nur Usability-Probleme behoben wurden.
https://linear.app/changelog/2022-12-01-polishing-season-202...
https://web.archive.org/web/20231003205004/https://linear.ap...
Besonders temporäre Profilbilder sind extrem nervig. Seit fast einem Jahr funktionieren sie nicht richtig und wechseln nicht auf das ursprüngliche Bild zurück.
Dort scheint niemand mehr etwas zu polieren.
https://littlebigdetails.com ist genau so ein Ort.
Die grundlegende Lösung für dieses konkrete Problem ist, das Eingabeelement in das Label zu setzen.
Ich habe mich gefragt, warum, und vermute, dass sich Themes so einfacher anwenden lassen, wenn man Positionierung/Padding von Label oder Eingabeelement anpassen will.
[1] https://getbootstrap.com/docs/5.3/forms/checks-radios/
for-/id-Attribute nötig: https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...Bei Radio-Buttons oder Checkboxen sollte nicht nur das Kästchen samt Padding umschaltbar sein, sondern das komplette Text-Label anklickbar sein.
Flexbox wirkt etwas übertrieben. Auch mit nicht verschachtelter Syntax würde es inline angeordnet sein, und man müsste meiner Meinung nach nur auf dieselbe Weise Padding hinzufügen.
Zur Abschwächung sollte man
Fooin ein separates Element kapseln.So etwas ist in Agile viel zu sehr verloren gegangen
Ingenieure müssten Zeit haben, ein Produkt zu verfeinern, aber in der Praxis gibt es sie nicht. Wenn QA nicht wegen eines Abstandsproblems ein Ticket erstellt, wird es niemals behoben
Kunden bemerken so etwas wahrscheinlich, aber dass sie es melden, ist schon ein Wunder, dass daraus am Ende ein Ticket wird, ist ein weiteres Wunder, und dass es dann jemand priorisiert und behebt, ist noch einmal ein Wunder
In den meisten Firmen sind die Issue-Boards aus Kundensicht tatsächlich viel zu intransparent, sodass es nervt, wenn man ein kleines Problem oder einen Bug entdeckt und dann 50 Stunden hin und her investieren muss, nur um zu beweisen, dass es ein Bug ist, und ein Ticket im Tracker anzulegen
Glaubst du, das Wasserfallmodell hätte ausdrücklich Zeit zum Testen und Verfeinern von UI gegeben?
Das ist normalerweise ein Prozess, bei dem der Produktmanager priorisiert und man es zusammen mit fähigen UX-Ingenieuren oder Designern bearbeitet. Wenn man will, kann man diese Priorität in jede Entwicklungsmethodik aufnehmen, daher ist Agile hier irrelevant
Ich habe das in den letzten drei Jahren mehrfach gemeldet. Das Bearbeiten von Text beim Schreiben ist dadurch extrem schwierig und frustrierend
Als Webentwickler frage ich mich, wie so etwas überhaupt kaputtgehen konnte. Ich weiß nicht, welches Maß an Inkompetenz nötig ist, um etwas zu zerstören, das standardmäßig funktioniert. Es wäre ein Fix von kaum mehr als 30 Minuten und würde die User Experience für alle um das Tausendfache verbessern, aber selbst drei Jahre nach der Meldung ist es immer noch unverändert
Ich habe auch in Teams über Microsoft Premiere Support einen Bug gemeldet, bei dem man im Eingabefeld für Telefonnummern die HOME/END-Tasten nicht verwenden kann, und die Antwort war: „Works as designed“
Es überrascht nicht, dass Kunden solche Bugs nicht mehr melden. Weder Mitarbeiter/Entwickler noch das Unternehmen kümmern sich am Ende darum
Ich bin Lead-Entwickler eines Produkts, und überall gibt es kleine Probleme. Für manches trage ich Verantwortung, aber ich habe nicht die Befugnis, es zu beheben — das kann sich unmöglich gut anfühlen
Aus Geschäftssicht lautet die Logik: Wenn es Umsatz oder Marke nicht schadet, warum sollte man Zeit und Geld investieren, um es zu beheben? Langfristig wird es zwar die Marke beeinflussen, aber die meisten wechseln ohnehin innerhalb von fünf Jahren die Rolle oder das Unternehmen, also kümmert es sie nicht
Schon überhaupt eine Antwort zu bekommen, ist noch der bessere Fall
Es gibt offensichtlich einen Prozess, der die Bedürfnisse der Kunden nicht erfüllt, also sollte man ihn mit dem Team beheben
Wenn es Scrum-Rituale gibt, kann man es in der Retrospektive ansprechen, aber eigentlich geht das jederzeit. Die Retrospektive ist nur ein bewusst angesetzter Moment, um auf die letzten Wochen zurückzublicken; was man unterwegs bemerkt, sollte man auch unterwegs zu lösen versuchen
Es ist wirklich wichtig, dass es Menschen mit dem Gespür gibt, kleine UX-Probleme zu melden und zu beheben
Im UX-Design vergleicht man so etwas oft mit Papierschnitten, die dem Nutzer passieren. Nicht fatal, aber sie nagen an der Zufriedenheit der Nutzer
Um dem Autor noch etwas hinzuzufügen: Dieser Radio-Button folgt nicht der Konvention, im ausgewählten Zustand einen Punkt statt eines Häkchens zu verwenden. Nutzer könnten auf den ersten Blick missverstehen, dass mehrere Auswahlmöglichkeiten erlaubt sind oder dass man auch gar nichts auswählen muss
Das ist wahrscheinlich eine Nebenwirkung der Funktion, dass es sich schließt, wenn man außerhalb klickt
Wenn es auf der negativen Seite „Papercuts“ gibt, dann gibt es auf der positiven Seite Juice, das kürzlich auch auf HN thematisiert wurde
Dieser Beitrag zeigt gut, warum ich UI-Programmierung hasse
Die unvorhersehbaren und auf triviale Weise schieflaufenden Dinge übersteigen meine Geduld. Mir macht es bis zu einem gewissen Grad sogar Spaß, darüber nachzudenken, wie etwas scheitern könnte, und Tests dafür zu schreiben, aber einfach wahllos herumzuklicken, um zu sehen, ob etwas kaputtgeht, ist zerstreuend und nervig
Ich frage mich, ob die Implementierung von UI inhärent so komplex ist oder ob wir einfach noch nicht das richtige Programmiermodell gefunden haben. Ist es manchmal vielleicht unreasonable, zu erwarten, dass etwas von Anfang an so aussieht und funktioniert, wie es beabsichtigt war?
Das Feintuning einer UI muss man nur machen, wenn man eine Komponente zum ersten Mal erstellt. Manchmal muss man Komponenten anders kombinieren oder eine einmalige Implementierung bauen
Ehrlich gesagt dauert es nicht so lange, wenn man weiß, was man tut. Gute Design Engineers sind Spezialisten für genau diese Rolle
Es gibt viel zu viele Freiheitsgrade, und Basiselemente wie Formularelemente sollten eigentlich schon mit den Defaults gut funktionieren
Es gibt bereits gute Möglichkeiten, UI im Code auszudrücken. Das Problem ist das Nullsummenspiel auf der Business-Seite. Cross-Platform-UI ist zu teuer, wenn man es nicht mit dem abscheulichsten UI-Stack überhaupt macht: HTML/CSS/JS
Aber die Webplattform ist für Dokumente ganz okay, für Apps stimmt jedoch das Abstraktionsniveau nicht. Deshalb wird Web-UI jedes Jahr mit neuen, leaky Abstraktionen neu erfunden
Schon allein mitzuhalten ist viel zu viel Arbeit
Ähnlich ist es auch in anderen Bereichen. Wenn es keine einfache Möglichkeit gibt, Requests zu senden oder Parameter in Queries einzufügen, erfinden Leute unter natürlichem Druck alle möglichen halbgaren Methoden, selbst wenn sie eigentlich vorsichtig sein wollen
Die Webplattform ist bei Grafik State of the Art, aber als UI wirklich miserabel. Trotzdem will das niemand zugeben und ändern. Die Leute vertrauen nur auf den ersten Teil, und das Legacy-Erbe und die Komplexität der Browser verhindern Veränderungen. Wenn man es als Bibliothek baut, ist es kein „Standard“, also kümmert es niemanden
Manche UIs verwenden übrigens auch quadratische Kästchen für Radio-Buttons
Es gibt hervorgehobene Buttons, die sich mit der Enter-Taste nicht aktivieren lassen
Und manchmal verbergen sich hinter drei verschiedenen Symbolen — Auslassungspunkten, Hamburger und Kebab — jeweils Menüs
Die Qualitätsunterschiede sind enorm. Menschen, die UI verfeinern, sind wirklich etwas, wofür man dankbar sein sollte
Sogar Apple macht das so :(
Ich verstehe nicht, warum die Variante, Eingabeelemente in ein Label zu legen, nicht beliebt ist
Damit verschwindet das Problem doch komplett, und man muss auch keine eindeutige
idfürforerzeugenEs ist nur so, dass es offenbar noch einige Hilfstechnologien gibt, die neue gültige Standardmuster noch nicht interpretieren können, weshalb es als Best Practice gilt, den Standard aus der Bronzezeit einzuhalten [1]
Andere Frameworks machen es vermutlich ähnlich. Wenn man diese beiden Eingabefelder in ein
label-Element einpackt, ist es kein gültiges HTML mehrBei Radio-Buttons ist das kein Problem, aber manche haben das wohl erlebt und machen es dann „zur Sicherheit“ so. Ein bisschen wie Semikolons am Ende von JavaScript-Zeilen. Fast nie nötig, aber weil man nicht genau weiß, wann es doch nötig ist, setzt man sie einfach überall
Für typische Anwendungsfälle mit Checkboxen/Radio-Buttons ist die Schreibweise auch viel sauberer
Man umschließt das Eingabeelement mit dem Label, und wenn man den Text stylen will, steckt man ihn in ein
span. Man kannlabelaufdisplay:flexsetzen und die Textposition ebenfalls so steuernBei Bug Bashes nutzen wir diese Methode, und dabei kommen viel mehr Tickets heraus als bei der Person, die Testfallkombinationen als mehrdimensionale kartesische Produktmatrix erstellt
Solche Testfälle als Ausgangspunkt zu kennen, ist gut, aber um kleine Probleme zu finden, ist zufälliges Testen geplanten Tests sehr schnell überlegen
Geplante Tests bleiben meist auf dem Happy Path oder bei erwarteten Fehlern. Diese Art des Polierens findet Randfall-Bugs viel schneller
Dabei finde ich immer Probleme oder kleine Verbesserungsmöglichkeiten. Dinge, die bei geplanten Tests in der Praxis kaum herausgekommen wären
Ich poliere meine persönliche Website (https://dustinbrett.com) nun seit fast 4 Jahren, und es fühlt sich an, als könnte das ewig weitergehen
Zum Glück macht mir die Arbeit daran Spaß
Hoffentlich alles :-)
Bei „Desktop-OS auf einer Webseite“ habe ich meistens das Gefühl, dass sie halb fertig sind, und ehrlich gesagt kommt mir das inzwischen auch zu oft vor, aber dieses hier ist im Gegenteil sehr solide und sauber poliert
Wirklich gut gemacht und inspirierend. Auch darüber nachzudenken, wie alles umgesetzt wurde, macht ziemlich viel Freude
Nämlich den Wunsch, auf dem Handy ein fensterbasiertes OS zu benutzen
Wenn ich eine fehlende Sache nennen müsste, dann dass man im Explorer mouse4/mouse5 nicht verwenden kann. „Polieren“ kann wirklich ewig weitergehen