TeaCo-Android: Neue Plattform, neue Konzepte?

Transkript

1 Institut für Multimediale und Interaktive Systeme Direktor: Prof. Dr. rer. nat. Michael Herczeg TeaCo-Android: Neue Plattform, neue Konzepte? Redesign auf Grundlage einer iphone-optimierten Socialware Bachelorarbeit vorgelegt von: Christoph Wittstock Prüfer: Prof. Dr. rer. nat. Michael Herczeg Wissenschaftliche Begleitung: Dr. rer. nat. Martin Christof Kindsmüller

2 Kurzfassung Mit TeaCo wurde ein leichtgewichtiges Werkzeug entwickelt mit Hilfe dessen sich Termine in großen, heterogenen Gruppen leicht und komfortabel koordinieren lassen. Neben der Desktop-Variante existiert TeaCo bereits auch für mobile Browser und als native iphone-applikation. Um den Benutzerkreis von TeaCo zu erweitern, soll in dieser Arbeit basierend auf der iphone-applikation eine native Applikation für Android-Smartphones entwickelt werden. Um die Gebrauchstauglichkeit der entstehenden Applikation zu erhöhen, wird eine umfassende Analyse durchgeführt. Innerhalb dieser werden die Stärken und Schwächen der iphone-applikation ermittelt und das entstehende System daraufhin optimiert. Neben der Aufgabenanalyse wird außerdem eine Benutzer-, Organisations- und Kontextanalyse durchgeführt, um sich auf die Erwartungen der Benutzer einzustellen und die Interaktionsformen eines Android-Smartphones maximal auszuschöpfen. Die daraus resultierenden Erkenntnisse werden in der folgenden Konzeption genutzt, um ein Interfacedesign zu erstellen. Dieses Konzept wird in einem benutzerorientierten Feature Driven Development-Prozess realisiert. Abschließend wird eine summative Evaluation durchgeführt, die eine Steigerung der Gebrauchstauglichkeit gegenüber der mobilen Variante zeigen soll, da diese bisher als einzige Variante für Android-Smartphones zur Verfügung steht. Schlüsselwörter Terminkoordination, Android, iphone, Computer Supported Cooperative Work

3 Abstract Due to the development process of the TeaCo application, users were able to communicate appointments among a heterogeneous group of larger scale. The usability convinces through an easy operation structure and supports the possibility to coordinate information in a quick and simple way. The TeaCo application already exists as a mobile browser version and as a native iphone application. To expand the circle of the potential TeaCo users, this thesis includes a development of a native application for android smartphones, based on the iphone application. With the purpose of an advancement concerning factors of functionality a detailed analysis will be done in the course of this thesis. Within this analysis the strengths and weaknesses of the existing solution will be identified and transferred into the optimization of the existing system. In addition to a task-analysis a user-, organisation- and context-analysis will be conducted to adjust to the user expectations and to maximize the possibilities of interaction of the android smartphones. The resulting findings will be used for a conception to create an interface design through a feature-driven-devolopment-process. In conclusion a summative evaluation will be performed which is supposed to illustrate the increase of the usability of a native application compared to the existing mobile version for android smartphones. Keywords appointment coordination, android, iphone, computer supported cooperative work

4 Inhaltsverzeichnis Kurzfassung Abstract ii iii 1 Einleitung Ziele der Arbeit Stand der Technik Vorgehensweise Analyse Aufgabenanalyse Benutzeranalyse Organisationsanalyse Kontextanalyse Use-Cases Konzeption Systemarchitektur Interaktionsgestaltung Feature-Sets Realisierung Ruby on Rails REST Umsetzung iv

5 Inhaltsverzeichnis 5 Dialogbeispiele Login Meetingübersicht Meeting erstellen Terminvorschläge hinzufügen Meetingansicht Teilnehmer verwalten Einstellungen Evaluation Ziele Vorgehensweise und Methoden Ergebnisse Zusammenfassung und Ausblick Zusammenfassung Offene Punkte Ausblick Abbildungen 79 Tabellen 81 Quelltexte 82 Quellen 83 Literatur Software Abkürzungen 87 Glossar 89 v

6 Inhaltsverzeichnis Anhänge 92 A Interviewleitfaden B Ergebnisse der Nutzerstudie C Interviewleitfaden Evaluation D Evaluationsergebnisse Erklärung 108 vi

7 1 Einleitung Früher verabredete man sich persönlich, per Brief oder später auch per Telefon, doch heutzutage stehen viele Möglichkeiten zur Verfügung. Viele Arbeitgeber fordern erhöhte Flexibilität und ein ständiges Erreichbarsein ist selbstverständlich geworden. Je nach persönlicher Neigung oder gesammelter Erfahrungen stehen mobile Telefone, Short Message Service (SMS), -Verkehr oder andere spezifische Verfahren zur Verfügung. Doch trotz alledem ist die Terminfindung innerhalb einer größeren Gruppe stets schwierig zu bewältigen. Um der Schnelllebigkeit standhalten und flexibel und einfach ganz nebenbei einen gemeinsamen Termin mit mehreren Personen finden zu können, wurde der Terminund Teamkoordinator TeaCo entwickelt. Neben der Desktop-Variante dieses Systems (TeaCo-Desktop, Lohrenz (2009), Abbildung 1), wurde bereits eine mobile Variante TeaCo-Mobile (Roenspieß, 2009) für mobile Browser, speziell für das iphone, respektive Safari Mobile, und die native iphone-applikation TeaCo-iPhone (Schröder (2010), Abbildung 2) entwickelt. Seit der Weiterentwicklung von TeaCo- Mobile, welche auch für weitere mobile Plattformen optimiert wurde, steht die Variante TeaCo-Mobile- NG (Kalus & Wittstock (2011), Abbildung 3) zur Verfügung. Um die TeaCo-Applikation mit einem Android-Smartphone erreichen zu können, steht folglich TeaCo- Mobile zur Verfügung. Da TeaCo-Mobile jedoch in erster Linie auf das Apple iphone, respektive Safari Mobile, optimiert wurde und Web-Applikationen im Allgemeinen nicht auf die Hardware-Funktionen eines Smartphones zugreifen können, ließen sich sowohl Performance, als auch Gebrauchstauglichkeit durch eine native Applikation erheblich steigern. Da derzeit ca. 37% aller Smartphone-Besitzer ein Gerät mit dem Android Operating System (OS) nutzen (The Nielsen Company, 2011), soll im Rahmen der vorliegenden Arbeit auf Grundlage des Android Software Development Kit (SDK) eine native Applikation für das Android OS entstehen. 1

8 1 Einleitung Abbildung 1: Meetingansicht in TeaCo-Desktop Abbildung 2: Meetingansicht in TeaCo-iPhone Abbildung 3: Meetingansicht in TeaCo-Mobile- NG 2

9 1 Einleitung 1.1 Ziele der Arbeit Im Rahmen dieser Arbeit soll ergänzend zu den bereits vorhandenen Umsetzungen von TeaCo eine native Applikation für das Android OS entwickelt werden. Dabei sollen in Anlehnung an das bereits vorhandene System TeaCo-iPhone die Stärken und Schwächen analysiert und das System optimiert werden. Im Zuge dieser Analyse können Interaktionsformen der iphone-applikation übernommen oder angepasst werden. Die Möglichkeiten eines Android-Smartphones werden während dieser Arbeit weitestgehend ausgeschöpft, wodurch der Funktionsumfang vergrößert wird. Das Corporate Design soll einerseits an das TeaCo-System angepasst, andererseits sollen die Prinzipien des Android-Interfacedesigns berücksichtigt werden. Besondere Anlehnung findet das Design an die TeaCo-iPhone Version, wobei dort darauf geachtet werden soll, den Bezug zu TeaCo-Desktop nicht zu verlieren. Dem Benutzer soll die neue Applikation in einer bereits bekannten Anwendungsumgebung präsentiert werden, wodurch ein leichter Einstieg ermöglicht werden soll. 1.2 Stand der Technik Obwohl eine Vielzahl von Systemen zur webbasierten Terminfindung existiert (Tungle 1, NeedtoMeet 2, When is Good 3, ScheduleOnce 4, timebridge 5 ), beschränkt sich die Auswahl an entsprechenden Umsetzungen für das Android-Smartphone auf eine Applikation: Doodle. Diese Applikation soll im Folgenden im Vergleich zu der Variante von TeaCo, entwickelt für das iphone, dargestellt werden. Der Google-Kalender soll ebenfalls als Vergleich zu den bereits genannten Varianten dargestellt werden. Kalenderwerkzeuge sind den Möglichkeiten zur Terminfindung ähnlich und da dieser standardmäßig in jedem Android-Smartphone integriert ist, kann dieser als Vergleichsmaßstab dienen. Zur besseren Verständlichkeit werden an dieser Stelle einheitliche Begriffe eingeführt, die für den Rest der Arbeit verwendet werden. Die Sammlung von Terminvorschlägen, auf die abgestimmt wird, wird als Meeting

10 1 Einleitung bezeichnet. Der Initiator ist die Person, welche dieses Meeting erstellt und anschließend einen oder mehrere weitere Teilnehmer dazu einlädt Doodle Doodle (Doodle AG, ) stellt wie TeaCo einen Online-Terminplaner dar, der in mehreren Varianten, wie einer iphone-applikation und einer Applikation für Android-Smartphones, verfügbar ist. Die Planung von Terminen kann direkt ohne Angabe von persönlichen Daten oder einer Anmeldung erfolgen. Des Weiteren besteht die Möglichkeit, ein persönliches Konto zu erstellen, welches die Organisation aller Meetings ermöglicht, an denen der Benutzer beteiligt ist. Um diese Option einzurichten, ist die Angabe einer -Adresse erforderlich. Im Wesentlichen bietet Doodle die folgenden drei Funktionen: Terminfindung: Innerhalb eines Meetings wird ein passender Terminvorschlag gewählt; Abstimmung: Umfrage mit beliebig vielen Antwortmöglichkeiten; MeetMe: Diese Funktion gewährt einen Einblick in den persönlichen Kalender innerhalb dessen Terminanfragen erstellt werden können. Die Android-Applikation von Doodle bietet abgesehen von MeetMe den gleichen Funktionsumfang wie die Desktop-Variante. Nach dem Start der Applikation wird entschieden, ob ein Termin gefunden werden, oder nach einer Registrierung und einem Login mit Doodle verbunden werden soll. Nach der Anmeldung öffnet sich die Meetingübersicht (vgl. Abbildung 4), welche unterteilt ist in eigene Meetings und Meetings, an denen der Benutzer beteiligt ist. In Abbildung 5 ist vergleichend zur Meetingansicht in TeaCo (Abbildung 2 und 3) eine Meetingansicht von Doodle zu sehen. 4

11 1 Einleitung Abbildung 4: Übersicht der Meetings der Doodle-App Abbildung 5: Meetingansicht der Doodle-App TeaCo-iPhone TeaCo kann auf einem Android-Smartphone derzeit ausschließlich über TeaCo-Mobile-NG bedient werden. Diese Variante stellt im Wesentlichen alle Funktionen bereit, die TeaCo bietet. Lediglich spezifische Interaktionen wie Drag and Drop oder das Darstellen von Hover-Effekten sind in TeaCo- Mobile-NG nicht vorhanden. Außerdem wurde diese Variante in erster Linie für das iphone, respektive Safari Mobile, optimiert. Aus diesem Grund gilt es, die entstehende Applikation TeaCo-Android hinsichtlich Performance und Gebrauchstauglichkeit zu optimieren. Die Möglichkeiten eines Android- Smartphones werden von der bestehenden TeaCo-Variante bei weitem nicht ausgeschöpft. In diesem Zusammenhang wäre es denkbar, auf das Adressbuch oder die GPS-Koordinaten des Benutzers zuzugreifen. In Abbildung 6 ist die Meetingübersicht und in Abbildung 7 eine Meetingansicht von TeaCo- Mobile-NG auf einem Android-Smartphone zu sehen. 5

12 1 Einleitung Abbildung 6: Meetingübersicht in TeaCo- Mobile-NG auf einem Android- Smartphone Abbildung 7: Meetingansicht in TeaCo- Mobile-NG auf einem Android- Smartphone Google-Kalender Der Google-Kalender stellt das Kalenderwerkzeug des Android-Smartphones dar und ist fest in das Betriebssystem integriert. Der Kalender ist sowohl in einer Basis-, als auch in einer optimierten Version verfügbar. Mit Hilfe der Basisversion lassen sich ausschließlich die eigenen Kalender anzeigen und neue Termine anlegen. Die optimierte Version des Kalenders kann sowohl auf Android-, als auch auf iphone- und HP webos-geräten verwendet werden (Google Inc., ). Diese Version ermöglicht, dass Termine und deren Details hinzugefügt, bearbeitet und gelöscht werden können, sowie auf Termine geantwortet werden kann. Die Abbildung 8 stellt den Google-Kalender in der Monatsansicht auf dem Android-Smartphone dar. Neben den vorhandenen Umsetzungen in Teaco-iPhone und 6

13 1 Einleitung TeaCo-Mobile-NG stellt dies eine denkbare Option für die Übersicht von Terminvorschlägen in der Applikation TeaCo-Android dar. Abbildung 8: Google-Kalender, Monatsansicht 1.3 Vorgehensweise Bei der Entwicklung von TeaCo-Android soll das Prinzip des Feature Driven Development (FDD) angewandt werden. Hierbei wird eine Liste aller geplanten Features erstellt, welche wiederum in so genannte Feature-Sets gruppiert werden. Daran anschließend werden die Features priorisiert und entsprechend der Prioritätenliste umgesetzt. Die Realisierung eines Features umfasst dessen Entwurf und Konstruktion (vgl. Abbildung 9). 7

