TeaCo ipad Das Beste aus zwei Welten

Transkript

1 Institut für Multimediale und Interaktive Systeme Direktor: Prof. Dr. rer. nat. Michael Herczeg TeaCo ipad Das Beste aus zwei Welten Eine Socialware zwischen Desktop und Smartphone Bachelorarbeit vorgelegt von: Jan-Philipp Kalus Prüfer: Prof. Dr. rer. nat. Michael Herczeg Wissenschaftliche Begleitung: Dr. rer. nat. Martin Christof Kindsmüller

2 Kurzfassung Die neuesten Entwicklungen zeigen die anwachsende Beliebtheit von Tablets wohingegen Desktop- PCs und Smartphones schon seit langem auf dem Markt etabliert sind. Diese Arbeit befasst sich mit der Frage, wie Anwendungssysteme, die bereits für Desktop-PCs und Smartphones existieren, auf ein Tablet übertragen werden können. Dabei wird ein besonderes Augenmerk auf die Benutzungsschnittstelle gelegt. Beispielhaft für alle Anwendungssysteme und Tablets soll deshalb eine native ipad-applikation für TeaCo entwickelt werden. TeaCo ist ein Werkzeug zur Terminplanung für kleinere und größere Gruppen. Es möchte vor allem durch seine Leichtgewichtigkeit überzeugen. Für TeaCo existiert bereits je eine Variante für Desktop-Browser und mobile Browser sowie eine Variante als native iphone-applikation. Zunächst wird eine Analyse durchgeführt, die sich vor allem mit den Erwartungen der Benutzer und bereits aufs ipad übertragenen Anwendungssystemen befasst. Die daraus gewonnenen Erkenntnisse werden in der Konzeption genutzt, um im Anschluss die ipad-applikation in einem Entwicklungsprozess zu realisieren, welcher die Elemente aus dem User Centered Design und dem Feature Driven Development verbindet. Eine abschließende Evaluation wird dann zeigen, ob die ipad-applikation gebrauchstauglich und ein Zugewinn neben den bereits existierenden TeaCo-Varianten ist. Danach kann bewertet werden, auf welchem Wege und mit welchen Mitteln sich bestehende Anwendungssysteme erfolgreich auf ein Tablet übertragen lassen. Schlüsselwörter Terminkoordination, Tablet, ipad, Benutzungsschnittstelle 2

3 Abstract The latest developments evince the increase in popularity of tablets whereas desktop PCs and smartphones are established in the market place for a long time. This thesis enters into the question, how application systems, that already exist for desktop PCs and smartphones, can be applied on a tablet. At this the main attention will be on the user interface. Representing all application systems and tablets, a native ipad application for TeaCo shall be developed. TeaCo is a lightweight tool for appointment coordination within small and large groups. There are versions of TeaCo for desktop and mobile browsers as well as a native iphone application. At first an analysis is done, in which the user s expectations are inquired in particular. In addition to that application systems, which were already applied on the ipad, are analyzed. With this new knowledge a native ipad application is designed and developed. The development process combines parts of user centered design with parts of the feature driven development. The concluding evaluation will reveal the level of the application s usability and evaluate the gain for the user considering the existing versions of TeaCo. Accordingly to that, the best ways to apply existing application systems to a tablet can be discussed. Keywords appointment coordination, tablet, ipad, user interface 3

4 Inhaltsverzeichnis Kurzfassung 2 Abstract 3 1 Einleitung Zielsetzung Stand der Technik Vorgehensweise Analyse Aufgabenanalyse Benutzeranalyse Organisationsanalyse Kontextanalyse Use Cases Konzeption Systemarchitektur Benutzungsschnittstelle Feature-Sets Realisierung Serverseitige Technik Clientseitige Technik Umsetzung Dialogbeispiele Login Meetingübersicht Meetingansicht

5 6 Evaluation Ziele Vorgehensweise Ergebnisse Anpassungen Zusammenfassung und Ausblick Zusammenfassung Offene Punkte und Ausblick Abbildungen 102 Quelltexte 104 Literatur 105 Abkürzungen 108 Glossar 109 Erklärung 112 Anhang A, Leitfaden Analyse 113 Anhang B, Rohdaten Analyse 119 Anhang C, Leitfaden Evaluation 122 Anhang D, Rohdaten Evaluation 127 5

6 1 Einleitung Desktop-PCs und Smartphones haben sich schon seit längerem auf dem Markt etabliert und gehören in entwickelten Ländern sowohl beruflich als auch privat zur Normalität. Indes zeigen die neuesten Entwicklungen, dass so genannte Tablets immer beliebter werden. Tablets sind flache, mobile Computer mit Touchscreen, die zumeist mit den Fingern bedient werden. Im Jahr 2010 betrug der Anteil der Tablets drei Prozent des gesamten deutschen PC-Markts (BITKOM e.v., 2011a). Für das Jahr 2011 wird prognostiziert, dass bereits jedes zehnte verkaufte Gerät ein Tablet ist (BITKOM e.v., 2011b). Und auch in den folgenden Jahren soll der Anteil dieser neu entstandenen Geräteklasse weiter wachsen. Durch diesen aktuellen Trend ist eine neue Problemstellung im Bereich Interaktionsdesign entstanden. Viele Anwendungssysteme existieren bereits sowohl für Desktop-PCs als auch für Smartphones. Die Interaktionsformen für diese beiden Geräteklassen sind allerdings sehr unterschiedlich. Während Desktop-PCs über vergleichsweise große Displays verfügen und zur Eingabe vorwiegend Maus und Tastatur bereitstellen, bieten Smartphones auf dem Display deutlich weniger Platz. Die Eingabeformen der Smartphones variieren je nach Modell. Die gängigsten Eingabeformen sind Multi-Touch-Displays, Miniatur-Tastaturen, Tasten und Schalter. Darüber hinaus verfügen viele Smartphones über verschiedene Sensoren wie zum Beispiel einen Beschleunigungssensor oder einen Helligkeitssensor. Betrachtet man nun die Interaktionsmöglichkeiten eines Tablets, so lässt sich feststellen, dass weder die Interaktionsformen (Herczeg, 2006) eines Desktop- PCs noch die Interaktionsformen eines Smartphones ohne weiteres auf eine Benutzungsschnittstelle für einen Tablet übertragen werden können. Vielmehr muss für die Benutzungsschnittstelle eines Tablets für jeden Anwendungsfall differenziert analysiert werden, ob eher die Interaktionsform des Desktop-PCs oder die Interaktionsform des Smartphones angewendet werden kann. Da in bestimmten Anwendungsfällen beide Interaktionsformen unpassend sein können, müssen ebenso neue Interaktionsformen speziell für Tablets entwickelt werden. Ein System, welches bereits für Desktop-PCs und Smartphones existiert, ist der Team- und Terminkoordinator TeaCo (Lohrenz, 2009). Dieses webbasierte Terminplanungswerkzeug bietet seinen Nutzern die Möglichkeit zur effizienten Terminfindung in kleinen und großen Gruppen. Um 6

7 mit TeaCo einen Termin für ein Meeting zu finden, erstellt der Initiator ein neues Meeting, legt eine beliebige Anzahl von Terminvorschlägen an und lädt die gewünschten Teilnehmer via ein. Die Teilnehmer können das Meeting über eine eindeutige persönliche URL im Browser öffnen und für jeden Terminvorschlag festlegen, ob sie Zeit haben oder nicht. Sobald ein passender Termin gefunden wurde, kann einer der Teilnehmer eine über das Anwendungssystem verschicken, welche die anderen Teilnehmer über den gewählten Termin informiert. Abbildung 1: TeaCo Desktop, Meetingansicht Neben TeaCo Desktop (Abb. 1) für Desktop-Browser (Lohrenz, 2009) und TeaCo Mobile (Abb. 2a) für mobile Browser (Roenspieß, 2009) existiert TeaCo iphone (Abb. 2b), eine native iphone- Applikation (Schröder, 2010). Um von einem Tablet auf TeaCo zuzugreifen, steht seit deren Weiterentwicklung (Kalus & Wittstock, 2011) die Variante TeaCo Mobile zur Verfügung. Allerdings ist TeaCo Mobile für Smartphones optimiert. Die technischen Möglichkeiten von Tablets können von TeaCo Mobile nicht in vollem Umfang genutzt werden. Vermutlich ließe sich die Ge- 7

8 brauchstauglichkeit (nach DIN EN ISO , siehe auch Herczeg, 2007, S. 188) ebenso wie die Performance mit einer nativen Applikation erheblich steigern. (a) TeaCo Mobile (b) TeaCo iphone Abbildung 2: TeaCo Mobile und TeaCo iphone, Meetingansicht Da das Apple ipad zurzeit den größten Anteil am Tablet-Markt hat (The Nielsen Company, 2011) und Apple die Softwareentwicklung für das ipad durch das ausführlich dokumentierte ios Software Development Kit (ios SDK, Apple Inc., 2011e) und die ios Human Interface Guidelines (ios HIG, Apple Inc., 2011d) unterstützt, soll während dieser Arbeit beispielhaft für alle Tablets eine native ipad-applikation für TeaCo (TeaCo ipad) entstehen. Das Betriebsystem des ipads ist Apple ios. 1.1 Zielsetzung Im Rahmen dieser Arbeit soll untersucht werden, welche Interaktionsformen sich für Tablets eignen. Dabei soll analysiert werden, in welchen Fällen bekannte Interaktionsformen von Desktop- 8

9 PCs oder Smartphones unter Umständen mit Anpassungen übernommen werden können und in welchen Fällen neue Interaktionsformen konzipiert werden müssen. Da TeaCo sowohl für Desktop-PCs als auch für Smartphones existiert, erfüllt es die Voraussetzungen, um als Beispiel für die oben genannten Analysen zu dienen. Gestützt auf die angestrebten Analysen soll eine native ipad-applikation für TeaCo konzipiert, implementiert und evaluiert werden. 1.2 Stand der Technik Mittlerweile existieren viele Softwaresysteme für die drei Geräteklassen, die in dieser Arbeit untersucht werden sollen (Desktop-PC, Tablet, Smartphone). Besonders für die Socialwares wie zum Beispiel Facebook oder Twitter existieren neben der Desktop-Variante auch Varianten für den Großteil an Smartphones und Tablets. Dennoch sollen im Folgenden vor allem Terminfindungswerkzeuge und deren Ausprägungen auf den drei Geräteklassen untersucht werden. Dabei lässt sich feststellen, dass es keines der vielen auf dem Markt befindlichen Terminfindungswerkzeuge schafft, auf allen drei Geräteklassen gleichermaßen gute Software bereitzustellen. Besonders die Tablets werden hierbei kaum unterstützt. Aus diesem Grund wird am Ende dieses Unterkapitels das Kalenderwerkzeug ical (Apple Inc., 2011c) von Apple vorgestellt, da ein Kalenderwerkzeug dem Wesen eines Terminfindungswerkzeugs ähnelt und ical auf dem Mac, dem ipad und dem iphone gleichermaßen sorgfältig implementiert ist TeaCo TeaCo Mobile ist bisher die einzige Möglichkeit, TeaCo auf einem Tablet, hier ipad, zu bedienen. TeaCo Mobile ist für Smartphones optimiert, lässt sich aber auf dem ipad ebenso gut bedienen und bietet im Wesentlichen alle Funktionen, die auch TeaCo Desktop bereitstellt. In Abbildung 3 ist die Meetingansicht von TeaCo Mobile auf dem ipad zu sehen. Die Abbildung verdeutlicht beispielhaft, dass TeaCo Mobile die Darstellungsmöglichkeiten, die sich durch das größere Display eines Tablets im Vergleich zu einem Smartphone nicht ausnutzt und somit viel Platz auf dem 9

10 Display ungenutzt bleibt. Für die größeren Displays von Tablets wäre im Fall der Meetingansicht auch eine Darstellung ähnlich der Desktop-Variante (vgl. Abb. 1) denkbar. Abbildung 3: TeaCo Mobile auf dem ipad, Meetingansicht Doodle Doodle ist ein webbasiertes Werkzeug zur Terminfindung in Gruppen. Die Nutzung der Browser- Variante ist kostenlos und bedarf keiner Registrierung. Doodle bietet drei Funktionen: Terminfindung Diese Funktion dient der Terminfindung in größeren Gruppen und bietet grundsätzlich die selben Funktionen wie TeaCo. Abstimmung Mithilfe dieser Funktion lässt sich mit einer großen Gruppe eine Wahl aus beliebigen Dingen treffen. MeetMe Mit dieser Funktion kann man anderen Menschen zeigen, wann man für ein Treffen Zeit hat, und diese dann Vorschläge für ein Treffen machen lassen. 10

11 Neben der Browser-Variante von Doodle, die sowohl auf Desktop-Browsern als auch auf Tablet- Browsern und Smartphone-Browsern funktioniert, gibt es noch drei Varianten von Doodle, die besonders für Smartphones optimiert sind. Zum einen existiert eine zusätzliche Variante speziell für Smartphone-Browser, zum anderen gibt es eine native Applikation für das iphone und eine für Android-Smartphones. Abbildung 4 zeigt die Browser-Variante von Doodle auf einem ipad. Der Aufbau der Internetseite zeigt, dass auch hier die Browser-Variante von Doodle nicht für Tablets optimiert ist. Vielmehr haben die Entwickler nicht zwischen Desktop-Browsern und Tablet-Browsern unterschieden und liefern für beide Geräteklassen das selbe Web-Dokument. Abbildung 4: Doodle Desktop, Tabellenansicht 11

12 1.2.3 ical ical ist ein Kalenderwerkzeug von Apple. ical existiert für den Mac, für das iphone und für das ipad. Somit ist ical in jeder der drei Geräteklassen Desktop-PC, Tablet und Smartphone vertreten. Da ical zuletzt auf dem ipad veröffentlicht wurde, lässt sich beispielhaft betrachten, wo die Benutzungsschnittstelle der ipad-version den Versionen für Mac oder iphone ähnelt und wo sie sich von diesen unterscheidet. Abbildung 5 zeigt die Wochenansicht von ical auf dem ipad. Es lässt sich erkennen, dass sich die Kalender-Darstellung, die den größten Teil des Displays einnimmt, sehr an der Darstellung der Desktop-Variante orientiert. Andererseits sind die Kopf- und Fußzeile in Form und Funktion bereits vom iphone bekannt. Die Leiste in der Fußzeile, mit der sich zwischen einzelnen Wochen umschalten lässt, ist ein neues Interaktionselement, welches sich weder in der iphone- noch in der Mac-Version wieder findet und somit speziell für die ipad- Version konzipiert wurde. Abbildung 5: ical ipad, Wochenansicht 12

13 1.3 Vorgehensweise Während der Entwicklung von TeaCo ipad sollen die beiden Entwicklungsprozesse User Centered Design (kurz UCD, Norman & Draper, 1986) und Feature Driven Development (kurz FDD, Coad et al., 1999) verwendet werden. Die Verwendung von UCD soll durch frühe und kontinuierliche Benutzerpartizipation eine hohe Gebrauchstauglichkeit garantieren. Der Einsatz von FDD verspricht einen strukturierten Überblick über die Features und bereits zu Beginn der Realisierung ein lauffähiges und somit auch testfähiges Teilsystem. In Abbildung 6 ist dargestellt, wie UCD und FDD zu einem Entwicklungsprozess zusammengeführt werden. Für jedes Feature-Set Entwicklung des Entwurf des Gesamtmodells Feature-Sets Benutzeranalyse Erstellung der Feature List Konstruktion des Feature-Sets Summative Evaluation Planung der einzel- Formative nen Feature-Sets Evaluation Abbildung 6: Entwicklungsprozess (modifiziert nach Roenspieß, 2009), Elemente des UCD sind hell, Elemente des FDD dunkel dargestellt Im ersten Schritt findet die Benutzeranalyse statt. Um die Erfahrungen, Erwartungen und Wünsche der Benutzer zu untersuchen, werden Benutzerinterviews und eine Nutzungsstudie durchgeführt. Auch wenn in der Analyse in Kapitel 2 weitere Bereiche untersucht werden, ist die Be- 13

14 nutzeranalyse erstrangig, um Erkenntnisse für die nachfolgende Konzeption zu sammeln. Dieser Schritt ist Teil des UCD. Der zweite Schritt ist Teil des FDD. Aufbauend auf den Erkenntnissen der Analyse wird die Benutzungsschnittstelle konzipiert. Dabei sollten auch die ios HIG berücksichtigt werden, um eine zufriedenstellende Gebrauchstauglichkeit gewährleisten zu können. Während der Konzeption werden die einzelnen Features des Anwendungssystems festgelegt und in sogenannte Feature Sets eingeteilt. Features Sets sind kleine Gruppen von Features, die während der Implementierung unmittelbar aufeinander folgend implementiert werden, weil sie gemeinsam einen größeren Funktionskomplex darstellen. Die Konzeption ist in Kapitel 3 beschrieben. Der dritte Schritt wird für jedes Feature-Set wenn nötig, mehrmals durchlaufen. Die Realisierung jedes Feature-Sets läuft in drei Phasen ab. Zunächst wird ein Feature-Set im Sinne des FDD entworfen und danach konstruiert. Im Rahmen des UCD wird dieses Feature-Set dann mittels Usability-Tests und Benutzerbefragung formativ evaluiert. Sollten die Ergebnisse zufriedenstellend ausfallen, kann mit dem nächsten Feature-Set fortgefahren werden. Ansonsten werden die drei Phasen Entwurf, Konstruktion und Test erneut durchlaufen. In Kapitel 4 wird die Realisierung beschrieben und in Kapitel 5 die entstandene Applikation anhand von Dialogbeispielen vorgestellt. Abschließend wird eine summative Evaluation des entstandenen Anwendungssystems durchgeführt, um es besonders in Hinblick auf die Gebrauchstauglichkeit zu bewerten. Die summative Evaluation findet sich in Kapitel 6. Die Zusammenfassung der Ergebnisse sowie ein Ausblick ist in Kapitel 7 zu finden. 14

