Media Asset Management – celum als Herzstück der Contentverwaltung

Logo celum

Vom 21. bis 23. April fanden erstmals die celum Partnertage im Linzer Hauptquartier statt. Namics war als langjähriger Implementierungspartner vor Ort, um sich die Neuerungen um das neue Lizenzmodell und die Neuerungen in celum Content Server (ehemals Synergy) näherbringen zu lassen. Ebenso … Weiterlesen

Smashing Conference 2013

Die diesjährige Smashing Conference stand ganz unter dem Motto «Personal Experiences». Das Thema war also offener als es gar nicht hätte sein können & die Speakerliste – quasi das Who is Who der Webszene – liess Grosses erhoffen.

Location: Historisches Kaufhaus

Hier mein Versuch, die Konferenz in drei Kernaussagen zusammenzufassen:

  1. Deciding in the Browser
  2. Progressive Enhancement, Progressive Enhancement, Progressive Enhancement
  3. Have fun!

Deciding in the browser

Die Zusammenarbeit zwischen Design & Frontend steht seit Responsive Web Design vor ganz neuen Herausforderungen.

Tools wie Photoshop, InDesign & Co. stehen in der Kritik dem Multi-Device-Web zu wenig Rechnung zu tragen. Dennoch sind sie DAS Tool für Designer, sich kreativ ausdrücken zu können. Das Designen im Browser wiederum benötigt Frontend-KnowHow & bietet zu wenig Platz für Kreativität. Dazwischen gibt es eine ganze Palette von Tools, die den neuen Umständen gerecht werden wollen, oftmals jedoch bloss Zwischenerzeugnisse für die Tonne produzieren.

Die Zeit ist also mehr als reif sich über den sinnvollen Einsatz/Mix von Kreativtools & Frontend Gedanken zu machen. Dan Mall & Jason Santa Maria haben dies getan & teilten ihre Erfahrungen mit uns. Die beiden leidenschaftlichen Webdesigner sind sich einig:

As an industry, we sell websites like paintings. Instead, we should be selling beautiful and easy access to content, agnostic of device, screen size, or context – Dan Mall

Ihr Vorschlag um dies zu erreichen ist so einfach, dass er sich in zwei umgemünzte Zitate packen lässt.

Zitat #1

Current design approach

New design approach

Die Design-Diskussion mit dem Kunden soll also nicht auf Basis von fertig gestalteten, pixelgenauen Designs geführt werden.

Denn was ist mit verschiedenen Screen-Grössen? Vernachlässigbar? Wohl kaum! Ein detail- und pixelgenaues Design verleitet aber dazu, die Design-Diskussion auch auf Level von Detail- und Pixelgenauigkeit zu führen. Dabei wird das Wesentliche – wie fühlt sich die Seite unabhängig von Device & Screen-Grösse an – oftmals ausgeblendet.

Dan Mall schlägt vor, statt dessen als Diskussionsgrundlage Styletiles – oder Visual Inventories o.ä. – zu verwenden.

«The Examiner» Styletiles

«The Examiner» – Projektübersicht

I don’t think we’re in a post-PSD era, but I do think we’re moving towards a post-“full-comp” era – Dan Mall

Anschliessend soll der Prozess in den Browser verlagert werden. Denn nur im Browser kann das Verhalten, die Verhältnisse der Elemente zueinander – unter Berücksichtigung von verschiedenen Screen-Grössen – sinnvoll dargestellt werden. Mit diesem Schritt werden zudem gleichzeitig auch andere Risikofaktoren ausgeschaltet & die Machbarkeit implizit sichergestellt.

Das für mich wichtigste Zitat der ganzen Konferenz folgte postwendend.

Zitat #2

… und wirken lassen …

Der Design-Entscheid soll also in den Browser verlagert werden. Damit hätte man auch gleichzeitig eine wunderschöne Definition of done. Nämlich:

It’s done when it’s done

Progressive Enhancement

Das Konzept von Progressive Enhancement ist so alt, dass man als Frontend Engineer schon fast nicht mehr darüber nachdenkt. Nichtsdestotrotz – oder eben vielleicht gerade deshalb – ist das Thema momentan wieder in aller Munde. Auslöser dafür war Nicolas Zakas Präsentation Enough with the JavaScript Already.