14 1 Einleitung Erstellung der Feature List Planung der einzelnen Features Entwurf des Features Entwicklung des Gesamtmodells Konstruktion des Features Abbildung 9: FDD-Entwicklungsprozess (nach Coad, Lefebvre & Luca (1999)) Außerdem soll der Entwicklungsprozess User Centered Design (UCD) Anwendung finden. Der Benutzer wird während dieses Vorgangs in den Mittelpunkt des Prozesses gestellt, wodurch eine hohe Gebrauchstauglichkeit erzielt werden soll. Die benutzerorientierte Evaluation (Herzeg, 2009, Seite 215 ff.) spielt hier eine bedeutende Rolle und der iterative Prozess der Anpassung des Features wird durch Benutzerbefragungen begleitet und das Feature folglich optimiert (vgl. Abbildung 10). Neben diesem Vorgehen der formativen Evaluation sollen aber auch die Benutzerpartizipation und die summative Evaluation zum Einsatz kommen. Bei der Benutzerpartizipation werden zukünftige Benutzer bereits während der Analyse- und Konzeptionsphase der Entwicklung einbezogen. Das entstehende System kann somit auf die Wünsche und Bedürfnisse der Benutzer angepasst werden und erreicht eine höhere Akzeptanz durch eine intensivere Identifizierung. Durch diese Integration der Benutzer können deren Erfahrungen und Anregungen den Entwicklungsprozess positiv unterstützen, insbesondere hinsichtlich einer möglichen ungünstigen Gestaltung von Benutzerschnittstellen (Herzeg, 2009, Seite 217 f.). Am Ende der Systementwicklung wird eine Evaluation durchgeführt, mit Hilfe derer das System bewertet und qualitativ eingestuft werden soll. Anhand dieser summativen Evaluation soll gezeigt werden, dass mit der nativen Android-Applikation gebrauchstauglicher als mit TeaCo-Mobile-NG gearbeitet werden kann. In Abbildung 10 ist dargestellt, wie UCD und FDD zusammengeführt werden können und die gerade aufgeführten Evaluationen zum Einsatz kommen. Im folgenden 2. Kapitel werden zunächst die Anforderungen an das neue System dargestellt. Dies geschieht durch eine Benutzer-, Aufgaben-, Kontext- und Organisationsanalyse. Aus diesen gewonnenen Informationen soll eine Konzeption entstehen, die sich in Kapitel 3 wiederfindet. Die Realisierung der Konzeption wird anschließend in Kapitel 4 beschrieben. Dieses neu entstandene System wird exemplarisch anhand von Dialogbeispielen in Kapitel 5 vorgestellt. Die abschließende summative Evaluation 8

15 1 Einleitung des Systems und dessen Ergebnisse sind innerhalb des 6. Kapitels beschrieben. Und letztlich sind die Zusammenfassung der Arbeit und ein Ausblick in Kapitel 7 zu finden. Abbildung 10: Prozessmodell unter Verwendung von FDD (dunkel) und UCD (hell) (Roenspieß, 2009) 9

16 2 Analyse In der folgenden Aufgabenanalyse werden die Anforderungen an TeaCo-Android, welche denen der TeaCo-iPhone-Applikation sehr ähnlich sind, dargestellt. Die Klassifikation der Benutzer soll in der Benutzeranalyse in Abschnitt 2.2 genauer erläutert werden. Innerhalb der Kontextanalyse (Abschnitt 2.4) soll anschließend die technische Umgebung betrachtet werden. Dies beinhaltet sowohl Hard- als auch Software und untersucht speziell auch die Interaktionsformen eines Android-Smartphones hinsichtlich ihrer Einsetzbarkeit. Abschließend wird in Kapitel 2.5 der entstehende Funktionsumfang der Applikation in Form von Use-Cases beschrieben. 2.1 Aufgabenanalyse Ein traditioneller Terminfindungsprozess lässt sich nach Lohrenz (2009) in folgende sechs Phasen gliedern (vgl. Abbildung 11): (1) Der Initiator beginnt mit der Planung eines Meetings, indem er sich ein oder mehrere Terminvorschläge überlegt, an denen er Zeit hat und das Meeting stattfinden soll. (2) Im nächsten Schritt unterbreitet der Initiator diese Vorschläge allen Personen, die für das Meeting wichtig sind, auf beliebigem Weg. (3) Die Teilnehmer des Meetings entscheiden nun über diese Terminvorschläge und teilen dem Initiator ihre Entscheidung mit. Eventuell unterbreitet der ein oder andere Teilnehmer neue Terminvorschläge, weil ihm keiner der vorgeschlagenen Termine zusagt. (4) Kommen neue Terminvorschläge in Frage, so werden diese vom Initiator oder dem Vorschlagenden selbst allen Teilnehmern mitgeteilt und es wird erneut auf Rückmeldung gewartet (3 ). 10

17 2 Analyse (5) Der Initiator wählt auf Grundlage der Abstimmungsergebnisse den geeignetsten Terminvorschlag. (6) Zuletzt teilt der Initiator allen Teilnehmern den endgültigen Termin oder die endgültigen Termine mit. Abbildung 11: Traditioneller Terminfindungsprozess (Lohrenz, 2009) Durch dieses Modell entsteht jedoch ein erheblicher Engpass an Stelle des Initiators, da dieser die globale Verwaltung von Terminen innehat. Aus diesem Grund ist bereits Lohrenz (2009) während der Analyse und Konzeption zu dem Entschluss gekommen, von diesen traditionellen Phasen abzuweichen und den Terminfindungsprozess zu optimieren. TeaCo-Desktop und infolgedessen auch alle weiteren Varianten von TeaCo verzichten auf die Rolle des zentralen Mediums in Form des Initiators und weisen diese Rolle dem TeaCo-System zu. Dadurch werden alle Informationen eines Teilnehmers, wie Abstimmungen zu einem Terminvorschlag, Terminänderungen oder Kommentare, jedem anderen Teilnehmer zugänglich gemacht und müssen nicht zeitaufwändig von dem Initiator an jeden Teilnehmer weitergeleitet werden. Reaktionen von Teilnehmern werden demzufolge unmittelbar durch das Anwendungssystem für die anderen Benutzer sichtbar. Eine weitere Anforderung an das entstehende System ist die Möglichkeit, TeaCo allen potenziellen Teilnehmern auch unter Verwendung unterschiedlicher Geräte oder sogar Geräteklassen zugänglich zu machen. Um die Gebrauchstauglichkeit für alle Benutzergruppen (vgl. Abschnitt 2.2) zu gewährleisten, soll das Anwendungssystem sowohl unmittelbar verständlich, als auch schnell und einfach erlernbar sein. 11

18 2 Analyse Abbildung 12: Terminfindungsprozess mit Hilfe von TeaCo (Lohrenz, 2009) In Abbildung 12 ist der durch TeaCo unterstützte Terminfindungsprozess dargestellt. Zu Beginn der Terminfindung hat ein Benutzer eine Idee für ein Meeting und übernimmt so die Rolle des Initiators (1). Dieser Initiator richtet schließlich ein Meeting in TeaCo ein, innerhalb dessen er seine Terminvorschläge einträgt (2). In Anbetracht dessen, dass der Initiator die Termine vorschlägt, geht das Anwendungssystem automatisch davon aus, dass dieser an den Terminen verfügbar ist und stimmt automatisch für ihn ab. Im Anschluss werden weitere Teilnehmer zu dem Meeting eingeladen, die über die erstellten Terminvorschläge abstimmen (3). Um die Abstimmung durchzuführen, steht den Teilnehmern entsprechend einer Ampelmetapher die Optionen Ja (Grün), Vielleicht (Gelb) und Nein (Rot) zur Verfügung (vgl. Abbildung 13). Abbildung 13: Terminvorschlag in TeaCo-Desktop mit Abstimmungsbuttons in Ampelmetapher (oben rechts) Die eingeladenen Teilnehmer können jedoch auch selbst neue Terminvorschläge erstellen, über die alle weiteren Teilnehmer inklusive des Initiators abstimmen müssen. Wurde über alle Terminvorschläge 12

19 2 Analyse abgestimmt oder im Vorhinein bereits ein geeigneter Termin gefunden, können ein oder mehrere Terminvorschläge als endgültig markiert werden. Dies geschieht abhängig von der Rechtevergabe entweder durch den Initiator selbst oder durch einen beliebigen Teilnehmer des Meetings. Bei der Eröffnung des Meetings entscheidet der Initiator darüber, ob das entstehende Meeting eingeschränkt sein soll und nur der Initiator Terminvorschläge manipulieren, Teilnehmer ausladen und endgültige Termine auswählen kann oder ob allen Teilnehmern des Meetings diese Interaktionen möglich sind. Abschließend wird allen Teilnehmer per mitgeteilt, welche Termine für das Meeting ausgewählt wurden (4). 2.2 Benutzeranalyse Wie in Kapitel 1.3 erläutert, stellt der UCD-Entwicklungsprozess einen elementaren Bestandteil der Benutzeranalyse dar. Die zukünftigen Benutzer sollen anhand ihrer bereits vorhanden Erfahrungen mit TeaCo zunächst in zwei Benutzergruppen eingeteilt werden. Die daran anschließenden Benutzerinterviews bauen auf die Erfahrungen der beiden bestimmten Benutzergruppen auf und sollen einen Einblick in die Anforderungen, Wünsche und Anregungen der Benutzer in Bezug auf TeaCo geben. Anhand der gewonnenen Informationen soll für TeaCo-Android eine Basis geschaffen werden, diese Applikation möglichst gebrauchstauglich entwickeln zu können. Die Ergebnisse und die daraus interpretierten Schlussfolgerungen werden in Kapitel dargestellt Zielgruppen Wie bereits im vorherigen Abschnitt erläutert, lassen sich die Benutzer von TeaCo anhand ihrer Erfahrungen in zwei Benutzergruppen einteilen. In der ersten Gruppe befinden sich die Benutzer, die das Anwendungssystem zum ersten Mal benutzen und bei denen noch kein Vorwissen über die Funktionen und den Ablauf des Systems vorhanden ist. Diese werden im Folgenden Novizen genannt. Die zweite Gruppe wird von den sogenannten Experten gebildet. Diese Benutzer haben das Anwendungssystem und seine Funktionen bereits kennen gelernt und sind im Umgang mit diesem vertraut. Von einer dritten möglichen Gruppe, der Gelegenheitsbenutzer, wird an dieser Stelle abgesehen, da sich Be- 13

20 2 Analyse nutzer in einem leichtgewichtigen Werkzeug wie TeaCo schnell von Novizen zu Experten entwickeln und ein Übergang von der Benutzergruppe der Novizen zu den Experten fließend ist. Da sich die Anforderungen und Ziele der beiden Benutzergruppen teilweise grundsätzlich unterscheiden können, muss darauf geachtet werden, dass das Anwendungssystem so konzipiert wird, dass es beiden Benutzergruppen gerecht wird. Sowohl die für die Experten vorhandenen erweiterten Funktionen als auch die für die Novizen wichtigen essentiellen Funktionen müssen gleichermaßen verfügbar und erreichbar sein. Für die Experten, die bereits Routine im Umgang mit TeaCo haben, einige sogar Nutzer von TeaCo-iPhone oder TeaCo-Mobile-NG sind, sollen die fortgeschrittenen Funktionen, die zu einer effizienteren Nutzung des Anwendungssystem führen, erreichbar sein. Die Leichtgewichtigkeit und die hohe Gebrauchstauglichkeit der TeaCo-Applikation sind besonders für die Novizen von großer Bedeutung. Das Ziel besteht darin, die Anforderungen der Novizen und der Experten miteinander zu verbinden. Es wird davon ausgegangen, dass die Novizen bisher keine Erfahrungen mit TeaCo und unter Umständen auch mit keinem anderen Kalenderwerkzeug gesammelt haben. Doch wie lernen die Novizen Tea- Co als Kalenderwerkzeug kennen? Eine Möglichkeit besteht darin, dass der Benutzer von einem anderen Teilnehmer zu einem Meeting eingeladen wird. Über diese Einladung wird der Novize durch eine informiert, wodurch er TeaCo jedoch abhängig davon, ob die an einem Desktop-PC oder auf einem Smartphone geöffnet wird, als TeaCo-Desktop oder TeaCo-Mobile-NG kennenlernt. Die Benutzer werden versuchen die in der jeweiligen Variante gesammelte Erfahrung auf die TeaCo- Android-Applikation zu übertragen. Aus diesem Grund sollten die bekannten Funktionalitäten und das, an die anderen Versionen von TeaCo angelehnte, visuelle Design zur Verfügung stehen, um einen Wiedererkennungswert zu erzeugen und die Bedienung zu vereinfachen. Eine weitere Möglichkeit besteht darin, dass der Novize von TeaCo-Android erfährt, ohne vorher bereits in Kontakt mit einer Variante von TeaCo getreten zu sein. In diesem Fall ist es besonders wichtig, dass TeaCo-Android eine hohe Selbstbeschreibungsfähigkeit und Fehlertoleranz (nach DIN EN ISO (2006)) besitzt, damit die Bedienung des Anwendungssystem auch durch bereits bekannte Interaktionsformen des Android-Smartphones schnell und einfach verständlich wird. Die nach Norman (1988) beschriebene Affordanz, nach der Interaktionselemente ein Angebotscharakter aufweisen und zur Handlung anregen, ist in diesem Zusammenhang besonders wichtig, damit der Novize die angebotenen Funktionen selbsterklärend und unmittelbar verständlich wahrnimmt. 14