15 2 Analyse Die Anforderungen an TeaCo ipad werden in der Aufgabenanalyse (2.1) und in der Organisationsanalyse (2.3) untersucht. In der Kontextanalyse (2.4) werden die speziellen Interaktionsformen eines Tablets untersucht und mit denen des Smartphones und Desktop-PCs verglichen. Darüber hinaus soll gemäß der Zielsetzung in Unterkapitel 1.1 während der Analyse der Schwerpunkt darauf gelegt werden, welche Interaktionsformen sich für ein Tablet eignen. Der in Unterkapitel 1.3 beschriebene Entwicklungsprozess erfordert eine umfassende Benutzeranalyse, welche in Unterkapitel 2.2 beschrieben wird. Diese Analyse wird am konkreten Beispiel des ipads durchgeführt, um für TeaCo ipad möglichst passende Erkenntnisse zu gewinnen. 2.1 Aufgabenanalyse Nach Lohrenz (2009, S. 15, 16) lassen sich traditionelle Terminfindungsprozesse üblicherweise in sechs Phasen untergliedern (vgl. Abb. 7). Abbildung 7: Traditioneller Terminfindungsprozess (nach Lohrenz, 2009, S. 16) (1) Eine Person, im Folgenden Initiator genannt, stellt für sich selbst fest, in welchen Zeiträumen ein Meeting für sie in Frage kommt. (2) Der Initiator unterbreitet den anderen Teilnehmer diese Terminvorschläge auf beliebige Weise. (3) Jeder Teilnehmer teilt dem Initiator nach einer Bedenkzeit mit, welche Terminvorschläge für ihn in Frage kommen, und unterbreitet unter Umständen neue, eigene Terminvorschläge, sofern für ihn keiner der Terminvorschläge passt. 15

16 (4) Der Initiator teilt den anderen Teilnehmern neu erhaltene Terminvorschläge mit und wartet abermals auf Rückmeldung. (5) Der Initiator begutachtet die gesammelten Informationen über die Teilnehmer und wählt den oder die geeignetsten Terminvorschläge aus. (6) Der Initiator teilt den weiteren Teilnehmern den oder die ausgewählten Termine mit. Während der Analyse und Konzeption von TeaCo Desktop und in Folge dessen auch von TeaCo Mobile und TeaCo iphone hat man sich dazu entschlossen, von diesen dem Benutzer gewohnten Phasen abzuweichen, um den Terminfindungsprozess zu optimieren (Lohrenz, 2009). In den Varianten von TeaCo nimmt das System dem Initiator die Organisation des Terminfindungsprozesses ab. Somit werden Informationen eines Teilnehmers (Zu- oder Absagen, Terminänderungen, Terminvorschläge, Kommentare) den anderen Teilnehmern umgehend zugänglich und müssen nicht mühsam und zeitaufwändig vom Initiator jedem einzelnen Teilnehmer mitgeteilt werden. Weiter hat jeder Teilnehmer die gleichen Rechte, ein Meeting im System zu bearbeiten. Somit können sich alle Teilnehmer gleichermaßen und hierarchielos an der Problemlösung beteiligen. Unter der nahe liegenden Annahme, dass alle Teilnehmer an der Terminfindung interessiert sind und den Terminfindungsprozess nicht sabotieren wollen, wird so die Terminfindung beschleunigt. Da sich dieser modifizierte Terminfindungsprozess in allen TeaCo-Varianten bewähren konnte und sich TeaCo ipad bezüglich des Arbeitsablaufs nicht von den anderen TeaCo-Varianten unterscheiden sollte, bietet sich für TeaCo ipad dieser modifizierte Terminfindungsprozess an. Im Folgenden sollen bereits bestehende Anwendungssysteme auf dem ipad untersucht werden, um gängige Interaktionsformen auf dem ipad ableiten zu können. Dabei soll auch analysiert werden, welche Interaktionsformen von Desktop-PC oder Smartphone auf das ipad übertragen werden können. Zuerst soll das Kalendertool ical von Apple betrachtet werden. Mit der Abbildung 5 wurde die ipad-variante bereits kurz vorgestellt. Nun sollen die Varianten für den Mac und für das iphone 16

17 beschrieben und mit der ipad-variante verglichen werden. Die Abbildung 8 zeigt die Wochenansicht von ical für den Mac. Abbildung 8: ical Mac, Wochenansicht Es ist erkennbar, dass die grobe Anordnung einzelner Elemente auf die ipad-variante übertragen wurde. Den meisten Platz nimmt in beiden Varianten die Darstellung der Termine in Anspruch und in beiden Varianten lässt sich zwischen verschiedenen Darstellungen wechseln. Die Abbildungen 5 und 8 zeigen die Wochenansicht, aber die Abbildungen 9 und 10 zeigt, dass sich auch die weiteren Darstellungen sehr ähneln. Sich zeitlich überlagernde Termine werden in der Ansicht räumlich überlagert dargestellt. Darüber hinaus wurde auch die Detailansicht eines Termins für die ipad-variante übernommen. Die Detailansicht ist mit einem Pop-Up realisiert, welches durch einen Pfeil mit dem zugehörigen Termin assoziiert wird. Neben der Darstellung der Termine sind auch weitere Interaktionselemente sehr ähnlich angeordnet. Die Liste der verschiedenen Kalender des Benutzers befindet sich in der linken oberen Ecke. Allerdings muss aus Platzgründen in der ipad-variante erst ein Button angetippt werden, sodass ein Pop-Up mit der Liste der Kalender erscheint. Einzelne Termine lassen sich jedoch in der ipad-variante nicht via Drag&Drop (Ziehen und Fallenlassen) verschieben, wie es in der Mac-Variante möglich ist. In beiden Vari- 17

18 anten findet sich die Schaltfläche zum Ändern der Termindarstellung zentriert in der Kopfzeile und das Suchformular rechts in der Kopfzeile. Die Varianten unterscheiden sich in der Art und Weise, wie der Benutzer den angezeigten Zeitraum in der Termindarstellung ändern kann. In der Mac-Variante dienen dazu Pfeile, die links und recht neben der Schaltfläche zum Ändern der Termindarstellung platziert sind, und der kleine Kalender in der linken unteren Ecke. In der ipad-variante existiert hingegen eine Zeitleiste in der Fußzeile, um den angezeigten Zeitraum zu verstellen. Dieses Element ist speziell für die ipad-variante konzipiert, denn etwas Vergleichbares ist auch in der iphone-variante nicht zu finden. Die Abbildung 11 zeigt die wesentlichen Darstellungen von ical für das iphone. Die Termine können in der Monatsansicht (Abb. 11a), in der Listenansicht (Abb. 11b), in der Tagesansicht (Abb. 11c) oder in der Detailansicht (Abb. 11d) betrachtet werden. Die iphone-variante kann dem Platzmangel geschuldet keine Termindarstellung präsentieren, die an die Übersichtlichkeit der Varianten für Mac und ipad heranreicht. Die Listendarstellung ist die einzige Darstellung, die die Funktionalität der ipad-variante erweitern würde und wurde deshalb auf die ipad-variante übertragen. Erstaunlicherweise verzichtet die iphone-variante auf Gesten und versteckte Interaktionselemente. So wäre zum Beispiel eine Swipe-To-Delete-Funktion (Wischen zum Löschen) für Termine in der Listenansicht oder eine Wisch-Geste zum Umblättern in der Tagesansicht denkbar. Auch in der ipad-variante wird auf Gesten dieser Art verzichtet. Die ipad-variante von ical ist hinsichtlich der Ausgabe vor allem der Desktop-Variante sehr ähnlich, was sich maßgeblich durch die großen und übersichtlichen Termindarstellungen zeigt. Die Form der Eingabe lässt sich weder vollständig mit der Mac-Variante noch mit der iphone-variante vergleichen. Vermutlich würden Eingabeformen mit Hilfe von Gesten die Gebrauchstauglichkeit sowohl der iphone-variante als auch der ipad-variante verbessern. In den ios HIG finden sich im Kapitel Case Studies: Transitioning to ios Fallstudien, zu weiteren Mac-Anwendungssystemen, die auf das ipad transportiert wurden. Bemerkenswert dabei ist die Empfehlung, Expertenfeatures, die nur von einer kleinen Benutzergruppe benutzt werden, im Zweifelsfall nicht zu implementieren. So kann die Einfachheit und Übersichtlichkeit eines Anwendungssystems auf dem ipad gewahrt werden. Auch über aussagekräftige Shortcuts und Rück- 18

19 (a) ipad (b) Mac Abbildung 9: ical Tagesansicht 19

20 (a) ipad (b) Mac Abbildung 10: ical Monatsansicht 20

21 (a) Monatsansicht (b) Listenansicht (c) Tagesansicht (d) Detailansicht Abbildung 11: ical iphone 21

22 meldungen via Animation kann der begrenzte Platz auf dem Display besser ausgenutzt werden. Durch die Einhaltung von Design-Paradigmen lassen sich Erfahrungen ausnutzen, die Benutzer in anderen Anwendungssysteme auf dem ipad gesammelt haben. Das zweite Anwendungssystem, das analysiert werden soll, ist das kostenlose Aufgabenverwaltungssystem Wunderlist (6 Wunderkinder, 2011). Mit Wunderlist lassen sich Aufgaben erstellen, mit Notizen und Informationen zur Fälligkeit und Priorität versehen sowie in verschiedene Kategorien sortieren. Um Wunderlist nutzen zu können, muss der Benutzer sich mit seiner - Adresse und einem Passwort anmelden. Über den so erstellten Benutzeraccount werden die Aufgaben zwischen den verschiedenen unterstützten Geräten synchronisiert. Im Folgenden sollen die Varianten für iphone, ipad und Mac betrachtet werden. Wunderlist existiert darüber hinaus auch für Windows und Android. In Abbildung 12 ist die ipad-variante von Wunderlist zu sehen, welche folgend zunächst mit der Mac-, dann mit der iphone-variante verglichen werden soll. Abbildung 12: Wunderlist ipad, Querformat 22

23 Abbildung 13 zeigt Wunderlist auf dem Mac. Sowohl die Mac- als auch die ipad-variante kommen im Wesentlichen mit einer einzigen zweigeteilten Ansicht aus. Auf der einen Seite des Anwendungsfensters ist eine Auflistung der einzelnen Aufgabenkategorien zu sehen. Obwohl diese Liste in der Mac-Variante vom Benutzer nach Belieben links oder rechts angezeigt werden kann, hat man diese in der ipad-variante fest links platziert. Der Grund dafür könnte sein, dass man eine Listendarstellung auf dem ipad auf der linken Seite von anderen Anwendungssystemen gewohnt ist, was nicht zuletzt daran liegt, dass Apple im ios SDK speziell für zweigeteilte Displays ein Oberflächenelement, den Split-View-Controller (Apple Inc., 2011g), bereitstellt (vgl. Abb. 12 und 16). Dieser Split-View-Controller sieht den schmaleren Teil wie zum Beispiel eine Liste auf der linken Seite vor. Die Auflistung der Kategorien ist in den Varianten für Mac und ipad sehr ähnlich. Die Mac-Variante benutzt zur Beschreibung von Interaktionselementen teilweise Text, während die ipad-variante gänzlich darauf verzichtet. Dies macht sich beispielsweise an der Schaltflächen bemerkbar, mit denen der Benutzer die Aufgaben anzeigen lassen kann, die Heute oder Morgen fällig sind. In der Mac-Variante sind diese Schaltflächen beschriftet (Abb. 13, unten links), in der ipad-variante dienen Icons zur Beschreibung (Abb. 12, unten links). Auch der Indikator für überfällige Aufgaben ist in der Mac-Variante ein recht großer, beschrifteter Button, während dieser Indikator in der ipad-variante eine kleine, rot hinterlegte Zahl ist. Der andere Teil des Anwendungsfensters der Varianten für Mac und ipad ist die Anzeige der Aufgaben. Die Anordnung der Elemente ist in beiden Varianten fast identisch. In der Mac-Variante werden erledigte Aufgaben weiterhin dargestellt, während diese in der ipad-variante ausgeblendet werden. Auch die Elemente, die eine Aufgabe repräsentieren, sind in beiden Varianten nahezu gleich konzipiert worden. Es lässt sich festhalten, dass die Varianten für ipad und Mac bis auf die Position der Kategorienliste und kleine Unterschiede im Detail eine identische Darstellung haben. Für die iphone-variante wurden Kategorienliste (Abb. 14a) und Aufgabenliste (Abb. 14b) aus Platzmangel auf zwei Ansichten verteilt, die nicht gleichzeitig sichtbar sind. Zwar ähnelt die iphone- Variante den anderen Varianten hinsichtlich Farbgebung und einzelner Designelemente. Dennoch unterscheidet sich die iphone-variante in Aufbau und Anordnung von den Varianten für 23

24 Abbildung 13: Wunderlist Mac Mac und ipad. Gemeinsamkeiten von ipad- und iphone-variante lassen sich vor allem in den Eingabeformen finden. Die wohl häufigste Interaktion ist das Manipulieren einer Aufgabe. Dabei kann ein Eintrag, der eine Aufgabe repräsentiert, drei Zustände annehmen (Abb. 15). Im normalen Zustand (Abb. 15a) kann die Aufgabe durch Tippen auf das Kästchen am linken Rand als erledigt oder durch Tippen auf den Stern als wichtig markiert werden. Durch Wischen über den Eintrag erscheint ein Löschen-Button auf der rechten Seite des Eintrags (Abb. 15b, Swipe-To-Delete). Durch Tippen auf diesen Button wird das Meeting gelöscht. Der dritte mögliche Zustand ist der Editier-Modus (Abb. 15c). In diesem Zustand erscheint auf der linken Seite ein roter Button, durch dessen Tippen der selbe Löschen-Button wie im Swipe-To-Delete-Zustand sichtbar wird. Darüber hinaus lassen sich die einzelnen Einträge im Editier-Modus via Drag&Drop vertikal anordnen und somit sortieren. Zum Drag&Drop muss der Benutzer den Tabelleneintrag an den drei vertikalen Balken auf der rechten Seite des Eintrags anfassen. Durch Tippen auf eine Schaltfläche in der 24

25 (a) Listenübersicht (b) Listenansicht Abbildung 14: Wunderlist iphone rechten oberen Ecke des Displays gelangt man in den Editier-Modus. Diese drei Zustände und einige andere Interaktionsformen wurden von der iphone- auf die ipad-variante übertragen. Die ipad-variante von Wunderlist reagiert auch auf einen Orientierungswechsel des ipads. Hält der Benutzer das ipad hochkant, so wird eine andere Darstellung präsentiert, als würde es es waagerecht halten. In Abbildung 16 ist diese Darstellung im Hochformat zu sehen. In diesem Fall ähnelt die Darstellung eher der iphone-variante. Im Normalzustand (Abb. 16a) ist die Liste der Kategorien nicht zu sehen. Durch ein Tippen auf den Button in der linken oberen Ecke erscheint diese Liste als Pop-Up (Abb. 16b). Diese Funktionalität wird durch den Split-View-Controller geliefert. Die Analyse von Wunderlist bekräftigt die Tendenzen, die sich bereits nach der Analyse von ical zeigten. Die Ausgabeformen des ipads ähneln in den meisten Fällen denen eines Macs. Dies lässt sich auf die Ähnlichkeit der Ausgabegeräte zurückführen. Wird das ipad allerdings speziell im 25

26 (a) Normaler Zustand (b) Zustand nach Swipe-To-Delete (c) Zustand im Editier-Modus Abbildung 15: Wunderlist, Zustände eines Tabelleneintrags Hochformat betrachtet, so wird es schwieriger, die Darstellung der Mac-Anwendungssysteme auf das ipad zu übertragen. Im Hochformat erinnert das ipad eher an ein großes iphone, weshalb sich in diesem Fall auch die Darstellungen ähneln. Die Eingabeformen des ipads erinnern oft an die des iphones. Da beide Geräte nur begrenzten Platz auf dem Display zur Verfügung haben, sollten Anwendungssysteme mit versteckten Interaktionselementen und Gesten Platz sparen. Die folgende Benutzeranalyse soll zeigen, ob die Erwartungen und Wünsche der Benutzer diese Ergebnisse bestätigen können. 2.2 Benutzeranalyse Ein elementarer Bestandteil des UCD und somit des in Kapitel 1.3 beschriebenen Entwicklungsprozesses ist die Benutzeranalyse. In diesem Kapitel sollen zuerst die Zielgruppen identifiziert und charakterisiert werden, um auf dieser Grundlage TeaCo ipad für die relevanten Nutzer möglichst gebrauchstauglich zu entwickeln. Außerdem sollen Benutzerinterviews durchgeführt werden, um die Erwartungen, Anforderungen und Wünsche der Benutzer zu analysieren. 26

