Werkmodul Nutzerstudien/Sicherheit und Benutzbarkeit

jeden Donnerstag, 13:30 bis 16:45, Marienstraße 7 B - Seminarraum 102 (siehe auch: Die Veranstaltung im Vorlesungsverzeichnis)

Aktuelles

Beschreibung

wer liest mit? (Bild: Dahlström, CC-BY)
Interviewen
Analysieren

Warum ist eine App nützlich und nutzbar, eine andere nicht? Wie kann ich herrausfinden was meine Nutzer brauchen?

Im Werkmodul Nutzerstudien werden wir Design und die Funktionen von Apps zur sicheren Kommunikation entwickeln und verbessern.

Wir werden:

  • Durch unsere Gespräche und Beobachtungen mehr über Nutzer lernen
  • Lernen, welche psychologischen Prinzipien bestimmen, ob etwas leicht oder schwierig zu benutzen ist und damit Designen.
  • Wir werden unsere Designs ausprobieren lassen und so Verbesserungsmöglichkeiten erkennen und neue Ideen bekommen.


Um zu lernen, wie wir diese Methoden in der Praxis anwenden, haben wir eine Praxiskooperation mit dem Guardian Project. Wir haben die Aufgabe, sichere Kommunikation über mobile Apps zu verbessern. Mitarbeiter des Projektes werden uns beraten und Feedback für eure Ideen geben.

Kommunikation, die nicht einfach abgehört oder Personen zugeordnet werden kann, ist für Bürgerrechtler und Journalisten essentiell, wird aber auch von Personen verwendet, die ihre Rechte im Netz nicht geschützt sehen.

Leider ist die Nutzung solcher Methoden nicht einfach. Sicherheitsexperte Bruce Schneier z.B. gibt Tips, sieht diese Tips aber kritisch, denn: »My five tips [for more security] suck. They are not things the average person can use. […] Basically, the average user is screwed.« (aus einem Interview mit dem MIT Technology Review) Zwar wird oft auf »Nutzererziehung« verwiesen. Das Argument entschuldigt auch die unbenutzbarsten Lösungen – und selbst erfahrene Nutzer scheitern z.B. an Verschlüsselungsprogrammen. Besser wären Lösungen, die praktisch, gut benutzbar und sicher sind. Wir wollen zu solchen Lösungen beitragen.

Häufige Fragen

Muss ich Programmieren können? Nein.

Ist das hier alles theoretisch? Nein, der Kurs ist nicht theoretisch, im Gegenteil, wir werden die gelehrten Methoden anwenden und sie nutzen, um eine anwendbare, praktische Lösung für Probleme zu schaffen.

Ist das wissenschaftlich? Jein. Es ist wissenschaftlich in dem Sinne, das die Gestaltung auf (eigenen) Erkenntnissen beruht, die wir auch kritisch hinterfragen. Nicht wissenschaftlich ist, das wir konkrete Probleme lösen, anstatt ein allgemeines Modell zu erstellen. (Vergleiche "Wie verhindere ich, das es umfällt?" mit "warum fallen Dinge nach unten?")

Voraussetzungen

  • Bereitschaft zu eigener Forschung und Weiterentwicklung von Ideen. Mit einem Konzept, dessen Umsetzung für euch schon absolut feststeht, wird der Kurs freud- wie erkenntnislos.
  • Texte auf Englisch lesen, denn es gibt wenig Literatur zu dem Gebiet auf deutsch. Wir lesen nicht viel, und ich wähle keine Texte aus, die den Leser mit nebulös-abstrakten Begriffen beeindrucken. Aber es ist hilfreich, sich damit zu beschäftigen was andere bisher herausgefunden haben.

Bewertung

  • Dokumentation (im WikiHaiwaiian for ''fast'' (not an acronym). It is the name for a hypertext system for websites where the user may not only read the content but is also able to change it instantaneously through the browser., dabei an die Struktur des Arbeitsbuches halten)
  • Vortrag
  • Anwesenheit (regelm., max 3x fehlen)

Anmelden

Mail an jan.dittrich ÄT uni-weimar.de mit

  • Name, Vorname
  • Matrikelnummer
  • Studiengang
  • Kurzer Text der erklärt, warum ihr Teilnehmen möchtet.

Vortragsthemen| student presentations

Mögliche Vortragsthemen. Bitte nutzt die bereitgestellten Quellen, und macht dann eine eigene Recherche. Bereitet das Thema auf, macht es anschaulich und nicht einfach nur eine Nacherzählung der Quellen (oder der Stichpunkte auf den Slides).

Vortragsdauer: 15-20min


Zeitplan

  • 24.10: Einführung | Introduction
  • 31.10 : Feiertag
  • 7.11: Security
  • 14.11 : Nutzerforschung: Beobachten und Fragen stellen | User Research: Observing and Asking Questions
  • 21.11: Datenanalyse, Szenarioerstellung | Analyse Data, Create Scenarios
  • 28.11: Idenentwicklung | Idea Development
  • 5.12.: Prototyping

[…]

  • 12.12: 1st Feedback round

[…]

Gruppe Anmeldung

  • 16.01: heuristische Analyse und Schwachpunkte herausarbeiten

Treffen um den PaperMockUp gestalten
Prototyp in den nächsten zwei Wochen testen (evtl. mehrere Iterationsschritte)

  • 23.01: Feedback | vorläufige Ergebnisse zusammentragen
  • 30.01: Verbesserungen vornehmen

