Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Entwicklung & Design

Das Ende der Isolation: Wie Apps in Zukunft zusammenarbeiten werden

    Das Ende der Isolation: Wie Apps in Zukunft zusammenarbeiten werden

App-System. (Bild: Andreas Weder)

Die App-Metapher ist ausdrucksstark und dank der starken Verbreitung von Smartphones leicht erlernbar. Doch sie hat auch einen Nachteil: Um eine gestellte Aufgabe zu lösen, ist ein mehrmaliger Wechsel zwischen Apps notwendig. Das müsste nicht so sein, wenn wir Apps als Dienstleister betrachten würden.

Das App-System: Einfach und erweiterbar

Hier ist klar: Diese Systeme sind über Apps erweiterbar. (Bild: Andreas Weder)
Hier ist klar: Diese Systeme sind über Apps erweiterbar. (Bild: Andreas Weder)

Apps sind überall: auf Handys, Fernsehern, Set-Top-Boxen, Uhren. Wir finden sie zunehmend auch auf Desktopsystemen, wo sie grundsätzlich nichts Neues sind, denn installierbare Anwendungen gibt es dort schon seit eh und je. Doch mit dem Begriff der „App“ schwingen hier die gleichen Versprechen wie auf Smartphones mit: auch Apps für Desktops sollen in Stores einfach zu finden, leicht gekauft und installiert sein.

„Apps: eine exzellente Metapher für Einfachheit und Erweiterbarkeit.“

Hinter dem Siegeszug von Apps stecken außer cleverem Marketing und einträglichen Business-Modellen auch tiefere Gründe: Apps sind eine exzellente Metapher für Einfachheit und Erweiterbarkeit. Apps auf einem Smartphone sollen unter vielen äußeren Bedingungen gut und schnell funktionieren. Daher zwingen sie uns, die Komplexität auf der Interface-Ebene auf einzelne Blöcke herunter zu brechen und verlangen von uns, dass wir diese klar umreißen. Der Kontext einer Nutzung wird so klarer, die Use-Cases bleiben simpel, die Menüs werden schlanker.

Gleichzeitig lassen sich die Systeme leicht erweitern. Kunden und Benutzern wird das vor allem anhand des Icon-Rasters klar: Zeige ich einem Benutzer einen Homescreen und frage ihn, wie das System dahinter erweitert werden kann, ist die Antwort immer: indem ich eine zusätzliche App installiere. Ist das dann nicht möglich oder nicht einfach zu bewerkstelligen, fühlt man sich betrogen. Ein App-System mit nur wenigen Icons hingegen, hinter denen auch noch komplexe Menübäume stecken, fühlt sich schwerfällig und auch irgendwie „falsch“ an.

Nachteile von Apps: Das Beispiel Facebook-Messenger

Facebook: Die erzwungene Trennung von Netzwerk- und Messenger-App fühlt sich für Nutzer noch holprig an. (Screenshot: t3n)
Facebook: Die erzwungene Trennung von Netzwerk- und Messenger-App fühlt sich für Nutzer noch holprig an. (Screenshot: t3n)

Doch Apps haben auch Nachteile. Einer davon ist das „Flattern“ (oder auch: thrashing). Apps sind so eng gehalten, dass oft mehrere von ihnen kombiniert werden müssen, um größere Aufgaben zu lösen. Das erfordert andauernde Wechsel zwischen diesen Apps, was desorientierend und belastend wirken kann und oft zusätzliche (wenn auch meist offensichtliche) Klicks erfordert. Ein andauernder App-Wechsel stört den hindernisfreien Fluss (flow), in dem ein Benutzer ruhig, fokussiert und effizient arbeiten kann.

Ein aktuelles Beispiel für das geschilderte Problem ist Facebooks Messenger. Benutzer werden einerseits gezwungen, nur für den Austausch von Meldungen eine eigene App zu installieren, obwohl dies nicht Teil der Kernfunktionalität von Facebook ist. Dann aber gestaltet sich der Wechsel zwischen Messenger und der Hauptapp äußerst holprig und so störend, dass frustrierte Benutzer sich schließlich nach Messaging-Alternativen umsehen werden. Das dürfte den Zielen von Facebook eher zuwider laufen.

Ein weiterer Nachteil von Apps sind die entstehenden Datensilos. Eine typische App operiert auf einem Typ von Daten (etwa: Seiten, Bilder, Kontaktinfos, Maileinstellungen). Benötigt eine andere App dieselben Daten, so muss ein Zugriff auf diese einfach möglich sein. Ähnliches gilt für verschiedene Apps, die auf demselben Datensatz arbeiten müssen: der Zugriff auf diesen muss klar geregelt sein – mit vielen Spielern wird ein Spiel nicht unbedingt einfacher.

