Richtlinie: Benutzerschnittstelle (Allgemein)
Diese Richtlinie beschreibt allgemeine Regeln für die Entwicklung fensterbasierter Benutzerschnittstellen.
Beziehungen
Hauptbeschreibung

Grundlagen für Fenstertechnik: Kontext festlegen

Dieser Abschnitt gibt einen Überblick über die Anatomie einer fensterbasierten Benutzerschnittstelle. Dieser Überblick ist erforderlich, um den Rest der Richtlinien verstehen zu können.

Eine fensterbasierte Benutzerschnittstelle ist in Fenster unterteilt. Fenster können auf dem Bildschirm verschoben, übereinander gestapelt und als Symbole dargestellt werden. Ein System hat in der Regel ein Primärfenster und mehrere Sekundärfenster. Das Primärfenster verarbeitet die meisten Interaktionen mit dem Benutzer und enthält häufig eine beliebige Anzahl von Objekten. Sekundärfenster werden verwendet, um die Interaktionen mit Primärfenstern zu unterstützen und liefern Details zu den Objekten und den Operationen, die für diese Objekte ausgeführt werden.

Primärfenster

Das Primärfenster enthält häufig eine beliebige Anzahl von Objekten, mit denen der Benutzer interagiert. Der Benutzer interagiert normalerweise mit dem System, indem er zunächst eine oder mehrere Objekte auswählt, z. B. auf sie klickt, und anschließend eine Operation auswählt (z. B. in einem Menü), die dann für alle ausgewählten Objekte ausgeführt wird. Gebräuchliche Operationen sind Ausschneiden, Kopieren, Einfügen, Löschen und Eigenschaften anzeigen.

Das Primärfenster enthält normalerweise eine Menüleiste, in der der Benutzer Operationen auswählen kann. Benutzer können Operationen auch in Popup-Menüs (durch Rechtsklick auf das Objekt selbst) oder durch direkte Manipulation (durch Anklicken und Ziehen des Objekts) auswählen. Da möglicherweise nicht alle Objekte in das Primärfenster passen, können Benutzer häufig mit Hilfe einer Schiebeleiste durch die Objekte blättern oder die Größe des Fensters verändern. Außerdem können Primärfenster in Teilfenster (definierte Teilbereiche des Fensters) eingeteilt sein, deren Größe der Benutzer ebenfalls ändern kann.

Zusammengesetzte Objekte

Ein zusammengesetztes Objekt in einer Benutzerschnittstelle ist ein Objekt, das sich visuell aus anderen Objekten zusammensetzt. Beispielsweise ist ein Absatz ein Objekt, das sich aus Zeichen zusammensetzt, und ein komplexes Zeichenobjekt ein Objekt, das sich aus mehreren primitiven Zeichenobjekten zusammensetzt.

Sekundärfenster

Sekundärfenster unterstützen die Primärfenster insofern, als sie Details (z. B. Eigenschaften) zu den Objekten im Primärfenster und den Operationen, die für diese Objekte ausgeführt werden, liefern. Normalerweise werden im Primärfenster nur wenige Eigenschaften von Objekten angezeigt. Eigenschaften eines Objekts können angezeigt werden, indem ein Eigenschaftenfenster (ein Sekundärfenster) geöffnet wird, in dem alle Attribute eines Objekts angezeigt werden. Der Benutzer kann die Attribute häufig mit Steuerelementen wie Umschalt- und Radioknöpfen, Skalen, kombinierten Feldern und Textfeldern ändern.

Beachten Sie, dass es eine feine und zuweilen sogar künstliche Linie zwischen Primärfenstern und Sekundärfenstern gibt. Beide Fenstertypen können dieselbe Komplexitätsstufe haben. Die beiden Hauptunterschiede zwischen Primär- und Sekundärfenstern sind jedoch die folgenden:

  • Primärfenster werden häufig als wichtiger für die Anwendung eingestuft, da sie einen hohen Grad von Benutzerfreundlichkeit aufweisen müssen. Deshalb richten sich die Entwicklungsanstrengungen eher auf die Primärfenster.
  • Sekundärfenster werden häufig bei der Navigation in Primärfenstern angezeigt und nicht umgekehrt.

Neben den Eigenschaftenfenstern gibt es weitere Typen von Sekundärfenstern, z. B. Dialogfenster, Nachrichtenfenster, Paletten und Popup-Fenster.

Viele Anwendungen sind dateibasiert. Benutzer können solche Anwendungen starten, indem sie die Operation Öffnen für ein Dateiobjekt ausführen (z. B. durch Doppelklicken auf ein Dateisymbol in einem Ordner). Im Primärfenster werden die Objekte angezeigt, die in dieser Datei gespeichert sind. Gebräuchliche Operationen für Dateien sind Speichern, Speichern unter, Öffnen und Neu, die normalerweise in einem Menü "Datei" im Primärfenster angeboten werden. Im Primärfenster können in der Regel mehrere Dateien angezeigt werden (die Bezeichnung hierfür ist auch MDI, Multiple Document Interface), was dem Benutzer erlaubt, zwischen mehreren Dateien zu wechseln.

Visuelle Dimensionen

Der Schlüssel für brauchbare Primärfenster ist die Verwendung visueller Dimensionen bei der Visualisierung der enthaltenen Objekte und ihrer Attribute. Die Darstellung von mehr Attributen, als für die Identifizierung erforderlich sind, hat die folgenden Vorteile:

  • Dem Benutzer bleibt zusätzlicher Navigationsaufwand erspart, weil Sie die Anzahl der Fenster reduzieren, die angezeigt werden müssen (wenn der Benutzer ein Attribut sehen muss, das im Primärfenster dargestellt wird).
  • Der Benutzer kann die unterschiedlichen Aspekte (verschiedener Objekte) auf einem Blick sehen, was häufig für Vergleiche und die Erkennung von Mustern hilfreich sein kann. Eine durchdachte Verwendung visueller Dimensionen kann bewirken, dass Benutzer ein völlig neues Fingerspitzengefühl für ihre Arbeit entwickeln:

