TU Wien:Interface and Interaction Design VU (Wimmer)

Aus VoWi
Zur Navigation springen Zur Suche springen
Ähnlich benannte LVAs (Materialien):

Daten[Bearbeiten | Quelltext bearbeiten]

Diese LVA wird nicht mehr von dieser Person angeboten, ist ausgelaufen, oder läuft aus und befindet sich daher nur noch zu historischen Zwecken im VoWi.
Vortragende Wimmer Christoph
ECTS 3
Aufgezeichnet true
Links tiss:183289 , Homepage
Zuordnungen
Bachelorstudium Wirtschaftsinformatik
Bachelorstudium Medieninformatik und Visual Computing
Bachelorstudium Medizinische Informatik
Bachelorstudium Software & Information Engineering

Mattermost: Channel "interface-and-interaction-design" • Register • Mattermost-Infos

Inhalt[Bearbeiten | Quelltext bearbeiten]

Ähnlich wie in der LVA von Peter Purgathofer soll hier das nötige Know-How zur erfolgreichen Erstellung jeglicher Schnittstellen und Interaktionskonzepte vermittelt werden. Es wird hier aber auch auf die wissenschaftlichen Hintergründe eingegangen.

Ablauf[Bearbeiten | Quelltext bearbeiten]

WS 2019/2020:

Wie im WS 2016/2017, noch immer wöchentliche Vorlesungen und 3 Übungsbeispiele (2x Einzeln, 1x 3er-Gruppe).

WS 2016/2017:

Wöchentliche Vorlesung, parallel dazu 3 Übungsbeispiele mit steigendem Zeitaufwand. Die ersten beiden waren einzeln zu lösen, das letzte gemeinsam in einer 3er-Gruppe. Nähere Infos siehe Abschnitt Übungen.

WS 2011/2012:

Die Beispiele waren vom Aufbau her genau gleich wie im Vorjahr. Beim zweiten Beispiel war die Aufgabe, ein Timetracking-System für Freelancer zu erstellen. Beim dritten Beispiel hatte man die Wahl zwischen einem mobilen Schlüsselsystem oder einem mobilen Zahlungssystem. Man musste ein Mobile-App-Konzept erstellen, ein ca. 10-Seitiges Dokument abgeben und ein Video für die Abschlusspräsentation erstellen.

WS 2010/2011:

Es gibt eine Vorlesung, die nicht besonders fesselnd ist, und 3 laufende Übungsbeispiele inkl. Abgabegespräche für die Gruppenbeispiele. Eines wird selbstständig gelöst und die restlichen zwei in Gruppen.

Beim ersten Beispiel musste man im WS10/11 schlechte und gute Beispiele für verschiedene vorgegebene Interfaces finden, fotografieren und als PDF in TUWEL hochladen.

Das zweite Beispiel war die Erstellung einer Webseite für ein Onlineportal für die Buchung von Flugtickets. Die Technologien im Hintergrund waren gänzlich egal und trugen nicht zur besseren oder schlechteren Bewertung bei. Wesentlich wichtiger war hier die Dokumentation, die die Überlegungen, Ideen und Mockups beschreiben sollten, die man während der Erstellung der Website hatte. Dazu gab es dann ein mehr oder weniger sinnvolles Abgabegespräch, wo man sich 10 Minuten über Fragen wie "Wieso ist der Button nicht orange?" unterhalten musste.

Im dritten Beispiel musste man exemplarisch mit Hilfe von Mockups o.Ä. ein automatisiertes Heimsystem erstellen, das man per Handy ansteuern kann. Für das Abgabegespräch war neben der Dokumentation auch noch eine passende Präsentation (Comics, Videos, etc.) vorzubereiten. Auch hier gab es ein ähnliches Abgabegespräch.

Benötigte/Empfehlenswerte Vorkenntnisse[Bearbeiten | Quelltext bearbeiten]

  • WS22/23: Keine HTML Kenntnisse notwendig, sämtliche Übingsbeispiele wurden mit Figma/Penpot erstellt
  • WS16/17: Für Bsp. 2 und 3 waren HTML-, CSS- und JavaScript-Kenntnisse von Vorteil. Bootstrap bereits zu kennen schadet auch nicht.
  • Einige Inhalte werden auch von Basics of Human Computer Interaction VU bereits bekannt sein.

Vortrag[Bearbeiten | Quelltext bearbeiten]

Nicht besonders mitreißend und die Folien sind leider auch nicht wirklich zu gebrauchen oder sinnvoll.

Andere Meinung: Kommt stark auf das persönliche Interesse an, finde die Folien sehr gut gelungen und verständlich.

