Konfigurationsmanagement mit fachlichen Nutzern als Zielgruppe für ein technisch komplexes System

(1)

Konfigurationsmanagement mit fachlichen Nutzern als Zielgruppe für ein technisch

komplexes System

Bachelorarbeit

von

Jonas Stock

03.11.2021

Technische Universität Kaiserslautern, Fachbereich Informatik,

67663 Kaiserslautern, Deutschland

(2)

Hiermit versichere ich, dass ich die von mir vorgelegte Arbeit mit dem The- ma „Konfigurationsmanagement mit fachlichen Nutzern als Zielgruppe für ein technisch komplexes System“ selbstständig verfasst habe, dass ich die verwendeten Quellen und Hilfsmittel vollständig angegeben habe und dass ich die Stellen der Arbeit - einschließlich Tabellen und Abbildungen -, die anderen Werken oder dem Internet im Wortlaut oder dem Sinn nach entnommen sind unter Angabe der Quelle als Entlehnung kenntlich gemacht habe.

Kaiserslautern, den 1.11.2021

Jonas Stock

(3)

Abstract

A configuration management software is implemented and presented, which should support the development of a system with increasing complexity using the example of Game of TUK. For Game of TUK, a large amount of different data is required annually. These fi- les are created by several employees. In this work, the requirements for the software are worked out, so that the usability for the known target group can be opti- mized. Additionally, the requirements serve to evaluate the software. It was found that a good usability can be achieved more easily if the target group is small and known. With such a target group, the software can be precisely adapted to the requirements of the users. If the target group is very large or unknown, more usability restrictions need to be implemented to accommodate the requirements of a wide variety of user types. Fur- thermore, when developing such software, it should be taken into account that the target group is alterable, which means that the usability can also downgrade, de- pending on the change of the target group.

With the implemented software, the development of Game of TUK is significantly improved. The employees can use the program to independently create the necessary data in the correct format. For this they receive appropriate help and restrictions within the software.

However, if the target group changes, the usability may downgrade (for example, there is no good support for visually impaired people). The software was developed in such a way that adaptations and extensions can be implemented by Game of TUK programmers without much effort. However, in order to use the software to its full extent, an adjustment to the Game of TUK server is still necessary so that the output file can be read completely.

(4)

Es wird eine Konfigurationsmanagementsoftware implementiert und vorgestellt, die am Beispiel von Game of TUK die Entwicklung eines immer komplexer wer- denden Systems unterstützt. Bei Game of TUK werden im jährlichen Zyklus eine Vielzahl von verschiedensten Daten benötigt, die mehrere Mitarbeiter erstellen.

Anforderungen an die Software wurden erarbeitet, damit die Nutzbarkeit für die bekannte Zielgruppe opti- miert werden konnte. Zusätzlich dienen die Anforde- rungen der Bewertung der Software. Es wurde festgestellt, dass eine gute Nutzbarkeit leichter zu erreichen ist, wenn die Zielgruppe klein und bekannt ist. Bei einer solchen Zielgruppe kann die Software genauestens auf die Anforderungen der Nutzer angepasst werden.

Ist die Zielgruppe sehr groß oder unbekannt, müssen Abstriche in der Nutzbarkeit gemacht werden, um die Anforderungen verschiedenster Nutzertypen zu berück- sichtigen. Des Weiteren sollte bei der Entwicklung einer solchen Software beachtet werden, dass die Zielgruppe veränderbar ist, wodurch sich die Nutzbarkeit, je nach Änderung der Zielgruppe, auch verschlechtern kann.

Mit der Software wird die Entwicklung von Game of TUK deutlich verbessert. Die Mitarbeiter können das Programm nutzen, um selbstständig die nötigen Da- ten im korrekten Format zu erstellen. Hierfür erhalten sie entsprechende Hilfe und Einschränkungen innerhalb der Software. Sollte sich die Zielgruppe jedoch ändern, kann sich die Nutzbarkeit verschlechtern (zum Beispiel fehlt eine gute Unterstützung für Sehbeein- trächtigte). Die Software wurde so entwickelt, dass Ga- me of TUK Programmierer ohne großen Aufwand An- passungen und Erweiterungen implementieren können.

Um die Software im vollen Umfang zu nutzen, ist jedoch noch eine Anpassung am Game of TUK Server nötig, damit die Ausgabedatei vollständig gelesen werden kann.

(5)

Inhaltsverzeichnis

Abbildungsverzeichnis vii

1 Einleitung 1

1.1 Ergebnisse . . . 2

1.2 Verwandte Arbeiten . . . 2

1.3 Struktur der Arbeit . . . 3

2 Grundlagen 5 2.1 Problem . . . 6

2.1.1 Game of TUK Configtool Anforderungen . . . 7

2.2 Ziele des Konfigurationsmanagement . . . 7

2.3 User Interface . . . 9

2.4 Desktop-App vs. Web-App . . . 14

2.4.1 Desktop-App . . . 15

2.4.2 Web-App . . . 15

2.5 Game of TUK . . . 17

2.5.1 Entwicklung . . . 17

2.5.2 Ablauf . . . 17

2.5.3 Spielebenen . . . 18

2.5.4 Spiele . . . 19

3 Configtool von Game of TUK 25 3.1 Design . . . 25

3.2 Navigation . . . 26

3.3 Home . . . 27

3.4 Quiz . . . 28

3.5 Donkeyrace . . . 32

3.6 Coin Collector . . . 33

3.6.1 Coins . . . 33

3.6.2 Running Coins . . . 34

3.6.3 Super Coins . . . 36

3.6.4 Days . . . 36

3.7 Mr. Z . . . 37

3.8 Paper Chase . . . 38

3.9 Fitness Courses . . . 40

3.10 Import / Export . . . 40

4 Ergebnisse 41 4.1 Konfigurationsmanagement . . . 44

4.2 Ausblick . . . 44

(6)

5 Fazit 47

Literatur 49

(7)

Abbildungsverzeichnis

2.1 Angepasste Anzeige aller Spielebenen in der Game of TUK App. 18 2.2 Ein laufendes Quiz Spiel. . . 20 2.3 Ein laufendes Eselrennen. . . 21 3.1 Die Tableiste des Game of TUK Configtools mit dem Hometab

ausgewählt . . . 26 3.2 Home: Pop-up zur Auswahl der Spieltage der kompletten Spiel-

runde . . . 27 3.3 Home: Beispielbilder in der Galerie sowie die Verwendung des

Editors. . . 28 3.4 Quiz: Pop-up Fenster zum Erstellen einer neuen Quizfrage . . . 29 3.5 Quiz: Beispiel Tags mit unterschiedlichen Zuständen . . . 30 3.6 Quiz: Anzeigeliste mit Konfliktfragen . . . 31 3.7 Quiz: Pop-up zum Lösen eines Datenkonflikts innerhalb einer

Frage, welche aus mehreren Quellen hinzugefügt wurde. . . 32 3.8 Donkeyrace: Alle Einstellungen des Donkeyrace Tabs. . . 33 3.9 Coin Collector: Running Coin Modus mit Beispiel Pfad. . . 35 3.10 Coin Collector: Vergleich zwischen Fading- und Edit-Mode. . . 35 3.11 Coin Collector: Days Modus mit Beispiel Tagen und Warnungen.

Datepicker mit veränderter Anzeige ist geöffnet. . . 37 3.12 Paper Chase: Rätselansicht mit Beispiel Rätsel. . . 38 3.13 Paper Chase: Kartenansicht mit Beispiel Rätsel. . . 39 4.1 Darstellung der Farben bei UI-Elementen für verschiedene Zwecke 43

(8)

(9)

1 Einleitung

Eine gute Handhabung aller Einstellungen einer Software zu gewährleisten, wird mit zunehmender Größe des Projekts immer schwerer. Neue Module werden implementiert, bereits vorhandene Module werden verbessert und das Pro- jekt erhält immer mehr Einstellungsmöglichkeiten. Die Komplexität nimmt weiter zu und die Übersichtlichkeit sinkt. Dies ist auch bei der Entwicklung der Game of TUK Smartphone App der Technischen Universität Kaiserslau- terns zu beobachten. Game of TUK ist ein bewegungsförderndes Spiel, welches üblicherweise jährlich im Sommersemester an der TUK stattfindet. In verschiedenen Spielen können die Teilnehmer mithilfe der App Punkte sammeln, um zu gewinnen.

Durch den jährlichen Zyklus der Spielrunden müssen alle Daten, die für die verschiedenen Spiele und weitere Aspekte der App wie zum Beispiel Willkom- menstexte beinhalten, regelmäßig aktualisiert werden. Die Daten können kleine Werte umfassen, die selten geändert werden aber auch große Datensätze, welche immer neu erstellt werden müssen. Die meisten Daten benötigen aufgrund ihres Inhaltes unterschiedliche Formate, weswegen mit einer Vielzahl von Da- teien gearbeitet wird. Zusätzlich müssen für alle Formate Bedingungen festgelegt werden, um deren Nutzbarkeit zu gewährleisten. Die Dateien werden von mehreren Mitarbeitern der Universität, teilweise ohne IT-Ausbildung, erstellt und an die Game of TUK Entwickler weitergeleitet. Durch die verschiedenen Dateien, Formate, Bedingungen für diese, sowie die Anzahl der Mitarbeiter, ist diese Vorgehensweise der Konfiguration der benötigten Daten sehr fehler- anfällig, wodurch meist eine zusätzliche Kontrolle und Korrektur aller Daten notwendig ist.

Diese Arbeit soll dazu beitragen, die Erstellung der Daten welche für Game of TUK benötigt werden zu verbessern, um den Arbeitsaufwand aller Beteiligten und die Fehleranfälligkeit zu verringern. Hierfür wurde eine Konfigurationsma- nagementsoftware [Sto21] implementiert, mit der die Mitarbeiter einheitlich arbeiten können, um alle benötigten Daten zu erstellen. Fehlerhafte Eingaben werden mit entsprechenden Hilfestellungen vermieden. So wird eine Datei aus- gegeben werden, die der Game of TUK Server ohne zusätzliche Korrekturen akzeptiert.

