it-swarm.com.de

Feature Exposure vs. UI Blähungen

Bei der Entwicklung meiner Webanwendungen habe ich normalerweise ein Symbol/eine Schaltfläche pro Merkmal/Funktion und platziere es so, dass es leicht zugänglich ist, ohne den Benutzer während seiner normalen Arbeit abzulenken. Ich habe jedoch häufig Konfrontationen mit einem Teil des Managements, weil sie der Meinung sind, dass bestimmte Schaltflächen an mehreren Stellen angebracht und so gut wie möglich sichtbar sein sollten.

Wie sehen Sie das? Sollten Schaltflächen/Funktionen im selben Kontext einen Ort haben, an dem der Benutzer immer danach suchen sollte (mein Ansatz), oder sollten Schaltflächen an allen Stellen dupliziert werden, an denen der Benutzer sie möglicherweise benötigt (Ansatz des Managements).

Beispiele:
- Setzen Sie eine weitere Schaltfläche edit direkt neben die Registerkarten eines Konfigurationsbildschirms, um zum Bearbeitungsmodus der App zu gelangen, da sich die Option edit in einem Symbolleistenmenü befindet und nicht sofort sichtbar
- Setzen Sie eine save-Schaltfläche über nd unter eine textarea, da der Benutzer möglicherweise die Eingabe beendet (unteres save ist nah ) oder beenden Sie das Lesen der Vorschau (oberes save ist geschlossen)

Unsere Argumentation hinter der Debatte:

mein Ansatz:
+ schickes Design
+ Nicht verwendete Symbole bleiben verborgen
+ Struktur
- Benutzer, die zuvor nicht mit der Software vertraut waren, müssen möglicherweise die Funktionen/die Suche nachschlagen

management-Ansatz
+ Funktionen sind dort sichtbar, wo sie benötigt werden
- redundante UI-Komponenten für die gleiche Funktion
- unorganisiertes Erscheinungsbild
- UI aufblähen

Ich denke, dass die Argumentation voreingenommen zu sein scheint, aber deshalb frage ich. Welcher Ansatz führt zu einer besseren Benutzeroberfläche?

6
Mike

Das Duplizieren von Aktionen ist nicht immer schlecht meiner Meinung nach. Vor allem nicht, wenn sie aus Anwendersicht nicht exakt gleich sind.

Ich denke am Ende gibt es keinen Weg für alles zu folgen. Es wird nicht so oft wie möglich dupliziert. Schauen Sie sich den vorliegenden Fall an und entscheiden Sie, was der Benutzer hier denken könnte, was sein übliches Muster ist, was er tun würde, wenn es keine Anwendung, sondern eine Papiersache wäre, wie er denken würde. Entscheiden Sie auf dieser Grundlage, wo Sie welche Aktionen ausführen möchten.


Gehen Sie auf Ihr erstes Beispiel ein:

Platzieren Sie eine weitere Schaltfläche edit direkt neben den Registerkarten eines Konfigurationsbildschirms, um zum Bearbeitungsmodus der App zu gelangen, da sich die Option edit in einem Symbolleistenmenü befindet und nicht sofort sichtbar ist

Ich denke, das sagen Sie:

tabs with an edit-mode

Wenn ja, haben die beiden Aktionen für den Benutzer unterschiedliche Bedeutungen. Der erste 'Bearbeitungsmodus' versetzt sie in einen redaktionellen/redaktionellen Modus (auch in ihren eigenen Gedanken) und macht alles bearbeitbar. Die zweite Option "Diese Einstellungen ändern" funktioniert nur auf dieser Seite.


Ihr zweites Beispiel:

Setzen Sie eine save -Button über nd unter ein textarea, da der Benutzer entweder die Eingabe beenden könnte (unteres save ist nahe) oder das Lesen der Vorschau beendet (oberes save ist nah)

Ich hatte in letzter Zeit eine ähnliche Situation:

CMS edit form with two save buttons

In diesem Fall bietet die erste Schaltfläche zum Speichern eine schnelle Möglichkeit, Änderungen vorzunehmen. Ein [Bearbeiten - etwas ändern - Speichern] ist einfach und der Benutzer muss nicht das gesamte Formular nach unten scrollen. Und wenn der Benutzer die erweiterten Optionen festlegen muss, kann er einfach dem Formular folgen und unten speichern.

(Man kann argumentieren, die erweiterten Einstellungen unter einen Link über der ersten Schaltfläche zum Speichern zu setzen und sie beim Klicken auf den Link ausklappen zu lassen. Dies ist jedoch nicht immer erwünscht.)