27 (a) Kategorienliste versteckt (b) Kategorienliste sichtbar Abbildung 16: Wunderlist ipad, Hochformat Zielgruppen Die Benutzer von TeaCo lassen sich in zwei Gruppen aufteilen. Unerfahrene Benutzer, die TeaCo kaum oder gar nicht kennen, werden im Folgenden als Novizen bezeichnet. Erfahrene Benutzer werden als Experten bezeichnet. Die Erwartungen und Ziele, die diese beiden Benutzergruppen mit dem Anwendungssystem verbinden, können sich oftmals grundsätzlich unterscheiden. Das Anwendungssystem muss deshalb so konzipiert werden, dass es sowohl den Novizen als auch den Experten gerecht wird. Im Folgenden werden die beiden Benutzergruppen näher betrachtet, wobei davon ausgegangen wird, dass alle Benutzer bereits mit dem ipad und dessen gängigen Interaktionsformen vertraut sind. Wenn ein Novize zum ersten Mal mit TeaCo in Berührung kommt, geschieht dies vorwiegend in einem von zwei denkbaren Szenarien. Im ersten Szenario bekommt der Benutzer von einer ihm bekannten Person eine mit einem Link zu einem Meeting im TeaCo-System und der Bitte, sich an der Terminfindung zu beteiligen. Der Novize kommt infolge dessen über den Link 27

28 zu TeaCo und somit entweder zu TeaCo Desktop, falls er den Link auf einem Desktop-PC öffnet, oder zu TeaCo Mobile, falls er den Link auf einem Smartphone öffnet. In diesem ersten Szenario ist es also ausgeschlossen, dass der erste Kontakt über TeaCo ipad erfolgt. Dies liegt nicht zuletzt daran, dass der Novize noch nicht über ein Passwort verfügt, welches zum Einloggen bei TeaCo iphone nötig ist und somit höchstwahrscheinlich auch bei TeaCo ipad nötig sein wird. Im zweiten Szenario hat der Novize auf anderem Wege von TeaCo erfahren und möchte sich das Anwendungssystem mit oder ohne konkretem Bedürfnis ein Meeting zu planen anschauen. Dabei ist es durchaus möglich, dass der erste Kontakt über TeaCo ipad abläuft. Deshalb ist die Selbstbeschreibungsfähigkeit und Fehlertoleranz (nach DIN EN ISO , siehe auch Herczeg, 2009, S , ) von TeaCo ipad für Novizen besonders wichtig. Weiter sollte TeaCo ipad dem Novizen die Grundfunktion von TeaCo die schnelle und einfache Terminfindung in Gruppen vermitteln. Die Benutzergruppe der Experten muss zur exakten Betrachtung nochmals in zwei Untergruppen geteilt werden. Auf der einen Seite stehen Benutzer, die zwar schon viele Erfahrungen mit TeaCo gesammelt haben, denen allerdings TeaCo ipad noch unbekannt ist. Für diese Benutzer ist es sehr wichtig, dass sie ihr Wissen über die anderen TeaCo-Varianten auf TeaCo ipad anwenden können. Auf der anderen Seite stehen die Benutzer, denen sowohl TeaCo als System als auch TeaCo ipad gut bekannt sind. Diese Benutzer werden besonderen Wert auf die Effizienz (nach DIN EN ISO , 1998) des Anwendungssystems legen. Um die Effizienz des Anwendungssystem für Experten zu steigern, können dem Benutzer alternative, effizientere Interaktionsmöglichkeiten angeboten werden, die unter Umständen nicht selbsterklärend und offensichtlich sind. In diesem Zusammenhang kommen versteckte Interaktionselemente, Multi-Touch-Gesten oder der Beschleunigungs-Sensor des ipads in Frage Benutzerinterviews Um die Erwartungen und Wünsche der Benutzer zu analysieren und Anregungen hinsichtlich der Interaktionsformen zu sammeln, wurde eine Reihe von semistrukturierten Benutzerinterviews durchgeführt. Da es zum Zeitpunkt der Analyse kein Anwendungssystem für das ipad gab, 28

29 dem TeaCo ipad ähnlich sein wird, wurde dabei auf einen praktischen Teil, in dem der Benutzer während der Interaktion beobachtet und danach zu dieser befragt wird, verzichtet. Stattdessen sollte eine Gespräch stattfinden, in der sich die Befragten selbst Gedanken über das Konzept der Benutzungsschnittstelle machen und so wesentlich in den Entwicklungsprozess einbezogen werden. Sollte TeaCo dem Befragten noch nicht bekannt sein, so findet eine grundlegende Einführung in TeaCo Desktop und TeaCo iphone statt, sodass der Befragte qualifiziertere Antworten geben kann. Im folgenden Absatz wird die Struktur der Interviews beschrieben. Die Interviews wurden mit jedem Befragten einzeln und in ruhiger, gewohnter Umgebung durchgeführt, um äußere Einflüsse und Störungen zu vermeiden und eine entspannte Atmosphäre zu schaffen. Alle Befragten waren erfahren im Umgang mit dem ipad oder in einem Fall zumindest mit ios. Das Interview fand mit besonderem Augenmerk auf die Darstellung der Terminvorschläge eines Meetings statt. Mit den Befragten wurden dafür verschiedene Lösungsmöglichkeiten diskutiert. Auch weitere zentrale Fragen bezüglich der Benutzungsschnittstelle wurden mit den Befragten besprochen. Darüber hinaus sollten die Befragten die Wichtigkeit der Informationen zu Meetings und Terminvorschlägen auf einer Skala einstufen. Der Interviewleitfaden findet sich in Anhang A. Insgesamt wurden sechs Benutzerinterviews durchgeführt. Im Folgenden sollen nun die Erkenntnisse, die aus den Benutzerinterviews gewonnen wurden, dargestellt werden. Eine Auflistung der gewonnenen Rohdaten ist in Anhang B zu finden. Meetingübersicht In ausnahmslos allen TeaCo-Varianten werden die Meetings eines Benutzers als Liste dargestellt und nach Aktualität sortiert. Diese Darstellungen unterscheiden sich jedoch hinsichtlich der Gruppierung einzelner Meetings. In TeaCo Desktop findet keine Gruppierung der Meetings statt, wohingegen TeaCo Mobile die Meetings in die drei Gruppen Noch nicht abgestimmt, Bereits abgestimmt und Eigene Meetings unterteilt. TeaCo iphone teilt die Meetings lediglich in die zwei Gruppen Noch nicht abgestimmt und Bereits abgestimmt, wobei eigene Meetings mit einem entsprechenden Icon versehen werden. Die Befragten haben sich einstimmig für eine zweigeteilte Gruppierung wie in TeaCo iphone entschieden. Die 29

30 Sortierung nach Aktualität haben alle Befragten als sinnvoll erachtet. Einige Befragte haben darüber hinaus den Wunsch geäußert, wahlweise alphabetisch sortieren zu können oder die eigenen Meetings zuoberst anzeigen zu können. Meetingansicht Die Gestaltung der Meetingansicht und insbesondere die Darstellung der Terminvorschläge eines Meetings war eine zentrale Fragestellung des Benutzerinterviews. Den Befragten wurden sieben (später acht, siehe unten) verschiedene Möglichkeiten vorgestellt, wie die Terminvorschläge dargestellt werden könnten und diese dann mit dem Befragten diskutiert. Diese Möglichkeiten waren teils den Varianten TeaCo Desktop oder TeaCo iphone entlehnt, teils eigens für das ipad erdacht. Die prozentuale Befürwortung der einzelnen Ansichten ist in Abbildung 17 zu sehen. Die Interviews haben ergeben, dass je nach Zusammensetzung der Terminvorschläge (überdeckter Zeitraum, Regelmäßigkeit) und Anwendungsfall unterschiedliche Darstellungen als gebrauchstauglich bewertet werden. Zum schnellen Abstimmen ist eine Auflistung der Terminvorschläge (Quick-Vote-List) wie in TeaCo iphone und TeaCo Mobile sinnvoll. Um einen Überblick über die Terminvorschläge zu gewinnen, können je nach Verteilung der Terminvorschläge eine Tages-, Wochenoder Monatsansicht sinnvoll sein. Dabei wurde immer wieder betont, dass diese drei Ansichten erst in Kombination wirklich sinnvoll sind, da eine der Ansichten allein nicht allen Meetings gerecht werden kann. Die von TeaCo Desktop gewohnte Ansicht eines selbstskalierenden Grids bietet eine Kombination aus Übersichtlichkeit und der Möglichkeit schnell abzustimmen. Bereits im ersten Interview schlug der Befragte vor, die Quick-Vote-List mit anderen Ansichten zu kombinieren, um die Vorzüge der Quick-Vote-List und die Vorzüge der übersichtlicheren Anzeigen zu vereinen. Im Querformat würde dann im Sinne des Split-View- Controllers auf der linken Seite die Quick-Vote-List zu sehen sein, während auf der rechten Seite eine der Ansichten Tages-, Wochen-, Monatsansicht oder das selbstskalierende Grid dargestellt wird. Nach eine Orientierungswechsel des ipad ins Hochformat würde die Quick-Vote-List verborgen werden und über einen Button erreichbar sein. Dieser Vorschlag stieß bei den weiteren Befragten auf Zustimmung. Eine alleinstehende Quick-Vote- 30

31 List oder Kombinationen von Quick-Vote-List und weiteren Details zu einem Meeting wurden von den Befragten nicht befürwortet. Das lag vor allem daran, dass diese Ansichten den Platz auf dem Display nicht optimal auszunutzen scheinen. 100% 83% 83% 100% 100% 83 % 50% 33% 33% 17% 0% Quick-Vote-List Liste + Details Liste + Details + Kommentare Selbstskalierendes Grid Tagesansicht Wochenansicht Monatsansicht Split-View-Ansicht Abbildung 17: Benutzerinterview, Gestalt der Meetingansicht Priorität der Informationen Ein Teil des Benutzerinterviews befasste sich damit herauszufinden, wie wichtig den Benutzern einzelne Informationen zu einem Meeting respektive zu einem Terminvorschlag sind. Dazu sollten die Befragten die einzelnen Informationen in eine Skala von 0 (weniger wichtig) über 1 (wichtig) bis 2 (sehr wichtig) einordnen. Als Hilfestellung sollten sich die Befragten vor Augen halten, dass wichtige Interaktionselemente mit weniger Interaktion sichtbar werden als unwichtige. Diese Erhebung soll dabei helfen, die einzelnen Interaktionselementen auf dem Display gemäß ihrer Wichtigkeit zu platzieren. Folgend sind die Durchschnittswerte anhand von Balkendiagrammen in den Abbildungen 18 und 19 visualisiert. 31

32 Abstimmungsstatus Ausgewählte Termine Initiator Klonen Kommentare Letzte Änderung Löschen Rechtevergabe Teilnehmer Titel Titel ändern Abbildung 18: Benutzerinterview, Prioritäten der Meeting-Interaktionen Für ein Meeting (Abb. 18) wurden von den Benutzern die Interaktionen zu Meetingtitel und Abstimmungsstatus durchweg als sehr wichtig erachtet. Auch die Anzeige für ausgewählte Termine, Kommentare, Löschen und Teilnehmer wurde zwischen wichtig und sehr wichtig eingestuft, während Klonen, Rechtevergabe und Titel ändern kaum Bedeutung beigemessen wurde. Die Interaktionen zu einem Terminvorschlag (Abb. 19) lassen sich in zwei Kategorien einteilen. Löschen und Zeitpunkt ändern werden zwischen wichtig und weniger wichtig eingestuft. Diese beiden Interaktionen müssen demnach nicht sofort erreichbar sein, sondern können zum Beispiel als versteckte Interaktionselemente implementiert werden. Alle anderen Interaktionen werden als sehr wichtig eingestuft. Diese Interaktionselemente sollte dem Benutzer also sofort zugänglich sein. Auditive Rückmeldung von Interaktion Die auditive Rückmeldung von Interaktion stieß bei den meisten Befragten auf Zustimmung. Keiner der Befragten hat angegebenen, dass er sich durch Signaltöne gestört fühlen würde. Für die auditive Rückmeldung sollten vor allem durch das ios bereits bekannte Si- 32

33 Abstimmen Abstimmungsergebnis Als endgültig markieren Eigene Stimme Löschen Zeitpunkt Zeitpunkt ändern Abbildung 19: Benutzerinterview, Prioritäten der Terminvorschlag-Interaktionen gnaltöne verwendet werden, da diese Töne besser vom Benutzer interpretiert werden können. Push-Notification Die Interviews haben ergeben, dass sich die Benutzer Push-Notifications in drei Fällen wünschen. Sobald alle Teilnehmer über die Terminvorschläge abgestimmt haben, sobald ein oder mehrere Terminvorschläge als endgültig markiert wurden und sobald der Benutzer zu einem Meeting eingeladen wird, sollte auf dem ipad eine Push-Notification erscheinen. Drag&Drop Ausnahmslos alle Befragten wünschen sich die Möglichkeit, Terminvorschläge via Drag&Drop verschieben zu können. Zum einen soll es möglich sein, in einen sogenannten Edit-Modus zu wechseln, in dem der Benutzer alle Terminvorschläge nach Belieben verschieben kann. Zum anderen sollen einzelne Terminvorschläge durch langes Halten beweglich werden. Eigener Kalender sichtbar Ein Befragter hat den Wunsch geäußert, die eigenen Termine unter die Darstellung von 33

34 Terminvorschlägen zu legen. So müsste man nicht zwischen TeaCo ipad und ical wechseln, um zu sehen, zu welchem Termin man Zeit hat. Diese Idee fand bei weiteren Befragten Zuspruch, obgleich einige Befragte sich wünschten, das Feature deaktivieren zu können. Termine reservieren Des Weiteren wurde der Vorschlag gemacht, dass der Benutzer für Terminvorschläge, zu denen er zugesagt hat, den entsprechenden Termin in ical als reserviert markieren kann. Sobald dann Terminvorschläge als endgültig markiert wurden, können die übrigen Reservierungen aufgehoben werden. So wird vermieden, dass der Benutzer zum Zeitpunkt eines zugesagten Terminvorschlags einen anderen Termin macht. Die Benutzerinterviews zeigten, dass die Befragten von TeaCo ipad deutlich mehr Interaktionsmöglichkeiten wünschen, als bei TeaCo iphone vorhanden sind. Das größere Display macht übersichtlichere Darstellungen der Terminvorschläge und gebrauchstauglichere Interaktionen möglich. Darüber hinaus erwarten die Benutzer von TeaCo iphone bekannte Funktionen wie Push- Notifications und die Quick-Vote-List auch auf dem ipad. 2.3 Organisationsanalyse Auch wenn TeaCo momentan hauptsächlich innerhalb der Universität genutzt wird, ist es dennoch auch für allen anderen Bereiche des Alltags konzipiert. Deshalb lässt sich keine allgemein gültige Aussage über die Beschaffenheit einer Gruppe, die TeaCo benutzt, treffen. Vielmehr ist es der Anspruch von TeaCo besonders heterogene Gruppen zu unterstützen. Innerhalb der Gruppe können Benutzer mit verschiedenen Browsern, Geräteklassen, Kalendertools und Sprachen vertreten sein, ohne dass es den Terminfindungsprozess behindert. Es ist davon auszugehen, dass sich die Mitglieder der zu unterstützenden Gruppen konstruktiv und nicht sabotierend am Terminfindungsprozess beteiligen und deshalb ein Terminfindungsprozess in den meisten Fällen ohne eine Hierarchie auskommt. Der Terminfindungsprozess kann deutlich schneller abgeschlossen werden, wenn sich alle Teilnehmer aktiv daran beteiligen können, indem sie zum Beispiel ihrerseits Terminvorschläge machen oder passende Terminvorschläge als endgültig festlegen. TeaCo räumt deshalb allen Teilnehmern die gleichen Rechte ein und 34

35 bietet für Gruppen, in denen von der Regel abweichend eine Hierarchie nötig ist, die Funktion des eingeschränkten Meetings (vgl. Unterkapitel 2.5, UC10). 2.4 Kontextanalyse In der Kontextanalyse soll zunächst geklärt werden, in welchem Umfeld der Benutzer das Anwendungssystem benutzen wird Räumlich-Zeitlicher-Kontext Das ipad wird sowohl in der ersten als auch in der zweiten Generation in zwei Varianten angeboten. Zum einen werden ipads verkauft, die sich ausschließlich über Wireless Local Area Network (WLAN) mit dem Internet verbinden können. Zum anderen werden ipads verkauft, die neben einer WLAN-Internetverbindung auch über 3G-Mobilfunknetze Internetverbindungen herstellen können. Außerdem ist es mit der Veröffentlichung von ios 5 möglich, ein ipad zu benutzen, ohne im Besitz eines Desktop-PCs zu sein, weshalb das ipad nicht mehr ausschließlich zusätzliches Gerät neben einem Desktop-PC zu sehen ist. Aus diesen technischen Voraussetzungen lässt sich ableiten, dass sich der räumlich-zeitliche Nutzungskontext für das ipad letztendlich nicht sinnvoll einschränken lässt ist. Das ipad kann zu Hause ersatzweise oder ergänzend zu einem Desktop-PC oder unterwegs ersatzweise oder ergänzend zu einem Laptop oder Smartphone genutzt werden. Auch der Einsatz am Arbeitsplatz ist denkbar. Infolge dieser Vielfalt an Benutzungskontexten lässt sich keine allgemein gültige Aussage über Geräuschpegel und Lichtverhältnisse während der Interaktion mit dem Anwendungssystem treffen. Vielmehr müssen alle denkbaren Rahmenbedingungen berücksichtigt werden Technischer Kontext Im Folgenden werden die einzelnen Möglichkeiten zur Interaktion mit dem ipad aufgezählt und analysiert. Zur Eingabe auf dem ipad stehen dem Benutzer folgende Technologien zur Verfügung. 35

