Webstandards? Die größere Baustelle sind die Mailstandards

HTML gibt's nicht nur im Web, auch Mails kann man als HTML verschicken. Hier hat man durchaus den Eindruck, dass ständig Rückschritte gemacht werden: Outlook 2007 beispielsweise verwendet unter anderem »aus Sicherheitsgründen« Word als Rendering-Engine für HTML-Mails. Was spricht gegen eine vernünftige Browser-Rendering-Engine in allen E-Mail-Clients nur ohne JavaScript-Unterstützung und Verzicht auf einige möglicherweise kritische Elemente – bspw. object? Wer schonmal einen HTML-Newsletter bauen durfte, der in einer Vielzahl von Mail-Clients funktionieren musste, unterschreibt diese Forderung sofort.

Stefan Walter ist seit 1999 professionell als Webdesigner- und entwickler tätig. Er arbeitet derzeit bei IBM Internet Security Systems in Kassel als Webentwickler.

Eine neue Denke

Ich glaube 2009 sollten wir vor allem für eine neue Denkweise sorgen, nicht mehr mit dem erhobenen Zeigefinger durch die Welt laufen und überwiegend kritisieren, sondern positive Beispiele für gute, moderne Webentwicklung geben, die auch wirkliche Probleme lösen kann. Wir sollten vermitteln, dass modernes Webdesign cool ist und Spaß macht, und es mehr Möglichkeiten gibt als traditionellere Entwicklungsmethoden. Und wir sollten das offene Web, offene APIs benutzen, um Probleme zu lösen.

Eric Eggert macht Web und bloggt darüber. Seine Schwerpunkte liegen auf Semantik, Microformats und Zukunfts-Technologien wie HTML5.

Authentischer Wahlkampf im Web 2.0 gesucht!

2009 ist Wahljahr. Die Bundestagswahl wird viele Monate die Medien und damit auch das Netzgeschehen beeinflussen. Mein Wunsch ist, dass Politiker sich nicht nur oberflächlich mittels aufwändig produzierter Video-, Audio- oder Textbeiträge ins Netz einklinken. Echte Volksnähe wären für mich ehrliche Weblogs oder Twitter-Accounts, die nicht von Pressesprechern gefüllt werden. Kleine Vorbilder gab es dafür ja schon 2008. Klar, dass wir in Deutschland von einem Netzwahlkampf wie in den USA weit entfernt sind. Ich würde gerne authentische Politiker, wenn das überhaupt möglich ist, im Internet antreffen. Meine Wahlentscheidung würde das sicher mehr beeinflussen als Plakate und TV-Spots.

Johannes Ries schreibt unter metafakten.de über Netzgeschehen und freie Software.

Saubere Basis

Eine schnelle Veröffentlichung des Internet Explorer 8 und ein wirklich überzeugendes Windows 7 werden endlich auch die Systemadministratoren anspornen, ihre völlig veraltete Systemarchitektur mit dem IE6 in die Rente zu schicken. Wenn das soweit ist, haben wir eine saubere Basis auf der wir innovative und kreative Produkte aufbauen können. Die Tools dafür gibt es bereits heute schon. Es fehlt einzig die Offenheit für Neues, Unerwartetes.

David Maciejewski ist Teamlead Frontend Developer in Hannover, Verfechter sauberen Handwerks und Missionar in seinem Webstandards-Podcast Technikwürze.

Abgerundete Ecken in IE8 und Opera

Eigentlich ein bescheidener Wunsch, und auch so naheliegend: Nachdem die letzten 4 Jahre Web2.0-Kultur allen Beteiligten gezeigt haben, dass abgerundete Ecken ein wichtiges und nützliches Stilmittel für Webdesigner sind, sollten sich nun endlich alle Browserhersteller genötigt fühlen, diese auch per reinem CSS zu ermöglichen. Safari und Firefox machen vor, dass es gut funktionieren kann: Schicke, geglättete und wirklich einfach handhabbare Eckenveredelungen kann man hier schon heute produktiv nutzen. Und es ist ja nicht so, dass es dafür noch keinen Webstandard in Form von CSS 3 gäbe. Er ist eben nur noch nicht verabschiedet. Aber ist das wirklich ein Hinderungsgrund, es nicht trotzdem zu implementieren?

Gerrit van Aaken, Dipl.-Des. (FH), arbeitet als freier Webdesigner und veröffentlicht auf praegnanz.de populäre Fachartikel über alle Aspekte des modernen Web.

Erwachsene Web-Frameworks statt Plugin-Frickeleien

Ich wünsche mir einen weiteren Siegeszug der »standardisierten« Web-Frameworks wie Rails oder Django. Damit das »Reinfrickeln« von Funktionalitäten in proprietäre Plugin-Schnittstellen der vorwiegend PHP-basierten CMS-Systeme aufhört und auch die Web-Entwicklung sich langsam aber sicher auf in der restlichen Welt der Programmierung längst übliche Standards einlässt. Und damit die Qualität auch kleinerer Web-Anwendungen einen deutlichen Sprung nach vorne macht.

Ralf Graf ist ein freier Web-Entwickler aus Karlsruhe, realisiert Web-Sites und -Anwendungen mit Webstandards, Ruby On Rails und PHP und bloggt.

Erst die Benutzer, dann der Auftraggeber

Wir haben die letzten 10 Jahre damit verbracht, die Technologie immer weiter zu entwickeln, und stehen mit CSS 3 kurz vor der Umsetzung des nächsten großen Schrittes. Es wird Zeit, unsere Aufmerksamkeit auf die Menschen zu richten, für die wir eigentlich Webseiten entwickeln: die Nutzer.

Es ist herzlich egal, ob eine Webseite Flash, Silverlight, runde Ecken oder Web zwo-nullige Schaltflächen benutzt. Am Ende zählt nur, welchen Nutzen dem Be-Nutzer geboten wird. Ein kritischer Blick auf eigene und fremde Projekte offenbart oftmals die ganze Bandbreite der Grausamkeit: verspielte Navigationskonzepte ohne Gebrauchswert, vom Marketing zur Unkenntlichkeit misshandelte Texte sowie die generelle Fokusierung auf die Bedürfnisse des Auftraggebers unter Missachtung der Nutzer. Webseiten sollten Spaß machen – davon sind wir zur Zeit oftmals noch weit entfernt.

Bernhard Welzel

IE nutzt Webkit

Vor ein paar Wochen erklärte Microsoft-Chef Steve Ballmer auf einer Entwicklerkonferenz in Sydney: »Open Source ist interessant. Apple hat sich das Webkit zu eigen gemacht, und wir werden uns das vielleicht ansehen, aber wir werden weiterhin Erweiterungen für den IE8 entwicklen.« (O-Ton)

Das heißt nun nicht, dass der IE8 plötzlich mit einer Open-Source-Rendering-Engine daher kommt. Aber die Tatsache, dass sich Microsoft zumindest andere Engines ansehen möchte, gibt mir Hoffnung, dass einer der nächsten IEs vielleicht nicht mehr mit Microsofts Trident-Engine laufen wird. Und weniger Engines bedeuten für Webentwickler weniger Arbeit.
Ich werd' noch hoffen dürfen…

Nicolai Schwarz bastelt unter dem Namen textformer mediendesign an Corporate Designs und konzipiert Webseiten. Gelegentlich schreibt er darüber.

Mehr Schriften im Web

Es sollte möglichst schnell eine Lösung für das Schriftproblem im Web gefunden werden. sIFR und Typeface sind sehr unelegante Wege beliebige Schriftarten ins Web zu bringen. @font-face birgt leider noch zu viele rechtliche Untiefen. Es sollte eine Möglichkeit gefunden werden, mit der alle Parteien zufrieden sind.

Moritz Gießmann

Mobiles Browsen

Die fortschreitende Mobilisierung des Internets bringt auch neue Herausforderungen an das Webdesign, nicht nur durch die kleineren Bildschirme, sondern auch, weil auf der ein oder anderen Plattform etablierte Techniken nicht zur Verfügung stehen, etwa Flash auf dem iPhone. Mit der Veröffentlichung des Internet Explorer 8 hat man aber zumindest im Desktop-Bereich erstmals eine Basis, auf der man wirklich aufbauen kann. Bleibt zu hoffen, dass die auf den mobilen Plattformen erscheinenden Browser uns hier nicht wieder einen oder gar zwei Schritte zurückwerfen. Und dass sich niemand auf den Lorbeeren ausruht, sondern die Entwicklung der Browser weiter in dem Tempo voranschreitet, wie es aktuell der Fall ist, um realistische Perspektiven für nahezu flächendeckende Unterstützung neuer Technologien aufzuzeigen, etwa CSS3.

Matthias Slovig

Open-Source-Browser