Dadurch können alle Mitarbeiter selbstständig, durch die entsprechende Hilfe und Oberfläche des Programms, die Daten erstellen. Des Weiteren müssen sich die Nutzer nicht mit verschiedenen Dateien und deren Anforderungen für die Korrektheit beschäftigen, da das Programm dies automatisch im Hintergrund erledigen kann.

(10)

1.1 Ergebnisse

Um die steigende Anzahl an Konfigurationsmöglichkeiten eines wachsenden Softwaresystems übersichtlich zu halten, wurde ein Programm implementiert, mit der das aktuelle Problem in der Entwicklung von Game of TUK angegangen wird. Da die Zielgruppe bekannt und klein ist, konnte präzise auf die nötigen Elemente eingegangen werden, um eine gute Nutzbarkeit zu erreichen. Gleich- zeitig wurde festgestellt, dass eine UI gezielt für eine bestimmte Zielgruppe zu entwickeln eines der größten Probleme der User-Interfaces-Entwicklung ist. Je größer und vielfältiger die Zielgruppe ist, desto allgemeiner müssen Funktio- nen zur Verfügung stehen. Das UI muss flexibel und anpassbar sein, um alle Bedürfnisse der verschiedensten Nutzer zu erfüllen.

So ist es zwar von großem Vorteil, wenn die Zielgruppe bekannt ist und genauestens auf deren Anforderungen eingegangen werden kann, jedoch kann es zu größeren Problemen kommen, sollte sich die Zielgruppe ändern.

1.2 Verwandte Arbeiten

Es gibt bereits mehrere Ansätze um Probleme des Konfigurationsmanage- ments, der Einfachheit sowie der Qualität einer Software anzugehen. Die Grund- lagen dieser Arbeit beziehen sich auf einige solcher Ansätze. So bietet zum Beispiel Grandes „100 Minuten für Konfigurationsmanagement“ einen entsprechenden Ausgangspunkt für Konfigurationsmanagement [Gra12]. Das Buch soll die Entwicklung von hochwertigen Produkten, für die entsprechende Kennt- nisse verschiedenster Bereiche nötig sind, unterstützen, indem es Wissen des Bereichs Konfigurationsmanagements vermittelt. Um Ziele für die entwickelte Software zu formulieren, wurden Grandes Ziele genutzt und für dieses Pro- jekt angepasst. Grandes Auslegung baut auf eine andere Projektstruktur auf, weshalb die Anpassungen für die Game of TUK Entwicklung nötig waren.

Die Nielsen Norman Group (NN/g) hat sich viel mit der Nutzbarkeit von Software auseinander gesetzt. Ergänzend zu den älteren Arbeiten der NN/g wurden die moderneren „Design-Prinzipien Reloaded“ [Bru18] von Eva Brum- me hinzugezogen, die auf Arbeiten der NN/g basieren. Diese 13 hier vorgestellten Prinzipien wurden zusammen mit dem Zeiss Usability-Team bei der Entwicklung des Custom Usability Index erarbeitet, damit der Erreichungs- grad der Nutzbarkeit einer Software gemessen werden kann [Sch17]. Der In- dex ist für die hier vorgestellte Arbeit im Vergleich zu den Prinzipien weniger hilfreich, da spezielle Usability Testmethoden erforderlich sind, um diesen zu messen. Zusätzlich müssen die Methoden regelmäßig am Teilprodukt durch- geführt werden. Entwickler haben dadurch, vor allem bei größeren Projekten mit mehreren Meilensteinen und Teilprodukten, den Vorteil, die gewünschte Qualität und deren Fortschritt zu jedem Zeitpunkt einsehen zu können. Mit den Prinzipien konnten jedoch Designentscheidungen in der Entwicklung der Konfigurationsmanagementsoftware begründet und die Nutzbarkeit bewertet werden.

Eine weitere wichtige Grundlage bieten die von John Maeda erarbeiteten

(11)

1.3 Struktur der Arbeit

„Laws of Simplicity“ [Mae06], die ebenfalls die Entwicklung der Software un- terstützen, um die Komplexität so gering wie möglich zu halten.

Mit den von Leonard Koch dargestellten „wichtigsten Vor- und Nachteile von Desktop- und Web-Apps“ [Koc21] konnte eine gezielte Entscheidung für das Projekt getroffen werden, dieses als Web-App zu implementieren.

Die Inhalte dieser Arbeiten, die die Entwicklung der Software beeinflussen, sind ebenfalls in „ISO 25010 - Qualität von Software“ [ISO11] enthalten, dort jedoch in weniger ausführlicher Form, da die ISO noch weitere Elemente um- fasst. Die vorher genannten Arbeiten gehen gezielter auf die Anforderungen der gewünschten Software ein, wodurch diese als Grundlage gewählt wurden.

Zuletzt wurde die Game of TUK App sowie deren Webseiten genutzt, um den Zusammenhang mit dieser Arbeit zu verdeutlichen.

1.3 Struktur der Arbeit

In dieser Arbeit wird eine Software vorgestellt, die die Entwicklung von Game of TUK unterstützen soll, indem das beschriebene Problem behandelt wird.

Im zweiten Kapitel „Grundlagen“ werden Anforderungen festgelegt und benö- tigte Zusammenhänge erläutert. Des Weiteren werden die nötigen Konfigura- tionselemente aus Game of TUK dargestellt. Die technische Beschreibung des Programms sowie Softwaredesignentscheidungen, die mit Hilfe der Grundla- gen getroffen wurden, sind im dritten Kapitel aufgeführt. Nachfolgend wird im vierten Kapitel „Ergebnisse“ die Software bewertet und mögliche weiterfüh- rende Arbeiten werden vorgestellt. Im fünften und letzten Kapitel schließt das Fazit die Arbeit ab.

(12)

(13)

2 Grundlagen

Um den Fokus für das Konfigurationsmanagement-Tool korrekt zu legen, ist eine genauere Beschreibung der Problemstellung und Anforderungen unerläss- lich. Bei der bisherigen Vorgehensweise wurde zuerst, meist einige Wochen vor Beginn der Spielzeit, festgelegt, welche Daten benötigt werden und welche Einstellungen gewünscht sind. Die Bereitstellung der benötigten Daten erfolgt von mehreren Mitarbeitern. Alle Daten werden dann an die Programmierer weitergegeben, die sie in den Server einpflegen. Der Server benötigte mehrere Dateien wie zum Beispiel die verschiedenen Bilder, ein Quizfragenkatalog oder eine Datei mit dem Graphen für das Mr. Z Spiel.

Die Schwierigkeit, die sich aus dieser Vorgehensweise ergibt, ist die unein- heitliche Nutzung verschiedenster Programme mit denen die Dateien erstellt werden. Mitarbeiter erstellen die Daten eigenständig an verschiedenen Endge- räten, wie private Computer, Laptops oder Universitätsrechner und verwen- den hierfür eine Vielzahl von Programmen. Somit erhalten die Programmierer sogar einfache Dateien wie Texte durch die unterschiedlichen Programme und Betriebssysteme in verschiedenen Formaten. Dadurch können die Dateien nicht einfach in den Server geladen werden, sondern es entsteht ein weiterer Schritt in diesem Prozess, in dem die Programmierer die Dateien weiterverarbeiten müssen, um die Korrektheit dieser zu versichern.

Dieser Schritt wird dadurch erschwert, dass die Dateien fehlerfrei sein müs- sen, damit sie vom Server akzeptiert werden. Hierfür müssen bestimmte Kon- ventionen eingehalten werden, die für Mitarbeiter ohne technische Ausbildung nur schwer umsetzbar sind. Infolge dessen benötigt es eine gute Kommunikation zwischen Teamleitern, Mitarbeitern und Programmierern, damit der Aufwand so gering wie möglich gehalten wird. Erst wenn sich alle Dateien im entsprechenden Format befinden und auf Fehler kontrolliert wurden, können diese in den Server eingepflegt werden. Die Formate, der jeweiligen Syntax, die Frei- heiten und die Einschränkungen müssen mit den Mitarbeitern, die über die unterschiedlichsten IT-Kenntnissen verfügen, einwandfrei kommuniziert werden. Hierbei ein perfektes Ergebnis zu erzielen ist nahezu unmöglich.

Durch die Nutzung einer Konfigurationsmanagementsoftware können alle Mitarbeiter mit einer einheitlichen Software arbeiten. Diese kann die Anwen- der beschränken und nötige Hilfestellungen geben, damit die benötigten Daten von allen Mitarbeitern einfach und korrekt erstellt werden können. Die Softwa- re soll alle Daten automatisch konvertieren und in einer Konfigurationsdatei vereinigen, ohne dass die Nutzer hierfür Einstellungen tätigen müssen. Um einen weiteren Arbeitsschritt zu sparen, soll die Datei nicht wie die einzelnen Daten davor zusätzlich händisch kontrolliert werden müssen.

Mitarbeiter hätten dadurch den Vorteil, dass sie Probleme durch Hilfe in-

(14)

nerhalb der Software selbst lösen können und nicht auf die Hilfe anderer Mit- arbeiter angewiesen sind. Zusätzlich kann eine solche Software die Wiederver- wendbarkeit alter Daten deutlich verbessern, da es im Optimalfall nur eine Outputdatei gibt, welche leicht geteilt werden kann.

Die Software muss ein entsprechendes User-Interface (UI) besitzen, um die Arbeit der Game of TUK Mitarbeiter zu vereinfachen. Indem die Nutzer der Software gezielt geleitet werden, sollen sie die Arbeit leichter bewältigen kön- nen. Hierfür müssen nötige Hinweise und helfende Fehlermeldungen integriert sein. Des Weiteren muss die Software für alle leicht zugänglich und auf den nötigen Endgeräten voll funktionsfähig sein. Die Ausgabe sollte in einem For- mat erfolgen, welches der Server akzeptiert. Nutzer müssen entsprechend ein- geschränkt werden, sodass die Ausgabe in jedem Fall gültig ist. Um die Wie- derverwendbarkeit alter Daten zu gewährleisten, müssen alte Konfigurationen einsehbar sein. Da mit der Weiterentwicklung von Game of TUK weitere und abgeänderte Daten benötigt werden, soll die Software leicht zu warten, anpassbar und erweiterbar sein.

Basierend auf den Ergebnissen dieser Überlegungen lässt sich eine Software designen, die die Arbeit an Game of TUK nachhaltig erleichtert. Zunächst wird daher noch einmal verdeutlicht, welche Aspekte maßgeblich verbessert werden sollen.

