2012-08-23

Usability-Tests mit Kindern durchführen 3: Der Abschluss

Mit Kindern kann die Methode des Lauten Denkens nicht wie bei Erwachsenen angewendet werden. Gründe hierfür sind:

  • Wortschatz
  • Schüchternheit
  • Angst etwas Falsches zu sagen
  • "Erwartungen" der Erwachsenen möchten erfüllt werden


Daher muss zum Auswerten der Testergebnisse sehr genau hingeschaut werden:

  • Um herauszufinden, wie sehr einem Kind ein Produkt oder Programm gefallen hat, muss unbedingt auf die Gestik und Mimik geachtet werden. Lächeln, Lachen und Vorbeugen geben positives Feedback, frowns, sighs, yawns und Abwenden sind negatives Feedback. Das Körpersprachen-Feedback ist aussagekräftiger, als das, was die Kinder sagen, da Kinder es den fragenden Erwachsenen in der Regel recht machen wollen.
  • Ältere Kinder können bereits die Software bewerten. Die Autoren von "Guidelines for Usability Testing with Children" schlagen eine vertikale Skala mit einem lachenden Smiley am oberen und einem weinenden Smiley am unteren Ende vor.
  • Diese Kinder freuen sich häufig auch, von ihren eigenen Ideen und Verbesserungsvorschlägen zu erzählen wenn sie danach gefragt werden.  

  • Nach dem Test sollte der Testleiter unbedingt noch mal betonen, wie wichtig dieser Test war und wie sehr der Proband ihnen geholfen hat.
  • Als Belohnung sollten neben Bezahlung auch Geschenke, wie Gutscheine, Spiele oder Bücher angeboten werden.


Usability-Tests mit Kindern durchführen 2: Der Test

Während der Testphase ist auf folgende Punkte zu achten:

  • Vorschul-Kinder sollten ein wenig Eingewöhnungszeit an den Computer bekommen. Der Testleiter könnte mit dem Finger auf den Monitor zeigen und das Kind bitten, mit der Maus an diese Stelle zu fahren.
  • Kinder sollten das Produkt in freier Exploration nutzen. Älteren Kindern können allerdings auch konkrete Aufgaben gestellt werden. Wichtig hierbei:
    • Einzelne Aufgaben müssen kleiner sein, als man sie erwachsenen Probanden stellen würde.
    • Der Testleiter muss sicherstellen, ob das Kind die Aufgabe auch wirklich verstanden hat...
    • ... und die Aufgabenstellung wiederholen, falls deutlich wird, dass das Kind diese vergessen hat.
  • Kinder sind es in der Regel gewohnt, neue Produkte nicht alleine, sondern gemeinsam mit Freunden, Geschwistern oder Eltern auszuprobieren. Daher stellen sie auch häufig Fragen. Der Testleiter muss auf diese Fragen mit geschickten Gegenfragen reagieren. Der Ball wird (in einem vernünftigen Rahmen) so lange hin und her gespielt, bis das Kind eine Vermutung äußert.
  • Der Testleiter sollte die Probanden nicht fragen, ob sie das Spiel (etc.) spielen wollen. Die Kinder könnten 'nein' sagen. Besser zB. "Wir machen jetzt ...".
  • Sollte das Kind unruhig und unkonzentriert werden, sollte eine kurze Trink-/Toilettenpause eingelegt werden.
  • Aufgaben sollten ion Form von konkreten Arbeitsanweisungen formuliert werden.
  • Die Reihenfolge der Tests sollte insbesondere bei Kindern pro Proband variieren, da sich hier die fehlende Konzentration am Ende der Session deutlich stärker bemerkbar macht.
  • Motivation beim Kind wird auch durch positives Feedback des Testleiters gefördert.

2012-08-17

Designing Games for Non-Gamers

Dennis Paiz-Ramirez, Sarah Chu, Allison Salmon, and Belinda Gutierrez in User Experience Magazine: Volume 10, Issue 4, 2011


Tutorials: Too Much or Not Enough?

They tested their prototype of a real life simulation game with gamers an non-gamers and a pattern began to emerge:
Ann, the more experienced gamer, was willing to explore; Betty [familiar with computers but with little video game experience] was hesitant to click on anything before confirming it was the right action. [...] We learned that the tutorial should be explicit about what players can do in the game and should explain what happens when a player performs a game action. We also need to allow users to skip the tutorial and explore the game if they feel comfortable doing so.
I think it is import to tell the user, that she can "skip the tutorial and explore the game [AND can] feel comfortable doing so". -- Whatever tell means in this context. -- Otherwise the user might not trust that she can explore it without reading through all the tutorial stuff.


