|
In einfacheren Zeiten gab es einen Satz Richtlinien für Websites und einen anderen Satz Richtlinien für
Anwendungen. Und die beiden waren klar zu unterscheiden. Zum Beispiel gab es unterschiedliche Regeln, um die Optionen der Benutzer anzuzeigen:
Die Richtlinien für Websites und Anwendungen waren unterschiedlich (und sind nach wie vor unterschiedlich) aufgrund eines uralten Usability-Grundsatzes: Gutes Design hängt (a) von den Benutzern und (b) von den Aufgaben ab. Websites und Anwendungen unterscheiden sich in der letzteren Hinsicht fundamental:
-
Bei Websites besteht die Hauptaufgabe der Benutzer darin, sich
in einem Informationsraum hin- und herzubewegen und seine Inhalte zu lesen.
-
Bei Anwendungen besteht die Hauptaufgabe des Benutzers darin, den
Zustand eines bestehenden Datensatzes mit Hilfe von Befehlen zu verändern.
In der Tat entspricht es der eigentlichen Definition einer Anwendung, dass ihre Funktionen etwas Externes in den Bereich der eigenen Benutzeroberfläche hineinziehen. Wenn man eine Anwendung benutzt, ändert sich dadurch etwas, weil der Benutzer etwas ändern will. Eine Website dagegen ändert sich nicht durch ihren blossen Gebrauch; die Seiten bleiben immer die selben. (Auch wenn sich die Informationen ändern, sind Webseiten vom Konzept her statisch. Eine Seite mit der Wettervorhersage für morgen z. B. enthält immer diese Information, auch dann, wenn sie an einem Tag das Symbol für Regen, an einem anderen Tag das Symbol für Sonnenschein anzeigt.)
Die Trennlinie zwischen Anwendungen und Websites verwischt
In den vergangenen zehn Jahren wurde der klare Unterschied zwischen Websites und Anwendungen verwischt.
Zunächst haben die Websites auf semantischer Ebene immer mehr Funktionen angeboten. Die erste weit verbreitete Funktion war: „In den Warenkorb“, und es war immer eine Richtlinie für
E-Commerce-Usability, diese Funktion als Button anzuzeigen, auch wenn sie sich auf einer Website befand.
Mithin sollten Sie bei Anwendungs-Komponenten – also solchen, die eher Funktionen oder Befehle darstellen als reine Informationen – die Richtlinien für
Anwendungs-Usability befolgen (wie z. B. bei der Funktion „In den Warenkorb“).
Das zweite Thema ist schwerer zu behandeln: Auf der Syntax-Ebene wurde die Grenze zwischen Buttons und Links verwischt, weil einige Befehle als Links angezeigt werden.
Zum Glück haben wir wenigstens eine klare Regel: Verwenden Sie keine Buttons für die Navigation. Um zu einer anderen Seite mit Informationen zu gelangen, sollten die Benutzer einen einfachen Link anklicken.
Doch auch zu dieser Regel gibt es eine Ausnahme: Die Optionen „Einkauf fortsetzen“ und „Zur Kasse“ auf der Warenkorb-Seite werden traditionell als Buttons angezeigt, obwohl sie reine Navigationsschritte sind. Nichts ändert sich, wenn man eine dieser Optionen anklickt – es erscheint lediglich eine neue Seite, die die gewünschten Befehle enthält. Doch da die Kasse Teil eines Arbeitsprozesses ist, hat sie einen Passierschein, der sie aus der
Navigation-durch-Link-Regel entlässt.
Doch im Allgemeinen lautet die Regel, Links zu verwenden, wenn die Benutzer sich von Seite zu Seite
bewegen. Das hat unter anderem den Vorteil, dass die Benutzer die neue Seite je nach Wunsch in einem neuen Tab oder einem neuen Fenster öffnen können, und dass man die Links in unterschiedlichen Farben anzeigen kann, je nach dem, ob der Benutzer das Ziel schon einmal besucht hat oder nicht.
Richtlinien für das Design von Befehls-Links
Windows Vista hat einen neuen Bedienungshebel für Befehle eingeführt: den
Befehls-Link. Sobald sich etwas in dem System befindet, das die Leute im Alltag verwenden, wird es zum
De-facto-Standard. Da sie ihnen in Windows Vista häufig begegnen, kennen die Benutzer Befehls-Links und erwarten sie zu finden.
Viele Websites verwenden bereits Links für Befehle. Zwar wird den Benutzern in zunehmendem Masse bewusst, dass Links einen Befehl auslösen können, doch es besteht noch das Risiko der Verwirrung, da die meisten Links zur Navigation gehören.
Um Verwirrung zu vermeiden, sollte der Link-Text ausdrücklich
festhalten, dass der
Link zu einem Befehl führt und nicht bloss zu einer neuen Seite. Es reicht nicht, diese Information im umgebenden Text mitzuteilen; die Benutzer scannen Webseiten oft nach Bereichen, in denen sie etwas tun können. Deshalb sollten Sie davon ausgehen, dass die meisten Benutzer nur den Link-Text lesen werden. In der Tat lesen die Benutzer oft nur die ersten paar Wörter des Link-Textes, deshalb ist es wichtig, dass Sie
mit einem Wort beginnen (in der Regel einem Verb), das
die Aktion anzeigt, die passiert, wenn man den Link anklickt.
Was die Gross- und Kleinschreibung betrifft [Anmerkung der
Übersetzung: gemeint ist hier die Gross- und Kleinschreibung von Namen, Überschriften u. ä. im Englischen], halten Sie sich an die Richtlinien für normale Links in Ihrem Firmen- oder
Institutions- Styleguide. Wenn Sie keinen Styleguide haben, verwenden Sie die satztypische Gross- und Kleinschschreibung (das heisst: Sie schreiben nur den ersten Buchstaben des ersten Wortes der Befehlsbezeichnung gross). Eine Ausnahme wäre ein Textlink innerhalb eines ihn umgebenden Satzes. Es ist aber normalerweise besser, innerhalb des Fliesstextes Befehls-Links zu vermeiden; solche Textlinks sollten auf die Navigation begrenzt sein.
Beschränken Sie die Verwendung von Befehls-Links auf:
- Aktionen mit eher geringfügigen Konsequenzen, da die Benutzer möglicherweise etwas anklicken, was wie ein Link aussieht, weil sie erwarten, dass dadurch nur eine neue Seite aufgerufen wird. In einer
Börsen-Anwendung zum Beispiel sollten Sie den Befehl „Diese Aktie kaufen“ weiterhin als Button
anzeigen.
- Zweitrangige Befehle, da die Benutzer den Bildschirm nach einem Button absuchen werden, wenn sie einen „ernsten“ oder wichtigen Befehl suchen. Sie sollten also die wichtigsten Befehle – sei es aus der Perspektive der Benutzer, sei es aus Ihrer Perspektive – als Buttons präsentieren. Verwenden Sie zum Beispiel weiterhin einen Button für „In den Warenkorb“.
Trotz dieser Beschränkungen haben Befehls-Links ihren Platz, weil sie einige Vorteile mit sich bringen. Besonders bemerkenswert: Bei einem Link können Sie einen
längeren Befehlsnamen unterbringen und so die beschreibende Qualität verbessern; Bezeichnungen in Buttons müssen dagegen kurz sein (höchstens vier kurze Wörter), sonst sieht der Button unförmig aus. Natürlich sollten Sie die Befehlsbeschreibungen weiterhin so kurz wie möglich halten, da die Benutzer ungern lesen.
Vista stellt einen weiteren Vorteil von Befehls-Links heraus: die Möglichkeit, zusätzlichen erklärenden Text unterhalb des
primären Linktextes unterzubringen. Sie können diese Erläuterung in einer kleineren Schrift präsentieren, um ihre sekundäre Natur zu betonen (damit erfahrene Benutzer keine Zeit damit verlieren, sie zu lesen). Da Buttons eingekapselt und in sich abgeschlossen sind, ist es schwerer, einen erklärenden Text zu einem Befehls-Button hinzuzufügen. Und wenn Sie es tun, werden viele Benutzer ihn wahrscheinlich übersehen.
Die Zeit ist gekommen, einige Ihrer Befehle als Links anzuzeigen. Aber übertreiben Sie es nicht.
|