Durch die Verlagerung von Business- und Renderlogik in den Client, steht das bewährte Konzept von Progressive Enhancement erneut auf dem Prüfstand – Client Side Rendering, Model Driven Views etc. vertragen sich nur bedingt mit dem progressiven Gedanken.

Gleich mehrere Speakers – Andy Hume, Ethan Marcotte, Jake Archibald & Jeremy Keith – riefen uns das Konzept – und dessen Bedeutung im neuen Kontext – zurück ins Gedächtnis.

Dabei wurde oftmals der von BBC geprägte Begriff «Cutting the mustard verwendet. «The mustard» ist im Falle von BBC der «Support von HTML5».

  if('querySelector' in document
     && 'localStorage' in window
     && 'addEventListener' in window) {
        // bootstrap the javascript application
  }

Erfüllt ein Browser die Mustard-Kriterien so erhält er die Schöne-Neue-Welt-Version, falls nicht erhält er eine funktionale Core-Version. Die Mustard-Kriterien entscheiden schlussendlich mit über den Grad des «Enhancements».

Its a myth that progressive enhancement means making lowest common denominator designs. Its just about starting there – Jeremy Keith

Eine schöne funktionale Core-Version – die mit sage & schreibe 1 Request auskommt – zeigte Andy Hume am Beispiel der Mobile-Seite von The Guardian. Dieses Extrembeispiel zeigt, dass vor allem im mobilen Kontext – in dem Netzunterbrüche & fehlgeschlagene Requests keine Seltenheit sind – Progressive Enhancement die «gefühlte Verfügbarkeit» einer Seite drastisch verbessern kann.

Have fun!

Web & Spass gehören zusammen. Sei dies bei der Arbeit & natürlich auch überall sonst – auch an der Smashing Conference.

Highlights waren der als Mystery Speaker getarnte Handorgelspieler Klaus Schmidt

… die spontan aus Speakern zusammengewürfelte «Smashing Conference Lonely Hearts Club Band»

… oder das von WordPress grossartig eingehaltene Versprechen

Free Beer All Night Long

Alles in allem war die Smashing Conference bereichernd, bestätigend, trotz Ausnahmen grösstenteils kurzweilig & unterhaltsam, gespickt mit allerlei Würsten vom Markt & inspirierend.

… hoffentlich nächstes Jahr wieder

Weiterführende Links

Progressive Enhancement
That Emil – Progressive Enhancement: Still Not Dead.
Jake Archibald – Progressive enhancement is still important
BBC – Cutting the mustard

Decide in the Browser
Dan Mall – Responsive Design is Hard/Easy! Be Afraid/Don’t Worry!
Brad Frost – The Post-PSD Era … in response … Dan Mall – The Post-PSD Era: A problem of expectations

Terrific – a Frontend Development Framework goes Open Source

terrifically.org

Der Frontend Entwicklungsprozess wird durch die rasante Technologie- und Browserentwicklung immer komplexer. Die stetig steigende Vielzahl von Zielgeräten und Auflösungen, Animationen, CSS3, HTML5 etc. tun ihr Bestes, um die Aufwände und die Komplexität schon während der Konzeptionsphase zu erhöhen. Die unendlichen … Weiterlesen

Clarify – Ein Toolkit für den Frontend Workflow

Der Frontend Entwicklungsprozess in einem Projekt wird immer komplexer und zeitaufwendiger. Aufgrund einer Vielzahl von Zielgeräten und Auflösungen, Verhaltensweisen, Animationen, CSS3, HTML5, etc. steigen zwangsläufig auch die Aufwände und die Komplexität während Konzeptionsphase in allen Disziplinen. Dieser Wandel ist enorm spannend und bietet fast unendliche Möglichkeiten. Es ist aus meiner Sicht aber auch der Moment über die Effizienz im Workflow nachzudenken.

Wir setzen mit Terrific ein fantastisches Werkzeug ein, dass uns ermöglicht modulare und wartbare Frontendbausteine effizient umzusetzen. Es gehört aber nach wie vor zu jedem Projekt dazu, die Spezifikationen zu komplettieren, seien dies nun Vermassungen, Farbcodes, Verhaltensweisen, Geschwindigkeiten von Übergängen, etc. Aber genau diese Erarbeitung kostet Zeit und kann optimiert werden.

