Moderne Apps

Artikel
04/09/2015

Ein "Mobil zuerst"-Ansatz für die moderne Anwendungsentwicklung

Rachel Appel In diesem Augenblick greifen Millionen mobiler Geräte auf Millionen von Websites und mobile Apps zu. Laut Pew Research und anderen Statistikern nutzen mehr als 55 % der US-Amerikaner ein Smartphone, um auf das Internet zugreifen, und 30 % der US-Amerikaner nutzen ausschließlich ein Smartphone für den Zugriff auf das Internet. Diese Zahlen wachsen weiter, da Smartphones kostengünstiger werden und immer einfacher zu verwenden sind. Wenn Sie die Zeichen der Zeit erkannt haben, wissen Sie, dass Sie sich für einen "Mobil zuerst"-Ansatz entscheiden sollten.

Benutzer kann die beste Erfahrung auf allen Geräten von Desktops bis Smartphones geboten werden, wenn eine Website oder Anwendung zuerst für Mobilität entworfen wird. Denn es ist schwierig, eine Skalierung von einem großen Bildschirm auf einen winzigen vorzunehmen. Die Benutzeroberfläche funktioniert meist dann nicht besonders. Sie müssen nicht weiter zurückblicken als zum Betriebssystem Microsoft Windows Mobile 6.5 (nicht zu verwechseln mit Windows Phone) als prägnantes Beispiel einer verkleinerter kaum brauchbaren Desktop-Benutzeroberfläche.

Eine Skalierung von einem Smartphone zu einem Desktop ist dagegen möglich, ohne Benutzerfreundlichkeit zu vernachlässigen. Sie können bei der Skalierung der Umgebung Funktionen hinzufügen und den Übergang zur anderen Oberfläche reibungslos gestalten. Dieses Verfahren wird als progressive Verbesserung bezeichnet. Sowohl Websites als auch Apps profitieren von diesem Typ der "Mobil zuerst"-Entwicklungsstrategie.

"Mobil zuerst" bedeutet reaktionsfähiges Design

Das Anpassen von Inhalten an verschiedene Bildschirmgrößen ist die primäre Anforderung an moderne Anwendungen für mehrere Geräte. Sie müssen einen der beiden folgenden Ansätze befolgen. Sie können zwei Versionen der Software entwickeln: eine für Desktops und größere Computer und eine zweite für kleinere Formate. Die andere Möglichkeit ist, die Software so zu entwerfen, dass sich die Benutzeroberfläche an das Gerät anpasst, auf dem sie verwendet wird.

Sie haben es mit vielen verschiedenen Gerätetypen zu tun. Einige werden sie tragen und andere mit sich führen. Und möglicherweise werden schon bald IoT-Geräte (Internet of Things, Internet der Dinge) als Teil der Entwurfsanforderungen an die Anwendungsentwicklung hinzukommen. IoT-Geräte wie Fitbit oder Microsoft Band sind tragbare Geräte, die die Aktivitäten des Benutzers verfolgen.

Andere IoT-Geräte sind u. a. intelligente Thermostate (z. B. Nest), ein intelligentes Türschloss oder Software in einem neuen Fahrzeug. Viele IoT-Geräte arbeiten mit einer "Mobil zuerst"-Website oder -Anwendung zusammen, z. B. eine intelligente Kaffeemaschine. Da Computer immer kleiner und kostengünstiger werden, ist abzusehen, dass weitere IoT-Geräte mit zusätzlichen Einsatzmöglichkeiten den Markt überschwemmen werden.

"Mobil zuerst" bedeutet auch, die Auswirkungen der Plattform zu berücksichtigen. Systemeigene Apps haben unterschiedliche Entwicklung-, Architektur- und (mitunter) Geschäftsanforderungen als Webanwendungen. Es folgen einige Überlegungen zum Entwurf einer Anwendung nach dem "Mobil zuerst"-Prinzip:

Reaktionsfähige Benutzeroberfläche
Navigation
Listen und Raster von Elementen und Formatierung des Inhalts
Speicher, einschließlich Offlinespeicher
Unterstützung von Touch-, Stift- oder anderen Eingaben
Verwaltung von Ressourcen und Leistung