21 2 Analyse Die zweite Benutzerklasse wird durch die Experten gebildet, die bereits viele Erfahrungen mit Tea- Co gesammelt haben und den Funktionsumfang und die Interaktionsmöglichkeiten des Systems kennen. Da mit TeaCo-Mobile-NG bereits eine mobile Variante von TeaCo besteht, werden die Benutzer versuchen, ihre bereits erworbenen Erfahrungen und Kenntnisse von diesem Anwendungssystem auf TeaCo-Android zu übertragen. Demnach sollten, wie bereits die bestehende Notwendigkeit für den Novizen erläutert, nicht nur alle bekannten Funktionalitäten zur Verfügung stehen, sondern auch Möglichkeiten angeboten werden, diese Funktionen durch weniger offensichtliche aber hocheffiziente Interaktionsmöglichkeiten zu erreichen. Dies soll ermöglichen, ein Ziel schneller zu erreichen und effizienter mit dem Anwendungssystem zu interagieren. In diesem Zusammenhang können vor allem Multi-Touch-Gesten, die das Multi-Touch-Display ermöglicht, aber auch Interaktionsformen auf Grundlage des Beschleunigungssensors herangezogen werden Benutzerinterviews Neben den theoretischen Analysen wurden für die Entwicklung und Konzeption von TeaCo-Android eine Reihe von Benutzerinterviews durchgeführt. Dabei sollten die Erwartungen und Wünsche der beiden Benutzergruppen für das zukünftige Anwendungssystem erörtert werden. Zu Beginn wurden mit den Novizen zur Einführung in TeaCo verschiedene Anwendungsszenarien in TeaCo-Desktop und TeaCo-iPhone durchlaufen, die das Kennenlernen dieser Applikation erleichtern sollten. Anschließend wurde sowohl mit den Novizen als auch mit den Experten ein Benutzerinterview durchgeführt und die sich daraus ergebenden Verbesserungswünsche und mögliche zusätzliche Funktionen ermittelt. Insgesamt wurden sieben Benutzerinterviews mit ausschließlich männlichen Probanden durchgeführt, die mit Ausnahme von einem alle Android-Smartphones besitzen und den Umgang mit diesem gewohnt sind. Unter diesen Probanden waren vier Mitarbeiter der Universität zu Lübeck am Institut für Multimediale und Interaktive Systeme (IMIS) und drei Studenten selbiger Universität. Das Durchschnittsalter der Probanden betrug 31.3 Jahre (zwischen 22 und 47 Jahren). Bis auf zwei Studenten war TeaCo allen Probanden bekannt. Anhand von Tabelle 1 lässt sich die Zusammensetzung der Probanden der Benutzerinterviews erkennen. 15

22 2 Analyse Android-User TeaCo bekannt ja nein ja 4 1 nein 2 - Tabelle 1: Benutzerinterview, Zusammensetzung der Probanden Um eventuelle Störfaktoren zu minimieren und somit die Konzentration der Probanden nicht zu beeinträchtigen, wurden die Interviews mit jedem Teilnehmer einzeln in ruhiger und gewohnter Umgebung durchgeführt. Den Novizen wurde wie bereits eingehend erläutert TeaCo anhand von TeaCo- Desktop und TeaCo-iPhone vorgestellt. Anschließend wurde der Benutzer mit einem typischen Anwendungsszenario konfrontiert. Dadurch, dass die Entwicklung der TeaCo-Android-Applikation in Anlehnung an die TeaCo-iPhone-Variante stattfinden soll, ist es besonders interessant, den Umgang mit der iphone-applikation zu beobachten. Während der Anwendung wurden die Benutzer dazu aufgefordert, laut zu denken (Jørgensen, 1989), um anhand der Bemerkungen einen Eindruck der Meinungen bezüglich der Applikation und der speziellen Bedienelemente zu erhalten. Anschließend wurde die Befragung der Teilnehmer anhand des Interviewleitfadens (Anhang A) durchgeführt. Anhand dieses fokussierten Interviews (nach Merton & Kendall (1979)) sollten etwaige Schwierigkeiten während des Umgangs mit TeaCo ergründet werden, aber auch Anregungen und Ideen für neue Funktionen und Verbesserungsmöglichkeiten in TeaCo-iPhone gesammelt werden. Im Folgenden sollen die Ergebnisse der Benutzerinterviews, welche auch in tabellarischer Form in Anhang B einzusehen sind, dargestellt werden. Meetingübersicht Die vorhandenen Varianten von TeaCo unterscheiden sich sehr in Hinblick auf die Gruppierung der Meetings. In TeaCo-Desktop findet keine Gruppierung statt und die Meetings werden nach Aktualität sortiert. TeaCo-iPhone hingegen nimmt eine Unterteilung in zwei Gruppen Noch nicht abgestimmt und Bereits abgestimmt vor. Die Sortierung innerhalb dieser Gruppen geschieht ebenfalls wieder nach Aktualität. Innerhalb der Variante TeaCo-Mobile-NG existiert eine dritte Gruppe, in der die eigenen Meetings gesondert gruppiert werden. Die Sortierung erfolgt auch in dieser Variante innerhalb der Gruppen nach der Aktualität. Anhand der 16

23 2 Analyse Benutzerinterviews wurde ersichtlich, dass die Befragten bevorzugt die Meetings (vgl. TeaCoiPhone) nach Noch nicht abgestimmt und Bereits abgestimmt gruppieren. Hinsichtlich der Sortierung der Meetings wurden die Wünsche geäußert, diese nach dem Alphabet oder dem Abstimmungsstatus sortieren zu können (vgl. Abbildung 14). % % % 43% Aktualit at Alphabetisch Abstimmungsstatus Abbildung 14: Benutzerinterview, Sortierung der Meetingansicht Meetingansicht Vor allem wegen der geringen Größe des Displays eines iphones wurde bei der Entwicklung von TeaCo-iPhone auf eine kalenderähnliche Darstellung verzichtet und stattdessen die Quickvote- Liste implementiert, die Roenspieß (2009) für TeaCo-Mobile konzipiert hat. Da TeaCo-iPhone keine Ansicht im Querformat unterstützt, dies aber innerhalb von TeaCo-Android möglich sein soll, wurde anhand der Benutzerinterviews ermittelt, ob eine Tages-, Wochen- oder Monatsansicht durch den gewonnenen Platz bevorzugt werden würde. Abbildung 15 macht jedoch deutlich, dass die Quickvote-Liste auf dem kleinen verfügbaren Platz die beste Lösung darstellt. Die Tagesansicht hingegen wurde einheitlich abgelehnt, wohingegen die Wochen- und Monatsansicht für einige Befragte wünschenswert sind. 17

24 2 Analyse % % % 43% 20 0% Quickvote-Liste Tagesansicht Wochenansicht Monatsansicht Abbildung 15: Benutzerinterview, Alternative Darstellungen der Meetingansicht Löschen von Meetings In TeaCo-iPhone können Meetings auf zwei Wegen gelöscht werden. Zum einen gibt es die Möglichkeit mit Hilfe einer Swipe-Geste, also das Streichen mit dem Finger von links nach rechts über einem Listenelement, den Button Löschen sichtbar zu machen (vgl. Abbildung 16). Zum anderen gibt es in der Kopfzeile in der Meetingübersicht einen Button Bearbeiten, welcher nach dem Antippen vor jedem Listenelement ein Interaktionselement sichtbar macht, welches zum Löschen eines Meetings genutzt werden kann. Abbildung 16: Versteckter Löschen-Button (b) in Listenansicht durch Streichen über Listeneintrag (a) auf dem iphone (Schröder, 2010) 18

25 2 Analyse Da weder die Swipe-Geste noch ein Bearbeiten -Button übliche Interaktionsformen für einen Android-Nutzer darstellen, erhielten beide Optionen wenig Zuspruch. An Stelle derer bevorzugten die Befragten ein Kontextmenü, welches durch ein Gedrückthalten eines Listenelements erscheint. Mit Hilfe dessen lässt sich dann das Listenelement manipulieren. Zum Löschen mehrerer Meetings wurde hingegen eine entsprechende Funktion im Menü gewünscht, welches durch eine der vier Hardware-Tasten erreicht werden kann. Innerhalb der Abbildung 17 werden die Ergebnisse dieser Befragung grafisch dargestellt. % % 86% % 14% per Swipe per Swipe Kontextmen u durch Gedr uckthalten Mehrere l oschen uber das Men u Abbildung 17: Benutzerinterview, Löschen eines Meetings Benachrichtigungen via Status Bar Notification TeaCo-iPhone benachrichtigt einen Benutzer über neue Kommentare oder Einladungen zu Meetings via Push Notification Service (Apple Inc., ). Anhand der sogenannten Status Bar Notification (Google Inc., ) sollen diese Benachrichtigungen auch für TeaCo-Android ermöglicht werden. Durch die Benutzerinterviews wurde deutlich, dass diese Benachrichtigungen in drei speziellen Fällen als besonders notwendig erkannt wurden: Sobald alle Teilneh- 19

26 2 Analyse mer über die Terminvorschläge abgestimmt haben (Abstimmung bei 100%), bei einer Einladung zu einem Meeting und sobald die Planung abgeschlossen wurde und Terminvorschläge als endgültig markiert wurden (vgl. Abbildung 18). Aber auch eine Benachrichtigung bei neuen Kommentaren oder der Löschung eines noch nicht abgeschlossenen Meetings sind wünschenswert. % % 100% 86% 100% 71% % Abstimmung bei 100% Vollst. Abstimmung eines Teilnehmers Einladung zu einem Meeting Neuer Kommentar Planung abgeschlossen L oschung eines offenen Meetings Abbildung 18: Benutzerinterview, Benachrichtigungen Anzahl ausgewählter Terminvorschläge in der Meetingübersicht Abbildung 19 zeigt die Meetingübersicht von TeaCo-iPhone (ausgewählte Termine hervorgehoben). Keiner der Befragten war in der Lage mit oder ohne Navigieren im System zu beantworten, was die grün hinterlegte Zahl bei jedem Meeting zu bedeuten hat. Durch die fehlende Assoziation und die Doppeldeutigkeit der grünen Farbe, die bereits in der Ampelmetapher genutzt wird, ist diese Information anscheinend schwer interpretierbar. Aber auch nachdem die Befragten wussten, um was für eine Information es sich handelt, wurde diese für unwichtig befunden. 20

27 2 Analyse Abbildung 19: Meetingübersicht in TeaCo-iPhone (ausgewählte Termine hervorgehoben) Übertragung der Termine in den Kalender Vereinzelt wurde der Wunsch geäußert, ausgewählte Termine aus der Applikation in den eigenen Kalender übertragen zu können. So erspart man sich den Umweg über die icalendar-datei, die der beigefügt ist, die nach Abschluss der Planung eines Meeting vom System versendet wird. Im Zuge dessen wäre es außerdem denkbar, diese Termine aus der Meetingübersicht ausblenden zu können, da mit Übernahme des Termins in den eigenen Kalender die Planung vollständig abgeschlossen ist. Free-Busy-Listen Weder die eigene Free-Busy-List noch die anderer Teilnehmer werden in der iphone-applikation von TeaCo berücksichtigt. Im Falle einer Überschneidung von Terminvorschlag und Free- Busy-List-Eintrag wurde eine entsprechende Visualisierung auf dem Nein -Button gewünscht. In der Übersicht der Abstimmungsergebnisse könnten dann auch die fremden Listen sichtbar werden. 21

28 2 Analyse 2.3 Organisationsanalyse Um einen gemeinsamen Termin für mehrere Personen zu finden, ist es besonders wichtig, die Teilnehmergruppe geeignet zu koordinieren. Entscheidend dafür ist die Untersuchung der Gruppen, speziell deren Zusammensetzung, organisatorische Strukturen und das Umfeld der einzelnen Teilnehmer. Mit Hilfe dieser Informationen kann bei der Konzeption und der Implementierung eines Anwendungssystems Rücksicht auf diese Teilnehmergruppe genommen und so die Chance der Zielerreichung gesteigert werden. Momentan wird TeaCo hauptsächlich innerhalb der Universität genutzt, jedoch soll die Entwicklung des Systems nicht auf dieses Umfeld beschränkt werden. Deshalb kann keine allgemeingültige Aussage über die Beschaffenheit der Benutzergruppe getätigt werden, sondern es handelt sich vielmehr um eine heterogene Gruppe, die das TeaCo-System verwendet bzw. verwenden wird. Das Ziel besteht darin, eine Konsistenz zwischen dem individuellen Kalendersystem der Teilnehmer und TeaCo herzustellen und zu erreichen, dass diese Systeme zusammenarbeiten. Aus dem Grund, dass der Android-Google- Kalender in dem Android-Smartphone fest integriert ist und eine Synchronisation mit Desktopkalendersystemen wie Outlook (Microsoft, ) oder ical (Apple Inc., ) möglich ist, ist davon auszugehen, dass dieser primär als Kalendersystem verwendet wird. Dem Anwender sollen vertraute Interaktions- und Darstellungsformen zur Verfügung stehen, um die Integration dieser Kommunikationsplattform zu vereinfachen. Aus diesem Grund soll bei der Gestaltung von TeaCo-Android der Android-Google-Kalender berücksichtigt werden. Da eine Synchronisation mit dem im Android-Smartphone integrierten Android-Google-Kalender möglich ist, sollte dem Nutzer die Möglichkeit geboten werden, seinen Kalender mit TeaCo zu synchronisieren. Durch die Verwendung des icalendar-formats (Internet Engineering Task Force, 1998), welches von vielen Kalendersystemen unterstützt wird, erhält jeder Teilnehmer nach Festlegung eines endgültigen Termins eine mit einer Datei in diesem ical-format als Anhang. Dadurch ist es möglich, schnell und komfortabel den gefundenen Termin in seinen Kalender zu übertragen. Die Effizienz könnte weiter gesteigert werden, wenn der Nutzer diesen Termin direkt aus TeaCo-Android in seinen integrierten Android-Google-Kalender übernehmen könnte, damit er anschließend auch auf das Desktop-Kalendersystem übertragen wird. 22