2.1 Problem

Game of TUK ist ein komplexes System, welches auf Daten basiert, die von Mitarbeitern bereitgestellt werden. Es gibt sehr viele unterschiedliche Typen dieser Daten und viele Anforderungen an jeden Typ. Diese Daten müssen von Mitarbeitern erstellt werden, die oftmals keinen Zugang zum Servercode haben, geschweige denn ausgebildet sind diesen zu verstehen. Somit sind alle Mitar- beiter auf die Kommunikation mit den Programmierern angewiesen und alle Anforderungen an alle Daten müssen genauestens geklärt sein. Erschwerend kommt hinzu, dass es keine einheitlichen Programme gibt, die auf allen End- geräten aller Mitarbeiter benutzt werden, um die Daten zu erstellen, wodurch es zu Kompatibilitätsproblemen kommen kann. So gibt es zum Beispiel sogar Unterschiede bei einfachen Textdateien am Ende jeder Zeile, wenn diese auf einem Linux-PC oder Windows-PC erstellt wurden. Oftmals ist es auch nötig alte, bereits verwendete Game of TUK Konfigurationen einzusehen und diese mit kleinen Anpassungen wiederzuverwenden. Dies ist durch die Menge an verschiedenen Dateien und Dateiformaten kein geringer Aufwand, da die verschiedenen Dateien teilweise direkt an die Programmierer weitergeleitet und direkt in den Servercode eingebunden wurden.

Dies so gut zu kommunizieren, damit sich eine effiziente und lohnende Ar- beitsteilung ergeben kann, ist kompliziert und endet üblicherweise in einem Mehraufwand für alle Beteiligten. Eine Software die die verschiedenen Konfi- gurationen von Game of TUK verwaltet, könnte viel Arbeit erleichtern, jedoch muss diese einige Anforderungen erfüllen.

(15)

2.2 Ziele des Konfigurationsmanagement

2.1.1 Game of TUK Configtool Anforderungen

Software für Konfigurationsmanagement, im weiteren auch als „KM“ bezeichnet, kann je nach Projekt, Projektstruktur und Ressourcen verschiedene Anfor- derungen haben und unterschiedliche Gewichtungen bezüglich Verfügbarkeit, Erweiterbarkeit, Einfachheit, Design, Nutzbarkeit und weiteren Eigenschaften besitzen. Deswegen sollten die Anforderungen gezielt auf das jeweilige Projekt angepasst sein.

Unter Verfügbarkeit versteht man, wie gut die Software zugänglich ist und welcher Aufwand vom Anwender nötig ist, diese zu benutzen. Das Tool sollte sehr einfach verfügbar sein, es sollte keine komplizierten Installationen benö- tigen und wenige Abhängigkeiten von anderer Software besitzen. Es sollte auf Endgeräten mit unterschiedlichen Betriebssystemen im vollen Umfang genutzt werden können.

Die Software muss leicht erweiterbar sein, da sich Game of TUK immer weiterentwickelt und je nach Entwicklung mehr, weniger oder geänderte Daten benötigt werden. Game of TUK Entwicklern sollte es gut möglich sein, das Configtool weiterzuentwickeln.

Einfachheit wird oftmals im Zusammenhang des Gegenbegriffs „Komplexi- tät“ betrachtet. Um eine Software einfach zu halten, sollte die Komplexität gering gehalten werden [Kle14]. Diese Konfigurationsmanagementsoftware soll einfach zu bedienen sein und keine großen Einweisungen benötigen, sodass Mitarbeiter mit unterschiedlichsten IT-Kenntnissen sie nutzen können.

Ebenfalls wichtig ist, dass das Design sowohl logisch und verständlich als auch ansprechend ist. Hiermit wird gewährleistet, dass es den Nutzer nicht in seiner Arbeit behindert, sondern unterstützt. Die Optik ist in diesem Projekt jedoch nicht sehr stark zu gewichten.

Eine gute Nutzbarkeit hat zufolge, dass ein Nutzer eine Software gut und intuitiv benutzen kann, damit das Ziel der Software effizient erreicht wird [Loh11]. Die Nutzbarkeit resultiert unter anderem aus der Einfachheit und dem Design, und sollte bei diesem Projekt sehr stark gewichtet werden. Es soll vor allem darauf abzielen, dass jeder seine Aufgaben gut und schnell erledigen kann.

Zuletzt muss die Konfiguration, welche die Software liefert, in einem Format erfolgen, das vom Server gelesen werden kann und die Ziele des Konfigurati- onsmanagements erfüllt.

2.2 Ziele des Konfigurationsmanagement

Diese Arbeit bezieht sich auf die Definitionen von Marcus Grande aus dem Buch „100 Minuten für Konfigurationsmanagement“ [Gra12]. Eine Konfigura- tion ist die Gesamtheit aller Konfigurationselemente. Als Konfigurationsele- mente werden Objekte bezeichnet, die verändert werden können, jedoch zu jedem Zeitpunkt die benötigten Eigenschaften besitzen. Zudem behalten die Objekte nicht nur selbst ihre nötigen Eigenschaften, sondern auch die nötigen Beziehungen zu anderen Objekten bleiben bestehen.

(16)

Es wird sich auf drei der sechs von Grande vorgestellten Ziele für KM be- schränkt, da andere Elemente des KMs durch die hier gegebene Projektstruk- tur auf andere Art und Weise gelöst oder im geringeren Maße benötigt werden.

So gibt es zum Beispiel in diesem Projekt keinen einzelnen Konfigurationsma- nager, welcher KM-Pläne erstellt, Präsentationen vorbereitet und notwendige Werkzeugunterstützung definiert und das Bearbeiten der Konfigurationsele- mente soll stärker im Vordergrund stehen. Die für Game of TUK relevanten Ziele des Konfigurationsmanagementes werden nachfolgend dargestellt[Gra12]:

1. Gewährleistung der Integrität

Die Daten und Einstellungen sollen bei jeder Konfiguration korrekt, voll- ständig und konsistent sein. Das bedeutet, dass die Nutzer der Softwa- re nur gültige Eingaben tätigen können und hierfür entsprechende Ein- schränkungen sowie Hilfestellungen erhalten.

2. Wiederherstellbarkeit früherer Konfigurationen

Nutzern soll es möglich sein, bereits verwendete Konfigurationen zu laden, um diese erneut nutzen zu können. Hiermit kann man Spielrunden mit Konfigurationen testen und sie dann mit eventuellen Änderungen wiederverwenden.

3. Leichte Einsehbarkeit von Inhalten und Unterschieden verschiedener Konfigurationen

Fertige Konfigurationen sollen jederzeit wieder geladen und eingesehen werden können. Um zu gewährleisten, dass diese auch leicht einsehbar sind, soll das Programm mit sehr geringen Anforderungen im vollen Um- fang verfügbar sein, damit es auf einer Vielzahl von Endgeräten nutzbar ist. Des Weiteren sollten gleiche Einstellungen auch die gleichen Konfigu- rationen ergeben, wodurch Unterschiede mithilfe von simplen Difference- Checkern leicht auffindbar sind. Da es Difference-Checker bereits mehrfach und auch online gut zugänglich gibt, ist die Implementierung eines solchen Diff-Tools kein nötiges Feature der Software und somit kein Teil dieser Arbeit.

Für die hier vorgestellte Software weniger relevant, jedoch allgemein ebenfalls wichtige Ziele sind:

1. Verfolgbare Änderungen

Die Beschriftung von Änderungen mit Zeitstempel und Name des Nut- zers, welcher die Änderung getätigt hat, ist in diesem Projekt nicht nötig.

Die Anzahl der Mitarbeiter ist überschaubar und durch die flache Hier- archie innerhalb des Projekts ist die Nachverfolgung von bestimmten Änderungen auf gezielte Mitarbeiter aktuell nicht notwendig.

2. Einhalten des Budgets

Die Kostenverwaltung des Projekts ist keine Aufgabe des Entwickler- teams und für dieses nicht einsehbar. In dem Bereich, in dem das Konfi- gurationsmanagementtool genutzt werden soll, ist dieses Ziel nicht relevant.

(17)

2.3 User Interface

3. Einhalten des Zeitplans

Das Zeitmanagement wird bereits innerhalb des Entwicklerteams selbst betrieben und ist somit nicht wichtig für die Konfigurationsmanagement- software.

Nachdem gezeigt wurde, welche Ziele für das Konfigurationsmanagement- Tool für Game of TUK relevant sind, werden im folgenden weitere Aspekte der Anforderungen erläutert, die für die Entwicklung der Software von großer Bedeutung sind.

2.3 User Interface

Das User-Interface (UI) ist eine Schnittstelle zwischen dem Nutzer und der Software, die es dem Nutzer ermöglicht die Funktionen der Software zu verwen- den. Es gibt verschiedene Arten von UIs: Nutzer können mithilfe von Sprach- befehlen, die immer populärer werden, Smarthome Produkte über ein Voice- controlled User Interface (VUI) steuern, anhand von Körperbewegungen Spiele in einer virtuellen Welt durch mehrere Sensoren und einem Gesture-based In- terface spielen oder an einem Computer alle möglichen Arten von Software durch ein Graphical User Interface (GUI) bedienen. Da sich diese Arbeit mit einer Software beschäftigt, welche nur an Computern bedient werden soll, wird sich auf ein Graphical User Interface beschränkt [Des]. Bei einer GUI sind die Funktionen und Ergebnisse grafisch dargestellt, sodass die Nutzer nicht die Komplexität der Software verstehen müssen, um diese zu bedienen. Ziel ist es, die Nutzung so einfach wie möglich zu gestalten, jedoch auch die nötige Funktionalität zu gewährleisten.

Design und Usability sind bei einem GUI nur schwer getrennt voneinander zu betrachten. Viele Designentscheidungen, die getroffen werden, um das Produkt optisch ansprechender zu machen, vermitteln gleichzeitig auch eine verbesserte Nutzbarkeit und umgekehrt. Vor allem bei einem GUI wird daher oft beides im Zusammenhang betrachtet. Um das beschriebene Ziel eines GUIs zu erreichen, wurde von vielen versucht, Richtlinien festzulegen, die dies be- günstigen. So haben zum Beispiel die Softwareunternehmen Google [Goo21b]

