eparo – Digital Service Design

Das Blog von eparo.de

22. Mai, 2017

Therapeutisches Videospiel „Memore“ in der Produktreiferei

Wir waren selbst neugierig und haben Memore ausprobiert :-)

Wir waren selbst neugierig und haben Memore ausprobiert.

In der Produktreiferei testen wir innovative Startup-Produkte. Diesmal haben wir die therapeutische Videospielkonsole MemoreBox mit drei 70+ Probanden über drei Stunden getestet und spannende User Insights gesammelt!

Gaming mal anders!

Am 11. Mai haben wir die therapeutische Videospielkonsole MemoreBox getestet. Memore wird vom Social Startup RetroBrain entwickelt und wurde speziell für Senioren konzipiert. Über die gestenbasierte Steuerung mit einer Microsoft Kinect werden am TV mit verschiedenen Spielen Gleichgewichtssinn und Beweglichkeit trainiert – das mussten wir unbedingt testen! Also haben wir drei Nutzer im Alter von 70+ eingeladen, vor einen großen Fernseher gestellt und dann einfach mal geschaut, was passiert. Fazit: Unsere Probanden haben sich generell gut in den einzelnen Spielen zurechtgefunden. Bei der Navigation durch das Menü haperte es an einigen Stellen, aber der Spaßfaktor stimmte auf jeden Fall! Können wir auch so bestätigen. Wir waren selbst neugierig und haben Memore ausprobiert :-)

Testbeobachtung

Trotz des guten Wetters am Testtag kamen zahlreiche Produktreifer zur Testbeobachtung. Während wir den Probanden beim Spielen von Memore zuschauten, hielten wir die beobachteten Reaktionen und Probleme direkt auf Post-Its fest.

Nach jedem Test wurden die zahlreichen Notizen auf unserer über 20m² großen Whiteboardwand gesammelt. So füllte sich der Raum schnell mit vielen bunten Post-Ist. Testauswertung

Nach den Nutzertests haben wir die Post-Its gemeinsam sortiert und zu Clustern zusammengefasst. So zeigte sich schnell, an welchen Stellen es Nutzungsprobleme gab. Zusammen mit RetroBrain haben wir mögliche Optimierungsansätze für das Interface und die Gestensteuerung erarbeitet und diskutiert und den Abend dann gemütlich bei einem Bierchen ausklingen lassen. Unser Learning: Gesten, bei denen der Nutzer die Arme oder Beine heben muss, sind vollkommen neu und ungewohnt. In diesem Feld Interaktionen zu gestalten ist echt nicht so einfach. ;-)

PostIts

Was tun wir in der Produktreiferei?

Startup-Produkte aller Art werden in der Produktreiferei mit der Nutzerzielgruppe auf ihre User Experience und Usability getestet. Zu jedem Termin gibt es von uns ein kostenfreies Mini-UX-Testing für ein Startup. Über unser Meetup laden wir euch zum Mitmachen ein. Ihr könnt die Nutzertests gemeinsam mit uns beobachten, lernen, wie UX-Tests funktionieren und dabei helfen, die Produktideen zu verbessern. Genaueres könnt ihr hier nachlesen.

Du hast eine Produkt-Idee, die getestet werden soll? Schreib uns: https://www.eparo.de/produktreiferei

 
21. März, 2016

NUMBER26 – Das Positiv-Beispiel für Banken?

number26-verifikation

Wie wird die Bank der Zukunft aussehen? Schon 2013 haben wir Prof. Dr. Jürgen Moormann in einem Interview gefragt und mögliche Gründe für die fehlende Modernisierung von Banking Services erfahren.

Diesmal schauen wir von der anderen Seite und haben dafür eine Bank ausgesucht, die bereits mit ihrem Konzept sich von anderen Banken unterscheidet. Ziel von NUMBER26 ist nämlich kein geringeres, als die Bank für die Hosentasche zu sein – von der Kontoeröffnung über die Überweisung bis hin zur Kartensperrung. Und der Erfolg gibt NUMBER26 recht: schon nach einem Jahr zählt die Bank mehr als 100.000 Kunden.