29 2 Analyse 2.4 Kontextanalyse Neben den zu erledigenden Aufgaben und den betrachteten Benutzern, die diese Aufgaben erledigen sollen, muss auch das Umfeld analysiert werden, indem der Benutzer das Anwendungssystem benutzen wird. Dies beinhaltet zum einen den technischen Kontext, zum anderen den räumlich- und zeitlichen Kontext Technischer Kontext Da die Applikation lediglich für Android-Smartphones entwickelt wird, müssen auch nur solche Smartphones und deren Hardware analysiert werden. Obgleich der Vielzahl an verschiedenen Android- Smartphones, haben diese gewisse gemeinsame Eigenschaften, welche im Folgenden aufgelistet werden, da auch nur Gemeinsamkeiten für die Entwicklung relevant sind. Hardware-Tasten Android-Smartphones sind alle mit denselben vier Hardware-Tasten ausgestattet, die üblicherweise unter dem Display zu finden sind (vgl. Abbildung 20). Abbildung 20: Hardware-Tasten eines Android-Smartphones (Quelle: noscope.com) Zurück-Taste: Mit Hilfe der Zurück-Taste kann sowohl in Applikationen, als auch im Browser oder Betriebssystem bequem zurück navigiert werden. 23

30 2 Analyse Menü-Taste: Die Menü-Taste ist kontextsensitiv und zeigt je nach Situation andere Interaktionsmöglichkeiten. Ist keine Interaktionsmöglichkeit in einer Applikation implementiert, so ist diese Taste ohne Funktion. Home-Taste: Durch einen Druck auf die Home-Taste gelangt der Benutzer zur Desktop- Ansicht (Startbildschirm) des Geräts. Suchen-Taste: Beim Antippen der Suchen-Taste, wird eine Suchfunktion für die jeweils aktive Applikation angeboten. Durch Gedrückthalten der Lupen-Taste wird für die Suche eine Spracheingabe über das integrierte Mikrofon ermöglicht. Multi-Touch-Display Bei der Bedienung eines Android-Smartphones können durch die Multi-Touch-Fähigkeit des Geräts auch mehrere Finger genutzt werden und Gesten, beispielsweise Wischen, sind möglich. Somit können Interaktionselemente in der Applikation eingespart werden und beanspruchen somit keinen Platz. Platzsparend verhält sich auch die Tastatur, die nur bei Bedarf eingeblendet und ebenfalls über das Display bedient wird. Über die Display-Größe kann keine allgemein gültige Aussage getroffen werden, da Android- Smartphones von verschiedenen Herstellern in vielen unterschiedlichen Größen und damit verbunden auch unterschiedlichen Auflösungen hergestellt werden. Die Maximalgröße beträgt jedoch 4,3 Zoll. Beschleunigungssensor Android-Smartphones sind in der Lage, mit einem Sensor Bewegungen und auch die Ausrichtung zu erkennen. Dadurch kann zwischen Hoch- und Querformat unterschieden werden und je nach Ausrichtung eine andere Anordnung der Elemente stattfinden. Außerdem können gewisse Bewegungen als Eingaben dienen und sind auch ohne Interaktion auf dem Multi-Touch-Display möglich. Mikrofon Über das Mikrofon können Sprach- oder Geräuschaufnahmen getätigt werden. Aber auch zur Spracheingabe wird das Mikrofon benötigt. So kann eine Applikation ebenfalls gesteuert werden. 24

31 2 Analyse Lautsprecher Jedes Android-Smartphone besitzt einen Lautsprecher, über den unter anderem Musik oder Sprachaufnahmen wiedergegeben werden können. Auch auditive Rückmeldungen von Interaktionen sind hierüber möglich. Datenübertragungen Datenverbindungen können mit einem Android-Smartphone zum einen über ein lokales Funknetz (Wireless Local Area Network (WLAN)), zum anderen unterwegs über den Mobilfunkvertrag mit einem Mobilfunknetz erfolgen. Hier stünden Universal Mobile Telecommunications System (UMTS) mit Datenübertragungsraten von bis zu 14,4 Megabit pro Sekunde und Enhanced Data Rates for GSM Evolution (EDGE) mit einer maximalen Geschwindigkeit von 220 Kilobit pro Sekunde zur Verfügung. Aufgrund der geringen Größe des Displays soll besonderer Wert auf die Übersichtlichkeit und eine angemessene Darstellung gelegt werden. Der geringere Platz darf folglich nicht zu Interaktionselementen führen, deren Bedienbarkeit durch ihre geringe Größe beeinträchtigt ist. Außerdem sollte es aufgrund der im mobilen Bereich geringen Datenübertragungsraten nicht zu Geschwindigkeitsproblemen oder gar zu bedingten Abstürzen beim Verwenden der Applikation kommen. Da jedoch sämtliche grafischen Elemente lokal auf dem Gerät gespeichert sind und lediglich spezifische Informationen übertragen werden müssen, sollte eine uneingeschränkte Nutzung der Applikation auch unter diesen Extrembedingungen gewährleistet werden können Räumlicher- und zeitlicher Kontext Jedes Android-Smartphone ist in der Lage, sich zu einem WLAN zu verbinden. Des Weiteren ist ein Android-Smartphone in der Regel mit einem Mobilfunkvertrag und einer darin enthaltenen Daten- Flatrate ausgestattet, um auch über ein Mobilfunkstandard der dritten Generation (3G) eine Internetverbindung herstellen zu können. Aufgrund dieser beiden Aspekte lässt sich ableiten, dass die räumliche- und zeitliche Umgebung des Benutzers nicht festgelegt werden kann. Es ist davon auszugehen, dass TeaCo zu Hause in der Desktop-Variante verwendet wird, da man dort den Umgang mit dem Desktop-PC gewohnt ist und dieser auch hinsichtlich des TeaCo-Systems zahlreiche Vorteile gegenüber einem Smartphone bietet. Übersichtlichkeit und Fehlertoleranz sind zwei ausschlagge- 25

32 2 Analyse bende Punkte, auf die bei der Konzeption von TeaCo-Android besonderer Wert gelegt werden sollte. Insbesondere unterwegs ist nicht davon auszugehen, dass ein Benutzer das Smartphone konzentriert bedienen kann und Fehleingaben sind aus diesem Grund keine Seltenheit. Das Anwendungssystem sollte angemessen mit solchen Eingaben bzw. Aktionen umgehen und die Möglichkeit bieten ungewollte Benutzeraktionen zu widerrufen. 2.5 Use-Cases Use-Cases sind nach Jacobson, Christerson & Jonsson (1992) Anwendungsszenarien, in denen der Benutzer mit dem Anwendungssystem interagiert. Während der Analyse für TeaCo-Android wurden die zukünftigen Benutzer dieser Anwendung hinsichtlich der Stärken und Schwächen von TeaCo-iPhone befragt. Auf Grundlage der Ergebnisse dieser Benutzerinterviews wurden die aus der Konzeption von TeaCo-iPhone entstandenen Use-Cases optimiert und durch weitere ergänzt. Die entstehende TeaCo- Android-Applikation wird durch die Gesamtheit dieser Use-Cases hinsichtlich ihrer Funktionalität definiert. Mit einigen Änderungen wurden die Use-Cases, in denen die Unterschiede dargestellt werden, von TeaCo-iPhone (Schröder, 2010, Seite 32 ff.) übernommen. Die in Abschnitt 3.3 entstehenden Feature-Sets basieren auf den nachfolgend aufgelisteten Use-Cases. UC1 Navigation innerhalb der Meetingansicht und -übersicht In der Meetingansicht bekommt der Benutzer vom Anwendungssystem eine Liste selbst initiierter bzw. beigetretener Meetings. Über diese Liste erfolgt die Navigation zur Meetingübersicht, in der die Möglichkeit zur Abstimmung über Terminvorschläge geboten wird. Außerdem werden hier die eigene Stimme und weitere Informationen bezüglich des entsprechenden Meetings ersichtlich. UC2 Abstimmung über Terminvorschläge Da das Abstimmen über Terminvorschläge sowohl die wichtigste als auch die häufigste Interaktion mit dem Anwendungssystem ist, muss eine leicht zugängliche Möglichkeit vorhanden sein, über Terminvorschläge abzustimmen. Außerdem muss das Anwendungssystem den Benutzer auf Terminvorschläge hinweisen, über die er noch nicht abgestimmt hat. 26

33 2 Analyse UC3 Erzeugen neuer Terminvorschläge Allen Teilnehmern - sowohl dem Initiator als auch weiteren Teilnehmern - des Meetings muss die Möglichkeit geboten werden, eigene Terminvorschläge zu erzeugen. Da der Benutzer diese Terminvorschläge selbst gewählt hat, ist davon auszugehen, dass er diesen wahrnehmen kann und das Anwendungssystem stimmt automatisch für ihn ab. UC4 Manipulation von Terminvorschlägen Der Benutzer kann seine eigenen Terminvorschläge hinsichtlich Datum, Uhrzeit und Dauer manipulieren. Existiert eine entsprechende Berechtigung (UC10), so kann er auch die Terminvorschläge anderer Teilnehmer manipulieren. UC5 Zurücksetzen einer Abstimmung Manipuliert (UC4) ein Benutzer einen Terminvorschlag, über den bereits abgestimmt wurde, so setzt das Anwendungssystem diese Abstimmung zurück, damit die Teilnehmer neu über diesen Terminvorschlag abstimmen können. UC6 Löschen eines Terminvorschlags Erstellt ein Benutzer irrtümlich einen Terminvorschlag, hat er die Möglichkeit, diesen wieder zu löschen. Auch fremde Terminvorschläge können bei entsprechender Berechtigung (UC10) gelöscht werden. UC7 Auswahl endgültiger Termine Ist die Abstimmung über Terminvorschläge vollständig, kann der Benutzer bei entsprechender Rechtevergabe (UC10) einen oder mehrere Termine als endgültig markieren. UC8 Benachrichtigung über endgültige Termine Nach der Auswahl endgültiger Termine (UC7) kann der Benutzer alle Teilnehmer über diese informieren. Die Benutzer erhalten diese Benachrichtigung via inklusive eines ical- Eintrags und im Falle von TeaCo-Android via Status Bar Notification (Google Inc., ). UC9 Erzeugen eines neuen Meetings Der Benutzer kann ein neues Meeting erstellen und dabei dessen Titel festlegen und angeben, ob es sich um ein eingeschränktes Meeting handelt (UC10). 27

34 2 Analyse UC10 Festlegung der Rechte eines neuen Meetings Bei der Erzeugung eines neuen Meetings (UC9) hat der Benutzer festgelegt, ob es sich um ein eingeschränktes Meeting handelt. In diesem Fall kann nur der Initiator Terminvorschläge manipulieren, Teilnehmer ausladen und endgültige Termine auswählen. Andere Teilnehmer können lediglich abstimmen, andere Teilnehmer einladen, Terminvorschläge erzeugen und eigene Kommentare schreiben und manipulieren. UC11 Einladen von Teilnehmern Jeder Teilnehmer hat die Möglichkeit, weitere Teilnehmer zu einem Meeting einzuladen. Anschließend wird dieser Benutzer per und im Falle von TeaCo-Android via Status Bar Notification informiert. UC12 Eingabe bereits bekannter Teilnehmer Teilnehmer, die bereits von einem Benutzer zu einem Meeting eingeladen wurden, werden von dem Anwendungssystem gespeichert. Will ein Benutzer nun neue Teilnehmer zu einem Meeting einladen, kann er aus einer Liste die zuvor gespeicherten Teilnehmer auswählen. Außerdem hat er die Möglichkeit, Kontakte aus seinem Android-Adressbuch auszuwählen. UC13 Eingeladene Teilnehmer in ein neues Meeting übernehmen Dem Benutzer wird neben dem Verfahren UC9 die Möglichkeit gegeben, ein Meeting zu erstellen, das alle Teilnehmer eines bereits existierenden Meetings übernimmt. UC14 Ausladen von Teilnehmern Ist die Anwesenheit eines bestimmten Teilnehmers in einem Meeting nicht mehr von Nöten, so kann dieser vom Benutzer unter Berücksichtigung der Rechtevergabe (UC10) ausgeladen werden. UC15 Verlassen bzw. Löschen eines Meetings Der Benutzer hat die Möglichkeit, ein Meeting zu verlassen, wenn er daran nicht mehr teilnehmen möchte. Ist der Benutzer selbst der Initiator des Meetings, so kann er das Meeting löschen. UC16 Verfassen, Bearbeiten und Löschen von Kommentaren Zur Planung des Meetings können textuelle Beiträge in Form von Kommentaren Hilfestellung geben. Diese sind für alle Teilnehmer des Meetings ersichtlich und können vom Verfasser geän- 28