Conventions: Is That Supposed to Mean Something?

They have grayed-out non-clickable buttons, but:
it wasn't enough to follow web standards, especially when the target audience has little familiarity with digital media.
So they decided to not display buttons until they are introduced.


Content: Missing the Point

Too many feature, that are not directly connected to the main goal of the game, distracted the user from the main goal. Also, the head-up display became overcomplicated.
Featuritis -- who does not know the problem, but everybody runs into it from time to time -- everybody!


2012-08-15

Wohnen der Zukunft

Interessant: Im November 2010 habe ich hier von meinem Besuch beim World Usability Day berichtet: WUD2010HH: Living Place Hamburg 

Zu dem Zeitpunkt war das Projekt Living Place Hamburg noch relativ frisch (gestartet im Januar 2009) und viele Ideen waren noch Ideen.

Jetzt ist die Modellwohnung der Zukunft schon ziemlich ausgereift und bewohnbar.
Ein Beitrag bei Galileo (ab etwa Minute 8:30) zeigt die Wohnung im Einsatz.

In meinem neuen Projekt "Vernetztes Wohnen im Quartier" planen wir, uns die Wohnung einmal anzuschauen - ich bin gespannt.



2012-08-06

Josh Clark - Buttons are a Hack


The New Rules of Designing for Touch - BD Conf, Sept 2011 (vimeo video)

Description:
Fingers and thumbs turn design conventions on their head. Touchscreen interfaces create ergonomic, contextual, and even emotional demands that are unfamiliar to desktop designers. Find out why our beloved desktop windows, buttons, and widgets are weak replacements for manipulating content directly, and learn practical principles for designing mobile interfaces that are both more fun and more intuitive. Along the way, discover why buttons are a hack, how to develop your gesture vocabulary, and why toys and toddlers provide eye-opening lessons in this new style of design.

My notes from the talk:


  • Fitt's Law
  • Let people be lazy
  • Step 1: Gestures as shortcuts for buttons
    • How to teach gestures?
    • How to find a uniform set of gestures?
  • Buttons are (visual) abstraction - they work in the distance - they are workarounds
  • Norman's new book: Living with complexity
    • Social understanding is not synchronized
    • UI conventions are social construction
  • Labels help, but better doesn't need them at all
    • Don't touch a button/label: Tap the content
  • Instructions at start of the app -> NO - no one wants to learn HOW to use before WHY to use ??
    • Nature itself doesn't have labels or instructions - but is an complex interface
  • embrace the UI metaphor you use
  • Play more video games to learn:
    • Coaching: time by time, don't overdo it, show feature hints when needed
    • Leveling up: Pause action, show how to use new feature, continue AFTER user SHOWS she has learned -> so divide your app into levels
    • Power ups: gestures are the keyboard shortcuts of touch, but they are hidden, so tell your users
  • Uzu (app): multitouch gestures: ten fingers - ten modes - no buttons or labels at all
  • no leadership yet for finding uniform set of gestures


2012-07-06

Die Zukunft von Mobile

Die Zukunft von Mobile heißt nicht Phone oder Tablet;
die Zukunft von Mobile bedeutet, sich diverser Umgebungen bewusst zu sein.
(Menschen lassen sich nicht auf Finger und Augen reduzieren ;)

Bildschirme sind billig, sie werden überall sein;
Personal Devices brauchen eine einheitliche Schnittstelle, dann können wir unsere Aufgaben über mehrere Bildschirme verteilen. Was ist das für ein Nutzererlebnis? Frage an die User Experience Spezialisten.

Mobile und Cloud Computing: Toy Story wurde in 800.000 Rechner-Stunden erzeugt - über die Cloud ginge das in fünf Minuten.

Die Interaktion zwischen Personal- und Mobile Devices bringt völlig neue User Experience; Beispiel: Nike plus.


Offene Punkte für die Zukunft von Mobile

  • Design, Hardware und Software müssen eng zusammenspielen.
  • Umdenken: Geräte sollen auf Menschen reagieren, nicht umgekehrt.
  • Neue Entwicklungsprozesse: Dokumentation, Produktion und Nutzung liegen verdammt eng beieinander; es geht nicht mehr um Bürosoftware, die man später den Mitarbeitern einfach vorsetzt.
  • Orts- und kontextabhängige Nutzung rückt noch weiter in den Vordergrund. 
  • Computer müssen Content filtern und verarbeiten und dürfen nur relevanten Content an den Nutzer liefern. Ansonsten ist die permanente Anwesenheit von Technik nicht akzeptabel.