Aber wir wollten es genau wissen: Wie hat das Team bei NUMBER26 zusammen gearbeitet? Wie war der Entwicklungsprozess? Und wie wurden die rechtlichen Hürden, die eine Bank zu erfüllen hat, gelöst? Diese und weitere Fragen haben wir Helena Treck von NUMBER26 gefragt.

eparo: Wie verlief euer Konzeptionsprozess?

NUMBER26: Vor allem Valentin hatte bereits Erfahrung im FinTech Bereich durch seine Zeit bei Payleven und Paymills. Wir haben beobachtet, dass es in verschiedenen B2B Nischenbereichen Innovation im FinTech Bereich gab, der B2C Bereich in Deutschland noch ausschließlich von traditionellen Banken bedient wurde. Also haben wir uns an das Herzstück von Banking gewagt: Das Girokonto.

eparo: Und wie seid ihr vorgegangen? Womit habt ihr begonnen?

NUMBER26: Wir haben uns jeden Schritt im Banking einzeln angeschaut und hinterfragt ob das so nötig ist und wie man es besser gestalten kann. Muss man für die Konteröffnung in die Filiale? Nein. Muss eine Kartensperrung übers Telefon laufen? Nein. Und muss sie final sein? Nein. Muss die Karte in einem Brief geschickt werden? Nein. Sobald die Parameter abgesteckt waren, konnten wir kreativ werden. Und so sind wir zu dem Produkt gekommen das unsere Nutzer nun lieben. Wir entwickeln es immer weiter.

eparo: Ihr habt ja sicher nicht von Null auf angefangen. Was waren die wichtigsten Aspekte für euch beim Product Discovery Prozess?

NUMBER26: Erst hatten wir ein Konto für Jugendliche entwickelt, bekamen dann aber das Feedback von Freunden und Kunden, dass so ein Konto auch für eine größere Zielgruppe interessant ist. Nach Probleminterviews zum Thema Banking mit 100 Testpersonen und intensiven Feedbackloops haben wir den Prototyp gebaut. Bestätigt durch die größere Nachfrage in den Testfamilien war klar, dass wir NUMBER26 – wie es heute ist – umsetzen werden: Ein Girokonto für jeden, der transparentes Banking sucht. In die offene Phase sind wir nach einer internen Betatestphase übergegangen. Bei allen Schritten steht bei uns immer die User Experience bzw. Usability und Weiterentwicklung des Produkts im Vordergrund.

eparo: Das PostIdent-Verfahren ist nach unserer Erfahrung eine der größten Hürden für Neukunden von Banken und Versicherungen. Wie habt ihr es hinbekommen, das lästige PostIdent-Verfahren durch so etwas simples wie Video Chat zu ersetzen? Was habt ihr anders gemacht, als die größeren Banken?

NUMBER26: Wir arbeiten mit IDnow für die Identifizierung zusammen. Sie sind auch ein junges Startup, deswegen konnten wir ihre Services so schnell bei uns integrieren. Mittlerweile haben zwar auch traditionelle Banken dieses System integriert, allerdings ist es nicht so elegant und natively in deren Sign-up Prozesse eingebunden.

eparo: Das kann ja auch rechtlich schnell in die Hose gehen. Wie hart habt ihr gekämpft, um auch einen rechtlich-sauberen Service bieten zu können?

NUMBER26: Die Vereinbarung mit unserer Partnerbank Wirecard beinhaltet, dass sie sich um die regulatorischen Themen im Hintergrund kümmert, während wir für die Customer Experience verantwortlich sind. Wenn man seine Kunden und die zugrunde liegende Sicherheitsansprüche gut kennt, ist es mit Kreativität möglich auch in diesem strengen Rahmen die User-Experience zu verbessern.

eparo: Bei der Entwicklung einer neuen Bank ist Teamwork auf Augenhöhe gefragt – und sicher nicht immer einfach. Wie habt ihr im Team zusammen gearbeitet? Was für Abläufe hattet ihr?

