Content Design und UI Architektur für Multiscreen-Projekte
Methoden und Regelwerke für die Konzeption, Gestaltung und Umsetzung von Layout, Inhalt und Workflows im Baukasten-Prinzip
Digitale Inhalte können heute überall erscheinen. Wir nutzen täglich digitale Services auf verschiedensten Geräten und Medien. Informationen fließen in alle Kanäle. Multiscreen ist inzwischen digitale Realität geworden. Um ein einheitliches Nutzungserlebnis zu erschaffen, benötigt es einen durchgängigen Informationsfluss. Voraussetzung dafür sind ein zentraler Knotenpunkt für Inhalte, ein System zur Definition von UI Elementen und Regeln wann welche Inhalte in welcher Kombination wo und wie angezeigt werden. Damit dies technisch gelöst werden kann, ist es erforderlich Inhalte, User Interfaces und Workflows nach einem jeweils ähnlichen Muster modular und strukturiert zu planen und aufzubauen — vergleichbar mit den Bausteinen in einem Baukastensystem.
Anmerkung: Dieser Text ist ursprünglich 2015 entstanden und bildet die Basis für den Folgetext und einen Vortrag zum Thema “Content und UI Mapping”. Das Thema wird außerdem ausführlich in Kapitel 7 in “Multiscreen UX Design” behandelt und illustriert.
Ergänzend zum Artikel die Vortragsfolien der “Usability Professionals 2015” Konferenz:
Einleitung
Viele Content-Angebote (z.B. einzelne Artikel der New York Times oder des Spiegel) werden heute häufiger in anderen Kanälen (z.B. auf Twitter oder in Flipboard) als der originären Website wahrgenommen. Eine Inhalts-Schnittstelle (Content API) gibt alle Infos ab und der Empfänger oder darstellende Kanal entscheidet, welche Inhaltselemente er verwendet. Die visuelle Ausgestaltung ist dann durch die Styling-Definitionen der Ziel- und Fremdplattformen vorgegeben.
Um für eine automatisierte Verwendung die richtigen Inhaltsbausteine bereitstellen zu können, muss der Inhalt entsprechend strukturiert — im besten Fall sogar „intelligent“ — sein.
“You can create good experiences without knowing the content. What you can’t do is create good experiences without knowing your content structure. What is your content MADE from, not what your content IS.” — Mark Boulton
Next Generation Information Experience in einer Multiscreen-Welt
Das Internet ist integraler Bestandteil unseres Lebens, digitale Informationen werden selbstverständlich auf verschiedensten Geräten, genutzt. Wir leben in einer Multiscreen-Welt. Informationen werden auf verschiedensten Geräten erstellt und konsumiert.
Die Art und Weise, wie Informationen entstehen, verändert sich. Auf der Seite der Entstehung von Inhalt steht der Autor oder Inhaltskurator. Auf der anderen Seite steht der Rezipient, also der Nutzer der Informationen.
Ein Informationsverwaltungssystem muss die Arbeit von Inhaltserstellern unterstützen und sollte als Hub für sämtliche Inhalte dienen können. Seine Schnittstellen, Datenaggregation und Workflows müssen individuell gestaltbar sein.
Die Erfassung bzw. Erstellung des Inhalts geschieht selten über ein einheitliches System. Am besten wäre es, wenn Autoren ihr gewohntes Erstellungs-System benutzen können und die erfassten Inhalte über entsprechende Schnittstellen und eine Art Inhalts-Struktur-Mapping im Content Hub gemäß des Inhaltsmodells konsolidiert, zusammengeführt und auf die definierte Struktur gebracht werden. Dadurch wäre es möglich Inhalte mit Informationen des Inhaltsmodels zum Beispiel per E-Mail, Evernote, Tweet, Facebook-Post oder einem anderen System zu erfassen, im Content Hub aufzubereiten und flexibel an einen beliebigen Kanal abzugeben.
Es wäre somit möglich über eine „simple“ E-Mail die Inhaltselemente Autor/Verfasser, Erstellungsdatum, Kurzbeschreibung, textlicher Hauptinhalt, Bilder oder Media-Elemente (als Anhänge) und andere Metainformationen z.B. mit Hilfe von Hashtags oder anderen definierten Zeichen im E-Mail-Text zu erfassen, so wie es beispielsweise die Todo-App Todoist macht. Die erfassten Inhalte können dann von den Editoren im zentralen Knotenpunkt bearbeitet, optimiert und ergänzt werden.
Inhaltsanbieter stehen vor dem Problem, dass sie Inhalte in vielen Kanälen konsistent publizieren können sollten. Informationen sollten sich überall darstellen lassen. Voraussetzung dafür sind ein zentraler und möglichst benutzerfreundlicher Knotenpunkt für Inhalte (z.B. CMS), ein zentrales System zur Definition von UI Elementen (z.B. Styleguide) und entsprechende Regeln (Workflows) wann welche Inhalte in welcher Kombination auf welchem Gerät wie angezeigt werden.
In einem vorgelagerten oder zumindest am Anfang des Projekts initiierten (CMXD-) Prozess lassen sich die dafür wichtigsten Parameter definieren (Nagel, 2014b). CMXD steht hier für „Content Manager Experience Design“, angelehnt an einen Artikel von Rasmus Skjoldan (2013). Dazu gehört es die Modi der Inhaltserfassung zu erkennen, die 3–5 wichtigsten Zielkanäle zu definieren und das Eingabeinterface und die Systeme entsprechend anzupassen oder zu synchronisieren.
Eine unabhängige Methode für eine ungewisse Zukunft
Mein nachfolgender Ansatz ist nicht grundsätzlich neu. Es geht mir unter anderem um das Grundprinzip und eine einheitliche allgemein verständliche Sprache und um disziplinübergreifende Begriffe, die von allen Stakeholdern verstanden werden (Projektmanager, Kunden, Entwickler, Konzepter, Gestalter). Der Grundgedanke ist es, alles (ähnlich) atomar bzw. nach dem Baukastenprinzip zu zerlegen bzw. zusammenzusetzen und generisch zu denken. Vor allem vor dem Hintergrund, dass wir gar nicht ahnen können, für welche zukünftigen Kanäle wir zum aktuellen Zeitpunkt Inhalte und User Interfaces entwerfen (Frost, 2015).
„I have no idea what the hell I am doing. And neither do you. And that’s ok.“ — Brad Frost
Ich denke, dass wenn man Inhalte, User Interfaces und Prozesse nach atomaren, modularen Baukasten-Patterns erstellt, ist man von zukünftigen Entwicklungen weitgehend unabhängig.
Semantisch gleiche Inhalte sollten in unterschiedlichen Medien, Kanälen und Geräten variabel einsetzbar sein — das gilt für Smartphone, Tablet, Desktop, TV und Smartwatch genauso wie für Inhalte auf der eigenen Website, im Google-Suchergebnis, im RSS-Feed, auf Instagram oder Facebook oder jede andere Inhalts-Darstellung.
Vier Kernbereiche
Um Inhalte, Interfaces und Prozesse flexibel, strukturiert und modular zu planen und umzusetzen, sind im Projektverlauf (neben der Berücksichtigung der Nutzer und derern Bedürfnisse) grundsätzlich vier Kernbereiche zu betrachten: Inhalte, UI, Workflows und Schnittstellen.
Der Inhalt und seine Nutzer (das sind sowohl die Autoren und Editoren als auch die Empfänger der Information) sollten im Zentrum der Betrachtung stehen.
„Design from the Content out.“ — Stephen Hay (via Frost, 2012)
Informationen (Daten/Content)
Entsprechend der thematischen Tendenz (Taxonomie, “Unit”, Domäne) gibt es Inhaltselemente für verschiedene Inhaltstypen. Dazu die entsprechenden Formular-Elemente für das “Backend-Frontend”, um die Eingabemaske für die Inhaltsobjekte zu bauen (vorausgesetzt die Inhalte werden in einem eigenen Content Management System erfasst). Ein Inhaltstyp besteht aus verschiedenen Inhaltselementen. Die semantische Bedeutung beeinflusst die Struktur des Inhaltstyps, dessen Klassifikation und entsprechende Kategorien.
Interface/UI
Zum User Interface gehören in dem Fall auch Visual Design, Interaction Design. Die UI-Elemente werden nach dem Atomic Design Prinzip aufgebaut. Sie sind relevant für die Frontend-Ausgabe, für die Formular-Elemente im Backend und für die (Preview-) Darstellung der Inhalte im Backend. Visual Design und individuelles Styling wird über einen „Living Styleguide“ beschrieben, der stets aktuell gehalten wird. Das UI und die UI-Elemente für das Backend werden generisch vorbereitet. Die UI-Elemente und Bibliotheken können sukzessive ergänzt werden.
Prozesse und Workflows (Regeln)
Sie definieren — nach dem „If This Then That“-Prinzip — wie Inhalte zusammenhängen oder sich ändern können, wenn ein Ereignis eintritt oder eine Veränderung stattfindet. Es handelt sich dabei um die Definition einer regelbasierten Interaktion zweier Objekte untereinander.
Schnittstellen
Das Konzept der originären App mit eigenständigem Inhalt wird abgelöst vom Konzept der App als ein Content-Lieferant. Dieser stellt (in kleine Einheiten zerlegte) Inhalte über eine Schnittstelle anderen Diensten zur Verfügung (Schätzle, 2015a) — innerhalb der Inhalts-Bausteine im Content Hub und von und zu anderen Applikation, um die Inhalte/Daten auszutauschen bzw. zu synchronisieren.
Baukastenprinzip. Modularer Ansatz: Atomic Design und Content Modeling
Struktur und Modularität
Apps und Websites sind zukünftig weniger autarke Einheiten, sondern eher aus unterschiedlichsten Modulen bestehende Systeme. Dieser Aspekt wird vor allem wichtiger, wenn sich Smart Watches im Windschatten der Apple Watch stärker verbreiten.
Eine Information setzt sich strukturell aus einzelnen Elementen zusammen. Je nach Plattform, Zielkanal und Kontext werden die entsprechenden Elemente angezeigt. Diese Zusammensetzung beschreibt Brad Frost im User Interface Design Kontext mit Atomic Design (Frost, 2013a). Auf dem gleichen Prinzip basierend lässt sich auch Inhalt atomar aufbauen, man könnte von „Atomic Content“ sprechen. (Andere gängige Begriffe sind Structured Content, Future Friendly Content, Intelligent Content, Adaptive Content oder Smart Content.)
Mit Atomic Design werden ähnlich wie in der Chemie (daher die Atom-Metapher) Web-Projekte in kleinstmögliche Bausteine zerlegt. Diese Bausteine werden anschließend zu größeren Einheiten (vgl. Moleküle oder Organismen) bis hin zu kompletten Seiten kombiniert.
Beim Content Modeling (Gibbon, 2015 und Lovinger, 2012) werden — basierend auf dem Inhaltskonzept — Inhaltsmodelle erstellt, die strukturierten Inhalt (Structred Content) in Form von Inhaltstypen (Content Types), einzelnen Attributen und Datentypen und deren Beziehung untereinander beschreiben. Um Inhalt zu strukturieren, muss man die Inhaltstypen kennen und natürlich auch den Themenbereich, um den es sich handelt, weil dieser die Struktur und die Semantik entscheidend beeinflusst.
Gut strukturierter modularer Inhalt lässt sich auch als Rich Snippets für die Suchmaschinenoptimierung einsetzen. Diese Elemente werden in den Suchergebnissen angezeigt. Das sind beispielsweise Qualitätsbewertungen wie sie bei Focus-Online-Artikeln angezeigt werden oder bei Rezepten Bilder, Kalorienangaben, Kochzeiten und Zutaten.
Atomic Design und Content Modeling sind vergleichbar mit dem LEGO-System oder ähnlichen Prinzipien. Ihnen gemein ist Modularität und strukturierter Aufbau der einzelnen „Bauteile“.
„We’re not designing pages, we’re designing systems of components.“ — Stephen Hay
Vorbild: Atomic Design und LEGO
Das Ziel der von mir vorgestellten Baukasten-Überlegungen ist es alle Elemente ähnlich zu strukturieren und dafür ein gemeinsames verständliches und allgemeingültiges Wording für alle Projektbeteiligten zu finden, weil die Metapher „Atom“ unter Umständen schwer vermittelbar oder irritierend sein könnte.
Beim Atomic Design und Content Modeling werden einzelne Elemente (oder Bausteine) LEGO-ähnlich nach dem Baukastenprinzip zusammengesetzt. Da sich auch Workflows und andere Bereiche nach diesem Prinzip konzipieren und realisieren lassen, setze ich ein einheitliches Wording angelehnt an das Content Modeling ein.
UI und Content Inventory (und Audit)
Um zu wissen mit welchen visuellen und inhaltlichen Bausteinen es man in einem Projekt zu tun hat, empfiehlt es sich in einer frühen Projektphase eine Analyse der bestehenden und zukünftig zu verwendenden Elemente durchzuführen. Mit einem Content Inventory (oder Audit) wird untersucht, welche Arten von Inhalt aus welchem Themenbereich verwendet werden und wie diese Inhalte und Inhaltsmodelle strukturiert sind (Baldwin, 2010). Welche Inhaltselemente sind erforderlich, um mit dem zu publizierenden Inhalt alle aktuell bekannten und ggf. zukünftig relevanten Kanäle mit adäquatem Inhalt zu versorgen. Entsprechend ähnlich untersucht und definiert man mit einem UI Inventory welche UI Elemente in einem Projekt verwendet werden (sollen) (Frost, 2013b). Nach der Inventur folgt das Modellieren der Bestandteile.
Modellieren nach dem Baukastenprinzip
Wenn die Inhalte und deren potentielle strukturelle und visuelle Ausprägung bekannt sind, kann man sich an das Modellieren von Inhaltstypen und UI Typen machen. Diese Typen werden stufenweise aufgebaut, beginnend mit dem kleinstmöglichen Bauteil.
Generisches 5-Stufiges Baukasten-Model (Matrix)
Die einzelnen (atomaren) Elemente bzw. Bausteine bauen aufeinander auf und lassen sich flexibel zu einem Model zusammensetzen. Jedes Model lässt sich 5-stufig aufbauen. Vom kleinstmöglichen Element über das generische Template bis zum realen, einmaligen Objekt (individuelles Unikat).
Die Begriffe aus der Chemie-Metapher lassen sich durch allgemeingültige generische Begriffe ersetzen:
- Atom = Element (Baustein)
- Molekül = Komponente oder Modul
- Organismus = Segment
- Template oder Typ (generisch)
- Instanz oder Objekt (konkret)
Modulare Baukastenprinzipien gibt es auch in anderen Bereichen. Ob ich nun ein LEGO-Produkt zusammensetze, mit Hilfe eines Konfigurators meinen nächsten Neuwagenkauf plane oder die im Kühlschrank vorhandenen Zutaten zu einem schmackhaften Gericht kombinieren möchte — alles lässt sich aufteilen, konfigurieren und kombinieren.
Korrelation zwischen Inhalt und UI
Es besteht eine Korrelation der Elemente in Atomic Design und Content Modeling, das bedeutet zwischen den einzelnen Inhaltselementen und deren Darstellung im Zielkanal oder verwendeten Medium des Rezipienten. Wenn ich Inhalt modelliere, definiere ich damit quasi indirekt auch gleich das zugehörige UI-Element in generischer Form (Wireframe-artig / ohne Visual Design). Wenn man den Inhaltstyp definiert, legt man außerdem indirekt automatisch auch die entsprechenden Formular-Feld-Typen für das Eingabe-Interface fest. Mit dem Eingabe-Interface werden die Inhalte erfasst. Im besten Fall (für den Erfasser) können das sehr beliebige bzw. die von ihm bevorzugten Systeme sein. Die erfassten Inhalts-Elemente müssen bei unterschiedlichen Systemen zur Struktur des Inhaltstyps passen, damit sie auf diesen gemappt werden können.
Es ist bekannt, dass Inhalt und UI — also die Formatierung des Inhalts beim Rezipienten — strikt voneinander getrennt werden sollen. Dennoch stehen die Elemente in direktem Zusammenhang zueinander. UI Typen und Inhaltstypen korrelieren. Beim Rezipienten bzw. im jeweiligen Medium werden UI und Inhalt wieder zusammengefügt. Durch die strikte Trennung kann dieses Zusammenfügen sehr flexibel geschehen.
Für Sunrise war es beispielsweise eine große Herausforderung die populäre Kalender-App auf den kleinen Screen der Apple Watch anzupassen (Sunrise, 2015).
„We had to challenge our entire interface to make it fit on such a tiny screen, cropping out text and icons with every design iteration.“ — Sunrise
Je atomarer und unabhängiger die UI Elemente konzeptionell gedacht sind, desto einfacher lassen sich Inhalte auf andere Viewports bringen und UI Elemente anpassen.
Das Content Model definiert das (Backend) UI (Model)
Henne-Ei: Zuerst der Inhalt, dann das UI.
Die Inhaltsmodelle werden nach dem Baukastenprinzip zusammengebaut. Sie bestehen aus kleinsten (atomaren) Elementen, die sich zu kompletten generischen Inhaltstypen zusammensetzen lassen, auf deren Basis wiederum die konkreten Ausprägungen gebildet werden.
Eine konkrete individuelle Ausprägung eines Inhaltstyps nenne ich Inhaltsobjekt. Dem Ganzen liegt ein Baukasten für Formular- bzw. Inhaltselemente zu Grunde. Die primäre Aufgabe für Editoren, Autoren, Content-Pfleger und -ersteller ist es die Inhaltsobjekte (Informationsprodukt, Content Objekt, etc.) zu erstellen und/oder zu bearbeiten.
Über das Content Model und den Content Type werden automatisch die Inhaltselemente und damit auch indirekt entsprechende Formular-Elemente des Backends definiert (konzeptionelle Korrelation). Das Inhalts-erfassende System benötigt für jedes Inhaltselement ein entsprechendes (formularartiges) UI-Element. Dieses kann sich je nach System oder Art der Erfassung unterscheiden oder in Varianten vorliegen (z.B. Erfassung von Datum oder Location). Für Text wäre das ein einfaches Texteingabefeld oder ein RTE (Rich Text Editor), für Bilder ein entsprechendes Bildupload-Formular inkl. Caption-Text und ergänzenden Metainformationen zum Bild.
Zu jedem Inhaltselement wiederum gibt es ein UI-Element (oder einen User Interface Baustein) im Frontend (Viewport bzw. Zielkanal), damit der Inhalt dargestellt werden kann.
Inhalts-Elemente, Formular-Elemente im Backend zur Erfassung der Inhalte und UI-Elemente zur Darstellung der Inhalte im Frontend stehen damit in direktem Zusammenhang und bedingen sich gegenseitig.
Universalität und Verständlichkeit
Ich möchte den Bezug zwischen den verschiedenen strategischen und konzeptionellen Disziplinen im Bereich Inhalt und UI herstellen. Alles baut auf dem Baukastenprinzip auf und ist miteinander verknüpft. Spätestens beim Rezipieren der Informationen stehen UI und Inhalt in direktem Zusammenhang. Der Nutzer konsumiert Inhalt und UI nämlich in kombinierter Form. Die Korrelation besteht außerdem auch zwischen UI, Inhalt und Workflows. Schnittstellen bilden die Brücke beispielsweise um Inhalte zu synchronisieren oder zwischen Systemen auszutauschen.
Das Prinzip soll stets verwendet werden können (egal ob es sich um Atome, UI, Layout, Inhalt oder irgendetwas anderes handelt). Mit der vorgestellten Korrelationsmatrix möchte ich diese generischen und allgemeinverständlichen Muster erklären und auf alle Bereiche anwendbar halten. Die 5-Stufigkeit und der Atomic Design Ansatz sind kein Dogma. In einem Kundenprojekt haben wir einen Living Styleguide nach dem Atomic Design Prinzip aufgebaut und davor noch eine zusätzliche Ebene zur Definition von Basiselementen wie Grid, Farben, Typografie und Interactive States eingeführt. Kleinstmögliche, nicht weiter unterteilbare Elemente sollten in der untersten Ebene definiert werden.
Prozesse und Tools
Wenn man den atomaren Ansatz wählt und nach und nach mit den aufeinander aufbauenden kleinsten Elementen — den Atomen — beginnt, erhält man erst spät im Projektverlauf vorzeigbare Seiten. Voraussetzung dafür ist, dass Moodboards, Scribbles oder Photoshop-Screens, die die Visual Design Richtung andeuten und aus meiner Sicht immer noch eine Berechtigung haben, zur Abstimmung anfangs ausreichen. Je weiter das Projekt fortgeschritten ist, desto mehr amortisieren sich die anfangs höheren Aufwände zum Projektstart (Schätzle, 2015b).
Ein Projekt aus UX-Sicht gliedert sich in die Disziplinen User Research, Content/IA, UI, IxD, Visual Design und Entwicklung/Umsetzung.
Im Verlauf eines Projekts sind unterschiedliche Methoden anzuwenden, deren Zuständigkeit sich jeweils auf diese Disziplinen verteilt. Aus Budget-, Kompetenz-, Zeit- oder anderen Gründen können und werden natürlich niemals alle relevanten Methoden in einem Projekt angewandt, man sollte sich aber zumindest damit beschäftigen und über deren Relevanz und Nutzen für das Gesamtergebnis im Klaren sein. Mit der passenden Methode zur richtigen Zeit lässt sich im Projektverlauf unnötiger Ressourcenverbrauch vermeiden, weil weniger „rumgewurschtelt“ werden muss und Entscheidungen auf fundierten Erkenntnissen getroffen und begründet werden können.
Methodisches Vorgehen
Die Disziplinen UI und Content Modeling, Visual Design und Multiscreen Konzeption werden sich zukünftig noch stärker überschneiden. Projekte werden komplexer, alle Disziplinen und Themenbereiche müssen zur richtigen Zeit berücksichtigt und bearbeitet werden.
Im Projektverlauf müssen (kompakt formuliert) nacheinander und iterierend das Thema erkannt, priorisierte Ausgabekanäle und die Inhaltsmodelle definiert werden. Ausgehend vom Inhalt lassen sich weitere Details festlegen und bearbeiten (Struktur, Content Wireframes, Inhaltserfassung, Schnittstellen). Wenn diese Parameter bekannt sind, können unter Berücksichtigung des Baukastenprinzips Workflows modelliert und Ausgabe Interfaces bestimmt und gestaltet werden. Da sich alles um den Inhalt dreht, könnte ein zentraler Content (Management) Hub den erwähnten Gedanken Rechnung tragen.
Zwei Checklisten mit Informationen und Tipps zum Projektverlauf können hier heruntergeladen werden: Multiscreen Projekt Workflow und Projektphasen.
Zentraler Content (Management) Hub
Das Konzept basiert auf der bereits erwähnten Vierteilung der Projektbestandteile Inhalt, UI, Workflows und Schnittstellen. Der Content Editor (also der Nutzer der Software) steht dabei im Vordergrund. Die Datenstruktur für das Backend wird entsprechend der Inhaltsmodelle definiert. Das Editor Interface besteht aus einem auf der Datenstruktur basierenden Formular. Im zentralen Content Hub können die Inhalte konsolidiert abgelegt und verwaltet werden.
Das Inhaltsmodell definiert das UI Modell.
Wenn am Anfang ein Content Audit durchgeführt und anschließend die Inhaltsmodelle erstellt werden, lassen sich daraus die passenden UI Formular-Elemente für das Backend (und die UI Elemente für das Frontend) ableiten. Durch die Korrelation von Inhalt und UI definiert das Inhaltsmodell im Grunde auch schon das Backend und die Frontendausgabe.
Themenrelevanz
Das (Projekt) Thema ist relevant bzgl. Begrifflichkeit für das Inhaltselement und das Labeling im Backend bzw. dem Interface für die Erfassung und Verwaltung der Inhalte (Unit, Domäne, Taxonomie). Es ist ein Unterschied, ob es sich um Kochrezepte, technische Produkte, Restaurants, geschäftliche Adressdaten oder einen Urlaubsantrag handelt. Die Sprache und dementsprechend auch die Bezeichnung der Labels an den Inhaltselementen im Inhaltserfassungs-System (klassischerweise ein CMS-Backend) wird eine andere sein.
Auf Basis der jeweiligen Unit- oder Themen-spezifischen Inhaltsmodelle ergibt sich eine Art spezialisierter Content Manager passend zum definierten Anwendungsfall. Zu jedem definierten Inhaltstyp erhält der Anwender die korrelierenden UI-Formular-Elemente. Ein Inhaltsmodell für ein Kochbuch (Rezept) sieht deutlich anders aus als die Inhaltsmodelle für einen Produktkatalog mit E-Shop-Funktionalität, eine Kalenderapplikation oder eine klassische Nachrichtenpublikation.
Mit einem Formulargenerator lassen sich die Formularelemente generisch nach dem Baukastenprinzip zum Eingabe-Interface kombinieren. Durch das Inhaltsmodell steht die vordefinierte Struktur des Formulars fest (atomare Korrelation von Inhalt, Backend-UI und Frontend-UI), könnte jedoch bei Bedarf um eigene Module und Templates erweitert werden.
Unabhängiges Eingabe-Interface
Die Datenübernahme in den Hub kann grundsätzlich unabhängig vom Eingabe-Interface geschehen. Die Inhaltsobjekte müssen lediglich entsprechend konvertiert und den einzelnen Inhalts-Elementen zugeordnet werden (Content Mapping).
Das grundsätzliche UI für das Eingabe-Interface ist durch die Strukturdefinition der Inhaltstypen festgelegt, nicht jedoch das exakte Styling (das ist flexibel). Zudem können eigene UI Elemente jederzeit ergänzt werden. Die Ausgabe ist davon ebenfalls unabhängig und kann in einem eigenen oder fremden Kanal erfolgen. Das Styling der Inhaltselemente im Frontend ist unabhängig vom Backend. Lediglich die Struktur (Chunks der Inhaltsobjekte, nicht deren Reihenfolge) ist vorgegeben. Der Ansichtsmodus im Backend ist „nur“ eine „Content Structure Preview“. Die Reihenfolge, Anordnung und Darstellung der Inhalts-Elemente geschieht im Client bzw. Ausgabemedium.
Durch die klare Strukturierung und Gliederung der Inhaltstypen (konkrete gefüllte Inhaltstypen sind Inhaltsobjekte) sind die Daten grundsätzlich plattform- und touchpointunabhängig und können in beliebigen Ausgabemedien und Kanälen dargestellt werden. Die Ausgabe wird im Backend konfiguriert (über Regeln bzgl. der jeweiligen Nutzungskontexte, die wiederum Vorgaben bzgl. Kanal, Layout und Medium und auch Interaktion beinhalten).
Dreistufiger Content Hub
Der Content Hub ist dreistufig aufgebaut [vgl. drei Phasen in Abbildung “Next Generation Information Experience”]. Man kann Inhalte erstellen, erfassen und ausgeben, wo und womit man möchte.
Für die Ausgabe ist eine entsprechende Schnittstelle erforderlich (also z.B. Inhaltserfassung im Formular bzw. dem CMS-Interface des Content Hubs und Ausgabe in Wordpress, Flipboard oder jedem anderen Kanal). Es ist auch denkbar Inhalte in einem beliebigen System zu erfassen (Step 1, flexibles Eingabe-Interface) und diese nach dem Mapping des Inhalts im Content Hub (Step 2) wiederum flexibel auszugeben (Step 3).
Theorie und Praxis kombinieren
Ich träume von einem Tool, mit dem sich Prozesse und Methoden aus Content Modeling und UI Architektur vereinen lassen, weil es dann als Schnittstelle dient. Es bringt die Theorie und die Methoden mit der Praxis zusammen und liefert einen konkreten Nutzen für das Projekt.
Wenn ich Content Modeling direkt im oder mit dem Content (Management) Hub durchführen kann, erhalte ich quasi automatisch (generische, automatisierte, aber individualisierbare) Arbeitsergebnisse, die ich für das Interface und die Darstellung beim Rezipienten verwenden kann. Man muss alles nur einmal machen und hat direkt ein konkretes Ergebnis.
Eine Modeling-Software passend zum Baukastenprinzip.
SETU als Tool für zukunftsfähigen Inhalt
Basierend auf den vorgestellten Ideen haben wir bei der SETU GmbH ein Konzept für einen solchen „Content Management Hub“ entwickelt, das wir unser nächstes SETU (3.0)-Release einfließen lassen. Damit lassen sich Content Management Apps für verschiedene Themenschwerpunkte realisieren.
Der Content Architekt hat weitgehend freie Hand bei der Strukturierung von Datenkörpern. Die Software bietet eine große Bibliothek an vordefinierten (und erweiterbaren) Formular- und Ausgabeelementen und unterstützt innerhalb eines Datenmodells iterierende Elemente (auch komplexere Strukturen wie Text mit Bild) sowie Beziehungen und Beziehungsarten zu anderen Elementen. Es bietet Funktionen für die Erstellung und Verwaltung von Sprach- und Marktspezifischen Inhalten wie Vererbung und Workflow Unterstützung. Bestehende Plattformen können um frei definierbare Workflows in der Kundenkommunikation ergänzt werden.
Außerdem lassen sich regelbasierte und verknüpfte/verwandte und individuell personalisierte kontextbasierte Inhalte bereitstellen. Kontextrelevanz lässt sich über Regeln und Metainformationen erkennen und nutzen (personalisierte Inhalte, abhängig u.a. von Login, Profil, Internetgeschwindigkeit, Gerät, Ausgabemedium, Kanal, etc.). Die abgegebenen strukturierten Informationen lassen sich in beliebige Plattformen und Kanälen integrieren.
Quo vadis Inhalt und Interface?
Für die Zukunft empfiehlt es sich Informationen in jeglicher Ausprägung baukastenartig zu planen und zu erfassen, um mit den richtigen Tools möglichst ohne große Zusatzaufwände Informationen auf allen erdenklichen Kanälen publizieren zu können. Die passenden Prinzipien, Methoden und Prozesse sollten verständlich beschrieben, etabliert und angewandt werden. Aus dieser Überzeugung heraus zerlege ich möglichst alle Projektbestandteile in generische Einzelteile, die sich später wieder leicht zusammensetzen lassen. Ganz ähnlich wie man das von LEGO kennt.
Wie es weitergeht und Details zum Content und UI Mapping sind im Folgeartikel nachzulesen und den Slides zum Vortrag auf der Usability Professionals 2016 zu entnehmen.
Anmerkung: Der Artikel ist entstanden für den Tagungsband der Usability Professionals 2015 Konferenz und den dazugehörigen Vortrag. Die Folien zum Vortrag sind auf Slideshare einzusehen.
Quellen
- Baldwin, S. (2010). Doing a content audit or inventory. http://nform.com/blog/2010/01/doing-a-content-audit-or-inventory/ (14.04.2015)
- Frost, Brad (2012). BDConf: Stephen Hay presents Responsive Design Workflow. http://bradfrost.com/blog/mobile/bdconf-stephen-hay-presents-responsive-design-workflow/ (03.02.2015)
- Frost, Brad (2013a). Atomic Design. http://bradfrost.com/blog/post/atomic-web-design/ (14.05.2015)
- Frost, Brad (2013b). Interface Inventory. http://bradfrost.com/blog/post/interface-inventory/ (07.01.2015)
- Frost, Brad (2015). I Have No Idea What The Hell I Am Doing. http://bradfrost.com/blog/post/i-have-no-idea-what-the-hell-i-am-doing/ (03.06.2015)
- Gibbon, C. (2015). Cleve Gibbon Website: Content Modeling. http://www.clevegibbon.com/content-modeling/ (04.02.2015)
- Lovinger, R. (2012). A List Apart. Content Modelling: A Master Skill. http://alistapart.com/article/content-modelling-a-master-skill (11.02.2015)
- Nagel, W. (2012). Usability Professionals 2012, Konstanz: Multiscreen Experience Design. http://de.slideshare.net/wolframnagel/multiscreen-experience-design-september-2012-muc-up12 (12.09.2012)
- Nagel, W. (2014a). Next Generation Information Experience: Trends und Herausforderungen von morgen. https://wolframnagel.wordpress.com/2014/12/09/next-generation-information-experience-trends-und-herausforderungen-von-morgen/
- Nagel, W. (2014b). Next Generation Information Experience: Trends und Herausforderungen von morgen. EXD Prozess. https://wolframnagel.wordpress.com/2014/12/09/next-generation-information-experience-trends-und-herausforderungen-von-morgen/#EXD_Prozess (13.04.2015)
- Nagel, W., Fischer V. (2013). Multiscreen Experience Design. Prinzipien und Muster für die Strategieenwticklung und Konzeption digitaler Services für verschiedene Endgeräte. Schwäbisch Gmünd. digiparden GmbH.
- Schätzle, A. (2015a). Modulare Systeme. In: PAGE Ausgabe 02.15. S. 24f
- Schätzle, A. (2015b). Im Teilchenbeschleuniger. In: PAGE Ausgabe 06.15. S. 82ff
- Skjoldan, R. (2013). Editor Experience Design. http://rasmusskjoldan.com/post/64666373967/editor-experience-design (05.11.2013)
- Sunrise (2015). Sunrise Blog: “Sunrise Is Taking Over Your Apple Watch”. http://blog.sunrise.am/post/120436887179/sunrise-is-taking-over-your-apple-watch (16.06.2015)
- Twitter (2015). Website Card. https://business.twitter.com/website-card-overview (16.06.2015)
- UX Booth (2014). Experiencing the Author Experience. http://www.uxbooth.com/articles/experiencing-the-author-experience/ (11.12.2014)
Über den Autor
Wolfram Nagel ist UX Designer, UI Architekt und Content Designer. Als Senior User Experience Designer bei TeamViewer kümmert er sich um die Themen User Experience und User Interface Design in enger Zusammenarbeit mit seinen Kollegen aus dem Produktmanagement und der Entwicklung.
Davor war er lange Zeit als Head of UX bei der SETU GmbH für Konzeption und Gestaltung verantwortlich und betreute interne und externe Web- und Software-Projekte in den Bereichen Content Design, UI Architektur und Visual Design im engen Austausch mit Frontend- und Backend-Entwicklern. Er hält Vorträge zu diesen Themen und ist Autor des Buchs “Multiscreen Experience Design”, sowie der englischen überarbeiteten Ausgabe „Multiscreen UX Design“. Außerdem ist er Mit-Initiator des ADC-prämierten Design Methoden Finders.
