uxzentrisch erörtert:
4 Lösungen für Mobile am Beispiel einer mobilen Version von StayScout.de

StayScout.de ist ein junges, wachsendes Socialnetwork für Pfadfinder, das ich ehrenamtlich konzipiere und betreue. Wir sind vor ca. 5 Monaten online gegangen und konnten seitdem mehr als 5.500 ehemalige und aktive Pfadfinder aktivieren.

Seit langem schon denke ich auch darüber nach, wie sich StayScout im mobilen Umfeld (iPhone, Android-Phone u.ä.) platzieren sollte. Da diese Überlegungen auch auf andere Projekte angewendet werden können, teile ich sie hier gerne mit euch.

Unsere Ausgangsbasis dafür ist also eine bestehende Webapplikation/Community, die bisher nur für den Desktop-Browser optimiert wurde.

StayScout Startseite am iPhone StayScout Startseite im eingeloggten Zustand am iPhone StayScout Stammes-Seite am iPhone

Optionen

Zuerst einmal stellt sich die Frage, welche Optionen wir überhaupt haben:

  • Keine Template-Optimierung, nur Bugfixes für mobile Browser.
  • Das bestehende Template für mobile Browser optimieren. Das betrifft vor allem die Spaltenbreite und -anzahl.
  • Ein eigenes mobiles Template für die bestehenden Seiten erstellen (Stichwort jQTouch).
  • Eine native (iPhone/Android-)App erstellen, die die Funktionen der Seite abbildet.

Ihr seht, dass diese Liste schon anhand ihres Umsetzungsaufwands priorisiert ist und sie stellt auch erstmal die offensichtlichen Möglichkeiten dar.

Gleichzeitig ist sie aus Sicht einer mobilen Strategie zu mindestens 50 % falsch. Natürlich ist es legitim darüber nachzudenken, den bestehenden Website-Content möglichst gut mobil erlebbar zu machen. Für eine mobile Strategie fehlen aber Szenarien, die den Context des mobilen Nutzers berücksichten. Die offensichtlichsten und wichtigsten sind: »Wo befindet sich der Nutzer (Ortsbezug)?« und »Was möchte er in seinem mobilen Context auf der Website erledigen?«.

Für meine Pfadfinder-Website könnte das bedeuten: Ich raste mit meiner Gruppe während eines Ausflugs im Zug oder auf der Parkbank im Wald und möchte den Ausflug schonmal in StayScout anlegen um ihn in meinen Pfadfinder-Lebenslauf einzutragen und die übrigen Teilnehmer einzuladen. Oder: Ich bin im Sommerferienlager mit meiner Ortsgruppe und möchte Statusupdates für daheimgebliebene Freunde oder zur Dokumentation schreiben. Oder: Ich bin auf einem bundesweiten Pfadfinderevent und möchte den Event in meinen Pfadfinderlebenslauf eintragen. Dazu muss ich in StayScout angeben, dass ich teilgenommen habe.

Dies sind drei wahrscheinliche mobile Anwendungsszenarien die den Ort und Context des Nutzers berücksichtigen. Bei einer mobilen Applikation erwarte ich als Anwender, dass die App weiß, wo ich mich befinde (Geo-Koordinaten) und im System entsprechend darauf reagiert in dem es beispielsweise alle Aktionen und Gruppen im Umkreis anzeigt.

Wir müssen die Liste also erweitern. Und wie auch zuvor gibt es wieder verschiedene Umsetzungs-Szenarien:

  • Mobile Szenarien innerhalb der Webapplikation umsetzen und für mobile Browser freischalten
  • Mobile Szenarien innerhalb der Webapp umsetzen und auch die Geo-Funktionen des Browsers berücksichtigen
  • Mobile Szenarien als Kernfunktion einer nativen (iPhone/Androit-)App umsetzen

Zwischenfazit: Es ist wichtig, nicht nur an native Apps, sondern auch Anpasungen am Website-Template in Betracht zu ziehen. Und es ist außerdem wichtig, sowohl an den bestehenden Inhalt der Site zu denken, als auch die wirklichen mobilen Anwendungsszenarien zu berücksichten.

Umsetzung

Als nächstes stellt sich die Frage nach der Umsetzung. Damit verbunden ist auch eine Aufwand-Nutzen-Betrachtung. Gehen wir also die Optionen durch:

1. Native, mobile Applikationen:

UX: Sehr gut – Aus User Experience-Sicht sicherlich eine der schönsten Lösungen. Es könnte eine App geben für Androit und iPhone, die den Ort des Nutzers berücksichtigt und ein entsprechend optimiertes Interface anzeigt.