Ich schätze, dass ein größerer Anteil von Open-Source-Browsern das Web voranbringen würden. Denn sie sind es vor allem, die mit den heutigen Webstandards am ehesten Schritt halten können. Je größer ihr Anteil ist, desto eher werden sich heutige (Quasi-) Standards auch in der Praxis nutzen lassen.

Markus Wulftange

Was hat sich in diesem Jahr im Netz getan? Wir haben die Webkrauts gefragt: Welcher Trend, welches Ereignis, welches Produkt hat Dich 2008 besonders beeindruckt?

JavaScript-Performance-Gewinne

Mich haben vor allem die Fortschritte in Sachen JavaScript-Performance (SqirrelFish, TraceMonkey und V8) beeindruckt. Und obwohl bereits teilweise Steigerungen um bis zu 1000% erreicht sind, scheint das noch nicht das Ende zu sein.
Damit kann zukünftig mit noch komplexere Web-Anwendungen mit umfangreicheren Echtzeit-Funktionen gerechnet werden, wie sie heutzutage hauptsächlich im Desktop-Bereich anzutreffen sind.

Markus Wulftange

Datenschmutz?!

Wenn ich auf das Jahr 2008 zurückblicke, denke ich sofort an die öffentliche Debatte um Datenschutz. Das Internet und seine Gewächse waren für mich mehr als zuvor im Hinblick auf die »richtige Nutzung« in den Massenmedien zu finden. Ob in Talkrunden, in den Nachrichten oder den vielen politischen und gesellschaftsbeobachtenden Magazinen:

Sensibilisierung im Umgang mit Daten, besonders im Internet, war großes Thema und besonders Seitenbetreiber, aber auch Entwickler und Designer machten sich neue Gedanken. Die Frage, die ich mir dabei stelle ist, ob das ein günstiger Zug war, auf den die Zeitungen und Fernsehanstalten aufsprangen, oder ob wirkliches Informationsinteresse die Motivation war, welches nicht beim »nächsten Eisbär« wieder nur in den Randspalten der Technikseite großer Zeitungen zu finden ist.

Johannes Ries schreibt unter metafakten.de über Netzgeschehen und freie Software.

Webfonts

Vor zehn Jahren erfunden, jedoch niemals produktiv genutzt, konnte sich die Webfonts-Technologie im Jahr 2008 nun endlich neu erschaffen! Den Anfang machte die WebKit-Engine bereits im Oktober 2007 – und seit März 2008 kann sich jedermann die aktuelle Version von Safari herunterladen, welche auf Websites beliebige verlinkte Schriften im TrueType- oder OpenType-Format darstellen kann. Firefox steht derzeit mit Version 3.1 in den Startlöchern und leistet ganz Ähnliches. Und als wäre das noch nicht genug, wird beim W3C derzeit mit Browserentwicklern und Schrifthäusern wild diskutiert, auf welche Weise man die neue Schriftenvielfalt im Netz zu einem ordentlichen Webstandard machen kann. Der wichtige erste Schritt ist also getan, und auch nächstes Jahr wird hier einiges passieren, wollen wir wetten?

Gerrit van Aaken, Dipl.-Des. (FH), arbeitet als freier Webdesigner und veröffentlicht auf praegnanz.de populäre Fachartikel über alle Aspekte des modernen Web.

JavaScript für alles

JavaScript ersetzt zunehmend viele andere Technologien. Typeface macht sich auf den Weg sIFR zu ersetzen. JavaScript Frameworks wie etwa jQuery ersetzen, mit diversen Plugins versehen, Flash Anwendungen. Ein schönes Beispiel dafür ist das jQuery Galeriescript Gallerific. IE7-js versucht sogar dem IE6 teilweise Webstandards beizubringen.

Moritz Gießmann

Videos überall

Ich sehe eine Tendenz, auch kleine Webseiten mit Videos aufzupäppeln. Kurze Vorstellungen des Unternehmens, persönliche Begrüßungen durch Mitarbeiter, Produktpräsentationen oder auch mal ein kleiner Image-Film. Was vor ein paar Jahren noch eher größeren Unternehmen vorbehalten war, wird nun auch für kleinere Firmen interessant.

Eine gute Sache. Denn während es bei Text noch zu oft um BlaBla geht oder JavaScript-Funktionen mitunter nur genutzt werden, damit sich etwas bewegt, geht es bei den Videos (meistens) um wirkliche Inhalte, um eine andere Möglichkeit, Kunden und Nutzer einer Webseite anzusprechen.
Sicher nicht die schlechteste Zeit, um sich auf Videos und Image-Filme für Unternehmen zu spezialisieren.

Nicolai Schwarz bastelt unter dem Namen textformer mediendesign an Corporate Designs und konzipiert Webseiten. Gelegentlich schreibt er darüber.

Standortbezogene Dienste

Apple hat es mit dem iPhone vorgemacht, viele andere, darunter auch Google mit Android, werden auf den Zug aufspringen oder haben das schon getan. Neben dem Browsen auf dem Handy ist vor allem auch die Nutzung standortbezogener Dienste (Location Based Services, LBS) endlich nicht nur mehr ein Hirngespinst, sondern wirklich beim Endnutzer angekommen. Das Angebot an Programmen beispielsweise in Apples AppStore, die von einfachen »Wo bin ich«-Funktionalitäten bis hin zur Fahrplansuche unter Berücksichtigung von Zeit und Standort die komplette Bandbreite von LBS bieten, ist nur ein Indiz dafür.

Matthias Slovig

Das Jahr des mobilen Webs

2008 war das Jahr, in dem, iPhone sei Dank, die mobile Nutzung des Webs mit »richtigen« Browsern auch auf kleinen Schirmen fast schon »Mainstream« geworden ist. Und wer auf Webstandards setzte, dessen Seiten funktionieren auch »mobil« zufriedenstellend. Evtl. notwendige Anpassungen lassen sich mit geringem Aufwand realisieren. Ein weiterer Pluspunkt für sauberen Code.

Ralf Graf ist ein freier Web-Entwickler aus Karlsruhe, realisiert Web-Sites und -Anwendungen mit Webstandards, Ruby On Rails und PHP und bloggt.

Bessere Browser

Die Weiterentwicklung der Browser hat mich beeindruckt, Webkit hat den modernen Browsern ein Momentum zur Weiterentwicklung gegeben, Javascript wird immer, immer schneller und mit dem IE8 werden wir (auf lange Sicht) ein nicht-Standard-konformes Stiefkind los. Außerdem gaben uns neue experimentelle CSS3-Eigenschaften und -Funktionen einen Einblick in das Webdesign der Zukunft.

Eric Eggert macht Web und bloggt darüber. Seine Schwerpunkte liegen auf Semantik, Microformats und Zukunfts-Technologien wie HTML5.

iPhone – Internet Anywhere

Die einschneidenste Verändung in diesem Jahr war die Integration des iPhone in mein Leben. Genauer gesagt: viele Aktivitäten habe ich an das iPhone angepasst. Außerordentlich praktisch sind die bereits bekannten Funktionen wie E-Mail, Adressbuch, Kalender und der einfache Abgleich mit verschiedenen Programmen. Da ich mich oft verlaufe habe ich insbesondere die GPS gestützte Darstellung von Karten sehr zu schätzen gelernt. Revolutionär ist der kinderleichte und sehr gut zu nutzende Internetbrowser. Jederzeit und (fast) überall auf das Internet zugreifen zu können verändert sehr massiv wie ich mit einer Umwelt und anderen Menschen interagiere. Jeden Tag kommen neue, nützliche iPhone – Anwendungen hinzu, welche mein Leben einfacher gestalten und mir ganz neue Möglichkeiten bieten wie beispielsweise ortsbezogene Umkreissuchen. Ich hoffe dieser Trend setzt sich in 2009 fort und schlägt auch auf das Webdesign durch.

Bernhard Welzel

Mehr Möglichkeiten mit MODx

Das Redaktionssystem MODx entwickelt sich zu einem mächtigen Werkzeug für Webentwickler. Aufgrund der hohen Flexibilität dieses noch relativ jungen PHP/MySQL-Frameworks, ermöglicht es eine individuelle Anpassung und Umsetzung auch anspruchsvoller Webauftritte. Der Output ist zu 100 Prozent beeinflussbar, es bereitet Freude mit dem CMF zu arbeiten. Eine standardkonforme und zugängliche Lösung wird unproblematisch durch eigene leicht zu erstellende Templates erreicht. Schon jetzt dürfen wir uns auf die MODx-Version Revolution freuen.

Matthias Koch ist Webentwickler mit pädagogischem Hintergrund, Buchautor und bei FINALNET in Freiburg im Breisgau tätig.

Quantität und Qualität

Leider ist es 2008 zum Trend geworden, dass jeder sein eigenes jQuery-Plugin schreibt, jeder den heiligen Gral gefunden haben möchte, wie man am besten HTML und CSS schreibt und bei wie vielen Diensten man einen eigenen Account eingerichtet hat. Viel Grundrauschen im Blätterwald, wenig Qualität.
Dennoch gibt es noch wahre Perlen: Das iPhone mit einem »echten Browser« und Browserhersteller, die mal neue Dinge ausprobieren und implementieren. Hier wird nicht jahrelang diskutiert und alles zu Tode diskutiert, sondern gehandelt.