36 Multi-Touch-Display Das ipad verfügt über ein 9,7-Zoll-großes Multi-Touch-Display, welches mit den Fingern bedient wird. Da das ipad sehr spärlich mit Eingabearmaturen (nach Herczeg, 2006, S ) ausgestattet ist, findet der Großteil der Eingaben über dieses Multi-Touch-Display statt. Der Entwickler kann somit selbst über Anzahl, Art, Position und Größe von Interaktionselementen bestimmen und bekommt diese nicht fest vom Gerät vorgegeben. Für die Texteingabe wird auf dem Display eine Tastatur eingeblendet. So kann der Platz, den die Tastatur einnimmt, anderweitig genutzt werden, wenn diese nicht benötigt wird. Außerdem kann die Tastatur der jeweiligen Sprache und Situation angepasst werden. Durch die Multi-Touch-Fähigkeit kann das ipad eine große Anzahl von Gesten wie zum Beispiel das Wischen oder Tippen mit zwei Fingern und weitere erkennen. Solche Gesten können vom Anwendungssystem zur Interaktion genutzt werden, ohne dass Platz auf dem Display beansprucht wird. Eingabearmaturen Die wenigen Eingabearmaturen des ipads haben eine vom Betriebssystem fest vorgegeben Funktion und können deshalb nur sehr bedingt von Anwendungssystemen ausgenutzt werden. Unterhalb des Displays (ipad in aufrechter Position) befindet sich die sogenannte Hometaste. Mit einem einfachen Klick gelangt man zum Home-Screen des ipads (ähnlich dem Desktop eines Desktop-PCs). Mit einem zweifachen Klick bekommt man Zugriff auf die Multi-Tasking-Funktion des ipads. An der oberen Seite des ipads befindet sich der Ein/Aus-Schalter, mit dem man das ipad aus dem Standby-Modus ruft oder es in den Standby-Modus schickt. Hält man den Ein/Aus-Schalter länger gedrückt, kann man das ipad gänzlich ausschalten. An der rechten Seite befindet sich der Lautstärkeregler und darüber ein Kippschalter, der wahlweise zum Stummschalten dient oder dazu, die automatische Ausrichtung des Displays zu unterbinden. Beschleunigungssensor Das ipad verfügt über einen Beschleunigungssensor. Über diesen können die momentane Ausrichtung des ipads sowie Bewegungen festgestellt werden. Deshalb kann das ipad selbst als Eingabegerät dienen, indem man es kippt, es hin und her wackelt oder weniger abstrak- 36

37 te Bewegungen wie zum Beispiel eine Lenkbewegung in einem Autorennen-Spiel macht. Diese Form der Eingabe beansprucht genau wie Gesten keinen Platz auf dem Display und kann deshalb als gute Alternative dienen. Mikrofon Das Mikrofon des ipads befindet sich an der linken oberen Seite. Mit Hilfe des Mikrofon können Spracheingaben zur Steuerung eines Anwendungssystems gemacht werden. Wie komfortable eine solche Steuerung sein kann, muss für jedes Anwendungssystem separat analysiert werden. Umgebungslichtsensor Der Umgebungslichtsensor dient dazu, die Bildschirmbeleuchtung den aktuellen Lichtverhältnissen anzupassen und kann von Anwendungssystemen nicht genutzt werden. Der Umgebungslichtsensor wird zur Vollständigkeit mit aufgeführt. Kameras (nur ipad 2) Das ipad 2 verfügt über zwei Kameras. An der Front ist eine Kamera mit einer Auflösung von Pixeln. Diese kann zum Beispiel zur Videotelefonie genutzt werden. Denkbare wäre auch eine Eingabeform mittels Eye-Tracking. Auf der Rückseite des ipads befindet sich eine Kamera mit einer Auflösung von Pixeln. Diese dient hauptsächlich zur Eingabe von Bildmaterial (Bilder oder Filme) und kann darüber hinaus kaum als Eingabeform von Anwendungssystemen genutzt werden. Die Ausgabe auf dem ipad erfolgt auditiv oder visuell. Seit der Veröffentlichung von ios 4 ist es via AirPrint (Apple Inc., 2011a) möglich, Druckaufträge drahtlos an unterstützte Drucker zu senden. Nachfolgend sind die Ausgabeformen einzeln analysiert. Display Das Display des ipads hat eine Auflösung von Pixeln im Hochformat und dementsprechend Pixeln im Querformat bei einer Pixeldichte von 132 dpi. Das Display ist somit größer als das eines Smartphones und ausreichend groß, um die meisten Internetseiten, die für Desktop-PCs optimiert sind, auch auf dem ipad hinreichend gut darzustellen. 37

38 Audiowiedergabe Das ipad verfügt an der rechten unteren Seite über einen Lautsprecher. Zwar lässt sich mit diesem keine hochwertige Klangqualität erreichen, aber der Lautsprecher genügt, um in einem kleinen, ruhigen Raum Musik abzuspielen, und vor allem um einfache Signaltöne zur Rückmeldung von Handlungen oder zum Lenken der Aufmerksamkeit, genannt Earcons (Brewster et al., 1993), wiederzugeben. Des Weiteren wird die Audiowiedergabe vom ios benutzt, um Bedienungshilfen für Sehbehinderte bereitzustellen. Sind diese Bedienungshilfen aktiviert, kann der Benutzer sich einzelne Objekte auf dem Bildschirm vorlesen lassen, indem er auf ein Objekt tippt. AirPrint Die Druckfunktion des ipad ist in vielen Anwendungssystemen, die Apple direkt mit dem ios auf dem ipad vorinstalliert, gegeben. Andere Anwendungssysteme müssen diese Funktion selbst implementieren. Deshalb kann die Druckfunktion sehr individuell an ein Anwendungssystem angepasst werden. Die Handhabung von AirPrint durch den Benutzer ist sehr einfach. Das ipad bietet automatisch eine Liste der AirPrint-fähigen Drucker in der Umgebung an, aus welcher der Benutzer den gewünschten Drucker wählen kann. Aus dieser Analyse der Interaktionsmöglichkeiten lässt sich entnehmen, dass für die Eingaben am ipad eher die Eingabeformen von Smartphones in Frage kommen. Besonders das Multi-Touch Display mit Gesten und situationsabhängiger Tastatur, der Bewegungssensor und die wenigen Eingabearmaturen sind vom Smartphone bekannt. Die Ausgabe hingegen lässt mit einem vergleichsweise großen Display eher an einen Desktop-PC erinnern. 2.5 Use Cases Use Cases nach Jacobson et al. (1992) sind Anwendungsfälle, in denen der Benutzer mit dem Anwendungssystem in Interaktion tritt. Für TeaCo iphone hat Schröder die Use Cases, die Lohrenz und Roenspieß für TeaCo Desktop und TeaCo Mobile formulierten, mit wenigen Anpassungen übernommen. Da der Funktionsumfang von TeaCo ipad im wesentlichen derselbe wie der Funk- 38

39 tionsumfang der anderen TeaCo-Varianten sein soll, können die Use Cases von TeaCo iphone (Schröder, 2010) für TeaCo ipad mit einigen Änderungen übernommen werden. UC1 Navigation innerhalb der Meetingübersicht und -ansicht Der Benutzer bekommt eine Übersicht über seine Meetings (Meetingübersicht) angezeigt und kann aus dieser Auflistung zu jedem seiner Meetings in die Meetingansicht navigieren. Innerhalb der Meetingansicht werden alle zugehörigen Terminvorschläge und weitere Informationen zu dem betreffenden Meeting angezeigt. UC2 Abstimmung über einen Terminvorschlag Der Benutzer kann in der Meetingansicht möglichst schnell und einfach über Terminvorschläge abstimmen respektive seine Stimme zu Terminvorschlägen ändern. Das Anwendungssystem weist den Benutzer auf Terminvorschläge hin, über die der Benutzer noch nicht abgestimmt hat. UC3 Erzeugen eines neuen Terminvorschlags Der Benutzer kann neue Terminvorschläge zu einem Meeting erzeugen. Da der Benutzer die Zeit des Terminvorschlags selbst gewählt hat, ist davon auszugehen, dass er diesen Termin wahrnehmen kann. Deshalb stimmt das Anwendungssystem automatisch mit Ja für den Benutzer ab. UC4 Manipulation eines Terminvorschlags Der Benutzer kann eigene und mit entsprechender Berechtigung (UC10) auch fremde Terminvorschläge eines Meetings in Datum, Uhrzeit und Dauer manipulieren. UC5 Zurücksetzen der Abstimmung Das Anwendungssystem setzt manipulierte Terminvorschläge (UC4) automatisch zurück, damit die Teilnehmer neu für diesen Terminvorschlag abstimmen können. UC6 Löschen eines Terminvorschlags Der Benutzer kann eigene und mit entsprechender Berechtigung (UC10) auch fremde Terminvorschläge eines Meetings löschen. 39

40 UC7 Auswahl endgültiger Termine Der Benutzer kann einen oder mehrere Terminvorschläge eines Meetings als endgültig auswählen. Ja nach Rechtevergabe (UC10) kann dies nur der Initiator eines Meetings oder jeder beliebige Teilnehmer. UC8 Benachrichtigung über endgültige Termine Der Benutzer kann mit Hilfe des Anwendungssystem alle Teilnehmer eines Meetings über endgültige Termine (UC7) informieren. Alle Teilnehmer erhalten die Benachrichtigung via oder optional via Apple Push Notification Service (kurz APNs, Apple Inc., 2011b), sofern sie über TeaCo iphone oder TeaCo ipad verfügen. UC9 Erzeugen eines neuen Meetings Der Benutzer kann eine neues Meeting erstellen. Hierzu wählt der Benutzer einen Meetingtitel und legt fest, ob es sich um ein eingeschränktes Meeting handelt (UC10). UC10 Festlegung der Rechte eines neuen Meetings Beim Erzeugen eines neuen Meetings legt der Benutzer fest, ob es sich um ein eingeschränktes Meeting handelt. In einem eingeschränkten Meeting können Teilnehmer nur Abstimmen, Terminvorschläge erzeugen und Kommentare schreiben. Das Manipulieren, Ausladen von Teilnehmern und endgültige Auswählen von Terminvorschlägen bleibt dem Initiator vorbehalten. UC11 Einladen von Teilnehmern Jeder Teilnehmer kann weitere Personen zu einem Meeting einladen, indem er deren E- Mail-Adresse angibt. Die Eingeladenen werden via oder optional via APNs informiert. UC12 Eingabe bekannter Teilnehmer Das Anwendungssystem speichert die Teilnehmer, die ein Benutzer schon einmal zu einem Meeting eingeladen hat. Der Benutzer hat nun die Möglichkeit, diese Teilnehmer aus einer Liste einfach und schnell zu einem Meeting einzuladen. Außerdem kann der Benutzer Kontakte aus seinem ipad-adressbuch importieren. 40

41 UC13 Eingeladene Teilnehmer in ein neues Meeting übernehmen Der Benutzer kann ein Meeting erstellen, das alle Teilnehmer eines anderen, existieren Meeting beinhaltet. UC14 Ausladen von Teilnehmern Der Benutzer kann unter Berücksichtigung der Rechtevergabe (UC10) Teilnehmer aus einem Meeting ausladen. UC15 Verlassen bzw. Löschen eines Meetings Der Benutzer kann ein Meeting verlassen, sofern er nicht der Initiator ist. Der Initiator eines Meetings kann ein Meeting löschen. UC16 Verfassen, Bearbeiten und Löschen von Kommentaren Der Benutzer kann einen Kommentar zu einem Meeting verfassen, diesen bearbeiten oder löschen. Der Initiator eines Meetings kann darüber hinaus fremde Kommentare löschen. UC17 Individualisierung des Anwendungssystems Der Benutzer hat die folgenden Möglichkeiten, das Anwendungssystem nach eigenen Wünschen anzupassen: Angabe eines Namens Angabe eines Passworts Änderung der aktuellen und Hinzufügen weiterer -Adressen Angabe einer persönlichen Free-Busy-List Einstellung der Systemsprache UC18 An- und Abmeldung Der Benutzer kann sich mit seiner -Adresse und seinem Passwort am Anwendungssystem anmelden. Außerdem kann er sich vom Anwendungssystem abmelden. UC19 Registrierung Der Benutzer kann sich mit einer -Adresse und einem Passwort registrieren. Dabei kann er eine Sprache wählen und optional einen Namen angeben. 41

42 UC20 Hilfesystem Das Anwendungssystem stellt dem Benutzer zu jeder Zeit in Abhängigkeit vom Systemzustand eine Hilfe mit Erläuterungen zur Bedienung des Anwendungssystems bereit. Außerdem kann der Benutzter vor der ersten Benutzung ein einführendes Tutorium aufrufen. UC21 Termine reservieren Der Benutzer hat die Möglichkeit, für zugesagte Terminvorschläge Reservierungen in seinem Kalender vorzunehmen. Dabei können sowohl einzelne Termine als auch alle zugesagten Termine reserviert werden. UC22 Eigene Kalender betrachten In der Meetingansicht kann der Benutzer seine eigenen Kalender sichtbar machen, um schneller entscheiden zu können, zu welchen Terminvorschlägen er Zeit hat. 42

43 3 Konzeption Zunächst wird in Unterkapitel 3.1 die Systemarchitektur des Anwendungssystems dargestellt. Die serverseitige Systemarchitektur ist durch die anderen TeaCo-Varianten bereits gegeben und kann weitestgehend übernommen werden. In Unterkapitel 3.2 folgt dann die Konzeption der Benutzungsschnittstelle als ein zentraler Bestandteil dieser Arbeit. Hierbei werden die in der Analyse (Kapitel 2) gewonnenen Erkenntnisse berücksichtigt. Um während der Implementierung den in Unterkapitel 1.3 beschriebenen Entwicklungsprozess einzuhalten, werden die einzelnen Features in Unterkapitel 3.3 in Feature-Sets eingeteilt. Der in der Aufgabenanalyse (Unterkapitel 2.1) beschriebene traditionelle Terminfindungsprozess wird für TeaCo optimiert. Dieser optimierte Terminfindungsprozess wurde von Lohrenz (2009) bereits beschrieben und soll hier nochmals dargelegt werden. Der optimierte Terminfindungsprozess gliedert sich in vier Phasen und ist in Abbildung 20 visualisiert. Abbildung 20: Optimierter Terminfindungsprozess (nach Lohrenz, 2009, S. 43) (1) Der Initiator eines Meetings überlegt sich, zu welchen Zeiten das Meeting stattfinden könnte. Auf diese Weise entstehen die ersten Terminvorschläge eines Meetings. (2) Der Initiator erstellt ein neues Meeting in TeaCo, pflegt die entstandenen Terminvorschläge ein und lädt alle gewünschten Teilnehmer über deren -Adresse ein. (3) Die eingeladenen Teilnehmer stimmen über jeden einzelnen Terminvorschlag ab. Außerdem können Teilnehmer weitere Terminvorschläge erstellen, über die dann die übrigen Teilnehmer ebenfalls abstimmen. 43

44 (4) Nachdem sich ein oder mehrere Terminvorschläge durch die Abstimmung als passend herausgestellt haben, werden diese vom Initiator oder einem anderen Teilnehmer im System als endgültig markiert. Alle Teilnehmer werden mit einer über die endgültigen Termine informiert. Dieser optimierte Terminfindungsprozess hat gegenüber dem traditionellen Terminfindungsprozess weniger Schwächen. Neue Informationen werden über das Anwendungssystem schneller kommuniziert und sind von allen Teilnehmern jederzeit einsehbar. Außerdem kommt der optimierte Terminfindungsprozess ohne Hierarchie aus, sodass sich alle Teilnehmer daran beteiligen können und der Initiator nicht länger einen Flaschenhals darstellt (vgl. Abb. 7). 3.1 Systemarchitektur Für TeaCo ipad wird grundsätzlich dieselbe Systemarchitektur verwendet, wie sie auch schon für TeaCo iphone Verwendung fand. TeaCo ipad und TeaCo iphone unterscheiden sich in einem Punkt von TeaCo Desktop und TeaCo Mobile. Während TeaCo Desktop und TeaCo Mobile die Benutzungsschnittstelle auf dem Server generieren und diese dann mitsamt der relevanten Informationen an den Client senden, wird die Benutzungsschnittstelle in TeaCo iphone und TeaCo ipad lokal vom Client generiert, nachdem dieser die relevanten Daten vom Server erhalten hat. Neben dem Client-Server-Modell (Unterkapitel 3.1.1) bedienen sich alle TeaCo-Varianten dem Model-View-Controller-Architekturmuster, welches in Unterkapitel beschrieben wird. In Unterkapitel wird das Datenbankschema für TeaCo beschrieben Client-Server-Modell Damit mehrere Benutzer an verschiedenen Orten über TeaCo interagieren und kommunizieren können, basiert TeaCo auf dem Client-Server-Modell. Die Schritte, die während einer Anfrage des Clients ablaufen, wurden bereits von Schröder (2010) beschrieben. Abbildung 21 visualisiert diesen Vorgang. 44