Weitere Meinung: Die Folien sind keine klassischen "akademischen" Folien mit einer Wall of Text aus Definitionen sondern enthalten eher viele Bilder und Stichwörter dazu. Es sind aber genug Inhalte vorhanden, sodass man nicht in die Vorlesung gehen muss.

Übungen[Bearbeiten | Quelltext bearbeiten]

WS2022/23:

Die Struktur der Übungsbeispiele ist weiterhin ähnlich aber der Inhalt hat sich leicht geändert. Die ersten beiden Beispiele sind Einzelaufgaben und das letzte ein Gruppenbeispiel.

  • 1. Bsp (Einzeln): Man musste sich mit dem Konzept von Dark Patterns beschäftigen und danach ein Beispiel in der Praxis finden. Dieses sollte dann dokumentiert werden und man musste einen Lösungsvorschlag angeben.
  • 2. Bsp (Einzeln): Man erhielt Wireframes einer Applikation zur Verwaltung des Budgets eines Users (eine Art Pseudo-Buchhaltungs-App), mit Ausgabenverrechnungen, Statistiken. Diese musste man dann mit irgendeiner Gestaltungssoftware (Figma, Penpot, Powerpoint, ...) als Prototyp umsetzen. Teil der Aufgabe war auch dies gemäß der Material Design Guidelines zu erstellen. Abweichungen oder Fehler sollten schriftlich festgehlaten werden.
  • 3. Bsp (Gruppe): Die Erstellung eines durchklickbaren und herzeigbaren Prototyps der App aus Bsp 2. Man sollte hier Funktionalität wie Links auf verschiedene Seiten simulieren und Demos für wichtige Features erstellen. (Eintragen von neuen Ausgaben, Suchen von Eingaben, etc.). Es war nicht gefragt, dass man diese auch wirklich implementiert aber man sollte sie auf irgendeine Weise demonstrieren können. Für die Aufgabe konnte man wieder die Software frei wählen. Zu empfehlen ist mMn Figma/Penpot, jedoch ist ein Html/Css Prototyp sicher auch einfach wenn man damit einiges an Erfahrung hat.

WS2017/18:

Ähnlich zu WS2016/17, nur dass das 2. Bsp auch eine Gruppenarbeit war. Für 2. und 3. Bsp gab es jeweils ein Abgabegespräch bei dem kurze Fragen zur Lösung gestellt wurden. Man sollte gut Diskutieren und Verhandeln können.

WS2016/17:

3 Übungen mit steigendem Zeitaufwand:

  • 1. Bsp (Einzeln): Man sollte ein selbst gewähltes, in der Vergangenheit selbst erstelltes Programm analysieren (ich habe das Einzelbeispiel aus Software Engineering und Projekt-Management gewählt). Dazu durfte man sich irgendeine der enthaltenen Funktion aussuchen und musste sie dann beschreiben (Eingabe, interne Datenverarbeitung, Feedback an den Nutzer, ...) und Verbesserungsvorschläge nennen. Außerdem sollten die beiden Themen Affordance und Mapping durch zwei kleine Beispiele aus dem realen Leben (inkl. selbstgemachter Fotos) erklärt werden.
  • 2. Bsp (Einzeln): Es wurde eine Website in Form einer html-Datei vorgegeben, in der allerdings nur Text und Bilder vorhanden waren. Diese sollte man dann entsprechend den in der Vorlesung besprochenen Richtlinien designen. Dazu bietet sich natürlich CSS an, man hätte es aber auch z.B. komplett in Photoshop machen können, da der Code selber nicht in die Bewertung miteingeflossen ist.
  • 3. Bsp (3er-Gruppe): Es sollte ein durchklickbarer und herzeigbarer Prototyp einer Webapplikation erstellt werden (diesmal verpflichtend mit html, css und dem Bootstrap-Framework). "Echte" Funktionalität war nicht gefragt (also kein Backend oder Datenbank), aber man sollte alle wichtigen Links anklicken und alle wichtigen Seiten anschauen können. Das Thema des Projekts durfte man sich mit ein paar Einschränkungen selber auswählen. Für dieses Bsp gab es auch ein Abgabegespräch.

WS2012/13:

Modus der Übung blieb gleich, nur Abgabegespräche sind nun nicht mehr verpflichtend sondern freiwillig mit vorheriger Anmeldung (zahlt sich aber aus, vor allem wenn man wenig Punkte bekommen hat und es beim nächsten Beispiel besser machen möchte)

1. Übung: Es waren mehrere schlecht designte Interfaces im alltäglichen Leben zu suchen, zu fotografieren und genau zu erleutern warum diese schlecht sind.