Auf diese Aspekte wird gleich noch im Detail eingegangen. Websites, Hybrid- und SPA-Anwendungen (Single-Page Architecture, Einzelseitenarchitektur) nutzen CSS, um ein reaktionsfähiges Design zu implementieren. XAML-Apps und Apps für die Android- oder iOS-Plattform bieten unterschiedliche, proprietäre Möglichkeiten zur Erstellung einer reaktionsfähigen Benutzeroberfläche. XAML verwendet z. B. ein Objekt namens "Resources", das Formatvorlageninformationen enthält. Sie können Ressourcen XAML-Steuerelementen zuordnen, um entsprechend der Bildschirmgröße des Geräts automatisch eine passende und reaktionsfähige Anzeige zu ermöglichen.

Bei HTML-Apps (Web oder systemeigenen wie z. B. Windows Library for JavaScript [WinJS]) können Sie mit CSS Formatvorlagen und Gestaltungselemente definieren. CSS verwendet das Konzept einer Medienabfrage, um eine reaktionsfähige Benutzeroberfläche zu erstellen. Medienabfragen sind CSS-Regeln, die auf verschiedene Medientypen reagieren. Diese Medientypen stellen verschiedene Bildschirmgrößen, Druck- oder Fernsehformate, Blindenschrift, Bildschirmausrichtung und andere Features dar. Wenn Sie eine Medienabfrage erstellen, geben Sie die CSS-Regeln für unterstützte Features des Geräts an (siehe den folgenden Code):

@media only screen and (min-device-width : 320px) and (max-device-width : 480px) {
/* style rules */
}
@media only screen and (min-width : 321px) {
/* style rules */
}
@media only screen and (max-width : 320px) {
/* style rules */
}
@media only screen and (min-device-width : 768px) and (max-device-width : 1024px) {
/* style rules */
}
@media only screen  and (min-width : 1224px) {
/* style rules */
}

Dieser CSS-Code funktioniert auf Smartphones und iPads sowohl im Hoch- als auch Querformatmodus und auch auf größeren Geräten wie Laptops und Desktops-PCs. Weitere Informationen zur Verwendung von CSS für systemeigene Windows-Anwendungen finden Sie unter "Aufbau einer reaktionsfähigen und modernen Benutzeroberfläche mit CSS für WinJS-Apps" unter msdn.microsoft.com/magazine/dn451447.

Für einen guten, reaktionsfähigen "Mobil zuerst"-Entwurf dürfen im Code keine spezifischen Gerätetypen angegeben werden. Denn Sie werden niemals mit den zahlreichen verfügbaren Geräten Schritt halten können. Planen Sie stets für eine Palette von Bildschirmgrößen. Sie können beispielsweise für 3-bis-4-Zoll-Geräte, 5-bis-8-Zoll-Geräte, 10-bis-13-Zoll-Tablets und Laptops und Desktops mit mehr als 13 Zoll planen. Auf diese Weise können Sie eine Benutzeroberfläche erstellen, die für die größtmögliche Zielgruppe geeignet ist. Konzentrieren Sie sich bloß auf einige gängige Smartphonegrößen. Dieser Code wird auch künftig, wenn neue Geräte auf den Markt kommen, weiter verwaltbar bleiben, da Sie bereits nach dem Größenbereich für sie planen.

Eine einfache Möglichkeit zum Entwerfen eines Projekts, das vom Smartphone bis zum Desktop skaliert werden kann, ist das Wählen des Projekttyps "Universelle App" in Visual Studio für Windows Store und Windows Phone. Universelle Apps verfügen über den gesamten Code und die Struktur, um auf verschiedenen Clients zu reagieren. Sie können eine universelle App entweder mit XAML oder HTML erstellen. Diese Apps nutzen einen Großteil ihres Codes gemeinsam, sodass Sie viel Code wiederverwenden können. Wenn Sie Ihre Kenntnisse über universelle Apps auffrischen möchten, lesen Sie "Erstellen universeller Apps für die Windows-Plattform" (msdn.microsoft.com/magazine/dn781364).

Entwickler zeigen Daten in Websites und Apps in der Regel im Tabellen- oder Listenformat an. Kurze Listen auf Smartphones funktionieren einwandfrei auf größeren Bildschirmen, wenngleich Platz vergeudet wird. Auf einer progressiv verbesserten Benutzeroberfläche werden weitere Inhalte mit zunehmender Größe des Bildschirms hinzugefügt und formatiert. Auch das Gegenteil ist der Fall, denn auf kleineren Geräten werden Elemente entfernt und der Bildschirm neu formatiert, um weniger Inhalte anzuzeigen.