35 2 Analyse dert und gelöscht werden. Darüber hinaus kann der Initiator auch fremde Kommentare löschen, um die Funktion eines Moderators zu übernehmen. UC17 Individualisierung des Anwendungssystems Der Benutzer hat folgende Möglichkeiten, das Anwendungssystem an seine individuellen Bedürfnisse anzupassen: Angabe eines Namens Angabe eines Passworts Angabe einer Free/Busy-List (Uniform Resource Locator (URL)) Auswahl einer Systemsprache aus Deutsch, Englisch und Französisch Änderung der primären -Adresse und Hinzufügen weiterer -Adressen Ein- und Ausschalten der Status-Bar-Notification. Dieser Use-Case wurde hinsichtlich der Status-Bar-Notification angepasst, da diese nur auf einem Android-Smartphone zur Verfügung steht. UC18 An- und Abmeldung Der Benutzer kann sich mithilfe seiner -Adresse und seines Passworts oder mit seinem persönlichen Zugangsschlüssel bei dem Anwendungssystem anmelden. Außerdem kann der Benutzer sich wieder vom Anwendungssystem abmelden. Die Anmeldung mit Hilfe des Zugangsschlüssels stellt eine Erweiterung gegenüber dem entsprechenden Use-Case von Schröder (2010) dar. UC19 Registrierung Durch Eingabe seiner -Adresse und Auswahl einer Systemsprache kann der Benutzer sich registrieren. Optional kann der Benutzer ein Passwort und einen Namen angeben. Die Use- Cases An- und Abmeldung und Registrierung sind bei Schröder (2010) zusammengefasst. 29

36 3 Konzeption In diesem Kapitel soll aus den in der Analyse gewonnenen Erkenntnissen ein Konzept für das Anwendungssystem TeaCo-Android entstehen. Da TeaCo-Android das vorhandene TeaCo System nutzen soll, wird zunächst die Systemarchitektur in Anlehnung an Lohrenz (2009) betrachtet. Anschließend soll die Interaktionsgestaltung (Kapitel 3.2) vorgestellt werden, anhand welcher die Einteilung in Feature-Sets und Priorisierung erfolgt, um den angestrebten FDD-Prozess durchlaufen zu können. Des Weiteren wurde dieses Konzept mit einigen Probanden der Benutzerinterviews validiert, indem während der Konzeption wiederholt Rücksprache gehalten wurde. 3.1 Systemarchitektur Da TeaCo-Android, wie auch TeaCo-Mobile, TeaCo-Mobile-NG und TeaCo-iPhone, eine Erweiterung von TeaCo auf einer anderen Plattform ist, wird dieselbe Architektur und Technik genutzt, die auch in allen anderen Varianten genutzt wird. Da diese eingehend und vollständig in der Dokumentation von TeaCo beschrieben wurden (Lohrenz, 2009, Seite 46 ff.), werden sie an dieser Stelle lediglich noch einmal zusammenfassend erläutert Client-Server-Modell Um den Terminfindungsprozess mit Hilfe von TeaCo realisieren zu können, ist es erforderlich, zeitlich und örtlich getrennte Benutzer zu verbinden. Dafür findet das Client-Server-Modell Anwendung, welches eine Abfrage wie folgt strukturiert (vgl. Abbildung 21): 30

37 3 Konzeption (1) Die Interaktion eines Benutzer mit dem Anwendungssystem TeaCo-Android erzeugt eine Hypertext Transfer Protocol (HTTP)-Anfrage, die von dem Android-Smartphone an den zentralen Webserver gesendet wird. (2) Dieser zentrale Webserver wandelt die Anfrage in Parameter um, die an den Applikationsserver weitergeleitet werden, auf dem die eigentliche Anwendung ausgeführt wird. (3) Der Applikationsserver verarbeitet diese Anfrage schließlich unter Verwendung der in der Datenbank vorhandenen Datensätze und generiert eine entsprechende Antwort. (4) Diese Antwort wird je nach Anforderung, zum Beispiel im Extensible Markup Language (XML)- Format, an den Webserver zurückgesendet. (5) Aus der ursprünglichen HTTP-Anfrage wird nun mit Hilfe der Antwortdaten eine HTTP-Antwort erstellt. Das Android-Smartphone empfängt diese Antwort und generiert daraus letztlich eine entsprechende Ansicht. Abbildung 21: Client-Server-Architektur (modifiziert nach Lohrenz (2009)) 31

38 3 Konzeption Model-View-Controller-Pattern Model-View-Controller (MVC) ist ein Architekturmuster, das die unabhängige Trennung der drei Module Daten (Model), Präsentation (View) und Programmsteuerung (Controller) vornimmt. Dieses heute bewährte Prinzip zur Modellierung von Anwendungssystemen wurde erstmals von Reenskaug (1979) beschrieben. Die einzelnen Module dieses Architekturmusters sind wie folgt definiert: Das Model enthält alle Daten und Objekte die von dem Anwendungssystem erstellt und manipuliert werden sollen. Die auf diese Weise verarbeiteten Daten und Objekte werden über eine Schnittstelle in einer entsprechenden Datenbank abgelegt und gespeichert. In TeaCo-Android finden zwei Views Anwendung. Dies ist zum einen die Ausgabe der XML-, bzw. JSON-Daten (die Form der Datenausgabe wird sich in der Implementierung herausstellen), die an das Android-Smartphone gesendet werden und zum anderen die Ausgabe in der TeaCo- Android-Applikation. Die View des Anwendungssystems nimmt Eingaben durch Interaktionen vom Benutzer entgegen und leitet diese an den internen Controller weiter. So bildet diese View die Schnittstelle zwischen Ein- und Ausgabe des Anwendungssystems. Der Controller beinhaltet sämtliche Funktionen des Systems. Auch hier besteht eine Unterteilung in zwei verschiedene Controller. Der interne Controller der TeaCo-Android-Applikation ist verantwortlich für die Verwaltung der TeaCo-Android-View und nimmt Benutzeraktionen entgegen. Diese Benutzeraktionen werden an den Controller des TeaCo-Systems weitergeleitet und interpretiert. Anschließend stellt der Controller gegebenenfalls eine Anfrage an das Model, um erforderliche Daten oder Objekte zu erhalten und entsprechend der Benutzeraktion zu reagieren. Durch die Verwendung des MVC-Architekturmusters und die strikte Trennung in diese drei Kategorien wirken sich Änderungen in einem Bereich auf keinen anderen Bereich aus. Dies ist auch für die Entwicklung von TeaCo-Android eine vorteilhafte Grundlage, da die zugrundeliegende Funktionsweise des Anwendungssystems auch für TeaCo-Android verwendet werden soll und somit an dieser Stelle keine Änderungen nötig sind. Infolgedessen wird zusätzlich Fehlern in der Entwicklung vorgebeugt und die vorhandenen Varianten von TeaCo bleiben von dieser Erweiterung unangetastet. 32

39 3 Konzeption Datenbankschema Für alle Varianten von TeaCo wird das in Abbildung 22 abgebildete Datenbankschema zur Speicherung von Daten verwendet. Die Tokens-Tabelle wird jedoch nur von der iphone-applikation für den Push-Notification-Service in Anspruch genommen. Im Folgenden werden die acht Entitäten und die verbindenden Relationen aufgeführt. Abbildung 22: Datenbankschema von TeaCo Die Tabelle User enthält alle im System registrierten Benutzer mitsamt der benutzerspezifischen Daten. Entsprechend des ER-Diagramms in Abbildung 22 kann jeder Benutzer beliebig viele Meetings initiieren (Initiator), an beliebig vielen Meetings teilnehmen (Participants), beliebig viele Terminvorschläge erstellen (Creator), 33

40 3 Konzeption beliebig viele Kommentare schreiben (Author), über vorgeschlagene Termine abstimmen (Voter), beliebig viele alternative -Adressen besitzen (has Addresses), beliebig viele bekannte Adressen von Teilnehmern besitzen (has known Addresses) und beliebig viele Tokens besitzen (has Tokens). Die Tabelle Meeting enthält alle Meetings von TeaCo. Ein Meeting hat genau einen Initiator (Initiator), beliebig viele Teilnehmer, mindestens jedoch einen, den Initiator (Participants), beliebig viele Terminvorschläge (has Suggestions) und beliebig viele Kommentare (has Comments). Terminvorschläge werden in der Tabelle Suggestion gespeichert. Ein Terminvorschlag gehört genau einem Meeting an (has Suggestions), enthält beliebig viele Abstimmungen (Votes), maximal jedoch die Anzahl der Teilnehmer eines Meetings und wurde von genau einem Teilnehmer des Meetings erstellt (Creator). Ein Kommentar (Tabelle Comment) gehört zu genau einem Meeting (has Comments) und hat genau einen Autor (Author). Die Tabelle Vote enthält alle Abstimmungen von Teilnehmern eines Meetings. Eine Abstimmung wird von genau einem Benutzer (Voter) zu genau einem Terminvorschlag abgegeben (Votes). Alternative -Adressen sind in der Tabelle Alias Addresses abgelegt und haben genau einen Benutzer has Addresses. Die Tabelle Known Addresses enthält alle bekannten -Adressen eines Benutzers, also E- Mail-Adressen von Benutzern, die er bereits zu einem Meeting eingeladen hat. Bekannte Adressen haben genau einen Benutzer (has known Addresses). 34

41 3 Konzeption Die für die Push-Notification der iphone-applikation sowie für die Status-Bar-Notification der Android-Applikation relevanten Tokens sind in der gleichnamigen Tabelle Tokens gespeichert. Diese gehören zu genau einem Benutzer (has Tokens). 3.2 Interaktionsgestaltung Wichtigstes Ziel bei der Erstellung der grafischen Benutzungsoberfläche (Graphical User Interface (GUI)) ist die Erreichung der angestrebten Gebrauchstauglichkeit nach DIN EN ISO (1998). Dafür müssen die drei Kriterien Effizienz, Effektivität und Zufriedenstellung erfüllt werden. Werden die Funktionen des Anwendungssystems leicht zugänglich gemacht, erreicht man eine hohe Effektivität des Benutzers. Wiederkehrende Tätigkeiten können durch diese aufgabengerechte Gestaltung und die gleichzeitig schnelle Erreichbarkeit der Funktionen ebenfalls sehr effizient ausgeführt werden. Die Zufriedenstellung wird letztlich vor allem durch die Gestaltung der Benutzungsoberfläche und einer angemessenen Interaktion erreicht. Durch ansprechende Visualisierungen und klare Strukturen des Anwendungssystems soll beim Benutzer eine positive Grundeinstellung zum System erzeugt werden. TeaCo-Android verwendet zwei Hauptansichten, welche nach Einloggen bzw. Registrierung (vgl. Abbildung 23 (1)) erreicht werden können. Von diesen Hauptansichten können alle weiteren Ansichten erreicht werden. Dies ist zum einen die Meetingübersicht (vgl. Abbildung 23 (2), Abschnitt 3.2.1) und zum anderen die Meetingansicht (vgl. Abbildung 23 (3), Anschnitt 3.2.2). Über das kontextsensitive Menü, welches stets über die Menütaste des Android-Smartphones erreicht werden kann, können jederzeit die Einstellungen (vgl. Abbildung 23 (7)) aufgerufen werden. Außerdem kann abhängig vom Zustand über andere Menüpunkte mit dem System interagiert werden. Befindet sich der Benutzer in der Meetingansicht, hat er über das Menü die Möglichkeit, einen Kommentar zum Meeting hinzuzufügen (vgl. Abbildung 23 (8)). In Abbildung 23 ist zu sehen, dass zusätzlich Terminvorschläge hinzugefügt werden können (5), die Teilnehmer verwaltet (6) werden können und die Planung abgeschlossen werden kann (9). Diese Ansichten sind ebenfalls über das kontextsensitive Menü zu erreichen. Ist der Benutzer jedoch in der Meetingübersicht, stehen andere Optionen, wie das Hinzufügen eines neuen Meetings, zur Verfügung (vgl. Abbildung 23 (4)). Aufgrund der Verfügbarkeit dieses Menüs wird in TeaCo-Android global auf Kopf- und Fußzeilen verzichtet. Die in TeaCo-iPhone in den Kopf- und Fußzeilen untergebrachten Funktionen finden sich nun im kontextsensitiven Menü, wodurch Platz, aber 35

42 3 Konzeption keine Funktionen eingespart werden. Die in der iphone-app im User Interface (UI) untergebrachten Zurück-Buttons, werden durch die hardwareseitig implementierte Zurücktaste ersetzt. Im Folgenden werden die Teilbereiche des Konzepts von TeaCo-Android dargestellt. Abbildung 23: Aufrufreihenfolge der einzelnen Ansichten und Pop-Ups der TeaCo-Android- Applikation 36

43 3 Konzeption Meetingübersicht In Abbildung 24 ist die Konzeption der Meetingübersicht dargestellt. Dies ist eine Übersicht über alle Meetings eines Benutzers. In dieser Darstellung ist zu erkennen, dass sich das Konzept von TeaCo- Android an der Konzeption von TeaCo-iPhone (Schröder, 2010) orientiert. Entgegen der Umsetzung von TeaCo-iPhone ist die Liste der Meetings aufgrund der Befragung der Probanden jedoch lediglich in die folgenden zwei Gruppen unterteilt. Abbildung 24: Mockup: Meetingübersicht Noch nicht abgestimmt Diese Gruppe beinhaltet alle Meetings, die mindestens einen Terminvorschlag enthalten, über den der Benutzer noch nicht abgestimmt hat. Da diese Meetings eine Interaktion erfordern und auch bei längeren Listen nicht aus dem sichtbaren Bereich verschwinden sollen, ist diese Gruppe als erste aufgeführt. 37