Auf beide Probleme könnten Apps mit einem erhöhten Funktionsumfang reagieren. Damit würden wir aber deren klare Ausrichtung und Einfachheit torpedieren. Da ist ein modulares Prinzip à la Lego, bei dem einfache Bauteile temporär zu größeren Strukturen kombiniert werden, deutlich viel versprechender. Denn so kann ein App-System weiterhin seine Stärken ausspielen.

„The end of apps as we know them“

Was heißt das? Sehr konkret hat Paul Adams das in dem spannenden Artikel, „The end of apps as we know them“ auf seinem Blog „Inside Intercom“ dargestellt. Er spricht davon, dass Apps nur noch in ausgewählten Fällen das Ziel einer Interaktion sein werden. Er schlägt vor, dass sie ihre Funktionen und Interfaces einander und der Umgebung vermehrt über Card-UIs zugänglich machen sollen.

Eine solche Entwicklung lässt sich bereits in aktuellen Versionen von Android und iOS beobachten. Auch hier bleiben Apps einerseits ihren Kernaufgaben treu, bieten ihre Dienste aber vermehrt anderen Apps an. Ein Beispiel: der Password-Manager unter iOS. Muss ich mich im eingebauten Webbrowser auf einer Webseite einloggen, so kann ich neu an Ort und Stelle meinen Password-Manager aufrufen, mich authentifizieren und Benutzername und Passwort einfüllen lassen. Die Grundlage für dieses Verhalten bilden die in iOS neu eingeführten Erweiterungen (extensions). Früher war dafür ein Wechsel zur Password-App notwendig – beide Login-Daten mussten händisch und nacheinander kopiert und nach einem Wechsel zurück in den Browser wieder eingefügt werden.

Eine App ruft eine andere auf: Einfüllen der Login-Daten auf einer Webseite (iOS). (Bild: Andreas Weder)
Eine App ruft eine andere auf: Einfüllen der Login-Daten auf einer Webseite (iOS). (Bild: Andreas Weder)

Über ähnliche Mechanismen kann ich Daten einer App an eine andere App übergeben. Bleibe ich beim Browser als Beispiel, so kann eine Seite mit den Webdiensten Evernote und Instapaper direkt geteilt werden, die dann deren Inhalt verarbeiten. Auch hier bleibe ich im Browser und muss erst dann wirklich zur Evernote-App wechseln, wenn ich die geteilte Seite weiter bearbeiten möchte.

Eine App reicht Daten weiter: 
Abspeichern einer Webseite in Evernote (Android). (Bild: Andreas Weder)

Eine App reicht Daten weiter: 
Abspeichern einer Webseite in Evernote (Android). (Bild: Andreas Weder)

Apps zu Arbeitsketten kombinieren

Ein ähnliches, aber weitergehendes Beispiel ist das Dialogfenster, das eingeblendet wird, wenn ich ein Foto in einer „Fotos“-App per Mail oder als Nachricht versenden möchte. Es stammt von der jeweiligen Nachrichten-App, wird jedoch im Kontext der „Fotos“-App angezeigt. Der Benutzer kann so ein Foto versenden, ohne die aktuelle App verlassen zu müssen. Im Gegensatz zum bloßen Teilen mit Instapaper oder Evernote wird hier eine komplexere Funktion der „Mail“-App zwischenzeitlich verwendet, bevor ich zu „Fotos“ zurückkehre.

Eine App zeigt sich in einer anderen: Ein Fenster zum Schreiben einer Mail in der „Fotos“-App (iOS). (Bild: Andreas Weder)
Eine App zeigt sich in einer anderen: Ein Fenster zum Schreiben einer Mail in der „Fotos“-App (iOS). (Bild: Andreas Weder)

Mit diesen Mechanismen lassen sich flexibel und erweiterbar Apps zu kleinen Arbeitsketten kombinieren. Die Kernbeobachtung hier ist, dass das „Flattern“ zwischen Apps und damit grobe Unterbrechungen im Nutzungsfluss vermieden werden. Einmal eingeführt, ist das so einleuchtend und erleichternd, dass es schnell selbstverständlich und erwartet wird.

So richtig spannend wird das, wenn Apps ihre Dienste überall anbieten können. Ein Trend in aktuellen Mobile-Betriebssystemen sind beispielsweise zunehmend interaktive Nachrichtenströme. Möchte ich auf eine SMS antworten, so ziehe ich die zugehörige Benachrichtigung nach unten. Es wird ein Textfeld sichtbar, in das ich direkt meine Antwort tippen kann. Möchte ich schnell eine Geburtstagserinnerung erstellen, verwende ich mein ToDo-Widget im Nachrichtenstrom dafür. Muss ich die Spesen für ein Mittagessen erfassen, kann ich auch das erledigen, ohne erst die zugehörige App starten zu müssen.

