Wann kauft Google CrazyEgg?
Vor einigen Tagen hat mich Maximilan Wenzel (Co-Autor im Webdesignblog) auf ein sehr interessantes Tool namens Crazy Egg hingewiesen. Mit diesem Tool ist es möglich, die Surfaktivität seiner User zu tracken, dadurch kann man sehen welche Links eher geklickt werden, und welchen Bereichen der Website die größte Aufmerksamkeit geschenkt wird.
Durch diese Information kann man die Usability seiner Website erhöhen, eine bessere Anzeigenposition für Werbung herausfinden oder einfach mal sehen welche Links so gut wie keine Aufmerksamkeit erhalten.
Dieses Tool ist in der Grundversion kostenlos und zum testen reicht das allemale. Bleibt nur noch die Frage wann Google das Tool aufkauft und kostenlos anbietet, würde ja in Google Analytics gut reinpassen.
Google Sitemaps heißt jetzt Webmaster Central
Viele werden jetzt sicher sagen, das ist doch nur alter Wein in neuen Schläuchen, aber ganz so ist es nicht, denn Google wäre nicht Google, um dies nicht auch gleich für die Integration von neuen Tools zu nutzen. An sich ist Sitemaps vor allem dafür entwickelt worden, Google einen schnelleren Informationszugang zur eigenen Internetseite zu gewähren.
Inzwischen hilft der Marktführer aber auch immer mehr dem (vor allem ehrlichen) Webmaster, da z.B. Dinge wie das bekannte Problem des doppelten Contens auf der eigenen Domain inzwischen gemeldet werden können, was gerade für User ohne Server- bzw. PHP-Kenntnisse oder bei kleinen Hostingpaketen ganz ohne PHP von Vorteil ist.
Mehr Informationen dazu gibt es im Support oder per Video (etwa 7 Minuten) vom Googlemitarbeiter Matt Cutts.
Sehr praktisch ist ebenso die Abfragestatistik, welche Auskunft über einige Keywordphrasen gibt und wie die eigene Webseite dort in etwa gerankt ist, in meinem Fall mit “p990i erscheinungstermin” an durschnittlicher Spitzenposition 3 (der Durchschnitt errechnet sich hier aus den letzten 3 Wochen). Das Ganze kann man zudem als CSV-Datei herunterladen und entsprechend verarbeiten.
Ich denke Google ist mit solchen Services auf einem guten Weg noch mehr Nutzer vor allem langfristig zu binden, auch wenn Webmaster Central sicher noch ausbaufähig ist. Wer lieber gleich alle Daten haben möchte muss mal bei AOL vorbeischauen… ;-)
Der Autor dieses Artikel ist Maximilian Wenzel und er bloggt unter anderem im p910i-blog
Usability ist nicht alles
Usability ist der Versuch, eine von einem Menschen benutzte Anwendung optimal für diesen benutzbar zu machen, nur um dann festzustellen, das zuviel Usability einfach langweilig aussieht.
Wie schon häufiger erwähnt benötige ich bei meinem derzeitigen Projekt einige Formulare und bei der Erstellung und Auswertung der Formulare werde ich bestens von PEAR unterstützt. Wenn ich mir die Formulare anschaue dann kann ich zufrieden sagen: “Diese Formulare erfüllen zu 95% alle gestellten Usability-Kriterien”, doch leider sehen sie einfach nur langweilig aus.
Formulare müssen “benutzbar” sein
Hier geht PEAR aber den eindeutig korrekten weg, denn die von PEAR dargestellten Formulare sind absolut funktional und halten sich an bestehende Usability-Kriterien: Zum Beispiel wird neben jedem Pflicht-Feld ein kleiner roter Stern ausgegeben und ein Feld welches nicht ordnungsgemäß ausgefüllt wurde, wird, zumindest der Name, mit rot unterlegt.

