Artikeltipp: Basiskoffer für Web-Projekte

basiskoffer

Einen wirklich guten Artikel darüber, was man grundlegenden bei den Meilensteine eines Web-Projekts zu beachten hat, hat neulich Achim Schaffrinna in seinem aktuell für den Grimme Online Award nominierten Design Tagebuch veröffentlicht.

Er verdeutlicht seine Aussagen anhand des Koffer-Packens für eine Reise. Dabei steht das Schuhwerk für den Aufbau der Website, die Sonnenbrille für das Corporate Design, die fein säuberlich eingepackte Oberbekleidung für Hierarchien, Klassen und Abstände, das Taschenmesser für die Usability und das Navigationskonzept wird abschließend von mobilen Navigationsgerät repräsentiert.

Doch wie Achim diese dinglichen Aufhänger in einen gut herausgearbeiteten Kontext mit diesen Bausteinen eines Web-Projekts in Einklang bringt, lest ihr am Besten bei ihm selbst … im Artikel Basiskoffer für die Reise durchs Netz.

Böse, coole, kurze URLs

shortenerurls

Sind verkürzte URLs (zum Beispiel tinyurl.com oder bit.ly) ein Problem? Stimmt die Behauptung von Joshua Schachter

shorteners are bad for the ecosystem as a whole

Neben Joshua Schachter haben auch Oliver Wagner und Erick Schonefeld sich aktuell mit dieser Frage beschäftigt. In ihren Beiträgen beleuchten sie das Nutzen von verkürzten URLs und die damit verbundenen Gegebenheiten und Gefahren. Es wird beispielsweise die Frage aufgeworfen, was mit verkürzten URLs eines Dienstes passiert, sollte dieser nicht erreichbar sein. Weil die Server aktuell nicht verfügbar sind, weil der Dienst pleite gegangen ist, weil er gehackt wurde,… Außerdem wird auf die Hürden hingewiesen, die sich für den User durch verkürzte URLs ergeben. Der User kann nicht erkennen, wohin diese zeigen. Er kann sich lediglich auf sein Vertrauen zu dem Poster oder den Kontext verlassen, in dem die verkürzte URL gepostet wurde.

Als ein Lösungsansatz wird vorgeschlagen, dass sich Website-Betreiber selbst um kurze, sprechende URLs bemühen sollten, wie es bei einigen Anbietern, wie zum Beispiel Brightkite auch schon der Fall ist. Ist dies nicht möglich, wie beispielsweise bei Karten-Anwendungen, die auf bestimmte Parameter in der URL nicht verzichten können, dann könnten Website-eigene Verkürzungsmechanismen Abhilfe schaffen. Da besonders twitter zum Erfolg der verkürzten URLs beigetragen hat, sollte auch dieser Dienst eine Alternative anbieten. Denkbar wäre hier laut Schonefeld die Möglichkeit, Worte mit Links zu versehen.

An dieser Stelle wurden nur kurz einige der Gedanken von Joshua Schachter, Oliver Wagner und Erick Schonefeld aufgegriffen. Neben deren ausführlicheren Beiträgen ist auch die Umfrage von TechCrunch zum Thema (siehe Keyvisual) sehr interessant. Im Moment sind 58% der TechCrunch-Leser der Meinung, dass verkürzte URLs eine Gefahr darstellen.

Browser-Performance: JavaScript vs. HTML

html_vs_js

Gestern bin ich auf AjaxLine.com auf einen interessanten Artikel gestoßen, der sich mit der Performance von Browsern bezüglich JavaScript befasst. Wie der Titel “The Browsers Performance in Dependence of HTML Coding” schon sagt, ist dieser Artikel kein weiterer reiner Vergleich der JavaScript-Engines verschiedener Browser. Vielmehr beschäftigt er sich damit, wie performant Browser JavaScript in Abhängigkeit vom zu rendernden HTML-Code ausführen.

