Ein Streit ist ausgebrochen zwischen den berühmt-berüchtigten Basecamp-Machern 37signals und dem Designer der bekannten Web-Agentur blueflavor.

Streitpunkt: Entwicklung von Ideen mit oder ohne Photoshop

Die Macher einer der erfolgreichsten Web Applikations-Suite mit Basecamp, Campfire, etc. sehen folgende Gründe für das Verwenden von Html und Css im Entwicklungsprozess:

• Keine Interaktionsmöglichkeiten bei einem Photoshop-Mockup (kein Klicken, Navigieren, etc.)
• zu hoher Fokus auf Details
• Text in Photoshop ist nicht der Text, den man im Browser sieht
• Dopplung von Arbeit: Zuerst in Photoshop und dann erneute Umsetzung in html und css
• Photoshop erschwert die Zusammenarbeit, da nicht alle diese Software verwenden und es meist einen Experten gibt

Die Antwort von blueflavor:

• für das visuelle Design ist Photoshop unumgänglich (37signals hat bereits einen etablierten Stil)
• für einfache Web Applikationen ist nicht viel visuelles nötig, für bestimmte (z.B. Corporate Web-Seiten) schon
• Kunden wollen etwas sehen für Geld. Im wahrsten Sinne des Wortes. D.h. visuelle Kommunikation (auch im Detail) spielt eine grosse Rolle

Die richtigen Tools für die richtige Anforderung

Ich denke, dass beide Herangehensweisen etwas wichtiges und richtiges beinhalten. Ein wesentlicher Vorteil der Html und Css-Mockups ist natürlich die Möglichkeit, sie in der Produktion weiterzuverwenden.

Es gibt Bereiche im Design-Prozess, wo der Prototyp mit Html und Css umgesetzt werden sollte. Hierbei geht es vor allen Dingen um strukturelle und funktionale Fragen:

• wo ist der Fokus der Seite?
• wie strukturieren wir unseren Inhalt?
• wo kommt Feature x hin?
• wie funktioniert die Navigation?
• wie ist die globale Seiten-Struktur?

Widerum andere Fragen lassen sich primär in Photoshop lösen. Vor allen Dingen visuelle und Detail-Fragen:

• Welche Farben verwenden wir?
• Hintergründe, Verläufe, Logo
• genaue Positionierung von Elementen zu einander
• Icons, Detail-Elemente
• visueller Gesamteindruck (vor allen Dingen auch für den Kunden=

Weitere Fragen, die man sich beim Herstellen von Prototypen stellen muss:

• Wer ist die Zielgruppe? (Entwickler im Team, Kunde, Pitch)
• Wieviel Zeit hat man? (reicht ein Papier-Mockup oder sollte man eine komplette Seiten-Struktur in html und css erstellen)
• Ermöglicht man anderen konstruktives Feedback? (Lieber in Powerpoint als in Photoshop?)
• Welche Detail-Stufe ist erfordlich? (Komplettes visuelles Layout vs. strukturelle Übersicht)

Am Rande: Video zu Prototyping-Tools

Ein sehr interessantes Video zur Auswahl des richtigen "Arbeitsgerät" zum Erstellen von Mockups und Prototypen gibt es von Jonathan Arnowitz (Google).

Er distanziert sich zum Teil von den Konzepten von Bill Buxton, über den ich vor einer Weile geschrieben habe. Im Wesentlichen vertritt Arnowitz die Meinung, dass Prototyping mit jedem Tool (von Papier und Bleistift über Excel bis hin zu Visio) gemacht werden kann. Die Frage ist jedoch stets nach Effizienz und Anforderung.

In einem sehr umfangreichen Artikel auf SmashingMagazine.com gibt es lange Liste an Tipps und Tricks für Css Entwickler.

Ich kann jedem Web Designer einen Blick darauf empfehlen, vor allen Dingen auf die Hinweise zur Strukturierung und Erstellung von Css-Dateien.

Zwar teile ich nicht alle Ideen, jedoch denke ich, dass es zum Arbeitsprozess eines jeden Html/Css-Web Designers gehören sollte, sich grundlegende Fragen zur Strukturierung der eigenen Css-Dateien zu machen.

Sei es, um die Arbeit damit für Kollegen zu erleichtern; sei es, um noch in 2 Monaten zu wissen, wofür bestimmte Definitionen stehen; sei es, um schneller und effizienter zu arbeiten.

Ich habe einen ausführlichen Beitrag zu meinen Überlegungen zu diesem Thema in der Schublade; er sollte bald fertig sein :)