David Maciejewski ist Teamlead Frontend Developer in Hannover, Verfechter sauberen Handwerks und Missionar in seinem Webstandards-Podcast Technikwürze.

Insbesondere, wenn man seine Schriftgrößen nicht in Pixel definiert, kann man sich nicht immer sicher sein, ob sich nicht Schriftgrößen ungewollt multipliziert haben oder ob man richtig umgerechnet hat. Denn im Normalfall verlangt ein Designer/Kunde ja eine Schriftgröße in einer Pixelgröße, nicht in “bitte gut lesbar”. Ich habe für solche und ähnliche Fälle die Firebug-Konsole zusammen mit jQuery besonders schätzen gelernt. Mit jQuery kann ich in bekannter und gewohnter CSS-Syntax meine Zielobjekte selektieren, die Konsole zeigt mir die Ergebnisse. Es gibt hierfür prinzipiell drei Wege:

1. Direkteingabe der Anweisungen in der Firebug-Konsole
2. Notierung der Anweisungen in der betreffenden HTML-Datei
3. Notierung der Anweisungen einer externen Javascript-Datei

Die Auswahl des Vorgehens ist Geschmackssache. Gegen die erste Variante, die Direkteingabe in die Firebug-Konsole, spricht in meinen Augen, daß diese Art des Debuggings meist der Beginn eines Prozesses ist. Es folgen also Anpassungen und wiederholte Überprüfungen. Es wäre mir lästig, immer die gleichen Anweisungen in die Konsole einzutippen. Kopiere ich sie aus einer Datei in die Konsole, kann ich auch gleich kosnequenter eine der anderen beiden Lösungswege beschreiten.

Schriftgrößen anzeigen lassen

So kann ich beispielsweise die Schriftgröße einer Liste in einem Container folgendermaßen bestimmen und zudem vernünftig beschriftet ausgeben lassen:

// Schriftgröße in Firebug anzeigen lassen
if ($.browser.mozilla) {
     console.log('Liste voller Nebensächlichkeiten, Schriftgröße: '+$('#container ul.nebensaechlich ').css('font-size'));
}

Auf diese Weise kann man sich natürlich auch alle anderen CSS-Eigenschaften ausgeben lassen. Die Multiplikationseffekte bei Schriftgrößen kann man so prima kontrollieren.

em und Pixel

Und wie kommt man initial auf die em- an Stelle der Pixelwerte? Ich nutze dafür ein kleines AIR-Tool namens "EM Calculator". Die Browser verwalten allerdings intern alle Schriftgrößen als Pixel. Egal wie man nun seine Schriften auszeichnet, Firebug wird immer nur Pixel ausgeben. Ein Test in anderen Browsern bestätigt dieses Verhalten. Es handelt sich dabei um “computed values” (berechnete Werte).

Kein jQuery zur Hand? Kein Problem!

Was aber tun, wenn man auf der eigenen Seite kein jQuery nutzt oder auf einer fremden Seite etwas überprüfen will, dort aber auch kein jQuery eingebunden ist? Alles kein Problem dank des jQuerify-Bookmarklets.

Nach Klick auf das Bookmarklet wird jQuery in die gerade offene Webseite hinzugefügt. Man kann es nun innerhalb von Firebug nutzen.

Streng genommen muss man natürlich nicht jQuery für eine Layoutprüfung nehmen. Es kann allerdings recht umständlich werden, exakt das gewünschte Objekt zu selektieren, wenn man kein Javascript-Framework zur Hand nimmt.

Zum Autor

Jens Grochtdreis arbeitet als "Senior Frontend Developer" bei SinnerSchrader in Frankfurt. Neben seinem Weblog betreut er auch die CSS-FAQ und setzt sich mit den Webkrauts für moderne, standardkonforme Webseiten ein.

Nichts ist mühsamer als sich durch den HTML-Code zu hangeln, nur weil man die Präsentation eines Elements ändern will. Eine der wichtigsten Herausforderungen des modernen Webdesigns ist es, das HTML richtig hinzubekommen und das heißt so simpel wie möglich bei gleichzeitig hohem semantischen Wert. Neue Browsergenerationen bieten uns mit besserer CSS-Unterstützung neue Möglichkeiten ohne Veränderungen am Markup die visuelle Gestaltung zu beeinflussen. Eine Beispiel-Seite zeigt Anwendungsmöglichkeiten.

1. Externe Links

Um externe Links auszuzeichnen kann man sehr einfach den Attribut-Selektor in CSS3 benutzen:

a[href^='http://'] {
    padding-right: 17px;
    background: url(extern.png) right no-repeat;
}
a[href^='http://www.webkrauts.de'],
a[href^='http://webkrauts.de'] {
    padding-right: 0;
    background: none;
}

Der erste Selektor sucht alle externen Links heraus und versieht sie mit einem Hintergrundbild. Absolute Pfade auf die eigene Domain müssen dann noch zurückgesetzt werden. Dies kann man auch für E-Mail-Links verwenden, wenn man ganz pfiffig sein will sogar mit Bild für den einzelnen Adressaten:

a[href^='mailto:'] {
    padding-right: 15px;
    background: url(mail.png) right no-repeat;
}
a[href^='mailto:john'] {
    padding-right: 15px;
    background: url(johndoe.png) right no-repeat;
}

Kompatibilität:

2. Gestreifte Tabellen

Gestreifte Tabellen sind eine tolle Idee, jede zweite Zeile mit einer Klasse zu versehen ist aber meistens auch mühsam, wenn man eine Zeile hinzufügen muss. JavaScript-Lösungen dazu gibt es einige, allerdings ist das :nth-child-Pseudoattribut in CSS schon weit verbreitet, so dass wir uns diesen Javascript-Aufruf für diese Browser getrost sparen können:

tr:nth-child(odd) {
  background-color: #9f9;
}
tr:nth-child(even) {
  background-color: #f9f;
}

Kompatibilität:

3. Spezielle Absätze

Oft soll auf die erste Überschrift ein besonderer Absatz folgen, der noch einmal als Einführung dient. Meist bedient man sich dann einer Klasse .intro um den Absatz anzusprechen. Das ist aber gar nicht nötig, wenn man den CSS2-Geschwister-Selektor (+) benutzt:

h2 + p {
    border-bottom: 1px solid #ddd;
    font-weight: bold;
}

Kompatibilität:

4. Abgerundete Ecke und Schatten

CSS3 kennt die Möglichkeiten per CSS abgerundete Ecken und Schatten zu benutzen, ohne irgendwelche Grafiken zu benutzen. Das spart nicht nur Arbeit sondern auch Serverzugriffe und Traffic. Momentan sind diese Eigenschaften mit Vendor-Prefix in modernen Browsern bereits verfügbar (Schatten im Firefox erst ab Version 3.1).

#sidebar {
    border: 1px solid #333;
    -moz-border-radius: 15px;
    -webkit-border-radius: 15px;
        border-radius: 15px;
    -moz-box-shadow: 5px 5px 15px #000;
    -webkit-box-shadow: 5px 5px 15px #000;
        box-shadow: 15px;
}

Kompatibilität:

Einige Worte zum Internet Explorer:

Alle hier verwendeten Kniffe funktionieren nicht im IE6, was schade aber nicht tragisch ist, da es sich nur um visuelle Verbesserungen handelt. Alle Informationen sind auch ohne CSS verfügbar, die hier angewendeten Regeln führen also zu einer Verbesserung der Nutzbarkeit für die Mehrheit der Benutzer der Seite und gehören zu den Darstellungsunterschieden mit denen man leben kann.

Border-radius und box-shadow sind Eigenschaften, die in den meisten Browsern noch nicht umgesetzt werden. Sind die abgerundeten Ecken von untergeordneter Bedeutung und mehr eine Stilfrage, so kann man sich mit der Angabe dieser Eigenschaften das Leben viel einfacher machen.

Zum Autor

Eric Eggert glaubt an das offene und für jeden zugängliche Web. Deshalb setzt er sich im W3C mit dem neuen HTML5-Standard auseinander und hilft der BAD TF dabei gute Beispiele für Barrierefreie Webseiten zu entwickeln. Er bloggt (von Zeit zu Zeit) auf yatil.de.

Die Navigation ist dazu da, um den Nutzer möglichst schnell und einfach zu den gewünschten Informationen zu führen. Dazu wählen wir ebenso einfache Worte, die so gut es geht erläutern, was sich hinter den Menüpunkten verbrigt. Wie so oft gilt es auch hier, an die Zielgruppe zu denken. Webworkern kann man sicher Wörter wie »Feedback«, »Newsfeeds« oder »Disclaimer« zumuten. Bei anderen Zielgruppen muss man aufpassen, was man in eine Navigation schreibt.