und Apple [App21] jeweils ihre eigenen Design-Richtlinien, um die große An- zahl an Nutzern für die unterschiedlichsten Aufgaben an einem Smartphone anzusprechen. Die Richtlinien beziehen sich vor allem auf das Layout und auf die Optik des Interfaces, dienen aber auch gleichzeitig der Nutzbarkeit, da diese Eigenschaften stark miteinander zusammenhängen [Gor20].

Apples Flat Design

Apple nutzt ein Flat Design, das versucht, durch eine sehr geringe Tie- fe den Nutzer auf das Wesentliche zu fokussieren. Das bedeutet, Icons und Illustrationen sind sehr einfach gehalten, wodurch sich dem Nutzer ihre Bedeutung besser erschließt. Es existieren sehr wenige Bildebenen, sodass alle nötigen Informationen sehr schlicht und gleichzeitig auf einem Bildschirm dargestellt werden können. Üblicherweise werden keine

(18)

Style-Elemente wie zum Beispiel Schattierungen, Farbverläufe und auf- wändige Texturen verwendet. Die Nutzer sollen dadurch nicht abgelenkt werden und wegen der geringen Tiefe keine Schwierigkeiten haben durch die Oberflächen zu navigieren [Lai17].

Googles Material Design

Google hingegen baut auf ein Design, das optisch sehr flach aussieht, jedoch eine größere Tiefe besitzt. So werden Style-Elemente wie Schat- tierungen, mehrere Ebenen oder Animationen im Material Design häufig genutzt, womit es eine sehr große Flexibilität für Designer besitzt. Gleich- zeitig ist es sehr intuitiv zu benutzen, da die Nutzer direkt mit den UI- Elementen interagieren können und dies durch entsprechendes optisches Feedback gut dargestellt wird. Durch die sich voneinander abhebenden Elemente, können die Nutzer schnell erkennen, mit welchen Elementen sie interagieren können und sollen. Hiermit wird die Navigation deutlich offensichtlicher [Lai17].

In diesen Designs, sowie in vielen anderen, finden sich Grundzüge der sogenannten „Laws of Simplicity“ [Mae06] wieder. Diese Gesetze sind unabhängig voneinander, können jedoch auch in Kombinationen genutzt werden. Davon werden die ersten drei als „basic simplicity“ beschrieben, wohingegen die nach- folgenden eine tiefere Bedeutung haben. Die Gesetze können beim Erstellen eines GUI genutzt werden um Ordnung zu schaffen, sodass die Nutzer nicht überfordert werden und die Software optisch ansprechend ist. Des Weiteren sollen diese die Nutzbarkeit des Programms steigern um einen guten „Workflow“

zu gewährleisten. Zu den Laws of Simplicity gehören [Mae06]:

1. Reduce / Reduktion

Der beste Weg etwas zu vereinfachen erfolgt durch Reduktion des Um- fangs. Jedoch sollte nichts entfernt werden, was benötigt wird. Dies gilt für Funktionalität, sowie Designelemente. Ein System soll nur weiter re- duziert werden, wenn dieses nicht zu stark darunter leidet. Wenn das System hierdurch weniger gut nutzbar ist, sollte man das Gesetz nicht weiter anwenden.

2. Organize / Organisieren

Die Gruppierung von Objekten lässt eine große Anzahl dieser geringer erscheinen. Der Zugriff auf Objekte wird erleichtert, wenn diese in passende Kategorien geordnet wurden, da es die Zeit ein Objekt zu finden verkürzt. Jedoch können hierdurch auch Probleme entstehen, wenn zum Beispiel Kategorien schlecht gewählt, oder Objekte nicht gut eingeteilt wurden. Zusätzlich stellt sich die Frage, ab wann eine Einteilung nötig ist und ob eventuell nur ein Teil der Objekte gruppiert werden sollte.

3. Time / Zeit

Lange Wartezeiten, zum Beispiel beim Laden von Objekten, werden als unangenehm empfunden. Deshalb sollten Ladezeiten so gering und Re- aktionsgeschwindigkeiten von Objekten, mit denen die Nutzer agieren

(19)

2.3 User Interface

so hoch wie möglich gehalten werden. Die Nutzer empfindet dann das System als einfach und sind zufriedener bei der Bedienung des Systems.

4. Learn / Lernen

„Wissen macht alles einfacher“ [Mae06]. Wenn ein System und dessen Nutzung bereits bekannt sind, ist es einfacher zu bedienen. Lernprozesse sollten unterstützt werden, da ansonsten das dritte Gesetz gebrochen wird. Stößt ein Nutzer auf neue Funktionen, ist es von Vorteil, wenn er diese gleich oder ähnlich bedienen kann wie bereits bekannte Funktionen.

Damit werden unnötige Lernprozesse umgangen.

5. Differences / Gegensätze

Je komplexer alles wird, desto mehr stechen einfache Dinge heraus. Eine sehr einfache Software kann deshalb in der großen Masse von komplexer Software viel Zuspruch bekommen und an Beliebtheit gewinnen.

6. Context / Kontext

Objekte müssen in ihr Umfeld eingearbeitet sein und nicht als unab- hängiges Objekt in einer unpassenden Umgebung platziert werden. Den Nutzern kann dadurch die Sicherheit gegeben werden, dass Objekte die Funktionalität besitzen, welche erwartet wird.

7. Emotion / Emotion

Dieses Gesetz widerspricht dem ersten Gesetz in gewisser Weise, jedoch kann ein Objekt durch zu stark vereinfachte Formen und Funktionen möglicherweise als minderwertig oder sogar unschön empfunden werden.

Wie auch im ersten Gesetz beschrieben, darf das Produkt nicht zu stark unter einer Vereinfachung leiden und somit können Stil-Elemente wie zum Beispiel spezielle Texturen etc. genutzt werden, um dem Nutzer positive Emotionen zu vermitteln.

8. Trust / Vertrauen

Wenn Nutzer einem System vertrauen, wirkt sich das positiv auf die Nutzbarkeit aus. Ist bereits vor der Nutzung des Systems klar, was das System für ein Ergebnis liefern wird und diese Erwartung wird getroffen, erscheint das System für den Nutzer als einfach. Hier besteht jedoch auch die Gefahr, dass sich die Nutzer bevormundet fühlen und durch eventuelle Einschränkungen das System nicht mehr als einfach ansehen.

9. Failure / Fehlschläge

Vereinfachung kann auch zu Fehlern führen und manche Dinge können nicht vereinfacht werden. Dies macht sich bemerkbar, wenn „vereinfachte“

Objekte plötzlich deutlich schlechter zu nutzen sind und sollte folglich rückgängig gemacht werden.

10. The One / Das Eine

In diesem Gesetz werden die ersten neun Gesetze vereint dargestellt. Of- fensichtliches soll entfernt und Wichtiges sowie Bedeutsames hinzugefügt werden. Hierfür gibt es folgende drei „Schlüssel“:

(20)

Away / Entfernt

Viele Objekte können wenig erscheinen, wenn diese entfernter dargestellt werden.

Open / Offen

Selbst komplexe Dinge können einfach sein, wenn diese offen dargestellt sind. Ein Beispiel hierfür ist das Open Source Betriebsystem Linux.

Power / Energie

Nutzer sollen auf einem kurzen, dafür effizienten Weg ans Ziel ge- führt werden.

Diese „Laws of Simplicity“ sind sehr vielseitig anwendbar. Sie können als Richt- linien für das ein Design einer Oberfläche dienen. Viele dieser Gesetze sind zum Beispiel auch in den von Google und Apple vorgestellten Designrichtlini- en zu finden. Auch die Funktionalität eines Systems und die damit verbundene Nutzbarkeit können dadurch beeinflusst werden. Abseits von Designgrundsät- zen, welche zum genannten Ziel eines User-Interfaces beisteuern, wurde auch mehrfach versucht, Grundsätze gezielt für die Nutzbarkeit festzulegen. Viele Designgrundsätze beinhalten dies teilweise, darunter auch die „Laws of Simpli- city“, jedoch gibt es Ansätze, welche gezielter auf die Nutzbarkeit ausgerichtet sind. Die von vielen genutzten Grundlagen sind die von Jakob Nielsen im Jahr 1994 erfassten „10 Usability Heuristics for User Interface Design“ [Nie94]. Niel- sen, der als „Guru of Usable Web Pages“ [Ric98] bekannt ist, gründete 1998 zusammen mit Don Norman, welcher 2013 das Buch „The Desin of Every- day Things“ veröffentlichte, die Nielsen Norman Group (NN/g). Die NN/g ist die führende Firma in forschungsbasierter User Experience, die Unternehmen wie eBay, National Geographic, Sony und Google berät und die Entwicklung von bekannten Systemen wie Microsofts Windows 8 [Nie12] oder Apples iPad [Bud11] durch User Experience Analysen unterstützt hat.

Durch die schnelle Entwicklung der Technik wurden die Grundlagen von 1994 mittlerweile in vielen Arbeiten für modernere Anwendungen angepasst und überarbeitet. So auch in „Design-Prinzipien Reloaded: 13 wichtige Usability- Prinzipien“, die 2018 von Eva Brumme der Firma Zeiss veröffentlicht wurde [Bru18]. Die 13 Prinzipien basieren zum einen auf Nielsens zehn Usability Heu- ristiken und Normans „The Design of Everyday Things“, aber auch auf den Web Content Accessibility Guidelines 2.0 [Kir+18], einem Webstandard des World Wide Web Konsortium von 2018 und weiteren Arbeiten und lauten wie folgt:

1. Effektivität: Das Ziel erreichen

Die Anwendung soll die entsprechende Funktionalität besitzen, um den Nutzer effektiv in seiner Arbeit zu unterstützen. Es dürfen keine unnö- tigen Inhalte angezeigt werden. Es ist zum Beispiel von Vorteil, wenn Texte nur relevante Informationen beinhalten. Unnötige Informationen lenken den Anwender von essenziellen Inhalten ab.

2. Effizienz: Schnell zum Ziel kommen

Wie auch bereits in den „Laws of Simplicity“ soll die Reaktionszeit von

(21)

2.3 User Interface

