Heute gings zum Drupal Design Camp¹⁾. Ich bin normalerweise Backend Developer, doch der Theming Teil der Konferenz hat mich neugierig gemacht - es standen eine Vielzahl von interesannten Sessions auf dem Programm.

Bis zur Lunch break standen „Theming API“, „Theme like a Rockstar“ und „Face your Fears – Aegis“ auf dem Plan. Gleich mit einem, im Verhältnis zu anderen Sessions, recht technischem wie „Theming API“ zu beginnen war vielleicht nicht sogut denn es lief ein bisschen zäh, die Ausführungen waren durchaus korrekt aber dennoch irgendwie schwer zu folgen.

Dafür fand ich „Theme like a Rockstar“ wesentlich besser. Allgemein muss man dazu sagen, ich bin eher der Drupal Backend Developer, da wir allerdings auch oft Designs umsetzen müssen – bin ich zwangsläufig auch „Themer“ jedoch kein Designer. Letzteres lastete mir wohl bei „Theme like a Rockstar“ an denn einige präsentierte Konzepte ergaben sich mir nicht so recht. Nichtsdestotrotz spannend, den Theme Vorgang mal aus Augen eines Vollblut Designers zu sehen.

Die Session „Face your Fears – Aegis“, welche über das Drupal Hosting System und Drush ging war ebenfalls recht interesannt. Aegis ist vor allem für Hoster interesannt, die viele verschiedene Drupal Systeme zentral steuern können müssen. Drush wiederum ist ein Kommandozeilen Tool für Drupal, mit dem man viele Erleichterungen bei der Entwicklung hat z.B. kann man damit in Einzeilern Module runterladen, installieren und aktivieren oder auch ganze Drupal Installationen auf Basis eines Profils erstellen, wobei alle nötigen Dateien automatisch runtergeladen und eingerichtet werden.

Nach der Mittagspause ging es mit einer Vorstellung der „Drupal 8 Design Initiative“ weiter. Diese hatte zum Ziel, mehr Designer zu Drupal zu bringen. Es wurde ausgeführt, dass Drupal eine hohe Einstiegshürde besitze und im momentanem System zu wenig Anerkennung und Anreize für Designer hat. Vorgestellt wurde ebenfalls der Lösungsansatz dieser Probleme aus Sicht der Drupal 8 Design Initaitve. Das System beinhaltet unter anderem „Design Challenges“ wobei sich Designer messen können, ein System um eigene Designs zu diskutieren, Anregungen und auch Lob zu bekommen, sowie eine Möglichkeit seine Designs hochzuladen und zu zeigen. Eines der, wie ich finde, großen Probleme, dass auch finanzielle Anreize geschaffen werden müssen um Drupal attraktiver für nicht so technik affine Entwickler oder Projektleiter zu machen wurde, soweit mir ersichtlich, nicht aufgegriffen.

Danach wurde dem „Render Array“ von Drupal eine gesamte Session gewidmet. In „The Scary Render API“ ging es um die Möglichkeiten mit dem Render Array die Seite zu manipulieren. Der große Vorteil an dem Render Array in Drupal 7 ist, dass man sich zum Zeitpunkt bevor die ganze Seite gerendert wird, einhaken kann und dadurch die Möglichkeit bekommt, die Seite Regionen übergreifend zu manipulieren. Das ist ganz interesannt, weil man sonst eigentlich fast immer im Kontext einer bestimmten Region arbeitet, z.B. manipuliert man den Content indem man eine Node anpasst, die Navigation indem man das Menu anpasst oder auch Stellen dazwischen wie die Breadcrumb.

„Working with Grids using 960“ stand danach ursprünglich auf dem Plan, glücklicherweise gab es eine Woche vor der Konferenz eine Planänderung, welche nicht auf der Webseite oder der gedruckten Version des Programmes übernommen worden ist. Glück deswegen, weil mich die Session über die CSS Methode rein überhaupt nicht interessierte. Stattdessen kam eine Session die für mich eines der Highlights heute war: „Vertical Hierarchy Design“, welches um Design Theorie und Wahrnehmung im Kontext des „Vertical Hierarchy“ Prinzipes ging. Dabei wurde versucht von der klassischen „Gestalt“ Lehre abzugrenzen jedoch auch eingeräumt, dass es viele Überschneidungen gibt. Es wurde auf viele Prinzipien eingegangen wie z.B. Proximity, Unity oder Color aber auch auf Wechselwirkungen und, dass unter Umständen für unsere Wahrnehmung einige Prinzipien stärker wirken als das andere. Ein Beispiel z.B. war eine Liste von Elementen, wo es visuell noch „Unterlisten“ gab, also eingerückte Listen. Wenn man jetzt Farbe dazugibt und z.B. einige Listenelemente Rot färbt und andere grau lässt, dann ergibt sich eine ganz andere Wahrnehmung der Zusammenhänge.

Abgeschlossen hat den Tag „Sherlock Markup und Sammy Semantic“ wo unter die Lupe genommen wurde, woher Drupals Markup, welches wir aus der „Theming API“ und „Render API“ bekommen überhaupt kommt und gegenüber gestellt, welche Methoden man hat, wenn man an ein Theming Problem angehen oder auch debuggen muss.

Morgen gehts weiter mit Tag #2