Die visuellen Dimensionen sind:

Diese Dimensionen werden im Folgenden vorgestellt. Achten Sie beim Design der Visualisierung von Objekten jedoch auf den verfügbaren Anzeigenbereich. Versuchen Sie, bei der Ausnutzung des Anzeigenbereichs den Aufwand so gering wie möglich zu halten, und überlegen Sie, ob es sich rechnet, für mehrere visuelle Dimensionen zusätzlichen Anzeigenbereich herzugeben. Möglicherweise ist dem Benutzer besser damit gedient, wenn nur eine Liste von Namen angezeigt wird, weil der Benutzer im Grunde nur so viele Objekte wie möglich sehen muss.

Es ist wichtig, diese visuellen Dimensionen zu verwenden oder zu erweitern, um Objekte eindeutig identifizieren zu können. Auch zu diesem Thema finden Sie im Folgenden eine Beschreibung (siehe Abschnitt "Identifizierung").

Die visuellen Dimensionen können auch in Korrelation mit der zeitlichen Dimension verwendet werden, beispielsweise indem Objekte verschoben werden (ihre Position ändert sich mit der Zeit) oder die Form oder Farbe von Objekten geändert wird (ihr Zustand ändert sich mit der Zeit). Letzterer Fall wird im Abschnitt "Form" erläutert.

Position

Die intuitivsten Aspekte, die eine Position darstellen kann, sind Positionen in der realen Welt. Beispiele:

  • Geographical Information Systems (GIS), die eine Karte anzeigen, auf der Sie die Objekte auf demselben Längen- und Breitengrad anzeigen, auf denen sie sich in der echten Welt befinden.
  • CAD-Programme (Computer Aided Design), die die Objekte und ihre Umgebung entsprechend ihren Koordinaten in der echten Welt exakt darstellen.
  • WYSIWYG-Editore (What You See Is What You Get), die die Objekte (Zeichen) an derselben Position im Fenster anzeigen, an der sie auf einem Ausdruck erscheinen.

Manchmal ist es wichtig, dass realistische Größen angezeigt werden (z. B. in CAD-Programmen und WYSIWYG-Editoren), und manchmal nicht, z. B. wenn die Objekte wesentlich kleiner sind als der Abstand zwischen den Objekten.

Stellen Sie sich beispielsweise ein Flugbuchungssystem vor, in dem der Benutzer Zielorte eingeben muss. Eine mögliche Darstellungsart wäre, eine Karte anzuzeigen, die die verschiedenen Flughäfen enthält (wobei ein Flughafen ein Objekt ist). Da die realistische Größe der Flughäfen hier irrelevant (und für eine Anzeige auch zu klein) ist, werden alle Flughäfen als Symbole mit derselben Größe angezeigt.

Dieses Beispiel veranschaulicht auch, dass realistische Positionen auch dann verwendet werden können, wenn sie nicht relevant sind, solange sie dem Benutzer bei der Identifizierung der Objekte helfen. In dem Beispiel muss der Benutzer die genaue Position eines Flughafens nicht kennen. Wenn der Benutzer jedoch in Geographie bewandert ist, kann es leichter für ihn sein, Zielorte auf der Karte als in einer Liste zu finden.

Sie können die Dimension Position auch verwenden, um "virtuelle" realistische Position darzustellen. Stellen Sie sich beispielsweise ein Home-Shopping-System vor, in dem die Benutzer Artikel in unterschiedlichen "Kaufhäusern" kaufen können. Eine mögliche Darstellung wäre, ein schematisches Bild eines (virtuellen) Einkaufszentrums anzuzeigen, in dem unterschiedliche Kaufhäuser positioniert sind (wobei ein Kaufhaus ein Objekt ist). Dieses schematische Bild hat nichts mit den echten Positionen dieser Kaufhäuser zu tun, es nutzt lediglich die räumliche Vorstellungskraft des Benutzers. Es ist einfacher, sich eine XY-Position zu merken als einen Eintrag in einer Liste oder Hierarchie.

Außerdem können mit der Dimension Position Assoziationen zwischen Objekten gezeigt werden. Alle Objekte mit derselben vertikalen Position stehen in einer Beziehung und alle Objekte mit derselben horizontalen Position in einer anderen Beziehung miteinander. Spreadsheets sind Beispiele hierfür.

Eine ähnliche Alternative ist, den Wertebereich eines Attributs auf einer Achse darzustellen. In einem Reisebuchungssystem könnten gebuchte Flüge (ein Flug ist ein Objekt) beispielsweise auf einer horizontalen Zeitachse dargestellt werden, die die zeitliche Beziehung der Flüge zueinander, die Flugdauer und die Aufenthaltsdauer des Benutzers an den einzelnen Zielorten zeigt. Dies sind alles Dinge, die der Benutzer nicht wissen muss, aber hübsch anzusehen sind, wenn sie dezent dargestellt werden können.

Wenn Sie nicht so viel Anzeigenbereich für die Darstellung des gesamten Wertebereichs verwenden möchten, können Sie die Abstände zwischen den Objekten ausblenden. Im Reisebuchungssystem würde diese bedeuten, dass alle gebuchten Flüge auf einer horizontalen Linie ohne Leerräume dazwischen dargestellt werden, wobei der erste Flug ganz links, der zweite Flug sofort rechts daneben usw. angezeigt wird. In diesem Fall sehen die Benutzer nicht, wie lange sie an jedem Zielort bleiben könnten, aber wie lange die einzelnen Flüge dauern.

Größe

In vielen Fällen muss "Größe" dasselbe darstellen wie Position. In einem CAD-System beispielsweise muss Größe natürlich die realistischen Abmessungen darstellen. Manchmal können wir frei wählen, was Größe darstellen soll, z. B. die Flughäfen auf der Karte, die die Zielortwahl unterstützt.

