BEIER-CHRISTIAN.eu » webdesign

Wirify: Bookmarklet das aus einer Website einen Wireframe macht

Christian Beier — Tue, 08 Feb 2011 08:47:48 +0000

Wird schnell mal ein Wireframe von einer bestehenden Website benötigt? Mit dem Bookmarklet Wirify ist das kein Problem und geht mit einem Klick. Das kleine Tool ist sehr hilfreich, wenn vor einem Redesign der Status Quo festgestellt werden soll oder bisherige Entwicklungen, hinsichtlich verschiedener Designparameter (Abstände, Weißraum, Platzaufteilung) überprüft werden sollen.

» Wirify: The web as wireframes

Life Below 600px

Christian Beier — Wed, 24 Feb 2010 12:07:51 +0000

Life Below 600px, ist ein sehr interessante und grafisch hochwertig aufbereiteter Artikel, über die imaginäre 600 Pixel Grenze im Webdesign. Wie bei Zeitungen wird im Webdesign versucht, das Wichtigste (und das ist bekanntlich meist alles) oberhalb des »Knicks« anzuordnen. Weshalb dies nicht so gut ist und wie viel Leben unter einem solchen Eisberg stecken kann, zeigt der Artikel.

SlickMap CSS – einfaches Erstellen von Sitemaps

Christian Beier — Sat, 11 Jul 2009 14:17:39 +0000

SlickMap CSS ist ein einfaches »Framework« zum Erstellen von Sitemaps, direkt als HTML. Dazu wird eine ungeordnete Liste genutzt die beliebig verschachtelt (bis zu drei Level) werden kann, woraus dann die Sitemap entsteht.

html5gallery – Beispiele für den Einsatz von HTML5

Christian Beier — Mon, 29 Jun 2009 14:56:34 +0000

html5 Gallery ist ein Showcase von Websites, die bereits Elemente des HTML5-Standards nutzen. Die Galerie soll als Inspirationsquelle dienen und aufzeigen, was mit den neuen Elementen alles möglich ist. Dabei kommt es nicht auf eine hohe Browserkompatibilität an, sondern die gezeigten Seiten sind eher experimenteller Natur. Via Webkrauts.

Typekit, eine neue Möglichkeit für mehr Schriftenauswahl im Webdesign

Christian Beier — Fri, 29 May 2009 11:40:06 +0000

Wer außergewöhnliche Schriften im Webdesign verwenden möchte, hat ein Problem. Zum einen fehlt es an einer zuverlässigen technischen Lösung und auch das Thema der Schriftenlizenzierung ist bisher ungeklärt. Bisher gibt es zwar sIFR (was ich teilweise auch schon eingesetzt habe) oder andere Lösungen die sich JavaScript/Flash/Canvas bedienen, aber alle haben ihre Nachteile und sind nicht wirklich »rund«. Und der diese Scripte mit nicht expliziert freigegebenen Schriften verwendet, befindet sich in einer rechtlichen Grauzone.

Mit Typekit wurde jetzt ein Dienst angekündigt, der alle diese Probleme lösen soll. Es sollen eine Reihe von Schriften angeboten werden, die über ein JavaScript in der Seite verwendet werden können. Die Schriftendateien werden dazu auf den Servern von Typekit bereitgestellt und – je nach Möglichkeit des Browsers – nativ über CSS eingebunden. So wie es aussieht, konvertiert Typekit die Schriften auch in EOT, womit diese auch im Internet Explorer zur Verfügung stehen. Also keine Krückenlösung mehr, sondern eine Möglichkeit die die Funktionen der Browser nutzt. Dies macht sich sowohl in der Geschwindigkeit, wie auch beim Handling (Rechtsklick, Kopieren von Text etc.) bemerkbar.

Für alle Schriften die über Typekit zur Verfügung stehen ist die Rechtslage geklärt. So richtig beliebige Schriften können damit jedoch weiterhin nicht verwendet werden. Zudem begibt man sich natürlich in eine gewisse Abhängigkeit, da die Schriften bei typeface gespeichert sind und nicht auf dem eigenen Server. Fällt der Dienst einmal aus, sieht die Website auch schnell wieder recht trostlos aus. Und natürlich wird das Angebot nicht ganz kostenlos sein.

Wahrscheinlich werden auch nicht die regulären Schriften angeboten, sondern optimierte Webfonts. In diesen wird der Umfang der mitgelieferten Zeichen wohl reduziert sein (um die Ladezeit klein zu halten) und auch eine Optimierung für die Bildschirmdarstellung wäre nicht schlecht.

Typekit soll im Sommer veröffentlicht werden. Bis dahin wird es hoffentlich noch weitere Details zu erfahren geben. (Via Mashable)

YAML Debug – Hilfreiches Analyse-Tool

