Wer schon einmal längere Zeit mit einem (W)CMS gearbeitet hat, wird sich bald wünschen, sie wäre ein normales Programm für sein Betriebssystem und keine Webanwendung. Die meisten Webanwendungen die ich kenne haben äußerst wenig Komfort. Meistens beschränken sie sich auf das Bereitstellen von Eingabefeldern und die Auswertung nach dem Absenden des Formulars. Wenns ganz schlimm kommt, ist das Formular auch noch in alle möglichen Tabellen eingepackt, enthält Inline-Bilder usw.

Ideen

Es gibt eine ganze Reihe von Funktionen, die sehr nützlich wären. Einige von ihnen sind leichter, andere schwerer zu realisieren.

1. Klick auf die Beschriftung fokussiert Eingabefeldes
2. Größenveränderliche Texteingabefelder
3. Autosave für Formulare
4. Karteireiter für aufwändige Formulare
5. Einfache Umsortierung von Listen
6. Sinnvolle Tabulatorreihenfolge
7. Sofortige Formularfeldauswertung und ggf. Korrektur
8. Möglichkeit zur stapelweisen Eingabe von Daten
9. Neue Formularelemente

1. Klick auf die Beschriftung fokussiert Eingabefeldes

Es ist überraschend wie viele Formulare es im Internet gibt, die diese einfache Möglichkeit, die Usability eines Formulars zu verbessern, nicht wahrnehmen. Dabei ist es so einfach. Es ist nur nötig, die Beschriftung des jeweiligen Formularfeldes in ein label-Tag zu schreiben und dann die passenden for-Referenzen zu setzen. Schon springt der Cursor automatisch in das dazugehörige Feld, Checkboxen werden aus- bzw. eingeschalten und Radiobuttons werden aktiviert - wie auch in allen grafischen Betriebssystemen die ich kenne.

Weitere Informationen: SelfHTML über das label-Element

2. Größenveränderliche Texteingabefelder

Es ist fast nicht möglich, ein Texteingabefeld (ich meine hauptsächlich mehrzeilige Felder, also textarea) in der genau passenden Größe zu machen. Es kommt ja auch immer auf den Text an, der hier reingeschrieben werden soll. Manchmal ist der Artikel eben länger, manchmal nur eine kurze Nachricht, vielleicht aber auch ein besonders langer Kommentar zu einem Blogbeitrag. Besonders praktisch ist es, wenn man die Größe des Texteingabefeldes dauerhaft(!) verändern kann. Es gibt zwar eine Erweiterung für den Firefox, aber nicht jeder Benutzer hat die installiert - von Anwendern anderer Browser ganz zu schweigen. Es ist sinnvoll, dem Autor eine Möglichkeit zu geben, die Größe des Texteingabefeldes an seine Wünsche anzupassen. Mit dauerhaft ist gemeint, dass das System mit dem der Benutzer arbeitet sich die eingestellte Größe “merkt” und beim nächsten Formularaufruf genau so groß anzeigt.

3. Autosave für Formulare

Wem ist es noch nicht passiert, dass er einige Zeit damit verbracht hat, einen Beitrag für ein Weblog, ein Forum oder in ein CMS zu schreiben und dann beispielsweise versehentlich auf den falschen Button geklickt hat - der Text war verloren. Es spart einiges an Ärger, wenn das System hier einen Autosave-Mechanismus bereitstellt. Schon während der Benutzer noch den Artikel verfasst wird der Inhalt in periodischen Abständen zum Server übertragen und dort zwischengespeichert - ohne das der Benutzer kurz unterbrechen muss oder überhaupt etwas von der Aktion mitbekommt. Wenn der Anwender nun versehentlich das Browserfenster schließt, oder sonstwie die Seite verlässt, ist der Text immer noch gespeichert. Man könnte hier auch wie z.B. WordPress mit Entwürfen arbeiten.

Eine solche Autosave-Funktion kann man zum Beispiel verhältnismäßig einfach mit Techniken wie XMLHttpRequest oder versteckten Iframes realisieren.

4. Karteireiter für aufwändige Formulare