Das fängt schon beim ersten Punkt an: der Homepage. Denn während wir genau wissen, was mit einer »Homepage« gemeint ist, können andere damit vielleicht nichts anfangen. Noch 2005 zeigte eine Wording-Studie (schönes Wort), dass 46 Prozent der Befragten die Bezeichnung »Startseite« bevorzugten, während sich nur 10 Prozent mit einer englischen »Homepage« anfreunden können.

Wenn es klarer geht, texte klarer

Die Grafik rechts zeigt die Navigation eines Steuerberaters. Hinter »Wir über uns«, »Existenzgründer« oder »Wirtschaftsnews« kann man sich noch etwas vorstellen. Bei »Aktiver Steuerberatung« zucken schon die Augenbrauen. Klickt jemand, der eine einfache »Steuerberatung« braucht, auf »aktive Steuerberatung«? In diesem Fall vermutlich ja, weil es die einzige Stelle in der Navigation ist, an der von "Steuerberatung" die Rede ist. Trotzdem stellt sich die Frage, ob das »aktiv« an dieser Stelle wirklich nötig ist. Der Steuerberater möchte hier bereits seine Philosophie der Steuerberatung rüberbringen. Das kann er machen, wenn er dafür in Kauf nimmt, dass er einige Besucher verwirrt.

Ebenso unklar ist das »Online-Formular«: Um was für ein Formular geht es? Ist es ein Steuerrechner? Kann ich Unterlagen anfordern? In dem Fall geht es um ein Kontaktformular. Dementsprechend wäre »Kontaktformular« oder auch »Kontakt« besser gewählt.

Dass beim Menüpunkt »Wirtschaftsnews« ein »t« fehlt, kann zwar passieren, ist aber an zentraler Stelle unglücklich und hätte in mehreren Monaten korrigiert werden können.

Mehr Fragen

Nehmen wir ein anderes Beispiel: Was sucht ein »mehr« in der Navigation neben den »Leistungen«? Gibt es A-Leistungen und dann noch einmal B-Leistungen?

Und was verbirgt sich hinter »Ihre Fragen«? Eine Frage- und Antwort-Seite im Sinne eines FAQ? In diesem Fall der Aufruf, sich an den Steuerberater zu wenden. Auch hier wäre »Kontakt« sinnvoller.

Verwirrung in der IT

In diesem Beispiel sind ein paar Menüpunkte eines IT-Informationsportales zu sehen. Verwirrend sind hier die Punkte »Partnerzones«, »Datenbanken« und »Meine Seite«.

Was verbirgt sich wohl hinter »Partnerzones«? Ein Partnerprogramm ähnlich zu dem von Amazon vielleicht? Kann man selbst zum Partner werden? Sind es Links zu den Partnern der Portals? Nach einigen Klicks rät man, dass es sich hier um Channels einiger Partner handelt – richtig klar wird es nicht. Sie bieten Schwerpunkte zu Themen rund um Microsoft, IBM oder Abmahnungen. Wenn dem so ist, wäre vielleicht ein Titel wie »Schwerpunkte« oder »IT-Specials« besser.

Die »Datenbanken« sind ebenso mysteriös. Was für Datenbanken? Mit welchen Inhalten? Ein Klick enthüllt einen »Anbieter-Index A-Z« samt zugehöriger Suche. Warum nennt man den Menüpunkt dann nicht ebenso »Anbieter-Index«? Vermutlich, damit ich Material für einen Webkrauts-Artikel habe.

Amüsant finde ich immer einen Punkt »Meine Seite« auf Websites, die ich noch nie besucht habe. Wie komme ich so schnell an eine eigene Seite? Hier werden mir diverse Newsletter angeboten mit der Möglichkeit, mich anzumelden bzw. zu registrieren. Wenn Newsletter der einzige Nutzen der Anmeldung sind, warum nennen sie den Menüpunkt nicht gleich »Newsletter«? Und wenn es über die Newsletter hinaus weitere Vorteile gäbe, warum werden die nicht augeflistet?

Kreativität auf Kosten der Klarheit

Die Navigation ist nicht dazu da, um clever zu texten. Es geht um Einfachheit. Damit möglichst viele Leute verstehen, was sie erwartet, wenn sie auf einen Menüpunkt klicken.

Ich habe neulich eine Webseite für einen Pianisten leicht modernisiert. In dem Fall sollten von der alten Seite die musikalischen Begriffe in der Navigation übernommen werden. Zu lesen ist also »Prelude«, »Vorspiel« oder »Ovationen«. Erst, wenn man mit der Maus über die Menüpunkte fährt, ändern sich die Worte zu »Intro« (Startseite), »Hörproben« und »Referenzen«.

Bei den ersten Begriffen ist erst einmal nicht klar, was sich dahinter verbirgt. Die Worte passen zum Thema, weil es sich um eine musikalisch geprägte Seite handelt. Aber sowohl dem Entwickler als auch dem Kunden muss klar sein, dass die »kreative« Navigation auf Kosten der Klarheit geht und neue Besucher zunächst irritiert.

Zum Autor:

Nicolai Schwarz arbeitet als selbstständiger Webworker unter dem Namen textformer mediendesign in Dortmund. Er berät bei Webprojekten und kümmert sich um Konzeption, Design und Umsetzung.

Breadcrumb-Navigationen helfen dem Besucher, sich innerhalb der Struktur einer Seite zu orientieren.

Erst bei der Nutzung einer Screenreader-Software wird einem bewusst, welche ursprüngliche Bedeutung die Symbole haben, mit denen die einzelnen Ebenen einer Breadcrumb-Navigation voneinander getrennt werden.

Die klassischen Trennzeichen zwischen den Aufzählungspunkten in Breadcrumb-Navigationen symbolisieren für sehende Benutzer eine Art »Weiter-Pfeil« oder »Ebene tiefer«-Pfeil:

Diese haben aber bei der Nutzung von Screenreadern ihre Tücken, die umso größer werden, je länger der Pfad wird. Sie sorgen unter Umständen für genervte Benutzer, im schlimmsten Falle für Verwirrung und Verständnisprobleme. Mal sind sie beim Vorlesen zu lang, mal haben sie unklare Aussagen oder werden gar nicht vorgelesen.

Lässt man sich die Liste typischer Trennzeichen z.B. von JAWS vorlesen,
merkt man, dass einige Zeichen nicht unbedingt ideal sind.

Beispiel gefällig?

(getestet mit JAWS 7.10 und JAWS 8.0 deutsch.)

Manchmal sieht man auch den Einsatz von Pfeilgrafiken; diese brauchen natürlich einen Alternativtext. Wenn dann eines dieser Zeichen im Alternativtext steht, wird es noch aufgeblähter, JAWS sagt dann »Doppelt gewinkelte Klammer, Grafik« oder gar »Doppelt gewinkelte Klammer – Eine Ebene tiefer, Grafik«. Wenn es also unbedingt eine Grafik als Trennzeichen sein soll, dann bitte den ALT-Text leer lassen.

Wie denn jetzt?

Beim Aufbau einer solchen Navigationsliste sollte man sich ein hübsches und sinnvolles Zeichen aussuchen, das auch dem Screenreader-Benutzer die Navigation erleichtert und ihn nicht mit langen Erläuterungen belästigt oder gar im Dunkeln lässt. Hier empfehlen sich der Doppelpunkt, der Schrägstrich oder das Größer-Zeichen, die auch unter Usability-Aspekten ihre Berechtigung haben.

Grundsätzlich sollten Breadcrumb-Navigationen immer als Liste ausgezeichnet sein, hierbei eignet sich eine geordnete Liste (<ol>) besser als eine ungeordnete (<ul>), denn über die CSS-Formatierung kann die Nummerierung ausgeblendet werden, die der Screenreader trotzdem vorliest.

Das führt uns zu folgendem Code:

<ol>
<li><a href="home.html">Startseite</a></li>
<li> : <a href="hierhin">eine Ebene tiefer</a></li>
<li> : <a href="dorthin">zweite Ebene</a></li> 
</ol>

Über den Autor

Maik Wagner lebt und arbeitet in Essen. Neben der Arbeit für Kunden engagiert er sich bei SELFHTML und dem W3C für Webstandards und Barrierefreiheit.

Webentwickler geben in ihren Stylesheets und Skripten oft und gerne an, wie sich Links oder Elemente bei Mausberührung verhalten sollen. Dabei wird leider häufig übersehen, dass diese Effekte endgeräte-spezifisch sind. Denn wer keine Maus nutzt, tut sich natürlich mehr als schwer, den nicht vorhandenen Mauszeiger über ein Seitenelement zu bewegen, um beispielsweise ein Untermenü oder einen Tooltip mit Zusatzinformationen anzeigen zu lassen. Dies betrifft Anwender eines Screenreaders ebenso wie iPhone- bzw. iPod-Nutzer.