2. Übung: Wireframes zu einer Applikation zur Verwaltung des Budgets eines Users (eine Art Pseudo-Buchhaltungs-App), mit Ausgabenverrechnungen, Statistiken erstellen etc. Dazu sollte einmal eine Applikation für Webbrowser und eine für Smartphones durchgeplant werden, zusätzlich noch Personas und natürlich Use Cases dazu.

3. Übung: Die geplante Web-App aus Teil 2 soll in die Tat umgesetzt werden - mithilfe von HTML, CSS und JS (Bootstrap-Framework). Spätestens hier zahlt es sich aus beim Abgabegespräch aus Teil 2 gewesen zu sein, da man nochmals die Chance bekommt alles nochmal bei Bedarf umzuändern. Zusätzlich sollen Funktionen der App, welche aufgrund von Einschränkungen (es sollte ja keine Funktionalität geben) nicht vorhanden sind oder nur teilweise vorhanden sind, erläutert und begründet werden warum man in diesem statischen Prototypen diese eben nicht darstellen kann.

WS2011/12:

Der Modus hat sich eine Spur geändert, da das 3. Beispiel nun vor ein paar weiteren Gruppen präsentiert werden musste. Die Präsentation pro Gruppe dauerte im Schnitt 10 - 15 Minuten, wobei zusätzlich ein von den Gruppen erstelltes Konzeptvideo abgespielt wurde. Insgesamt saß man etwa 1 1/2 Stunden bei den Vorträgen. Was vor allem auffällig war: je später die Stunde, desto "entnervtere" Tutoren, dann am besten besonders kurz halten, sonst wird man prompt dazu aufgefordert :)

WS2010/11:

1 selbstständiges Übungsbeispiel, 2 Gruppenbeispiele + je ein Abgabegespräch a 10 min. Organisation und Abgabe über TUWEL.

Tipps zum User Interface Design für diese LVA[Bearbeiten | Quelltext bearbeiten]

Hier kommen für Aspiranten dieser LVA unerlässliche Tipps, wie man User Interfaces erstellt, die der UE-LVA-Leitung genehm sind.

  • Es darf nie zwei unterschiedliche Wege geben, um ähnliche, aber nicht gleiche Ziele zu erreichen. Beispiel: Es wurde eine elektronische-Geldbörse-Smartphone-App vorgestellt. Zum Aufladen von Geld auf die Geldbörse gab es zwei Optionen: Entweder man lädt explizit auf (ähnlich wie auf eine Quick-Karte) oder man verbindet die App mit einem Konto/Kreditkarte, wo automatisch abgebucht wird. Mit dieser Vorstellung war die LVA-Leitung offensichtlich überfordert.
  • Es ist besser, Wireframes mit Papier und Bleistift zu zeichnen als mit elektronischen Tools. Offensichtlich werden "digitale" Wireframes kritischer beurteilt; während bei digitalen Wireframes saure Rückfragen darüber kommen, dass der Button nicht wie ein Button aussieht (obwohl es sich offensichtlich um eine WIREFrame handelt), erspart man sich mit handgezeichneten Wireframes derartige Diskussionen.
  • Achtet darauf, dass eure Applikation nicht mehr als zwei Features enthält; jedes dieser Features muss mit einem einzigen Button anklickbar sein. Denkt an die schlechten Klischees über Apple-Software: Es ist besser, eine gut aussehende Applikation herzustellen, die dem User keinerlei Freiheiten lässt, als eine Applikation mit mehr als vier Buttons, in der der User gewisse Wahlmöglichkeiten hat. (Tipp: Es ist jedoch möglich, ein drittes Feature einzubauen, solange es sich um ein unnötiges Feature handelt.)
  • Einfacher scheint besser zu sein, beim Abgabegespräch zum 3. Beispiel wurde unsere Gruppe mit einem deutlich einfacherern Interface als die anderen Gruppen viel weniger gefragt.

Prüfung, Benotung[Bearbeiten | Quelltext bearbeiten]

Wenn man auf alle Übungsbeispiele halbwegs Punkte bekommen hat, dann ist es ein leichtes, die LVA zu bestehen, da man für den Abschlusstest keine gewisse Anzahl an Punkten erreichen muss. Man kann mit den Übungsbeispielen allein, ohne Prüfung, bereits auf ein B3 kommen. Weiters ist zur Prüfung ein quasi überdimensionaler Schummelzettel erlaubt - ein beidseitig beschriebener A4 Zettel, der lediglich handgeschrieben sein muss, sonst ist es aber egal, was drauf steht.

Die Prüfung besteht aus ein paar MC-Fragen und offenen Fragen (siehe auch den Test in Materialien).