[So lange könnt ihr euch bei smashingmagazine.com inspirieren lassen]

In einer sehr lesenswerten Einführung in das Thema der Mikroformate für das Markup beschreibt Brian Suda wie diese funktionieren und das Html bedeutungsvoller und somit funktionaler machen.

Was sind Microformats?

Wenn man von der formalen Definition absieht wird man schnell herausfinden, dass Mikroformate eine Art semantische Erweiterung des bestehenden Htmls (und damit der Inhalte) sind, die der Funktion dienen soll, dem jeweiligen Html-Block eine spezielle Bedeutung zu geben.

Im wesentlichen werden Html-Elemente mit bestimmten Klassen-Namen versehen und erhalten somit eine Art Tag, dass den Inhalt des Elements weiter spezifiziert.

Der Clou an der ganzen Geschichte ist, dass nicht irgendwelche Klassen-Namen und somit Microformats verwendet werden, sondern es werden bereits vorhandene, standartisierte Formate verwendet, wie z.B. hCalendar, ein Kalenderformat.

Wofür das Ganze?

Die Idee hinter dem Projekt ist, dass die mit Microformats versehenen Inhalte leichter gefunden werden können. Eine normale Html-Seite ist derzeit noch (in eventuell späteren Html-Versionen soll sich das ja ändern) völlig bedeutungslos. Ein p-Tag ist ein p-Tag ist ein p-Tag. Sollte aber z.B. ein Kalender-Eintrag mit Microformats versehen sein, so weiß man sogleich, um welche Art Inhalt es sich hier handelt, und kann diesen dann z.B. automatisiert anzeigen oder weiterverwenden. So kann aus einem p-Tag z.B. ein Datum werden.

Yahoo, Flickr, Microsoft...

Wenn man sich über die Frage, wie sinnvoll das Projekt ist, hinaus wundert, ob es sich denn um ein zukunftsweisendes und vielversprechendes Projekt handelt, dass eventuell sogar als Standard implementiert werden könnte; so lassen die oben erwähnten Namen eine positive Antwort erahnen. So werden bei Flickr und Upcoming.com Microformats verwendet.

Darüber hinaus melden auch Browser-Hersteller Interesse für Microformats-Funktionalität angemeldet. So könnte man dann automatisch Adressen in das Adress-Buch importieren oder Termine im Google Calendar speichern.

Es gibt sogar schon ein Plug-In bzw. Add-On für den Firefox mit dem Namen Operator, der genau dies ermöglicht.

Weiterführendes:

• Zum oben erwähnten, einführenden Artikel zum Thema Mikroformate (mit Beispielen)
• Zur Homepage des Projekts
• Zum Microformats Cheat Sheet von Brian Suda (Referenz)

Mit der grundlegenden Fragestellung nach dem Design von Verweisen (Links) setzt sich Andy Rutledge auseinander.

Was sind die Anforderungen?

• Text und Verweise müssen leicht unterscheidbar sein
• Verweise sollten auf sich aufmerksam machen
• Das Design der Seite und des Produkts sollte von den Verweisen aufgenommen/unterstützt werden

Was sind die Möglichkeiten?

In seinem Artikel zeigt Rutledge anhand vieler Beispiele mögliche Gestaltungen für Verweise:

• Farbe: Verweise in einer anderen Farbe darstellen
• Dekoration: Unterstreichen, Überstreichen, mit Farbe oder einem Pattern hinterlegen