Die Berührung des Bildschirms eines solchen Geräts wird als "Klick" interpretiert. Mauszeigerbewegungen gibt es defacto nicht, was viele Webseiten nahezu unbedienbar machen würde. Apple versucht dieses Problem dadurch in den Griff zu bekommen, dass bei der Berührung des iPhone-Bildschirms zunächst mouseover- und mousemove-Events ausgeführt werden. Verändern sich dabei Elemente der Seite, klappt also z.B. ein Untermenü aus, wird anschließend abgebrochen und es werden keine mousedown-, mouseup- oder click-Events ausgeführt. Das funktioniert aber leider nicht immer zuverlässig.

Im schlimmsten Fall ist das Element mit dem Hover-Effekt kein Link. Dies funktioniert auf dem iPhone gar nicht. Ein Browser mehr in dem Pseudoklassen nur für a-Elemente sinnvoll einsetzbar sind.

Mit unterschiedlichen Strategien lassen sich diese Probleme jedoch adressieren und die eigene Webanwendung für das iPhone fit machen.

Spezielle Versionen von Webseiten, …

Als ein Negativbeispiel für die beschriebenen Probleme kann die Webseite von Amazon dienen, die auch in anderen Bereichen mit Worst Practice aufwarten kann. Hier funktioniert die Hauptnavigation ohne Maus überhaupt nicht. Während beim Überfahren der Navigationspunkte mit dem Mauszeiger Untermenüs ausklappen, passiert beim Klick darauf gar nichts. iPhone-Besitzer, aber auch Tastatursurfer, stehen vor einem unlösbaren Problem. Der Buchhändler bietet allerdings eine speziell auf das Apple-Gerät optimierte Seitenversion an. Diese wird automatisch beim Aufruf der Domain mit dem mobilen Safaribrowser geöffnet.

Wer diesen Weg gehen möchte kann anhand des User-Agent-Headers die Besucher mit einem iPhone bzw. iPod aussortieren und sie so auf speziell optimierte Angebote umleiten. Doch hier muss vorsichtig geprüft werden, denn bereits jetzt gibt es durch unterschiedliche Firmware-Versionen differenzierte iPod/iPhone-User-Agenten.

… angepasste Stylesheets und Skripte, …

Eine andere Strategie kann sein, konditionale CSS-Regeln für bestimmte Endgeräte, in diesem Fall das Apple Gerät, anzubieten. Da der mobile Safari-Browser aber auf das Medienattribut handheld nicht reagiert muss man sich diesbezüglich eines anderen Kniffs bemühen.

<link media="only screen and (max-device-width: 480px)" href="spezielles.css" type= "text/css" rel="stylesheet" />

Erfasst werden also alle Geräte, die sich als screen ausgeben und maximal 480px breit sind.

Apple selbst empfiehlt zudem, Skripte durch kleine Tricks anzupassen. So lässt sich z.B. ein nicht auf Klicks reagierendes Element mit onmouseover durch Hinzufügen eines onclick-Dummyevents wie gewünscht bedienen. Dieser darf sogar später wieder entfernt werden. Der Browser "merkt" sich dies und führt dennoch mouseover-Effekte aus, wie man auf unserer Beispielseite sehr gut nachvollziehen kann.

… oder besser gleich zugänglich gestalten!

Letztlich sollten Webseiten aber gleich barrierefrei und zugänglich gestaltet sein. Das umständliche Bekämpfen von Symptomen durch den Einsatz von Browserweichen und Speziallösungen wird so (fast immer) überflüssig. Es gilt schließlich nicht nur an das gerade im Medieninteresse stehende iPhone zu denken, sondern generell endgeräteunabhängig zu arbeiten. Daher gehört es zum Best Practice, zugängliche Webseiten zu gestalten. Hierzu ein Zitat aus den Richtlinien der WCAG und der BITV:

Internetangebote sind so zu gestalten, dass Funktionen unabhängig vom Eingabegerät oder Ausgabegerät nutzbar sind.

Eine Webanwendung, die von Mausbewegungen abhängig ist, geht demnach einen grundsätzlich falschen Weg. Entwickler sollten sich mehr auf den Benutzer konzentrieren. So ist das eigene Webprojekt nicht nur fit für das iPhone, sondern auch für nahezu alle anderen Arten von Endgeräten.

Möglicherweise hift das populäre iPhone so dabei, die Aufmerksamkeit auf Interaktionsmodelle jenseits der Maus zu lenken und dadurch auch bei Zuänglichkeits-Muffeln ein größeres Bewußtsein für die Notwendigkeit von Barrierefreiheit zu schaffen.

Zum Autor

Sascha Postner ist Kommunikationswissenschaftler aus Essen. Er arbeitet als "PR Specialist New Media" bei Mazda Motor Europe und ist als selbständiger Berater und Webentwickler tätig.

Nicht immer kann man sich als Webdesigner darauf verlassen, mehrere Kundentermine für die sorgfältige Planung einer Webseite zu erhalten. Noch seltener ist der Idealfall gegeben, dass der Kunde auch noch für die Phase der Webseiten-Konzeption Zeitressourcen erübrigt. Je kleiner das Projekt, umso größer liegt der Fokus auf die Effektivität der Kundentermine – durchaus auch im Sinne des Webdesigners, der ebenfalls seine Zeitressourcen im Blick haben muss.

Die Kommunikationswege machen es heute möglich, überregionale Aufträge entgegenzunehmen, auch ohne direkten Kontakt zum Kunden. Optimal ist jedoch mindestens ein direktes Gespräch. Die nonverbale, zwischenmenschliche Begegnung, das gegenseitige Kennenlernen, vielleicht ein gemeinsames Mittagessen – all das sind Aspekte aktiver Kundenkommunikation, die durch kein Medium ersetzt werden können. Umso wichtiger ist die sorgfältige Planung des Kundengespräches, um nicht mit leeren oder nur halbvollen Händen heimzufahren und dann doch wichtige Konzeptfragen über Telefon und E-Mail klären zu müssen.

Die richtigen Fragen: Checklisten

In meinem Artikel zur erfolgreichen Gesprächsführung wurde bereits die Notwendigkeit erwähnt, dass man sich auf gleicher Augenhöhe und auf dem Niveau der Medienkompetenz des Kunden bewegen sollte. Eine professionelle Checkliste ist für den Webdesigner hier das perfekte Instrument für die Planung und Konzeption von kleinen und mittleren Projekten.

Vorteile von Checklisten:

• Qualifizierung der Medienkompetenz des Kunden
• Transparenz der Anforderungen
• Sachliche Kommunikation durch standardisierte Fragestellungen

Als Webdesigner trifft man immer wieder auf verschiedene Kundentypen mit unterschiedlichen Kompetenzen und differenzierten Anforderungen an eine Webseite. Ein standardisierter Fragenkatalog macht aus dem Kunden zwar keinen Stereotypen, aber er garantiert einen sachlichen Umgang mit den Inhalten und allen anderen Aspekten des Projektes.

Sachlichkeit und Zeit

Die Checkliste ist ein Instrument, um sachlich Informationen zu verarbeiten – das heißt, sie ist wertfrei zu verwenden. Das bedeutet, die Fragen sollten eindeutig, klar und konkret formuliert sein. Diskussionen sollten ebenso vermieden werden wie die Notwendigkeit von langen Erklärungen durch den Webdesigner. Wichtig ist, dass die Checkliste ungestört und konzentriert abgearbeitet werden kann. Der Katalog ist eine logische Abfolge von Fragen, die Gesprächspartner sollten deshalb genügend Zeit mitbringen. Mindestens zwei Stunden sollte der Zeitrahmen betragen, ansonsten ist ein anderer Termin vorzuziehen.

Sinnvoll ist eine Basis-Checkliste, die dann für bestimmte Kundentypen und Anforderungen individualisiert werden sollte. Die Frageliste für die Entscheidergruppe in einem Unternehmen hat anderes zu sein als die Liste für den Vorsitzenden eines Vereins oder für die Gremien einer Kommune.

Die Basis-Checkliste

Durch verschiedene Themenbereiche lässt sich eine Checkliste gut strukturieren und schnell individualisieren.

Bereich Inhalte und Zielgruppe: Funktion und die Inhalte der späteren Webseite

• Gibt es einen Bereich, der in der Außendarstellung und in der Webseite besonders hervorgehoben werden soll?
• Was ist Ihre wichtigste Zielgruppe?
• Aus welchem regionalen Bereich kommt Ihre Zielgruppe?
• Welche Inhalte sind Ihrer Meinung nach für die Zielgruppe am wichtigsten?

Bereich Leitbild: Motivation und das Selbstverständnis des Kunden

