Umsetzungsstrategien für Cross-Platform Projekte

A session at IA Konferenz 2013: Prozess. Dialog. Qualität.

Friday 3rd May, 2013

10:40am to 11:15am (CET)

Responsive Webdesign, separate Device-Templates, Platform-Solution, Apps: Welche Kombination eignet sich für welches Projekt?

Die Festlegung auf eine technische Umsetzungsstrategie hat direkte Auswirkungen auf die Konzeption und das Design, und zwar entweder durch die sich ergebenden Einschränkungen oder durch zusätzliche Möglichkeiten. Der Vortrag will aufzeigen, welche Umsetzung für welche Art von Projekt geeignet ist. Er soll eine Entscheidungshilfe bieten und dazu befähigen, sich bei dieser zentralen Projektentscheidung informiert einzumischen.

-

Ob ein Online-Projekt mit reinem Responsive Webdesign umgesetzt wird, ob es zusätzlich separate Device-Templates für unterschiedliche Geräteklassen gibt, ob zusätzlich eine Plattform mit Device-Datenbank verwendet wird und ob das Angebot eine App mit einschließt, macht einen erheblichen Unterschied in der Konzeption und auch in der Zusammenarbeit der Konzeption mit Design, Frontend und Backend: Jede der Varianten hat spezifische Stärken und Schwächen, und es gilt schon früh im Projekt – wegen der Kostenrelevanz meist schon in der Angebotsphase – die richtige technische Umsetzungsstrategie zu wählen.

Weil diese Entscheidung so wichtig ist und meist früh getroffen werden muss, haben wir bei Aperto die Notwendigkeit verspürt, stärker als bisher zu formalisieren und über alle Disziplinen hinweg ein aktuelles Bild davon zu entwickeln, welche Umsetzungsstrategie für welches Projekt geeignet ist.

Der Vortrag soll Konzepter dazu befähigen, ihre Anforderungen in die Entscheidung der technischen Umsetzungsstrategie einzubringen. Er soll eine Entscheidungshilfe zwischen den folgenden Strategien bieten:

Responsive Webdesign ( + App):
Responsive Webdesign ist dabei zunächst einmal die Grundlage. Die Website muss auf allen einigermaßen modernen Endgeräten gut dargestellt werden und gut nutzbar sein. Dies funktioniert gut, wenn die Seite von Grund auf neu gemacht wird, wenn schon von Beginn an reduziert und universell konzipiert wird und dabei auf bestehende Patterns zurückgegriffen wird. Dann nämlich bleibt der Umsetzungsaufwand im Rahmen und gibt keine zu großen Probleme mit Ladezeit und Performance insbesondere auf Smartphones. Es funktioniert auch gut, wenn es keine unterschiedlichen Use-Cases für die unterschiedlichen Geräte gibt und damit im Wesentlichen die selben Inhalte und Funktionen auf allen Devices dargestellt werden - und wenn diese Funktionen und Ansichten nicht zu komplex sind. Diese Randbedingungen sind härter, als es auf den ersten Blick scheint!

Responsive Webdesign + Device-Templates ( + App):
Wenn es auf der Website komplexere Funktionalitäten wie Checkout-Prozesse oder Facettensuchen gibt, dann werden insbesondere für Smartphones häufig zusätzliche Device-Templates notwendig. Sie ergänzen dann das Responsive Design, mit dem große Bildschirme und meist auch Tablets abgedeckt werden. Device-Templates bieten den Vorteil, dass die Nutzerführung komplexer Funktionalitäten hier freier als bei Responsive Design an die Erfordernisse des Geräts angepasst werden kann. Auch wenn spezielle Use-Cases auf Smartphones oder Tablets für diese Geräteklassen zusätzliche oder abweichende Features erforderlich machen, kommt man um Device-Templates nicht herum. Vielleicht am wichtigsten ist dabei aber, dass der Code dieser Templates entschlackt und simpel sein kann, so dass sie in der Regel notwendig werden, wenn Ladezeit und Performance in mobilen Kontexten erfolgskritisch sind.

Responsive Webdesign + Platform-Solution ( + App):
Wenn allerdings die Geräteabdeckung erfolgsentscheidend ist, insbesondere auch für ältere mobile Geräte, dann ist das mit reinem Responsive Design nicht zu schaffen und auch mit Device-Templates wächst der Aufwand schnell ins Unermessliche. In diesem Fall muss über eine Plattformlösung wie Netbiscuits oder Sevenval zumindest nachgedacht werden. Für solche Plattformen werden die Templates in einer Meta-Sprache (z.B. BiscuitML) definiert und die Plattform generiert daraus dann für eine Vielzahl von Geräten ganz spezifische Ausspielungen, inklusive passender Bildformate und Videocodecs. Problematisch ist hier aber die Bindung an eine Plattform und vor allem die hohen Kosten für den laufenden Betrieb.

Apps:
Die drei voranstehenden Varianten betreffen Websites. Etwas anderes und mit allen drei Herangehensweisen zu einem echten Cross-Channel Angebot kombinierbar sind Apps: Sie sollten nur angeboten werden, wenn es klare Use-Cases für eine App gibt und möglichst auch einen Business-Case. Besonders geeignet sind Apps, wenn hochperformanter Joy-of-Use erreicht werden muss, komplexe Interaktionen abzubilden sind und wenn Device-Funktionen angesprochen werden sollen. Es sollte auch Bewusstsein dafür herrschen, dass man es mit Software-Entwicklung zu tun hat, dass mehrere Updates pro Jahr einzukalkulieren sind, gegebenenfalls unterschiedliche Betriebssysteme und Geräte zu bedienen sind und die App gemanaged werden muss.

About the speaker

This person is speaking at this event.
Klaus Rüggenmann

Vespa-Fahrer, Vinylmusik-Hörer, Konzert-Gänger, UX und IA, Konzepter bei Aperto in Berlin bio from Twitter

Next session in Einsteinsaal (Track 2)

11:40am UX Design goes Unterbewusstsein by Markus Wienen

Coverage of this session

Sign in to add slides, notes or videos to this session

Tell your friends!

When

Time 10:40am11:15am CET

Date Fri 3rd May 2013

Short URL

lanyrd.com/scghgp

Official event site

iakonferenz.org

View the schedule

Share

See something wrong?

Report an issue with this session