In diesen Fällen sollte Größe darstellen, was intuitiv als realistische Größe des Objekts wahrgenommen wird. Für eine Datei sollte die Objektgröße den belegten Plattenspeicherplatz darstellen, für ein Bankkonto den Kontostand. Für die meisten Größen eignet sich eine logarithmische Skala besser als eine proportionale, da eine proportionale Skala normalerweise zu viel Anzeigenbereich verbraucht.

Größe ist in der Tat so intuitiv, dass Sie sie anzeigen können, selbst wenn sie nicht relevant ist. Schließlich nehmen in der realen Welt unterschiedliche Dinge (Objekte) aufgrund ihrer unterschiedlichen Größe unterschiedliche Proportionen unseres visuellen Blickfelds ein. Und dies ist nicht penetrant, sondern hilft uns, zwischen Dingen zu unterscheiden. Ähnlich helfen unterschiedliche Größen in der Benutzerschnittstelle Benutzern häufig, zwischen unterschiedlichen Objekten zu unterscheiden.

Größe sollte normalerweise verwendet werden, um nur ein Attribut darzustellen, obwohl es theoretisch möglich ist, ein Attribut durch horizontale Abmessung und ein anderes Attribut durch vertikale Abmessung darzustellen (was jedoch nicht sehr intuitiv ist und den Benutzer verwirren könnte).

Die horizontale bzw. vertikale Abmessung sollte (logarithmisch) proportional zu dem Attribut sein, dessen Größe veranschaulicht werden soll. Die andere Abmessung sollte fest (oder beispielsweise von der Länge des Namens abhängig sein). Wenn horizontale und vertikale Abmessung proportional zu demselben Attribut sind, hat dies selten einen zusätzlichen Wert. Vielmehr wirkt es penetrant und verbraucht nur mehr Anzeigenbereich.

Form

Formen werden in einer grafischen Benutzerschnittstelle normalerweise durch Symbole dargestellt. Form eignet sich am besten, um Typen darzustellen, weil eine Unterscheidung intuitiver anhand der Darstellung als anhand eines Typs getroffen werden kann. In der realen Welt sehen unterschiedliche Objekte desselben Typs in der Regel ähnlich aus, während Objekt unterschiedlicher Typen auch unterschiedlich aussehen. Beispielsweise sehen unterschiedliche Objekte von Stuhl ähnlich aus (sie haben alle vier Beine, einen Sitz und eine Lehne), während ein Auto sich stark von einem Stuhl unterscheidet.

Was sind also die Kriterien, um zu entscheiden, ob Objekte unterschiedliche Typen haben? Unterschiedliche Klassen sollten auf jeden Fall als unterschiedliche Typen betrachtet werden. Außerdem sind einige Attribute "typenähnlich". Diese Attribute müssen eine begrenzte Anzahl möglicher Werte haben, und ihr Wert bestimmt normalerweise, was mit dem Objekt getan werden kann (mit Operationen und möglichen Werten anderer Attribute). Dies ist dasselbe wie in der realen Welt. Der Hauptunterschied zwischen Stuhl und Auto ist die Art und Weise, in der sie verwendet werden. Ein Stuhl wird zum Ausruhen und ein Auto zum Transport verwendet.

Wenn Sie jedoch analysieren, was als unterschiedlicher Typ einzustufen ist, müssen Sie dabei den wichtigsten Aspekt berücksichtigen: Welches Attribut wird vom Benutzer am ehesten als Typ wahrgenommen.

Wenn Sie nicht mehrere Klassen oder "typenähnliche" Attribute haben, können Sie Symbole verwenden, um die verschiedenen Werte für andere Attribute mit begrenztem Wertebereich darzustellen, jedoch nur, wenn das jeweilige Attribut von zentralem Interesse für den Benutzer ist.

Symbole werden häufig verwendet, um unterschiedliche Zustände des Objekts (neben dem Typ) zu veranschaulichen. Wenn Sie ein Objekt auswählen, wird dies gewöhnlich auf eine von zwei Arten angezeigt: Die Farbe ändert sich in schwarz, oder das Objekt wird von einem Rechteck umrahmt angezeigt. Ein weiterer möglicher Zustand ist der, dass Sie ein Eigenschaftenfenster für das Objekt geöffnet haben. Normalerweise gibt es auch noch weitere anwendungsspezifische Zustände, die angezeigt werden könnten, z. B. ob eine E-Mail gelesen wurde oder nicht. Stellen Sie lediglich sicher, dass die Darstellung des Zustands es für den Benutzer nicht schwieriger macht, den Typ zu erkennen und umgekehrt.

Farbe

Farbe kann basierend auf der visuellen Wahrnehmung in drei Komponenten unterteilt werden. Dies sind der Farbton (d. h. rot, blau, braun usw.), Sättigung und Dunkelheit. Es ist jedoch davon abzuraten, unterschiedliche Komponenten für die Darstellung unterschiedlicher Attribute zu verwenden, da dies für den Benutzer zu schwer zu erkennen ist.

Der Farbton könnte verwendet werden, um Typ oder Attribute mit einer eingeschränkten Gruppe gültiger Werte darzustellen. Allerdings eignet sich hierfür ein Symbol besser, da das Symbol so gestaltet werden kann, dass der Benutzer versteht, welchen Wert das Symbol darstellt, während eine solche intuitive Unterscheidung zwischen Farbinhalt und (den meisten Typen von) Werten nicht möglich ist. Der Farbton kann anstelle von Symbolen verwendet werden, wenn keine intuitiven Symbole gefunden werden. Wenn Sie viele Typsymbole haben, kann der Farbton als Alternative für die Kategorisierung der Typsymbole verwendet werden (so dass einige Symbole mit ähnlicher Bedeutung in rot, einige Symbole mit einer anderen Bedeutung in blau usw. dargestellt werden).