• Notieren Sie fünf bis zehn Begriffe, die Ihre Tätigkeit am besten beschreiben; was macht Sie und Ihr Unternehmen/Verein aus, was treibt Sie täglich an?
• Welcher der Begriffe ist Ihrer Meinung nach der wichtigste?

Bereich Gestaltung und Werbemittel: Grundlagen des (Web-)Designs

• Gibt es ein ausgearbeitetes visuelles Erscheinungsbild mit Farbsystem, Hausschrift und Logo?
• Falls ja: liegen die Daten digital vor?
• Haben Sie schon Flyer, Visitenkarten und Briefpapier?
• Falls ein visuelles Basiskonzept für die Webseite ausreicht – welche Farbrichtung bevorzugen Sie: Vollfarben, warme Mischtöne oder kühle Mischtöne?
• Haben Sie eine Hausschrift (z. B. Times New Roman oder Arial)?

Bereich Webseite: Medienkompetenz, Wünsche, Anforderungen des Kunden

• Können Sie Webseiten nennen, die Ihnen besonders gut gefallen?
• Was gefällt Ihnen daran besonders gut, was gefällt Ihnen nicht?
• Soll Ihre Adresse _www.kunde.de_ die Hauptadresse sein oder eine andere?
• Seit wann ist die jetzige Webseite ungefähr im Netz, gab es große inhaltliche Änderungen?
• Wer hat die bestehende Webseite realisiert und war der Dienstleister die ganze Zeit über für das Projekt verantwortlich?
• Was gefällt Ihnen an Ihrer Webseite besonders gut, was halten Sie für besonders gelungen?
• Haben Sie sich schon eine Grundstruktur als Navigationsliste für Ihre Webseite überlegt?

Die Checkliste in anderen Medien

Die Basis-Checkliste sollte nicht nur für Kunden- und Webseitentypen individualisiert werden, sondern auch für andere Kommunikationsmedien. Als E-Mail-Anhang sollte ein Office-Dokument nicht allzu komplex formatiert werden, und in einem Telefonat lassen sich nur Teile der Fragen abarbeiten, eine Stunde ungestörter Kommunikation ist hier auch für den Kunden die zumutbare Belastungsgrenze. Beim Versand per Post (oder als E-Mail-Anhang) ist zu überlegen, ob für den individuellen Kunden eher Lücken zwischen den Fragen oder Leerblätter zum Ausfüllen in Frage kommen.

Inhalte

Ergänzen sollte man die Checkliste mit Fragen zu den Inhalten nur dann im ersten Termin, wenn sich der Kunde zuvor konkret in diese Richtung geäußert oder sogar schon Inhalte weitergereicht hat. Viele Kunden machen sich erst dann intensive Gedanken zu den Inhalten, wenn sie darauf gestoßen werden, meistens stehen Gestaltung und Aussehen der Webseite im Vordergrund.

Im Laufe des Abarbeitens erfährt man schnell, über welche Medienkompetenz der Kunde verfügt, wie intensiv er sich mit dem eigenen Projekt auseinandergesetzt hat und welche Anforderungen er an das Projekt stellt. Die Summe der Informationen bildet eine ideale Basis des Webdesigners, um das weitere Vorgehen genau zu planen. Es ist damit gleichzeitig eine wichtige Grundlage für die Angebotserstellung und für die Konzeptionsphase.

Über den Autor

Nils Pooker war im Kunstbereich tätig und arbeitet als selbständiger Webdesigner in Preetz (Schleswig-Holstein). Er ist Fachbuchautor und hält Vorträge zu Kommunikation, Projektmanagement und Webdesign.

Links

Links führen zu anderen Dokumenten (Web 1.0) oder rufen Funktionen, Dialoge auf (Web 2.0). Sie müssen deutlich als Links zu erkennen sein, der Benutzererfahrung gemäß optimalerweise durch eine besondere Farbigkeit und eine Unterstreichung. Wichtig ist auch, bereits besuchte und gerade aktive Links von unbesuchten Links visuell zu unterscheiden. Für suchende Benutzer ist die Kennzeichnung von besuchten Links ein willkommenes Hilfsmittel, unnötige wiederholte Besuche von Seiten zu vermeiden. Auch kann wichtig sein, das Ziel der Links visuell darzustellen und so externe von internen Links zu unterscheiden, oder zu visualisieren, welche Art von Quelle (Video, Audio, etc.) referenziert wird.

Radiobuttons

Radiobuttons symbolisieren eine Auswahl aus zwei oder mehr Möglichkeiten, von denen nur eine auswählbar ist. Sie sollten niemals dazu zwingen, nur eine aus verschiedenen denkbaren Optionen auszuwählen – dadurch fühlt sich der Benutzer bevormundet. Nur wenn tatsächlich immer nur eine einzige Möglichkeit zutreffen kann, sollten Radiobuttons verwendet werden.

Wie aus gedruckten Formularen gelernt, sollten Sets aus Radiobuttons immer untereinander stehen, mit der Beschriftung in Leserichtung nach dem Radiobutton. Bei horizontaler Ausrichtung ist die Zugehörigkeit von Radiobutton zu Beschriftung schlecht erkennbar. Außerdem sollte man bei Radiobuttons eine Vorbelegung erwägen, und zwar auf einen neutralen Standardwert, der nicht mit der eigentlichen Auswahl an Möglichkeiten in Verbindung steht.

Die Wahrnehmungspychologie lehrt, dass ein Mensch sieben Auswahlmöglichkeiten problemlos behalten kann – bei mehr als sieben wird es schwer. Obwohl die Lehren der Wahrnehmungspsychologie hier nur mit Vorsicht adaptierbar sind, sollte man doch die Anzahl der Möglichkeiten gering halten.

Checkboxen

Sie symbolisieren eine Zustimmung zu einer Vorgehensweise (eine einzige Checkbox) oder eine Auswahl mit mehreren oder gar keinen zutreffenden Möglichkeiten (mehrere Checkboxen). Wie bei Radiobuttons sollten Sets aus Checkboxen ebenfalls immer untereinander stehen, mit der Beschriftung in Leserichtung nach der Checkbox.

Selectboxen

Sie symbolisieren eine Auswahl an Möglichkeiten, aus der nur eine einzige gewählt werden kann. Der kognitive und koordinatorische Aufwand, eine Selectbox zu bedienen, ist wesentlich höher, als der, eine Liste von Radiobuttons zu bedienen. In Einzelfällen kann es jedoch sinnvoll sein, die Selectbox vorzuziehen, beispielsweise bei einer Datumsangabe. Hier ist es noch wichtiger als bei Radiobuttons, dem Benutzer einen neutralen Standardwert zu zeigen, bevor er eine der angebotenen Möglichkeiten wählt. Es gibt jedoch einen Sonderfall: eine Selectbox, die in der Höhe so angelegt ist, dass die enthaltenen Optionen bereits sichtbar sind, ohne sie aufklappen zu müssen. Diese Variante macht es möglich, beispielsweise bei einer gedrückten Strg- (Microsoft Windows) oder Cmd-Taste (Apple Mac OS X) mehrere Optionen auszuwählen. Allerdings bietet auch diese Variante einen Fallstrick, denn ein unerfahrener Benutzer erkennt ohne Erklärung nicht, dass er mehrere Möglichkeiten wählen kann. Hier bietet es sich eher an, eine eigene Form dieser Art des Interaktionselement zu gestalten, als ein bestehendes Element zu missbrauchen.

Drehregler

Man findet sie sehr selten auf Webseiten, sie sollten aber dennoch erwähnt werden. Sie haben zwei gelernte Einsatzfelder: die Steigerung eines Werts (wie bei dem Lautstärkeregler einer Stereoanlage) oder die Abweichung von einem Normalwert (wie bei dem Balance-Regler einer Stereoanlage). Es ist Standard, dass gemäß der Leserichtung der Wert von links nach rechts ansteigt oder aber nach links ins Negative und nach rechts ins Positive abweicht. Für Drehregler gibt es kein Markup-Element und auch kein von einer Rendering Engine oder einem Betriebssystem gestellte Standard-Visualisierung. Daher ist es hier immer nötig, zu einer individuellen Visualisierung zu greifen.

Schieberegler

Auch sie sind eher selten zu finden, allerdings im Rahmen von Webapplikationen deutlich häufiger als Drehregler. Bei Youtube beispielsweise finden sich sowohl horizontale (Timeline), als auch vertikale Schieberegler (Lautstärke). Der Standard ist hier einfach: wie auch bei Drehreglern finden sich sowohl der Einsatz als reine Steigerung oder als Abweichung, auch hier von rechts nach links ansteigend oder von links negativ abweichend nach rechts positiv abweichend. Bei vertikalen Schiebereglern steht unten synoym für links/mehr und oben synonym für rechts/weniger.

Texteingabefelder

Die wohl am zweithäufigsten genutzten Interaktionselemente, direkt nach den Links, sind Texteingabefelder. Hier hat man auch ohne aufwändige Ersetzungstechniken einen großen gestalterischen Spielraum, der nicht immer komplett ausgeschöpft werden muss.