In vielen Content-Management-Systemen findet man umfangreiche Formulare, oft auch über mehrere Seiten hinweg verteilt. Zum einen tragen solche Ansammlungen von Formularelementen nicht gerade zur übersicht bei. Der Benutzer hat beispielsweise nicht den Titel, den er für einen Artikel vergeben hat im Blickfeld wenn er weiter runter scrollt um den eigentlichen Text einzugeben. Oft werden manche Funktionen sehr selten oder nur bei bestimmten Gelegenheiten benutzt. Eine Auslagerung in einen nicht sichtbaren Karteireiter wäre hier sehr sinnvoll.

Wenn Formulare über mehrere Seiten hinweg verteilt sind, kann man mit dieser Technik z.B. auch eine flüssigere Eingabe sorgen da man nicht zwischendurch ständig neue Seiten laden muss. Wenn man auf einer Karteireiterseite unten angekommen ist aktiviert der Klick auf einen Link die nächste Seite - ohne lange Wartezeiten. Für den Benutzer ist es auch angenehm wenn ihm beispielsweise auf jeder Seite oben ein “Workflow”, also eine Auflistung der noch zu erledigenden Arbeitsschritte bis zur Fertigstellung des Artikels, angezeigt wird.

5. Einfache Umsortierung von Listen

In so gut wie allen CMS gibt es Orte an denen die Darstellung von Listen fast zwingend ist. Beispiele sind hier die Anzeige eines Verzeichnisbaumes oder die Sortierung einer Artikelliste. Die meisten System behelfen sich zur Sortierung mit Pfeilen oder anderweitig beschrifteten Buttons neben jedem Element. Das es auch anders geht, zeigt Tim Taylor in “Drag & Drop Sortable Lists with JavaScript”. Interessant ist auch das [Beispiel] für ein Verschieben zwischen zwei Listen.

Für den Benutzer ist es viel einfacher, wenn er mit der Maus den Inhalt an die gewünschte Stelle verschiebt anstatt sich mit Pfeilbuttons herumzuquälen, die bei jeder Sortieraktion auch noch den Platz ändern - das Element ist in der Liste ja schließlich weiter nach oben gerutscht.

6. Sinnvolle Tabulatorreihenfolge

In vielen Formularen im Internet fehlt auch eine sinnvolle Tabulatorreihenfolge. Genau so wie in [1.] ist auch diese Funktion nur mit HTML und ohne die Zuhilfename von Scripting zu lösen. HTML bietet das Attribut tabindex an um eine sinnvolle Tabulatorreihenfolge festzulegen. Bei Formularen, die ohne Tabellen auskommen, also bei denen die Formularelemente im Quelltext in der richtigen Folge nacheinander kommen, ist diese Funktion nur zweitrangig da sowieso durch die Anordnung im Code eine einigermaßen sinnvolle Reihenfolge vorgegeben ist. Aber gerade bei älteren Formularen, die möglicherweise auch noch mit Tabellen strukturiert worden sind, ist es sinnvoll, eine passende Tabulatorreihenfolge vorzugeben, die dem Benutzer ein zügiges Eingeben von Daten ermöglicht. Aber man sollte auch nicht übertreiben. Normalerweise erwartet der Benutzer nämlich, dass der Cursor bei einem Druck auf Tab in das nächstgelegene Eingabefeld springt. Wenn das aber am Ende der Seite liegt, wird er nur verwirrt und in seinem Arbeitsfluss gestört.

7. Sofortige Formularfeldauswertung und ggf. Korrektur

Die Funktion, die vielleicht am wichtigsten ist, ist die Auswertung von Formularfeldern. Man kennt ja schon, dass manchem Webseiten vor einem Klick auf Absenden alles prüfen und den Benutzer darauf hinweisen, dass er ein Feld noch nicht ausgefüllt hat. Oder die Korrekturseite nachdem ein Formular auf dem Server überprüft wurde. Das sind zwar schon gute Ansätze, geht aber noch nicht weit genug. Zum einen wird der Benutzer erst auf einen Fehler hingewiesen wenn er schon lange an dem Feld vorbei ist und vielleicht schon gar nicht mehr daran denkt, zum anderen verlangsamen nachgeschaltete Korrekturseiten oder JavaScript-Popups den ganzen Vorgang.