Aus diesem Grund ist durch Diskussionen mit Experten aus den Bereichen UX, Design, Projektleitung & Entwicklung innerhalb kurzer Zeit ein Tool entstanden, das einzelne dieser Arbeiten mit kleinen Hilfsmitteln versucht zu unterstützten. Clarify. Es handelt sich dabei um eine Webapplikation mit einer darunterliegenden Datenbank. Nachfolgend gibt es einen Vorgeschmack der Funktionen des aktuellen Prototyps.

Projekte & Screens

Clarify erlaubt das Erfassen von Projekten und das Hochladen von Screens (JPG, PNG) zu jedem Projekt. Es listet diese übersichtlich in der Projektansicht auf. Ein Klick auf einen Screen öffnet die Toolansicht. Sie besteht aus mehreren Layern, u.a. Kommentare, Vermassungen, Farben, Schriften, etc. Initial befindet man sich auf der Kommentaransicht.

Kommentare

Im Kommentarlayer ist es möglich Punkte mit Nummern auf dem Screen zu platzieren und dazu jeweils einen Beschreibungstext zu hinterlegen. Denkbar sind Implementierungshinweise, Infos zu Modulen oder einfach nur Annotationen.

Vermassung

Jeder Frontend Entwickler hat seine Tools um Abstände & Grössen zu vermassen (falls nicht schon bei der Designübergabe vorhanden). So richtig glücklich wurde ich aber noch mit keinem. Nachfolgend sieht man die Vermassungsfunktion von Clarify. Sie zeigt eine Lupe ähnlich wie bei einem Color Picker für den Start- und Endpunkt an. Nachfolgend wird die Breite & Höhe angezeigt. Nachträglich kann die Vermassung angepasst werden. Alle Vermassungen werden in der Datenbank für spätere Outputs wie einem Styleguide gespeichert.

Farben

Das Tool erlaubt Designern und Entwicklern, je nach Workflow, Farben direkt vom Screen zu picken. In Clarify werden die ausgewählten Farben in eine Projektfarbbibliothek hinzugefügt und vom jeweiligen Screen referenziert. Dies erlaubt uns in Zukunft z.B. für ein Projekt automatisiert LESS Templates mit Farben anzulegen. Desweiteren hat man immer den Überblick, welche Farben über das gesamte Projekt hinweg verwendet werden.

Es ist auch möglich eine Farbe anstatt vom Screen zu picken, über die Farbbibliothek auf einen Screen zu ziehen. Dies ist z.B. hilfreich, wenn man im Vorhinein schon weiss, dass dies genau dieses Gelb sein muss, unabhängig davon ob es einen Hauch von jener abweicht.

Embedding

Der Kommentarlayer kann bereits im jetzigen Zustand in andere Systeme per Javascript eingebettet werden. Dies ist hilfreich z.B. in einem Wiki oder im Jira Bugtracking. Man hat dann immer eine aktuelle Version des automatisch skalierten Screens mit den Kommentarpunkten, ohne das man von Hand in Photoshop beginnen muss Punkte zu zeichnen.

Styleguide

Ein möglicher Output von Clarify (dank der strukturiert erfassten Daten) könnte ein Styleguide sein. Hier ein ganz einfaches Beispiel:

Roadmap

Dies ist der heutige Stand des Prototyps, in der nächsten Phase entstehen die Werkzeuge für Verhalten (Dropdown, Slider, etc.) und für Schriften (Zeilenhöhen, Schriftgrössen, px/em). Ich bin gespannt was ihr so darüber denkt, welche Ideen ihr zu dem Thema habt. Last was von euch hören, via Kommentare oder Mail (roger.dudler@namics.com). Mein Ziel ist es Clarify so schnell als möglich zu veröffentlichen und allen zugänglich zu machen. Stay tuned.

Ein ganz besonderer Dank für die spannenden Diskussionen geht an Thommy, Olaf, Daniel, Alex, Remo & Ernst & das gesamte Team Roman!