WebApp Designrichtlinien
In der mir vorliegenden Fachliteratur zur Programmierung von WebApps werden die Designrichtlinien meiner Meinung nach vernachlässigt. Markus Spiering & Sven Haiges verwenden beispielsweise für das gesamte Thema lediglich die Seiten 21 und 22 und führen dort stichwortartig einige Punkte auf. Ich werde daher in diesem Artiekl einige Designaspekt (zusätzlich zu den in der Literatur genannten) unter Zuhilfenahme der Designrichtlinien für native iOS Apps herausarbeiten bzw. selbst entwickeln und begründen.
Klare Strukturen
Eine Smartphone App unterscheidet sich stark von einer Software, die auf einem Desktop PC läuft. Apps haben immer nur einen einzigen ganz bestimmten Zweck. Komplexe, verschachtelte Menüs mit Tausenden von Funktionen, die die meisten Nutzer nie, oder nur in sehr seltenen Fällen brauchen, widersprechen der mobilen Nutzung. Bei mobiler Nutzung muss immer davon ausgegangen werden, dass der Zeitraum, der zur Nutzung der App zur Verfügung steht, sehr klein ist. Der Nutzer muss die Chance haben die App „nebenbei“ zu benutzen. Sie muss daher einfach strukturiert sein, eine klarer Nutzungsabfolge bieten und nur die nötigsten Dinge zur Auswahl stellen, ohne, dass beim Nutzer das Gefühl aufkommt bevormundet zu werden.
Eine Möglichkeit dies zu realisieren ist vieles über kaskadierte Tableviews (quasi eine Liste, die beim Antippen eines Listenpunktes zu einer weiteren Liste oder einer Detailansicht führt) abzubilden. Der Benutzer findet damit eine klare Struktur und wird sicher durch den Programmablauf geführt.
Des weiteren sollten alle Masken so gestaltet sein, dass der Nutzer in der Lage ist alle an dieser Stelle der App wichtigen Informationen auf einen Blick zu erkennen. In diesem Zuge kann es sinnvoll sein Informationen auf- bzw. in mehreren Masken zu verteilen, statt, wie in der Desktop Programmierung üblich, eine große Übersichtsseite zu erzeugen.
Keine Deko
Einige Icons als Eye Candy wecken Gefallen beim Nutzer und sind daher sinnvoll. Alles darüber hinausgehende wirkt eher verwirrend, da der ohnehin schon kleine Bildschirm von Elementen belegt wird, die keine Funktion haben. Im schlimmsten Fall müsste sogar eine weitere Hierarchiestufe in die beispielhaft genannten Tableview-Kaskade eingeführt werden, um den Platzverlust zu kompensieren. Dies würde nicht zur Benutzerfreundlichkeit der App beitragen. Außerdem müssen Bilddaten etc. bei einer WebApp mindesten beim ersten Start vom Server geladen werden, was zu einer relativ langen ersten Start-Up Phase und damit zur Ablehnung der App durch den Nutzer führen kann.
Berechnungen serverseitig
Bei einer Datenbank basierten Web-App sollte die Datenverarbeitung serverseitig vorgenommen werden. Geht man davon aus, dass auf dem Server, auf Grund der Einstellungen in der App, ein „Daten-Set“ generiert und das komplette Set zum Client übertragen wird, erscheint dies auf den ersten Blick ineffizient. Andererseits werden auf diese Art ausschliesslich genau die Daten übertragen, die die Web-App für einen flüssigen Programmablauf benötigt. Bei diesen Daten handelt es sich in der Regel um reine Textdaten (geringe Datenmenge), die grundsätzlich dem aktuellen Stand auf dem Server entsprechen.
Würden die Inhalte der Datenbank auf dem Client dauerhaft gespeichert werden, müssten beim Programmstart alle Einträge auf eventuelle Veränderungen überprüft werden. Diese Prüfungen würden, im Gegensatz zum reinen Anzeigen von HTML Code, zu einer deutlich erhöhten Prozessorlast und damit zu einer verkürzten Akkulaufzeit führen, selbst wenn sie hocheffizient und sehr schlank programmiert wären.
Netzwerkverbindungen minimieren
Die größten Stromverbraucher in einem Smartphone, neben dem Bildschirm, sind die verschiedenen Systeme zur drahtlosen Datenübertragung. Die Nutzung von Netzwerkverbindungen sollte also so weit wie möglich vermieden werden. Bei einer datenbankbasierten WebApp kann man die zu übertragenden Daten minimieren und gleichzeitig die Datenbank konsistent halten, in dem man beim Start der WebApp ein „Daten-Set“ generiert, und ab dann nur noch einzelne IDs mit dem Server austauscht, beispielsweise wenn einem Warenkorb ein Artikel hinzugefügt werden soll.
Eine weitere Methode Netzwerkverbindungen zu minimieren ist der Einsatz von AJAX. AJAX erlaubt es unter anderem einzelne Teile der WebApp auszutauschen ohne dafür das komplette Fenster im Browser neu laden zu müssen. Wechselt der Nutzer innerhalb der WebApp von einer statischen Maske (z.B. der Anzeige der Produkten) zu einer dynamischen Maske (z.B. der Anzeige seiner aktuellen Bestellung) reduziert AJAX den Overhead erheblich, da z.B. Header Infos oder auch statische Seiten- bzw. Maskenelemente nicht neu vom Server geladen werden müssen.
Um den Netzwerkverkehr, der durch die Übertragung rein statischer Daten verursacht wird, wie. z.B. Grafiken, Buttons, Icons, JavaScript Bibliotheken, zu minimieren, wird der HTML5 Application Cache eingesetzt. Der Application Cache erlaubt es Dateien bis zu einer Gesamtgröße von 5 Megabyte in einer Cache Manifest Datei aufzulisten und diese für die Zukunft auf dem Smartphone vorzuhalten.
Gute Bedienbarkeit mit dem Finger
Eine App muss motorisch einfach zu bedienen sein. Sowohl Buttons als auch Listenpunkte, etc. müssen bezüglich ihrer Größe auf dem Bildschirm so angelegt und ausgerichtet werden, dass eine Bedienung mit dem Finger möglich ist, ohne dafür die gesamte Konzentration des Nutzers einzufordern.
Tastatureingaben sollten, wo immer es möglich ist, vermieden werden, da das eingeblendete Keyboard der meisten Smartphones große Teile der Anzeigefläche verdeckt und auch für längere Texteingaben nicht sehr komfortabel ist.
Gesten sind als Eingabemöglichkeit interessant, aber nur wenn sich aus deren Einsatzes auch wirklich Vorteile bezüglich der Bedienbarkeit und des Bedienkomforts für den Benutzer ergeben. Ist dies bei einer WebApp nicht der Fall sollte der für die Behandlung von Gesten notwenigen Programmcode eingespart werden um dadurch die Ladezeit der App zu reduzieren bzw. die zu übertragende Datenmenge zu minimieren.