alps hypertexte

Die Herren Usabilitologen berichten auf guuui.com mal wieder, dass die Navigationselemente einer Site wenig Beachtung finden, da der "suchende" User (als gäbe es keine anderen User-Typen) sich vornehmlich am mittleren Inhaltsbereich orientiert und Navigationslinks mit zu seiner Suchtask inkompatilen Beschriftungen ignoriert. Tja, das kommt davon, wenn man zuviel Eye-Tracking betreibt ... Kristoffer Bohmann sagt ja seit 5 Jahren schon Why Primary Navigation Must Die und demonstriert zeitgleich, dass man damit aber nicht übertreiben sollte. Als ich (für diesen Eintrag) den besagten Artikel nämlich gesucht habe, bin ich von seiner Startseite bohmann.dk (die ich glücklicherweise noch im Kopf hatte) ausgegangen. Da auf der Startseite aber nichts außer Kontaktmöglichkeiten existieren, musste ich Google bemühen, um seine Artikel zu finden. Ich finde, zu so einem Preis sollte man seine Hauptnavigation nicht gerade killen ... Usabilitologen sind schon kleine Extremisten. Und die Wahrheit, ob man primäre Navigationselemente anbieten soll oder nicht, liegt irgendwo zwischen den beiden Polen "Ja, ganz aufwendig" und "Nein, überhaupt nicht". Seit 7 Jahren beobachten die Usabilitologen also dieses Userverhalten. Tue ich auch, aber nicht nur. Ich beobachte u.a. auch das Uservehalten, dass nicht jeder sofort auf den Back-Button klickt, wenn er die gewünschte Seite/Info nicht vorfindet. Auch bei mir wäre so manche Recherche ins Leere gelaufen, wenn ich immer nur das Suchmaschinen-Interface verwendet hätte. Mit der Back-Klickerei kommt man nämlich in vielen Fällen nirgendwo hin. Tatsächlich haben fortgeschrittenere User mehr drauf, als nur den Umgang mit Google und dem Back-Button. Einige lernen nach "Sitemaps" zu schauen oder bestimmte Kategorien eines Artikel/Weblogarchivs zu durchwühlen. Einige sollen sogar schon so weit sein und Tabs verwenden und damit den Back-Button immer seltener gebrauchen Die Tipps in dem Artikel (mehr deep links zu setzen, Linkbeschriftungen eindeutig zu gestalten, auf ähnliche Texte/Produkte/Software am Ende einer Seite hinzuweisen) sind schon vernünftig. Aber die Hauptnavigation ganz wegfallen zu lassen, wäre 'ne dumme Idee.

... ist unhöflich. Die Groß-/Kleinschreibung hilft dem Leser, die Wörter und die Bedeutung des Satzes schneller zu erfassen. Ausserdem begünstigt es das sogenannte Querlesen eines Textes (eine Methode, mit der die Augen den Text durch diagonales scannen und nicht durch lineares Wort-für-Wort-Verfolgen lesen). Durchgehende Kleinschreibung ist anstrengender zu lesen; die Bequemlichkeit des Kleinschreibers geht also auf Kosten des Lesers. Ich persönlich deabonniere die Feeds der Kleinschreiber und werde auch nicht mehr mit Kleinschreibern in Kommentaren und Emails diskutieren. Nur mal so als Referenz abgelegt, damit ich mich nicht bei jedem Kleinschreiber wiederholen muss ...

Da man Kommentare meist nicht nachbearbeiten und es manchmal zu Missformatierungen kommen kann, habe ich hier wieder die Live-Preview-Funktion reaktiviert. Damit sieht der Kommentator gleich die Auswirkungen seiner Formatieranweisungen. Für Wordpress gibt's dafür ein entsprechendes PlugIn von Chris J. Davis. Da das PlugIn hauptsächlich aus ein paar Zeilen JavaScript besteht, lässt es sich auch locker auf andere CMSe übertragen. Eine Schwachstelle hat dieses Verfahren jedoch: Es werden auch Formatierungsanweisungen im Live Preview angezeigt, die in den Kommentaren nicht erlaubt sind. [Siehe auch: Kommentarformatierungshilfen I]

Die meisten Blogs geben dem Kommentator verschiedene Möglichkeiten, ihren Senf zu formatieren. In den letzten Tagen sind mir 2 sehr gegensätzliche Beispiele aufgefallen. Gegensätzlich in der Art und Weise, wie sie diese Möglichkeiten präsentiert werden. Nehmen wir die "Kommentarhilfe" von Anne van Kesterens Weblog.

Read the guidelines (20040601) if you don't get it. (In short: write complete, well-formed XHTML, without CDATA section and comments.) Comments are moderated. Contact me for off-topic replies. Thanks.