Aktionen dem Anwender das Gefühl von Einfachheit vermittelt. Die Usa- bility steigert sich, wenn die benötigte Zeit für einen Prozess minimal gehalten wird. So kann die Arbeitsgeschwindigkeit des Nutzers zum Bei- spiel durch passende Default-Werte erhöht oder indem die Auflösung angepasst wird, die Ladezeiten von Bildern verringert werden.

3. Steuerbarkeit: Die Nutzer haben die Macht

Die Anwender sollen stets die Kontrolle über ihre Aktionen behalten, sie können Vorgänge abbrechen, pausieren und zu gewünschter Zeit fortset- zen. Auch die Möglichkeit, bestimmte Aktionen rückgängig zu machen oder bei Wunsch von vorne zu beginnen, ist hierbei hilfreich.

4. Individualisierbarkeit: Alles passt zum Nutzer

Es ist am besten, wenn die Anwender die Möglichkeit besitzen, die Arbeit so zu verrichten, wie sie möchten. So können zum Beispiel Schriftgröße und Default-Werte geändert werden und erfahrene Nutzer, können die von ihnen am meisten genutzten Befehle durch Shortcuts schnell aufru- fen.

5. Konsistenz: Alles passt zusammen

Die Nutzer können besser arbeiten, wenn Konventionen eingehalten werden. Solche können vom Betriebssystem vorgegeben sein, es können aber auch software-interne Konventionen existieren. Begriffe, Icons oder sogar das Layout sollten entsprechend konsistent sein, sodass die Nutzer bereits erlernte Methoden leicht anwenden können.

6. Design und Layout: Auf den ersten Blick verständlich

Das Visuelle darf den Anwender nicht negativ beeinflussen. Farben und Anordnungen können den Nutzer in der Anwendung unterstützen. Infor- mationen sollen insgesamt gut dargestellt werden. Zu geringe Kontraste verschiedener Elemente oder sehr kleine Schriftarten sind zu vermeiden.

Dieses Prinzip ist gut in den bereits genannten Designs von Google und Apple zu erkennen.

7. Sprache: Die Sprache des Nutzers sprechen

Die Anwendung soll in Funktionalität, Design und den dargestellten In- formationen passend an die jeweilige Zielgruppe gerichtet sein. Die An- wender können Informationen besser verarbeiten, wenn sie gut dargestellt sind. So ist es zum Beispiel vorteilhaft, Fehlermeldungen an den Nutzer und nicht den Entwickler zu richten oder die Schriftgröße zu vergrößern, falls die Anwendung an Sehbeeinträchtigte gerichtet ist.

8. Sichtbarkeit: Die Nutzer erkennen ihre Möglichkeiten

Die Navigation muss klar aufgebaut sein und die Nutzer müssen wissen, wo sie sich in der Anwendung befinden, sowie welche Möglichkeiten ihnen gerade zur Verfügung stehen. So können durch farbliche Markierungen oder Anpassungen im Layout, wie zum Beispiel der Größe von Buttons, die jeweiligen Elemente hervorgehoben werden.

(22)

9. Feedback: Die Nutzer erfahren, was los ist

Bei Interaktionen mit dem System sollen die Nutzer die nötige Rück- meldung erhalten. Auf Ladezeiten kann mit Spinner-Icons hingewiesen werden und es ist von Vorteil, wenn Fehlermeldungen das Problem zu- treffend beschreiben oder sogar eine Hilfestellung zur Problembehebung geben.

10. Lernförderlichkeit: Leicht zu lernen

Vor allem bei komplexeren Anwendungen ist es wichtig, den Nutzer mit den nötigen Funktionen vertraut zu machen. Die Anwender sollten die Möglichkeit haben, die notwendigen Abläufe ohne negative Auswirkun- gen auf ihre Arbeit zu erlernen. Hierfür können zum Beispiel Tutorials oder ein Probemodus genutzt werden.

11. Hilfe und Dokumentation: Hilfe, die hilft

Benötigen die Nutzer Unterstützung, sollen sie diese ohne großen Auf- wand finden können. So kann zum Beispiel ein Hilfetext mit in die Ober- fläche eingebunden sein, wenn entsprechender Platz vorhanden ist. Al- ternativ dazu kann ein kleiner extra Button platziert werden, um ein Hilfemenü öffnen zu können.

12. Fehlertoleranz: Nutzerfehler verzeihen und vermeiden

Dem Nutzer sollte es nicht möglich sein, die Anwendung in einen ungül- tigen Zustand zu versetzen. Ungültige Eingaben müssen verhindert oder durch entsprechende Warnungen deutlich gemacht werden. Die Nutzung darf unter keinen Umständen zu Datenverlust führen.

13. Nutzungsgefühl (UX): Die Software fühlt sich gut an

User Experience ist das Gesamterlebnis beim Bedienen der Anwendung.

Es setzt sich aus der Nutzung selbst, den Erwartungen sowie den Vor- kenntnissen des Anwenders zusammen. Seine Vorkenntnisse sollen helfen und Erwartungen übertroffen werden. Dieses Prinzip fasst die vorher genannten Prinzipien großteils zusammen.

Bei all diesen Prinzipien gilt es jedoch immer zu beachten, dass sie keine per- fekte Lösung darstellen. Wie gut eine Software bedienbar ist, kann nicht voll- ständig anhand von Kriterien festgemacht werden, sondern ist für jeden Nut- zer unterschiedlich. Somit sollte, abseits dieser Prinzipien, immer die jeweilige Zielgruppe berücksichtigt und die Software gegebenenfalls durch Nutzertests angepasst werden [Bru18]. Nachdem Prinzipien für das Oberflächen-Design be- züglich Nutzbarkeit definiert und abgewägt wurden, ist es zu entscheiden, wie das GUI zusammen mit der restlichen Software am besten verfügbar gemacht wird.

2.4 Desktop-App vs. Web-App

Bei der Entwicklung einer Software stellt sich die Frage, ob diese als Web-App oder als Desktop-App zur Verfügung gestellt werden soll. Hierfür müssen die

(23)

2.4 Desktop-App vs. Web-App

jeweiligen Vor- und Nachteile betrachtet werden. Diese werden nachfolgend anhand den Ausführungen von Leonard Koch [Koc21] zunächst für Desktop- Apps und anschließend für Web-Apps dargestellt.

2.4.1 Desktop-App

Eine Desktop-Anwendung wird auf einem Endgerät direkt installiert und kann auf dessen Hardware zugreifen.

Vorteile

Die Vorteile einer Desktop-Anwendung lassen sich wie folgt zusammenfassen:

Internetzugang nicht dauerhaft benötigt

Bei einer Desktop-Anwendung wird keine dauerhafte Internetverbindung benötigt, da diese lokal auf dem Endgerät arbeitet. Es können zwar Funk- tionen enthalten sein, für die Internet benötigt wird, jedoch beschränken sich diese meistens auf eine temporäre Verbindung wie zum Beispiel das Updaten einer Datenbank.

Hardwareanbindung

Da die Software direkt auf dem Endgerät läuft, kann sie deutlich rechen- intensivere Funktionalitäten besitzen als eine Web-App. Die Anwendung kann zum Beispiel einfacher mit der Prozessorleistung arbeiten und einen großen lokalen Speicherplatz nutzen (beides ist jedoch abhängig vom Endgerät)

Nachteile

Leider bringt eine Desktop.Anwendung auch Nachteile mit sich:

Installationsaufwand

Desktop-Anwendungen müssen auf jedem Endgerät installiert werden, auf der sie genutzt werden sollen. Die Installation kann sich je nach End- gerät unterscheiden und eventuell müssen Berechtigungen erteilt werden, damit diese überhaupt durchgeführt werden darf. Bei gewerblich genutzten Computern bei denen die Nutzer nicht immer auch die Besitzer des Gerätes sind, kann dies zu einem hohen Aufwand führen.

Höherer Entwicklungsaufwand

Anwendungen welche lokal auf einem Endgerät laufen sollen, müssen meistens für die verschiedenen Betriebssysteme unterschiedlich entwickelt werden. Dies erhöht den Aufwand langfristig, da Updates ebenfalls angepasst werden müssen.

2.4.2 Web-App

Web-Apps werden auf einem externen Server installiert und Nutzer müssen Online über einen Browser auf diese zugreifen. Die Anwendung kann komplett über den Browser gesteuert werden und benötigt keine weiteren Programme.

(24)

Vorteile

Eine Web-Anwendung hat folgende Vorteile:

Betriebssystemunabhängig

Eine Web-Anwendung kann von jedem Rechner genutzt werden, welcher einen Browser installiert hat. So kann jedes Endgerät, welches eine be- stehende Internetverbindung sowie einen Browser hat, darauf zugreifen.

Keine Installation

Die Web-App benötiget keine Installation, wodurch die Anwendung selbst auf Betriebsrechnern mit fehlenden Installationsrechten genutzt werden kann.

Geringerer Entwicklungsaufwand

Die App kann zentral und einheitlich entwickelt werden, da es keine Unterscheidung zwischen verschiedenen Betriebssystemen gibt. Updates können auf den Server gespielt werden, wodurch sie für alle Nutzer direkt verfügbar sind.

Nachteile

Web-Apps haben jedoch ebenfalls auch Nachteile:

Dauerhaft benötigter Internetzugang

Eine Web-Anwendung benötigt dauerhaften Zugang zum Internet und je nach Anwendung, kann eine langsame Verbindung zu einer schlechten Nutzbarkeit führen. Entfällt die Verbindung komplett, kann die Software meist nur noch sehr eingeschränkt genutzt werden, sofern die Webseite vorher bereits geladen wurde.

Höheres Datensicherheitsrisiko

Da die Daten nicht lokal auf dem Endgerät verwaltet werden, sondern alles über den Browser läuft, sind die verwendeten Daten einem höheren Sicherheitsrisiko ausgesetzt.

Da jedes Projekt unterschiedliche Anforderungen besitzt, kann nicht pauschal gesagt werden, ob eine Web- oder Desktop-Anwendung besser geeignet ist.

