Donnerstag14. März 2013

Dieses Mal ist er drin. Der Beitrag “Design im Browser” in der ScreenGuide Nr. 17 mit meinen Gedanken zu den Gründen für das frühzeitige Versagen der WYSIWYG Webeditoren ala Frontpage,GoLive und Dreamweaver, sowie die Gründe dafür, warum ich mit meinen Projekt Thinkin’ Tags trotzdem einen visuellen Layoutansatz gewählt habe. Angekündigt hatte ich den Beitrag ja bereits im November. Durch einige unglückliche Umstände musste er jedoch verschoben werden und um so mehr freut es mich, dass er nun ab dem 18.3. endlich zu lesen sein wird.

Webentwickler sehen sich in der heutigen Zeit beeindruckenden technischen Möglichkeiten der Browser, aber auch deutlich gestiegenen Erwartungen und Ansprüchen seitens ihrer Kunden gegenüber. Um diese zu meistern, bedarf es der Anpassung der eigenen Arbeitsweise an die veränderte Wirklichkeit. Layout-Dummies in Photoshop mögen als Hochglanzdrucke auf weißem Karton im Rahmen einer Präsentation ob ihrer Perfektion beeindrucken, doch Sie geben uns (oder dem Kunden) keinerlei brauchbares Feedback über das Verhalten des Layouts in verschiedenen Umgebungen. Sie geben uns kein Gefühl über die Rendering-Geschwindigkeit von CSS3 auf Mobilgeräten mit nur mäßig schneller Hardware. Sie täuschen eine Qualität der Kantenglättung von Webfonts vor, die in realen Browsern (man denke nur an die Kombination: Firefox + Windows) nicht einmal ansatzweise erreicht wird. Sie vermitteln uns kein Gefühl für Ladezeiten.

Doch all das sind Fragen, für die nach einer Antwort verlangen und die auf dem klassischen Weg vom Photoshop-basierten Entwurf zur pixelgetreuen HTML-Umsetzung nach Abnahme des finalen Designs erschreckend spät beantwortet werden können. Der Grund dafür ist der Medienbruch in der Entwurfsphase, indem auf Werkzeuge aus dem Printbereich zurückgegriffen wird (Photoshop, InDesign, etc.), um das Design einer Website vom ersten Prototyp bis zum fertigen Design zu gestalten. Fehler in dieser frühen Projektphase bleiben so bis zur Umsetzung (ggf. sogar darüber hinaus) unbemerkt und sind nur unter großem Aufwand zu korrigieren.

Für all diese Probleme erscheint der Browser als Grundlage für die Entwurfserarbeitung eine sinnvolle Alternative. Die Leistungsfähigkeit der JavaScript- und CSS-Engines ist bei der aktuellen Browsergeneration ebenfalls gegeben, sodass ich mich für diesen Weg entschieden habe. Mehr dazu in der aktuellen ScreenGuide.


Sonntag10. März 2013

Seit kurzem kann man sich den aktuellen Entwicklungsstand von Bootstrap 3.0, dem kommenden Major-Release dieses umfangreichen Applikations-Frameworks ansehen. Die größten Neuerungen sind der Mobile-First Ansatz und das überarbeitete Design, welches sich nun stärker von seinen Wurzeln bei Twitter abnabelt.

Die neue Optik betrifft dabei in erster Linie die Formular- und Navigationselemente. Ich persönlich finde sie deutlich weniger elegant, wodurch Bootstrap insbesondere für das Prototyping etwas von seinem Reiz verliert. Denn selbst wenn man sich die Twitter-nahe Optik so langsam satt gesehen hat, so sind die UI Komponenten doch nahezu perfekt aufeinander abgestimmt gewesen und damit erstellte Layout-Prototypen vermittelten einen hochwertigen – jederzeit vorzeigbaren – Eindruck. Diese Qualität von Bootstrap scheint im aktuellen Entwicklungsstadium etwas verloren zu gehen, denn die Entwickler ziehen den neuen Stil nicht konsequent durch. Insbesondere die Formularelemente sehen nun kontrastärmer und irgendwie ... unfertig aus.

Nun ist es so, dass auch ich bei YAML 4 das mitgelieferte Design in neutralem grau halte, weil dies für den Bau von Prototypen eine sinnvolle Ausgangsbasis ist, will man doch den Anwender nicht in Richtung eines bestimmten Farbschema drängen. Steht dann erstmal der eigentliche Layoutentwurf, werden die einzelnen Komponenten im Detail gestaltet. Bootstrap (ehemals Twitter Bootstrap) will sich in Version 3 offenbar weiter von seinen Wurzeln lösen und seine Anwender mit der “unfertigeren” Optik stärkerer zur Individualisierung ... nennen wir’s mal animieren, denn überall wird auch die nun “platte” oder neu-deutsch “flat” Optik auch nicht passen.