45 (1) HTTP-Anfrage (2) Weiterleitung Anwendungs- Client (ipad View) (5) HTTP-Antwort Webserver (4) Antwort server (3) Verarbeitung Datenbank Abbildung 21: Client-Server-Modell von TeaCo (nach Schröder, 2010, S. 39) (1) Der Client generiert aus den Eingaben des Benutzers eine HTTP-Anfrage und sendet diese an den Webserver. (2) Der Webserver leitet die Anfrage an der Anwendungsserver weiter, auf dem TeaCo läuft. (3) Der Anwendungsserver generiert unter Berücksichtigung der anfragenden TeaCo-Variante eine entsprechende Antwort. Dabei greift der Anwendungsserver auf die Datenbank zu. (4) Der Anwendungsserver sendet die Antwort an den Webserver. Im Fall von TeaCo ipad handelt es sich dabei um ein Property-List-Objekt (plist, Apple Inc., 2011f). (5) Der Webserver leitet die Antwort an den Client weiter, welcher mit Hilfe der Antwort die neue Ansicht auf dem ipad generiert. 45

46 3.1.2 Model-View-Controller-Architekturmuster Das Model-View-Controller-Architekturmuster (MVC) wurde erstmals für Smalltalk-80 (Burbeck, 1992) eingesetzt. MVC sieht eine strikte Trennung von Anwendungsdaten (Model), Benutzungsschnittstelle (View) und Programmsteuerung (Controller) vor. Es folgt eine Beschreibung der einzelnen Komponenten. Model Im Model werden die Anwendungsdaten strukturiert und abgespeichert. Für TeaCo ipad werden dieselben Daten wie für die anderen TeaCo-Varianten verwendet. Eine Beschreibung des Datenbankschemas findet sich in Unterkapitel View Die View umfasst die Benutzungsschnittstelle, über die der Benutzer mit TeaCo interagiert. Anders als bei TeaCo Desktop und TeaCo Mobile werden im View des Anwendungsservers lediglich die Anwendungsdaten bereitgestellt. Die eigentliche Benutzungsschnittstelle entsteht erst auf dem Client. Da bereits eine View für TeaCo iphone existiert, die die Anwendungsdaten im plist-format liefert, muss für TeaCo iphone voraussichtlich keine neue View für den Anwendungsserver entstehen. Controller Der Controller beinhaltet alle Funktionen des Anwendungssystems. Für TeaCo ipad werden auch hier voraussichtlich keine Änderungen nötig sein Datenbankschema Abbildung 22 zeigt ein Entity-Relationship-Diagramm des Datenbankschemas von TeaCo. Das Datenbank-Schema, welches für TeaCo Desktop verwendet wurde (Lohrenz, 2009), wurde um weitere Entitäten und Relationen erweitert. Für das aktuelle TeaCo iphone wurde für den APNs nachträglich eine weitere Tabelle in der Datenbank angelegt. Außerdem existieren nun die Entitäten Known Addresses und Alias Addresses, deren Funktion im Folgenden beschrieben wird. 46

47 Die Tabelle Users enthält alle Benutzer, die bei TeaCo angemeldet sind. Ein Eintrag in dieser Tabelle enthält den Namen des Benutzers, seine -Adresse, seine Sprache, Free-Busy-List- Daten, seinen individuellen Schlüssel und sofern eingegeben das verschlüsselte Passwort. Ein Benutzer kann folgende Relationen eingehen: Der Benutzer ist Teilnehmer beliebig vieler Meetings. Der Benutzer ist Initiator beliebig vieler Meetings. Der Benutzer ist Autor beliebig vieler Kommentare. Der Benutzer ist Urheber beliebig vieler Terminvorschläge. Der Benutzer hat über beliebig viele Terminvorschläge abgestimmt. Der Benutzer hat beliebig viele alternative -Adressen (Alias Addresses). Der Benutzer kennt beliebig viele -Adressen anderer Benutzer (Known Addresses). Der Benutzer hat beliebig viele Tokens (benötigt für den APNs). has Comments N Comment N Author Alias Address N 1 Initiator 1 has Addresses N 1 1 Meeting N Participants M User 1 N has known Add. Known Address has Suggestions Creator Voter has Tokens N N N N Suggestion 1 N Votes Vote Token Abbildung 22: Datenbankschema von TeaCo Alle Meetings werden in einer gleichnamigen Tabelle verwaltet. Ein Tabelleneintrag enthält den Namen und den Initiator des Meetings sowie die Information, ob ein Meeting eingeschränkt ist. Ein Meeting kann folgende Relationen eingehen: 47

48 Ein Meeting hat mindestens einen Teilnehmer. Ein Meeting hat beliebig viele Kommentare. Ein Meeting hat beliebig viele Terminvorschläge. Die Tabelle Suggestions beinhaltet alle Terminvorschläge. Ein Terminvorschlag hat ein Datum, einen Startzeitpunkt, einen Endzeitpunkt und die Information darüber, ob der Terminvorschlag als endgültig markiert ist. Ein Terminvorschlag hat einen Urheber. Ein Terminvorschlag gehört zu einem Meeting. Die Tabelle Votes enthält alle Stimmen. Die Einträge enthalten die jeweilige Entscheidung sowie folgende Relationen: Eine Stimme kommt von einem Benutzer. Eine Stimme gehört zu einem Terminvorschlag. Die Tabelle Comments enthält alle Kommentare. Ein Kommentar besteht aus einem Kommentartext und geht folgende Relationen ein. Ein Kommentar hat einen Autor. Ein Kommentar gehört zu einem Meeting. Die Tabelle Alias Addresses enthält die -Adressen zu jedem Benutzer. Die Tabelle Known Addresses verwaltet zu jedem Benutzer die ihm bekannten -Adressen. Dies sind die Adressen aller Benutzer, mit denen dieser bereits ein Meeting vereinbart hat. In der Tabelle Tokens werden Tokens gespeichert, die für den APNs benötigt werden. 3.2 Benutzungsschnittstelle Abbildung 23 zeigt das Schema der Benutzungsschnittstelle von TeaCo ipad. Sie ist in drei Hauptansichten (Login-Seite, Meetingübersicht, Meetingansicht) unterteilt. In diesen Hauptansichten 48

49 können weitere Ansichten als sogenannte assoziierte Pop-Ups aufgerufen werden. Assoziierte Pop-Ups werden über einen Button aufgerufen und mit diesem über einen Pfeil assoziiert (vgl. Abb. 27, 28, 32). Ruft der Benutzer die Applikation auf, so gelangt er zunächst auf die Login-Seite. Auf der Login-Seite kann der Benutzer sich registrieren und gelangt via Login zur Meetingübersicht. In der Meetingübersicht lassen sich die Pop-Ups Neues Meeting, Meetingtitel ändern und Einstellungen aufrufen. Wählt der Benutzer aus der Meetingübersicht ein Meeting aus, so gelangt er zur Meetingansicht. In dieser Ansicht können die Pop-Ups Neuer Terminvorschlag, Termindaten versenden, Teilnehmer und Kommentare aufgerufen werden. Login-Seite Login Logout Meeting auswählen Zurück Meetingübersicht Meetingansicht Pop-Ups Pop-Ups Neues Meeting Neuer Terminvorschlag Meetingtitel ändern Termindaten versenden Einstellungen Teilnehmer Kommentare Abbildung 23: Zusammenhang der Dialoge 49

50 3.2.1 Login-Seite Die Login-Seite wird immer dann gezeigt, wenn der Benutzer die Applikation aufruft und noch nicht eingeloggt ist. Außerdem gelangt der Benutzer nach einem Logout auf die Login-Seite zurück. Die Login-Seite vermittelt dem Benutzer sehr knapp, wozu die Applikation gedacht ist (»TeaCo ipad. Terminfindung. Schnell und einfach.«) und bietet ihm die Möglichkeit zum Registrieren oder Einloggen. Das Einloggen kann über die -Adresse und das Passwort oder über einen persönlichen Autorisierungsschlüssel, der nach der Registrierung via an den Benutzer geschickt wird, erfolgen. Da die Tastatur für alle Vorgänge gebraucht wird, ist diese zu jeder Zeit eingeblendet. Die Anordnung der Interaktionselemente auf der Login-Seite ist in Abbildung 24 skizziert. Hierbei handelt es sich um die Ansicht im Querformat. Die Ansicht im Hochformat wird sich nur leicht von dieser unterscheiden. Abbildung 24: Mockup der Login-Seite, Querformat 50

51 3.2.2 Meetingübersicht Die Abbildung 25 zeigt eine Skizze der Meetingübersicht im Hochformat. Im Querformat würden Kopf- und Fußzeile sowie die Auflistung der Meetings breiter. Dafür könnten allerdings weniger Meetings gleichzeitig angezeigt werden, da die Ansicht im Querformat weniger hoch ist. In der Kopfzeile befindet sich der Bearbeiten-Button, mit dem der Editier-Modus (vgl. Abb. 26) aktiviert und deaktiviert werden kann. In der Fußzeile befindet sich links ein Button zum Aktualisieren der Ansicht, in der Mitte eine Schaltfläche zum Ändern der Sortierung der Meetings (nach letzter Änderung, Alphabet oder Initiator) und rechts ein Button zum Aufrufen der Einstellungen (vgl. Abb. 28). Zwischen Kopf- und Fußzeile sind die Meetings aufgelistet. Die Meetings werden in zwei Gruppen eingeteilt je nach dem, ob der Benutzer bereits über alle Terminvorschläge des Meetings abgestimmt hat oder nicht. In Abbildung 26 sind die vier möglichen Zustände eines Eintrags in der Meeting-Liste dargestellt. In der ersten Zeile ist der Normalzustand skizziert. Links zeigt ein Icon, ob der Benutzer der Initiator des Meetings ist oder ob das Meeting eingeschränkt ist (hier: Benutzer ist Initiator). Daneben ist der Meetingtitel und unter dem Meetingtitel der Zeitpunkt der letzten Änderung zu finden. Auf der rechten Seite befinden sich Informationen über die Anzahl der als endgültig markierten Terminvorschläge (hier: 0) und den Anteil der Teilnehmer, die bereits abgestimmt haben (hier: 75%). Wischt der Benutzer nun mit einem Finger über diesen Eintrag, so erscheint ein Button zum Löschen bzw. Verlassen des Meetings an der rechten Seite. Durch erneutes Wischen oder Tippen auf einen anderen Bereich auf dem Display wird dieser Zustand wieder verlassen. Der Zustand ist in der zweiten Zeile der Abbildung 26 skizziert. Wechselt man über den Bearbeiten-Button in den Editier-Modus, so erscheinen Interaktionselemente zum Löschen (-), Klonen (+) und Titel ändern(>). Tippt man auf das Interaktionselement zum Löschen (linke Seite), so erscheint der gewohnte Löschen-Button. Der Zustand im Editier-Modus ist in den Zeilen drei und vier der Abbildung 26 skizziert. Nach dem Tippen auf den Button zum Erzeugen eines neuen Meetings (+) in der Kopfzeile erscheint ein Pop-Up zum Erstellen eines neues Meetings (vgl. Abb. 27). In diesem Pop-Up kann man den Titel des Meeting festlegen und bestimmen, ob das Meeting eingeschränkt sein soll. Mit 51

52 Abbildung 25: Mockup der Meetingübersicht, Hochformat 52

53 Abbildung 26: Mockup: Zustände eines Meeting-Eintrags einem Tippen auf Neues Meeting anlegen wird das Meeting erstellt und der Benutzer gelangt zur Meetingübersicht. Dort kann der Benutzer dann sofort die weiteren nötigen Schritte (Teilnehmer einladen, Terminvorschläge erzeugen) durchführen, um ein Meeting zu planen. Abbildung 27: Mockup: Ein neues Meeting erstellen Über den Button Einstellungen in der Fußzeile lässt sich ein Pop-Up aufrufen, in dem der Benutzer jegliche Einstellungen zu seinem Account durchführen kann. Dieses Pop-Up ist in Abbildung 28 skizziert. 53

54 Abbildung 28: Mockup: Einstellungen 54

55 3.2.3 Meetingansicht Die Meetingansicht stellt ein Meeting mit allen dazugehörigen Terminvorschlägen, Teilnehmern und Kommentaren dar. Der Benutzer kann zwischen einer Tages-, einer Wochen- und einer Monatsansicht wechseln. In allen drei Ansichten findet sich auf der linken Seite eine Auflistung aller Terminvorschläge, sodass schnell und unkompliziert abgestimmt werden kann. Außerdem kann in dieser Liste ein Terminvorschlag als endgültig markiert oder bearbeitet werden. Über dieser Liste befinden sich zwei Buttons. Der eine Button führt zurück zur Meetingübersicht (<), mit dem anderen (+) wird ein Pop-Up zum Erstellen eines neuen Terminvorschlags eingeblendet. Unter der Liste befindet sich ein Button zum Aktualisieren der Ansicht. In der Kopfzeile des rechten Teils der Meetingansicht befindet sich der Bearbeiten-Button, mit welchem man genau wie in der Meetingübersicht in den Editiermodus gelangt. Rechts daneben befindet sich der Titel des Meetings. Links in der Kopfzeile befindet sich die Schaltfläche zum Wechseln zwischen den einzelnen Darstellungen der Terminvorschläge. In der Fußzeile befinden sich die Buttons zum Termindaten versenden, Teilnehmer verwalten und Kommentare verwalten. Abbildung 29 zeigt die Tagesansicht. Diese Ansicht stellt einen einzelnen Tag dar. Die Terminvorschläge sind dementsprechend groß und können alle nötigen Interaktionselemente umfassen. An der linken Seite der Tagesansicht befindet sich die Zeitleiste. Durch seitliches Wischen mit zwei Fingern kann der Tag gewechselt werden. In der Tagesansicht kann gescrollt werden, da nicht die gesamten 24 Stunden eines Tages gleichzeitig dargestellt werden. In der Wochenansicht (Abbildung 29) sind die einzelnen Terminvorschläge im Vergleich zur Tagesansicht deutlich kleiner dargestellt, sodass die Interaktionselemente in einem zusätzlichen Pop-Up dargestellt werden müssen. Dieses Pop-Up öffnet sich nach einem einfach Tippen auf den Terminvorschlag. Neben den Interaktionselementen finden sich hier auch die Informationen, wie einzelne Teilnehmer zu diesem Terminvorschlag abgestimmt haben. An der linken Seite der Wochenansicht befindet sich die Zeitleiste. Durch seitliches Wischen mit zwei Fingern kann die Woche gewechselt werden. In der Wochenansicht kann gescrollt werden, da nicht die gesamten 24 Stunden eines Tages gleichzeitig dargestellt werden. 55

56 Abbildung 29: Mockup der Meetingansicht: Tagesansicht 56

57 Abbildung 30: Mockup der Meetingansicht: Wochenansicht 57

58 Die Monatsansicht (Abbildung 31) dient vor allem der Übersicht. Interaktionselemente auf den einzelnen Terminvorschläge können aufgrund der Größe kaum sinnvoll platziert werden. Deshalb ist an dieser Stelle genau wie in der Wochenansicht ein Pop-Up vorgesehen, welches die nötigen Interaktionselemente beinhaltet. Durch seitliches Wischen mit zwei Fingern kann der Monat gewechselt werden. Abbildung 31: Mockup der Meetingansicht: Monatsansicht In der Abbildung 32 ist beispielhaft für die anderen Pop-Ups (Terminvorschlag hinzufügen, Termindaten versenden, Teilnehmer) das Pop-Up für die Kommentare skizziert. Dieses Pop-Up stellt die Kommentare der Teilnehmer dar und bietet zudem die Möglichkeit, einen Kommentar zu schreiben (+), zu editieren oder zu löschen. In allen drei Ansichten findet ein wechselseitiges Updaten der Darstellung auf der rechten Seite (Tages-, Wochen-, Monatsansicht) und der Listendarstellung statt. Wird also ein Terminvorschlag in der Liste ausgewählt, so wird der entsprechende Terminvorschlag auch auf der rechten Seite 58

59 Abbildung 32: Assoziiertes Pop-Up in der Meetingansicht 59

60 angezeigt. Wird in der Tages-, Wochen- oder Monatsansicht ein Terminvorschlag ausgewählt, so wird dieser auch in der Listendarstellung markiert. Die Abbildungen zur Meetingansicht zeigen zwar alle Skizzen im Querformat, jedoch soll auch das Hochformat unterstützt werden. Die Darstellungen ändern sich im Hochformat dahingehend, dass der Bereich zur Darstellung der Tages-, Wochen- und Monatsansicht den kompletten Bildschirm einnimmt. Die Listendarstellung wird nicht mehr dauerhaft angezeigt, lässt sich jedoch im Sinne des Split-View-Controllers mit Hilfe eines Pop-Ups anzeigen (vgl. Abb. 16). 60