Christian Beier — Sat, 18 Apr 2009 10:53:24 +0000

Für das CSS-Framework YAML gibt es jetzt ein sehr hilfreiches Debugging-Tool. Mit diesem lässt sich sehr schnell die semantische Struktur einer Webseite sichtbar machen und die Qualität des Codes überprüfen. Auch bestimmte Aspekte der Barrierearmut lassen sich abtesten und so u.a. Bilder mit fehlenden oder leeren Alt-Attributen hervorheben. Und obwohl YAML im Namen enthalten ist, ist das Bookmarklet nicht nur auf den Einsatz bei YAML-Websites beschränkt. YAML Debug stellt eine wunderbare Ergänzung zu Firebug da und kann unter Firefox (ab Version 3), Opera (ab Version 9) und allen Webkit-Browsern genutzt werden.

Sitemaps und warum man sie nicht braucht

Christian Beier — Wed, 08 Apr 2009 14:47:57 +0000

Nach langer Zeit musste ich mich aufgrund eines Kundenwunsches für eine Website wieder mit dem Thema »Sitemap« auseinandersetzen. Sitemaps, das sind die Gebilde, die dem Anwender einen Überblick über die Struktur einer Website geben und als Navigationshilfe dienen sollen. Gerade bei einer komplexen Website wird gerne eine Sitemap verwendet, damit die mühsam ausgedachte und ausgefeilte Struktur dahinter auch deutlich wird. Zusätzlich wird eine Website gleich etwas für Suchmaschinen optimiert und die Linkdichte erhöht.

Aber sind wir einmal ehrlich: Wann haben Sie das letzte Mal eine Sitemap bewusst benutzt oder gar vermisst? Ich jedenfalls schon seit Jahren nicht mehr, wenn überhaupt einmal. Und Zahlen bestätigen meinen Eindruck: Wenn Nutzer direkt nach der Struktur einer Website gefragt werden, greifen gerade einmal 7 % auf die Sitemap zurück. Das schreibt Jakob Nielsen in seinem Essay »Site Maps are Used Rarely«.

Eine Sitemap soll – neben dem SEO-Aspekt – als als Hilfe zur Navigation dienen. Für die Navigation ist allerdings die Navigationsleiste und evtl. zusätzlich eine Suchfunktion gedacht. Warum dann also eine zusätzliche Sitemap entwerfen? Meine Schlussfolgerung daher: »Wenn innerhalb einer Website eine Sitemap benötigt wird (aus welchem Grund auch immer), ist entweder die Navigation schlecht gelöst oder die Struktur nicht optimal. Ein Grund dafür kann eine vom »Otto-Normal-Benutzer« nicht nachvollziehbare Bezeichnung (z.B. weil durch übermäßige Verwendung von Fachbegriffen) oder einfach eine zu komplexe und undurchschaubare Struktur sein. Aus diesem Grund sollte eher die Navigation bzw. Struktur aufgeräumt werden, als eine zusäbeitzliche Sitemap anzubieten, die eh nicht genutzt wird. Ansonsten stellt eine Sitemap nur eine Zweite und damit eigentlich doppelte Navigation dar und ist damit eine redundante Information. Und diese sollte vermieden werden, um den Anwender nicht zu verwirren. Das wiederum bedeutet auch, dass eine Sitemap den Nutzer meist mehr verwirrt, als dass sie ihm wirklich hilft.

IconDock – Benutzerfreundlicher Warenkorb

Christian Beier — Sat, 14 Mar 2009 10:09:11 +0000

Die Visualisierung eines Einkaufskorbes wurde bei IconDock sehr schön gelöst:

Zusätzlich zu den üblichen »In den Warenkorb«-Button, wurde der Kontext des »Ich lege einen Artikel in meinen Einkaufskorb« aus dem Alltag sehr clever in den digitalen Einkaufsprozess übertragen. So kann ich ein Icon per Drag and Drop in den Warenkorb »Dock« ziehen, wo dieses abgelegt wird. Zusätzlich hat der Kunde jederzeit den Inhalt und Wert während des Einkaufs im Blick.

Gleichzeitig ist es ein anderes Erlebnis für den Nutzer, wenn er so einkaufen kann. Es macht einfach mehr Spaß, als nur einen schnöden Button zu drücken. Dies ist natürlich auch weiterhin möglich, wenn die Drag an Drop Funktion z.B. nicht funktionieren sollte. Gerade durch die »Spaß-Funktion« kauft sicherlich der eine oder andere Kunde auch etwas mehr, nur um die Funktion erleben zu können.

Designer sind keine Programmierer

Christian Beier — Thu, 12 Mar 2009 14:35:06 +0000