In dem Fall von Game of TUK überwiegen die Vorteile eine Web-App. Die Anwendung muss keine rechenintensiven Prozesse ausführen und soll sehr einfach, selbst für Nutzer ohne IT-Kenntnisse, zu bedienen sein. Das Entfallen der Installation und die Möglichkeit die App zentral auf einem Server verwalten und updaten zu können, ist von großem Vorteil. Des Weiteren können Nut- zer ihre eigenen Endgeräte unabhängig des Betriebssystems nutzen. Hier kann es jedoch zu Design- und Eingabeproblemen zum Beispiel bei Smartphones mit einem anderen Seitenverhältnis und Touchscreens kommen. Daher wurde die Entscheidung getroffen, das Konfigurationsmanagement-Tool für Game of TUK als Web-App zu implementieren.

(25)

2.5 Game of TUK

Game of TUK ist eine App, mit der ein spielerischer Wettkampf ausgetragen wird, der seit 2018 jeden Sommer in der Technischen Universität Kaiserslautern stattfindet. Es wird dabei eine Mischung aus realen und virtuellen Aspekten genutzt, um die Bewegung der Teilnehmer zu fördern. Alle Spieler werden anhand ihrer Fachschaften in vier Gruppen, sogenannte Häuser, aufgeteilt. Seit 2020 können auch Mitarbeiter der TUK teilnehmen, die ein eigenes Haus bilden.

Ziel ist es, durch eine Vielzahl von verschiedenen Spielen Punkte zu sammeln, welche dem Haus gutgeschrieben werden. Am Ende der Spielrunde gewinnt das Haus mit den meisten Punkten und die Fachschaften des Gewinnerhauses erhalten einen Preis [Cam].

2.5.1 Entwicklung

Ursprünglich wurde die App von einem studentischen Team mit Mitarbeitern der TUK und des Deutschen Forschungszentrums für Künstliche Intelligenz (DFKI) entwickelt. Nach der zweiten Spielrunde wurde die Entwicklung über das DFKI Team eingestellt und seit Anfang 2020 nur noch von Mitarbeitern der TUK weiterentwickelt. Durch das neue Team wurde die App von Grund auf neu implementiert, um Kompatibilitätsprobleme zwischen Android und iOS zu lösen und einfacher und schneller neue Features einbinden zu können.

Somit wurde die App mit Hinsicht auf Modularität und Zukunftssicherheit mit der Programmiersprache Dart und dem UI-Entwicklungskit Flutter von Google neu programmiert. Die Verwendung von Flutter wurde gewählt, um die Kompatibilitätsprobleme zwischen Android und iOS zu minimieren. Mit Flutter kann aus einem Sourcecode die App für beide Betriebssystem exportiert werden. Durch die neue Entwicklungsstruktur, bei der vieles bezüglich der Modularität berücksichtigt wurde, ist es nun deutlich leichter die App nach Wünschen anzupassen. So konnte zu Beginn des Wintersemesters 20/21 bereits eine, speziell für die Erstsemester angepasste, Version veröffentlicht werden. In dieser Version standen die Erkundung des Campus, wichtige Informationen über die Uni sowie wichtige Orte der Stadt Kaiserslautern im Vordergrund.

2.5.2 Ablauf

Die Planung des jährlichen Game of TUK beginnt mehrere Monate vor der eigentlichen Spielrunde. Zuerst muss abgeklärt werden, welche Features in der Spielrunde enthalten sein sollen und zusätzlich noch neue entwickelt werden müssen. Das Programmierer-Team setzt dies um, während weitere Game of TUK Mitarbeiter die nötigen Daten für die Spielrunde erstellen, wie zum Bei- spiel Texte, Bilder und weitere Spieldaten. Nachdem die App, sowie der Server für die gewünschten Features angepasst wurden, werden die Daten eingepflegt.

Eine Standard-Spielrunde beträgt vier Wochen, in denen die Teilnehmer über drei Spielebenen Punkte sammeln können. Der Punktestand wird täglich um zwölf Uhr mittags in der App auf dem Homescreen aktualisiert. Die Bestenliste, in der die Spieler in einer Vielzahl von Rubriken dargestellt werden, aktualisiert

(26)

sich in Echtzeit bei bestehender Internetverbindung. Am Ende der Spielrunde findet ein Liveevent statt, an dem die Spieler teilnehmen können, um zusätzli- che Preise zu gewinnen und an dem das Siegerhaus gekürt wird. Diesen Ablauf soll das später vorgestellte Konfigurationsmanagement-Tool vor allem bei der Erstellung der Daten verbessern. Die Mitarbeiter, welche die Daten erstellen sollen unabhängiger, effizienter und einfacher arbeiten können um die Daten einheitlich zu erstellen.

2.5.3 Spielebenen

Um die Features des implementierten Tools besser nachvollziehen zu können, werden im folgenden Abschnitt die Spiele von Game of TUK und deren benö- tigten Daten genauer beschrieben. Die drei Spielebenen unterscheiden sich in dem zeitlichen Aufwand, den ein Spieler aufbringen muss, und den Punkten die er dadurch erhält. Ebenso verändert sich der Anteil der realen und virtuellen Spielaspekte in den verschiedenen Ebenen [Gam].

Abbildung 2.1: Angepasste Anzeige aller Spielebenen in der Game of TUK App.

Quickies

Quickies sind sehr kleine Spiele, die einen sehr geringen zeitlichen Aufwand erfordern und komplett virtuell in der App stattfinden. Sie fordern die körper- liche Aktivität des Spielers kaum, sondern zielen auf andere Fertigkeiten wie eine gute Reaktionszeit oder ein großes Allgemeinwissen ab. Die Teilnehmer erhalten hierfür nur sehr wenig Punkte, dafür können sie jederzeit, jedoch durch ein Tageslimit begrenzt, gespielt werden.

Weeklies

Weeklies sind größere Spiele, bei denen die App nur als Unterstützung dient.

Sie fördern stark die Bewegung und finden häufig im Freien statt. Meist müs- sen Aufgaben im realen Umfeld erledigt werden und wodurch die Teilnehmer virtuelle Punkte in der App erhalten. Die Anzahl der Punkte die gesammelt werden können ist deutlich höher als bei Quickies, dafür sind Weeklies nur für eine Woche spielbar. Die Spielzeit variiert in anderen Versionen von Game of TUK wie zum Beispiel der Ersti-Edition, jedoch behalten die Spiele trotzdem ihren Wert und Umfang.

(27)

2.5 Game of TUK

Events

Events sind die letzte Spielebene und finden üblicherweise nur zu Beginn und am Ende einer Spielrunde statt. Hier können nur wenige Spieler teilnehmen, die vor Ort ausgewählt oder gelost werden. Die Spiele finden vor Publikum und ohne die App statt. Sie besitzen somit den größten Aufwand für die Spieler.

Dementsprechend kann eine sehr große Anzahl an Punkten, jedoch selten für den Spieler selbst, sondern für das Haus des Spielers direkt gesammelt werden.

Mit den Events kann der Spielstand sehr stark beeinflusst werden und sie sind für den Sieg die wichtigsten Herausforderungen.

2.5.4 Spiele

Aktuell gibt es sechs Spiele, welche alle genutzt werden. Alle sechs Spiele haben ihr eigenes Ranking in der Bestenliste und werden im folgenden genauer beschrieben.

Quiz

Beim Quiz muss der Spieler innerhalb von 30 Sekunden zu einer Frage die richtige Antwort aus vier Antwortmöglichkeiten auswählen (siehe Abbildung 2.2). Ein Klick auf die jeweilige Antwort stoppt die Zeit und zeigt das Ergebnis an. Wenn innerhalb der 30 Sekunden keine Antwort ausgewählt wird, gilt die Frage als falsch und es werden keine Punkte vergeben. Da das Quiz als Qui- ckie verwendet wird, kann ein Spieler jeden Tag nur eine festgelegte Anzahl von Quizfragen spielen. Hat er diese an einem Tag bereits erreicht, wird eine Meldung angezeigt und er kann erst am folgenden Tag fortfahren.

Die Fragen werden für jeden Spieler täglich zufällig aus einer Sammlung ausgewählt. Somit können sich Spieler nur in wenigen Fällen (zum Beispiel, wenn ein Spieler dieselbe Frage an einem früheren Tag hatte) gegenseitig helfen.

Die Quizfragensammlung muss vor Beginn der Spielrunde von den Entwicklern bereitgestellt werden und beinhaltet ausreichend Fragen, wobei jede aus der Frage selbst und den vier Antwortmöglichkeiten in englischer und deutscher Übersetzung besteht.

Ein weiteres Quickie ist das Eselrennen, hierbei wird gegen einen Computer- gegner gespielt. Um zu gewinnen, muss der eigene Esel vor dem Gegnerischen das Ziel erreichen. Es ist ein Reaktionsspiel, bei dem so schnell wie möglich die richtigen Buttons gedrückt werden müssen. Es stehen zwei Buttons zu Aus- wahl, eine Karotte und eine Peitsche. Jeder Esel benötigt das richtiges Ver- hältnis zwischen Karotte und Peitsche. Ein gelber Ring verdeutlicht, welcher Button gedrückt werden muss (siehe Abbildung 2.3). Bei einer falschen Eingabe leuchtet der Bildschirm rot auf und die Strafzeit muss abgewartet werden. Für jede richtige Reaktion, bewegt sich der eigene Esel weiter in Richtung Ziellinie.

Welcher Button als nächstes betätigt werden muss, wird zufällig entschieden und soll somit die Reaktionszeit fördern. Um unfaire Spieltaktiken zu verhindern, wurde ein spezielles System entwickelt, welches den Zufallsgenerator beeinflusst und die Wahrscheinlichkeiten für die Auswahl des nächsten But-

(28)

Abbildung 2.2: Ein laufendes Quiz Spiel.

tons anpasst. Die Geschwindigkeit des gegnerischen Esels wird auch zufällig, innerhalb eines eingestellten Bereiches, gewählt. Seit dieses System eingesetzt wird, benötigt das Spiel nahezu keine weiteren Einstellungen für die einzelnen Game of TUK Spielrunden. Falls gewünscht, können jedoch die Parameter wie Anzahl der Spiele pro Tag, Strafzeit, Zeit des Gegner-Esels usw. angepasst werden.

Coin Collector