61 3.3 Feature-Sets An dieser Stelle werden die in Unterkapitel 2.5 beschriebenen Use-Cases in so genannte Feature- Sets eingeteilt. Die Feature-Sets sollen inhaltlich verwandte Features gruppieren und möglichst so einen Umfang haben, dass sie binnen einer Woche implementiert werden können. Darüber hinaus werden die einzelnen Feature-Sets nach Priorität geordnet, sodass die essentiellen Feature- Sets zuerst implementiert werden und optionale Feature-Sets nur dann umgesetzt werden, wenn es der gegebene Zeitrahmen zulässt. Feature-Set 1.1: Meetingansicht, Quick-Vote-List Der Benutzer sieht in der Quick-Vote-List alle Terminvorschläge und kann diese bearbeiten, als endgültig markieren, löschen und über diese Abstimmen. Feature-Set 1.2: Meetingansicht, Tagesansicht Der Benutzer sieht in der Tagesansicht alle Terminvorschläge und kann diese bearbeiten, als endgültig markieren, löschen und über diese Abstimmen. Tagesansicht und Quick-Vote-List updaten sich wechselseitig. Feature-Set 1.3: Meetingansicht, Terminvorschläge erzeugen + Termindaten versenden Der Benutzer kann neue Terminvorschläge erzeugen und Termindaten an alle Teilnehmer versenden. Feature-Set 1.4: Meetingansicht, Teilnehmer verwalten + Kommentare verwalten Der Benutzer kann Teilnehmer ein- und ausladen sowie Kommentare verfassen, löschen und bearbeiten. 61

62 Feature-Set 1.5: Meetingansicht, Wochenansicht + Monatsansicht Der Benutzer sieht in der Wochen- und Monatsansicht alle Terminvorschläge und kann diese bearbeiten, als endgültig markieren, löschen und über diese Abstimmen. Wochenansicht respektive Monatsansicht und Quick-Vote-List updaten sich wechselseitig. Die Feature-Sets 1.1 bi 1.5 umfassen die folgenden Use-Cases: UC2 Abstimmung über einen Terminvorschlag UC3 Erzeugen eines Terminvorschlags UC4 Manipulation eines Terminvorschlags UC5 Zurücksetzen der Abstimmung UC6 Löschen eines Terminvorschlags UC7 Auswahl endgültiger Termine UC8 Benachrichtigung über endgültige Termine UC11 Einladen von Teilnehmern UC12 Eingabe bekannter Teilnehmer UC14 Ausladen von Teilnehmern UC16 Verfassen, Bearbeiten und Löschen von Kommentaren Feature-Set 2: Meetingübersicht In der Meetingübersicht kann der eingeloggte Benutzer alle seine Meetings betrachten und bearbeiten. Er kann neue Meetings erstellen und bestehende Meetings klonen, löschen oder verlassen. Durch die Auswahl eines Meetings gelangt der Benutzer zur Meetingansicht. UC1 Navigation innerhalb der Meetingübersicht und -ansicht UC9 Erzeugen einen neuen Meetings UC10 Festlegung der Rechte eines neuen Meetings 62

63 UC13 Eingeladene Teilnehmer in ein neues Meeting übernehmen UC15 Verlassen bzw. Löschen eines Meetings Feature-Set 3: Anmelden und Registrieren Wird die Applikation vom Benutzer auf dem ipad gestartet, so erscheint eine Login-Seite, von der aus sich der Benutzer einloggen oder registrieren kann. Das Feature-Set umfasst folgende Use-Cases: UC18 An- und Abmeldung UC19 Registrierung Feature-Set 4: Einstellungen (optional) Der Benutzer hat die Möglichkeit, dass System nach eigenen Wünschen anzupassen. UC17 Individualisierung des Anwendungssystems Feature-Set 5: Hilfesystem (optional) Dem Benutzer wird in jedem Systemzustand eine Hilfe zu Bedienung des System angeboten. UC20 Hilfesystem Feature-Set 6: Expertenfeatures (optional) Um die Terminfindung für erfahrene Benutzer weiter zu vereinfachen, werden verschiedene Expertenfeatures angeboten. UC21 Termine reservieren UC22 Eigene Kalender betrachten 63

64 4 Realisierung In diesem Kapitel sollen zunächst die Techniken und Frameworks beschrieben werden, die auf dem Server respektive auf dem Client verwendet wurden. Danach werden wesentliche Abschnitte und Herausforderungen während der Umsetzung beschrieben. 4.1 Serverseitige Technik Die serverseitig verwendete Technik war durch die existierenden Varianten von TeaCo bereits vorgegeben. Lohrenz (2009) benutzte für den TeaCo-Server das Framework Ruby On Rails und bediente sich weiter dem REST-Architekturprinzip. Darüber hinaus existierte durch Schröder (2010) bereits eine Schnittstelle zwischen dem TeaCo-Server und ios-geräten Ruby On Rails Ruby on Rails (kurz: Rails) ist ein Web-Applikation-Framework, wurde von David Heinemeier Hansson (Thomas & Heinemeier Hansson, 2007) entwickelt und im Jahr 2004 erstmals veröffentlicht. Es ist in der objektorientierten Programmiersprache Ruby (Flanagan & Matsumoto, 2008) geschrieben und verfolgt die Prinzipien»Konvention vor Konfiguration«und»Don t repeat yourself«(dry). Das Prinzip»Konvention vor Konfiguration«besagt, dass das Zusammenwirken von Objekten durch ihre Benennung definiert ist und somit auf eine zusätzliche Konfiguration verzichtet werden kann. Durch die konsequente Einhaltung dieses Prinzips kann die Umsetzung eines Projekts beschleunigt werden. Das DRY-Prinzip (deutsch:»wiederhole dich nicht!«) steht für die Vermeidung von redundanten Informationen während der Umsetzung. Somit kann ein Projekt schneller umgesetzt und später leichter gewartet werden. 64

65 Rails besteht aus den Modulen Active Support, Action Mailer, Action Resource, Action Pack und Active Record, von denen lediglich die letzten beiden beschrieben werden sollen, da diese zusammen das von Rails verfolgte Model-View-Controller-Architekturmuster darstellen. Das Modul Action Pack beinhaltet den ActionController, welcher den Controller des MVC darstellt. Der ActionController empfängt die eingehenden HTTP-Anfragen und verarbeitet diese. Daraufhin generiert die ebenfalls im ActionPack befindliche ActionView also die View des MVC eine HTTP-Antwort, welche Informationen in verschiedenen Formaten beinhalten kann. Für TeaCo Desktop werden die Informationen in HTML codiert, die Varianten TeaCo iphone und TeaCo ipad bekommen die Informationen im plist-format geliefert. Das Modul Active Record stellt das Model des MVC dar. Mittels dieser Komponente können Daten aus der Datenbank gelesen und nach deren Verarbeitung wieder zurückgeschrieben werden. Beim Auslesen aus der Datenbank wird die Zeile einer Tabelle in ein Objekt umgewandelt, welches dann als solches behandelt werden kann. Existiert zum Beispiel eine Tabelle Meetings so kann nach dem Auslesen einer Zeile respektive eines Meetings die ID des Meetings mit meeting.id angesprochen werden. Beim Zurückschreiben in die Datenbank wird das Objekt dann wieder zu der Zeile einer Tabelle Representational State Transfer (REST) Der in der Doktorarbeit von Fielding (2000) behandelte Begriff Representational State Transfer (REST) beschreibt ein Paradigma für die Entwicklung von Webanwendungen. Die Grundidee von REST sagt aus, das eine explizite Internetadresse (URL) zu genau einer Ressource führt. Eine Ressource stellte dabei eine Entität der betreffenden Webanwendung dar. TeaCo benutzt genau wie die meisten Webanwendungen den HTTP-Standard um einzelne Ressourcen anzusprechen. Die Rails-basierte Umsetzung des TeaCo-Servers sieht also für jede Entität respektive Ressource eine individuelle URL vor. In der HTTP-Anfrage, die an eine URL gesendet wird, wird eine HTTP-Methode (GET, PUT, POST, DELETE) definiert. Je nach definierter HTTP-Methode wird dann eine Aktion auf dem Server ausgeführt und eine HTTP-Antwort generiert. Im Fall TeaCo wird der HTTP-Anfrage der User-Agent beigefügt. So kann der TeaCo-Server HTTP-Anfragen 65

66 von Desktop Desktop, TeaCo Mobile und TeaCo iphone sowie TeaCo ipad differenzieren und angepasste HTTP-Antworten zurücksenden. Die folgende Abbildung 33 nach Schröder (2010) zeigt am Beispiel der Entität Meeting, welche Aktionen durch angesprochene URLs in Verbindung mit einer HTTP-Methode ausgelöst werden. URL HTTP-Methode Aktion im Rails-Controller /meetings GET Listet alle Meetings auf. /meetings POST Erzeugt ein neues Meeting. /meetings/new GET Liefert ein Formular zur Erzeugung eines neuen Meetings. /meetings/1 GET Zeigt das Meeting mit der ID 1. /meetings/1/edit GET Liefert ein Formular zur Bearbeitung des Meetings mit der ID 1. /meetings/1 PUT Aktualisiert das Meeting mit der ID 1 mit neuen Daten. /meetings/1 DELETE Löscht das Meeting mit der ID 1. Abbildung 33: URLs und Aktionen im Rails-Controller (nach Schröder, 2010, S. 62) 4.2 Clientseitige Technik Zur Entwicklung von nativen ipad-applikationen wird die Cocoa Touch API in Verbindung mit Objective-C genutzt. Apple liefert mit dem ios Software Development Kit eine Sammlung von Werkzeugen zur Entwicklung für ios-applikationen. Für TeaCo ipad wurden im Wesentlichen Xcode 3.2 als Programmierumgebung, der ios-simulator zum Testen und Debuggen in der Simulation sowie das Tool Instrumentals zur Optimierung der Speicherverwaltung genutzt. 66

67 4.2.1 Cocoa Touch API Die Cocoa Touch API (Apple Inc., 2010a) ist die Programmierschnittstelle zur Entwicklung von Applikationen für das ios. Cocoa Touch basiert auf Cocoa, der Programmierschnittstelle für Mac-OS-X-Anwendungen, welches durch die Weiterentwicklung von NeXTSTEP durch das Unternehmen NeXT in den 1980er Jahren entstand. Die Abbildung 34 zeigt die Schichten des ios und wie Cocoa Touch darin angeordnet ist. Direkt unter der eigentlichen Applikation liegt die Cocoa-Touch-Schicht. Diese beinhaltet unter anderem das UIKit-Framework, welches die Objekte der Benutzungsschnittstelle liefert. Außerdem wird hier die Verarbeitung von Ereignissen wie zum Beispiel eine Multi-Touch-Geste oder das Drehen des ios-geräts bewerkstelligt. Mit Hilfe des UIKits wird somit die Interaktion zwischen ios-gerät und Benutzer gestaltet. Neben der Cocoa-Touch-Schicht ist auch die Core-Services-Schicht mit dem Foundation-Framework von essentieller Bedeutung. Hier werden unter anderem primitive Datentypen, das Verhalten von Objekten und Netzwerkfunktionen bereitgestellt. Abbildung 34: Cocoa Touch im ios (aus Apple Inc., 2010a, S. 16) 4.3 Umsetzung Die Umsetzung von TeaCo ipad beschränkte sich auf die Entwicklung der nativen ipad-applikation selbst. Es stellte sich heraus, dass die von Schröder (2010) geschaffene Schnittstelle zwischen dem TeaCo-Server und TeaCo iphone auch für TeaCo ipad genutzt werden kann. Damit eine Än- 67