In his opening keynote at the Design for Mobile conference in Chicago IL,. Jonathan Brill discussed several future scenarios for mobile user experience and their potential.


What Brill is focused on now: Multi-display/device interaction, 3D and gestural interfaces, glasses 3D display, Radios in things besides phones, positional and visual search.
Voice recognition, roll-up displays, and mesh networks have been “three years away” for a long time now.
When investigating, predicting, developing new technologies, laughter and delight signal a business opportunity.



2012-07-02

HTML5 und Mobile Apps

Warum mögen sich HTML5 und Mobile Apps nicht?


Immer wieder hört und liest man, dass HTML5 keine brauchbare Alternative zu nativen Apps ist - Hauptproblem: Performance!

So hat sich jetzt zum Beispiel angeblich auch Facebook dazu entschlossen, ihre iOS App noch einmal von Grund auf neu zu entwickeln (Facebook Abandoning HTML5 to Speed Up iOS App).

Auf der anderen Seite schafft es aber zum Beispiel ZaptoLab das beliebte Cut the Rope auf HTML5 / JavaScript zu portieren (Behind the Scenes). - Zwar mussten sich die Entwickler sehr auf die Performance konzentrieren, aber es ist ihnen gelungen.

Nun frage ich mich, ob die Performance-Probleme durch die Zwischenschicht zwischen nativ und HTML zustande kommen, ob die meisten HTML-Apps einfach schlecht entwickelt sind oder ob die Hardware der mobilen Geräte der ausschlaggebende Grund sind.



2012-07-01

Mobile & UX


Kleine Auszüge aus Jared Spool Mobile & UX: Inside the Eye of the Perfect Storm (Video) auf der Mobilism 2011


Sturgeon's Law


Warum sind 90 Prozent aller Mobile-Anwendungen Mist?
90 Prozent von allem ist Mist!


Marktreife


Das generelle Erlebnis ist wichtiger als neue Funktionen. 
Nutzer sind von einfachen Lösungen begeistert.


Das Kano Model


Kano fragt: 
Wann lohnt es sich, den Nutzer glücklich zu machen?
Das Kano-Model verrät, wann etwas ein Highlight ist und wann etwas zu den Grunderwartungen gehört.

Eine Achse beschreibt die User-Zufriedenheit von entzückend bis frustrierend, die andere die nötigen Kosten
Es spielt bei allen Bemühungen aber keine Rolle wie weit man geht, wenn die Grunderwartungen nicht erfüllt werden - diese Feature müssen IMMER vorhanden sein. Für ein langlebiges Produkt ist hierbei zu bedenken, dass die Grunderwartungen über die Zeit zunehmen. Was heute noch entzückt, kann zum Beispiel so hilfreich sein, dass es in Zukunft schon  zu einer erwarteten Basisfunktion wird.


"The Perfect Storm"


UX-Teams aufzubauen, die in diesem Rahmen arbeiten, ist sehr schwierig. Teams, die herausragende User Experience bauen möchten, brauchen die verschiedensten Fähigkeiten wie zum Beispiel Schreiben, Informatins-Architekturen, Design-Prozess-Management, User Research Techniken. Darüber hinaus muss es ein Verständnis der verwendeten Technologie, ROI, Soziale Netze, Marketing, Analytics, Geschäftswissen, Story-Telling und weiterem geben.


Ziel ist es, in Sturgeon's Law zu investieren und sich auf das Nutzererlebnis zu konzentrieren, statt an Technologie und Features zu denken.
Basisfunktionen müssen erfüllt werden und darüber hinaus sollten einige Highlights eingebaut werden.



2012-06-20

Nicht immer Responsive Web Design


Responsive Web Design ist in aller Munde und wird derzeit sehr stark gehyped. Auch Luke W ist Befürworter von Responsive Web Design - dennoch hatte er gute Gründe für die mobile Variante von Bagcheck ein eigenes Interface zu entwickeln. Diese Gründe liefert er in seinem Blog-Post "Why Separate Mobile & Desktop Web Pages?", die ich hier kurz aufgreifen möchte:

Oberstes Gebot bei dem Projekt war Site Performance und Geschwindigkeit. Unter diesen Prämissen - und der generellen Philosopie: "Nur so viel wie nötig" - findet Luke vier Gründe:


Sourcecode Reihenfolge


Der Kern von Responsive Web Design ist die Auslieferung einer einzigen (HTML-) Website-Variante an alle Geräte. Die Anzeige des Contents passt sich dann entsprechend den Möglichkeiten des Gerätes an (in der Regel durch CSS gesteuert).

HTML Markup hat aber eine Reihenfolge, die bestimmt, in welcher Reihenfolge was gerendert wird. Diese kann natürlich mittels JavaScript manipuliert werden - aber dies zuverlässig für alle Geräte umzusetzen ist eine herausfordernde Aufgabe.

Ein einfaches Beispiel ist ein Site-weites Navigationsmenü. Während es auf Desktop-Größen in der Regel oben angeordnet ist, ist es für mobile Geräte, insbesondere in Smartphone Größe üblich, diese Menüs ans Ende der Seite zu rendern.


Medien


Responsive Web Design setzt sich auch mit Medien auseinander. Grafiken und Videos werden auf kleineren Displays kleiner dargestellt. Allerdings ist skalieren hier nicht unbedingt die beste Wahl. Erstens werden dabei unnötig Große Dateien übertragen (gerade an mobile Geräte mit evtl. nicht besonders schneller Anbindung). 
Anm.: Hier kommt zum Beispiel auch die iOS Retina--Display Diskussion ins Gespräch, da es sich für diese Geräte anbietet - genügend Bandbreite vorausgesetzt - hochauflösende Grafiken nachzuladen. (Siehe z.B. What the New iPad’s Retina Display Means for Web Developers. - Danke für den Tipp Moritz)

Zweitens kann es durchaus sinnvoll sein, dass man die Medien für unterschiedliche Display-Größen unterschiedlich aufbereitet: Große Grafiken mit vielen Details vs. kleine Grafiken mit weniger Details, also einem anders gewählten Ausschnitt.


URL-Struktur


Anm. vorab: Wie ich in Mobile und Content oder besser Content vs. Mobile? geschrieben habe, gibt es nur ein Web und ein und der selbe Content sollte auch unter ein und der selben URL zu erreichen sein. Aber:

Es gibt Situationen, in denen eine eigene URL-Struktur für kleinere Screens durchaus Sinn ergibt: Luke nennt als Beispiel eine Seite mit User-Content, Kommentaren dazu, Updates und "Likes". Dies passt alles zusammen gut auf eine Desktop-Seite und ist zum Beispiel unter der URL bagcheck.com/bag/7811 zu erreichen. Für kleinere Bildschirme ist es aber durchaus sinnvoll, einige der Informationen auf Unterseiten auszulagern, die dann unter den URLs bagcheck.com/bag/7811/updatesbagcheck.com/bag/7811/comments und bagcheck.com/bag/7811/likes zu erreichen sind.


Anwendungsdesign


Ein letzter entscheidender Punkt, der zu bedenken ist, ist folgender: Auf kleinen Displays kann es sinnvoll sein, längere Tasks von einer Seite auf mehrere zu verteilen.



2012-06-15

Drei wesentliche Attribute eines UX-Teams

Jared Spool über die drei wesentlichen Attribute eines effektiven UX-Teams in Dawning of the Age of Experience:

1. Vision

Kann jeder aus dem Team beschreiben, wie es sich anfühlen wird, wenn man ihr Produkt in fünf Jahren verwendet?

2. Feedback

Es muss Teammitglieder geben, die die Zielgruppe persönlich in direkter Interaktion mit dem Produkt erlebt haben. Minimal-Ziel: 2 Stunden Userbeobachtung jeweils innerhalb von sechs Wochen. Die besten Firmen machen dies wöchentlich.

3. Kultur

Werden Mitarbeiter für Designfehler belohnt? Jeder Fehler birgt die Möglichkeit etwas zu lernen: Was haben wir über unsere Nutzer gelernt? Über unser Produkt? Über uns selbst?


2012-06-12

Keep it Simple. At First. - Designing spielbasierte Tools für Kinder