Bewährt hat sich ein hoher Kontrast zur unmittelbaren Umgebung (Rahmen, Farbe) und eine in Leserichtung vor dem Texteingabefeld stehende Beschriftung. Die Beschriftung über dem Texteingabefeld zu platzieren, ist ebenfalls möglich, allerdings ist der Aufwand der Zuordnung größer. Dabei ist die Beziehung zwischen Beschriftung und Texteingabefeld im Markup zu beschreiben, so dass das Textfeld ausgewählt werden kann, indem man die Beschriftung anwählt.

Wählt man ein Texteingabefeld an, um es auszufüllen, sollte dieser Zustand visualisiert werden, damit man erkennt, welches Feld sich in Bearbeitung befindet. Bei AJAX-getriebenen Suchanfragen mit ausklappenden Vorschlägen unterhalb des Eingabefelds (Auto-Suggest) muss darauf geachtet werden, dass erst nach erfolgter Eingabe einiger Zeichen und einem entsprechenden Delay nach der Eingabe eine Anzeige der vorgeschlagenen Daten erfolgt.

Pflichtfelder

Ist man als Betreiber einer Webseite geneigt, soviel Information wie möglich vom Benutzer zu erhaschen, so sollte man sich doch zügeln, denn zuviele Pflichtfelder wirken abschreckend. Als Visualisierung eines solchen Zwangs hat sich das Sternchen „*“ als Standard etabliert, oft auch in einer anderen Farbigkeit als die verpflichtende Beschriftung, aber immer mit einer Fußnote.

Reiter

Reiter sind umstrittene Metaphern im Web. Apple hat sie über Jahre genutzt, um die verschiedenen Bereiche der Webseite voneinander zu trennen – im wahren Leben kommen die Reiter sowohl als physisch voneinander getrennte Element vor (Hängeregister), die man auch separat wählen und betrachten kann, als auch als Teil einer Einheit innerhalb eines Containers (einer Akte z.B.).

Jakob Nielsen empfiehlt Reiter nur dort, wo sie verschiedene Ansichten des gleichen Bereichs anwählbar machen, aber nicht als übergeordnetes Navigationselement einer ganzen Webseite. Darüber lässt sich streiten, nicht aber darüber, dass die optische Anmutung von Reitern von der Wirkung eines realen Reiters inspiriert sein muss. Die Simulation der Haptik, also die Erhabenheit des gewählten Reiters in Kombination mit seiner Verbindung mit dem darunter beginnenden Inhalt spielt eine große Rolle bei der Erkennung dieses Interaktionselements. Eine andere Farbigkeit, die den aktiven Zustand anzeigt, hilft zusätzlich. Sind die Reiter getrennt voneinander und getrennt vom Inhalt darunter, sind sie kaum als solche wahrnehmbar.

Dialoge

Dialoge sind der Desktop Software entlehnt, wo sie auf versehentlich Geschehenes aufmerksam machen, Entscheidungen verlangen oder vor ungewollten Aktionen warnen. Eben diesen Zweck haben sie auch im Web, allerdings findet man sie fast ausschließlich in Webapplikationen.

Derartige Dialoge sollten deutlich von der Umgebung abgehoben werden, oft wird sogar die Umgebung ausgeblendet, um den Fokus des Benutzers auf den Dialog zu lenken. Auch eine simulierte Erhabenheit über dem eigentlichen Inhalt kann die Funktion unterstützen, zumindest ein Rahmen und eine Signalfarbe ist nötig, um einen Dialog hervorzuheben. Nur ein Bestätigungsdialog darf sich zurücknehmen, wobei er selbstverständlich nicht nahezu unsichtbar bleiben sollte.

Scrollbalken

Der einzig berechtigte Scrollbalken findet sich am rechten Rand des Browserfensters – horizontale Scrollbalken sind tabu! Auch sollte man auf bereichsbezogene Scrollbalken verzichten, da die Steuerung von verschachtelten oder scrollbaren Bereichen nebeneinander nur mit den Maustasten effizient möglich ist. Sobald man sich derartige Bereiche in Kombination mit Bedienung durch einen Touch Screen oder durch eine Tastatur vorstellt, werden Schwierigkeiten klar.

Ist man zur Verwendung von bereichsbezogenen Scrollbalken gezwungen, sollte man sich der durch Rendering Engine oder Betriebssystem bereitgestellten Elemente bedienen. Eigens dafür entwickelte haben den Nachteil, dass sie oft nicht intuitiv erkannt werden, nicht mittels Maus-Scrollrad bedienbar und nicht selten sehr anfällig für Bedienungsfehler sind.

Scrollbalken sollten nur dann angezeigt werden, wenn Scrollen tatsächlich notwendig ist. Ist sämtlicher Inhalt zu sehen, sollten Scrollbalken ausgeblendet werden. Der bei Zentrierung des Inhalts auftretende Versatz bei Seiten mit und ohne Scrollbalken kann dabei in unkritischen Fällen in Kauf genommen werden. Es gibt natürlich Anwendungsfälle, in denen es wichtig ist, dass der Inhalt nicht springt. Beispielsweise bei der Gestaltung einer im Viewport zentrierten Bildergalerie kann man das kleinere Übel wählen: dem Benutzer das problemlose Durchklicken einer Galerie zu ermöglichen, ihm dabei aber einen Scrollbalken zu zeigen, der nicht nutzbar ist.

Über den Autor

Stefan Nitzsche arbeitet als Webdesigner, Webentwickler, Berater und Autor mit über zehn Jahren Branchenerfahrung. Er lehrt Interface Design an der Mediadesign Hochschule in Düsseldorf, engagiert sich bei den Webkrauts für Webstandards und ist Mitglied des German Chapter (GC) der Usability Professional‘s Association (UPA).

Als Interaktionselemente bezeichnet man alle Elemente, die dem Benutzer ermöglichen, mit einer Webseite zu interagieren. Dazu gehören sämtliche Formularelemente, wie beispielsweise Texteingabefelder, Radiobuttons oder Checkboxen, Selectboxen, aber auch Dialoge wie Fehlermeldungen, Bestätigungen oder metaphorisch auf „echte“ Anwendungen Bezug nehmende Elemente wie Schiebe- oder Drehregler. Die Querverweise, die das Web erst zum Web machen, die Hyperlinks, gehören ebenso dazu wie eine aus Links bestehende Navigation.

Interaktionselemente des Browsers

Eine Webseite wird oft (fälschlicherweise) als eigenständige, autarke Oberfläche verstanden. Deren Designer sehen den Browser nicht selten bloß als unerwünschten, grafischen Rahmen, obwohl er eine Fülle von Interaktionselementen bietet, die sich auf die dargestellte Seite beziehen. Drucken, Vor/Zurück, das Setzen von Lesezeichen, Vergrößern und Verkleinern sind nur einige dieser Funktionen. Um den Benutzer nicht zu verwirren, wenig robuste technische Lösungen zu vermeiden und die Webseite zu entlasten, sollte man es vermeiden, bereits vorhandene Funktionen wie die oben genannten in der Webseite zu wiederholen, ohne dem Benutzer dabei einen wirklichen Mehrwert zu bieten:

Regel 1: Redundanz durch Doppelung der durch den Browser bereitgestellten Funktionen in der Webseite vermeiden!

Evolution des Web

Konzeptionelle Unterschiede in der Verwendung von Interaktionselementen fallen besonders auf, seitdem das Web 2.0 Gestalter von Dokumenten zu Gestaltern von Anwendungen gemacht hat. Während man bei der Gestaltung von Formularen in der Dokument-Metapher von einer Linearität ausgeht, einer Vorgehensweise in mehreren Schritten, arbeitet man bei der Gestaltung von Formularen in der Anwendungsmetapher häufig mit der direkten Beeinflussung/Manipulierung von Inhalt oder zumindest mit der direkten Validierung von Eingaben. Das ergibt natürlich im Kontext der Seite eine viel komplexere Interaktion, als bei Linearität – dem ist Rechnung zu tragen.

Regel 2: Bei der Gestaltung von Interaktionen den Grad der Komplexität des Produkts bedenken!

Status

Seit vielen Jahren geistert die 3-Klick-Regel durch die Köpfe von Laien, Konzeptern und Designern. Sie besagt, dass man den Benutzer verliert, falls er nicht innerhalb von drei Klicks sein Ziel erreicht. Mittlerweile weiß man aber, dass es wichtiger ist, dem Benutzer jederzeit zu zeigen, wo innerhalb der Architektur er sich befindet. Soviel zu vernetzten Dokumenten – bei Anwendungen kommt noch ein wichtiger Faktor hinzu: der Status. Die Grundlage des Web wie wir es kennen, das HTTP-Protokoll, ist ein zustandsloses Protokoll, dessen Zustandslosigkeit durch die Kombination mehrerer Technologien (Ajax) simuliert aufgebrochen wird. Das Kriterium des Systemzustands stammt aus der Software-Ergonomie, die sehr viel näher an der Anwendungs-Metapher liegt, als die Kriterien der klassischen Web Usability. Bedenkt man dieses Kriterium bei der Gestaltung der Oberfläche, so muss man dem Benutzer zu jeder Zeit klar zeigen, in welchem Zustand sich gerade das System befindet, dass er bedient. Das schließt natürlich wertvolle Fehlermeldungen ein, die an der Stelle angezeigt werden, an der ein Fehler geschehen ist – und die Möglichkeit, diesen Fehler leicht zu korrigieren.