Sättigung könnte verwendet werden, um ein Attribut mit einem Wertebereich darzustellen, aber dies führt zu einer eher hässlichen und aufdringlichen Benutzerschnittstelle. Die Verwendung unterschiedlicher Sättigungen wirkt unruhig und die Verwendung einer hohen Sättigung eher aufdringlich.

Dunkelheit ist die nützlichste Komponente von Farbe. Sie kann verwendet werden, um ein Attribut mit einem Wertebereich darzustellen und sie ist so unaufdringlich, dass sie auch für Attribute mit untergeordneter Bedeutung verwendet werden kann. Damit Dunkelheit unaufdringlich bleibt, sollten Sie es vermeiden, von Weiß (keine Dunkelheit) direkt zu Schwarz (vollkommene Dunkelheit) überzugehen. Gehen Sie lieber von hellem Grau (geringe Dunkelheit) zu dunklem Grau (hohe Dunkelheit) über. Bei vielen Systemen, bei denen die Benutzer den Großteil der Objekte erstellen, ist es hilfreich, Objekte nach Alter darzustellen, z. B. die seit der letzten Änderung vergangene Zeit. Dies hilft den Benutzern, das Objekt wiederzuerkennen, mit dem sie arbeiten möchten (das häufig das Objekt mit der kürzesten "Zeit seit der letzten Änderung" ist). Wenn Sie kein Attribut mit einem Wertebereich haben, das sie dem Benutzer wirklich präsentieren müssen, sollten Sie die Darstellung nach Alter in Erwägung ziehen.

Farbe wird häufig verwendet, um die Symbole attraktiver zu gestalten. Farbe hilft dem Benutzer auch, die Symbole besser unterscheiden zu können. Wenn Sie mehrfarbige Symbole verwenden, sollten Sie unter Umständen für andere Zwecke auf Farbe verzichten.

Da einige Menschen farbenblind sind und da nicht alle Anzeigen Farbe unterstützen, sollten Sie Farbe nicht als ausschließliches Mittel für die Anzeige elementarer Informationen verwenden. Andererseits macht ein wohl geplanter und unaufdringlicher Einsatz von Farbe die Benutzerschnittstelle vom Ästhetischen her gesehen sehr viel ansprechender.

Identifizierung

Der Benutzer muss in der Lage sein, jedes Objekt erkennen zu können. Manchmal reichen die anderen visuellen Dimensionen für die Identifizierung aus, größtenteils aber nicht. Die Anzeige eines Namens auf oder neben dem Symbol ist die gängigste Technik für die Unterstützung der Identifizierung. Namen haben den Vorteil, dass in einem sehr kleinen Anzeigenbereich eine hohe Anzahl eindeutig unterschiedlicher Namen angezeigt werden kann.

Am besten ist es, wenn ein Name aus einem Attributwert generiert werden kann (d. h. normalerweise als Text). Die Alternative ist, die Benutzer die Namen angeben zu lassen, wenn sie die Objekte erstellen, aber dies braucht Zeit und vermindert somit die Benutzerfreundlichkeit.

Manchmal können Sie das Symbol so gestalten, dass der Name im Symbol integriert ist. Dies spart Anzeigenbereich ein und gibt einen eindeutigeren Hinweis auf die Beziehung zwischen dem Symbol und dem Namen. Dies kann jedoch zu den folgenden Probleme führen:

  • Das Symbol muss in der Mitte (dort, wo der Name erscheint) leer sein.
  • Namen haben variable Längen, d. h. die horizontale Ausdehnung des Symbol muss sich nach der Länge des Namens richten, oder einige Namen müssen entsprechend gekürzt werden.
  • Das Symbol muss viel breiter als hoch sein, da alle Texte mit einer angemessenen Länge nicht länger sind als breit.

Deshalb müssen Sie den Namen häufig unter oder rechts neben dem Symbol anzeigen, was den Vorteil hat, dass weniger Anzeigenbereich verbraucht wird, aber leider auch dazu führt, dass das Objekt (Symbol + Name) noch breiter als hoch wird. Wenn Sie nicht genügend Platz haben, um den Namen überhaupt anzuzeigen (was durchaus der Fall sein kann, da ein Symbol normalerweise auch ohne Namen erkennbar ist), können Sie den Namen über Popup-Fenster anzeigen, die erscheinen, wenn der Cursor über das Symbol geführt wird.

Die Schriftart des Namens kann verwendet werden, um ein Attribut mit begrenzter Auswahl darzustellen, sofern Sie eine intuitive Zuordnung zwischen Schriftart und Attributwerten finden. Sie könnten beispielsweise Fett- und Kursivschrift zur Unterscheidung des Objekts oder zur Hervorhebung seiner Bedeutung verwenden. In den meisten Fällen ist jedoch von einer Unterscheidung durch Schriftarten abzuraten, weil sie eher aufdringlich wirkt und nur selten intuitiv ist.

Wenn Sie den Namen (und wenn wir schon dabei sind, alle Texte, die der Benutzer ändern kann) anzeigen, sollten Sie das Editieren des Namens direkt im Primärfenster unterstützen. Die Alternative wäre, dass der Benutzer eine Umbenennungsoperation anfordert und dann den neuen Namen eingibt oder das Eigenschaftenfenster öffnet und den Namen dort ändert. Den Namen direkt im Primärfenster zu ändern, ist nicht nur schneller, sondern unterstützt auch das Prinzip "sehen und ändern".

Profisuche und -auswahl

Wenn die Gruppe von Objekten, die geändert oder bearbeitet werden soll, so zusammengesetzt ist, dass der Benutzer Auswahlkriterien definieren kann, um sie zu identifizieren, kann die Suchfunktion des Primärfensters das Problem so lösen, dass stets alle Übereinstimmungen ausgewählt werden.