WS16/17: Die Prüfung wird offiziell nur einmal am Semesterende angeboten, allerdings gibt es bei Verhinderung auch einen Termin im März auf Anfrage. Die Prüfung im WS 2016/17 war wohl zu 90-95% gleich mit der in den Materialien. Es reicht also grundsätzlich sogar für eine sehr gute Note, wenn man die Antworten vorbereitet und auf den Schummelzettel überträgt. Allerdings sei gesagt, dass die Antworten zu den Freitextfragen ausführlich sein sollten und alle Stichwörter aus der VO vorkommen sollten. Dies gilt auch, wenn in der Angabe steht, dass man den Sachverhalt in einem Satz erklären soll. Zu oberflächliche Antworten führen also nur zu Teilpunkten.

WS17/18: Kann ich aus dem Vorjahr so bestätigen. Es kamen viele Altfragen, es wurde aber eher streng benotet. Dennoch bleibt der Aufwand in einem angenehmen Rahmen und ein Gut ist mit vollständig abgegebenen Übungsteil machbar.

Dauer der Zeugnisausstellung[Bearbeiten | Quelltext bearbeiten]

Semester Letzte Leistung Zeugnis
WS10/11 18.01.2011 10.02.2011 Punkte wurden am 26.01. bekanntgegeben
WS19/20 14.01.2020 30.01.2020 Punkte am 20.01.

Zeitaufwand[Bearbeiten | Quelltext bearbeiten]

  • eher gering - für die Übungsbeispiele den einen oder anderen Nachmittag einplanen.
  • ca. 4/8/16 h für die Übungsbeispiele (= 28 h) und ein paar Stunden für den Test vorbereiten.

WS2019/2020:

  • noch immer ein eher geringer Aufwand, bin zwar insgesamt auf ca. 50h gekommen, habe mich jedoch sehr intensiv mit den Übungsbeispielen beschäftigt → man wäre sicher auch mit dem halben Arbeitsaufwand gut durchgekommen

Unterlagen[Bearbeiten | Quelltext bearbeiten]

Tipps[Bearbeiten | Quelltext bearbeiten]

Sich bei den Abgabegesprächen nicht zu sehr entnerven lassen und halt alle sinnvollen und sinnlosen Fragen beantworten.

Zumindest bei uns war es so, dass er beim Abgabegespräch Dinge über unser Interface wissen wollte und meinte, dass sei nicht gut. Wir haben ihm so lange Argumente dafür gebracht bis er irgendwann meinte, "Ja habts schon recht". Mein Tipp: Wenn man überzeugt ist, dass es gut ist, einfach auf der Meinung bleiben (Ich denke mal Voraussetzung ist, dass man auch ungefähr weiß warum man das so gemacht hat ;))

Bei uns war es ein bisschen anders: Wir haben dem Tutor zwar unsere Idee genau geschildert, aber da vor allem einer besonders bissig war, haben wir ihm irgendwann bei seinen (zum Teil etwas seltsamen) Ideen "natürlich Recht" gegeben und dadurch wurden uns kaum Punkte abgezogen. Ist also fraglich, wie man das machen möchte.


Andere Meinung (WS22): (Fast) keine Kritik beim Abgabegespräch, die Sachen, die angemerkt wurden, wurden eigentlich begründet und auch so akzeptiert, nachher trotzdem recht gute Abzüge. Allgemein so gut wie keine Begründung der Benotung, selbst auf Nachfrage.

Verbesserungsvorschläge / Kritik[Bearbeiten | Quelltext bearbeiten]

Bis jetzt war es aus meiner Sicht eine nicht besonders sinnvolle LVA. Der Stoff an und für sich ist wirklich interessant - aber die Umsetzung nicht besonders. Mehr so ein BlaBla-Fach.


Die Assignments sind sehr unklar beschrieben und gleichzeitig wird erwartet, dass man exakte Aussagen macht und in jedem Satz "intent communication" erwähnt. Die Feedbacks wiedersprechen sich in jeder Hinsicht und fühlen sich oftmals so an, als hätte man unsere Abgabe garnicht richtig gelesen und die Umsetzung der Verbesserungsvorschläge ist somit auch schwer. Aufgrund der ganzen Fragen im Forum kann man auch erkennen, dass es vielen anderen Studenten genauso geht. Wenn alle Autos auf der Autobahn einem entgegenkommen, sollte man sich wirklich die Frage stellen, ob wirklich all' die anderen Schuld sind, oder nicht man selbst...

Abgerufen von „https://vowi.fsinf.at/index.php?title=TU_Wien:Interface_and_Interaction_Design_VU_(Wimmer)&oldid=170558“