RWD: Unterschied zwischen den Versionen

Aus TopoWiki
Zur Navigation springen Zur Suche springen
Zeile 149: Zeile 149:
 
# Document for production
 
# Document for production
  
[Sphehen Hay @stephenhay: Responsive Design by Stephen Hayπ]
+
[Sphehen Hay @stephenhay: Responsive Design by Stephen Hay]
  
 
=== Vor- und Nachteile ===
 
=== Vor- und Nachteile ===

Version vom 14. September 2014, 23:18 Uhr

Responsiveweb.jpg
RWD Eisberg.png
RWD Workflow.png
ScreenSizes.png
AndroidFragmentation.png

Vergleich

Classic Responsive
First
  • Layout
  • Desktop-Page-Design
  • Design = Layout = Content
  • Semantic
  • Content

(* Mobile)

Internet als Layoutmedium (analog Print: Coverdesign) als Informationsmedium (analog Buchinhalt: Gliederung)
Sicherheit durch Design Dokument Schnelle Feedbacks & Teamwork
Content = Design = Layout unabhängig von Design & Layout
Design
  • Page Design & Graceful Degradation
  • Module Design: Atomic WebDesign mit StyleTiles
  • Mobile First & Progressive Enhancement
Layout Statisch Dynamisch
Phase 1 Ziele & Strategie & Konzeption Ziele & Strategie & Konzeption
Phase 2
  • Content Strategy
  • PIM Strategy -> Implementierung
Phase 3 Design: Vom Wireframe zum Photoshop-Design Design + Testing: Mobile Paper Prototyping
Phase 4 Coding Design + Coding + Testing: Mobile Low Fidelity
Phase 5 Testing Design + Coding + Testing: Mobile High Fidelity
Phase 6 Retour Design + Coding + Testing: Next Screen
Prinzip Do not fail! Fail fast!
Waterfall.png
Rwd.png
Problems too much talking and too little testing

Bildquelle: http://www.wsol.com/a-more-flexible-workflow/

Responsive

  • "Reagierend" auf die Bildschirmbreite
  • "Reagierend" auf die Bildschirmhöhe
  • "Reagierend" auf die Geräteklasse
  • "Reagierend" auf das Device
  • "Reagierend" auf die Übertragungsgeschwindigkeit
  • "Reagierend" auf die Bewegungsgeschwindigkeit
  • "Reagierend" auf den Content!

Mobile Conversion

Devicecommerce.png

Responsive Commerce

EC mobiletraffic.jpg

(Quelle: www.internetretailer.com, BITKOM)

  • Die Verkäufe per Mobile oder Tablet der Top500 E-Commerce Shops werden in 2014 um 80% gestiegen sein (84 Milliarden USD)
  • E-Commerce beträgt 10% am Gesamt-Verkauf / 50% davon per Mobile
  • Durchschnittlicher Warenkorb: 80 EUR
  • In DE (2013): 51% mobiles Internet, davon 85% Online-Shopper (BITKOM) (DeStatis)
  • 103 der Top500 E-Commerce Shops sind bereits "Responsive" (Zuwachs um 164%)
  • 35% of actual transactions happen from a mobile device
  • We discovered that almost 1 out of every 3 shoppers that started their shopping session on a Smartphone or a Tablet completed their purchase on a different device (30% in the case of Smartphone users and 34% of Tablet users). The hopping trend intensified in the case of Smartphone users, where 41% of customers who performed a purchase on their Smartphone did so following an initial browsing session that was conducted on another device (Computer or Tablet).

Responsive Conversion

  • Currys.com: 30% mehr CR
  • Walmart.ca: 20% mehr CR
  • Baines & Ernst: 51% mehr CR

Responsive Shops

Responsivetopshopsde.png

Content Choreography

  • Inhalte unabhängig vom HTML-Markup anordnen
  • Das Markup selbst bleibt unverändert
  • Sehr mächtig in Kombination mit RESS etc.

Atmic Web Design

AtomicWebDesign.png

Mobile First

  • Mobile First erleichert die Priorisierung von Inhalten
  • Wir können prüfen ob die HTML-Struktur semantisch sinnvoll ist
  • Einziger Nachteil: unsere Sichtweise muss verändert werden

RESS

RESS.png
  • RESS = Reponsive Design + Server Side Components
  • Robustes Reponsive Design
  • Optimierte, ausgetauschte Inhalte durch serverseitige Abfrage

Workflow

  1. Content Inventory
  2. Content reference wireframes
  3. Design in text (structured content)
  4. Linear design
  5. Breakpoint graph
  6. Design for various breakpoints
  7. HTML design prototype
  8. Present prototype screenshots
  9. Present prototype after revision
  10. Document for production

[Sphehen Hay @stephenhay: Responsive Design by Stephen Hay]

Vor- und Nachteile

Klassischer Workflow RWD Workflow
Nachteile
  • Überflüssige Arbeit (z.B. viele Layouts)
  • Falsche Erwartungshaltung beim Kunden durch statische Grafiken
  • Flexible Layouts, Interaktionen, Animation lassen sich schlecht darstellen
  • Eine fehlerhafte Planung führt zu aufwändigen Korrekturen
  • Strukturelle oder funktionelle Änderungen haben oft Auswirkungen auf das Design, das führt zu doppelten Korrekturschleifen
  • Die User Experience (z.B. die Benutzung per Touch-Screen) kann schlecht optimiert werden
  • Der klassische Workflow ist langsam, unflexibel und somit teuer
  • Designer, Entwickler und Agenturen müssen umdenken
  • Designer und Entwickler müssen sehr gut zusammenarbeiten oder sind im Idealfall ein und dieselbe Person
  • Die Anforderungen an den Kunden steigen
Vorteile
  • Wir haben uns an diesen Ablauf gewöhnt
  • Ein Projekt kann linear bearbeitet werden, einzelne Abteilungen oder Mitarbeiter arbeiten nacheinander an verschiedenen Bereichen der Website
  • Der Workflow ist auch für Außenstehende leicht vorstellbar und anschaulich zu präsentieren
  • Das flexible Design, Animationen und Interaktionen lassen sich bereits in einer frühen Projektphase perfekt abbilden
  • Das Design und die Struktur folgt den Anforderungen des Inhalts (Form follows Function)
  • Fehler in der Konzeption werden frühzeitig (im Prototypen) erkannt und können behoben werden
  • Design und Funktion werden Anfangs getrennt bearbeitet und können sich daher nicht gegenseitig negativ beeinflussen.
  • Der responsive Workflow ist schnell – Design und Code können parallel bearbeitet werden.

Quellen