NUMBER26: In der ersten Testphase bis zum Launch hat unser kleines Team von rund 10 Leuten sehr nah am Produkt gearbeitet. Schon damals haben wir sehr dynamisch gearbeitet, wobei sich jeder individuell mit eingebracht hat. Nach dem Launch stellten wir unsere ohnehin agilen Methoden komplett auf Scrum um und Design- sowie Quality Assurance fest in unsere Sprints integriert. Als das Team um das Produkt herum gewachsen haben wir unsere Strukturen und Abläufe natürlich nach und nach ausgebaut. Mittlerweile haben wir natürlich auch Marketing-, Customer Service- und Operationsteams, die nicht direkt am Produkt arbeiten, und hervorragend als Betatestgruppe fungieren.

eparo: Wie sieht dabei eure Unternehmenskultur aus? Gibt es eine stark-hierarchische Struktur oder ist es vielmehr wie in einem Startup mit flacher Hierarchie?

NUMBER26: Unsere Strukturen sind immer noch sehr flach. Jeder, der Ideen hat kann und soll sich mit einbringen und die Initiative ergreifen.

eparo: Glaubt ihr, dass eure Unternehmensgröße und eure Unternehmenskultur mit dem Endergebnis zusammenhängt? Wäre das auch in einer der großen Banken möglich gewesen?

NUMBER26: Auf jeden Fall gibt es da eine starke Wechselwirkung. Zum Einen haben wir schlanke Strukturen ohne Filialen und können ohne einen administrativen, über Jahre gewachsenen Overhead sehr effizient arbeiten. Zum Anderen haben wir ein herausragendes Team, mit sehr talentierten und überdurchschnittlich motivierten Mitarbeitern. Wir glauben hier alle an unsere Vision und scheuen uns nicht davor Dinge einfach auszuprobieren. Da müssen große Banken an viel mehr Fronten kämpfen als wir.

 
16. Juli, 2015

AXChange Hamburg bei eparo – erstes Axure-Meetup Deutschlands

AXChange Hamburg

Am 10. Juni haben wir bei eparo das erste Axure-Meetup “AXChange Hamburg” Deutschlands organisiert. Mit Unterstützung von Axure aus Kalifornien. Das Ziel: Interessierte und Axure-Fu-Master treffen sich jeden zweiten Mittwoch eines Monats zum lockeren Austausch über das Prototyping mit Axure. Schwerpunktthema des ersten Treffens: „Design-robuste Prototypen und die Auslagerung von Interaktionen in Funktionen“. Christian berichtet.

Die Sache mit der Nachfrage und dem Angebot

