Progressive

Enhancement
Moderne barrierefreie User Interfaces
in der interdisziplinären Entwicklung

Mirko Erwig, Teamleiter Online Development

Christian Oestreich, Teamleiter Konzeption und Informationsarchitektur
Vorgestellt

Mirko Erwig Christian Oestreich

Progressive Enhancement

★ Methode / Vorgehensweise
★ Dreistufige Anreicherung,
ausgehend vom kleinsten
gemeinsamen Nenner der
User Agents
Progressive Enhancement
★ Struktur / Inhalt > Aussehen > Verhalten
http://www.alistapart.com/articles/understandingprogressiveenhancement/

★ Abgrenzung zur „Graceful Degradation“

Erwartete Vorteile

★ Nutzer älterer / weniger

leistungsfähiger User Agents werden
nicht ausgeschlossen
★ Weniger Hacks, schlankerer Code,
kürzere Entwicklungszeit
Progressive Enhancement
Alles dazu bereits gesagt?
 †
Allgemein akzeptierte Methode,
zweitbeste Option oder gar tot?
Eric Eggert
Königsweg oder Sackgasse?
Thema relevant „nur“
für Webdesigner?
 Wir glauben

Code ist das Endergebnis

eines Prozesses mit
vielfältigen Ausprägungen.
Der Weg dorthin ist oft verschlungen.
 Der Webdesigner kann
die Methoden seiner Wahl
nicht immer autonom
bestimmen.
Prozesse: der blinde Fleck der Diskussion?
 Welche Prozesse?
★ Innerhalb des eigenen Teams
★ Abstimmung mit dem Kunden
★ Mit weiteren Projektbeteiligten
 Projektkonstellation hat
Auswirkungen auf die Wahl
der Vorgehensweise
★ Teil 1

Personen, Situationen und Prozesse

★ Teil 2

Praxisbeispiele vor dem Hintergrund

konkreter Projektsituationen
 Teil 1

Personen, Situationen
und Prozesse
 ?
Ignorance is Bliss
★ Wichtige Diskussion,
angestoßen von
Andy Clarke
(23.12.2009)
Zwei Hauptthesen

1. Kunde bekommt keine statischen JPGs

sondern einen (progressiv
angereicherten) HTML-Prototypen

2. Dass dies Darstellungsunterschiede bei

verschiedenen User Agents mit sich
bringt, wird dem Kunden gegenüber
nicht erwähnt.
Zwei Hauptthesen

1. Kunde bekommt keine statischen JPGs

sondern einen (progressively enhanced)
HTML-Prototypen

2. Dass dies Darstellungsunterschiede bei

verschiedenen User Agents mit sich
bringt, wird dem Kunden gegenüber
nicht erwähnt.
Gewünschter Effekt

★ Dem Kunden keine plattform- und

browserübergreifende Pixelgenauigkeit
suggeriert.
★ Es wird auch nicht thematisiert.
★ Der Kunde gibt deshalb frei, was er / sie
selbst auf dem eigenen Computer sieht.
Alles prima?

★ Klingt toll…
★ In der Praxis nicht immer unkompliziert
 1
Der Webdesigner –
die eierlegende Wollmilchsau
in der Agentur
Webdesigner Kunde
Theorie

Berater, Projektmanager,
Experte für UX, IA und IxD,
Webdesigner Screendesign,
Frontendentwickler,
Backendentwickler
Praxis

Prototyp
Eierlegende Wollmilchsau
Webdesigner
1 von 100
 Ausdifferenzierung
Motion
Designer Berater/ Das Problem mit der
Konzepter
Wollmilchsau:
Screen-
Es gibt sie so selten.
designer
Projekt-
Chef
manager
Und selbst wenn es sie
Frontend-
öfter gäbe: Das Prinzip
Entwickler Spezialist
Analytics,
skaliert schlecht mit
SEO, SEM,
etc. steigender Projektgröße.
Backend-
Entwickler
Konzeptionsprozess

Frontend-
Konzepter
Entwickler
 Frontend-
Konzepter
Entwickler

Denkt vom Idealfall Muss bei Progressive

des User Interface- Enhancement von
Verhaltens aus: unten nach oben
oben nach unten denken
 Frontend-
Konzepter
Entwickler

Kommunikation
Übersetzung des Top-Down Konzeptansatzes
in eine Umsetzung von innen nach außen
Kundenkontakt

Frontend- Wer steht im täglichen

Entwickler Kundenkontakt?
Kundenkontakt

Projekt- Wer steht im täglichen

manager Kundenkontakt?
Projektmanager

★ Üblicherweise kein Frontend-Entwickler

★ Oft nicht versiert in technischen Details
★ Progressive Enhancement als
potenzielles Projektrisiko
 Projekt- Frontend-
manager Entwickler

Kompetenztransfer:
optimale Argumentation nach außen
 2
Der Kunde –
eine Stimme oder Stimmengewirr?
Best Case in der Theorie

★ Ein Hauptprojekt-
manager auf
Kundenseite als
Ansprechpartner der Kunde
Agentur
★ Wird überzeugt
★ Regelt den Rest intern,
keine „Querschläger“
Praxis

★ Ein Hauptprojekt-
manager aus dem
Kunde
mittleren
Management
Praxis