Aufwand: Sehr hoch – Man müsste aber nicht nur für iPhone und Android jew. eigene Apps entwickeln – wofür wir bei stayscout gar kein Expertenwissen haben. Wir müssten zusätzlich eine API erstellen, die es der App erlaubt, Inhalte zu lesen und zu schreiben. Auch das Testing ist nicht ohne weiteres geschehen.

Pflege: Kompliziert – Hinzu kommt, dass jeder Bugfix und jede Erweiterung nur von externen Fachleuten und nur durch den aufwändigen und zum Teil langwierigen Appstore-Prozess umgesetzt werden kann.

Insgesamt sind mobile, native Apps also für stayscout keine gute Lösung. Zu teuer und zu unflexibel.

2. Eigene Mobile-Templates:

Einfacher wird es, wenn wir für die stayscout-Webapplikation eigene mobile Template entwickeln. jQTouch bietet sich hier als Framework an und es gibt sogar Video-Tutorials, wie jQTouch in eine Railsapplikation wie StayScout integriert werden kann.

UX: Sehr gut – Webapplikationen am iPhone können zwar nicht auf alle Hardwareeigenschaften des Geräts zugreifen, sind insgesamt aber sehr leistungsstark. Für StayScout fällt mir spontan kein Anwendungsfall ein, der nicht abgedeckt werden kann. Für den Nutzer fühlt sich die App daher an, wie eine native App. Und da wir keine Marketing- und Absatzziele verfolgen, können wir auch die fehlende Aufmerksamkeit im Appstore verschmerzen. Wir werden dadurch keine Nutzer verlieren.

Viele gute Biespiele hierfür bietet Google, zum Beispiel die von Tamim vorgestellte mobile YouTube-Seite. Aber auch die mobile Site von Amazon, über die wir schon geschrieben haben, ist interessant – vor allem, da sie für weniger relevante Screens einfach zu den Standard-Tempaltes wechselt.

Aufwand: Hoch – Trotzdem bleibt auch bei dieser Lösung der Aufwand hoch, denn für jedes Template muss eine neue, mobile Version erstellt und getestet werden. Und aufgrund der anderen Element-Anordnung werden neue Zwischenseiten nötig sein. Hinzu kommt, dass die mobilen Anwendungsszenarien stärkere Anpassungen an der Informationsarchitektur und Applikationslogik mit sich bringen und auf die Gerätschnittstellen zugreifen müssen  (Geo-Daten auslesen und verarbeiten…).

Pflege: Überschaubar – Es ist nicht zu unterschätzen, wenn man bei jeder Korrektur oder Erweiterung nicht eine, sondern zwei Templateversionen berücksichtigen muss. Da beides aber durch die gleichen Entwickler in einem Arbeitsgang erledigt werden kann, ist der Aufwand wesentlich überschaubarer als im ersten Szenario.

3. Nur ein optimiertes Template:

Noch einfacher wird es natürlich, wenn nur ein Template genutzt wird. Dabei muss nicht auf mobile Optimierung verzichtet werden. Mit geschicktem CSS- und JavaScript-Einsatz kann man das Spaltenraster an die Browser-Breite und eigenschaften anpassen. Ausprobieren kann man diese Technik beispielsweise beim Magazin von designmadeingermany.de und bei der DEVK-Website. Bei beiden Websites bitte die Breite des Browserfenster verändern.

UX: Gut – Ein optimiertes Template ist meistens angenehmer zu bedienen als ein unoptimiertes. Wir bewegen uns aber mit diese Lösung zunehmend weg von fokussierten mobilen Anwendungsszenarien. Statt dessen sprechen wir eher von der einfachen Abbildung des bestehenden Funktionsumfangs auf optimierte Weise. In diese Lösung weichen einzubauen scheint mir zunehmend ungeeignet.

Aufwand: Überschaubar – Es gibt noch wenige Tutorials und Erfahrungsberichte zu diesem Thema, im Vergleich zu den bisher beschriebenen Lösungen ist der Aufwand aber sicherlich überschaubar.

Pflege: Einfach – Letztlich reicht es, bei Änderungen die bestehende Seite einmal im gewünschten mobilen Browser aufzurufen.

4. Nur Bugs im Template beheben:

Zuguterletzt die einfachste Möglichkeit, seine Site mobil zu optimieren: Man testet sie in mobilen Browsern und behebt nur Funktions- und Darstellungsfehler. Bei StayScout würde darunter beispielsweise das Lösen eines Darstellungsfehler im Pfadfinderlebenslauf gehören [SCREENSHOT].

UX: Besser als ohne… – Es geht wie gesagt jetzt nicht mehr darum, eine optimale UX zu erreichen, sondern darum negative UX-Erglebnisse zu vermeiden.