Coin Collector ist ein Weekly Spiel, bei dem in der realen Welt per GPS, Orte aufgesucht werden müssen, um virtuelle Münzen zu finden. Die Münzen werden innerhalb der App auf einer Karte angezeigt. Ab einer festgelegten Distanz, muss ein Button gedrückt werden, um sie einzusammeln, und je nach Einstel- lung, erscheint ein Pop-up, welches Informationen über den Ort anzeigt. Es kann jeden Tag eine Zusatzmünze, die sogenannte Super Coin, freigeschaltet werden, indem eine bestimmte Anzahl von Münzen eingesammelt wird. Sie ist versteckt und wird nicht auf der Karte angezeigt, jedoch kann sich der Spieler ein Bild anzeigen lassen, welches den Ort der Münze beschreibt. Eine weitere Münzart wurde 2020 zu Game of TUK hinzugefügt. Sie bewegt sich von selbst fort und ist somit schwerer einzusammeln. Diese sogenannte Running Coin kann jedes Mal eingesammelt werden, wenn eine bestimmte Anzahl von normalen Münzen erreicht ist. Zu Beginn ist die Running Coin bereits verfüg- bar. Benötigt man beispielsweise drei Münzen, kann ein Spieler, welcher bereits sechs normale Münzen gesammelt hat, den Running Coin dreimal einsammeln, einmal zu Beginn, sowie zweimal durch die Anzahl seiner normalen Münzen.

Durch die drei verschiedenen Münzarten soll im Spiel ein abwechslungsrei- cher Spielfluss gewährleistet sein. Ein Spieler kann abseits der Aufgabe, die

(29)

2.5 Game of TUK

Abbildung 2.3: Ein laufendes Eselrennen.

Super Coin freizuschalten, zusätzlich kleine Aufgaben wie das Aktivieren und Fangen der Running Coins absolvieren. Hat ein Spieler alle normalen Münzen, Running Coins und den Super Coin an einem Tag eingesammelt, kann er an diesem Tag nicht weiterspielen und muss auf den nächsten Spieltag warten.

Dieses Spiel erfordert eine große Menge an Daten und Einstellungen, die vor Spielbeginn eingepflegt werden müssen. Jede Münze benötigt eine Position sowie gegebenenfalls einen Informationstext des Ortes. Die Pfade, auf denen sich die Running Coins bewegen, müssen festgelegt und für die Super Coins die Positionen und Hinweisbilder bereitgestellt werden. Des Weiteren werden für jeden Spieltag die gewünschten Münzen, ein Pfad für die Running Coins, die Super Coin und eine Vielzahl von Parametern benötigt. Einige Parame- ter sind zum Beispiel: der Einsammelradius der Münzen, die Geschwindigkeit der Running Coins und die benötigte Anzahl an normalen Münzen, um einen Running Coin zu aktivieren.

Mr. Z

Dieses Weekly wurde 2020 mit der Neuentwicklung von Game of TUK einge- führt und ist das erste und bisher einzige Spiel, welches nicht alleine gespielt werden kann. Wie der Name suggeriert, ist das Spiel angelehnt an das Brett- spiel „Scotland Yard“, in dem der Verbrecher Mister X gefangen werden muss.

In Game of TUK muss sich eine Gruppe von zwei bis fünf Personen zusammen- finden, um Mr. Z zu fangen. Spieler müssen Spiellobbys selbst erstellen in die weitere Spieler über einen Code beitreten können. Sind alle Teilnehmer bereit, muss ein virtueller Mister Z gefangen werden. Hierzu wird allen Teilnehmern in der App eine Karte angezeigt, die mit einem Graphen überzogen wurde.

Der virtuelle Gegner befindet sich immer auf einem Knoten dieses Graphen

(30)

und bewegt sich nach einigen Sekunden über die Kanten zu einem anliegen- den Knoten. Wie auch im Brettspiel ist die Position des Gegners nicht immer bekannt. Dieser zeigt sich nur nach drei Bewegungen. Somit kann Mr. Z bis zu zwei Knoten von seiner bekannten Position entfernt sein. Er versucht vor den Spielern zu fliehen, wodurch diese sich taktisch fortbewegen und positio- nieren müssen. Um zu gewinnen, muss in Zusammenarbeit der Knoten erreicht werden, auf dem sich Mr. Z befindet. Sobald ein Teammitglied an Mr. Zs Po- sition ankommt, erhalten alle Spieler eine Nachricht und werden mit Punkten belohnt. Mr. Z kann beliebig oft gefangen werden. Ab einem bestimmten Punk- telimit ist es weiterhin möglich zu spielen, jedoch erhalten die Teammitglieder, welche ihr Limit erreicht haben, beim Sieg keine Punkte. So können andere Spieler weiterhin strategisch unterstützt werden.

Das Spiel hängt stark von dem vorher definierten Graphen ab, dieser besteht aus einer Vielzahl von Positionen und Verbindungen. Da Mr. Z sich immer zu einem Nachbarknoten auf dem Graphen bewegt, spielt die Entfernung der Knoten eine große Rolle. Zusammen mit der Zeit, welche er zwischen den Bewegungen wartet, bestimmt sie die Geschwindigkeit von Mr. Z.

Schnitzeljagd

Bei dem Weekly Schnitzeljagd müssen Spieler anhand von Rätseln bestimmte Orte aufsuchen. Den Teilnehmern wird keine Karte angezeigt, sondern nur eine Distanzanzeige, sowie eine Information, welche aus Text und Bildern bestehen kann. Mithilfe von GPS wird in diesem Spiel die Position des Spielers ermittelt, wodurch die Anzeige in Echtzeit angepasst wird. Diese gibt nur die Entfernung zum Zielort in Metern an (dies auch nur, wenn der Spieler höchstens 500 Meter vom Ziel entfernt ist) und nicht die Richtung, in der sich das Ziel befindet. Wird der Ort erreicht, erhält der Spieler Punkte als Belohnung und kann das nächste Rätsel beginnen. Die Rätsel müssen innerhalb einer Rubrik, welche in Game of TUK als „Stage“ bezeichnet wird, nacheinander gelöst werden. Es können mehrere kleine Schnitzeljagden mithilfe verschiedener Stages gespielt werden.

Stages können anhand von verschiedenen Gegenden eingeteilt werden, wodurch zum Beispiel eine Wald- und Innenstadt-Stage erstellt werden kann. Beendet man eine Stage, erhält man Zusatzpunkte. Je nach Konfiguration des Servers müssen Stages nacheinander gelöst oder können separat voneinander gespielt werden. Für dieses Spiel müssen alle Rätsel in der gewünschten Reihenfolge und Gruppierung erstellt werden. Jedes Rätsel benötigt eine Position des Ziels sowie den Rätseltext und gegebenenfalls die nötigen Bilder, die in die Texte eingepflegt werden sollen.

Sportkurse

Das letzte Weekly findet vor allem abseits der App statt. Hierfür müssen im Unisport Sportkurse belegt werden. Die Teilnehmer erhalten am Ende des Kur- ses vom Kursleiter einen Game of TUK Geldschein, dieser ist mit einem QR- Code bedruckt und kann in der App mit dem integrierten QR-Code Scanner abgescannt werden. Je nach Wert des Geldscheins, erhalten die Spieler die

(31)

2.5 Game of TUK

entsprechenden Punkte. Die Kursleiter werden mit den benötigten Geldschei- nen ausgestattet und geben diese nur in der Spielzeit dieses Weeklys aus. Da theoretisch eine große Anzahl an Sportkursen belegt werden kann, wurde ein Scan-Limit für Geldscheine festgelegt. Für dieses Spiel wird lediglich eine Datei mit generierten Codes, die akzeptiert werden, auf dem Server benötigt.

(32)

(33)

3 Configtool von Game of TUK

In Game of TUK muss für jede Spielrunde eine komplexe Konfiguration aus einer Vielzahl von Daten erstellt werden. Verschiedene Daten benötigen unterschiedliche Formate, wodurch eine gute Kommunikation mit allen Mitarbei- tern nötig ist. Daten im korrekten Format zu nutzen, kann für Personen mit fehlender technischer Ausbildung ein Problem sein. Um diesem entgegenzuwir- ken, wurde im Rahmen dieser Arbeit eine Konfigurationssoftware implementiert. Das Programm wurde in der Programmiersprache Dart und mit Hilfe des Open-Source-UI-Entwicklungskits Flutter, geschrieben. Ziel von Flutter ist unter anderem, in kurzer Zeit eine gute User-Experience zu schaffen. Diese soll mit wenig Aufwand und einem einheitlichen Code für verschiedenen Plattfor- men entwickelt werden können. Aktuell werden die Plattformen Android, iOS, Web-App, Windows, Linux, macOS und Google Fuchsia unterstützt [Goo21a].

Da Game of TUK ebenfalls in Dart und Flutter geschrieben wurde, bietet dies uns die Möglichkeit, dem Nutzer ein vertrautes User-Interface zu gestalten.

Zusätzlich kann das Configtool in Zukunft mit wenig Aufwand von Game of TUK Entwicklern erweitert werden, da diese sich nicht in eine neue Program- miersprache einarbeiten müssen.

Das Programm steht den Nutzern als Web-App zur Verfügung, da die Vortei- le im Vergleich zu einer Desktopanwendung für das Projekt klar überwiegen.

Die Software soll dafür zuständig sein, dass die Mitarbeiter schnell, einfach und ohne großen Aufwand die benötigten Daten auf ihren unterschiedlichen Endgeräten erstellen können. Hierfür ist die Cross-Platform-Kompatibilität einer Web-App von großem Nutzen. Zusätzlich entfällt auch eine Installation, welche je nach Endgerät (und möglicherweise sogar fehlenden Rechten auf Ar- beitscomputern) für manche Nutzer aufwendig sein kann. Eine bessere Hardwa- reanbindung, welche durch eine native Desktop-App verfügbar wäre, wird nicht benötigt, da keine komplexen und rechenintensiven Prozesse von dem Tool be- wältigt werden müssen. Auch die Weiterentwicklung des Programms und damit die Verteilung der neuen Updates ist einfacher. Die Entwickler können diese auf dem Server einspielen. Nutzer haben damit ohne weiteren Aufwand direkten Zugriff auf die neuste Version.

3.1 Design

Die Grundlage des Designs stammt aus der Game of TUK App. Dies hat den Vorteil, dass Nutzer, meist Game of TUK Mitarbeiter, sich durch das bekannte Design leichter zurechtfinden und die Umgebung vertrauter wirkt. Da hier auch auf das von Flutter angebotene „Material Design“ von Google gesetzt wird, können Buttons und Icons im selben Stil der App gehalten werden. Die