44 3 Konzeption Bereits abgestimmt Anschließend sind die Meetings aufgelistet, über die vollständig abgestimmt wurde. Die Sortierung innerhalb dieser Gruppe erfolgt nach dem Zeitpunkt der letzten Interaktion eines Benutzers. In TeaCo-Android wird darüber hinaus auf eine Kopf- und Fußzeile verzichtet und stattdessen ein kontextsensitives Menü genutzt (vgl. Abbildung 25). Abbildung 25: Mockup: Meetingübersicht inklusive Menü Im Fall der Meetingübersicht stehen in diesem Menü folgende Funktionen zur Verfügung: neues Meeting erstellen Dies geschieht mit Hilfe eines Pop-ups (vgl. Abbildung 26) und bedarf einer Bestätigung. Fehlerhafte Eingaben, wie z.b. ein leeres Titelfeld, sollen abgefangen werden. 38

45 3 Konzeption Abbildung 26: Mockup: Meetingübersicht mit Pop-up für neues Meeting Meeting-Liste neu laden Da sich die Meetingübersicht bei einer Änderungen eines anderen Teilnehmers nicht automatisch anpasst, wird mit diesem Menüpunkt die Möglichkeit geboten, die Ansicht zu aktualisieren. Meetings bearbeiten Mit Hilfe dieses Menüpunkts wird es möglich sein, mehrere Meeting auf einmal zu löschen oder zu verlassen. Damit erspart man sich das Gedrückthalten eines jeden Meetings, das sehr zeitaufwändig werden kann, wenn man sehr viele Meetings löschen bzw. verlassen möchte. Einstellungen Dieser Menüpunkt ruft die TeaCo spezifischen Einstellungen auf, die von TeaCo-Desktop unter myteaco bekannt sind. Android-Anwendung betreffende Einstellungen werden in dieser Ansicht ebenfalls zu finden sein. 39

46 3 Konzeption Um mit einem Meeting zu interagieren, hält man ein entsprechendes Listenelement, wie für das Android-Smartphone üblich, einen kurzen Moment gedrückt und erreicht ein Pop-up (vgl. Abbildung 27) mit folgenden Funktionen: Klonen Beim Klonen eines Meetings werden alle Teilnehmer des zu klonenden Meetings übernommen. Der Titel des Meetings kann dabei verändert werden. Löschen bzw. Verlassen Ist man selbst der Initiator des Meetings, wird das Meeting gelöscht. Andernfalls verlässt man lediglich das Meeting und es bleibt für die übrigen Teilnehmer weiterhin bestehen. Titel ändern Das Umbenennen des Meetings erfolgt wiederum durch ein entsprechendes Pop-up. Abbildung 27: Mockup: Meetingübersich mit Pop-up zum Bearbeiten eines Meetings 40

47 3 Konzeption Meetingansicht Nach der Auswahl eines Meetings aus der Meetingübersicht gelangt man zur Meetingansicht. Die Meetingansicht enthält die Details des ausgewählten Meetings und die Quickvote-Liste, über die der Benutzer über Terminvorschläge abstimmen kann (vgl. Abbildung 28). Dafür stehen ihm die Abstimmungsmöglichkeiten Nein (rot), Vielleicht (gelb) und Ja (grün) zur Verfügung. Die Abstimmungsergebnisse aller Teilnehmer wird im unteren Bereich eines jeden Terminvorschlags durch einen farbkodierten Balken visualisiert. Darüber hinaus sind unter der Quickvote-Liste alle verfügbaren Kommentare zu einem Meeting zu finden. Die Manipulation eines Terminvorschlags oder eines Kommentars erfolgt wie auch bei den Meetings in der Meetingübersicht über ein Pop-up. Dieses Pop-up kann durch Gedrückthalten eines Listenelements erreicht werden und beinhaltet auch die Abstimmungen der anderen Teilnehmer. Dadurch entfällt der in der TeaCo-iPhone-App vorhandene Bearbeiten- Abbildung 28: Mockup: Meetingansicht 41

48 3 Konzeption Button auf jedem Terminvorschlag. Eine Interaktion mit dem gewählten Meeting erfolgt erneut durch das kontextsensitive Menü. Dieses Menü beinhaltet: das Hinzufügen neuer Terminvorschläge oder Kommentare, das Abschließen des Meetings, die Verwaltung der Teilnehmer und das Verändern der Einstellungen (vgl. Abbildung 29). Abbildung 29: Mockup: Meetingansicht inklusive Menü Das Abschließen des Meetings und das Verfassen eines neuen Kommentars erfolgt über ein Pop-up. Im folgenden Abschnitt wird gezeigt, wie neue Terminvorschläge hinzugefügt und Teilnehmer verwaltet werden können. 42

49 3 Konzeption Teilnehmer verwalten und Terminvorschläge hinzufügen Über das kontextsensitive Menü der Meeting-Ansicht hat der Benutzer die Möglichkeit, die Teilnehmer des Meetings zu verwalten. Diese Verwaltung beinhaltet folgende drei Funktionen: Teilnehmer ausladen, Teilnehmern eine Nachricht senden, neue Teilnehmer einladen. Da diese Funktionen mehr Platz benötigen, als in einem Pop-up zur Verfügung steht, muss die Verwaltung auf eine weitere Ansicht ausgelagert werden. Diese Ansicht ist in Abbildung 30 dargestellt. Abbildung 30: Mockup: Teilnehmer eines Meetings verwalten Die Teilnehmer des Meetings sind in der oberen Hälfte der Darstellung in einer scroll-fähigen Box aufgeführt, sodass auch bei mehreren Teilnehmern nicht mehr als die Hälfte der Ansicht in Anspruch genommen werden muss. Durch das Setzen eines Hakens vor einem Teilnehmer werden die zuvor 43

50 3 Konzeption deaktivierten Buttons Ausladen und Nachricht senden aktiviert und es wird die Möglichkeit des Ausladens und des Nachrichten schickens geboten. Diese Funktionen sind ebenfalls mit mehreren Teilnehmern möglich. Das automatisierte Aktivieren und Deaktivieren der Buttons soll Fehleingaben verhindern und somit die Zufriedenstellung, aber auch die Effektivität und Effizienz der Benutzer steigern. In dem unteren Teil der Ansicht kann der Benutzer weitere Teilnehmer zu dem Meeting einladen. Um die dafür nötigen -Adressen einzugeben, stehen dem Benutzer folgende drei Methoden zur Verfügung: Auswahl aus dem Adressbuch des Android-Smartphones, Auswahl aus einer Sammlung von Adressen, der eingeladenen Teilnehmer zuvor erstellter Meetings (automatisch von TeaCo angelegt), Eingabe per Tastatur. Zusätzlich kann der Einladung ein optionaler Einladungstext beigefügt werden, der wie auch in allen anderen TeaCo-Varianten als Kommentar zum Meeting eingetragen werden kann. Um neue Terminvorschläge hinzuzufügen, steht die in Abbildung 30 dargestellte Ansicht zur Verfügung. Um dem Benutzer ein bekanntes Werkzeug zur Verfügung zu stellen, wird die aus dem integrierten Android-Google-Kalender verwendete Kalenderdarstellung genutzt. Auf diese Weise soll dem Benutzer der Einstieg und die Handhabung erleichtert werden. Es ist zu erkennen, dass keine Interaktionselemente zum Erreichen anderer Monate zur Verfügung stehen. Dies wird durch Wischen über das Display realisiert. Möchte der Benutzer mehrere Monate oder gar Jahre überspringen, so erreicht er dies über den Menüpunkt Gehe zu. Bereits vorhandene Terminvorschläge an bestimmten Tagen werden durch das Symbol angezeigt, welches in der Kalenderansicht auf dem ausgewählten Tag liegt (vgl. Abbildung 31). Die grünen Markierungen symbolisieren dabei vorhandene Terminvorschläge. Wählt der Benutzer einen Tag im Kalender aus, erhält er im unteren Teil der Ansicht eine Übersicht über die an dem Tag vorhandenen Terminvorschläge in Form einer Liste. Diese Listenelemente können wie gewohnt durch Gedrückthalten manipuliert werden. 44

51 3 Konzeption Abbildung 31: Mockup: Terminvorschlag erstellen 3.3 Feature-Sets In diesem Abschnitt sollen die in Kapitel 2.5 aufgeführten Use-Cases sowohl thematisch in Feature- Sets kategorisiert, als auch nach ihrer Relevanz priorisiert werden. Ein Feature-Set umfasst zusammenhängende Funktionen, die innerhalb einer Woche realisiert werden können. Die Use-Cases beinhalten den kompletten Funktionsumfang des zu entwickelnden Anwendungssystems, jedoch ist die Umsetzung weniger relevanter Features aufgrund der begrenzt verfügbaren Zeit optional. Feature-Set 1 - Meetingansicht Über die Navigation in der Meetingübersicht gelangt der Benutzer zur Meetingansicht. In dieser Ansicht verfügt der Benutzer über die Quickvote-Liste und kann die Planung des Meetings abschließen. 45

52 3 Konzeption Darüber hinaus gelangt der Benutzer zu den Ansichten Terminvorschläge hinzufügen und Teilnehmer verwalten. Folgende Features sollen in dieser Ansicht implementiert werden: Feature-Set 1.1 Abstimmung über Terminvorschläge (UC2) Manipulation von Terminvorschlägen (UC4) Zurücksetzen einer Abstimmung (UC5) Löschen eines Terminvorschlags (UC6) Feature-Set 1.2 Auswahl endgültiger Termine (UC7) Benachrichtigung über endgültige Termine (UC8) Verfassen, Bearbeiten und Löschen von Kommentaren (UC16) Feature-Set 2 - Teilnehmer verwalten und Terminvorschläge hinzufügen Aus der Meetingansicht gelangt man zu der Verwaltung der Teilnehmer und zum Hinzufügen von Terminvorschlägen. Diese Ansichten beinhalten folgende Features: Feature-Set 2.1 Erstellen neuer Terminvorschläge (UC3) Feature-Set 2.2 Einladen von Teilnehmern (UC11) Eingabe bereits bekannter Teilnehmer (UC12) Ausladen von Teilnehmern (UC14) 46

53 3 Konzeption Feature-Set 3 - Meetingübersicht Nach dem Einloggen und infolgedessen nach jedem zukünftigen Start (insofern kein Log-out erfolgt) ist dies die Startansicht von TeaCo-Android. In dieser Ansicht werden alle Meetings eines Benutzers zeitlich geordnet aufgelistet und können manipuliert werden. Diese Hauptansicht der Applikation enthält folgende Features: Navigation innerhalb der Meetingansicht und -übersicht (UC1) Erzeugen eines neuen Meetings (UC9) inklusive der Festlegung der Rechte eines neuen Meetings (UC10) Verlassen bzw. Löschen eines Meetings (UC15) Eingeladene Teilnehmer in ein neues Meeting übernehmen (Klonen, UC13, optional) Feature-Set 4 - Anmeldung/Registrierung Ohne vorheriges Einloggen in die Anwendung stellt dies die Startansicht der Applikation dar. Von hier aus ist es möglich, sich zu registrieren oder in TeaCo einzuloggen. Folgende Use-Cases sind in diesem Feature-Set enthalten: An- und Abmeldung (UC18) Registrierung (UC19) Feature-Set 5 - Verwaltungsbereich, optional Dieser Bereich stellt den aus TeaCo-Desktop bekannten Bereich myteaco dar. Hier können benutzerspezifische Einstellungen des Benutzerkontos vorgenommen werden. Das zu implementierende Feature ist die Individualisierung des Anwendungssystems (UC17) mit folgenden Funktionen: Angabe eines Namens, Angabe eines Passworts, Angabe einer Free/Busy-List (URL), 47

54 3 Konzeption Auswahl einer Systemsprache aus Deutsch, Englisch und Französisch, Änderung der primären -Adresse und Hinzufügen weiterer -Adressen, Ein- und Ausschalten der Status-Bar-Notification. Diese genannten Feature-Sets und die darin enthaltenen Features sollen gemäß dem FDD-Entwicklungsprozess implementiert werden (vgl. Abbildung 9). Die Feature-Sets selbst können aufgrund der verschiedenen Ansichten und somit disjunkten Mengen unabhängig voneinander realisiert werden. 48

55 4 Realisierung Bei der Implementierung von TeaCo-Android kamen clientseitig die Programmiersprache Java und serverseitig das Framework Ruby on Rails zum Einsatz. Im Folgenden sollen die verwendeten Techniken beschrieben werden. 4.1 Ruby on Rails Ruby on Rails (im Folgenden kurz Rails) ist ein quelloffenes Framework, welches in der Programmiersprache Ruby (Flanagan & Matsumoto, 2008) geschrieben ist und von Thomas & Hansson (2005) entwickelt wurde. Seitdem wird Rails vom Rails Core Team (Rails Core Developers, ) weiterentwickelt. Rails ermöglicht vor allem aufgrund der Model-View-Controller-Architektur eine agile Softwareentwicklung. Die ActionController-Komponente verarbeitet eingehende HTTP-Anfragen, welche durch öffentliche Methoden des Controllers behandelt werden. Anschließend wird die ActionView auf Grundlage eines Templates dazu veranlasst, eine Antwort zu generieren. Jede Entität innerhalb der Rails-Anwendung besitzt einen entsprechenden Controller. Zum Beispiel ist für alle Aktionen innerhalb eines Meetings in TeaCo der MeetingsController verantwortlich. Abhängig von der definierten Aktion im Controller erzeugt die ActionView-Komponente eine entsprechende Antwort auf die HTTP-Anfrage in verschiedenen Formaten, wie HTML, XML oder JSON. So wie jede Entität innerhalb der Rails-Anwendung einen entsprechenden Controller besitzt, besitzt sie auch eine entsprechende View-Komponente, die die passende Antwort liefert. Gemeinsam bilden die ActionView und der ActionController die ActionPack-Bibliothek. 49