Aufwand: Überschaubar – Alternativen Content für Flash-Inhalte anzeigen, JavaScripte überprüfen, … alles überschaubare Tätigkeiten – Zumindest in der Theorie, wie Marian in einem Ergo-Artikel festgestellt hat.

Pflege: Einfach – Eine sporadische Kontrolle mit den mobilen Zielbrowsern sollte ausreichen.

Fazit

Was bedeutet das jetzt für StayScout?

Lasst uns die beiden Seiten Aufwand und Nutzen betrachten:

Nutzen: Anhand unserer eTracker-Statistik für Betriebssystem kann ich sehen, dass gerade mal 0,9 % der Nutzer mobil auf StayScout zugreifen (Zeitraum 24.4.2010 bis 10.10.2010, Sessions).

StayScout Stammes-Seite am iPhone
Aufwand: Dieses Ergebnis macht die Aufwandsbetrachtung einfach: Auf eine so geringe Zielgruppe, sollten wir sinnvoller Weise keine Zeit für Templateoptimierungen verwenden und unsere ehrenamtlichen Ressourchen besser ander einsetzen. Da unsere mobilen Bugs die Nutzung nicht einschränken, werde ich noch nicht einmal das Bugfixing-Szenario weiter verfolgen.

Gleichzeitig zeigt die geringe mobile Nutzerschaft, dass es sich für unsere Zielgruppe noch nicht lohnt, Aufwand in richtige mobile Szenarien zu stecken. Es ist ja vielleicht auch ganz gut so, dass nicht jeder Stamm mit Laptop, UMTS-Stick und iPhone ausgestattet ins Lager fährt :-).

Was bedeutet das für eure Websites und Applikationen?

Kommerzielle Websites sollten schon jetzt als Minimalpaket ihre Site mit mobilen Browsern testen und Fehler beheben. Wenn sich die übrigen Inhalte dabei als lesbar und erlebbar darstellen, ist kurzfristig der wichtigste Schritt geschafft.
Hier sollte es aber nicht aufhöhren. Bei kommerziellen Sites erwarte ich mehr als bei einer ehrenamtlich finanzierten und entwickelten Community. Fast jede Seite hat einen oder mehrere zentrale Anwendungsfälle, die mobil häufiger aufgerufen werden. Diese gilt es zu ermitteln und in einem optimierten mobilen Prozess, sei es als native App oder eher als eigener Bereich der Website, umzusetzen.
Um eines der vorherigen Beispiele aufzugreifen: Kann es sein, dass DEVK-Kunden besonders häufig mit dem iPhone die Site aufrufen, wenn ein Schadensfall eingetreten ist und sich informieren möchten oder gar einen Schaden melden wollen? Falls sich diese Annahme als richtig herausstellt, wäre ein schneller Einstieg und ein mobil optmierter Melde-Prozess im mobilen Template sinnvoll…

Doch die Analyse von mobilen Anwendungsszenarien ist ein Thema für einen anderen Artikel. Jetzt interessiert mich zuerst einmal: Welche Gedanken habt ihr euch für eure mobile Site gemacht? Und wie kam die Entscheidung zu stande? Wie geht ihr mit dem Thema um?

PS: An alle Pfadfinder: SCOUTE DICH! :-)

6 Kommentare

Susanne vor 5 Jahren

Hallo Tobias.

Aus meiner Sicht gibt es einen ganz einfachen Grund für die fehlenden mobilen Zugriffe – mir ist die Seite einfach zu komplex um sie übers iPhone zu besuchen – was für mich die Konsequenz hat, dass ich mir denke – lieber erst zuhause gucken – und es dann vergesse, bzw. kaum noch pflege.

Ich fände die zweite Lösung interessant, kann natürlich auch verstehen, dass sich ein solcher Aufwand lohnen sollte.

Viele Grüße & Gut Pfad!
Susanne

Tobias Jordans Autor vor 5 Jahren

Ergänzung: LukeW fasst einen Talk zusammen, in dem gute Überlegungen/Schritte/Argumente für mobile Webapp vs. mobile Nativeapp genannt werden http://www.lukew.com/ff/entry.asp?1244

David Hellmann vor 5 Jahren

Also ich bin gerade an Make Better Shirts dran (wird bald online gehen) und habe da ein Design / Raster gemacht welches von 480px bis 1800 px alles abdeckt. Das ganze hab ich mit CSS Media queries gemacht > klappt super.

Marian Steinbach uxzentrisch vor 5 Jahren

@David Hört sich sehr gut an! Ich bin gespannt.

Trackbacks und Pingbacks