Sarah Clue und Constance Steinkuehler beschreiben in "UX User Experience, Volume 10, Issue 1, 2011" (S.28ff), wie die World of Worcraft Entwickler es geschafft haben, das Interface so zu gestalten, dass es für Einsteiger einfach und übersichtlich ist und für erfahrene Spieler die notwendige Komplexität bietet, um alle benötigten Funktionen abzubilden.

  1. Das Interface ist beim Einstieg in das Spiel einfach gehalten und bietet nur die notwendigsten Funktionen. So können die Spieler am Anfang zum Beispiel einfaches Herumlaufen üben.

  2. Informationen und Funktionen werden erst nach und nach eingeführt - wenn der Spieler an entsprechende Stellen kommt, an denen er sie benötigt.

  3. Die Menge an geschriebenen Informationen ist auf ein Minimum reduziert. Es würde den Spieler eher stören, wenn am Anfang jede Minute ein neues Tutorial-Fenster aufpoppen würde.

  4. Individualisierung des Interfaces ist möglich: Spieler können selbst Interface-Addons entwickeln und installieren - je nach Bedarf und individuellem Gameplay. Dies optimiert nicht nur die Effizienz beim Spielen sondern fördert gleichzeitig auch die Community.


2012-06-05

Die Sieben Tödlichen Mythen über Mobile

Gestern Abend gab es zwei sehr interessante Vorträge bei der Interaction Design Association Hamburg.

Josh Clark, author of "Tapworthy: Designing Great iPhone Apps" and "Best iPhone Apps", and Karen McGrane, author of "Content Strategy for Mobile," (coming in 2013), will each give a thirty minutes presentation talking about mobile usage, design and content creation.