★ Zahlreiche weitere
Projektbeteiligte aus
verschiedenen
Abteilungen
Kunde

★ Marketing, IT, Vertrieb,

Produktmanagement, etc.
Praxis

★ Projektbeteiligte mit
stark variierender
Kunde
Webkompetenz
★ Abteilungen oft mit
eigener Agenda
Praxis

★ Oberste Entscheider
auf Kundenseite nicht
im direkten „Zugriff“ Kunde
der Agentur
★ Häufig indirekte
Kommunikation
Kommunikationsströme

Webdesigner Kunde
 Sind beiderseits vielfältig
Motion Projekt-
Designer Berater/ beteiligte
Konzepter Projekt-
beteiligte

Screen-
designer Projekt-
Projektmanager Projektmanager
Chef beteiligte Chef
Agentur Kunde

Frontend- Projekt-
Entwickler Spezialist beteiligte
Analytics,
SEO, SEM, Projekt-
etc. beteiligte

Backend-
Entwickler
Was kann passieren, wenn
man einen angereicherten
Prototypen zeigt??
Verschiedene Mitarbeiter des Kunden sehen
unterschiedliche Dinge.
Und beginnen, darüber intern zu diskutieren.
Rezept von Clarke
Den Kunden im Unklaren lassen,
dass die Darstellung variiert.
 Was, wenn das in der
Kundendiskussion trotz alledem zum
Thema wird?
 Vorschlag Clarke
Gegenfrage an den Kunden:
„Pixelgenauigkeit oder neue coole Funktionen?“
 Seine These
Kunde will lieber coole Funktionen.
 Gegenthese
Kunde entscheidet sich für das,
womit er sich wohler fühlt.

Weitgehend gleiche Darstellung

 Variante
Den Kunden nicht im Unklaren lassen, sondern
bereits vorher „aufklären & erziehen“

Kann erfolgreich sein, muss aber nicht ;)

 Unser Vorschlag

Auf keinen Fall

verschweigen.
Situativ einschätzen
• Wie ist der Kunde intern strukturiert?
• Wofür ist der Kunde reif?
• Wie viel muss / kann man ihm plausibel
erklären?
 3
Externe Dienstleister oder Kunden-IT
für die Systemimplementierung
 Motion Projekt-
Designer Berater/ beteiligte
Konzepter Projekt-
beteiligte

Screen-
designer Projekt-
Projektmanager Projektmanager
Chef beteiligte Chef
Agentur Kunde

Frontend- Projekt-
Entwickler Spezialist beteiligte
Analytics,
SEO, SEM, Projekt-
etc. beteiligte

Backend-
Entwickler
 IT

Motion Projekt-
Designer Berater/ beteiligte
Konzepter Projekt-
beteiligte

Screen-
designer Projekt-
Projektmanager Projektmanager
Chef beteiligte Chef
Agentur Kunde

Frontend- Projekt-
Entwickler Spezialist beteiligte
Analytics,
SEO, SEM, Projekt-
etc. beteiligte

Backend-
IT

★ Oft andere Projektprioritäten

★ Sensibilität für Feinheiten des
Frontends unterschiedlich ausgeprägt
★ Mit Progressive Enhancement
vorproduzierte Templates werden nicht
entsprechend umgesetzt
★ Niedrige Priorität beim Bugfixing
Bemühungen können
versanden
Selbst bei klaren Absprachen und gut
dokumentiertem Frontend-Code
 Teil 2

Praxisbeispiele vor dem

Hintergrund konkreter
Projektsituationen
Drei Beispiele

★ Angereicherte Dropdowns
★ Abgerundete Ecken – oh no!
★ Medium-graceful IE6
 Fazit

Fingerspitzengefühl,
abhängig von Situation
und Projektstruktur
Kunde

Ein „starker“ und Gut argumentierbar

webaffiner mit Vorteils-
Ansprechpartner kommunikation

Stimmengewirr,
kein direkter Mögliches
Kontakt zu Projektrisiko
Entscheider
Projekt
Ressourcen und
Zeit knapp,
Fruchtbarer Boden
Performance sehr
wichtig

Imagelastig und
Schwerer
stark visuell
vermittelbar
getrieben
IT / externe Dienstleister

Frontend-Kom- Gemeinsame
petenz vorhanden? Sprache

Klare Absprachen
Sehr backend-
und Dokumentation
lastig?
besonders wichtig
Unsere Arbeitsweise

★ „Design in Code“

Sind offen dafür, passt aber selten zu

unseren Projekten und internen
Kompetenzen
Unsere Arbeitsweise
Toolbox – je nach Projekt:
★ Statische Wireframes
★ Interaktive Wireframes (kein Design)
★ Photoshop
★ Interaktive Mockups
(Code später nicht verwertbar)
Vielen Dank fürs Zuhören

Fragen, Ohrfeigen,
Schulterklopfer?
Fotonachweise (alle mit CC-Lizenz)

DorkyMum
http://www.flickr.com/photos/dorkymum/4345275339/

Valentin D.
http://www.flickr.com/photos/denicide/3076040648/

Marjan Krebelj
http://www.flickr.com/photos/nikio/3899114449/

John „K“
http://www.flickr.com/photos/johnkay/4048295113/

Sebastian Bergmann
http://www.flickr.com/photos/sebastian_bergmann/1436880351/