Sinnvoller wäre es, den Benutzer gleich bei der Eingabe der Daten auf Fehler aufmerksam zu machen. Wenn ein Fehler aufgetreten ist - beispielsweise eine ungültige E-Mail-Adresse - kann das Feld rot umrandet werden und/oder (für farbenblinde Menschen) ein kurzer Hinweistext erscheinen. Hier tritt aber auch wieder XMLHttpRequest auf den Plan. Eine serverseitige Formularüberprüfung ist nämlicht ebenfalls nötig um ungültige Eingaben - von böswilligen Benutzern direkt per GET oder POST übergebene Parameter, die nicht durch eine clientseitige Prüfung validiert wurden - zu überprüfung und gegebenenfalls zu bemäkeln. Mit XMLHttpRequest ist es möglich, die Validierung der Eingabedaten nur auf den Server abzuwälzen. So braucht der Benutzer auch nicht sämtliche Funktionen zur Überprüfung als JavaScript/ECMAScript zu laden.

Aber nicht nur die einfache Prüfung auf Korrektheit fällt in diese Rubrik. Denkbar wären auch gescriptete Eingabefelder, die nach viel komplexeren Mustern Dateneingaben überprüfen, beispielsweise Datumsfelder. Oft muss man verschiedene Daten oder Zeiten eingeben, ein Problem ist hierbei die zulässige Eingabemaske, also wie das Datumsformat aufgebaut sein muss. Um das zu vereinfachen kann man automatisch die vom Benutzer eingegebenen Zahlen in ein Datum konvertieren lassen. Simon Willison hat eine Demonstration eines solchen Eingabefeldes auf seiner Webseite. Darüberhinaus könnte man auch einen dynamisch generierten Kalender unterhalb oder neben dem Feld einblenden um so die Auswahl des richtigen Datums zu vereinfachen.

8. Möglichkeit zur stapelweisen Eingabe von Daten

Vielen webbasierten Systemen fehlt eine sinnvolle Möglichkeit zur stapelweisen Eingabe von Daten. Oft hat man größere Mengen an Daten einzugeben und wünscht sich, dass nicht ständig Bestätigungsseiten kommen und dass man sich nicht immer erneut zum Eingabeformular durchklicken muss. Hier wäre es hilfreich, zum Beispiel auf dem Formular ein Häkchen zu setzen, das das System anweist, nach dem Absenden des Formulars direkt zu einem neuen leeren Formular zu springen. Wenn es sich nur um wenige Eingabefelder handelt kann man das auch per XMLHttpRequest automatisieren und das bisherige Formular zusammenklappen, eine Statusmeldung anzeigen lassen und per JavaScript ein neues Formular generieren. So lässt sich flüssig arbeiten.

9. Neue Formularelemente

Nahezu alle Formulare im Internet begnügen sich nur mit den in HTML definierten Eingabefeldern. Für Aufgaben wie Farben auswählen, Bereiche auf Bildern markieren oder um eine Größenangabe zu machen sind aber andere Formularelemente besser geeignet, beispielsweise ein Slider für Zahlen oder ein buntes Feld wie in Bildbearbeitungsprogrammen für Farben. Natürlich ist es nötig, solche Formularelemente selbst zu programmieren. Mittels JavaScript sind dem Einfallsreichtum eigentlich keine Grenzen gesetzt - man sollte sich aber trotzdem an die gängigen Konventionen halten und nicht versuchen, besonders ausgefallene Eingabemöglichkeiten bereitzustellen.

Risiken

Natürlich hat der Einsatz der geschilderten Techniken und Ideen auch Risiken. Am größten ist sicherlich das Risiko, dass der Benutzer in seinem Browser das Scripting deaktiviert hat - alle per JavaScript/ECMAScript hinzugefügten Erweiterungen sind damit nicht vorhanden. Es ist besonders wichtig, dass ein Formular - zumindest wenn normale Webbenutzer damit umgehen - auch dann noch in seinem vollen Funktionsumfang benutzbar bleibt, wenn der Browser die Scripts nicht versteht oder verstehen darf.

Ein weiteres Risiko ist auch, dass die Zugänglichkeit des Formulars eventuell verschlechtert wird. Auch hier ist es notwendig, dass Menschen mit Einschränkungen, die zum Beispiel Screenreader benutzen (müssen) oder Farbenblinde das Formular immer noch benutzen können.

Um diese beiden Risiken zu minimieren, sollte man Formulare die man erstellt immer auch ohne aktiviertes JavaScript testen. Wichtig ist auch der Einsatz von “unaufdringlichem” JavaScript (siehe den Artikel “Unobtrusive Javascript”), wie bei jeder Anwendung von JavaScript.