@@ -37,5 +37,85 @@ Es ist also klar zu sehen wie wichtig es ist bei dem Design einer entsprechenden
...
@@ -37,5 +37,85 @@ Es ist also klar zu sehen wie wichtig es ist bei dem Design einer entsprechenden
Gerade bei einem Tool wie dem Accelerator wo die Interaktion klar im Fokus steht, stellt sich hier eine spannende Frage: Sollte man zu Gunsten der Benutzererfahrung auf Features verzichten?
Gerade bei einem Tool wie dem Accelerator wo die Interaktion klar im Fokus steht, stellt sich hier eine spannende Frage: Sollte man zu Gunsten der Benutzererfahrung auf Features verzichten?
Auch diese Frage war in verschiedenen Formen Teil der durchgeführten Nutzerumfrage, im Folgenden findet sich die Übersicht dieser Teilantworten:
Auch diese Frage war in verschiedenen Formen Teil der durchgeführten Nutzerumfrage, im Folgenden findet sich die Übersicht dieser Teilantworten:
Abbildung 1: Ergebnis von Frage zur Präferenz von mobilen Features von 1 (Stimme voll zu) bis 5 (Stimme gar nicht zu)
Klar zu sehen ist hier, dass deutlich über die Hälfte der Teilnehmer der Aussage zustimmen oder keine Meinung dazu nehmen. Nur neun stimmen der Aussage nicht zu. Hier schein eine Bereitschaft zu bestehen auf Features zu verzichten, sofern eine gewisse Qualität an Benutzererfahrung sonst nicht geboten werden kann.
In diesem Zusammenhang ist auch die Frage nach der generellen Nutzung interessant: Nutzen mobile Anwender überhaupt Features, die mit einer direkten Interaktion zusammenhängen?
Abbildung 2: Ergebnis von Frage zur Nutzung von Interaktionen auf mobilen Geräten von 1 (Stimme voll zu) bis 5 (Stimme gar nicht zu)
Auch wenn die Verteilung hier nicht ganz so eindeutig ist wie bei Abbildung 1, so scheint zumindest eine Mehrheit der Aussage zuzustimmen.
Sollte die Entscheidung zur Streichung von Features tatsächlich fallen, so ist es natürlich auch essentiell zu wissen, welche Features von Nutzern besonders wertgeschätzt werden:
Abbildung 3: Ergebnis von Frage nach wichtigsten mobilen Features
Die ersten sechs Antwortmöglichkeiten in Abbildung 3 waren gegeben, weitere konnten über ein Freitextfeld hinzugefügt werden. Es konnten mehrere Antworten angekreuzt werden. Auffällig ist, dass grundsätzlich eher wenig interaktive Features oft gewählt wurden.
Abschließend lässt sich hier also sagen, dass es eine mehr oder wenige deutliche Mehrheit gibt, die bereit wäre in einer mobilen Variante Features zu Gunsten einer besseren Benutzererfahrung zu streichen. Diese Mehrheit ist allerdings nicht eindeutig genug um blind dieser Schlussfolgerung zu folgen. Stattdessen sollen die Anforderungen einzeln analysiert und abgewogen werden, inwiefern diese mobil umgesetzt werden können.
# Anforderungsanalyse
Folgende Tabelle zeigt eine Liste aller identifizierten Anforderungen an die aktuelle (Desktop-)Version des Accelerators sowie einen Hinweis ob diese auch sinnvoll in einer mobilen Variante implementiert werden könnten:
Tabelle 1: Anforderungen an aktuelle und mobile Variante des Accelerators
Nach sorgfältiger Analyse der aktuellen Anforderungen wurde sich bei lediglich zwei Features dazu entschieden, auf diese zu verzichten.
Dies beinhaltet zum einen die Möglichkeit in den Fullscreen zu gehen, da dies mobil nicht nötig ist und ein überflüssiges Feature darstellt.
Zum anderen geht es um ein spezielles Draggable: Das Whiteboard. Das Whiteboard als Feature an sich ist auch mobil sinnvoll und sollte implementiert werden. Als Draggable stellt dies auf den kleinen Bildschirmen jedoch eine zu große Informationsvielfalt dar, da es z. B. zu der Situation kommen kann, dass auf ein existierendes Whiteboard das Draggable Whiteboard gezogen wird. Auch der Mehrwert dieses Features ist überschaubar, weswegen auf dieses Feature verzichtet wird. Es besteht jedoch die Möglichkeit hier einen Unterschied zwischen einer Umsetzung für Smartphones und Tablets zu machen und dieses Feature z. B. nur auf Smartphones auszuschalten.
Es wurde sich also bis auf zwei Ausnahmen dazu entschieden, alle Features der aktuellen Version des Accelerators in eine mobile Umsetzung aufzunehmen.
# Technische Umsetzung
Bei der Entwicklung einer mobilen Applikation gibt es grundsätzlich drei verschiedene technologische Ansätze die man wählen kann.
## Nativ
In puncto Qualität, Benutzererfahrung und Performance ist der native Ansatz die mit Abstand beste Wahl. Der große Nachteil ist jedoch, dass zwei separate Applikationen erstellt werden müssen: Eine für Android und eine für iOS. Dies ist nicht nur zeitaufwändig, sondern benötigt auch passende Kenntnisse in Java oder Swift bzw. Objective-C. Sollte man also nicht die Zeit oder das Wissen haben, ist von diesem Ansatz eher abzuraten.
**Vor- und Nachteile:**
- Performance
- UI/UX kann perfekt auf OS abgestimmt werden
- Zeitaufwendig
- Know-How muss vorhanden sein
**Typische Umsetzung mit:** Xcode, Android Studio
## Hybrid
Für den Hybrid-Ansatz wird eine App für beide mobilen Betriebssysteme basierend auf bekannten Sprachen wie HTML, CSS und JavaScript aufgebaut. Diese werden innerhalb eines Containers dargestellt und können als Webseite ausgegeben werden. Die großén Freiheiten in der Wahl der Sprache, die Flexibilität und schnelle Entwicklung gehen jedoch einher mit einer mäßigen Performance und großen Aufwänden für eine annehmbare Benutzererfahrung.
**Vor- und Nachteile:**
- Gleiche Codebasis
- Schnellste Entwicklung
- Freiheit in Wahl der Sprache
- Mäßige Performance
- UI/UX eingeschränkt
- Zugriff auf Hardware eingeschränkt
**Typische Umsetzung mit:** Ionic, Cordova
## Cross-Plattform
Auch beim Cross-Plattform-Ansatz hilft eine gemeinsame Code-Basis eine schnelle Entwicklung möglich zu machen. Die genutzten Technologien für diesen Ansatz setzen hauptsächlich auf JavaScript und bieten trotz des Cross-Plattfrom-Ansatzes eine annehmbare Performance und Benutzererfahrung.
**Vor- und Nachteile:**
Gleiche Codebasis
Schnelle Entwicklung
Freiheit in Wahl der Sprache
Mäßige Performance
**Typische Umsetzung mit:** Flutter, React Native
Verzicht auf Hybrid
Im Vergleich zwischen dem Nativ- und Cross-Plattform-Ansatz würden wir abschließend die Empfehlung für den Cross-Plattform-Ansatz aussprechen. Der große Nachteil für den Nativ-Ansatz ist der hohe Zeitaufwand und das nötige Know-How um die großen Nachteile dieses Ansatzes auch wirklich sehen und spüren zu können. Da der Accelerator von Studenten weiterentwickelt wird stellt dies wohl keine sinnvolle Variante dar. Zum einen müssten zwei Teams daran arbeiten, da eine Version für Android und eine für iOS erstellt werden müsste und ob sich überhaupt Studenten finden, die mit Sprachen? Vertraut sind ist im Vergleich zu den anderen Ansätzen eher unwahrscheinlich.