Der Autor, Sergey Chikuyonok (Blog), hat verschiedene HTML-Konstrukte in folgenden Browsern getestet: IE6, IE7, IE8b2, FF2, FF3, FF3.1a, Opera 9.62, Chrome 0.3, Safari 3.1.2, FF3 (Mac), FF3.1a (Mac), Safari 3.1.2 (Mac), Opera 9.6.1 (Mac), WebKit r37790 (Mac).
Es wurde beispielsweise überprüft, ob absolute oder relative Positionierung von Elementen performanter ist, oder wie sich die Anzahl der DOM-Elemente auf die Browser-Performance auswirkt. Die Ergebnisse der einzelnen Test sind jeweils grafisch aufbereitet dargestellt. Aus besonders eindeutigen Ergebnissen formuliert Chikuyonok außerdem klare Handlungsanweisungen.
Am Ende des Artikels befindet sich ein Resümee, in dem folgende Maßnahmen zur Verbesserung der Browser-Performance vorgeschlagen werden:

  • interaktive Elemente sollten absolut positioniert werden
  • interaktive Elemente sollten bereits von Anfang an bedacht und eingeplant und nicht nachträglich eingefügt werden
  • zu viele Elemente auf einer Seite können sich negativ auf die Performance auswirken
  • gleiches gilt für zu tiefes Verschachteln von Elementen
  • das Verwenden von <img />-Elementen ist performanter als das Einsetzen des Background-Image-Attributs
  • Bilder sollten nicht vom Browser skaliert werden

Die getesteten HTML-Konstrukte sind typisch für Szenarien, in denen DOM-Manipulation über JavaScript stattfindet. Doch das Befolgen einiger der vorgeschlagenen Maßnahmen – wie beispielsweise der Verzicht auf Skalierung von Bildern über den Browser – ist sicher auch ratsam, wenn kein JavaScript zum Einsatz kommt.

via spic

Infrastruktur für die Web-Entwicklung am Mac

mamp_vhx

Macs sind was für Kreative und nichts für richtige Entwickler. Dieses Dogma hält sich erstaunlich hartnäckig. Dass es aber auch möglich ist, am Mac Websites zu entwickeln, beschreibt Gerrit van Aaken in seinem praegnanz-Blog.

Wie Gerrit beschreibt, liefern zwei kostenfreie Tools die Grundlagen dafür: die Server-Infrastruktur MAMP und VirtualHostX. Das weitere Warum, Weshalb und Wie gibt es bei Gerrit im Beitrag MAMP und VirtualHostX.

XML als Basis für mehrsprachige Webprojekte

international

Auch wenn es aus Aufwandsgründen gerne mal unter den Tisch fällt, das erste W in WWW steht für weltweit. Somit müsste es nicht nur zum guten Ton gehören, sondern eigentlich der Normalfall sein, dass Webprojekte mehrsprachig umgesetzt werden. Soviel zur Theorie.

In der Praxis sind es dann oft finanzielle Gründe oder auch die Zielgruppen-Definition, weshalb ein Webprojekt nur in der Heimatsprache der Betreiber oder wenn international gedacht wird, nur in Englisch umgesetzt wird. Dabei gibt es inzwischen gute Methoden, die die Internationalisierung eines Webprojekts unterstützen, wie etwa gettext auf dem auch die Mehrsprachigkeit von WordPress basiert.

In diesem Kontext habe ich vorhin einen interessanten Artikel auf drweb.de gelesen. Björn Kaiser beschreibt in seinem Beitrag PHP: Lokalisierung auf Basis von XML wie und warum er eine solche internationale Umsetzung eines Webprojekts lieber auf Basis der Datenaustauschformats XML macht. Sehr lesenswert …

Netzlogbuch läuft nun auf WordPress 2.7

nlb_wp27

Wir haben es getan! Auch das Netzlogbuch läuft nun auf WordPress 2.7. Und ich bin erst einmal sehr zufrieden.

Das Backend sieht nun viel besser aus … irgendwie zweinullig. Es wirkt auch aufgeräumter. Die Navigation ist nun nicht mehr horizontal angeordnet, sondern wieder klassisch links in einer Spalte. Und wer mehr Platz in der Inhaltsspalte braucht, kann die Navigation auch noch minimieren.