Die Schwierigkeiten

Ein scheinbar einfaches Thema kann also im Detail doch zum Problem werden.

Rutledge verweist bei der Auswahl von Farben auf die Schwierigkeiten von Menschen mit Farbblindheit. Darüber hinaus setzt er sich anhand einiger inspirierender Beispiele mit der angemessenen Umsetzung des jeweiligen Seiten-Designs und Produkts bei der Gestaltung von Links auseinander.

Kleiner Nachtrag

Eine weitere Möglichkeit, die Rutledge nicht in der Gestaltung für Verweise nicht aufzählt, ist die Verwendung eines anderen Fonts. Durch die Kombination von Farbe, visueller Ausprägung (Unterstrich, etc.) und einer abweichenden Schriftart kann man sicherstellen, dass alle Nutzer den Verweis als solchen identifizieren können.

[Hier gehts zum Artikel auf Design View.]

[via www.yatil.de] Microsoft lenkt in der Diskussion ums Version Targeting ein.

In einem Blog-Post versichert der IE General Manager Hachamovitch, dass der IE8 so Standard-konform sein wird, wie nur möglich und alle Seiten im "Standards Mode" auch im IE8 Standards Mode dargestellt werden. Wenn man seine Seite explizit im IE7 Standards Mode anzeigen lassen will, so kann dies mit der header/meta-tag Lösung geschehen, über die ich vor einigen Tagen geschrieben habe.

Die Community atmet auf und es gibt doch tatsächlich eine Art Vorfreude auf ein Microsoft Browser, was die Unzahl an Kommentaren zu dem IE-Blogpost verdeutlicht.

[Browser Version Targeting Teil I und Teil II.]

In einem Beitrag von vor 2 Tagen habe ich über die angeregte Diskussion über das Browser Version Targeting geschrieben.

Die Idee war es, die Übergänge zwischen Browser-Versionen zu erleichtern, indem jede Seite ein Meta-Tag erhält, das beinhaltet in welchen Versionen die Seite richtig dargestellt wird. Neuere Browser würden die Seite mit der jeweiligen alten Rendering Engine darstellen.

Nun gibt es neue Reaktionen auch aus dem deutsch-sprachigen Raum.

Kritik am Web Standards Project

So befürchtet Jens Grochtdreis den Verfall des Web Standards Projekts (WaSP) in seinem Artikel "Wohin driftet WaSP?" und hätte mehr Widerspruch von der Community erwartet.

Die Gespräche mit Microsoft 

Grochtdreis bezieht sich auf eine Diskussion des WaSP mit Vertretern von Microsoft, die man sich hier als mp3 oder Transkript herunterladen kann.

Die Kritik am Riesen

Keith Jeremy übt in seinem Artikel "They Shoot Browsers" auf A List Apart scharfe Kritik am Browser-Marktführer Microsoft und fragt sich, warum Version Targeting überhaupt nötig sei und Microsoft anstatt dessen nicht einfach einen Standard-kompatiblen Browser (den IE8, z.B.) auf den Markt bringt. Womit sich das Problem von selbst gelöst hätte und für alle Browser nur noch eine html und css Spezifikation nötig sei. Denn Firefox, Opera und Safari sein bereits jetzt Standard kompatibel.

Man darf also gespannt bleiben, was am Ende von Microsoft umgesetzt wird und noch viel mehr, wie die Community den Schritt annehmen wird.

In dem Artikel "Beyond Doctype" auf der Seite von A List Apart (einem der renomiertesten Web-Design Magazine) schlägt Aaron Gustafson eine neue Technik vor, die es Web Entwicklern und Web Browser Herstellern gleichermaßen erleichtern soll, auch in der Zukunft kompatible Seiten zu erstellen bzw. darzustellen.

Der Artikel und die Antwort von Erik Meyer (s.u.) haben in Web Kreisen für viel Aufregung gesorgt.

Der geschichtliche Hintergrund