56 4 Realisierung Die ActiveRecord-Komponente stellt das Model der Model-View-Controller-Architektur dar. Sie ist die Datenbankabstraktionsschicht von Rails und enthält Daten, die in der Datenbank abgelegt werden. Neben den Controllern und den Views, hat jede Entität auch ein Model. Mit Hilfe dieses Models, welches das entsprechende Datenbankobjekt umfasst, ist es möglich auf die Attribute der jeweiligen Entität zuzugreifen. Im Falle eines Meetings in TeaCo greift man z.b. auf den Meetingtitel durch die Methode meeting.title zu. Rails basiert auf den folgenden beiden Grundprinzipien: Don t repeat yourself: Nach diesem DRY-Prinzip sollte jede Information nur ein einziges Mal im Programmcode vorhanden sein, um Fehler zu vermeiden und den Programmcode so gering wie möglich zu halten. Aufgrund der ActiveRecord-Komponente reicht es z.b. Spalten einer Tabelle nur in der Datenbank festzulegen. Rails erstellt darauf aufbauend automatisch Getter- und Setter-Methoden, damit die Daten einfach aus der Datenbank ausgelesen oder hinein geschrieben werden können. Das hat auch den Vorteil, dass Informationen bzw. Anweisungen nicht inkonsistent werden können, falls sich die Datenbank ändert. Convention over Configuration: In Rails werden gewisse Konventionen eingehalten, um dem Entwickler unnötigen Konfigurationsaufwand zu ersparen. Existiert wie z.b. bei TeaCo ein Model namens meeting, dann geht Rails automatisch davon aus, dass auch eine passende Datenbank namens meetings existiert. Auch Beziehungen zu anderen Tabellen können komfortabel angelegt werden, indem z.b. durch eine 1:N-Beziehung eine Verknüpfung zu einer zweiten Tabelle angelegt wird. Rails geht dann davon aus, dass in der zweiten Tabelle eine Spalte namens meeting id vorhanden ist. Möchte der Entwickler von diesen Standardwerten abweichen, so können diese auch umkonfiguriert werden. 4.2 REST Reprensentational State Transfer (REST) ist ein Architektur-Paradigma für die Organisation von Informationen in verteilten Hypermedia-Anwendungen. Der Begriff wurde von Fielding (2000) in seiner Dissertation geprägt. Im Sinne von REST ist eine Ressource eine URL-adressierbare Entität, mit der über HTTP interagiert werden kann. Mit Hilfe einer eindeutigen URL wird festgelegt, auf welche 50

57 4 Realisierung Ressource zugegriffen wird, während über die HTTP-Aktion festgelegt wird, in welcher Form mit der Ressource interagiert wird. Dabei stehen die Aktionen GET, POST, PUT und DELETE zur Verfügung. Abhängig von dieser Aktion wird eine bestimmte Methode im entsprechenden Controller aufgerufen, die schließlich die Ressource manipuliert. Tabelle 2 zeigt eine Übersicht der Methoden im Controller und dessen Funktionen. Entsprechend sieht man die zur Verfügung stehenden HTTP-Aktionen, die an eine angegebene URL gesendet werden. HTTP- Aktion URL Methode im Controller Funktion GET /users index Listet alle vorhandenen Benutzer auf. POST /users create Erstellt einen neuen Benutzer. GET /users/new new Liefert ein Formular zur Erstellung eines neuen Benutzers. GET /users/1 show Gibt den Benutzer mit der ID 1 in einem bestimmten Format aus. GET /users/1/edit edit Liefert ein Formular zur Bearbeitung des Benutzers mit der ID 1. PUT /users/1 update Aktualisiert die Daten des Benutzers mit der ID 1, die dem PUT mitgesendet werden. DELETE /users/1 destroy Löscht den Benutzer mit der ID 1. Tabelle 2: URLs und Methoden in den Rails-Controllern In TeaCo sind die Daten streng hierarchisch strukturiert. Dies wirkt sich auch auf die URL aus, um eine bestimmte Ressource anzusprechen. Jeder Benutzer von TeaCo nimmt an einer gewissen Anzahl von Meetings teil. Jedes dieser Meetings wiederum hat beliebig viele Terminvorschläge, die über eine bestimmte Anzahl von Abstimmungen verfügen. Um diese hierarchische Struktur auch in den URLs weiterzuführen, ergibt sich für eine Abstimmung folgende Struktur: /users/6b3cdf128f2511bf75c86b7bb792333aa118606f/meetings/513/suggestions/42 /votes/31. Damit es nicht möglich ist, über die URL Zugang zu anderen TeaCo-Accounts zu bekommen, wird der Benutzer durch eine 40-stellige zufällige aber eindeutige User-ID identifiziert. Die URL zeigt die Abstimmung mit der ID 31 aus dem Terminvorschlag mit der ID 42. Dieser Terminvorschlag gehört zu dem Meeting mit der ID 513, woran der Benutzer mit der User-ID 51

58 4 Realisierung 6b3cdf128f2511bf75c86b7bb792333aa118606f teilnimmt. Somit lässt sich bei einem Zugriff auf eine Ressource von TeaCo feststellen, ob ein bestimmter Nutzer Zugriff auf das angegebene Meeting hat und ob der Terminvorschlag zu dem Meeting und die Abstimmung zu dem Terminvorschlag gehört. Ist dies nicht der Fall, wird der Zugriff von der Anwendung verweigert. Diese URL greift in Kombination mit der HTTP-Aktion auf eine der sieben Methoden index, create, new, show, edit, update und destroy im Controller zu. Da sich diese Methoden oftmals nicht unterscheiden, sondern die Standardaktionen ausführen sollen, kommt in TeaCo das Rails-Plugin make resourceful (Catlin, 2009) zum Einsatz. Dieses generiert im Sinne des DRY-Prinzips alle sieben Controller-Methoden und stellt abhängig vom Controller und dessen Zugehörigkeit Ruby-Variablen zur Verfügung, die von der ActionView genutzt werden können, um entsprechende Ausgaben zu generieren. Am Beispiel des folgenden Ausschnitts des Vote-Controllers wird dies deutlich. c l a s s V o t e s C o n t r o l l e r < A p p l i c a t i o n C o n t r o l l e r m a k e r e s o u r c e f u l do b u i l d : a l l b e l o n g s t o : s u g g e s t i o n, : meeting, : u s e r end end Quelltext 1: make resourceful im Vote-Controller In diesem Controller, in dem die Verwaltung der Abstimmungsergebnisse stattfindet, werden alle Controller-Methoden durch das make resourceful-plugin generiert. Außerdem werden Abhängigkeiten definiert, damit dadurch entsprechende Informationen in der ActionView zur Verfügung stehen. Folglich stehen in der ActionView zur Verfügung. Diese repräsentieren das durch die URL angesprochene Abstimmungsergebnis, den dazugehörigen Terminvorschlag, das entsprechende Meeting und letztlich den Benutzer, zu dem diese Informationen gehören. 52

59 4 Realisierung 4.3 Umsetzung Bei der Implementierung der Android-Applikation kamen vor allem die Programmiersprache Java und die Auszeichnungssprache XML zum Einsatz. Wir betrachten im Folgenden zwei wesentliche Punkte, die zur Herstellung einer Kommunikation zwischen TeaCo-Server und TeaCo-Android-Applikation nötig sind. Dies ist zum einen die Identifizierung der Anfragen der Android-Applikation (Abschnitt 4.3.1), zum anderen die darauf folgende Antwort des Servers (Abschnitt 4.3.2) User-Agent Die TeaCo-Android-Applikation benötigt die Daten vom Server in einem anderen Format, als es die anderen TeaCo-Varianten tun. Entsprechend wird bei jeder HTTP-Aktion ein User-Agent-String mitgesendet. Dies erfolgt jedoch im Gegensatz zu einem Browser nicht automatisch, sondern muss explizit angegeben werden. In Quelltext 2 ist dies am Beispiel einer GET-Aktion von TeaCo-Android dargestellt. f i n a l S t r i n g USER AGENT = TeaCoAndroid ; h t t p G e t. s e t H e a d e r ( User Agent, USER AGENT) ; Quelltext 2: Setzen des User-Agent-String einer HTTP-Aktion von TeaCo-Android Damit der Server entsprechend dieses User-Agent-Strings Antworten generiert, müssen auch dort Anpassungen erfolgen. In der mime-types.rb muss ein Pseudo-Mime-Type für die Android-Applikation angelegt werden (vgl. Quelltext 3). Dieser ermöglicht schließlich das Generieren einer Ausgabe für das spezifische Format. Mime : : Type. r e g i s t e r a l i a s t e x t / html, : a n d r o i d n a t i v e Quelltext 3: Eintragung des Mime-Types für TeaCo-Android Im ApplicationController wird der User-Agent-String einer Anfrage ausgelesen und entsprechend das Format festgelegt, welches zuvor als Mime-Type registriert wurde (vgl. Quelltext 4). Auf- 53

60 4 Realisierung grund dieses Formats werden schließlich die Dateiendungen der zur Generierung der Ausgabe angeforderten Dateien erweitert. So wird Beispielsweise bei der Ausgabe der Meetings in TeaCo-Desktop die Datei meetings/show.haml angefordert, welche eine Liste aller Meetings generiert. Bei einem Zugriff von TeaCo-Android wird jedoch die Datei meetings/show.android native.haml angefordert, die eine entsprechende Liste im XML-Format liefert. def i s a n d r o i d n a t i v e r e q u e s t? end r e q u e s t. u s e r a g e n t = / ( TeaCoAndroid ) / b e f o r e f i l t e r : s e t p h o n e f o r m a t def s e t p h o n e f o r m a t i f i s a n d r o i d n a t i v e r e q u e s t? r e q u e s t. format = : a n d r o i d n a t i v e end end Quelltext 4: Erkennung des zugreifenden Endgeräts und Festlegung des Antwortformats im Application-Controller Die letzte Anpassung erfolgt in der responses.rb, in der für das make resourceful-plugin die Standard- Antworten festgelegt werden (vgl. Quelltext 5). Auf Grundlage dieser Einträge erfolgt schließlich die Generierung der Standard-REST-Aktionen. 54

61 4 Realisierung r e s p o n s e f o r ( : show, : index, : e d i t, : new ) do format format. html format. j s format. mobile format. i p h o n e n a t i v e format. a n d r o i d n a t i v e end Quelltext 5: Antwortformate für die REST-Standard-Aktionen Serverantwort Während der Konzeption war noch nicht klar, ob die Daten vom Server im XML- oder im JSON- Format an den Client gesendet werden sollen. Um die unabhängige Trennung des Models, der View und des Controllers gemäß des MVC-Pattern zu gewährleisten, werden die Daten im XML-Format gesendet. Diese Daten werden ausschließlich in der View generiert, und nicht wie die JSON-Daten, im Controller. Dabei wird das von Apple und NeXT entwickelte Property List Format (plist, Apple Inc. ( )) verwendet, da sich dieses auch bereits bei der Implementierung von TeaCo-iPhone bewährt hat. Quelltext 6 zeigt einen Ausschnitt einer plist für zwei Meetings. Mit Hilfe der Java-Klasse javax.xml.parsers ist es nun möglich, die empfangene plist in entsprechende Java-Objekte zu parsen. Dazu wurde entsprechend des XML Schema (XSD) ein Parser entwickelt, dem folgende XML- Schlüssel bekannt sind: INTEGER, STRING, REAL, DATE, DICT, ARRAY, TRUE, FALSE. Neben den primitiven Datentypen wurden die übrigen Datentypen DICT und ARRAY wie folgt implementiert: DICT: Ein Dict-Eintrag wurde als HashMap implementiert. HashMaps haben gegenüber Arrays den Vorteil, dass die Position eines Objekts nicht bekannt sein muss, sondern mit Hilfe dessen Keys darauf zugegriffen werden kann. ARRAY: Um Array-Einträge zu parsen, wurden ArrayLists zur Hilfe genommen, da bei diesem Datentyp die Länge des Arrays nicht bekannt sein muss. Somit muss das Array nicht mit einer bestimmten Länge initialisiert werden. 55

62 4 Realisierung < p l i s t v e r s i o n = 1. 0 > < d i c t > < key > Meetings < / key > < a r r a y > < d i c t > < key > M e e t i n g T i t l e < / key > < s t r i n g > Kinobesuch < / s t r i n g > < key > M e e t i n g V a l u e < / key > < i n t e g e r > 1 < / i n t e g e r > < key >Meeting Owner< / key > < t r u e / > < / d i c t > < d i c t > < key > M e e t i n g T i t l e < / key > < s t r i n g > Besuch des Weihnachtsmarkts < / s t r i n g > < key > M e e t i n g V a l u e < / key > < i n t e g e r >2< / i n t e g e r > < key >Meeting Owner< / key > < f a l s e / > < / d i c t > < / a r r a y > < / d i c t > < / p l i s t > Quelltext 6: Ausschnitt einer Property List für Meetings Login In TeaCo-iPhone wurde erstmals die Möglichkeit geschaffen, sich mit seiner -Adresse und einem persönlich ausgewählten Passworts einloggen zu können. Jedoch kann ein Passwort nur unter Zuhilfenahme einer web-basierten Variante von TeaCo zu einem bestehenden Account hinzugefügt werden. Benutzer werden wie in Abschnitt 4.2 beschrieben anhand der 40-stelligen User-ID identifiziert. Sobald ein Benutzer neu dem TeaCo-System hinzugefügt wird sei es durch eine Regis- 56