Wie zu erwarten, werden von Smartphone-Apps meist nur die wichtigsten Inhalte angezeigt, da aufgrund der Größe der Geräte der Platz begrenzt ist. Smartphone-Apps sind in der Regel gut überschaubar. Wenn es Werbeanzeigen gibt, sind sie klein und in der Regel an denselben Stellen. Da selbst auf den kleinsten Desktops so viel Platz vorhanden ist, werden Anzeigen und Inhalte gezeigt, die für das Thema der Webseite nicht immer relevant sind. Achten Sie also beim Hinzufügen von Inhalten darauf, dass diese relevant und sinnvoll und dem Benutzer nicht im Weg sind. Die Inhalte, die Sie hinzufügen können, sind Randleisten zum Inhalt selbst, relevante Anzeigen oder sogar einige Quicklinks.

Ein einfaches, benutzerfreundliches Navigationsschema ist überaus wichtig. Die Navigation ist eine Möglichkeit zur Interaktion mit der Anwendung selbst. Sie ist auch eine Möglichkeit, auf den gewünschten Inhalt zugreifen. Jede App bietet eine Navigation, die aber leider mitunter schlecht ist.

Bei systemeigener Desktopsoftware, wie z. B. Windows Forms, werden meist hierarchische Menüs als Navigationsmittel verwendet. Bei Websites ist das oft auch der Fall. In der Tat müssen auf Websites häufig schreckliche JavaScript-Dropdownmenüs verwendet werden, die die Präzision eines Chirurgen erfordern. Glücklicherweise gerät dieses Modell immer mehr aus der Mode. Es ist klar, dass diese Arten von Menüs auf Smartphones einfach nicht funktionieren. Was hingegen auf Smartphones funktioniert, sind mehrere spezifische Navigationstechniken:

Große Kacheln: Quadrat oder Rechteck wie bei Windows 8.
Touch-freundliche Listen: Rechtecke, die für alle Finger- und Daumengrößen breit und hoch genug sind.
"Wischfähige" Registerkarten: Diese ermöglichen Benutzern das Wischen in kurzen horizontalen Bewegungen, was sich gut eignet, um ein Menü mit Optionen für eine bestimmte Kategorie oder Funktion zu präsentieren.
Angedockte App-Leisten: Optionen befinden sich auf einem Streifen am oberen oder unteren Bildschirmrand. Sie können die App-Leiste ausblenden und erst anzeigen, wenn der Benutzer sie mit einer Wischbewegung anfordert.

Sie können auch Navigationstechniken kombinieren, z. B. wischfähige Registerkarten mit einer touchfreundlichen Liste mit Optionen. Häufig sind diese Arten von Navigationsmenüs Teil des Inhalts selbst, wie z. B. eine Nachrichten-App, bei der Sie auf die Textüberschrift tippen können, um den Artikel zu lesen. Wofür Sie sich auch entscheiden, stellen Sie sicher, dass Benutzer auch rückwärts navigieren können. Eine deutlich sichtbare "Zurück"-Schaltfläche bietet sich hierfür an.

Bei Windows Store-Apps basiert die Navigation auf dem Windows-Rastersystem zum Anzeigen von Daten und ermöglicht dem Benutzer das Klicken oder Tippen, um zu Details zum aktuellen Rasterelement zu navigieren. Es gibt auch eine deutlich sichtbare "Zurück"-Schaltfläche, damit der Benutzer bei einer Reihe von Navigationsschritten stets zurückfindet. Alternativ können Apps eine App-Leiste mit vollständigen Navigationsoptionen präsentieren.

Datenspeicherung und Offlinefunktionen

Es kommt nur selten vor, dass eine App nicht von einer Form der Offlineunterstützung profitieren würde. Selbst Bordkarten, die Fluggesellschaften als Hyperlink per Textnachricht senden, sind einfache Webseiten, die bei fehlender Netzwerkverbindung nicht angezeigt werden. Eine Qualitäts-App muss Offlinefunktionen unterstützen.

Viele Anwendungen speichern Inhalte nicht lokal. Sie rufen einen Webdienst auf oder führen einen Remoteaufruf zum Abrufen von Daten durch und speichern die Daten remote. Freilich gibt es trotzdem immer eine kleine Datenmenge, die Sie lokal speichern müssen, z. B. App- oder Benutzereinstellungen und Voreinstellungen. Speichern Sie nur Dinge, die lokal gespeichert werden sollten, wie z. B. die aktuelle Stelle in einem E-Reader oder Spiel oder das Farbdesign der App.