Das ist im Sinne der Eigenständigkeit des Frameworks und weniger uniformen “made with Bootstrap” Projekten zu begrüßen. Wenn ich mich recht entsinne arbeiten die beiden Entwickler auch gar nicht mehr bei Twitter. Dennoch war natürlich die ausgereifte Optik der UI Elemente bisher eines der ganz großen Pluspunkte. Die mit Bootstrap erstellten Oberflächen konnte man bisher meist ohne weiteres produktiv einsetzen. Ob das auch mit Version 3 so sein wird, bleibt abzuwarten – noch ist die Version 3 ja nicht fertig (wie man an einigen Komponenten leicht erkennen kann). Ich habe aber so meine Zweifel, ob der neue ... Draft-Look ... gleichermaßen gut angenommen wird. Von einem echten Flat-UI Design mag ich in diesem Zusammenhang eher nicht sprechen, denn dazu sind mir die Umstellungen im Design nicht konsequent genug. Bisher wurden in erster Linie die sanften Gradienten im Hintergrund entfernt und die Standardfarbe der Buttons ist nicht mehr weiß sondern grau. Ein neuer eigenständiger Stil ist das aber noch nicht.

Doch genau das bringt mich zu einem Problem, welches mich seit jeher an Bootstrap stört und welches wohl auch in Version 3 Bestand haben wird. Die Entwickler verzichten auch weiterhin auf eine Trennung von Funktionalität und Design im CSS. Bei YAML gibt es diese Trennung – aus gutem Grund. Die Funktionalität der Layoutbausteine steckt bei YAML in den Core-Dateien des Frameworks, während das Design (Theme) separat verwaltet wird. Dieser Ansatz hat seine Vorteile: Zum einen sind Anpassungen des Layouts bereits durch einfaches Austauschen einzelner CSS-Dateien erledigt (oder Sass-Dateien, so man mit dem Sass-Port von YAML arbeitet). Zum anderen sind Anwender frei in ihrem Workflow – speziell im Hinblick auf den Einsatz von CSS-Preprozessoren. Es ist also möglich, die Core-Dateien von YAML unverändert zu übernehmen, das eigentliche Design aber z.B. mit LESS oder Sass zu erstellen.

Bei Bootstrap gibt es diese Trennung bisher nicht. Zwar ermöglicht das hauseigene Konfigurationstool die Auswahl der Komponenten, ein Austausch des Layouts bedeutet aber immer auch den Austausch der Frameworklogik, weil eben alles miteinander verwoben ist. Das ist besonders dann ärgerlich, wenn man im Rahmen der eigenen Anpassungen vielleicht auch die eine oder andere Erweiterung hat einfließen lassen. Wer die Optik individualisieren will, ist so zwingend auf LESS angewiesen, unabhängig von den ggf. bestehenden Abhängigkeiten des eigenen Projektes.

Trotzdem ist es natürlich spannend zuzusehen, wohin die Entwicklung bei Bootstrap, Foundation & Co. geht. Schließlich macht man sich ja auch so seine Gedanken fürs eigene Framework.


Samstag09. März 2013

Thinkin’ Tags ist zweifellos komplex. Um sie jedoch sinnvoll einsetzen zu können, muss man die Funktionsweise zunächst einmal verstehen. Bisher ging das nur mit Fleiß und ausreichend Forschergeist. Während der letzten Wochen habe ich nun jedoch zahlreiche Screencasts für Thinkin’ Tags aufgenommen, welche Funktionsweise aller Kernbestandteile der Applikation ausführlich erklären. Ab sofort stehen sie auf dem neuen Youtube-Kanal von Thinkin’ Tags zur Verfügung.

Die Screencasts stehen sowohl in Deutsch als auch in Englisch zur Verfügung, wobei die deutschsprachige Playlist der Videodocs bereits 8 Screencasts umfasst, während die englische Playlist momentan erst 5 Videos enthält. Ich bin im Moment noch mit den Übersetzungsarbeiten beschäftigt und werde die die weiteren Screencasts dann Stück für Stück hochladen und freischalten.

Ach ja: Wer genau hinschaut, wird zu Beginn des ersten Screencasts ein leicht überarbeitete Startseite von Thinkin’ Tags erkennen, sowie ein “Request Invite” Formular. Das kommt nicht ganz von ungefähr, denn in Kürze möchte ich die Zahl der aktiven Nutzeraccounts deutlich erhöhen.


Seite 1 von 1 Seiten