63 4 Realisierung trierung (Eigenhinzufügen) oder durch eine Einladung (Fremdhinzufügen) bekommt er eine Benachrichtigung via . In dieser Nachricht wird ihm unter anderem seine User-ID mitgeteilt. Um nachträglich kein Passwort setzen zu müssen, ist es in TeaCo-Android möglich, sich neben der gewohnten Vorgehensweise mit -Adresse und Passwort, mit der persönlichen User-ID einzuloggen. Eine Darstellung dieses Verfahrens findet sich in Abschnitt 5 in Abbildung

64 5 Dialogbeispiele Im folgenden Abschnitt werden die verschiedenen Ansichten von TeaCo-Android dargestellt. Da es innerhalb der Applikation (mit Ausnahme des Login-Bildschirms) die Möglichkeit gibt, das Aussehen zwischen zwei vorhandenen Themen zu entscheiden, werden diese im Folgenden parallel dargestellt. 5.1 Login Wird TeaCo-Android vom Benutzer zum ersten Mal gestartet oder loggt sich dieser aus, gelangt er zum Anmeldebildschirm (vgl. Abbildung 32). In dieser Ansicht hat der Benutzer die Möglichkeit, sich mit Hilfe seiner -Adresse und seinem persönlichen Passwort einzuloggen. Alternativ zu diesem Verfahren besteht außerdem die Möglichkeit, sich mit seiner persönlichen User-ID einzuloggen. Darüber hinaus hat der Benutzer an dieser Stelle die Möglichkeit, sich zu registrieren und somit einen neuen Account anzulegen. Zum entsprechenden Dialog gelangt der Benutzer über das kontextsensitive Menü, welches im Folgenden in Abschnitt 5.2 genauer beschrieben wird. 58

65 5 Dialogbeispiele Abbildung 32: Anmeldebildschirm in TeaCo-Android 5.2 Meetingübersicht Wie bereits in Abschnitt 3.2 in Abbildung 23 gezeigt, gelangt man nach erfolgreichem Einloggen von dem Login-Bildschirm zur Meetingübersicht (vgl. Abbildung 33). Die Meetings sind an dieser Stelle in die Bereiche Noch nicht abgestimmte Meetings und Bereits abgestimmte Meetings unterteilt. Auf den in TeaCo-Mobile-NG vorhandenen dritten Bereich Eigene Meetings wurde aufgrund der Analyseergebnisse verzichtet. In jeder Zeile dieser Bereiche ist ein Meeting aufgelistet und folgende Informationen sind sofort ersichtlich: Der Initiator des Meetings, anhand des Symbols am Anfang jeder Zeile, die Eingeschränktheit eines Meetings, durch das Schloss-Symbol vor dem Meeting-Titel, 59

66 5 Dialogbeispiele der Abstimmungsstatus (prozentualer Anteil der abgestimmten Terminvorschläge) am Ende der Zeile, und die Anzahl der ausgewählten Terminvorschläge, neben dem Abstimmungsstatus. (a) Light-Theme (b) Dark-Theme Abbildung 33: Meetingübersicht in TeaCo-Android Im Vergleich zur Meetingübersicht in der iphone-applikation in Abbildung 19 ist zum einen hervorzuheben, dass Interaktionen in TeaCo-Android über das kontextsensitive Menü oder durch Gedrückthalten eines Listenelements durchgeführt werden können. Dadurch müssen die vorhandenen Buttons in der Kopf- und Fußzeile von TeaCo-iPhone nicht dargestellt werden. Dieser Platz kann folglich eingespart werden. Zum anderen wurde die Anzahl der ausgewählten Terminvorschläge nicht wie in TeaCo-iPhone in grün, sondern, um eine bessere Assoziation zur Meetingansicht zu gewährleisten, in blau dargestellt. 60

67 5 Dialogbeispiele Die Manipulation eines Meetings erfolgt schließlich durch ein Kontextmenü, welches durch Gedrückthalten eines Listenelements erreicht werden kann. Dort kann ein Meeting geklont, umbenannt und gelöscht bzw. verlassen werden (vgl. Abbildung 34). Abbildung 34: Kontextmenü eines Meetings Weitere Interaktionen, die über diese Ansicht ausführbar sind, können über das kontextsensitive Menü erreicht werden (vgl. Abbildung 35). Diese Aktionen sind: ein neues Meeting erstellen, woraufhin sich ein Dialog öffnet, die Meetingliste neu laden, aus TeaCo-Android ausloggen, wodurch man wieder zum Anmeldebildschirm gelangt und die Einstellungen öffnen (vgl. Abschnitt 5.7). Abbildung 35: Menü in der Meetingübersicht 61

68 5 Dialogbeispiele 5.3 Meeting erstellen Möchte der Benutzer ein neues Meeting erstellen und hat folglich in der Meetingübersicht den Menüeintrag Neues Meeting ausgewählt, so öffnet sich ein Dialog, in dem der Titel und die Eingeschränktheit des Meetings festgelegt werden können. Dieser ist in Abbildung 36a dargestellt. Analog dazu ist in Abbildung 36b der Dialog zum Bearbeiten eines Meetings dargestellt. Im Hintergrund der Dialoge lässt sich erkennen, dass sich das jeweils verwendete Thema unterscheidet, die Dialoge jedoch unabhängig vom Thema das gleiche Aussehen behalten. Über das in Abschnitt 5.2 beschriebene und in Abbildung 34 dargestellte Kontextmenü ist es möglich, ein Meeting zu klonen. Der erscheinende Dialog ist der gleiche, der für das Erstellen eines neuen Meetings verwendet wird. Lediglich der Titel und der Status der Eingeschränktheit des Meeting werden übernommen und entsprechend im Dialog dargestellt. (a) Neues Meeting erstellen (Light-Theme) (b) Meeting bearbeiten (Dark-Theme) Abbildung 36: Meeting-Dialog in TeaCo-Android 62

69 5 Dialogbeispiele 5.4 Terminvorschläge hinzufügen Nachdem der Benutzer ein neues Meeting erstellt hat, gelangt er direkt zu der Ansicht, in der Terminvorschläge hinzugefügt werden können (vgl. Abbildung 37). Dort ist die Eingabe des Datums und der Start- und Endzeit sowohl über die + - und - -Buttons als auch mit Hilfe textueller Eingabe möglich. Um dem Benutzer die Einstellung der Start- und Endzeit zu vereinfachen, bleibt bei einer Veränderung der Startzeit die Dauer festgesetzt und die Endzeit stellt sich entsprechend automatisch ein. Möchte der Benutzer die Dauer des Terminvorschlags ändern, muss eine Einstellung der Endzeit vorgenommen werden. Da in TeaCo keine Terminvorschläge mit einer Dauer kleiner als 30 Minuten möglich sind, werden solche Zeiteinstellungen von TeaCo-Android nicht zugelassen. Entsteht also bei der Änderung der Endzeit ein Intervall, dass die 30 Minuten unterschreitet, passt sich automatisch die Startzeit an, sodass ein fehlerhaftes Hinzufügen von Terminvorschlägen gänzlich verhindert wird. (a) Light-Theme (b) Dark-Theme Abbildung 37: Terminvorschläge hinzufügen in TeaCo-Android 63

70 5 Dialogbeispiele Nach dem Hinzufügen eines Terminvorschlags wird in der Ansicht verblieben, um weitere Terminvorschläge hinzufügen zu können. Die Rückmeldung über das erfolgreiche Hinzufügen eines Terminvorschlags erfolgt in Form eines sogenannten Toasts am unteren Bildschirmrand, unterhalb des Hinzufügen-Buttons (vgl. Abbildung 38). Abbildung 38: Rückmeldung für erfolgreiches Terminvorschlag hinzufügen in TeaCo-Android 5.5 Meetingansicht Im Normalfall gelangt ein Benutzer in die Meetingansicht, indem er ein Meeting in der Meetingübersicht auswählt. Hat er jedoch zuvor ein Meeting angelegt und schließlich Terminvorschläge hinzugefügt, gelangt der Benutzer über die Hardware-Taste Zurück in die Meetingansicht des zuvor erstellten Meetings. In dieser Ansicht sind sowohl die Quickvote-Liste als auch die Kommentare dargestellt (vgl. Abbildung 39). Um ausgewählte Terminvorschläge zu erkennen, dient zum einen der blaue Button mit dem Haken am Anfang jeder Quickvote-Zeile als auch die blaue transparente Hinterlegung selbiger. In Abbildung 39 ist außerdem ein Terminvorschlag vorhanden, bei dem der Benutzer noch nicht abgestimmt hat. Dieser ist sowohl daran zu erkennen, dass keiner der Radio-Buttons ausgewählt ist, als auch an der orangefarbigen transparenten Hinterlegung. Aufgrund dessen werden diejenigen Terminvorschläge sofort sichtbar, über die noch nicht abgestimmt wurde. Die Manipulation einzelner Terminvorschläge oder Kommentare erfolgt wie gewohnt durch Gedrückthalten eines dieser Listenelemente, woraufhin sich das Kontextmenü öffnet. Das Kontextmenü zum Manipulieren von Kommentaren beinhaltet die Auswahlmöglichkeiten Bearbeiten und Löschen, wohingegen über das Kontextmenü eines Terminvorschlags zusätzlich die Abstimmungen geöffnet werden können (vgl. Abbildung 40). Eine Ansicht dieses Dialogs mit den Abstimmungen ist in Abbildung 41 dargestellt. 64

71 5 Dialogbeispiele (a) Light-Theme (b) Dark-Theme Abbildung 39: Meetingansicht in TeaCo-Android Die Meetingansicht enthält ebenso wie die Meetingübersicht ein kontextsensitives Menü. Kontextsensitive Menüs haben immer die selbe Darstellungsweise, enthalten jedoch je nach Implementierung unterschiedliche Menüpunkte. Über das kontextsensitive Menü der Meetingansicht können folgende Aktionen ausgeführt werden (vgl. Abbildung 42): ein neuer Terminvorschlag kann hinzugefügt werden, um einen neuen Kommentar zu schreiben öffnet sich ein entsprechender Dialog, der Benutzer kann das Meeting abschließen, somit die ausgewählten Termindaten versenden und sowohl eine Nachricht als auch einen Ort hinzufügen, die Teilnehmer können verwaltet und somit neue Teilnehmer zu einem Meeting eingeladen oder bereits vorhandene Teilnehmer ausgeladen werden (vgl. Abschnitt 5.6), 65

72 5 Dialogbeispiele Abbildung 40: Kontextmenü eines Terminvorschlags Abbildung 41: Abstimmungen eines Terminvorschlags die Ansicht und somit alle Terminvorschläge und Kommentare können neu geladen werden und die Einstellungen können wie auch aus der Meetingübersicht aus dieser Ansicht erreicht werden (vgl. Abschnitt 5.7). Abbildung 42: Menü in der Meetingansicht In Abschnitt 5.2 wurde gezeigt, dass durch diese Art von Menüs gegenüber TeaCo-iPhone durch Verzicht auf die Kopf- und Fußzeile einiges an Platz gewonnen werden kann. In TeaCo-Mobile-NG kann dies auf die selbe Art und Weise geschehen. In Abbildung 7 ist zu erkennen, dass die Kopf- und Fußzeile ebenfalls nur diejenigen Interaktionen enthalten, die in TeaCo-Android durch die Menüs nicht 66

73 5 Dialogbeispiele dargestellt werden müssen. Somit kann auch gegenüber TeaCo-Mobile-NG der Platz der Kopf- und Fußzeile eingespart werden. 5.6 Teilnehmer verwalten Über den Button Teilnehmer verwalten aus Abbildung 42 können vorhandene Teilnehmer ausgeladen oder neue Teilnehmer eingeladen werden. Abbildung 43 zeigt die Unterteilung dieser Ansicht in Teilnehmer des Meetings und Neue Teilnehmer einladen. In dem Bereich Teilnehmer des Meetings können vorhandene Teilnehmer ausgeladen oder ihnen eine Nachricht gesendet werden. In dem Bereich Neue Teilnehmer einladen können mit Hilfe der Buttons -Adressen aus dem persönlichen Adressbuch sofern Kontakte mit eingetragenen -Adressen vorhanden sind oder aus den durch TeaCo bekannten -Adressen, ausgewählt und ins -Feld eingefügt werden. Alternativ kann die Eingabe einer -Adresse auch direkt im -Feld erfolgen, wobei dadurch die -Adressen aus TeaCo und dem Adressbuch berücksichtigt und mit Hilfe einer AutoCompletion vorgeschlagen werden. Letztlich kann dieser Einladung noch ein Einladungstext hinzugefügt und die Einladung als Kommentar eingetragen werden. 67

74 5 Dialogbeispiele (a) Light-Theme (b) Dark-Theme Abbildung 43: Verwaltung der Teilnehmer in TeaCo-Android 5.7 Einstellungen Die persönlichen Einstellungen des Benutzers sind wie auch in TeaCo-iPhone in einer separaten Ansicht ausgelagert. In dieser Ansicht können persönliche Kontoeinstellungen getätigt werden. Dies beinhaltet unter anderem den Namen und das Passwort. Außerdem können neue -Adressen über einen Menüpunkt in dem kontextsensitiven Menü hinzugefügt werden, um in einem Konto mehrere -Adressen zu verwenden oder verschiedene Konten zusammenzuführen. Zusätzlich zu den 68