Hier unterscheiden sich dann die Speicheranforderungen je nach Plattform, die Sie anvisieren. In HTML-Client-Apps können Sie DOM-Speicher (Domain Object Model) oder IndexedDB verwenden. In systemeigenen XAML-Apps können Sie lokale App-Einstellungen oder ein "StorageFile"-Objekt nutzen.

DOM-Speicherung (lokaler HTML5-Speicher): Dies ist ein einfacher Container für lokale Daten in HTML-Apps.
IndexedDB: Dient zum lokalen Speichern großer Datenmengen. Verwenden Sie IndexedDB in HTML-Apps, und speichern Sie relationale oder BLOB-Daten in Schlüssel-Wert-Paaren.
App-Einstellungen: XAML- und HTML-Windows Store und Windows Phone-Apps können auf Datenstrukturen von App-Einstellungen zugreifen. Die App kann Daten in diesen kleinen Objekten speichern. Sie enthalten normalerweise Einstellungen wie z. B. Benutzername, Farbdesign oder andere Einstellungen.
Speicherdateien: Dies sind alt bekannte Dateien, aber mit einer API für Windows Store- und Windows Phone-XAML- und HTML-Apps.

Sie können Anwendungseinstellungen im schreibgeschützten "ApplicationDataContainer"-Objekt speichern. Der Zugriff darauf erfolgt über die "ApplicationData LocalSettings"-Eigenschaft. Der folgende Code ruft die lokalen und Roaming-App-Einstellungen und ihre Ordner ab:

var localSettings = applicationData.localSettings;
var roamingFolder = applicationData.roamingFolder;
var roamingSettings = applicationData.roamingSettings;

Lokale Einstellungen sind natürlich nur auf dem dazugehörigen Gerät lokal verfügbar, während auf Roamingeinstellungen auf mehreren Geräten bzw. an mehreren Standorten zugegriffen werden kann. Weitere Informationen zur Datenspeicherung in Windows Store-Apps finden Sie unter "Datenzugriffs- und Datenspeicherungsoptionen in Windows Store-Apps" (msdn.microsoft.com/magazine/jj991982).

Architektur und Entwicklung nach dem "Mobil zuerst"-Prinzip

Der wichtige Aspekt beim "Mobil zuerst"-Prinzip ist, dass Sie tatsächlich sicherstellen, dass die Software, die Sie entwickeln, zuerst auf Mobilgeräten funktioniert. Denn was Bildschirme und Benutzererfahrung angeht, ist eine Skalierung von klein zu groß einfacher. Mit zunehmender Bildschirmgröße können Sie Informationen immer weiter hinzufügen.

Leistung ist für Benutzer mobiler Geräte äußerst wichtig. Sie zahlen für teure, aber häufig eingeschränkte Datenübertragungskontingente. Sie wollen nicht lange warten und für das Herunterladen einer Webseite oder App zahlen. Wenn Sie meinen, dass die Tage der Bedeutung jedes Bits und Bytes lange vorbei sind, sind Sie vielleicht ein bisschen voreilig. Denn das Management von Speicher und Ressourcen bei der Entwicklung mobiler Anwendungen spielt weiter eine große Rolle.

Heutige Telefone und IoT-Geräte sind technisch vergleichbar mit ihren größeren Desktop-Pendants in der Vergangenheit. Viele IoT-Geräte haben immer noch weniger als 1 GB Arbeitsspeicher, auch wenn Speicherkapazitäten astronomische Dimensionen angenommen haben. Lassen uns außerdem nicht die Akkulaufzeit vergessen. Benutzern werden Ihre App schnell wieder löschen, wenn sie den Akku leer saugt. Und Sie möchten möglichst dieselbe Codebasis für so viele Plattformen wie möglich verwenden. Der "Mobil zuerst"-Ansatz eignet sich für Websites und Anwendungen. Denken Sie daran, dass es nicht nur um die Bildschirmgröße geht.

Bestimmen Sie im Rahmen einer "Mobil zuerst"-Architektur zunächst, welche Art von mobiler App Sie entwickeln wollen. Handelt es sich um eine mobile Website? Ist es eine systemeigene Anwendung? Wie viele Plattformen müssen Sie unterstützen? Wenn Sie eine vorhandene mobile Website haben und schnell in einen App Store gelangen möchten, ist vielleicht eine Hybridlösung die beste Wahl.