Ok, Anne schreibt viel über XML, XHTML und Validität. Man kann davon ausgehen, dass die Leserschaft weiss, was "well-formed XHTML" und "CDATA" bedeutet. Aber lasst mal den Ton auf euch einwirken: "... if you don't get it", "...moderated", "(20040601)" (häh?) und dann auf der Seite, in der die erlaubten Formatieranweisungen im Detail aufgelistet werden "you must [...] use a block level element" und lauter so nette Sachen. Ich meine, ich erzähle ja selber viel von Semantik und will nicht im Glashaus sitzend mit Steinen werfen, aber bei so einer Kommentierhilfe würde ich auch zittrige Finger kriegen, sollte ich dort mal meinen Senf abgeben wollen. Andere scheinen darauf übrigens auch allergisch zu reagieren. Eine ganz andere Kommentierhilfe sieht man auf Nicos Webpropaganda. Dort gibt es drei Möglichkeiten: Link setzen, Fett- und Kursivdruck. Der Kasten heisst "Hilfe", die drei Möglichkeiten werden jeweils mit 'nem Beispiel präsentiert und kein Wort von "Textile" oder so. Kurz, zeitsparend, verständlich und usable. Ich selbst befinde mich mit meinem Weblog wohl irgendwo zwischen diesen Polen. Erstens, weil ich mich nicht viel von der Wordpress Vorlage entfernt habe und zweitens, weil ich die Sache gerne auf einige wenige HTML-Elemente beschränke (kann niemandem schaden, ein paar einfache Tags zu lernen). Mir wäre ein WYSIWYG-Editor, der mit allen Browsern funktioniert, lieber. Aber die 3-4, die ich bisher ausprobiert habe, funktionierten mit dem Opera nicht. Oder kennt jemand mittlerweile eine Editor-Lösung, die mir entgangen ist?

Nein, in diesem Blog läuft eigentlich keine Privacy-Themenwoche, aber hier wieder ein Artikel gegen Online-Registrierungen (Quelle: webword.com). Vor allem, wenn es dazu dient eine Barriere vor Content, alte Archive und der Möglichkeit zu kommentieren, zu stellen. Einzig die Registrierung im Falle des Beitritts in eine Mailingliste sieht der Autor als legitim (wegen der Spam-Problematik). Und warum macht - vor allem hier zu Lande - die Old Media so'n Mist?

You get the sense that the more popular a publication becomes online, the more money it must be losing, hence the barriers.

Registration? For What? John C. Dvorak, 16.09.2004

Da ist se wieder, die Motivation Gedankeninfektion für viel Blödsinn: möglicher entgangener Gewinn. Das läuft dann in den Köpfen so ab: eines schönen Sommertags legt man sich mit dem Grashalm im Mundwinkel auf die Wiese und träumt davon, wieviele Reichtümer einem doch zustünden, wenn auch nur die Welt da draußen das so sehen würde. Dann steht man auf und geht ins Büro und sieht nur noch Minusbeträge, die einem am laufenden Band zu entgehen scheinen. Ihr wisst ja, aus der selben Gedankeninfektion heraus zerrt die Musikindustrie schon seit längerem Studenten und Senioren vor den Kader. RIAA-Klagen, Archiv-Registrierungen, Fotoverbote bei wichtigen Veranstaltungen ... alles nur Symptome der selben Krankheit.

Ein interessanter Ansatz von Ben Hyde, was die Datenreduktion in Registrierungen angeht: Clubs - privacy services. (Quelle: Internet Alchemy Weblog) Ein Beispiel, dass am Ende genannt wird, ist die Anmeldung bei der städtischen Bibliothek. Die Bibliotheksverwaltung muss im Prinzip nur zwei Dinge wissen, um Bücher an ein neues Mitglied verleihen zu können: 1) Wohnt die Person in dieser Stadt? 2) Wird sie die ausgeliehenen Bücher auch wieder zurückbringen? Ersteres könnte durch eine Abfrage an einem städtischen privacy server erledigt werden, welches als Output nur eine Bestätigung in der Form "Ja, diese Person wohnt in dieser Stadt" liefert und in die Mitgliedskarte einträgt. Eine Empfehlung könnte von einer anderen Bibliothek kommen. Etwa in der Form, dass die abrufende Person schon soundso-lange Mitglied ist/war und immer seine Bücher zurückgebracht hat. Dadurch klärt die Bibliothek die beiden wichtigsten Punkte der Anmeldung und die Privatssphäre des Anmelders bleibt gewahrt. Schöne Idee, aber erstmal die Bürokraten finden, die die Cohones haben ein solches System umzusetzen. Naja, ich besorg mir jetzt erstmal 'ne 0190'er Nummer, da immer öfter auch Telefonnummern in Anmeldeformularen abgefragt werden

Altes Thema, klare Worte:

Here are some good defaults: For fluid designs, make your text columns at most 30-35em wide. Fixed-width designs should generally have text columns no wider than 480-500px (at 14pt type).

Long Live Line Length, 03.09.2004, the daily flight

(Nebenbei: Klasse Design nicht mehr )