7
Lode

Wer sagt, dass Redundanz immer schlecht ist? Es ist üblich, Menüs, Symbolleisten und Tastaturkürzel zu haben, die alle dasselbe tun. Wenn die Duplikate nicht jeweils etwas hinzufügen (dh sie sind wirklich vollständig redundant), , dann ist es Zeit, etwas zu entfernen, aber es sind möglicherweise nicht die Bits du denkst zuerst.

In Google Mail ist reply über und unter einer Nachricht verfügbar, da der Benutzer wahrscheinlich entweder nach oben oder unten gescrollt hat die Seite, was es schwierig macht, eine Schaltfläche am anderen Ende zu finden. Dieses Problem besteht für Desktop-Apps nicht, daher hätten sie keinen guten Grund, an beiden Stellen eine Schaltfläche einzufügen.

Der Trick besteht darin, ausgeglichen zu bleiben und nicht alles überall hin zu stellen. Das Prinzip Gruppieren verwandter Funktionen hilft in beide Richtungen - verstecken Sie Dinge nicht aus dem Weg, wenn sie wirklich mit lokalisierten Funktionen zusammenhängen, sondern werfen Sie Dinge nicht in die Mitte der Hauptbenutzeroberfläche es sei denn, es ist nützlich für die Ausführung der Aufgabe, für die der Benutzer da ist. Der letztere Fall behandelt Optionen und Einstellungen, die der Benutzer einmal festlegt und vergisst - stellen Sie keine Options-Schaltfläche in den Weg, wenn er nur einmal darauf klickt.

Finden Sie heraus, welche Anwendungsfälle für jeden Teil Ihrer App am häufigsten verwendet werden, und optimieren Sie die Benutzeroberfläche für diese Anwendungsfälle. Es ist in Ordnung, wenn dadurch ein kleines Redundanz.

4
Steve S

Microsoft Ribbon bietet dem Benutzer die Möglichkeit, der Symbolleiste "Schnellzugriff" verschiedene Befehle hinzuzufügen. Sie können diese Idee erweitern und diese Befehle zunächst hinzufügen, während der Benutzer die nicht gewünschten Befehle entfernen kann.

0
Pat

Ich habe viele Websites mit einer schwebenden Leiste oder einem Widget gesehen, die unabhängig vom Bildlauf im Blick bleiben. Könnte eine solche Leiste nicht verwendet werden, um die Befehle "Bearbeiten", "Speichern" oder andere im Blick zu behalten? Dies würde natürlich nur funktionieren, wenn die gesamte Seite gespeichert würde, denke ich.

0
Peter Frings

Was sagen die tatsächlichen Benutzer dazu? Und wie reagieren sie auf beide Implementierungen, wenn sie einem Benutzertest unterzogen werden? Ich denke, das sind entscheidende Faktoren. Ich denke, Anwendungen sollten hauptsächlich einfach zu bedienen sein, daher ist das Vermeiden von Aufblähen der Benutzeroberfläche kein Ziel an sich, sondern ein Mittel, um sie nutzbar zu halten. Wenn die zusätzliche Schaltfläche den Benutzern hilft (indem sie eine häufig verwendete Funktion leichter zugänglich macht), mehr als sie behindert (indem sie ihnen eine verwirrende Oberfläche präsentiert), sollte dies meiner Meinung nach getan werden.

(Beachten Sie, dass die meisten GUIs bereits redundant sind. Bestimmte Optionen sind in den Menüelementen oben, in der Symbolleiste, im Kontextmenü und mit einer Tastenkombination aufgeführt.)

Ich denke, wenn der Bearbeitungsmodus häufig verwendet wird, verdient er eine direkte Schaltfläche.

0
Inca

Viele Webanwendungen verfügen über Schaltflächen zum Speichern/Senden sowohl über als auch unter dem Inhalt (insbesondere Einkaufswagen).

Solange die Tasten identisch aussehen und zueinander ausgerichtet sind, ist daran nichts auszusetzen.

Kontextschaltflächen (z. B. eine Bearbeitungsschaltfläche für eine Zeile) sollten ihren Zeilen zugeordnet werden. Es ist wahrscheinlich besser, eine Bearbeitungsschaltfläche in die Zeile einzufügen (möglicherweise beim Bewegen des Mauszeigers) als in eine Symbolleiste (es sei denn, Sie unterstützen die Mehrfachauswahl).

0
SLaks