Die Suche kann mit zwei Methoden verwaltet werden:

  • Alle Objekte, auf die die Suchkriterien zutreffen, werden im Primärfenster ausgewählt. Wenn Sie nicht garantieren können, dass alle gefundenen Objekte gleichzeitig im Primärfenster angezeigt werden (weil sie zu weit entfernt sind), können Sie im Suchfenster eine Trefferliste anzeigen. Nach einer Suche gibt der Benutzer entweder zusätzliche Suchkriterien ein oder führt eine Operation für die ausgewählten Objekte durch. Dieser Ansatz hat den Vorteil, dass er dem Benutzer ermöglicht, eine Operation für alle Objekte anzufordern, die den Suchkriterien entsprechen.
  • Sie stellen im Suchfenster eine Schaltfläche Suchen bereits, die das nächste Objekt auswählt, das den Suchkriterien entspricht, und den Inhalt des Primärfensters so verschiebt, dass dieses Objekt sichtbar ist. Nach einer Suche kann der Benutzer eine Operation für das ausgewählte Objekt ausführen und anschließend nacheinander alle weiteren Objekte suchen, die den Suchkriterien entsprechen. Dieser Ansatz hat den Vorteil, dass der Benutzer jedes gefundene Objekt in seiner Umgebung sehen kann (im Primärfenster und nicht in einer separaten Trefferliste).

In vielen Fällen können Sie die beiden Ansätze kombinieren, z. B., indem Sie eine Schaltfläche Alles auswählen in das sequenzielle Suchfenster oder eine Schaltfläche Nächsten Treffer in das parallele Suchfenster einfügen.

Sortieren

Ein Beispiel für Sortierung ist, wenn das System alle Objekte untereinander in alphabetischer Reihenfolge, nach Namen oder nach dem Wert eines Attributs anordnet. Der Benutzer zeigt die Objekte dann durch Blättern an. Dies ist die einfachste Anzeigeunterstützung in Bezug auf die Implementierung und die Bedienung. Sortierung funktioniert am besten, wenn der Benutzer stets den Namen (oder das Attribut, nach dem sortiert wird) des gewünschten Objekts kennt. Ein Beispiel für ein System, das auf diese Weise implementiert werden sollte, ist ein Telefonbuch. Das Primärfenster sollte in der Regel eine Operation enthalten, mit der die Sortierreihenfolge und/oder die Sortierkriterien geändert werden können.

Benutzergesteuerte Vererbung

Ein Beispiel für benutzergesteuerte Vererbung sind WYSIWYG-Editoren, in denen Sie definieren, zu welchem "Stil" die einzelnen Absätze gehören, und anschließend festlegen, wie dieser Stil (d. h. jedes einzelne Zeichen, das zu diesem Stil gehört) dargestellt werden soll.

Die benutzergesteuerte Vererbung hat im Vergleich mit einem Suchtool den Nachteil, dass sie nur die Änderung von Attributen (und unter Umständen Assoziationen) für mehrere Objekte unterstützt, aber nicht die Ausführung von Operationen. Außerdem bedeutet benutzergesteuerte Vererbung insofern zusätzlichen Aufwand, als der Benutzer die Gruppen explizit definieren und verwalten muss (d. h. die verfügbaren Stile). Darüber hinaus ist sie ein komplizierteres Konzept.

Wenn jedoch keine Suchkriterien für die Objekte angegeben werden können oder wenn der Benutzer relative Änderungen an den Attributwerten (z. B. um zwei erhöhen) vornehmen muss, kann die Unterstützung benutzergesteuerter Vererbung eine Lösung sein.

Damit benutzergesteuerte Vererbung hilfreich ist, muss die Klasse derart gestaltet sein, dass die Objekte in Gruppen kategorisiert werden können (die für den Benutzer eine logische Bedeutung haben), in denen die meisten Attributwerte identisch sind.

Ein Vorteil im Vergleich mit einer Suchfunktion ist der, dass die benutzergesteuerte Vererbung Überschreibungen unterstützt, z. B. den Attributwert nur ändern, wenn wenn er nicht explizit im Objekt definiert ist. Außerdem kann der Benutzer durch benutzergesteuerte Vererbung generischere (und damit leistungsfähigere) Attributwertdefinitionen vornehmen, z. B. die Schriftart aus diesem Stil übernehmen, aber zwei Pixel größer machen. Benutzergesteuerte Vererbung ist besonders hilfreich, wenn die Suchkriterien für die Gruppen nicht so einfach anzugeben sind.

Die Klasse, für die Sie benutzergesteuerte Vererbung unterstützen, kann sich entweder selbst vererben, oder Sie können eine neue Klasse erstellen, von der der Zweck übernommen wird. Die Klasse sich selbst erben zu lassen, ist ein bisschen leistungsfähiger, da dasselbe Objekt sowohl als "Erbobjekt" verwendet werden kann als auch die Dinge tun kann, die ursprünglich für das Objekt geplant wurden, z. B. eine Rechnung sein, ein Konto sein usw. Damit hat der Benutzer (und das System) weniger Klassen zu verwalten. Andererseits hat das Erstellen einer neuen Klasse als "Erbklasse" den Vorteil, dass sie leichter zu verstehen ist, da Vererbung klar von der normalen Verarbeitung der Klasse getrennt ist. Das Erstellen einer neuen Klasse ist in den meisten Fällen die beste Lösung, insbesondere wenn die Benutzer keine bedeutende Erfahrung im Umgang mit Computern und objektorientierten Modellen haben. Die neue Klasse, die Sie erstellen, sollte sich vorzugsweise selbst beerben, um mehrere Vererbungsstufen zu unterstützen.

Bei den meisten Systemen muss der Benutzer häufig die Vererbungsgruppe für bestimmte Objekte ändern, da der Benutzer im Voraus nicht genau weiß, wie die Vererbungsgruppen strukturiert werden müssen. Stellen Sie hierfür eine Operation bereit.