Regel 3: Der Status des Systems muss zu jeder Zeit klar ersichtlich sein!

Verwirrung der Benutzer

Interaktionselemente müssen aussehen wie Interaktionselemente. Verwendet man als Gestalter beispielsweise Formularelemente, so ist man oft versucht, Checkboxen, Radiobuttons oder Texteingabefelder der Seitenanmutung anzupassen. Dies ist ein häufig begangener Fehler – hier kann nur Empfehlung sein, bereits erlernte Interaktionselemente zu nutzen. Apple formulierte eine ähnliche Richtlinie in seinen „Human Interface Guidelines“ so: „Users will learn your application faster if the interface looks and behaves like applications they’re already familiar with.“, auch Jakob Nielsen hat dazu etwas gesagt: „Users have several thousand times more experience with standard GUI controls than with any individual new design.“.

Regel 4: Die Bedienung durch Reduktion des kognitiven Aufwands erleichtern!

Schnittstelle zwischen Mensch und Maschine

Die Schnittstelle, über die man mit der Oberfläche interagiert, bestimmt zu einem großen Teil die Gestaltung. Konzipiert man Webseiten, so kann man höchstens mutmaßen, über welche Schnittstellen die Benutzer mit der Webseite interagieren – über die drei häufigsten sollte man allerdings nachdenken: Maus, Tastatur und Touch Screen. Das bringt, neben der Anforderung, durch die Tastatur bedienbare Webseiten zu produzieren, die Anforderung mit sich, die Dimensionen der Interaktionselemente der Schnittstelle Touch Screen anzupassen – gerade weil in naher Zukunft die Anzahl der verwendeten Geräte mit Touch Screen noch deutlich zunehmen wird.

Regel 5: Jede mögliche und wahrscheinliche Form von Schnittstelle in die Planung einbeziehen!

Reihenfolge

Die Reihenfolge von Interaktionselementen darf niemals von der technischen Umsetzung beeinflusst sein. Geschmackssache ist sie allerdings auch nicht, eher eine Gratwanderung zwischen Anforderungen, Informationsaufbau und Bedeutung der einzelnen Interaktionselemente. In vielen Fällen ist es sinnvoll, die gelernten Reihenfolgen einzuhalten, beispielsweise bei persönlichen Daten. Nimmt man beispielsweise die Anordnung von OK- bzw. Abbrechen-Schaltflächen in Desktop-Software, so machen es Microsoft und Apple völlig entgegengesetzt. In Microsoft Windows steht die OK-Schaltfläche stets vor der Abbrechen-Schaltfläche, bei Apples Mac OS X steht die OK-Schaltfläche grundsätzlich nach der Abbrechen-Schaltfläche. Und für beide Anordnungen gibt es gute Gründe.

Regel 6: Die Reihenfolge von Interaktionselementen will gut bedacht werden und sollte sich nie der technischen Umsetzung unterwerfen!

Nutzlose Interaktionselemente

Nutzlose Interaktionselemente und Elemente, die aussehen, wie Interaktionselemente, aber keine sind, haben nichts auf einer Webseite zu suchen. Gerade bei Formularen ist diese Regel unheimlich wichtig, denn Untersuchungen haben ergeben, dass schon mit der Reduktion um wenige Abfragen eine deutlich höhere Anzahl an vollständig ausgefüllten Formularen abgesendet wurde.

Regel 6: Nutzlose Interaktionselemente sowie Dinge, die aussehen wie Interaktionselemente, aber keine sind, müssen vermieden werden!

Konsistenz

Die Verwendung und die Verortung der verwendeten Interaktionselemente muss konsistent sein. Erwartet der Benutzer für eine bestimmte Funktion ein bereits vorher dafür verwendetes Interaktionselement, so sollte man kein anderes verwenden. Ebenso sollte man den Ort eines einmal eingesetzten Interaktionselement nicht ständig verändern, um so den Lernaufwand niedrig zu halten.

Regel 7: Konsistente Art und Ort eines Interaktionselements sind extrem wichtig!

Graceful Degradation

Nutzt man Interaktionselemente, die nur in bestimmten Systemen verwendbar sind, sperrt man Benutzer anderer Systeme aus. Um dies zu vermeiden, muss man die Funktionalität erhalten, ohne systemspezifische Interaktionselemente zu verwenden. Es gibt wenig schlimmeres als ein nicht funktionierendes Interface, dessen Benutzer nicht weiß, warum es nicht funktioniert.

Regel 8: Graceful Degradation stellt die Verwendbarkeit in ungeeigneten oder älteren Systemen sicher!

Löschen und Abbrechen

Viele Formulare machen Gebrauch von Reset- oder Abbrechen-Schaltflächen, die beide keinen anderen Zweck erfüllen, als den der Zurück-Schaltfläche des Browsers. Studien belegen, dass derartige Schaltflächen nur zu einem Versehen führen: man löscht den Inhalt des mühsam ausgefüllten Formulars, wenn man es abschicken will. Nur weil das Markup diese Schaltflächen als Standardfälle vorsieht, muss man sie nicht verwenden.

Regel 9: Die Verwendung von Reset- oder Abbrechen-Schaltflächen ist nur äußerst selten sinnvoll!

Vorbelegung

Standardwerte oder Vorbelegung von Interaktionselementen, besonders bei Formularen, ist beliebt, aber nicht immer sinnvoll. Es wirkt unverschämt, dem Benutzer zu unterstellen, er würde gern einen Newsletter bekommen oder die AGB akzeptieren – letzteres macht die dem Benutzer abgenommene Entscheidung sogar unwirksam. In jedem einzelnen Fall, sollte man sich eine Vorbelegung mit einem bestimmten Wert genau überlegen.

Regel 10: Vorbelegung von Interaktionselementen ist mit Vorsicht zu genießen und sollte von Fall zu Fall entschieden werden!

Gruppierung

Um die Zusammengehörigkeit von Interaktionselementen zu unterstreichen, ist es sinnvoll, sie visuell zusammenzufassen. Dazu können Rahmen, ein Bereich mit einer bestimmten Hintergrundfarbe oder ein Oberbegriff dienen.

Regel 11: Durch Gruppierung von Elementen lassen sich Zusammenhänge herstellen!

Beschriftung

Die Beschriftung von Interaktionselementen muss, wenn sie erforderlich ist, sprechend sein. Unklarheiten durch Formulierung oder Wahl der Begriffe müssen vermieden werden, auch muss die Beschriftung einen deutlichen Bezug zum beschriebenen Interaktionselement haben. Beschriftungen von Interaktionselementen, gerade bei Auswahl von mehreren Möglichkeiten, sollten außerdem immer positiv gewählt werden. „Ich möchte den Newsletter erhalten!“ wird eher verstanden, als „Ich möchte den Newsletter nicht erhalten!“. Man sollte es auch mit der Länger der Beschriftungen nicht übertreiben – Kürze und Prägnanz helfen dem Benutzer.

Regel 12: Sprechende und positive Beschriftungen erleichtern das Verständnis, Nähe zum beschriebenen Interaktionselement stellt einen Bezug her!

Reaktionszeit

Alle Interaktionselemente müssen schnell reagieren. Es gibt nur wenig Dinge, die den Benutzer schneller verjagen, als ein langsames Interface. Studien belegen, dass jede Reaktionszeit unter 0,1 Sekunde dem Benutzer das Gefühl gibt, sofort zu reagieren. Alles bis zu einer Sekunde nimmt der Benutzer als Verzögerung wahr, hält ihn aber nicht von dem ab, was er tut. Ab einem Limit von zehn Sekunden verliert der Benutzer jedoch den Fokus und tut andere Dinge, um die Zeit zu überbrücken, oder beendet die Interaktion komplett.

Regel 13: Die Reaktionsgeschwindigkeit während der Interaktion muss ständig beobachtet und bei Bedarf optimiert werden!

Stefan Nitzsche arbeitet als Webdesigner, Webentwickler, Berater und Autor mit über zehn Jahren Branchenerfahrung. Er lehrt Interface Design an der Mediadesign Hochschule in Düsseldorf, engagiert sich bei den Webkrauts für Webstandards und ist Mitglied des German Chapter (GC) der Usability Professional‘s Association (UPA).