68 derung der Schnittstelle für das iphone jedoch keine Auswirkungen auf die Funktionalität der ipad-applikation hat, wurde die bestehende Schnittstelle dupliziert Client-Server-Kommunikation Die Kommunikation zwischen dem TeaCo-Server und TeaCo ipad musste somit lediglich für die native Applikation auf dem ipad programmiert werden. Dazu wurde für jede mögliche Interaktion mit einer Entität auf dem Server eine eigene Klasse geschrieben. Auf diese Weise lassen das Erstellen der Anfrage sowie das Verarbeiten der Antwort strukturieren. Beispielsweise können mittels der Klasse MeetingDataConnection (Listing 1) die Informationen zu einem bestimmten Meeting abgerufen werden. 1 -( id) initwithmeetingid :( NSString *) meetingid keepdate :( BOOL ) keepdate { 2 keep = keepdate ; 3 meetingdata = [[ NSMutableData alloc ] init ]; 4 ID = [ meetingid copy ]; 5 6 // Init an show Loading - Screen 7 HUD = [[ MBProgressHUD alloc ] initwithview :[ appdelegate window ]]; 8 HUD. delegate = self ; 9 HUD. labeltext Meeting laden "; 10 [[ appdelegate window ] addsubview : HUD ]; 11 [ HUD show :NO ]; // Set up request 14 NSURL * rurl = [ NSURL URLWithString : 15 [ NSString stringwithformat :@"%@/%@/%@/",kteacourl, userkey, meetingid ] 16 ]; 17 NSMutableURLRequest * request = [[ NSMutableURLRequest alloc ] initwithurl : rurl ]; 18 [ request setvalue : kuseragent forhttpheaderfield :@" User - Agent "]; self = [ super initwithrequest : request delegate : self ]; 21 [ request release ]; 22 return self ; 23 } Quelltext 1: MeetingDataConnection.m, Initialisierung 68

69 Während der Initialisierung einer Client-Server-Verbindung werden im Wesentlichen drei Arbeitsschritte vollführt. Zunächst wird ein Indikator angezeigt, der dem Benutzer zeigt, dass eine Netzwerkaktivität existiert. Im Fall der MeetingDataConnection ist der Indikator eine Instanz des MBProgressHUD (Bukovinski, 2011), welches in der Mitte des ipad-displays erscheint und Benutzereingaben während der Netzwerkaktivität unterbindet (Listing 1, Z. 7-11). In anderen Fällen zum Beispiel beim Abstimmen über einen Terminvorschlag sind weitere Benutzereingaben jedoch zugelassen, weshalb an dieser Stelle nur ein dezenter Indikator in der Statusleiste des ipads angezeigt wird. Der zweite Arbeitsschritt ist das Erstellen der HTTP-Anfrage (Listing 1, Z ). Die Anfrage enthält Informationen über die URL, die HTTP-Methode und den User-Agent sowie den HTTP-Body, der weitere Informationen enthalten kann. Der mitgesendete User-Agent übermittelt dem TeaCo-Server, dass die HTTP-Anfrage von einem ipad gesendet wurde, damit der TeaCo-Server entsprechende Daten liefern kann. Der User-Agent ist also für jede Verbindung zwischen TeaCo ipad und dem TeaCo-Server gleich. Im Falle der MeetingDataConnection setzt sich die URL aus der Konstanten kteacourl (URL des Servers), dem individuellen user- Key und der Meeting-ID zusammen. Die HTTP-Methode POST ist der Standard-Wert und muss hier nicht gesetzt werden. Der HTTP-Body ist in diesem Fall leer. Der dritte Arbeitsschritt ist das Absenden der HTTP-Anfrage (Listing 1, Z ) In Listing 2 wird das Verhalten nach erfolgreicher Beendigung der Verbindung beschrieben. Zunächst werden die empfangenen Daten verarbeitet. Im Falle der MeetingDataConnection geschieht dies mit der Methode putdatainusermodel, welche die empfangenen Daten in das entsprechende Meeting-Model schreibt (Listing 2, Z. 2). Danach wird der Indikator für Netzwerkaktivität wieder ausgeblendet (Listing 2, Z. 3). 1 -( void ) connectiondidfinishloading :( NSURLConnection *) connection { 2 [ self putdatainmeetingmodel ]; 3 [ HUD hide :NO ]; 4 [ connection release ]; 5 [ meetingdata release ]; 6 [ID release ]; 7 } Quelltext 2: MeetingDataConnection.m, Verbindung beendet 69

70 Im Falle einer nicht erfolgreichen Verbindung wird eine andere Methode aufgerufen, die den Fehler entsprechend behandelt UINavigationController Um zwischen den einzelnen Ansichten von TeaCo ipad zu wechseln, wurde der UINavigation- Controller (Apple Inc., 2009) verwendet. Dieser ermöglicht die Anordnung von Ansichten auf einem Stapel, wobei immer die oberste Ansicht für den Benutzer sichtbar ist. Für TeaCo ipad wurde die Meetingübersicht als Grundansicht definiert, die angezeigt wird, wenn der Benutzer die Applikation startet. Sollte der Benutzer nicht eingeloggt sein, so wird umgehend die Login- Ansicht darüber gelegt und somit sichtbar. Nach dem Einloggen, wird die Login-Ansicht wieder entfernt und der Benutzer sieht die Meetingübersicht. Wählt der Benutzer ein Meeting aus, so wird die Meetingansicht über die Meetingübersicht gelegt. Über einen Zurück-Button in der linken oberen Ecke der Meetingansicht kann der Benutzer zur Meetingübersicht zurück gelangen. Durch die Nutzung des UINavigationControllers ist es leider nicht mehr möglich, den UISplit- ViewController für die Meetingansicht zu benutzen, wie es während der Konzeption noch geplant war. Diese Kombination ist in der Cocoa Touch API nicht vorgesehen. Aus diesem Grund musste die Funktionalität des UISplitViewControllers selbst implementiert werden, was letztlich auch einen erheblichen Mehraufwand während der Implementierung bedeutete. Der UINavigationController wird nicht nur verwendet um die drei Hauptansichten von TeaCo ipad zu organisieren. Auch innerhalb der Pop-Ups, in denen verschiedene Ansichten dargestellt werden, werden diese Ansichten mit dem UINavigationController organisiert. Dies betrifft die Pop-Ups für Einstellungen, Kommentare, Teilnehmer und das Detail-Pop-Up zu einzelnen Terminvorschlägen NSUserDefaults Die Klasse NSUserDefaults (Apple Inc., 2010b) ermöglicht das Festlegen von Standardwerten. Mit Hilfe dieser Klasse können zu einer ios-applikation Daten über die Laufzeit der Applikation hinaus gespeichert werden. Weiter kann man dem Benutzer ermöglichen, diese Standardwerte 70

71 an seine eigenen Bedürfnisse anzupassen. So könnte der Benutzer zum Beispiel festlegen, ob er die Uhrzeit lieber im 12- oder 24-Stunden-Format sehen möchte. TeaCo ipad nutzt die Klasse NSUserDefaults, damit ein Benutzer auch nach Beenden der Applikation eingeloggt bleibt. Dazu wird nach einem erfolgreichen Login der Autorisierungscode des Benutzers mittels der Klasse NSUserDefaults gespeichert. Das Listing 3 zeigt, wie der Autorisierungscode (userkey) in die Instanz standarduserdefaults der Klasse NSUserDefaults geschrieben wird und diese Änderung mit dem Aufruf synchronize gespeichert wird. 1 NSUserDefaults * standarduserdefaults = [ NSUserDefaults standarduserdefaults ]; 2 [ standarduserdefaults setobject : userkey forkey :@" userkey "]; 3 [ standarduserdefaults synchronize ]; Quelltext 3: Autorisierungscode speichern Wird TeaCo ipad dann erneut gestartet, so kann der Autorisierungscode wieder ausgelesen werden (Listing 4). Sofern ein Autorisierungscode vorhanden ist, muss sich der Benutzer nicht erneut einloggen. Sollte sich der Benutzer ausloggen, so wird dessen Autorisierungscode wieder gelöscht. 1 NSUserDefaults * standarduserdefaults = [ NSUserDefaults standarduserdefaults ]; 2 [ usermodel setuserkey :[ standarduserdefaults stringforkey :@" userkey " ]]; Quelltext 4: Autorisierungscode auslesen Die Meeting-Ansicht Wie die Konzeption ergeben hat, hat TeaCo ipad in der Meetingansicht das meiste Potential, um gegenüber TeaCo Desktop und TeaCo iphone ein Zugewinn für den TeaCo-Benutzer zu sein. Die geplanten vier verschiedenen Darstellungen der Terminvorschläge in einem Meeting wurden allesamt umgesetzt, sodass der Benutzer nun die Auswahl aus einer Tages-, Wochen- und Monatsansicht sowie einer Listenansicht hat. Die Listenansicht ist im Querformat (Das ipad wird vom Benutzer quer gehalten.) immer und und im Hochformat nie zu sehen. Die geplante Umsetzung einer optionalen Darstellung im Hochformat wurde aus zeitlichen Gründen bisher nicht umgesetzt. Neben der Listendarstellung kann der Benutzer eine der drei anderen Ansichten wählen, um die Terminvorschläge zu betrachten. 71

72 Da der Benutzer in allen vier Ansichten die Möglichkeit zur Manipulation der Terminvorschläge hat, müssen die einzelnen Ansichten stets synchron gehalten werden. Da diese Synchronität ein wesentlicher Bestandteil der Meetingansicht darstellt, sei deren Umsetzung im Folgenden näher erläutert. Die Abbildung 35 zeigt den abstrakten Ablauf, um die einzelnen Ansichten synchron zu halten. Alle Unteransichten der Meetingansicht werden in einer Instanz der Klasse MeetingViewController verwaltet. Für die vier Ansichten der Terminvorschläge existiert je eine Instanz der Klassen ListViewController, DayViewController, WeekViewController und MonthViewController. Sollte innerhalb einer dieser Ansichten ein Terminvorschlag manipuliert werden, so wird diese Manipulation an den MeetingViewController übermittelt (init sync), welcher die Manipulation verarbeitet und daraufhin die vier Ansichten aktualisiert (update). List- View- Controller init sync update Day- View- Controller update Meeting- View- Controller update Month- View- Controller update Week- View- Controller Abbildung 35: Meetingansicht synchronisieren Bei diesen Manipulationen kann es sich um jegliche Änderungen am Terminvorschlag Verschieben, Abstimmen, Als-endgültig-Markieren und Löschen handeln. Diese Manipulationen sind jedoch nur in der Listen- und Tagesansicht möglich. Allerdings kann ein Terminvorschlag in jeder Ansicht durch Antippen als aktiv markiert werden, wodurch dieser in den beiden gerade sichtbaren Ansichten hervorgehoben wird. Das hat den Vorteil, dass man den aktuell betrachte- 72

73 ten Terminvorschlag auch in den anderen Ansichten schnell wieder findet und die Vorzüge der anderen Ansichten nutzen kann. 73

74 5 Dialogbeispiele In diesem Kapitel soll die entstandene Benutzeroberfläche von TeaCo ipad anhand von Dialogbeispielen vorgestellt werden. Dabei werden Design-Entscheidungen, die während der Implementierung getroffen wurden, erläutert. 5.1 Login Wenn der Benutzer TeaCo ipad zum ersten Mal öffnet oder sich ausgeloggt hat, erscheint die Login-Ansicht. Abbildung 36 zeigt diese Ansicht im Querformat mit sichtbarer Tastatur. Abbildung 36: Dialogbeispiele: Login im Querformat Der Benutzer kann sich nun auf zwei verschiedene Weisen in seinen TeaCo-Account einloggen. Zum einen kann der Benutzer die Kombination aus seiner -Adresse und seinem Passwort eingeben. Diese Variante wird im Tool-Tip erklärt, welches in Abbildung 36 sichtbar ist. Zum 74

75 anderen kann der Benutzer über seinen persönlichen Autorisierungscode in seinen Account gelangen. Den Autorisierungscode erhält der Benutzer in einer nach der Registrierung. Der Tool-Tip, der in Abbildung 37 zu sehen ist, erklärt diesem Vorgang. In Abhängigkeit des gerade fokussierten Eingabefeld, werden die beiden verschiedenen Tool-Tips, die jeweils eine Möglichkeit zum Einloggen erklären, angezeigt. Die Abbildung 37 zeigt die Login-Ansicht im Hochformat, welche sich nicht wesentlich von der Ansicht im Querformat unterscheidet. 75

76 Abbildung 37: Dialogbeispiele: Login im Hochformat 76

77 5.2 Meetingübersicht Die Meetingübersicht wird direkt nach dem Einloggen angezeigt. Hier sieht der Benutzer eine Auflistung aller seiner Meetings mit den nötigen Informationen dazu. Der Benutzer kann die Meetings löschen, verlassen, klonen und umbenennen sowie neue Meetings erzeugen. Außerdem gelangt der Benutzer in dieser Ansicht zu seinen Einstellungen. Die Abbildung 38 (Querformat) und 40 (Hochformat) zeigen die Meetingansicht in ihrem Grundzustand. Abbildung 38: Dialogbeispiele, Meetingübersicht im Querformat In der Kopfzeile befindet sich auf der linken Seite ein Button um in den Editier-Modus zu gelangen. Der Button auf der rechten Seite ruft das Pop-Up zum Erzeugen eines neuen Meetings auf. Den größten Teil des Displays nimmt die Meetingliste ein. Sie ist in die zwei Bereiche Noch nicht abgestimmt und Bereits abgestimmt unterteilt. Jede Zeile steht für ein Meeting und beinhaltet (von 77

78 links nach rechts) ein Schloss-Symbol, falls das Meeting eingeschränkt ist, ein Mensch-Symbol, falls der Benutzer der Initiator des Meetings ist, den Meetingtitel und darunter den Zeitpunkt der letzten Änderung sowie am rechten Rand ein Symbol, welches den Fortschritt der Terminplanung anzeigt. Dieses Symbol enthält Informationen über den Anteil der Teilnehmer, die bereits abgestimmt haben, sowie über die Anzahl als endgültig markierter Termine. In der Fußzeile befindet sich am linken Rand der Aktualisieren-Button und am rechten Rand der Button zum Aufrufen des Einstellungen-Pop-Ups. Die Abbildung 39 zeigt die Meetingübersicht Editier-Modus. Im Editier-Modus befinden sich am linken Rand jeder Zeile zwei Buttons, über die die Pop-Ups zum Ändern des Meetingtitels und zum Klonen eines Meetings aufgerufen werden können. Am rechten Rand befindet sich ein Button, über den das Meeting gelöscht werden kann. Abbildung 39: Dialogbeispiele, Meetingübersicht im Hochformat 78

79 Abbildung 40: Dialogbeispiele, Meetingübersicht im Editier-Modus 79

80 5.2.1 Neues Meeting, Meetingtitel ändern, Meeting klonen Um ein neues Meeting zu erstellen, muss der Benutzer in der Meetingübersicht über den Button in der rechten oberen Ecke des Displays ein Pop-Up aufrufen. Die Abbildung 41 zeigt dieses Pop-Up. Öffnet sich dieses Pop-Up, so wird sofort die Tastatur sichtbar, damit der Benutzer den Meeting- Titel eingeben kann. Darüber hinaus kann der Benutzer das Meeting als eingeschränkt definieren. Abbildung 41: Dialogbeispiele, Neues Meeting Um den Titel eines Meetings zu ändern, muss der Benutzer in den Editier-Modus wechseln und mit dem blauen Button der entsprechenden Zeile ein Pop-Up aufzurufen (Abb. 42). Das Klonen eines Meeting läuft analog dazu ab. Abbildung 42: Dialogbeispiele, Meetingtitel ändern Einstellungen Die Abbildung 43 zeigt das Pop-Up für die Einstellungen. Hier kann der Benutzer seinen Namen, sein Passwort und seine Free-Busy-URL sowie seine -Adressen verwalten. Außerdem kann sich der Benutzer ausloggen oder seinen Account löschen. Dieses Pop-Up ist so gestaltet, wie es der Benutzer aus anderen Anwendungen für das ios gewohnt ist. Außerdem befinden sich unter jeder Einstellungsmöglichkeit ausführliche Erklärungen. So ist garantiert, dass der Benutzer sich schnell zurecht findet. Der Benutzer hat die Möglichkeit, seine Änderungen zu speichern oder den Vorgang abzubrechen, ohne die Änderungen zu übernehmen. 80

81 Die Möglichkeit, die Sprache von TeaCo ipad zu ändern, wurde bewusst weggelassen. Auch wenn TeaCo ipad momentan noch einsprachig (deutsch) ist, so ist geplant, die Sprache von TeaCo ipad in Abhängigkeit zur auf dem ipad voreingestellten Sprache zu ändern. Eine Änderung der Sprache über die Einstellungen hätte somit keinen auf dem ipad sichtbaren Effekt und würde den Benutzer lediglich verwirren. Abbildung 43: Dialogbeispiele, Einstellungen 81

82 5.3 Meetingansicht Sobald der Benutzer in der Meetingübersicht ein Meeting ausgewählt hat, gelangt er in die Meetingansicht. Die Meetingansicht besteht aus vier Ansichten, die die Terminvorschläge auf unterschiedliche Weise präsentieren, sowie einigen Pop-Ups um weitere Modifikationen (Terminvorschläge, Kommentare, Teilnehmer, Planung abschließen) vorzunehmen. Zu jeder Zeit und in jeder der vier Ansichten ist ein Terminvorschlag durch Graufärbung hervorgehoben. Dieser ist der Terminvorschlag, mit dem der Benutzer seine letzte Interaktion hatte und der somit vermutlich gerade die Aufmerksamkeit des Benutzer hat. In der Tages-, Wochen-, und Monatsansicht werden als endgültig markierte Terminvorschläge zusätzlich blau gefärbt. Im aktiven Zustand werden diese dann nicht grau gefärbt, sondern erhalten ein dunkleres Blau Quick-Vote-List Die Quick-Vote-List listet die Terminvorschläge nach Tagen sortiert untereinander auf. Sie ist genau dann zusehen, wenn das ipad im Querformat gehalten wird. Neben dem Zeitraum finden sich zu jedem Terminvorschlag drei Buttons zum Abstimmen und je einer zum endgültigen Markieren (links) und zum Aufrufen des Detail-Pop-Up (vgl. Abb. 47). Die Quick-Vote-List zeichnet sich vor allem durch die Möglichkeit zum schnellen Abstimmen aus. In der Abbildung 44 ist die Quick-Vote-List (rechts) neben der Tagesansicht (links) dargestellt Tagesansicht In der Tagesansicht (Abb. 44) ist immer genau ein Tag und die an diesem Tag platzierten Terminvorschläge sichtbar. Der Benutzer hat an zu jedem Terminvorschlag die gleichen Interaktionsmöglichkeiten wie in der Quick-Vote-List. Wird ein Terminvorschlag von einem anderen überlagert, so lässt sich dieser durch Tippen auf den Terminvorschlag in der Tagesansicht oder sofern sichtbar in der Quick-Vote-List in den Vordergrund rufen. Mit einer Wisch-Geste von links nach rechts oder von rechts nach links kann der Benutzer einen Tag zurück oder vor blättern. Die Tagesansicht bietet dem Benutzer einen guten zeitlichen Überblick über die Termin- 82

83 Abbildung 44: Dialogbeispiele, Tagesansicht und Quick-Vote-List, Querformat vorschläge, sofern diese sich an wenigen Tagen befinden. Der sichtbare Bereich eines Tages kann vergrößert werden, indem der Benutzer das ipad hochkant hält Wochenansicht In Abbildung 45 ist die Wochenansicht zu sehen. In dieser Ansicht ist eine Woche und die in dieser Woche platzierten Terminvorschläge sichtbar. Da die Darstellung der Terminvorschläge mitunter sehr klein werden kann, befinden sich innerhalb der Terminvorschläge nur die Zeitangaben sowie der Abstimmungsbalken, der das Ergebnis der Abstimmung visualisiert. Ein überlagerter Terminvorschlag kann genau wie in der Tagesansicht in den Vordergrund gerufen werden. Auch das Vor- und Zurückblättern funktioniert analog zur Tagesansicht. Die Wochenansicht kann dem Benutzer einen guten Überblick vermitteln, wenn die Terminvorschläge über wenige Wochen verteilt sind. In dieser Ansicht ist jedoch kaum Interaktion möglich. Der sichtbare Bereich ver- 83

84 größert sich analog zur Tagesansicht, wenn das ipad hochkant gehalten wird. Die Skalierung der Stunden ist in der Tages- und Wochenansicht gleich, damit der Benutzer sich nicht neu auf eine Skalierung einstellen muss. Abbildung 45: Dialogbeispiele, Wochenansicht und Quick-Vote-List, Querformat Monatsansicht Die Monatsansicht (Abb. 46) zeigt die Terminvorschläge innerhalb eines Monats und bietet genau wie die Wochenansicht aus Platzgründen keine Möglichkeit, die Terminvorschläge zu manipulieren. Die Terminvorschläge werden in den Tagen des Monats gruppiert und untereinander aufgelistet. So kann sich der Benutzer einen Überblick verschaffen, wenn sich die Terminvorschläge über mehrere Monate verteilen. Auch hier lässt sich der Monat mit einer Wisch-Geste ändern. Da für jeden Tag nur ein begrenztes Rechteck zur Verfügung steht, gibt es die Möglichkeit innerhalb eines Tages zu scrollen, sofern es so viele Terminvorschläge gibt, dass nicht alle gleichzeitig angezeigt werden können. Damit nicht sichtbare Terminvorschläge nicht übersehen werden, wird zu 84

85 jedem Tag die Anzahl der Terminvorschläge in einem orangenen Kästchen angezeigt. Wenn der Benutzer das ipad hochkant hält, vergrößert sich die Anzahl maximal sichtbarer Terminvorschläge. Die Skalierung der Tage ist in der Wochen- und Monatsansicht gleich, damit der Benutzer sich nicht neu auf eine Skalierung einstellen muss. Abbildung 46: Dialogbeispiele, Monatsansicht und Quick-Vote-List, Querformat Terminvorschläge: Hinzufügen und Detail-Pop-Up Über den schwarzen Editieren-Button eines Terminvorschlags in der Quick-Vote-List oder in der Tagesansicht lässt sich das Detail-Pop-Up aufrufen (Abb. 47). Im Grundzustand (Abb. 47a) sieht man darin den Zeitraum des Terminvorschlags sowie die Stimmen aller Teilnehmer einzeln aufgelistet. Tippt der Benutzer auf das Feld mit den Informationen zum Zeitraum des Meetings, so verändern sich Form und Inhalt des Pop-Ups und der Benutzer kann den Zeitraum des Terminvorschlags bearbeiten (Abb. 47b). Da das Pop-Up über einen Pfeil an der linken Seite mit dem 85

86 Terminvorschlag assoziiert wird, weiss der Benutzer jederzeit, zu welchem Terminvorschlag das Pop-Up gehört. (a) Auflistung der Teilnehmer-Stimmen zu einem Terminvorschlag (b) Terminvorschlag bearbeiten Abbildung 47: Dialogbeispiele, Terminvorschläge: Detail-Pop-Up Das Pop-Up zum Erstellen eines neuen Terminvorschlags gleicht im Wesentlichen dem Pop-Up aus Abbildung 47b. Allerdings wird dieses Pop-Up über den Button am rechten Rand der Kopfzeile aufgerufen und dementsprechend auch über einen Pfeil mit diesem Pop-Up assoziiert Teilnehmer In der Fußzeile der Meetingansicht befindet sich ein Button, der mit Teilnehmer beschriftet ist. Zugleich zeigt der Button die Anzahl der Teilnehmer an. Abbildung 48 zeigt diesen Button und das Pop-Up, welches mit diesem Button hervorgerufen wird. Im Grundzustand (Abb. 48a) werden alle Teilnehmer des Meetings aufgelistet. 86

87 Durch Tippen auf einen Teilnehmer kann dieser markiert werden. Die Markierung wird durch einen roten Kreis mit einem Haken darin symbolisiert. Sind ein oder mehrere Teilnehmer markiert, so aktivieren sich die Buttons Ausladen und Nachricht schicken in der Fußzeile. Dieser Zustand ist in Abbildung 48b dargestellt. Tippt der Benutzer nun auf den Ausladen-Button, so werden die gewählten Teilnehmer ausgeladen. Durch das Tippen auf den Nachricht-schicken-Button erscheint eine neue Ansicht, in der der Benutzer eine Nachricht formulieren und versenden kann. (a) Teilnehmer, Grundzustand (b) Teilnehmer, Ausladen (c) Teilnehmer, Einladen Abbildung 48: Dialogbeispiele, Teilnehmer Über den Button in der rechten oberen Ecke des Pop-Ups können weitere Teilnehmer eingeladen werden. Dazu öffnet sich ein neues Pop-Up, welches in Abbildung 48c dargestellt ist. In diesem Pop-Up kann der Benutzer aus seinen bekannten Adressen wählen oder über die Eingabe einer -Adresse einen neuen Teilnehmer einladen. Das Feld zur Eingabe einer neuen - Adresse ist außerdem mit einer Auto-Completion-Funktion versehen, sodass bekannte Adressen, 87

88 die mit der bisherigen Eingabe übereinstimmen, unter dem Eingabefeld angezeigt werden. Diese Funktion ist ebenfalls in Abbildung 48c zu sehen Kommentare Am rechten Rand der Fußzeile in der Meetingansicht befindet sich der Kommentare-Button, welcher auch die Anzahl der Kommentare anzeigt. Dieser Button und das dazugehörige Pop-Up sind in Abbildung 49 zu sehen. Die Kommentare werden hier aufgelistet. Neben dem Autor, einer Zeitangabe und dem Kommentar selbst finden sich zu jedem Kommentar zwei Buttons zum Editieren und Löschen des Kommentars, sofern der Benutzer die erforderlichen Rechte dazu hat. In der Kopfzeile befindet sich ein Button, über den ein neuer Kommentar geschrieben werden kann. Abbildung 49: Dialogbeispiele, Kommentare 88

89 5.3.8 Planung abschließen Sobald ein oder mehrere Terminvorschläge als endgültig markiert wurden, wird der Button Abschließen aktiv. Über diesen Button wird das Pop-Up zum Abschließen der Terminplanung aufgerufen (Abb. 50). Der Benutzer kann darin die als endgültig markierten Termine per an alle Teilnehmer versenden. Außerdem kann er dieser eine Nachricht und einen Ort beifügen. Optional kann diese auch als Kommentar eingetragen werden. Abbildung 50: Dialogbeispiele, Planung abschließen Hochformat Das Verhalten der Meetingansicht im Hochformat soll an dieser Stelle kurz dargestellt werden. Die Abbildung 51 zeigt die Wochenansicht im Hochformat. Die Quick-Vote-List ist in diesem Zustand nicht zu sehen. Stattdessen nimmt die Wochenansicht nun den restlichen Platz des Displays ein, weshalb der Benutzer nun einen größeren Ausschnitt eines jeden Tages sehen kann. Die Tagesansicht und die Monatsansicht verhalten sich analog zur Wochenansicht. 89

90 Abbildung 51: Dialogbeispiele, Wochenansicht im Hochformat 90

91 6 Evaluation Im Anschluss an die Realisierung wurde eine summative Evaluation durchgeführt. Diese summative Evaluation bildet den Abschluss der in Kapitel 1.3 beschriebenen Vorgehensweise während des Entwicklungsprozesses. Die Evaluation bestand aus zwei Teilen. Zum einen wurde ein Gebrauchstauglichkeitstest durchgeführt, zum anderen wurde noch einmal das Gespräch mit den Testpersonen gesucht, um Hinweise und Meinungen aufzunehmen, die im Gebrauchstauglichkeitstest nicht zu Tage gefördert wurden. 6.1 Ziele Die Evaluation soll zeigen, ob und in welchem Maße TeaCo ipad gebrauchstauglich für den Benutzer ist. Da sich die Gebrauchstauglichkeit nach der DIN EN ISO (1998) durch die drei Kriterien Effektivität, Effizienz und Benutzerzufriedenheit beschreiben lässt, soll TeaCo ipad auch hinsichtlich dieser drei Kriterien untersucht und bewertet werden, um dann eine Aussage über die Gebrauchstauglichkeit treffen zu können. Die drei aufgeführten Kriterien sollen im Folgenden kurz beschrieben sein. Effektivität Die Effektivität eines Anwendungsprogramms beschreibt, ob der Benutzer die Ziele, die er mit dem Anwendungsprogramm zu erreichen versucht, tatsächlich erreicht. So sollte ein Benutzer unabhängig von seiner Erfahrung mit TeaCo ipad erfolgreich an einer Terminplanung teilhaben können. Dies soll sowohl gelten, wenn der Benutzer zu einem Meeting eingeladen wird, als auch wenn er selbst als Initiator eines Meetings agiert. Effizienz Die Effizienz wird in der oben erwähnten Norm definiert als»der im Verhältnis zur Genauigkeit und Vollständigkeit eingesetzte Aufwand, mit dem Benutzer ein bestimmtes Ziel erreichen«. Diese Definition zeigt, dass des Benutzers Kenntnisstand bezüglich TeaCo Einfluss auf die Effizienz von TeaCo ipad hat. Dennoch sollte auch ein unerfahrener Nutzer 91

92 keinen allzu großen Aufwand betreiben müssen, da sich TeaCo vor allem durch Leichtgewichtigkeit auszeichnen will. Benutzerzufriedenheit Anders als die Effektivität und die Effizienz ist die Benutzerzufriedenheit kein Kriterium, welches sich anhand gemessener Werte bestimmen lässt. Um zu untersuchen, ob der Benutzer während und nach der Interaktion mit TeaCo ipad zufrieden gestellt wurde, bedarf es genauer Beobachtungen oder einem abschließenden Gespräch mit der Testperson. Am Grad der Gebrauchstauglichkeit von TeaCo ipad lässt sich dann ablesen, in wie weit bei der Wahl der Interaktionsmöglichkeiten und bei der Gestaltung der Benutzeroberfläche die richtigen Entscheidungen getroffen wurden. 6.2 Vorgehensweise Die Evaluation wurde mit insgesamt sechs Testpersonen durchgeführt. Dabei handelte es sich um die selben Personen, die auch schon an der Benutzeranalyse (Kapitel 2.2) teilgenommen haben. Die Evaluation wurde anhand eines zuvor erstellten Interviewleitfadens erstellt, welcher sich in Anhang C befindet. Die Evaluation mit jeder Testperson teilte sich in zwei Phasen. Zunächst wurden der Testperson Arbeitsaufträge erteilt, die dann mit TeaCo ipad bewältigt werden sollten. Diese Arbeitsaufträge deckten den Großteil der Funktionen von TeaCo ipad ab. Im Wesentlichen wurden die zwei gängigsten Arbeitsabläufe durchgespielt. Zum einen wurde die Testperson zu einem Meeting eingeladen und sollte darauf angemessen reagieren, zum anderen sollte die Testperson selbst als Initiator eines Meetings agieren. So wurde sichergestellt, dass die gewonnenen Erkenntnisse nicht nur einen Teil von TeaCo ipad betreffen, sondern für die gesamte Applikation repräsentativ sind. Die Testpersonen waren angehalten, während dieses Tests laut zu denken, um etwaige Schwierigkeiten und Hürden direkt aufzudecken. Durch diesen Teil der Evaluation sollten vor allem die Kriterien Effektivität und Effizienz untersucht werden. Daran anschließend wurde mit jeder Testperson das Gespräch gesucht, wobei die Testperson zunächst seine gewonnenen Eindrücke schildern sollte. Danach wurden der Testperson gezielte Fra- 92

93 gen zu Teilbereichen der Applikation gestellt, sofern die Testperson diese nicht schon aus eigenem Antrieb beantwortet hatte. Dieser Teil der Evaluation sollte Aufschluss über die Benutzerzufriedenheit geben. Außerdem hatte die Testperson die Möglichkeit darzulegen, an welchen Stellen sich die Applikation entgegen seiner Erwartungen verhalten hat. 6.3 Ergebnisse Da die Evaluation in zwei Phasen ablief, sollen die gewonnenen Erkenntnisse jeder Phase zunächst einzeln dargelegt werden, um im Anschluss daran diese Ergebnisse zu diskutieren. Die Abbildung 52 zeigt die Ergebnisse der ersten Phase. Die jeweiligen Ergebnisse der Testpersonen sind in sechs Spalten eingetragen. Dabei fallen vor allem die Zeilen 4 und 7 sowie die Spalte 5 negativ auf. Diese sind in der Abbildung 52 rot markiert. Zeile 4 der Abbildung zeigt, dass der überwiegende Teil der Testpersonen Probleme mit dem Abschließen eines Meetings hatte. Zum einen wurde der Button zum Abschließen eines Meetings nicht sofort gefunden, zum anderen waren sich die Testpersonen mangels Feedback nicht sicher, ob der Vorgang schließlich korrekt abgeschlossen war. Zeile 7 zeigt die Probleme beim Einladen der Teilnehmer auf. Konkret hatten die Testpersonen Probleme, den Vorgang weiterzuführen, nachdem diese die gefragten s-Adressen eingegeben hatten. Der Hinzu-Button (vgl. Abb. 48c), welcher zum Hinzufügen unbekannter - Adressen gedacht ist, wurde angetippt, obwohl der Weiter-Button rechts in der Kopfzeile den Vorgang fortgesetzt hätte. Die Testperson, die mit der Spalte 5 repräsentiert wird, hielt das ipad als einzige fortwährend hochkant. Die Ergebnisse belegen, dass die Applikation im Hochformat eine weitaus geringe Gebrauchstauglichkeit aufweist. Da die Quick-Vote-List im Hochformat nicht sichtbar ist, konnte die Testperson nicht alle Terminvorschläge wahrnehmen, weil diese an verschiedenen Tage lagen und die Testperson nur die Tagesansicht nutzte. Auch das Löschen von Terminvorschlägen ist ausschließlich mit der Quick-Vote-List möglich. Beim Erstellen von Terminvorschlägen erhielt die Testperson kein Feedback, da die Termine nicht am aktuell sichtbaren Tag waren. 93

94 Öffnen und Einloggen Meeting öffnen Abstimmen Abschließen /- +/- 5 Neues Meeting erstellen Terminvorschläge erstellen /- + 7 Teilnehmer einladen +/- +/- +/- + +/- +/- 8 Kommentar schreiben Terminvorschläge verschieben / Terminvorschläge löschen +/ Meetingtitel ändern Meeting löschen /- - Die Testperson hatte keine Probleme, das Ziel zu erreichen. Die Testperson hatte kurze Probleme, das Ziel zu erreichen. Die Testperson konnte das Ziel nicht erreichen. Abbildung 52: Ergebnisse der Evaluation, Phase I Des Weiteren wurde schon während dieser Phase der Wunsch nach einer Drag&Drop-Funktion zum Verschieben der Terminvorschläge deutlich. Der Großteil der Testpersonen versuchte das Verschieben zuerst auf diese Weise. Bis auf die oben genannten Ausnahmen konnten alle Aufgaben schnell und zielstrebig bewältigt werden. 94

95 Die in der zweiten Phase gewonnenen Erkenntnisse, die sich durch anschließendes Befragen der Testperson ergaben, soll im Folgenden aufgeführt werden. Alle Testpersonen äußerten sich vorwiegend positiv über die Applikation. Sowohl die Interaktionsmöglichkeiten als auch das äußere Erscheinungsbild gefielen allen Testpersonen. Ebenfalls äußerten alle Testpersonen während der Befragung den Wunsch nach einer Drag- &Drop-Funktion zum Erstellen und Verschieben von Terminvorschlägen. Fünf von sechs Testpersonen fanden das Zusammenspiel der vier Ansichten in der Meetingansicht als nützlich und erwartungskonform. Vier von sechs Testpersonen nahmen die Animation beim Wechsel des Zeitraums in der Tages-, Wochen- und Monatsansicht nicht richtig wahr, da diese zu kurz ist. Drei von sechs Testpersonen fehlte die Quick-Vote-List im Hochformat. Diese Personen würde die Quick-Vote-List gerne optional einblenden, auch wenn diese dann einen Teil der anderen Ansichten verdeckt. Drei von sechs Testpersonen wünschten sich einen Löschen-Button zusätzlich zur Swipeto-Delete-Funktion zum Löschen der Terminvorschläge. Weiter kamen vereinzelt Verbesserungsvorschläge zur Sprache, welche als weniger wichtig oder im Widerspruch zur Idee von TeaCo eingestuft wurden. Während der Evaluation erwies sich TeaCo ipad im Großteil der Situationen als gebrauchstauglich. Der Bereich, der sich am stärksten von TeaCo Desktop und TeaCo iphone unterscheidet, ist die Meetingansicht. Wo TeaCo Desktop und TeaCo iphone jeweils nur eine Darstellungsform für Terminvorschläge liefern, kann TeaCo ipad mit seinen vier verschiedenen Darstellungen dem Benutzer eine bessere Bedienbarkeit und Übersicht bieten. Es zeigt sich aber auch, dass gerade in der Meetingansicht weiterhin großes Entwicklungspotential gegeben ist. Die Drag&Drop-Funktion für Terminvorschläge und die optionale Quick-Vote-List im Hochformat waren zwar in der Konzeption geplant, wurden jedoch aus Zeitmangel nicht umgesetzt. Genau diese beiden Funktionen wurden während der Evaluation von den Testpersonen vermisst. Weiter wurden wenige kleine 95

96 Mängel deutlich, die jedoch im Anschluss an die Evaluation behoben werden konnten. Diese kleinen Details werden im folgenden Unterkapitel 6.4 beschrieben. 6.4 Anpassungen Die im Anschluss an die Evaluation vorgenommenen Anpassungen, sollen die Gebrauchstauglichkeit steigern und sind im Folgenden einzeln erläutert Meeting abschließen Beim Abschließen des Terminfindungsprozesses traten zwei Probleme auf. Zum einen wurde der Button zum Öffnen des Pop-Ups nicht gefunden. Abbildung 53a zeigt die Erscheinung des Abschließen-Buttons während der Evaluation. Die Abbildung 53b zeigt, dass die Position und Farbe des Buttons angepasst wurden. Er befindet sich nun ganz rechts. Diese Position ist erwartungskonform, da dieser Button am Ende des Terminfindungsprozesses benötigt wird. Außerdem ist der Button nun blau gefärbt, sofern mindestens ein Terminvorschlag als endgültig markiert wurde. Dies erhöht zum einen die Affordanz. Zum anderen wird der Button nun eher mit einem als endgültig markieren Terminvorschlag assoziiert, da diese ebenfalls blau gefärbt sind. (a) vorher (b) nachher Abbildung 53: Anpassung, Meeting abschließen Weiter war das Feedback nach dem Abschließen eines Meetings nicht ausreichend, weshalb sich einige Testpersonen nicht sicher waren, ob der Vorgang abgeschlossen wurde. Aus diesem Grund wird das Pop-Up zum Abschließen des Meetings nun geschlossen, nachdem der Vorgang abgeschlossen wurde. 96

97 6.4.2 Teilnehmer hinzufügen Um einen Teilnehmer zu einem Meeting hinzuzufügen gibt es zwei Möglichkeiten. Zum einen können unbekannte Teilnehmer über eine -Adresse eingeladen werden. Dazu wird die E- Mail-Adresse in ein Textfeld eingetragen und dann mit dem Button Hinzu bestätigt (vgl. Abb. 54a). Zum anderen kann ein Teilnehmer aus der Liste der bekannten -Adressen gewählt werden. Im Anschluss an die zweite Variante benutzen nahezu alle Testpersonen fälschlicherweise den Hinzu-Button statt des Weiter-Buttons. (a) vorher (b) nachher I (c) nachher II Abbildung 54: Anpassung, Teilnehmer hinzufügen 97

98 Die Abbildungen 54b und 54c zeigen, wie dieses Problem gelöst wurde. Solange noch keine gültige -Adresse im Textfeld steht, ist der Hinzu-Button nicht zu sehen. Sobald eine gültige E- Mail-Adresse im Textfeld steht, erscheint der Hinzu-Button innerhalb des Textfelds. So wird der Button noch stärker mit dem Textfeld assoziiert und ist nur sichtbar, wenn dieser gebraucht wird Terminvorschlag löschen Die Abbildung 55 zeigt die Anpassung, die am Detail-Pop-Up der Terminvorschläge vorgenommen wurde. Da einige Testpersonen die Swipe-to-Delete-Geste nicht kannten und viele Testpersonen sich diese zusätzliche Möglichkeit zum Löschen der Terminvorschläge wünschten, wurde ein Löschen-Button in das Detail-Pop-Up aufgenommen. So ist es nun auch im Hochformat möglich, Terminvorschläge zu löschen. (a) vorher (b) nachher Abbildung 55: Anpassung, Terminvorschlag löschen Tages-, Wochen-, Monatsansicht: Zeitraum wechseln Die Dauer der Animation beim Wechseln des Zeitraums in der Tages-, Wochen- und Monatsansicht wurde von 0,2 Sekunden auf 0,5 Sekunden verlängert, damit der Benutzer diese Animation als Feedback auf seine Interaktion besser wahrnehmen kann. 98