Wenn Sie sich für die Unterstützung benutzergesteuerter Vererbung in Ihrem System entscheiden, müssen Sie analysieren, welche Dinge (Attribute, Assoziationen, Klasse) vererbt werden muss und anschließend die Vererbung nur für diese Dinge unterstützen. Dies führt zu einer zwar weniger generischen, dafür aber einfacheren Methode (für Benutzer und Entwickler) zur Verwaltung der Funktionalität. Modellieren Sie die Dinge, die vererbt werden sollen, in Ihrer neuen Klasse. Viele Attribute werden dann in der erbenden und in der vererbten Klasse modelliert. Denken Sie daran, dass die benutzergesteuerte Vererbung eine Zeitersparnis für den Benutzer und nicht für Sie selbst bedeuten soll. Wenn die Klasse sich selbst vererbt, impliziert dies, dass alles vererbbar ist.

Entscheiden Sie, ob der Benutzer wirklich neue Objekte der vererbten Klasse erstellen muss oder ob das System eine ausreichende Anzahl von Objekten bereitstellen kann. Dem Benutzer zu untersagen, neue Objekte zu erstellen, beeinträchtigt die Flexibilität der Vererbung beträchtlich, ermöglicht aber andererseits eine einfache Bedienung.

Legen Sie außerdem fest, ob Änderungen an numerischen Attributen in den erbenden Objekten relativ zum vererbten Wert oder als feste Werte interpretiert werden sollen. Angenommen, ein Objekt erbt die Schriftgröße 12 und der Benutzer ändert sie in 14. Durch relative Interpretation merkt sich das System die Schriftgröße als vererbten Wert +2, d. h., wenn sich die Schriftgröße des vererbten Objekts ändert, ändert sich auch die Schriftgröße des erbenden Objekts. Wenn Sie relative Interpretation unterstützen, muss dies im Attribut des vererbten Objekts dokumentiert werden (da sie dort die Vererbung untersuchen). Es ist wichtig, dass die relative Interpretation dem Benutzer präsentiert wird (z. B. "Schriftgröße: 12+2=14" und nicht nur "Schriftgröße: 14"). Mit Szenarios können Sie versuchen, Situationen zu finden, die entweder die relative oder die feste Interpretation unterstützen. Möglicherweise müssen Sie beides unterstützen.

Da benutzergesteuerte Vererbung nur für fortgeschrittene und erfahrene Benutzer bestimmt ist, müssen Sie sie so gestalten, dass sie sich nicht auf die normale Verwendung auswirkt (z. B. wenn der Benutzer keine Vererbung verwendet). Andernfalls können Benutzer mit wenig Vorkenntnissen abgeschreckt werden.

Denken Sie daran, dass die benutzergesteuerte Vererbung, die Sie erstellen, dazu gedacht ist, das Leben des Benutzers zu vereinfachen. Sie muss nicht generisch oder rein sein, sondern verwendbar.

Eine Anzeigehierarchie erlaubt dem Benutzer (und möglicherweise dem System), die Objekte in Primärfenster oder zusammengesetzte Fenster zu kategorisieren, die hierarchisch aufgebaut sind. Anzeigehierarchien stellen sicher, dass der Benutzer nur eine (oder einige wenige) Kategorie suchen muss. Dies reduziert die Anzahl der Objekte, die zu einem bestimmten Zeitpunkt angezeigt werden müssen. Ein Nachteil ist, dass (gewöhnlich) der Benutzer die Kategorisierung verwalten muss. Ein Beispiel für diese Technik sind Dateibrowser. Der Grund für die Verwendung von Verzeichnissen oder Ordnern ist der, dass die Benutzer Dateien einfacher finden.

Fenstermanagement

Fenstergröße und -position liegen normalerweise komplett in der Kontrolle des Benutzers. Sie können den Aufwand für die Fenstertechnik jedoch verringern, indem Sie das System Größe und Position der Fenster beeinflussen lassen.

Je größer ein Primärfenster ist, desto mehr Objekte können angezeigt werden, aber desto mehr Anzeigenbereich wird auch verbraucht. Ein Primärfenster sollte normalerweise so viele Objekte wie möglich anzeigen, ohne jedoch Anzeigenbereich unnötig zu verbrauchen.

  • Machen Sie jedes Primärfenster groß genug, so dass alle Objekte angezeigt werden können, jedoch nicht größer als die Bildschirmanzeige. Machen Sie jedes Primärfenster groß genug, so dass die Objekte vollständig angezeigt werden, aber vermeiden Sie Bereiche, die nichts Hilfreiches zeigen, wie z. B. die Ränder in einer Desktop-Veröffentlichungskomponente. Selbst wenn Sie genug Platz haben, um diese leeren Bereiche anzuzeigen, können diese Bereiche andere Anwendungen teilweise überlagern.
  • Denken Sie daran, dass ein Benutzer Größenänderungen zwischen Sitzungen vornimmt. Wenn die Anzahl der Objekte zunimmt, erhöhen Sie die Fenstergröße so, dass alle Objekte sichtbar sind, sofern nicht bereits die gesamte Anzeigenhöhe ausgenutzt wird oder der Benutzer eine Größe ausgewählt hat, die kleiner ist als die Standardgröße. Nimmt die Anzahl der Objekte ab, verringern Sie die Größe, sofern der Benutzer keine Größe ausgewählt hat, die größer ist als die Standardgröße. Diese Regel stellt sicher, dass Sie der Absicht der Größenänderungsoperationen des Benutzers folgen.

Eine weitere mögliche Einschränkung für die Größe eines Primärfensters ist, dass Sie die Anwendung häufig gleichzeitig mit anderen Anwendungen ausführen müssen. Anschließend können Sie die Standardgröße des Fensters auf die Hälfte der Anzeige maximieren (im Gegensatz zur Gesamtanzeige).