Josh Clark (http://www.globalmoxie.com/) hat über "The Seven Deadly Myths of Mobile" gesprochen. Anschließend Karen McGrane (http://www.karenmcgrane.com/) über „Adapting Ourselves to Adaptive Content“.

Zunächst zu den Sieben Tödlichen Mythen über Mobile:

A set of persistent myths are driving the development of mobile experiences that frustrate more than delight. "Info snacking." "The distracted, rushed mobile user." Those behaviors don't always, or even usually, exist, yet too often we design solely for those contexts, creating mobile apps as lite versions of their desktop counterparts. Instead, mobile apps should almost always do MORE than their desktop counterparts. Josh Clark explains the difficult craft of designing simple interfaces for complex mobile apps, sharing techniques for future-friendly mobile efforts and, along the way, debunking seven stubborn mobile myths.

Mythos #1: Mobile-Users sind immer in Eile - sind quasi IMMER auf dem Weg zum Bus


Ebay verkauft täglich Autos über ihre mobile App, also gibt es wohl doch User, die am Smartphone sitzen und Zeit haben sich mit dem Content in Ruhe zu beschäftigen.

  • 28% der mobile Users in den USA nutzen (fast) ausschließlich mobile Geräte. 
  • 11%, wenn man nur erwachsene User betrachtet.

Mobile != In Eile


Mythos #2: Mobile = Weniger


Schon mal auf einer smartphone-optimierten Website gewesen, deren Content sich perfekt an die Displaygröße angepasst hat? Dann aber den entscheidenden Menüpunkt nicht gefunden (weil der Anbieter der Meinung war, dass die Mobilen-User sich nicht dafür interessieren)? Ganz unten findet man ja meist einen Link „Full Desktop Version“. Dann hat man zwar eine nicht leserliche minikleine Seite auf dem Screen, aber irgendwie bekommt man es schon hin - durch vieles scrollen und zoomen - dann doch den Menüpunkt zu finden, zu bedienen und schwupp, nur wenige genervte Minuten später hat man endlich die Infos, die man gleich hätte haben können, wenn der Anbieter den Menüpunkt einfach auch in die mobile Version der Website gepackt hätte.

Der Fehler ist, dass Kontext und Vorsatz häufig verwechselt werden!
Der Mobile-User kann ja auch auf der Couch sitzen und nur zu faul sein, sich seinen Laptop zu holen oder ins Arbeitszimmer zu gehen.
Für uns heißt das, dass die mobile Version eines Services immer den vollen Umfang bieten sollte.

Mobile != Weniger


Mythos #3: Komplexität vermeiden und
Mythos #4: Extra Taps vermeiden


Die Regenschirm App verbirgt die Komplexität der Wettervorhersage in die einfache Antwort: „Brauche ich heute einen Schirm oder nicht?“ Sie kennen ihre User, denn dem Wetterinteressierten wären das zu wenige Informationen. Der Wetterexperte möchte eine komplexe App mit diversen Wetterdaten. Diese sollten ihm auch geboten werden. Komplexität sollte also nicht zwingend vermieden werden - sollte nicht als Gegenteil von Einfachheit verstanden werden. Ein komplexer Service kann ein einfaches Interface haben. Früher, als Webseiten noch Minuten zum Laden brauchten, war es wichtig, den User mit möglichst wenig Klicks zum Ziel zu bringen. Heute gilt dies nicht mehr. (Anm.: Ich habe auch mal gelesen, dass mehrere Klicks bei denen der User genau weiß, was sich hinter dem Link verbirgt, weniger störend empfunden werden, als ein einzelner Klick, bei dem der User dies nicht weiß. Wenn die iOS Human Interface Guidelines von Apple sogar davon sprechen, dass Scrollen auf einem Touch-Device zur positiven User Experience gehören, dann kann ein Tab wohl kaum störend sein.)

Das Interface eines Services sollte Komplexität in der Form verbergen aber bereitstellen, in der ein User an ein Problem herangeht. Frage -> Antwort -> Frage -> Antwort: Der User hat eine Frage: „Wie wird das Wetter die Tage?“ Die App antwortet: „sonnig“. Frage: „Wie wird das Wetter morgen genau im Verlaufe des Tages?“ Tab auf die zusammenfassende Vorhersage für morgen. Als Antwort wird dann der genaue Wetterverlauf gezeigt. Kaum ein User braucht wohl bei einer 5-Tages-Vorhersage bereits stundengenaue Werte.

Wenn jeder Tab neue und zufriedenstellende Informationen auf die aktuell gestellte Frage bietet, ist jeder Tab ein Gewinn für den User und trägt zur positiven User Experience bei.

Komplex != Kompliziert
Tab-Qualität sollte also vor Tab-Quantität stehen.


Mythos #5: Man braucht eine Mobile-Website


Es gibt so viele verschiedene Bildschirm-Formate im mobilen Bereich. Wie viel Aufwand will man betreiben, um all diesen Auflösungen gerecht zu werden? Und was ist mit den diversen anderen Kanälen? Warum nicht in ein paar Jahren auch auf dem TV stattfinden? Oder Radio. Sprachausgabe und -erkennung - Zukunft? Noch ist Apples Siri beta, aber bald wird es wohl Standard sein.

„Es gibt kein ,mobiles' Web.“ Es gibt nur Content. Einmal generierter Content muss für alle Kanäle passen. Content First, nicht Mobile First.

URL: Uniform Resource Locator (dt.: einheitlicher Quellenanzeiger). Schon mal einen Link auf mobile.mySite.com/... zugeschickt bekommen und auf einem großen Monitor geöffnet?
„Es gibt nur ein Web.“


Mythos #6: Mobile = App


„Eine App ist keine Strategie, es ist einfach nur eine App“ - ein Container!
Ein Produkt an sich ist meist nur Content.
Bruce Lee sagte einmal:
Wenn man Wasser in eine Tasse gießt, wird es zur Tasse. Gießt man Wasser in eine Flasche, wird es zur Flasche. Gießt man Wasser in eine Teekanne, wird es zur Teekanne.

Das Ziel: Ein Content, auf allen Geräten, immer synchron.


Mythos #7: CMS und API ist nur für Datenbank-Nerds


Ziel ist es nicht, das Design zu überdenken, wie der Content wo dargestellt werden soll. Ziel ist es, das Anlegen und die Speicherung des Contents zu überdenken. Wenn man alles richtig macht, dann ist Metadaten angereicherter Content, der über sinnvolle Schnittstellen angeboten wird, in jeglicher Form nutzbar - völlig unabhängig vom Präsentations-Layer.

Content as a Service


Dies war auch die Kernaussage von Karen McGrane über die Frage, wie wir uns anpassen müssen, um in der Zeit des „anpassbaren Contents“ Schritt halten zu können.


For years, we've been telling designers: the web is not print. You can't have pixel-perfect layouts. You can't determine how your site will look in every browser, on every platform, on every device. We taught designers to cede control, think in systems, embrace web standards. So why are we still letting content authors plan for where their content will "live" on a web page? Why do we give in when they demand a WYSIWYG text editor that works "just like Microsoft Word"? Worst of all, why do we waste time and money creating and recreating content instead of planning for content reuse? What worked for the desktop web simply won't work for mobile. As our design and development processes evolve, our content workflow has to keep up. Karen will talk about how we have to adapt to creating more flexible content.

Präsentations-unabhängiger, strukturierter und mit Metadaten angereicherter Content als Ausgangslage, um schnell auf allen Plattformen stattfinden zu können.
Von „Create Ones, Puplish Everywhere“ spannte sie den Bogen zu „Publish Once, Distribute Everywhere“. Umdenken ist gefragt.


Vielen Dank auch an FORK als Veranstalter.