Einzelaufgaben

Es gibt zwei Einzelaufgaben. Diese sind allein, d.h. nicht im Team zu bearbeiten. Gänzlich oder teilweise identische Abgaben werden nicht bewertet und führen zu einem X für die Lehrveranstaltung. Siehe Ehrlichkeit.

Die Deadlines für die Abgaben der Einzelaufgaben finden Sie unter Terminplan. (Deadline Zeitpunkt: 23:59; Datum: jeweils im Terminplan gekennzeichnet)


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
  • Bennen Sie Ihre Abgabe bitte nach folgendem Schema: <Matrikelnummer>_<Nachname>_A1.pdf
  • Für Informatiker*innen: Laden Sie Ihre Lösung in einer pdf-Datei auf GitLab hoch. Es wurde ein Projekt für Sie erstellt nach dem Muster: HCI_22s_A1_userid. Dort laden Sie das PDF in den Rootfolder hoch. Für den Upload ist es notwendig, dass Sie einmalig auf GitLab angemeldet sind. Weitere Informationen dazu finden Sie hier.
  • Für Nicht-Informatiker*innen: Laden Sie Ihre Lösung in einer pdf-Datei auf Moodle hoch.
  • 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 Informatiker*innen ===

Installieren Sie das Programmier-Framework (Android, 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 Musiker*innen zu finden. Ziel der App ist es, die relevanten Metadaten über eine Band und ihre Alben von der Datenbank abzufragen und dem*der Nutzer*in anzuzeigen.

Die App soll aus drei Komponenten bestehen:

  • Startseite, auf der Sie es 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 MusicBrainz [1].
  • Anzeigebildschirm mit den Metadaten (Titel, Bild, Release-Jahr, Album-Type) der Alben mit einem sinnvollen Layout. Dabei soll der*die Nutzer*in die Band 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.)
A2 Abgabe für Informatiker*innen
  • Die Abgabe erfolgt über GitLab im Projekt mit folgendem Format: HCI_22s_A2_uaccountUserID.
  • Ihr gesamtes Projekt (d.h. der gesamte Code) sollte im Root-Folder liegen. Die App muss kompilierbar sein, ansonsten wird die Abgabe mit 0 Punkten bewertet.
  • Nur für React Native: Erstellen Sie eine kompilierte Version Ihrer App und geben Sie diese in einem Ordner "App" ab.
  • Der letzte Commit wird für die Bewertung ihrer Grace Days herangezogen.
  • Erstellen Sie eine README.md Datei mit folgender Struktur: Readme-Grundgerüst. Diese trägt maßgeblich zu unserem Verständnis Ihrer Abgabe bei.
  • 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 .
Test-Geräte:

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!

=== Für Nicht-Informatiker*innen ===

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

Dazu benötigen Sie drei Komponenten:

  • Startseite, auf der Sie eine*n Musiker*in / eine Band auswählen können. Sie können selbst fünf Musiker*innen Ihrer Wahl festlegen.
  • Detailseite zur gewählten Band und die Album-Metainformationen (Titel, Bild, Year, Genre, Beschreibung), die Details über die Alben dieser Band 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 für Nicht-Informatiker*innen
  • Die Abgabe erfolgt über Moodle.
  • Erstellen Sie bitte eine .zip (.tar.gz/...)-Datei, welche 2 Ordner beinhaltet: Dokumente, Source
  • Geben Sie Ihr gesamtes Projekt im Source Ordner 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).

[1] (für InformatikerInnen) https://musicbrainz.org/doc/MusicBrainz_API
Bitte beachten, damit MusicBrainz Sie nicht blockiert: Provide meaningful User-Agent strings - https://musicbrainz.org/doc/MusicBrainz_API/Rate_Limiting#Provide_meaningful_User-Agent_strings
Die folgende drei API-Calls sollen für diese Abgabe genügend sein:
Zum Finden eines Musikers mit dem Namen: https://musicbrainz.org/ws/2/artist/?query=coldplay&fmt=json
Zum Finden alle Alben dieses Musikers mit der ID: https://musicbrainz.org/ws/2/artist/cc197bad-dc9c-440d-a5b5-d52ba2e14234?inc=release-groups&fmt=json
Zum Finden des Cover-Bilds eines Album: https://coverartarchive.org/release-group/1dc4c347-a1db-32aa-b14f-bc9cc507b843