Auch schön: Trotz installiertem FlashPlayer10, der den komfortablen Upload von Bildern in der 2.6er Version verhinderte, kann man jetzt wieder ganz fix Bilder hochladen. Auch zwei weitere Punkte, die mich beim Bild-Upload gestört haben, sind nun geändert: Standardmäßig ist nun keine Link-URL vorausgefüllt und das Bild in der vollen Größe einbinden ist nun vorausgewählt. Nur Kleinigkeiten, aber sie ersparen mir bei jedem Artikel mindestens zwei überflüssige Klick.

Ansonsten sind es viele kleine Details die mir aufgefallen sind. Etwa die “Direkt bloggen”-Funktion unter Werkzeuge oder das beim Tippen kontinuierlich die Anzahl der geschrieben Wörter mit gezählt wird.

Auch nötigt es mir schon eine gehörige Portion Respekt ab, wenn ich so sehe wie einfach ein Versionsupdate … auch von einer solchen Tragweite … bei WordPress abläuft. Paket runterladen, bis auf den Ordner “wp-content” alles im betreffenden Verzeichnis auf dem Webserver überschreiben, im Backend einloggen und per Klick die Datenbank aktualisieren lassen. Fertig!

Ich bin zufrieden.

Was zum Teufel ist User Experience?

Mein Telefon braucht nicht schön zu sein oder so. Man muss damit Telefonieren können … Punkt aus! –– Okay, dann können wir ihr jetziges Gerät ja gegen ein baugleiches mit einem rosa Plüsch-Bezug austauschen. –– Sind sie verrückt! Sowas kommt mir nicht ins Haus!

Dieses fiktive Gespräch habe ich so ähnlich mal auf einer Veranstaltung zum Thema Usability in einem Vortrag über User Experience (UX) gehört. Es ist etwas überspitzt formuliert, da es als Anekdote eine Art “Hallo-Wach!”-Effekt bei den Zuhörern haben sollte. Aber es zeigt schon mal, dass UX nicht mit einem hübschen Design gleichzusetzen ist.

Hinter UX steht ein breiter interdisziplinärer Ansatz. Wenn eine Website als Beispiel optisch gefällt, dann ist das der UX erst einmal nicht abträglich. Aber das Bemühen um eine optisch ansprechende Website kann wiederum der Usability abträglich sein. Wenn etwa durch ein in der CI festgeschriebenes Gestaltungsraster inhaltlich zusammenhängenden Elementen nicht zusammen dargestellt werden können, dann kann dies die Gebrauchstauglichkeit, aber auch die Gebrauchsfreude einschränken, weil man dadurch einfach nicht zu Potte kommt. Und wenn auf der anderen Seite eine gut bedienbare Website die Augen quält, dann macht deren Nutzung auch kein Spaß.

UX steht also sowohl mit der Usability wie auch mit der Gestaltung in einem direkten Zusammenhang. Aber auch solche Aspekte, wie die Reaktionszeit beim Seitenaufbau, der angemessene Einsatz von multimedialen Elementen und natürlich auch von Werbeelementen stehen in einem Kontext mit der UX.

Im Kern geht es bei der UX im Web-Bereich um eine gute … ein besseres bzw. wertfreieres Wort fällt mir dazu nicht ein … also um eine gute Gestaltung von User Interfaces. Denn nichts anderes sind moderne Webseiten in der Regel. Aber “gut” ist hier auch im Sinne von zielführend und dem Nutzer einen Mehrwert bietend gemeint. Denn der oft im der UX in Verbindung gebrachte “Joy of Use” sollte nicht unbedingt als Spaß an der Nutzung missverstanden werden. Es kann auch sehr befriedigend sein, wenn man einfach nur schnell an eine gesuchte Information kommt.

Wie schlecht sich die UX in ein Bewertungsraster pressen lässt, zeigt auch ein schöner Spruch, der im Bezug darauf die Runde macht:

Listen to your users, but ignore what they say.

Heißt: Deine Nutzer werden dir nicht sagen können, was sie im Bezug auf deine Website von dir erwarten, aber wenn du aufmerksam bist, wirst du es schnell herausfinden können.