Designers are not Programmers: Designer mit Programmierkenntnissen denken meist schon im Designprozess über die spätere Umsetzung im Code nach. Das lässt sich kaum vermeiden. In seinem Blog hat Lukas Mathis recht anschaulich beschrieben, warum genau das schlecht ist. Denn dadurch wird die Möglichkeit gesteigert, dass gute Idee für das User Interface schon im Gehirn verworfen werden. Durch diese Scheuklappen werden meist optimale Ergebnisse im Hinblick auf Usability und User Experience verhindert. Via Martin Labuschin.

Usability-Gedanken zu Wizards im Webdesign

Christian Beier — Wed, 21 Jan 2009 13:12:19 +0000

Mehrseitige Formulare (auch unter der Bezeichnung »Wizard« bekannt) sind eine gute Möglichkeit, strukturiert und übersichtlich Informationen vom Benutzer abzufragen. Dazu wird das gesamte Formular in kleine, gut zu verdauende Häppchen aufgeteilt und immer nur einzelne Teile dem Nutzer angezeigt. Dadurch können auch Teile mit Informationen aus vorherigen Schritten interagieren und dementsprechend andere Informationen oder Eingabefelder angezeigt werden. Wizard-Formulare eigenen sich daher besonders gut für umfangreiche und komplexe Eingabeprozesse.

Bei all den Vorteilen haben diese Formulare aber auch einen gravierenden Nachteil bei der Benutzererfahrung und Benutzbarkeit. Da der Nutzer immer nur einen Teil und nicht das gesamte Formular sieht, kann er die genaue Dauer und Umfang der Eingaben nicht überschauen. Er weiß vorher praktisch nicht was von ihm (noch) verlangt wird.

Stellen wir uns einen Registrierungsprozess für einen Webdienst vor: Der Nutzer fängt beim ersten Schritt an und sucht sich einen Benutzername und ein Passwort aus, im zweiten Schritt sind seine Interessen gefragt, die er schnell aus einem Dropdown-Feld auswählen kann. Soweit hat der Anwender mitgemacht und freut sich schon, dass er die Prozedur gleich hinter sich gebracht hat. Im dritten Schritt verlangt der Betreiber von ihm aber eine ausführliche, ausformulierte Beschreibung. Unglücklicherweise ist dieses Feld auch noch ein Pflichtfeld und lässt sich nicht überspringen oder später ausfüllen. Der Nutzer ist jetzt also gezwungen sich einen Text auszudenken, wozu er aber eigentlich keine Lust oder im Moment keine Zeit hat. Er ist also frustriert und hat eine schlechte Erfahrung (User Experience) gemacht. Hätte der Nutzer gleich am Anfang gesehen, dass von ihm ein längerer Text abverlangt wird, hätte er die Registrierung zu einem späteren Zeitpunkt durchführen können. Er hätte es zumindest vorher gewusst und sich darauf einstellen können. Eine schlechte Nutzererfahrung und Frustration wäre so vermieden worden.

Das heißt nicht, dass Wizards überhaupt nicht eingesetzt werden sollten. Es kommt hier immer auf den genauen Einsatzzweck an und im Zweifelsfall sollte auf mehrseitige Formulare eher verzichtet werden. Bei wirklich umfangreichen und komplexen Eingaben können die Vorteile trotzdem überwiegen. Hier sollte aber zu Beginn des Formulars klar kommuniziert werden, was auf den Anwender zukommt und er sollte immer sofort sehen können, bei welchem Schritt er sich befindet und was noch vor ihm liegt (evtl. sogar mit ungefährer Zeitangabe für die Bewältigung des restlichen Formulars).

Eine gute Mittellösung ist, wie ich finde, die Aufteilung eines Formulars in mehrere, thematisch sinnvolle Abschnitte. Diese werden jedoch nicht auf mehrere Seiten verstreut, sondern auf einer »Seite« angezeigt. Mittels JavaScript kann immer nur ein Teil sichtbar gemacht werden und die anderen Teile sind z.B. eingeklappt (z.B. mit einem Accordion). So kann sich der Benutzer immer weitere Bereiche erschließen und wird nicht gleich mit dem ganzen, vielleicht etwas unübersichtlichen Formular konfrontiert. Er hat so aber auch die Möglichkeit, sind jederzeit das vollständige Formular anzeigen zu lassen, um den Umfang abschätzen zu können. Und zwar ohne vorher die Pflichtfelder des ersten Bereiches ausgefüllt haben zu müssen (wie es ja häufig bei Wizards der Fall ist). Pflichtangaben oder entscheidende Felder (z.B. umfangreiche Angaben) sollten jedoch nicht versteckt, sondern sofort sichtbar sein.

Diskutiert mit: Wie ist eure Meinung zu mehrseitigen Formularen im Webdesign? Was habt Ihr für Erfahrungen gemacht?