„Warum gibt es eigentlich noch kein Treffen von Axure-Interessierten und Fu-Mastern?“ Diese Frage haben wir uns in den vergangenen Jahren oft gestellt. Auch immer mehr Teilnehmer unserer Axure-Kurse (https://eparo.de/training.html) schickten ihre Fragen an eparo. Der Bedarf, sich auszutauschen, wurde offenbar immer größer. Im Mai gründeten wir die Meetup-Gruppe und bis zum ersten Meetup hatten sich mehr als 40 Axuristas angemeldet.

Für das Axure Meetup haben wir uns eine gute Mischung aus allem gewünscht: Austausch, „Lernen von …“ und Hilfestellungen bei konkreten Problemen. Außerdem wollten wir (oder auch andere Teilnehmer) ein Schwerpunktthema vorbereiten. So entstand das AXChange Hamburg Meetup, das jeden zweiten Mittwoch eines Monats stattfindet.
Die Meetup-Gruppe ist hier zu finden: http://www.meetup.com/de/AXChange-Hamburg/

AXChange-Format: das Beste aus Barcamps, Open Spaces und Roundtables

Unser Ziel: am Ende des Tages sollen alle mit dem Gedanken „das hat sich (wieder mal) gelohnt!“ nach Hause gehen. Dafür haben wir das Beste aus Barcamps, Open Spaces und Roundtables in eine Struktur gebracht:

  1. Um 18 Uhr stehen die Türen offen für alle, die sich austauschen möchten oder konkrete Fragen haben.
  2. Um 19 Uhr geht’s dann los: während einer kurzen Vorstellungsrunde schreibt jeder ein oder mehrere Axure-Themen auf, die ihn interessieren. Dann geht’s mit einem Talk im Stile einer Live- Demo weiter.
  3. Nach dem 30-minütigen Talk werden dann die Axure-Themen sortiert und auf die jeweiligen Tischinseln zum Diskutieren und Austauschen verteilt. Wer möchte, kann sich an die jeweilige Insel setzen, die ihn interessiert.

Aller Anfang ist schwer

AXChange TeilnehmerVor dem ersten AXChange lag auch eine gewisse Unsicherheit in der Luft: Passt das Schwerpunktthema? Wie viele werden wohl kommen? Werden wir unser selbstgestecktes Qualitäts-Ziel erreichen?

Total unbegründet: trotz des ersten heißen Sommertages im Jahr waren 18 von angemeldeten 29 Personen da. Die No-Show Rate war zwar ungewöhnlich hoch; dafür war das Feedback nach dem ersten Meetup super und unglaublich motivierend!

Ob über CSS und JavaScript-Integration in Axure, Kompatibilität mit anderen Programmen oder der Austausch über andere Programme und Workflows – alles kam auf den Tisch und wurde mit viel Elan von den Teilnehmern in kleinere Gruppen diskutiert.

Der Beginn einer Reihe…

Inzwischen fand bereits das zweite AXChange Hamburg Meetup statt. In einer kleinen gemütlichen Runde haben wir AxShare und Axure 8 als Schwerpunktthemen durchgesprochen. Wir haben diverse andere Axure-Themen auf den Tischen ausgebreitet und uns recht lange über Team-Projects oder auch über das Bauen von App-Prototypen ausgetauscht.

Am 12. August findet dann schon das dritte AXChange Hamburg Meetup bei uns statt. Wir freuen uns auf neue und alte Gesichter und Themenvorschläge! 
Zum Meetup: http://www.meetup.com/de/AXChange-Hamburg/events/223806735/

AXChange goes Berlin!

Gleich nach dem ersten Meetup haben wir dann AXChange Berlin gegründet, um die Axure Meetups auch nach Berlin zu bringen. Wir konnten Zalando einen guten Location-Sponsor finden (Dank dafür an Jay Kaufmann). Für alle Berliner Axuristas: am 21. Juli findet das AXChange bei Zalando in Berlin statt. Das Schwerpunktthema ist “Design-robuste Prototypen und das Auslagern von Interaktionen in Funktionen“. Das kam bereits beim ersten Hamburger Meetup gut an und ist extrem wichtig, denn Design-robuste Prototypen lassen sich ziemlich schnell auch während Nutzertests ändern.

Zum Meetup in Berlin: http://www.meetup.com/de/AXChange-Berlin-Axure-Meetup/

 
25. Mai, 2015

AxShare als App – sie ist online!

AxShare App Banner

Wir haben bis Hamburg die Nudelsuppenschüsseln klappern hören (Axure Insider-Witze…) und dann kamen auch schon die Mails von Axure, dass die AxShare App jetzt in den App- Stores von Apple und Google zu finden ist! Hier kommt nun unser kleines Update unserer in der Beta-Phase entstandenen Meinung.

Die App ist nach wie vor eine echte Hilfe und eine super Lösung, um den Prototypen auch einem Kunden in einem Café oder während eines Pitches zu zeigen. In Zukunft wird die App es uns ermöglichen, noch komplexere und vollständigere Prototypen zu bauen, um noch besser die endgültige App oder mobile Webseite für den UX-Test zu simulieren – und um damit auch noch glaubwürdigere und interessantere Reaktionen zu bekommen.

Sitemap in der AxShare App

Aktuell werden wir allerdings keinen Test mit der App durchführen: Am 6. Mai hatten wir ein sehr detailliertes Telefonat mit Rachel (der Produktmanagerin der AxShare App) und ihr die Punkte mitgeteilt, die wir noch nicht so prickelnd fanden. Vor allen die Sitemap ist uns ein Dorn im Auge: diese ruft man auf, indem man vom linken Bildschirmrand aus in die Mitte wischt. Das ist ein Problem für unsere UX-Tests von App-Prototypen. So ein Rechts-Swipe wird ja oft für echte Interaktionen genutzt und da ist es extrem störend, wenn dann immer die Sitemap von AxShare geöffnet wird. Rachel hat uns versprochen, dieses und weitere Probleme bald zu lösen – und wir werden am Ball bleiben!

 
18. April, 2015

AxShare als App – Erste Eindrücke aus dem Beta-Test

AxShare als App

Seit gestern gibt es von Axure eine App für AxShare. Wir hatten die App im Beta-Test.

Was kann die AxShare-App?

  • Über die App kann man schnell und komfortabel den zu testenden Axure Prototypen öffnen. Das lästige Eingeben der AxShare-URL entfällt.
  • Prototypen können lokal auf dem Device gespeichert werden.
  • Die lokal abgespeicherten Prototypen sind auch offline auf dem Gerät verfügbar und sorgen dafür, dass die Performance des Prototypen auf dem Gerät nicht aufgrund einer langsamen Internetverbindung leidet.
  • Die Statusleiste des Smartphones kann ausgeblendet werden.
  • Die App ist für iOS und Android verfügbar.

Gute Nachrichten für das mobile Prototyping mit Axure

Irgendwie war das Testen von App-Prototypen auf Smartphones und Tablets bislang nicht sonderlich komfortabel. Besonders für iOS-Devices ging das meist über remote in AxShare generierte Prototypen. Das war bei größeren Prototypen langsam und nicht sehr performant. Besonders bei User-Tests hat das bei den Probanden immer einen negativen Eindruck der zu testenden App ausgelöst. Die Probanden waren schnell genervt und haben weniger Sachen ausprobiert.

Ach ja, das Finden des richtigen Prototypen über die kryptische AxShare-ID hat auch genervt. Oft haben wir uns in der Vergangenheit uns die AxShare-ID diktiert, um den Prototypen auf dem Smartphone oder Tablet zu öffnen.

Über die lokal in der AxShare-App gespeicherten Axure-Prototypen wird das jetzt deutlich besser. Die Prototypen stehen sauber aufgelistet in der App. Die lokal gespeicherten Daten verkürzen die Ladezeiten der Prototypen und machen eine Internetverbindung überflüssig.

Zusätzlich kann die Statusleiste vom Smartphone ausgeblendet werden, was sicherlich bei einigen Prototypen wichtig ist, aber aus guten Gründen von Apple nicht empfohlen wird (Apple Developer Guidelines).

Unser Fazit

AxShare TesteinladungWäre schön gewesen, wenn die App einen Monat eher fertig geworden wäre. Dann hätten wir die letzten 6 App-Projekte, die wir mit Axure entwickelt haben, schon damit testen können.

Noch ist die App in der Entwicklung. Wir sind dennoch schon jetzt begeistert, denn die App sorgt für störungsfreiere UX-Tests und besseres Nutzer-Feedbacks.

Sobald wir mehr wissen, werden wir wieder berichten.

 
11. März, 2015

Kongress Raum Schiff Erde RSE15 im Nochtspeicher HH

Realität ignorieren ?! – 2030 ist virtuell!

RSE15 Panorama

Rückblick von Malte Lücken und Christian Reichel

Der Raum Schiff Erde Kongress RSE15 ist ein eintägiger Kongress mit knapp 100 Teilnehmern und damit (zumindest begrifflich) so etwas, wie eine vierteilige Trilogie an einem Tag. Daher ist das diesjährige Motto „Don’t Panic“ als Hommage an Douglas Adams und „The Hitchhikers Guide to the Galaxy“ mehr als passend. Eparo ist wie immer Sponsor. Malte und Christian waren dabei.

Keine Panik!

Auch wenn wir uns in 15 Jahren fast ausschließlich in einer virtuellen Welt bewegen, wenn Drogen auf USB-Sticks speicherbar sind und wir vielleicht nicht einmal mehr merken, wann wir mit Computern interagieren – es gibt keinen Grund zur Beunruhigung.

Die Einzigen, die kurzzeitige Panikattacken hatten, waren die Vortragenden, die es mit einem Beamer-Kabel mit Wackelkontakt zu tun bekamen.

Große Rolle für digitale Services

Unser Fazit nach sieben Stunden: digitale Services werden in Zukunft eine noch stärkere Rolle spielen, als sie es heute bereits tun. Sollte sich Moore’s Law bewahrheiten, dann werden wir in 15 Jahren 1000 Mal bessere Computer und Displays haben – so Prof. Dr. Frank Steinicke, Professor an der Universität Hamburg. Zu den Folien.

“Realität” ignorieren. Neue Ideen in Prototypen umsetzen.

Außerhalb der immersiven, virtuellen Welten ist und bleibt die direkte Interaktion mit digitalen Services ebenso wichtig. Da es allerdings Vielen schwer fällt, neue Interaktionsmöglichkeiten zu entwickeln, nannte Prof. Stefan Wölwer drei Methoden, den Gedankenblocker namens „Realität“ zu ignorieren: Design Fiction, Speculative Design und Wirklichkeitsschaffung durch Interaktion. Zu den Folien.

Alle drei Methoden haben allerdings eines gemeinsam: sie erschaffen Prototypen, die getestet werden und der Visualisierung eigener Idee dienen können.

Natürlich war das nicht alles, was auf dem RSE15 lief. Einige interessante Gedankengänge und Inspirationen haben wir mitgenommen. Die Band Lunartree bildete mit leicht melancholischer, ruhiger, akustischer Musik den krönenden Abschluss.

 
18. Dezember, 2014

Komponentenbasierte Frontend-Entwicklung

Lego-Bausteine
Konzepter und Benutzer von Axure Libraries wissen: man muss das Rad nicht neu erfinden. Darum gibt es gut-durchdachte UI Pattern Libraries. Aber wie sieht das Ganze in der Entwicklung aus? Wie kann man einzelne Bausteine für die Frontend-Entwicklung erstellen, ohne gleich eine Bibliothek aus Codeschnipseln bauen zu müssen? Ich habe beim vergangenen UX Roundtable im Dezember, 2014 eine mögliche Lösung vorgestellt: Precompiling.

Wenn wir ehrlich sind, dann erfinden wir das Rad bei Webseiten mit jedem Projekt nicht neu, sondern greifen gerne auf altbewährte Oberflächen-Elemente zurück. Das ist auch die Idee von UI Pattern und Axure Libraries. Diese bestehen aus bereits gestalteten oder durchdachten Elementen, die für das jeweilige Projekt nur noch eingefügt und angepasst werden.

Das Problem: starre technische Strukturen und Blockaden

Doch in der Umsetzung sieht das Ganze wieder ein wenig anders aus: die starren Syntax-Strukturen von den Sprachen HTML und CSS lassen keine Aufteilung in Komponenten zu. Das Problem dabei ist, dass für jedes neue Projekt viel aus bestehenden Projekten kopiert oder für das derzeitige Projekt neu geschrieben werden muss. Aber noch viel größer ist der Kommunikationslücke zwischen Konzeptern und Entwicklern: durch die unterschiedliche Struktur ist ebenfalls das Mindset des Projektes unterschiedlich. Das bedeutet, dass im Zweifel mühselige Übersetzungen von der Konzeption zur Entwicklung – meist in Form einer Spezifikation – nötig sind.

Das Problem sind dabei nicht die Entwickler, sondern die Umgebung, in der sie arbeiten: sie müssen ihr Denken an die vorhandene Programmiersprache anpassen – so wie Fließbandarbeiter ihren Arbeitstakt an die Maschine anpassen müssen. Die Lösung ist also, die Programmiersprache zu ändern, um diese Blockade aufzubrechen. Was daraus resultiert, sind Dateien, die mehrere Tausend bis Hunderttausend Zeilen an Code beinhalten. Natürlich bekommen Entwickler durch so viele Zeilen Code auch noch andere Probleme – wie beispielsweise die Übersichtlichkeit vom Code und damit auch die benötigte Zeit für eine Änderung.

Precompiler

Die Lösung: Precompiling

Die Lösung heißt Precompiling und ermöglicht das Benutzen anderer Programmiersprachen oder -syntaxen. So kann beispielsweise die Syntax von CSS so erweitert werden, sodass es möglich ist, die ursprüngliche CSS-Datei in viele kleine Komponenten zu unterteilen. Und das gleiche kann mit HTML auch gemacht werden.

Durch Precompiling werden die einzelnen Komponenten dann wieder in das jeweilige Format zusammen gesetzt, das der Browser für die Darstellung der Webseite benötigt.

Tools

Die Sprachen und Tools

Wir haben also nun die Technik, die starre Strukturen von HTML und CSS aufbrechen kann. Was wir nun benötigen, sind die jeweiligen Spracherweiterungen und der Precompiler selbst.

Für CSS gibt es sowohl die Sprache SASS als auch LESS, die sich nach einigen Jahren Weiterentwicklung bei den Entwicklern etabliert haben. Vor allen für SASS existieren bereits viele andere Bibliotheken, die jeder Entwickler zu schätzen wissen wird.

Die Sprachen SASS und LESS sind sehr mächtig und bieten viele Vorteile. So können Mix ins und Funktionen geschrieben werden, die den Code automatisch erweitern. Wieder eine Zeitersparnis also. Außerdem ermöglichen es beide Sprachen, Variablen für Farben, Schriftgröße usw. festzusetzen. So können Änderungen im Contextual Design über das gesamte Design hinweg schnell und effizient eingepflegt werden. Eine Farbänderung von Blau zu Violett kann so innerhalb weniger Sekunden erfolgen.

Für selbstständige Entwickler ist das besonders praktisch: sie müssen nur noch kleine Anpassungen bei einem neuen Webseiten-Projekt vornehmen, um die Webseite komplett neu zu gestalten.

Für HTML sieht die Welt deutlich anders aus. Es gibt bisher ein mir bekanntes Konzept, welches die Aufteilung von HTML-Dateien in Komponenten erlaubt und anwendbar macht. Dieses Konzept wurde in den so genannten Hammer Tags (http://hammerformac.com/docs/tags) in der zugehörigen Hammer Mac App http://hammerformac.com) umgesetzt.

Idee
Mit Hammer haben wir auch gleichzeitig eine App, die das Precompiling von unseren HTML-Komponenten erlaubt. Eine weitere App für den Mac ist CodeKit oder Koala. Alle drei Apps sind vom Prinzip her ziemlich ähnlich: man zieht den Projektordner in die jeweilige App rein und die App erledigt den Rest – vom Erkennen der zu kompilierenden Dateien bis hin zur Prekompilierung selbst. Die komponentenweise Aufteilung von HTML und CSS erlaubt allerdings bis heute nur Hammer mit den Hammer Tags (der Precompiler ist mittlerweile aber Open Source und könnte in Zukunft auch in anderen Apps benutzt werden: https://github.com/riothq/hammer-gem).

Struktur

Die Struktur

Wie strukturiert man aber nun die einzelnen Komponenten? Klar ist, dass diese Komponenten durchaus zusammen gesteckt werden können. So können eine Navigationsleiste und ein Logo gemeinsam den Kopfbereich einer Webseite bilden. Auf der anderen Seite beinhaltet die Navigationsleiste jeweils die einzelnen Navigationselemente. Fakt ist, dass diese Elemente durch ihre Komposition eine gewisse Hierarchie darstellen. Ein Fußbereich einer Webseite besteht aus mehreren kleineren Unterteilungen, die wiederum aus vielen kleineren Unterteilungen bestehen.

Brad Frost hat 2013 bei der Konferenz „Beyond Tellerrand“ in Düsseldorf eine Struktur vorgestellt, die sich auf den atomaren Aufbau von Organismen orientiert. Die Idee ist, dass größere Strukturen (wie Organismen) kleinere Strukturen (wie Moleküle) beinhalten können. Das „Atomic Design“ ist meiner Meinung nach eine sehr gute Grundlage, denn nicht anders strukturieren wir unsere Axure Libraries, die wir für Kunden bauen. Für die Entwicklung müssen wir diese Struktur allerdings noch etwas kleinteiliger strukturieren, damit wir die Wiederverwendbarkeit der einzelnen Elemente und Codezeilen gewährleisten können. Daher fangen wir mit dem ersten Element der Kette an: dem Proton.

Protonen

Die aus dem altgriechischen übersetzte „Ersten“ Teilchen unserer Struktur sind dafür zuständig, sämtliche notwendigen Bestandteile unseres Projektes – wie die SASS-eigenen Mix ins oder Funktionen – zu deklarieren. Hier steckt sozusagen alles drin, was bei nahezu jedem Element und Projekt benutzt werden kann und sollte. Somit sind hier auch die Variablen zu finden, die durch wenige Änderungen die gesamte Seite neu gestalten könnten.

Atomkern

Der Atomkern beinhaltet die Kernelemente, die ebenfalls in jedem Projekt zu finden sind, also grundsätzliche Gestaltungen von Tabellen, Typografien, Buttons und Formularfeldern. Es ist sozusagen eine Ansammlung vieler kleiner Gestaltungsmuster von User Interface Elementen. Wer hier sorgfältig Best Practices auswählt, braucht sich um solche Gestaltungsmuster keine Gedanken mehr zu machen, sondern kopiert diese nur noch von Projekt zu Projekt.

Atom

Die erste projektbezogene Strukturebene ist das Atom. Hier werden sämtliche Elemente aus dem Atomkern nochmals angepasst und auch neue, spezifischere kleine Elemente (meistens definiert durch CSS-Klassen) gestaltet.

Moleküle

Die Moleküle sind die ersten kleinen Kompositionen, speziell zum vorliegenden Projekt. So kann ein grundsätzliches Navigationselement oder eine Kombination aus einem Formularfeld und Button hier gestaltet werden.

Organismen

Organismen sind ganze Teilbereiche einer Seite, wie beispielsweise der Kopf- oder Fußbereich.

Templates

Die Organismen werden am Ende bei der nächstgrößeren Struktur – den Templates – in der richtigen Reihenfolge eingebunden

Pages

Für spezifische Seiten kann nun in der letzten Strukturebene die Gestaltung angepasst werden. So kann die Hauptseite anders als der Blog aussehen, ohne dabei die grundsätzliche Gestaltung einzelner Elemente allzu sehr zu verfälschen.

Diese gesamte Struktur mündet letztendlich in eine Dummy-SASS oder Dummy-LESS Datei, wodurch eine einzige CSS-Datei entsteht.

Mit dieser Struktur haben wir also eine hierarchische Abbildung einzelner Elemente. Durch die zusätzlichen zwei Strukturebenen Protonen und Atomkern haben wir außerdem bereits zwei Strukturebenen für eine eigene Bibliothek. Diese beiden Ebenen können in jedem Projekt genutzt werden.

Einige Elemente aus den weiteren Strukturen Atom und Moleküle können ebenfalls genutzt werden, allerdings ist die Gestaltung hier immer auf das jeweilige Projekt bezogen.

Fazit

Durch das Precompiling der Erweiterungssprachen wie SASS und Hammer Tags können Frontend-Entwickler eine sehr ähnliche Struktur von Bausteinen aufbauen, wie sie Prototypen-Entwickler mit Axure Libraries oder wie Konzepter mit UI Pattern Libraries aufbauen und nutzen. Missverständnisse können so verringert und verhindert werden, weil jeder im Team von der gleichen Sache spricht. Aber vor allem für die Entwickler bietet Precompiling einen entscheidenden Mehrwert: Änderungen können viel schneller durchgeführt werden, da die Aufteilung in Komponenten einen deutlich besseren Überblick verschafft.