Apps zu Diensten im Nachrichtenstrom: Reagieren und direktes Antworten auf eine Meldung (Android, iOS). (Bild: Andreas Weder)
Apps zu Diensten im Nachrichtenstrom: Reagieren und direktes Antworten auf eine Meldung (Android, iOS). (Bild: Andreas Weder)

Apps als Bausteine und nicht als Ziel unserer Interaktion – die Idee lässt sich weiterspinnen. Solange eine App eine Aufgabe genau abdeckt, starte ich sie separat. Benötige ich ihre Dienste nur nebenbei, so taucht sie auf, ohne dass ich das richtig merke.

App-Funktionalitäten bei Bedarf von überall aus

„Apps sollten die Bausteine, nicht das Ziel unserer Interaktion sein.“

Auch bei Magnolia setzen wir auf ein modulares, App-basiertes System, um komplexe CMS-Funktionalitäten abbilden zu können und gleichzeitig einzelne Aufgabenbereiche separat und einfach erlernbar zu halten. Magnolia besitzt einen Strom für Nachrichten und einen zweiten für Aufgaben (Tasks), auf die direkt reagiert werden kann. Typisch für diese Interaktionen ist, dass die angebotenen Arbeitsschritte klein und fokussiert sein müssen: Möchte ich mehr als nur schnell antworten oder eine Anfrage gutheißen, oder fallen gar mehrere Arbeitsschritte an, so wechsle ich immer in die zuständige App und richte damit meine gesamte Aufmerksamkeit auf die neue Aufgabe.

Bei einem CMS könnte das Baustein-Prinzip die Arbeitsabläufe in Zukunft noch weiter verändern. Ein Beispiel: Das Ziel ist eine neue Marketing-Site – eine größere Aufgabe also. Eine Seitenvorlage ist hierfür ein guter Ausgangspunkt. Eine App liefert den Seiteneditor, eine andere erlaubt es, Bilder und Videos einzufügen. Ohne dass ich die Seite verlasse, editiere ich sie mithilfe von Apps. Am Ende eines solchen Stroms von einzelnen Arbeitsschritten liegt die Publikation der neuen Seite. Auch hierfür bieten Apps wieder dem System ihre Dienste an – zeigen Dialoge, bieten Zugriff auf Daten oder stellen Interfaces zum Vergleichen zweier Seitenvarianten zur Verfügung.

Zugegeben: Bei Magnolia sind wir von solchen Abläufen noch etwas weit weg. Unser Weg führt uns aber vermehrt zu aufgabenorientierten Schnittstellen (task-oriented UIs). Apps sind dabei Inspiration und Baustein zugleich.

Fazit: Apps werden nicht verschwinden – aber sich verändern

Apps werden nicht verschwinden. Sie überzeugen als Metapher für Modularisierung und Erweiterbarkeit und erlauben uns Anbietern, klar umreißbare Blöcke für dedizierte Aufgabenbereiche anzubieten. Die typischen Funktionen einer App werden aber immer mehr dort erscheinen, wo sie gebraucht werden. So entsteht eine fokussierte Erfahrung, die den Nutzer im Flow belässt und flüssiges, konzentriertes Arbeiten unterstützt.

Weiteres zu Apps, ihren Chancen und Problemen findet ihr in den Slides zu meinem Talk „There’s Apps for that“ der J.Boye Konferenz in Philadelphia von 2013.

Über den Autor: Andreas Weder ist Head of User Experience bei Magnolia CMS.

Finde einen Job, den du liebst zum Thema iOS, Android

2 Reaktionen
Giacomo
Giacomo

Hinweis an die Redaktion: Der im Screenshot gezeigte "Passwort-Manager" ist nicht iOS-nativ, sondern die Third Party App "1Password"!

Antworten
Barcodes scannen
Barcodes scannen

Bei iOS und Android ist sharing von Libraries und Daten eher unüblich bzw. sogar untersagt. Nur Kontakte und Fotos kommt man oft dran oder muss potentiell bösen Apps den Zugriff aufs komplette Filesystem erlauben.

Nervig ist z.b. das man dieselben Barcodes mit 20 verschiedenen Apps scannen muss wenn man z.B. ein Buch verkaufen will. Notlösung sind halt Zugriffe in die diversen verschiedenen Cloud-Dienste.

Antworten

Melde dich mit deinem t3n-Account an oder fülle die unteren Felder aus.

Abbrechen