Treffen um WikiHaiwaiian for ''fast'' (not an acronym). It is the name for a hypertext system for websites where the user may not only read the content but is also able to change it instantaneously through the browser.-Seite zu aktualisieren

  • bis vorlesungsfreie Zeit => Feedback

Gruppe Sicherheit

  • 16.01.: Heuristische Analyse fertigstellen und Schwachpunkte der App finden
  • 23.01.: Prototypen verbessern (je nach Zeit: für Hoch- und Querformat) und Klickdummy anfertigen
  • 30.01.: Fertiggestellten Klickdummy testen
  • 06.02: Tests auswerten; Anfangen für die Dokumentation zu sammeln


Presentation and Documentation of Works

First use self observation

/firstUseChatSecure

Mid-Term-Presentations and Mentor Comments

End-Term-Presentation

Heuristic Analysis


Team Anmeldung: view the summary

Team Sicherheit view the summary

Die Analyse sollte am spätestens am 16.1. fertig sein

Beachtet

  • Jedes Mitglied der Gruppe macht die Analyse für die Themenfelder der Gruppe (s.o.) selber (= keine Zusammenarbeit), da jede Person andere Fehler findet, sodass sich die Analysen ergänzen.
  • Bitte so dokumentieren, dass die Analyse und ihre Ergebnisse dem Lehrenden (Jan) und dem ChatSecure Team verständlich sind. Schreibt auf Englisch (wenn möglich, sonst Deutsch) und nutzt Screenshots oder Skizzen.

Für Material siehe Abschnitt Materialien/Heuristische Analyse auf dieser Seite

Endabgabe

Termine

  • Bis zum Vorlesungszeitende (7.2.) sollen die Entwürfe und Forschungen fertiggestellt sein.
  • Bis zum Mi, 5.März 2014 ist die Dokumentation für den Lehrenden und die Designs und Erklärungen für den Projektpartner fertigzustellen. Auf diese Version gibt es Feedback (ca. am 10.), die fertige, darauf hin verbesserte und entgültige Version ist ca. eine Woche später, am 16. März abzugeben.

Anforderungen

  • Gruppe oder/und einzeln? Dokumentation für den Lehrenden und die Designs und Erklärungen werden pro Gruppe erstellt. Wichtige Infos oder Erfahrungen (e.g. eine Person hatte diese und jene Probleme mit dem Interview und hat sich deshalb entschiedenen diese und jene Änderungen anm Vorgehen zu machen) sind mitzudokumentieren (u.U. anonym)
  • Struktur/Inhalt: Die Dokumentation für den Lehrenden lehnt sich am besten an das Arbeitsbuch an. Möglicherweise sind nicht alle methodischen Vorschläge auf euer Projekt zutreffend, in diesem Fall kann es sinnvoll sein, die "Abweichung" zu erklären (xyz ist nicht gut geeignet weil …, deshalb haben wir die methode xyz benutzt", um das und das zu machen)
  • Format:Die Designs und Ergebnisse für den Projektpartner sind im WikiHaiwaiian for ''fast'' (not an acronym). It is the name for a hypertext system for websites where the user may not only read the content but is also able to change it instantaneously through the browser. zu veröffentlichen, die Doku an den Lehrenden im WikiHaiwaiian for ''fast'' (not an acronym). It is the name for a hypertext system for websites where the user may not only read the content but is also able to change it instantaneously through the browser. oder als PDF.
  • Nachvollziehbarkeit: Die Designs und Ergebnisse für den Projektpartner sollen ermöglichen die Ideen in der Software umzusetzen und es soll klar werden wie und warum (oder warum nicht) die Entwürfe so entstanden sind (das Programmieren kosten natürlich auch Zeit, und niemand würde etwas "einfach so" einbauen; Zudem kann es sein das Abweichungen von euren Entwürfen nötig sind – dann sind die Begründungen und Daten wichtig, um etwas ähnliches umzusetzen)
  • Anschaulich machen: Zu den Designs und Ergebnisse für den Projektpartner sollte gehören:
    • Ein Text mit Screenshots und Entwurfsskizzen
    • Ein Prototyp oder eine andere anschauliche Darstellungsform eures/eurer Entwurfes/Entwürfe

Arbeits & Übungshilfen

"Geldscheinmuster" (zu Interviewbeispiel)
  • "Workbook" in Begleitung zur Praktischen Arbeit als Dokumentation, Gedankenstütze und Reflektionsmöglichkeit
  • Interview/Beobachtung: Thema: "Grafiken erstellen"; zum Ausprobieren von Auswertungsmethoden.

Begriffe: Die erwähnten "Bitcoins" sind eine virtuelle Währung; "Offset" bedeutet soviel wie "Abstand".

Die Ergebnisse von Beobachtung und Fragen werden aufbereitet; Hier einige Zusammenhänge, die sich aus der Audioaufnahme herrausarbeiten lasse.

Folien

Links und Materialien

Security/Usability

Kyptografie

Ausprobieren…

Bücher Design

  • Interaction Design: Beyond Human-Computer Interaction – Preece, Rogers and Sharp, ISBN 978-0470665763 Interaktionsdesign-Bezug, darin aber sehr umfassender Überblick
  • Observing the User Experience: A Practitioner's Guide to User Research, Kuneavski, ISBN 978-1558609235

Human Centered Design

Mobile Apps

The Zen of Palm. Gute Zusammenfassung.

Heuristische Analyse

Hinweis: Eine heuristische Analyse kann das Testen nur ergänzen, aber nicht ersetzen!

Software

Nützliches

Meta

...das Designen von Designlehre