(34)

Farben wurden großteils aus der Farbpalette der App gewählt, um die Zuge- hörigkeit zu betonen. Diese wurden minimal eingesetzt und weitere Grautöne verwendet. Das Tool ist im Vergleich zu Game of TUK kein Spiel, welches bunt und auffallend designt ist, sondern eine Arbeitssoftware. Das Programm soll schlicht erscheinen und nicht durch bunte Icons oder Ähnliches (Maedas siebtes Gesetz der Einfachheit) unpassende Emotionen auslösen oder sogar ablenken [Mae06].

3.2 Navigation

Die Hauptnavigation findet, wie auch in der App, über eine Tableiste statt (siehe Abbildung 3.1). Diese ist am oberen Bildschirmrand platziert. Bei einem Smartphone hingegen, sind Tableisten öfter am unteren Rand positioniert. Der Grund hierfür liegt an der Reichweite des Daumens, der meistens nicht bis an den oberen Bildschirmrand reicht, ohne die Haltung zu verändern [Le+18].

Alternativ wäre hier auch eine sequenzielle Navigation durch die nötigen Be- arbeitungsschritte möglich. Im Beispiel von Game of TUK macht dies jedoch wenig Sinn, da die Reihenfolge der Bearbeitung nur in wenigen Fällen eine Rol- le spielt. Mit einer Tableiste kann die Bearbeitungsreihenfolge der jeweiligen Module selbst bestimmt werden, wodurch eine einfachere Arbeitsteilung ermög- licht wird. Zum Beispiel kann ein Mitarbeiter ein Modul seiner Wahl vollenden, die Konfigurationsdatei an einen anderen Mitarbeiter weitergeben und dieser danach ein weiteres Modul seiner Wahl bearbeiten. Diese Vorteile fördern die Usability der Software, wie im ersten und zweiten Usability-Prinzip „Effek- tivität“ und „Effizienz“ beschrieben [Bru18]. Innerhalb eines Tabs erfolgt die

Abbildung 3.1: Die Tableiste des Game of TUK Configtools mit dem Hometab ausgewählt

Navigation meist über eine Spalte am linken Bildschirmrand. Für zusätzliche Kontrolle werden Buttons genutzt. Hellgraue Buttons dienen der zugewiesenen Funktion, wohingegen dunkelgraue Buttons für eine weitere Navigationsebene zuständig sind und als Auswahlknopf fungieren. Somit werden Nutzer, mithilfe der Grauabstufungen (hellgraue Tableiste, dunkelgraue Buttons innerhalb eines Tabs), welche die Tiefe der jeweiligen Navigation darstellen, durch die Software geführt. Da die Navigationsspalte sowie die Farben der verschiedenen Buttons, innerhalb jedes Tabs gleich sind, können die Nutzer diese Navigation schnell erlernen und ihr vertrauen (Gesetze der Einfachheit Vier „Lernen“ und Sieben „Emotion“ [Mae06]). Die dunkelgrauen Buttons ändern bei erfolgreicher Auswahl die Farbe, wodurch ersichtlich wird, wo sich die Nutzer innerhalb eines Tabs befinden.

(35)

3.3 Home

Der Home Tab dient dazu die allgemeinen Einstellungen zu tätigen, welche innerhalb der ganzen App benötigt werden. Mithilfe des ersten Buttons in der Navigationsspalte können die Tage, an denen Game of TUK gespielt werden darf, über einen sogenannten Datepicker festgelegt werden. Die Tage werden benötigt, um andere Zeitspannen, wie zum Beispiel die Spieldauer einzelner Spiele, einzuordnen. Falls in anderen Tabs bereits Zeitspannen eingestellt sind, muss hier die angezeigte Mindestanzahl an Tagen ausgewählt werden, damit die Korrektheit der anderen Tabs erhalten bleibt. Dies wird mit Markierungen entsprechend dargestellt, um den Nutzer gemäß dem neunten Usability-Prinzip

„Feedback“ zu unterstützen. Datepicker werden auch in weiteren Tabs benötigt, bei denen das Design und die Benutzung auf die gleiche Weise erfolgt. Hier- durch wird laut dem fünften Usability-Prinzip „Konsistenz“ die Nutzbarkeit erhöht. Zusätzlich wird das System durch das vierte Gesetz der Einfachheit

„Lernen“ und das achte Gesetz „Vertrauen“ einfacher. Als nächstes können im

Abbildung 3.2: Home: Pop-up zur Auswahl der Spieltage der kompletten Spiel- runde

Home Tab die Texte bearbeitet werden, welche die App benötigt. Hierzu findet sich in der Navigationsspalte eine Liste mit allen bearbeitbaren Texten, welche in Abbildung 3.3 dargestellt sind. Diese können im mittleren Bildschirmbe- reich verändert werden. Da die Texte in Englisch und Deutsch zur Verfügung stehen müssen, befindet sich hier die Sprachauswahl. Die Bearbeitung erfolgt über die Auszeichnungssprache Markdown. Hierfür findet man unter dem Edi- tor auch ein Preview Bereich, in dem der Text in gerenderter Form angezeigt wird. Über einen Tooltip ist die Markdown-Syntax nachlesbar. Da die Game of TUK App dieselbe Markdown Library nutzt, kann im Preview Bereich die korrekte Darstellung des Textes überprüft werden. Auf der rechten Seite befindet sich eine Bildergalerie, in die man per Upload Button Dateien des Formates JPG, PNG und SVG hochladen kann, um sie in einen Markdowntext einzu- binden. Es ist auch möglich hochgeladene Dateien innerhalb der Anwendung

(36)

für Markdowntexte in anderen Tabs zu nutzen. Um die Einbindung der Bilder in den gewünschten Markdown Text zu vereinfachen, besitzt jedes Bild einen Button, der die benötigte Markdown-Syntax generiert.

Textfelder, die nicht ausgefüllt sind, jedoch von der Game of TUK App zwingend benötigt werden, sind mit einer roten Umrandung markiert. Zusätz- lich wird eine Warnung am unteren Bildschirmrand angezeigt um dem Nutzer, gemäß dem neunten Usability-Prinzip „Feedback“, das nötige Feedback zu vermitteln. In diesem Tab gibt es keine komplexen Aufgaben, jedoch helfen die Tooltips, Hinweistexte und Warnungen, dem Nutzer alles Nötige zu erklären.

Wie im elften Usability-Prinzip beschrieben, steigert es die Usability, wenn ein Nutzer ohne großen Aufwand Unterstützung erhalten kann, falls er diese benötigt.

Abbildung 3.3: Home: Beispielbilder in der Galerie sowie die Verwendung des Edi- tors.

3.4 Quiz

Am linken Bildschirmrand befinden sich die Navigationsspalte, in der die Be- dienelemente für die Nutzung der Quizfragenliste zu finden sind. Diese Liste befindet sich in der Mitte des Bildschirms und nimmt einen Großteil der Ober- fläche ein. Die Spielzeit für das Quiz kann wie gewohnt über den Datepicker eingestellt werden, der sich über den ersten Button in der Spalte öffnen lässt.

Hierzu muss zuerst im Home Tab eine Auswahl für die Spielzeit der Spielrunde getroffen werden, damit das Quizspiel dementsprechend innerhalb dieser Zeit eingeordnet werden kann. Somit wird eine fehlerhafte Eingabe von Spieltagen, die außerhalb der Spielzeit der Game of TUK Runde liegen, für das Quizspiel verhindert. Diese Einschränkung ist jedoch, wie im zwölften Usability-Prinzip

„Fehlertoleranz“ beschrieben, von Vorteil und hilft dem Nutzer eine korrekte Konfiguration zu erstellen.

(37)

3.4 Quiz

Über einen Button kann ein Pop-up (siehe Abbildung 3.4) geöffnet werden, um eine neue Quizfrage zu erstellen. Üblicherweise können Pop-ups geschlossen werden, wenn auf den Hintergrund geklickt wird. Dies wurde hier gezielt deaktiviert, um einen ungewollten Verlust an der teilweise erstellten Quizfrage zu verhindern. Ein Fehlklick würde sonst zu unnötigem Mehraufwand führen.

Das zweite Usability-Prinzip „Effizienz“ besagt, dass ein Nutzer schnell an sein Ziel kommen sollte und laut dem zwölften Prinzip „Fehlertoleranz“ muss Da- tenverlust unter allen Umständen vermieden werden. Dies widerspricht zwar der Konsistenz, hat jedoch in diesem Fall für den Nutzer nahezu keine Nach- teile und einen großen Mehrwert. Deswegen kann das Pop-up nur über den Button „discard“ geschlossen werden, damit dem Nutzer bewusst wird, dass er die Einstellungen dieser neuen Frage verliert.

Bei der Quizfrage müssen die Textfelder für den Fragentext und vier mögli- che Antworten in Englisch und Deutsch ausgefüllt, die Markierung der korrekten Antwort gesetzt, sowie mindestens ein Schlagwort vergeben werden. Dieses Schlagwort, im weiteren als „Tag“ (engl.) bezeichnet, können die Nutzer ent- weder neu erstellen, oder aus bereits vorhandenen Tags auswählen. Der Zwang mindesten ein Tag auszuwählen verhindert, dass Fragen eventuell nicht mehr gut gefunden werden können und soll die spätere Nutzung erleichtern. Im Falle

Abbildung 3.4: Quiz: Pop-up Fenster zum Erstellen einer neuen Quizfrage von unvollständigen Eingaben beim Erstellen einer neuen Quizfrage erscheint beim Versuch diese zu speichern eine rote Warnung am unteren Bildschirm- rand mit Informationen zu den fehlenden Eingaben. So wird verhindert, dass Quizfragen ins System gelangen, die der Server nicht lesen kann. Durch die Warnung erhalten die Nutzer genug Informationen und das nötige Feedback den Fehler selbstständig zu beheben (elftes Usability-Prinzip „Feedback“). Falls die Daten korrekt sind, wird die Quizfrage einer internen Liste hinzugefügt und erhält einen zufällig generierten Universally Unique Identifier (UUID), welcher später benötigt wird.