Facelift des Google Readers

Wieder mal still und ohne großes Tamm-Tamm hat Google mit seinem Reader eine seiner zentralen Web-Dienste optisch verändert, ein wenig aufgeräumt und damit den Funktionserweiterungen Rechnung getragen, die sie in letzter Zeit vorgenommen hatten.

Noch weiß ich nicht genau, was ich davon halten soll, aber da ich damit ja tagtäglich meine RSS-Feeds lese, werde ich es bald raus gefunden haben.

Drawter – Wireframes direkt zu Code machen

Ich bin mir noch nicht ganz sicher, ob das Web-Tool Drawster im produktiven Einsatz wirklich funktioniert. Aber im Prinzip geht es schon in die richtige Richtung. Damit kann man nämlich den Grundaufbau einer Webseite online zusammenschieben, die Elemente mit CSS versehen und sich dann den Quellcode ausgeben lassen.

Ich habe mal ein bisschen damit rumgespielt, wodurch ich jetzt noch nicht zu einer abschließende Wertung kommen kann, aber so richtig überzeugt hat mich Drawster noch nicht. Aber es gehört ja schließlich auch nicht zu meinen Aufgaben Web-Code zu erzeugen.

Was ich an Drawster jedoch spannend finde: Man merkt überhaupt nicht mehr, dass man es hier mit einer Online-Anwendung zu tun hat. Es fühlt sich an, als wenn man eine Desktop-Anwendung bedienen würde. Vor ein bis zwei Jahre hätte mich das noch vom Hocker gehauen. Heute sieht man sowas zugegebenermaßen aber schon ziemlich oft.

Via web2null

Web2.0 – Startpunkt der Differenzierung

In den vergangenen Tagen haben wir in der Agentur mal wieder über den Begriff Web2.0 diskutiert bzw. über das, was auf das Web2.0 folgen mag. Der Auslöser war ein Paper, welches den Begriff Web3.0 enthielt. Die Diskussion war durchaus interessant und lies mich mit der Erkenntnis zurück, dass es sowas wie das Web3.0 niemals wirklich geben wird.

Die hinter dieser Erkenntnis liegende Argumentation basiert darauf, dass es sich bei dem Web2.0 vor allem um eine Änderung der Wahrnehmung des Webs handelt. Das Web2.0 ist meiner Ansicht nach der Startpunkt der Differenzierung dessen, was Tim Berners-Lee ursprünglich mal als das World Wide Web bezeichnet hat. Das Web in den Kinderschuhen war an sich ja auch noch als ein Ganzes wahrzunehmen. Seit einiger Zeit ist das nicht ohne weiteres mehr möglich.

Spricht man mit Vertretern den verschiedenen Nutzer- bzw. Interessengruppen über das Web2.0 so bekommt man die unterschiedlichsten Schagworte aufgetischt, wie etwa:

  • User: Facebook, Wikipedia, RSS, …
  • Entwickler: Ajax, Rich Internet Application, …
  • Marketing: Grassroot-, Viral-Marketing, …
  • Grafiker: Glitter, Glossy, Verläufe, …
  • Konzepter: User Experience, Social Media, …

Diese Auflistung ließe sich fast beliebig erweitern und vertiefen. Aber sie zeigt uns auch schon so, dass es ein Web3.0 nicht geben kann. Jeder dieser und auch der fehlenden Punkte wird sich auf eine eigene Art und Weise weiterentwickeln … oder auch nicht. Wir kennen solche Entwicklungen von vielen technologischen Entwicklungen. So gab es z.B. am Anfang ein bzw. das Automobil. Inzwischen unterscheidet man auf unterschiedlichste Art und Weise … Limousine, Cabrio, SUV, Transporter, LKW, und so weiter und so fort.

Somit bin ich der Ansicht, dass der Begriff Web3.0 maximal aus einem der unterschiedlichen Verzweigungen des Webs kommen kann … dem Marketing.


Das Foto oben stammt übrigens von *Gräfin und ich hab es bei photocase heruntergeladen.

schließen