Die Entwicklung der Browser, der Html Standards und der Css-Spezifikation haben gezeigt, dass es über einen Zeitraum von 10 Jahren durchaus schwierig war, vorwärts-kompatible Seiten zu erstellen. So wurden per Browser Sniffing für spezielle Browser (Netscape, IE, etc.; je nachdem, welche der Nutzer installiert hatte) spezielle Layouts und Css-Dateien geliefert, so dass der jeweilige Browser die Seite im Sinne des Designers darstellen würde.

Das Problem im Übergang vom IE 6 zu 7

Ein Problem, dass mit dem Erscheinen des momentan aktuellen Microsoft Browsers Internet Explorer 7 entstand, war die Tatsache, dass viele Web Designer im IE6 und IE5 auf sogenannte Hacks zurückgreifen mussten, um das Design im nicht immer Standard-kompatiblen Microsoft Browser darstellen zu können.

Da nun der IE7 viele dieser Bugs gelöst hat, mussten viele Designer mit Schmerzen erkennen, dass ihre "alten" Designs für den IE6 und niedriger im IE7 nicht mehr richtig dargestellt wurden. Somit wurde ein meist aufwendiges Redesign nötig. Die Befürchtung ist, dass im Übergang zum IE8 und allen weiteren Browser-Generationen ähnliche Probleme entstehen.

Die Lösung: Browser Targeting

Den Vorschlag, den Gustafson nun macht, um diesen Redesigns und den damit verbundenen "defekten" Seiten vorzubeugen, ist Browser-Versionen direkt anzusprechen. Die Idee ist, in einem Meta-Tag die Version des Browser anzugeben, für die die Seite jeweils entwickelt wurde. Also, zum Beispiel, für den IE7 und Firefox 2.0, etc.

Die Browser-Hersteller würden dieses Meta-Tag auslesen und die Seite so darstellen, wie es ihr jeweiliger Browser "damals" gemacht hätte. Dies würde natürlich bedeuten, dass die Microsofts und Firefoxes ihre Browser enorm aufblähen müssten um auch alle alten Versionen zu integrieren.

Die Antwort des Gurus: Erik Meyer

Eine umfangreiche Reaktion verfasste der in Web-Kreisen bekannte und geschätzte Erik Meyer (vor allen Dingen seine Überlegungen zum Css-Reset sind mittlerweile Standard geworden). Er hat gemischte Gefühle, sieht er doch, dass sich das Web mit dem vorgeschlagenen Weg von einem einheitlichen Standard von Html und Css wegbewegt. Auf der anderen Seite sieht er jedoch auch die pragmatischen Vorteile (Vereinfachung der Entwicklung), die das Browser Targeting mit sich bringen würde.

Auch verweist er in diesem Zusammenhang auf die Rolle der Doctype-Deklaration, die eigentlich die Funktion der korrekten Darstellung übernehmen sollte.

Beides definitiv als Web und Html und Css Designer sehr lesenswerte Artikel, fassen sie doch auch viele der aktuellen und alten Probleme der Branche zusammen.

Die Vielfalt der Möglichkeiten von css-basierten Lösungen für Web Seiten präsentiert das smashing magazine in einem Artikel mit 53 Beispielen aktueller css Techniken.

Wer sich als Web Designer vom Einsatz von css und html als zukunftsweisende Technik überzeugen möchte, hört oft von Web Standards, Accessibility, schnelleren Ladezeiten, einfacherer Bearbeitung und Anpassung. Nach dem man diese inspirierenden Beispiele gesehen hat, wird css als Technik vor allen Dingen durch innovative und funktionale Lösungen überzeugen.

Und eine ungeheure Bandbreite and Anwendungsbereichen. Von Navigationen, über runde Ecken bis hinzu Pop-Up Karten; alles scheint möglich. Wer also das nächste mal einen Kunden überzeugen möchte, doch alte Tabellen-basierte layouts in der Schublade zu belassen, sollte ihn auf diesen Artikel verweisen.