A1: Beispiele für gute und schlechte Bedienoberflächen

• Recherchieren Sie nach drei, aus Ihrer Sicht, guten und drei schlechten Bedienoberflächen, jeweils eine mobile App, eine Webseite, und ein anderweitiges Beispiel (wie z.B. die eines Automaten, Gerätes, einer Anlage, etc.), also abseits typischer Computer oder mobiler Geräte.
• Begründen Sie aus ihrer persönlichen Sicht, warum Sie diese Bedienoberflächen als gut bzw. als schlecht einstufen und zeigen Sie dazu Fotos oder Screenshots, die Ihre Begründungen untermauern.
• Wählen sie ein von Ihnen als schlecht bewertete Bedienoberfläche oder Website aus. Folgende Aufgaben beziehen sich nur mehr auf diese Bedienoberfläche/Seite.
  • Für die ausgewählte schlechte Seite: Analysieren sie diese Seite/Oberfläche basierend auf den in der VU durchgenommenen Nielsen Heuristiken.
  • Für die ausgewählte schlechte Seite: Schlagen Sie zwei wesentliche Verbesserungen vor.

A1 Abgabe

• Laden Sie Ihre Lösung in einer pdf-Datei auf Moodle hoch.
• Bennen Sie Ihre Abgabe bitte nach folgendem Schema: <Matrikelnummer>_<Nachname>_A1.pdf
• Beschreibungen und persönliche Bewertungen der drei guten und drei schlechten Bedienoberflächen mit Screenshots und Quellenhinweis. (insgesamt mind. 400, max 450 Wörter, dazu illustrierende Screenshots).
• Zu der einen, schlechten Bedienoberfläche, die Sie für die genauere Betrachtung ausgewählt haben: Bericht der heuristischen Analyse und resultierenden Verbesserungen der ausgewählten schlechten Seite/Bedienoberfläche (zusätzlich mind. 350, max 400 Wörter, dazu illustrierende Screenshots)
• Beurteilt wird inhaltlich:
  
  • Anwendung der Inhalte aus VU 1 und 2 (Usability Heuristiken / Benutzer- und Aufgabenanalyse / Design Principles)
  • Angemessenheit der Bedienoberflächen als jeweils gute oder schlechte Designbeispiele
  • Persönliche Begründung und konstruktive Kritik

Bewertungsschema A1

• Bedienoberfläche mit persönlicher Begründung (gut)
  • App; 10%
  • Website; 10%
  • sonstiges; 10%
• Bedienoberfläche mit persönlicher Begründung (schlecht)
  • App; 10%
  • Website; 10%
  • sonstiges; 10%
• Heuristische Evaluierung & Verbesserungsvorschläge
  • 30%
• Aufbereitung: Screenshots, Quellen, Sprache, etc.
  • 10%

Vorsicht:

Das Überschreiten der insgesamten Wortzahl (850 Wörter) kann zu Minuspunkten bei der Notenberechnung führen.

A2: Mobile Programmierung einer einfachen App: MusicSearch

=== Für InformatikerInnen ===

Installieren Sie das Programmier-Framework (Android, Flutter, React Native) für das Betriebssystem Ihrer Wahl (Android, iOS, siehe unten!) und erstellen Sie eine erste App mit einem eindeutigen Namen (z.B. für Android "at.ac.univie.hci.MyA2App").

Ihre Aufgabe umfasst die Programmierung und Gestaltung einer einfachen App, die dabei hilft, Informationen über ein gesuchtes Musikers zu finden. Ziel der App ist es, die relevanten Metadata über den Musiker und seine / ihre Alben von der Datenbank abzufragen und dem/der Nutzer*In anzuzeigen.

Die App soll drei Komponenten haben:

• Startseite, auf der Sie Nutzer*Innen ermöglichen, in einem Suchfeld den Namen des Musikers / der Band einzugeben. Die Startseite soll auch Ihren Namen und Ihre Matrikelnummer beinhalten.
• Abfrage des Musikers und alle zugehörigen Alben über die API von TheAudioDB [1].
• Anzeigebildschirm mit den Metadaten (Titel, Bild, Year, Genre und Description) der Alben mit einem sinnvollen Layout. Dabei soll der/die Nutzer*In den Musiker auch einfach für später speichern können und diese Liste sollte auf der Startseite zugänglich sein. (Diese “Favorite-Artists”-Liste muss für A2 nicht über das Schließen der App hinaus gespeichert werden.)

Punkte bekommen Sie aufgeschlüsselt nach den folgenden Kriterien:

• 10%: Erfolgreiche Abgabe des Codes
• 15%: Teil 1 (Start- und Endbildschirm vorhanden)
• 30%: Teil 2 (API-Abfrage und Datenverarbeitung)
• 20%: Teil 3 (Bedienoberfläche und Interaktionen sind schlüssig designt)
• 15%: App läuft flüssig und ohne Bugs im IDE-eigenen Emulator
• 10%: Lesbarkeit und Struktur des Programm-Codes (sinnvolle Klassen- und Methodennamen, Code ist kommentiert, Einrückungen etc.)

=== Für Nicht-InformatikerInnen ===

Ihre Aufgabe umfasst die Gestaltung einer einfachen Musik-Webseite mit mehreren Unterseiten. Die Webseite soll tabellarisch fünf vorher gewählte Musiker / Bands darstellen, welche dann in Unterseiten detailliert mit Alben bzw. Discography zu sehen sind.

Dazu benötigen Sie drei Komponenten:

• Startseite, auf der Sie einen Musiker / eine Band auswählen können. Sie können gerne fünf Musiker Ihrer Wahl festlegen.
• Detailseite zum gewähltem Musiker und die Album-Metainformationen (Titel, Bild, Year, Genre, Beschreibung), die Details über die Alben dieses Musikers in einem sinnvollen Layout zeigt.
• Separate CSS-Datei mit einheitlichem Design für alle Unterseiten

Punkte bekommen Sie aufgeschlüsselt nach den folgenden Kriterien:

• 10%: Erfolgreiche Abgabe des Codes
• 15%: Teil 1 (Start- und Detailseite vorhanden)
• 30%: Teil 2 (Bedienoberfläche und Interaktionen sind schlüssig designt)
• 15%: Teil 3 (CSS-Datei für gesamte Webseite)
• 15%: Webseite wird auf Smartphone-Bildschirm korrekt angezeigt
• 15%: Lesbarkeit und Struktur des HTML- und CSS-Codes (sinnvolle Benennung, Metadaten, Einrückungen etc.)

A2 Abgabe

• Die Abgabe erfolgt über Moodle.
• Erstellen Sie bitte eine .zip (.tar.gz/...)-Datei, welche 3 Ordner beinhaltet: Dokumente, Source, App
• Geben Sie Ihr gesamtes Projekt im Source Ordner ab
• Erstellen Sie eine kompilierte Version Ihrer App und geben Sie diese im Ordner App ab
• Die letzte Abgabe wird für die Bewertung ihrer Grace Days herangezogen.
• Bitte bedenken Sie: Moodle hat eine Uploadgrenze von 250mb. Sollten Sie mehr Speicher benötigen, bitte schreiben Sie und bereits im Vorfeld, dann senden wir Ihnen Informationen zum weiteren Vorgehen.
• Bitte denken Sie daran, dass wir Ihren Code auf Plagiarismus überprüfen werden. Wenn Sie größere Stücke Code von Ihren Mitstudierenden oder aus Online-Tutorials kopieren, wird dies auffallen. Lesen Sie dazu auch unsere Hinweise zum Thema Ehrlichkeit (Link).

Erstellen Sie im Dokumente Ordner eine README.md Datei mit folgender Struktur: Readme-Grundgerüst. Diese trägt maßgeblich zu unserem Verständnis Ihrer Abgabe bei.


Flutter: Flutter kann nur in Android-Version beurteilt werden. Auf folgendem Gerät wird getestet:
Android: Pixel 2, API-Level 27-30
Geben Sie bitte im readme bekannt für welche Version Sie entwickelt haben!

React Native: Sie können entweder für Andriod oder iOS entwickeln. Die Apps werden mit folgendem Setup getestet:
iOS: iPhone 8, iOS 14, 4.7” 1334x750 326 ppi (Xcode 12.3)
Android: Pixel 2, API-Level 27-30
Bitte geben Sie die App kompiliert ab und schreiben Sie Ihre Präferenz (iOS oder Android) in das Readme.

Android: Android Apps werden mit folgendem Gerät (Simulator) getestet/bewertet:
Pixel 2, API-Level 27-30. Geben Sie bitte im readme bekannt für welche Version Sie entwickelt haben!

[1] (für InformatikerInnen) https://www.theaudiodb.com/api_guide.php Die folgende zwei API-Calls sollen für diese Abgabe genügend sein:
Zum Finden eines Musikers mit dem Namen: https://www.theaudiodb.com/api/v1/json/1/search.php?s=coldplay
Zum Finden alle Alben dieses Musikers mit der ID: https://theaudiodb.com/api/v1/json/1/album.php?i=111239