Jetzt abonnieren!
15 Punkte — Usability im Web
Ständig liest man von diversen »Usability Experten« im Netz »die 10 größten Usability Fehler«, »Todsünden in Sachen Usability« und andere tolle Geschichten. Vieles davon kann ich sehr gut nachvollziehen, meine Sicht der Dinge, was meine persönlichen Usability-Empfindungen und Erfahrungswerte aus Gesprächen mit Kunden und Freunden angeht, möchte ich an dieser Stelle trotzdem einmal kund tun:
Schlecht gekennzeichnete Links
Ich finde fast nichts geht darüber, Links so zu kennzeichnen, dass diese nicht als solche zu erkennen sind. Da gibt es dann Beispiele, in denen dunkelgraue, nicht unterstrichene Links sich inmitten von schwarzem Fließtext befinden. Manuel sagt: So nicht!
Links sollten meiner Meinung nach, möglichst immer unterstrichen sein, oder in einer Textfarbe, die sich deutlich von sonstigen Auszeichnungen (wichtiger Text in Fett, noch wichtigerer Text in rot, etc …) unterscheidet.
Unterstrichener Text
Zusätzlich zur (im optimalen Fall benutzten) Unterstreichung von Links, sollten diese auch eine andere Farbe bekommen. Dies muss nicht wie Usability Gurus behaupten das standard Link-Blau sein, sollte sich aber dennoch merklich vom Fließtext abheben. Andernfalls sollte man auf unterstrichene Stellen im Text verzichten, und stattdessen auf die dafür vorgesehenen Elemente <em> oder <strong>, also kursiven oder fetten Text, für Auszeichnungen zurückgreifen. Auch wenn die Zeit, in der ein text-decoration: none; bei Links noch nicht möglich war bereits lange vorbei ist, so identifizieren sehr viele Leute, mich eingeschlossen, unterstrichene Stellen im Text auch weiterhin mit Verlinkungen.
Zu kleine Schrift
Wird von sehr vielen Designern viel zu häufig schlecht angewandt und verwendet. Schriftgrößen unter (je nach Schriftart) 12 bis maximal 11px sollten höchstens für Kleingedrucktes (daher wohl auch der Name!) benutzt werden. Kein Mensch tut sich freiwillig (am Monitor) einen längeren Text an, der in einer 10px Arial gesetzt ist. Beste Erfahrungen habe ich persönlich mit Schriftgrößen im Bereich von 12 — 16 Pixeln machen können, bei allem was darüber hinaus geht wird die Schrift an Windows PCs ohnehin hässlich zu fett.
Zu große Schrift
Nicht nur zu kleine Schrift kann sehr unleserlich sein, in letzter Zeit wurde ich häufig darauf angesprochen, warum ich so oft recht große Schriftgrade benutze. Und in der Tat, bei einer Zeilenlänge von 500 Pixeln ist eine 16 Pixel große Schrift definitiv zu viel. Entgegen Behauptungen von Fachbüchern, in denen sehr häufig eine Zeilenlänge von 40—60 Zeichen als optimal für den Bildschirm angegeben wird, bin ich der Meinung, dass mindestens 60 Zeichen bis maximal 90 Zeichen das Optimum sind.
Zu lange Zeilen / »Flüssige Layouts«
Seiten bei denen sich die Zeilenlänge an das Browserfenster anpasst sind in der Regel eine feine Erfindung. Dies jedoch nicht für Leute wie mich, die mit einer Bildschirmauflösung von 1600 × 1200 Pixeln unterwegs sind. Für diese Randgruppe wird das Lesen von Texten derartiger Internetseiten verdammt erschwert. Ich ziehe mir jedenfalls in diesen Fällen in der Regel das Browserfenster kleiner, oder skaliere die meist ohnehin schon recht große Schrift. Für uns Webentwickler wurde vom W3C daher das extrem praktische max-width als CSS 2.1 Standard verabschiedet. Mein Tipp für Textcontainer: width: 100%; max-width: 600px; (Werte beliebig austauschbar ;) )
Zeilenhöhe auf Standardwert
Standardmäßig beträgt die Zeilenhöhe im Browser 1em, also der angegebenen Schriftgröße für einen Text. Unabhängig von der Schriftgröße hängt Text dabei jedoch sehr eng »aufeinander«, das Auge verrutscht daher beim Lesen sehr schnell in der Zeile, was ein angenehmes Lesen sehr erschwert. Faustregel ist hier, Zeilenabstand mindestens so groß wie der Abstand zwischen zwei Wörtern. Ist das Leerzeichen in der eingestellten Schriftgröße also 4 Pixel breit, sollte der Abstand der Zeilen ebenfalls mindestens 4 Pixel betragen. Gute Erfahrungen habe ich hier mit Werten zwischen 130 — 160 % gemacht.
Nervige PDF-Downloads im Browserfenster
Fast jeder kennt es, man klickt einen Link, dieser ist aber zufällig ein Speicherintensives PDF, und die nächsten 30 Sekunden reagiert der eigene Browser somit mal einfach garnicht. Dies muss nicht sein, Links zu PDFs sollte man daher immer kennzeichnen. Dies funktioniert bei anständigen Browsern meistens mit einer Zeile CSS-Code automatisch. Wie genau das gemacht wird, beschrieb ich bereits vor einiger Zeit in einem anderen Artikel.
»Links zu PDFs im Browser kenntlich machen«
Deaktivierte Navigationspunkte
Darüber streiten sich die Geister, sicherlich gibt es Vorteile, aber auch Nachteile. In meinen Augen überwiegen jedoch, aus Usability-Sicht, klar die Nachteile. Es geht darum ob Links zu aktuell angewählten Menüpunkten weiterhin »klickbar« bleiben. Ein Vorteil soll ja sein, dass man klar erkennt in welcher Rubrik der Seite man sich befindet. Für meinen Teil allerdings nicht wirklich nachvollziehbar, da man derartige Kennzeichnungen auch auf Links anwenden kann. Ein klares Argument dafür, gewählte Menüpunkte aktiv zu lassen, also den Link in die Rubrik nicht zu entfernen, ist auf jeden Fall, dass man auch bei nicht vorhandener Brotkrumen-Navigation stets auf die oberste Ebene zurückkommt, sollte man sich auf einer Unterseite befinden. Meine Empfehlung daher: Links von gewählten Menüpunkten immer Link bleiben lassen.
JavaScript Links
Auch dies ist in meinen Augen eins der schwersten Verbrechen was Web-Usability angeht: Links über die der User keine Kontrolle hat. Solche Links haben meist die Form:
<a href="javascript:neuesFenster('start.html');">, <a href="javascript:void();" onclick="window.open('seite2.html');" > oder ganz pervers: <a href="javascript:showpage(6671379);">. Doch auch das muss nicht sein. Dem User wird somit zum einen die Möglichkeit genommen Links während des Lesens im neuen Fenster (Shift+Mausklick), oder im neuen Tab (Strg+Mausklick oder mittlere Maustaste) zu öffnen, zum anderen haben User mit deaktiviertem JavaScript oftmals keine Chance durch die Seite zu navigieren. Dieses Usability-Ungeheuer trifft man all zu häufig in automatisch generierten Bildergalerien an, in denen es damit nicht möglich ist sich schnell hintereinander mehrere Bilder in Tabs anzeigen zu lassen. Aber auch komplexe CMS’ erzeugen teilweise derartige »Un-Links«. Dabei gibt es eine, unglücklicherweise immer noch recht unbekannte Möglichkeit, Links in neuen Fenstern zu öffnen, ohne dabei User auszuschließen oder in ihrer Entscheidungsfreiheit einzuschränken. Auch dazu schrieb ich bereits vor einiger Zeit einen kleinen Artikel
»Neues Fenster für Links unter xhtml 1.0 strict«
Jede Funktion sollte damit eigentlich so umgeschrieben werden können, dass der onclick-Handler nur bei eingeschaltetem JavaScript ein neues Fenster öffnet, die Seite dadurch aber für jedermann benutzbar bleibt.
Sperre der rechten Maustaste
Gerne wird auch heute noch bei einigen Seiten die rechte Maustaste blockiert (dabei ist der »Trick« ja schon sooowas von ausgelutscht …). Dies soll zumeist »Diebe« daran hindern an bestimmte Snippets im Quelltext, oder an Grafiken zu gelangen. Oftmals wissen entsprechende Seitenbetreiber nicht, dass sich das Bild zum Zeitpunkt in dem es angezeigt wird, bereits auf der Festplatte im Browsercache befindet. Eine solche »Funktion« hindert aber niemanden daran ein Bild, spätestens mittels Screenshot, zu klauen. Jedoch hindert es Leute die über das Kontextmenü Textpassagen kopieren, oder die Seite lokal speichern möchten. Ganz davon abgesehen gibt es mittlerweile glücklicherweise Extensions mit denen die Funktion der rechten Maustaste uneingeschränkt erhalten bleibt.
Flashseiten, Music-Player und keine Stop-Funktion
Ich weiß ja nicht ob ich die Funktion im Flashplayer noch nicht gefunden habe weil ich sie einfach nicht gefunden habe, oder weil es sie schlicht nicht gibt. Jedenfalls kann ich nicht behaupten nicht gesucht zu haben. Aber ich höre in der Regel, wenn ich am Rechner sitze Musik über WinAmp. Wenn ich eine Seite aufrufe, auf der Musik im Hintergrund läuft, dann find ich das ja ganz nett, allerdings steh ich nicht gerade auf »Sandwich-Composings« was Musikstücke angeht. Sprich, ich muss entweder mein WinAmp ausschalten, oder die Musik der Website. Da ich mir die Musik die ich höre generell ganz gerne selbst aussuche, ist es nicht selten vorgekommen das ich eine Seite die ich besucht habe genauso schnell wieder verlassen habe, wie ich gekommen bin — auf Grund des fehlenden Stop-Buttons. Daher: Musik, aber kein Ton-Aus-Knopf = Todsünde!
Reine Infoseiten + Flashtext
Im Gegensatz zu leider scheinbar sehr vielen Flash-Entwicklern weiß ich, dass es möglich ist, Texte in Flash dynamisch so einzubinden, dass diese hinterher problemlos aus dem Flashfilm mit der Maus kopiert werden können. Leider sieht man jedoch sehr häufig auf Seiten, auf denen ich die ein oder andere Textpassage kopieren und weiterverschicken möchte so statisch ist, dass mir nichts anderes übrig bleibt, als den Text abzutippen. Böser Fehler, vor allem auf Seiten die auf Grund des Lehrgehalts ein kopieren zulassen sollten.
Falsche Ordnung des Tabindex’
In der Regel geht ein Browser Formular-Eingabefelder in der Reihenfolge durch, in der sie im Quelltext stehen. Ausnahmen gibt es, wenn für einige Elemente das Attribut tabindex gesetzt ist. Generell ist gegen die Benutzung von tabindex nichts einzuwenden. Jedoch sollte man darauf achten, dass die Reihenfolge des Index in einer logischen Reihenfolge bleibt. Habe ich beispielsweise ein Formular in dem ich abwechselnd Pflichtfelder und optionale Felder habe, wäre es sehr unklug erst die Pflichtfelder, und dann erst die optionalen Felder anzuspringen. Es würde schlichtweg zu lange dauern, bis ein User wahrgenommen hat, dass der Cursor bereits 2 Felder weiter ist.
Unklug belegte Accesskeys
Beim Gebrauch von Accesskeys sollte man vorsichtig sein, denn schnell kommt es zu Konflikten mit Browserinternen Shortcuts. Habe ich auf einer Seite einen Link »Deutsche Version«, sollte ich mir zweimal überlegen ob ich den entsprechenden Accesskey auf D lege, oder ob ich meinen Usern die Option offen lasse, mittels ALT+D das Datei-Menü in meinem Browser aufzurufen.
Zu lange oder zu allgemeine Seitentitel
Google und auch andere Suchmaschinen mögen das title-Element. Ich mag das Teil auch. Denn ebenso mag ich es, wenn ich in meinen Bookmarks, von denen mir in der Übersicht rund 40 Zeichen des Seitentitels der gebookmarkten Seite angezeigt werden, sehen kann, um welche Seite und evtl. sogar Unterseite es sich handelt. Ein guter Titel hätte demnach kurz und prägnant in etwa die Form:
ManuelBieh.de » Weblog » Usability. Ich sehe so bereits auf dem ersten Blick welche Seite gemeint ist, und muss nicht erst das erweiterte Lesezeichenmenü meines Firefox öffnen. Zusätzliche Beschreibungen im Titel sind in meinen Augen aber ebenfalls ok, und oft sogar von Vorteil. So könnte ich, wenn ich den genauen Namen einer gesuchten Seite nicht mehr weiß, ich aber weiß das sie sich in meinen Bookmarks befindet, ganz einfach nach einigen Keywords suchen. Dazu könnte sich ein Titel in etwa der Form ManuelBieh.de » Weblog » Usability, Benutzerfreundlichkeit im Internet, Accessibility unter Umständen sehr gut eignen. Zum einen für Suchmaschinen, zum anderen für den User, der auf den ersten Blick klar erkennt worum es geht, aber auch die Möglichkeit hat nach vielen Schlagworten innerhalb seiner Bookmarks zu suchen.
Die angesprochenen Punkte sind wie erwähnt lediglich Erfahrungswerte von mir, Kunden und auch Freunden. Ich habe bisher keinerlei größeren Befragungen oder Beobachtungen bei Dritten angestellt. Die Liste ist für mich aber recht plausibel, und ich würde gerne mit Euch über die Punkte diskutieren, denen Ihr nicht zustimmt oder bei denen Ihr der Meinung seid das sie definitiv fehlen. Ich habe mich jedenfalls beim Schreiben am »durchschnittlichen« Internetuser orientiert, mich also bemüht aus der Sicht von Computer Neulingen, aber auch von Computerversierten Nutzern zu sprechen. Spezielle Dinge, die die Erstellung barrierefreier- oder Flash-Seiten betreffen, habe ich bewusst erstmal aussen vor gelassen, beziehungsweise nur angeschnitten. Dürfen aber selbstverständlich gerne mitdiskutiert werden.