Legen Sie die Standardposition eines Primärfensters so fest, dass es so wenig wie möglich von anderen Anwendungen überlagert. Wenn Sie einige Fenster überlagern müssen, wählen Sie solche aus, die am längsten nicht verwendet wurden, und versuchen Sie, wenigstens einen kleinen Teil der Fenster sichtbar zu lassen, so dass sie der Benutzer problemlos wieder aktivieren kann.

Die Anwendung der zuvor beschriebenen Regeln hat den Nachteil, dass dem Benutzer ein gewisser Teil der Kontrolle entzogen wird (das System ändert die Größe eines Fensters ungefragt und merkt sich keine Neupositionierungen durch den Benutzer über Sitzungsgrenzen hinweg). Wenn Sie diese Regeln anwenden, sollten Sie dem Benutzer deshalb ermöglichen, die Regeln (über ein Steuerelement) zu inaktivieren.

Für Sekundärfenster sollte die Größe und Position so gewählt werden, dass sie das Fenster, in dem sie aufgerufen wurden, und, sofern möglich, andere Sekundärfenster nicht überlagern. Wenn Sie das Fenster, in dem sie aufgerufen wurden, überlagern müssen, versuchen Sie sicherzustellen, dass sie keine ausgewählten Objekte überlagern. Die Überlagerung elementarer Dinge wie ausgewählter Objekte ist ein Mangel an Benutzerfreundlichkeit, den Sekundärfenster häufig aufweisen.

Für andere Primärfenster als das Hauptprimärfenster sollten Sie außerdem die Größenregel anwenden, die im vorherigen Abschnitt beschrieben wurde.

Dialogfenster sollten jedoch so platziert werden, dass sie das aktive Fenster überlagern. Da sie normalerweise temporär und klein sind, muss der Benutzer normalerweise das aktive Fenster nicht sehen, während das Dialogfenster geöffnet ist. Durch die Platzierung von Dialogfenstern auf dem aktiven Fenster wird sichergestellt, dass der Benutzer sie wahrnimmt. Außerdem werden dadurch unnötige Mausbewegungen verringert, weil sich der Cursor normalerweise über dem aktiven Fenster befindet.

Bei Eigenschaftenfenstern bestimmt die Anzahl der Attribute die Größe. Wenn die Größe zu groß ist (ungefähr 1/4 der Anzeige), sollten Sie mehr Registerkarten verwenden.

Sitzungsinformationen

Alle Anwendungskonfigurationen müssen zwischen Sitzungen gespeichert werden (ohne dass dies vom Benutzer angegeben werden muss). Dies betrifft die Größe und die Position der Fenster, die ausgewählte Sicht und die Positionen der Schiebeleisten. Wenn Benutzer eine Anwendung erneut starten, muss sie danach genauso aussehen, wie sie sie verlassen haben. Das Motiv hierfür ist, dass Benutzer nach dem Starten einer Sitzung gewöhnlich dort weiterarbeiten möchte, wo er die letzte Sitzung verlassen hat.

Onlinehilfe

Onlinehilfe ist ein sehr wichtiger Teil des Systems. Eine wohl gestaltetes Hilfesystem sollte für die meisten Systeme sogar in der Lage sein, die Benutzerhandbücher zu ersetzen. Die meisten Projekte wenden viel Zeit und Mühe für die Erstellung und Produktion von Handbüchern auf, obwohl es eine bekannte Tatsache ist, dass die meisten Benutzer diese Handbücher nicht verwenden. Sie sollten überlegen, ob Sie diese Zeit und Mühen nicht stattdessen in ein gutes Hilfesystem investieren.

Es gibt zahlreiche Hilfewerkzeuge, die Sie in Erwägung ziehen sollten:

  • Die Hilfe zum Thema ist das wichtigste Hilfewerkzeug. In diesem Hilfewerkzeug kann der Benutzer ein Thema eingeben oder ein vorhandenes Thema mit unterstützenden Informationen anzeigen. Der Schlüssel ist die Bereitstellung eines umfangreichen Hilfeindex mit vielen Synonymen. Denken Sie daran, dass der Benutzer unter Umständen nicht den korrekten Begriff kennt, wenn er Hilfe benötigt.
  • Die Hilfe zum Objekt ist eine kontextbezogene Hilfe. Sie zeigt Text an, der einen bestimmten Teil (Objekt) der Benutzerschnittstelle erläutert. Der Benutzer fordert kontextbezogene Hilfe an und wählt dann den Teil der Benutzerschnittstelle aus, zu dem er Hilfe benötigt. Diese Art von Hilfe sollte für jeden Teil der Benutzerschnittstelle bereitgestellt werden, wenn dieser verwendbar sein soll. Eine andere Alternative ist die Bereitstellung einer impliziten Hilfe in Popup-Fenstern, eine komprimierte Form der kontextbezogenen Hilfe, die das System neben dem Cursor anzeigt, wenn der Benutzer für ein paar Sekunden auf dem jeweiligen Objekt verweilt. Die Verwendung impliziter Hilfe in Popup-Fenstern hat den Vorteil, dass sie den "Normalbetrieb" der Benutzerschnittstelle nicht stört.
  • Der Nachrichtenbereich ist ein Bereich (gewöhnlich im Hauptfenster), in dem das System nicht angeforderte "Kommentare" zu den Aktionen des Benutzers ausgibt. Der Nachrichtenbereich sollte, sofern er bereitgestellt wird, optional sein.
  • Assistenten sind eine gängige Technik, die Sie in Erwägung ziehen sollten, wenn der Benutzer Hilfe zur Ausführung bestimmter Aufgaben anfordert. Ein Assistent führt den Benutzer sozusagen "an der Hand" durch eine (nicht triviale) Aufgabe. Er zeigt beschreibenden Text zusammen mit Operationen (Schaltflächen) an, über die der Benutzer die Teile der Aufgaben ausführen kann, die im Text erläutert werden. Alternativ kann ein Assistent Fragen stellen und basierend auf den Antworten des Benutzers die Aufgabe automatisch ausführen. Assistenten eignen sich ausgezeichnet für Aufgaben, die nicht trivial und nicht häufig verwendet werden.