Wenn Sie bei der Entscheidung Hilfe benötigen, lesen Sie "Mobile Websites im Vergleich zu systemeigenen Apps und Hybrid-Apps" unter msdn.microsoft.com/magazine/dn818502. Sobald Sie eine klare Vorstellung haben, was Sie erstellen möchten, ist der nächste Schritt das Veranschaulichen der Architektur der App. Weitere Informationen dazu, wie Sie Ihre mobile Website oder App planen, finden Sie in meiner Kolumne "Entwerfen einer plattformübergreifenden modernen App-Architektur" unter msdn.microsoft.com/magazine/dn683800.

Unabhängige Entwickler, die für App Stores entwickeln, befolgen das "Mobil zuerst"-Prinzip. Ihre Bereitstellungsziele sind meist eine oder mehrere App Stores. Entwickler in Unternehmen neigen zur Bereitstellung an einem Speicherort in ihrem internen Netzwerk oder in ihrer privaten Cloud.

Bei der Unternehmensentwicklung hat JavaScript viel an Bedeutung gewonnen. Entwickler führen es sogar auf dem Server aus. Mittlerweile ist JavaScript wahrscheinlich die beliebteste Programmiersprache der Welt. Ob es Ihnen gefällt oder nicht: Entwickler nutzen JavaScript als die einfachste Möglichkeit, plattformübergreifende Software in Form einer Webanwendung bereitzustellen. Selbst Entwickler in Unternehmen nutzen JavaScript, um Benutzeroberflächen von Unternehmensanwendungen zu verbessern. Dies gilt insbesondere angesichts der Entwicklung zum BYOD (Bring Your Own Device) in Unternehmen, da immer mehr Mitarbeiter ihre iPad- und Surface-Tablets und Smartphones an ihre Arbeitsplätze mitbringen.

Wenn Sie JavaScript- oder SPA-Apps für Unternehmen schreiben, sollten Sie TypeScript in Erwägung ziehen. In TypeScript sind alle ECMAScript-6-Anforderungen implementiert, auf die Entwickler schon lange warten, z. B. Vererbung sowie wie verschiedene Typen, Objektorientierung und andere Features, mit denen eine bessere Code-, Datei- und Projektorganisation möglich wird. Es ist eine gute Idee, sich mit den Entwurfsmustern für die Benutzeroberfläche und den Entwicklungsmustern vertraut zu machen. Beide unterstützen eine besser organisierte Projektstruktur. Vor der Verwendung von TypeScript in den JavaScript-Projekten Ihres Unternehmens sollten Sie "Verwenden von TypeScript in modernen Apps" unter msdn.microsoft.com/magazine/dn201754 lesen.

Zusammenfassung

Die wichtigste Botschaft dieses Artikels ist, dass das Softwareentwicklungsprinzip "Mobil zuerst" eine Skalierung auf eine größere Plattform vereinfacht. Progressiv entwickelte Benutzeroberflächen stehen oft für eine modularere Architektur. Dadurch wird es grundsätzlich einfacher, Code zu verwalten und neue Funktionen hinzuzufügen. Benutzer schätzen zudem eine ansprechende, überlegt entworfene Benutzeroberfläche. Ein "Mobil zuerst"-Strategie erzwingt, dass Sie sich auf die wichtigsten Daten und Features konzentrieren. Es sind diese Features, die für hohe Bewertungen und höhere Umsätze in App Stores sorgen.

Rachel Appel ist Beraterin, Autorin, Mentorin und frühere Microsoft-Mitarbeiterin mit über zwanzigjähriger Erfahrung in der IT-Branche. Sie nimmt an wichtigen Branchenkonferenzen wie Visual Studio Live!, DevConnections und MIX als Rednerin teil. Ihr Fachbereich ist die Entwicklung von Lösungen, bei denen geschäftliche und technologische Aspekte in Einklang gebracht werden und in denen führende Microsoft- und offene Webtechnologien zum Einsatz kommen. Besuchen Sie Rachel Appel auf ihrer Website unter rachelappel.com.

Unser Dank gilt dem folgenden technischen Experten von Microsoft für die Durchsicht dieses Artikels: Frank La Vigne