Worauf ich eigentlich hinauswill: “Funktion und Design müssen voneinander getrennt werden”. PEAR stellt die Funktionalität bereit und liefert an Usability-Maßstäben orientierte, gut funktionierende Formulare.
Usability ist nicht alles
Das das ganze nun zwar funktioniert aber nicht schön aussieht, liegt daran das “Funktion” nunmal nicht “Design” ist, aber das macht auch nichts, denn nun haben wir die Möglichkeit unsere Funktionalität, die uns PEAR liefert, schön aufzubereiten, zum Beispiel mit einem Template-System wie es uns Smarty liefert. Denn der optische Teil einer Webanwendung hat ebenfalls einen sehr hohen Stellenwert beim Benutzer, ob wir wollen oder nicht, der erste Eindruck entscheidet und wenn uns etwas optisch nicht gefällt, verziehen wir uns schnell wieder. Durch eine Anpassung des Designs kann mitunter, bzw. wird sehr wahrscheinlich die Usability leiden, aber diesen Schritt sollte man vollziehen denn die größte Usability bringt einem nichts, wenn niemand da ist der die Anwendung auch benutzt – der goldene Mittelweg zwischen Usability und Design.
Wo Usability aufhört
Ich arbeite derzeit an einem Projekt bei dem ich einige Formulare benötige und da Formulare immer die Eingabe eines Users voraussetzen muss man natürlich auch stark auf die Usability achten, zum Beispiel auf falsche Eingaben hinweisen. Falsche Eingaben können sein:
- Formularfeld nicht ausgefüllt
- Inhalt zu lang/ zu kurz
- nicht unterstütze Sonderzeichen
Jetzt bleibt nur die Frage, wann macht es Sinn unter einem Formular auszugeben, das die Eingabe in einem Feld “benötigt” wird und wann ist es überflüssig? Dazu muss man sich anschauen warum es diesen Hinweis “in diesem Feld wird ein Wert verlangt” gibt. Meist wird er eingesetzt bei Formularen mit mehreren Feldern um auf die wichtigen Felder hinzuweisen und dem User so ein schnelleres ausfüllen des Formulars zu ermöglichen. Es ist also absolut nicht nötig und sinnvoll diesen Hinweis in allen Formularen auszugeben, wie man auch gut bei Yahoo sehen kann. Wird in das Suchfeld kein Wert eingetragen und man klickt auf “Web-Suche” wird man einfach auf eine weitere Suchseite geschickt auf der man seine Eingabe tätigen kann, kein Hinweis, kein Fehler. Die User scheinen mittlerweile soweit zu sein, das man auf den übermäßigen Einsatz von Hinweisen verzichten kann. Ich empfehle daher nur bei großen Formularen Hinweise auf “benötigte Felder” zu setzen, zum Beispiel bei der Registrierung eines neuen Users. Was haltet ihr davon, wie würdet ihr es machen?
Programmierung eines Registrierungsformular – was muss man beachten
Wer auf seiner Website ein Registrierungsformular benötigt, damit sich seine Nutzer als Mitglieder identifizieren können, muss einiges beachten. Als erstes folgt ein Beispielformular und danach meine Checkliste:

Checkliste
- Username darf noch nicht in Datenbank vorhanden sein
- Email darf noch nicht in DB vorhanden sein
- Passwort muss min.-/ und max.-Länge haben
- Leerzeichen am anfang oder am ende einer Eingabe sollten automatisch entfernt werden (Bsp.: ” passwort ” wird zu “passwort”)
- Username muss min.-/ und max.-Länge haben
- Passwort muss in beiden Feldern identisch sein
- die Emailadresse muss den Regeln entsprechen, läßt sich per PHP prüfen mit “RegExpressions”
- “Registrieren”-Button darf nur einmal gedrückt werden -> verhindern das der Button “ausversehen” zweimal gedrückt wird, bzw. verhindern das Daten doppelt abgeschickt werden
Was sich zuerst nach einer Arbeit von 5 Minuten anhört, “Programmier mal eben ein Registrierungsformular”, kann sich, bei sauberer, sicherer und effizienter Programmierung, zu einer längeren Aufgabe hinziehen. Gerade bei Formularen sollte man aber seine zur Verfügung stehende Arbeitszeit investieren, denn hier spielen sicherheits-technische Kriterien eine hohe Rolle. Wer hier einen Fehler begeht öffnet Tor und Tür seiner Website für Hacker und Cracker.
Hier empfiehlt sich wieder der Einsatz der Klassenbibliothek PEAR die mit vielen Funktionen eine saubere, sichere und vorallem schnelle Programmierung eines Formulars ermöglicht. Für interessierte: Schaut euch mal das Package “HTML_Quickform” an. Sucht aber am besten nach Tutorials im Netz, denn die Online-Doku von PEAR ist absolut ungenügend für Einsteiger.
Habt ihr noch was auf das man bei einem Registrierungsformular achten sollte?