Der Bedarf an kontextbezogener Hilfe und Assistenten lässt sich am besten durch Tests feststellen. Wenn die Benutzer während der Tests die verschiedenen Teile der Benutzerschnittstelle nicht verstehen, ist dies ein Hinweis auf den Bedarf an kontextbezogener Hilfe. Wenn die Benutzer Schwierigkeiten haben, eine bestimmte Aufgabe auszuführen, ist dies ein Hinweis auf den Bedarf an Assistenten.

Das Problem bei vielen Hilfesystemen besteht darin, dass sie entweder für Benutzer mit wenig Vorkenntnissen (viel Text, der Offensichtliches erläutert) oder für Experten (Referenzhandbücher, die voraussetzen, dass der Benutzer nahezu soviel weiß wie der Programmierer, der die Anwendung erstellt hat) geschrieben sind. Bei den meisten Systemen sind die meisten Benutzer "fortgeschrittene Anfänger". Schreiben Sie die Hilfetexte für diese Benutzer.

Rückgängig machen

Die Funktion "Rückgängig machen" ist sehr hilfreich, obwohl sie im Allgemeinen schwierig zu implementieren ist. Diese Funktion erleichtert den Benutzern des Lernen, weil sie keine Angst davor haben müssen, etwas kaputt zu machen. Sie verringert auch das Risiko, Informationen zu verlieren. Ein Informationsverlust kann auch vermieden werden, indem vom Benutzer verlangt wird, alle Operationen zu bestätigen, die zu einem Informationsverlust führen könnten. Dies ist jedoch normalerweise eine schlechte Lösung, da sie erheblichen Interaktionsaufwand produziert und die Benutzer zu schnell lernen, Operationen unbewusst zu bestätigen, was diese Lösung relativ unzulänglich macht.

Eine ehrgeizige Möglichkeit ist die Bereitstellung einer zusätzlichen Wiederholungsfunktion und möglicherweise mehrerer Ebenen von "Rückgängig machen" und "Wiederholung". Allerdings trägt die erste Ebene von "Rückgängig machen" am meisten zu einer höheren Benutzerfreundlichkeit bei.

Makroagent

Wenn Sie Makros bereitstellen, kann es hilfreich sein, einen Agenten einzusetzen, der die Aktionen des Benutzers kontinuierlich überwacht und nach sich wiederholenden Interaktionssequenzen Ausschau hält. Sobald eine solche Interaktionssequenz gefunden wird, erstellt der Agent ein entsprechendes Makro (nach Einholung einer Genehmigung durch den Benutzer). Angenommen, der Benutzer hat die Operation "Unterstreichen" für zwei Textabsätze angefordert und beide Male hat er direkt nach der Anforderung auch die Textfarbe in blau geändert. In diesem Fall sollte der Agent den Benutzer fragen, ob er ein Makro haben möchte, das die Operationen "Unterstreichen" und "Farbe in blau ändern" für den ausgewählten Textabsatz durchführt. Wenn ja, sollte der Agent ein solches Makro und eine Schaltfläche (oder einen Menüpunkt) erstellen, die das Makro ausführt.

Wenn der Benutzer während der Aufzeichnung ein Objekt auswählt, sollte dies normalerweise als "Deltaspezifikation" interpretiert werden, d. h. welches Objekt im Vergleich zur vorherigen Auswahl ausgewählt wurde (z. B. "nächsten Eintrag auswählen", "ersten untergeordneten Eintrag auswählen" usw.).

Es ist nicht so offensichtlich, ob die Änderung der Attribute eines Objekts als Deltaspezifikation interpretiert werden sollte (z. B. die Änderung eines Attributs von 12 in 14 als Erhöhung um 2 oder als Einstellung auf 14 zu interpretieren). Die Interpretation als Deltaspezifikation ist gewöhnlich wirkungsvoller, da die Änderung eines Attributs für mehrere Objekte in einen festen Wert häufig so vorgenommen werden kann, dass mehrere Objekte ausgewählt werden und anschließend ein Attributfenster für diese Objekte geöffnet wird, in dem Sie das Attribut permanent (auf 14) einstellen.

Dynamische Hervorhebung

Relativ häufig sind Assoziationen zwischen Klassen bidirektional, d. h. in der echten Benutzerschnittstelle wird die Assoziation in beiden Objekten angezeigt. Wenn ein Benutzer, der sich auf Objekt A konzentriert, sehen kann, dass A dem Objekt B zugeordnet ist, ist der umgekehrte Fall für den Benutzer normalerweise auch interessant (d. h. wenn sich der Benutzer auf Objekt B konzentriert, kann er sehen, dass Objekt B dem Objekt A zugeordnet ist). Die Assoziation wird gewöhnlich in den Eigenschaftenfenstern der Objekte angezeigt, in denen das zugeordnete Objekt mit Namen angegeben ist.

Im Allgemeinen ist die Visualisierung von Assoziationen zwischen Objekten in einem Primärfenster eine knifflige Angelegenheit. Die Assoziationen als Pfeile oder Linien zu visualisieren, führt häufig zu einer relativ unattraktiven und aufdringlichen Darstellung. Eine elegante Methode zur Visualisierung von Assoziationen ist, alle zugeordneten Objekte hervorzuheben, wenn sich der Cursor über einem zuordnenden Objekt befindet. Diese Methode wird beispielsweise in einem Dokumenteditor angewendet, wenn Zeichen Fußnoten zugeordnet sind. Die Fußnoten werden hervorgehoben, sobald der Cursor auf das zugeordnete Zeichen bewegt wird.