hilberer.com

...Weltmeister!

Nunja, zumindestens ich. ;-)

Das aber richtig: Heute Kolloquium (1,0 für die Master Thesis).

*freu*

Labels: FH, privates

Gestern habe ich meine Master Thesis abgegeben. Mission Accomplished ;-).
Aber jetzt bin ich erstmal urlaubsreif und ich freue mich auf die Berge.

Irgendwie fühle ich mich ja schon so ein bisschen wie Butter auf zuviel Brot verstrichen, wenn Ihr wisst, was ich meine.

Egal, am 17. geht es los und dann sind erstmal zwei entspannende Wochen angesagt.



Also hierhin:


Größere Kartenansicht

Labels: FH, Kaprun, privates, Urlaub

Fast 2 Wochen sind seit der FedCon vergangen. Zeit genug, um die Eindrücke ein wenig wirken zu lassen und ein paar schöne Impressionen rauszusuchen. :-)
















ein klassischer Zylone auf seinem Weg durch das Publikum












ein mächtiger Klingone mit Banner
auch das Imperium war mit Mann und Maschine vertreten

















leider gab es auch solche obszönen Bilder, wie diese bekleidete weibliche Ferengi :O



















dagegen mein persönliches Highlight: René Auberjonois (Odo, Paul), hier beim Singen des Kochliedes von Ariel



















auch sehr nett: Nicky Cline von Kampfstern Galactica:

Labels: FH, Fun, star trek

Am kommenden Wochenende sind wir wieder auf der diesjährigen FedCon vertreten. Wer mag, kann ja gerne mal vorbeikommen. Ben fährt Samstags hin und hat, glaube ich noch Platz im Auto.
Ansonsten werde ich hier oder Ben bei Gomtuu über die Veranstaltung berichten.

Wenn ich dazu komme, gibt's auch Live-Bilder.

So lange schon mal eine Impression von unserer FH. :-)

Labels: FH, Fun

Eine Form der Evaluation von User Interfaces ist die heuristische Evaluation. Hierbei betrachten Experten ein User Interface und benutzen Ihre Expertise über allgemein anerkannte Schwachstellen, um es zu bewerten.
typische Problemstellen nach Nielsen:

• einfache und natürliche Dialoge?
• wird die Sprache des Users benutzt oder eine technische Systemsprache (Bsp.: Error: Systembuffer overload) ?
  
• muss sich der User zu viel merken? (Informationen die der User noch benötigt sollen weiterhin angezeigt werden)
• Konsistenz des Interfaces
• bekommt der Benutzer Feedback?
• gibt es klar definierte Exit-Points?
• Shortcuts
• Fehlermeldungen müssen sinnvoll sein und weiterhelfen
• Fehler möglichst vermeiden
  

Labels: FH, Human Factors, Usability

Design Patterns sind allgemeine Vorlagen, die dazu dienen standardisierte Lösungen für gleichartige Probleme zu bieten.
Sie dienen dazu, Expertenwissen zu kapseln. Ein Experte könnte vermutlich zu einem speziellen Problem eine bessere Lösung finden, als ein allgemeines Design Pattern bietet.
Da aber Experten teuer und rar sind, bietet sich ein Patternbasierter Ansatz an, um schneller zu einem zufriedenstellenden Ergebnis zu kommen.

Im folgenden betrachten wir das Pattern "Process Funnel", für die meisten Nuttzer in Form eines "Wizard" oder "Assistenten" bekannt. Im besonderen sind bei der Verwendung von "Process Funnel" folgende Punkte zu beachten:

• komplizierte Vorgänge in mehrere zusammenhängende Schritte aufteilen
• Problem: Back-Funktion
  
• dürfen nicht zu lang sein
• Nutzer muss erkennen können, wie weit er im Prozess ist

Labels: FH, Human Factors, Usability

Wie in den klassischen Ingenieurwissenschaften dienen Prototypen auch bei der Software Entwicklung dazu, Konzepte auf ihre Tauglichkeit zu überprüfen oder Feedback zu einer angestrebten Lösung einzuholen.
Prototypen bieten immer die Möglichkeit, für verschiedene Stakeholder über Produkte zu sprechen, die noch in der Entwicklung sind.

Arten nach Ausführung

• low fidelity (Papier)
• high fidelity (klickbare UI)

Arten nach Focus

• vertikal
• horizontal
• diagonal

Prototypen können alles mögliche sein: PowerPoints, Tafelbilder, Holzstücke, Photoshop Drawings, Websites, Software, Flash,...


Ziele:

• Evaluation
• Feedback
• Kommunikation
• Stakeholder Info
• PoC
  

Labels: FH, Human Factors, Usability

Im User Centered Design Process geht es darum, eine möglichst optimale Gestaltung der Interaktion zwischen dem (archetypischen) Benutzer und einem interaktiven System zu gestalten, damit eben auch die User Experience.

Jesse James Garret stellt in seinem Buch "The Elements of User Experience " eine Hierarchie der Elemente der User Experience vor:

1. Strategie (input Benutzer / Kontext / Business goals)
   
2. Scope (output task analyse)
   
3. Structure (Navigation und "Pageflow" des User Interface)
   
4. Skeleton (Screenlayout und funktionale Teile des Screens == Wireframe)
   
5. Surface (fertiges visuelles Design)
   

Ein Element kann das folgende validieren, muss aber nicht vollständig sein, um das folgende zu erstellen. Die einzelnen Schritte werden also iterativ (auch stufenübergreifend) durchlaufen.
Näherer Informationen findet man auf Garrets Website.

Labels: FH, Human Factors, Usability

Usability - ROI
Usability ist ein teurer Spaß, beschäftigt man doch hochbezahlte Experten, die wiederum Stakeholder von der Arbeit abhalten und nach einem langen UCD hat man oft noch keine Zeile Code entwickelt.
Daher die Frage: Lohnt sich der Aufwand? Was bekomme ich zurück für meine Investition?


Returns:

• erhöhte Produktivität der Benutzer
• Reduzierung der nutzerverursachten Fehler
• geringere Schulungskosten
  
• geringere Entwicklungskosten durch besseres Anforderungsmanagement
• geringere Supportkosten (vgl. "Ein anruf bei der Hotline vernichtet Gewinn bei diesem Kunden")
• höhere Zufriedenheit der Benutzer (-> Motivation)
• höhere Zufriedenheit der Kunden (-> Marktanteil)

Für alle Freunde betriebswirtschaftlicher Kennzahlen lässt sich der ROI auch berechnen:

Berechnung der Einsparung von Mitarbeiterarbeitszeit (z.B. keine redundante Eingabe in versch. Systeme, automatisierungen, Workflowunterstützung):
(eingesparte Zeit / Arbeitszeit) x Kosten pro Angestellter x Mitarbeiterzahl = Einsparung

Einsparung von Kosten durch Bedienfehler
Fehleranzahl x Reparaturdauer x durchschn. Stundensatz = Kosten durch Bedienfehler

Labels: FH, Human Factors, Usability

Auch beim Erstellen der Benutzerschnittstellen gibt es gewisse Prinzipien, die man beherzigen sollte.

Designprinzipien sind abstrakter, als etwa Design Patterns. Es gibt sie projektspezifisch und allgemein.
Manche Prinzipien haben eine gewisse allgemeingültigkeit, andere beziehen sich auf bestimmte Kontexte oder Systeme.

Als allgemeine Anleitung, wie man Design Prinzipien findet, könnte das folgende gelten:

Design Prinzipien = theoretisches Wissen + Erfahrung + gesunder Menschenverstand

• klare Beschriftungen (Labels) wählen
• klare Mappings ermöglichen (wenn ich hieran etwas ändere, wird sich folgendes ändern...)
• Nähe ermöglicht Mapping
• Farbcodierung ermöglicht Mapping
• siehe Gestaltgesetze
• nur die Aktionen zulassen, die im Moment erlaubt sind ("ausgrauen")
• phyische Einschränkungen nutzen (z.B. Floppy kann nur auf eine Art in das Laufwerk eingelegt werden)
• logische Einschränkungen nutzen (Metaphern und mentale Modelle aus dem Alltag nutzen, z.B. Ampel)
• kulturelle Vereinbarungen nutzen (international vs. spezifisch)
• Feedback an den User geben, wenn eine Handlung ausgelöst wurde
• "Wenn Anweisungen von Nöten sind, gibt es Raum für Verbesserungen"
• "Dinge, die unterschiedlich aussehen, sollten sich unterschiedlich Verhalten. - Dinge die gleich aussehen, sollten sich gleich verhalten"
• Konsistent bleiben

Probleme von Design Prinzipien:

• zu allgemein oder zu trivial (zu abstrakt oder zu konkret)
  
• schwierig das Richtige für den Kontext zu finden
• schwierig zu interpretieren (für ein spezifisches System)
• teilweise widersprüchlich
• mögliche Alternative: Design Patterns ("Baukasten")
  

Labels: FH, Human Factors, Usability

Wie der Name schon sagt, wird beim User Centered Design Prozess der Benutzer in den Mittelpunkt der Betrachtung gestellt.

Dies erscheint als Forderung vordergründig trivial. Betrachtet man jedoch die heute etablierten Entwicklungsprozesse, so stehen meist noch immer fachliche (business processes) und technische Anforderungen im Fokus der Software Entwicklung. Der Benutzer wird oft erst in der Testphase oder gar beim Release der Software miteinbezogen.

Im User Centered Design wird dagegen versucht, eine auf die Benutzerzielgruppe maßgeschneiderte Lösung zu entwickeln. Für alle die mit klassischen Softwareentwicklungsprozessen vertraut sind, wir befinden uns der Requirements Phase.
Dabei wird in etwa so vorgegangen:

Informationen gewinnen: User / Task Analysis

• Analyse und Modellierung der Benutzer und ihrer Ziele, Aufgaben und Arbeitsstile (goals / tasks/working styles)
• Mittel:
  
• Dokumente analysieren (Manuals, Beschreibungen, Regeln, Business Processes...)
• Fragebögen (Factual vs. Opinion, multiple choice, numeric / text open-end questions)
  
• semi-structured Interviews in der Arbeitsumgebung des Benutzers (besser als (un)structured)
• goal-directed questions
• Opportunity: Welche Aktivitäten verschwenden Ihre Zeit?
• Goals: Was macht einen "guten Tag" aus?
• Priorities: Was ist Ihnen wichtig?
• Information: Was unterstützt den Entscheidungsprozess?
• system-oriented questions
• Function: Worin bestehen die gewöhnlichen Tätigkeiten, die Sie mit dem Produkt ausführen?
• Frequency: Welcher Teil des Produktes wird am häufigsten benutzt?
• Preference: Welche Teile des Produktes sind am angenehmsten, welche am unangenehmsten?
• Expertise: Welche Shortcuts nutzen Sie?
• workflow-oriented questions
• Process: Was war Ihre erste Handlung, als Sie heute zur Arbeit kamen? Und die nächste...
• Occurence und Reoccurence: Wie oft machen Sie dies? Was machen die jede Woche oder jeden Monat aber nicht täglich?
• Exception: Wie läuft ein typischer Tag ab? Was wäre ein ungewöhnliches Ereignis?
  
• Beobachtung
• Zeit mit den Stakeholdern verbringen, während sie arbeiten

Informationen aufbereiten: Personas und Scenarios, Requirements und Usability Goals

• Personas (= archetypische Benutzer)
• "lebendige" Beschreibungen
• Persona hat Ziele, Möglichkeiten, Neigungen und einen Hintergrund
• repräsentiert die Zielgruppe an greifbarem Beispiel
• gegen self-referential design
• Infos aus den Interviews / Observations die in die Personas einfließen:
• Activities: Was tut der User? (Frequenz und Ausmaß)
  
• Attitudes: Wie denkt der User über die Domäne des Produktes und die Technologie?
• Aptitude: (Aus)bildung des Users und seine Möglichkeiten zu lernen
• Motivations: Warum betägtigt sich der User in der Domäne des Produktes? (vgl. Interview: Wie wird man Fleischfachverkäuferin?)
  
• Skills: Möglichkeiten und Fähigkeiten des User capabilitiesbezogen auf die Domäne und Technologie
• Personatypen
• Primary Persona
  
• 1 pro Interfacevariante
• Interface muss auf die Primary Persona zugeschnitten sein, ohne andere Personas zu zu kurz kommen zu lassen
• Secondary Personas
• typischerweise 0-2
  
• Persona ist absolut zufrieden mit dem Interface der Primary Persona mit einigen Änderungen
• Negative Personas
• repräsentiert Nutzergruppe, die explizit beim Design nicht berücksichtigt wird
• Scenarios
• Scenarios haben ein erfüllbares Goal
• sie setzen sich aus kleineren Tasks zusammen
• nutzen Sprache der Stakeholder
• Fördern Verständnis warum Leute was wie tun
  
• Requirements
• spezifiert was ein Produkt tun soll / wie es sich verhalten soll
• so spezifisch, klar und eindeutig wie möglich
• Arten von Requirements:
• Functional
  
• Technological
• Data
• Environmental / Context
  
• System Use
• User
• Usability (->Usability Goals and Measures)
  
• Usability Goals
• klären Prioritäten
• auf ihrer Basis sind "tradeoff decisions" möglich
• Ermöglichen Fokusieren von Aufmerksamkeit und Resourcen

Ergebnisse veranschaulichen: Das Framework

• konzeptuelles Framework, das sowohl den Zielen der Personas als auch denen der Organisation gerecht wird
• Beschreibung zentraler Elemente und Features
• Beschreibung der Information Architecture und der Hauptbestandteile der Navigation
• UI Konzept (vorgegebene Workflows vs. freie Navigation, Multi- oder Singledocument, ...)
  

Refinement

• fertige Dokumentation kann an den Auftraggeber übergeben werden
• Specs und Styleguides
• UI Samples
  

Labels: FH, Human Factors, Usability

Einige Stichworte zum Thema Human Factors / Human Computer Interaction:

• Usefullnes (Nützlichkeit)
• ein interaktives System kann zum Erreichen bestimmter Ziele genutzt werden
• Utility (Nutzwert)
• die Funktionalitäten des Systems um die Ziele zu erreichen sind prinzipiell im System enthalten
  
• Usability (Benutzerfreundlichkeit)
  
• wie gut können benutzer die Funktionalitäten nutzen
• Effektivität + Effizienz + Zufriedenheit
  

Ein interaktives System sollte folgende Anforderungen erfüllen:

• Aufgabenangemessenheit
• Selbstbeschreibungsfähigkeit
• Erwartungskonformität
• Fehlertoleranz
• Steuerbarkeit (Dialog steuerbar? -> Richtung/Geschwindigkeit beeinflußbar, undo-Funktion)
• Individualisierbarkeit
• Lernförderlichkeit (System ermöglicht es dem Benutzer an ihm zu wachsen)
• Memorierbarkeit (Einarbeitung nach längerer Nutzungspause?)
  

Labels: FH, Human Factors, Usability

...das Semester neigt sich dem Ende zu. Es wird wieder Zeit für Klausuren und Projekte.

Da ja bekanntlich bei uns nur die Besten der Besten der Besten den Master of Science Informatik studieren (Ihr glaubt mir nicht? Dann schaut Euch doch mal die offiziellen Brochüren an), ist uns natürlich kein Projekt zu anspruchsvoll und keine Klausur zu schwierig.

Für unser Projekt Requirements Tracking in einem SAP Distributed Development Process haben wir uns wieder zum Alphateam zusammengefunden, um die Aufgaben zu stemmen. Eigentlich hätten wir noch lieber als Gang of Four gearbeitet, aber bei 5 Teilnehmern im Kurs ein 4er Team zu bilden erschien nicht ganz angemessen. ;)
So müssen es der fließend UML sprechende Softwareengineer Meister Schwenker und meine informationsarchitektierende Wenigkeit wieder einmal richten. Bin mal gespannt, wann man uns ruft, um die ISS zu flicken.
Technorati Profile

Labels: FH, Fun

Wie Ihr seht, war ich am Wochenende auf der FedCon in Bonn. Mein Chef hielt dort zwei Vorträge, da bot sich eine Hinreise an.
(Die Orion-Frau hat übrigens versucht, mich mit ihren Pheromonen gefügig zu machen, hat sie aber aufgrund meiner vulkanisch anmutenden Logikfähigkeiten glücklicherweise nicht geschafft.)

Was ich professionell bei Dr Rainer Nagel mitnehmen konnte: Linguisten sind uns Informatikern irgendwie ähnlicher als ich bisher dachte. Sie lieben Bäume, bauen Grammatiken und bilden Äquivalenzklassen.

Fazit: Toller Event, sehr entspannte, nette Leute, gelungene Vorträge. Und Cpt. Janeway ist cool, nur schlecht synchronisiert (todo: Voyager auf englisch ansehen).
Technorati Profile

Labels: FH, forschung, Fun, star trek

Gerade war an unserer sommerlich-schwitzenden Hochschule ein netter Vortrag über das Social Web. Dabei wurde in erfrischenderweise auf inflationäre Buzzwordnutzung verzichtet - außer vielleicht seitens des Publikums.

However, um diesen sinnlosen Post zu finalisieren, wenn Ihr noch ein paar schöne neue Buzzwords habt, die Ihr der digitalen Bewegung zukommen lassen wollt, schreibt sie einfach ins Bolsche-Wiki oder schreibt sie auf Charmin-Toilettenpapier und spült sie runter, demnächst gibts bestimmt einen Webservice, der die auswertet und online stellt, außer die Blase blatzt zuvor.

Hiermit erkläre ich die Schreibblogade für beendet, vielleicht steckts Schommi Crane ja an.

Labels: FH, Fun, tech talk

...oder der Flyer aus dem schwarzen Sumpf der Gestrigen.

Nun unser Tag des offenen Campus ist vorüber und kam offensichtlich auch recht gut an - Zeit sich einen Moment mit dem bitteren Nachgeschmack der Werbeflyer zu beschäftigen:

Die beauftragte Agentur entschied sich bei der Auswahl der Fotomodelle für die Flyer für eine eher fragwürdige Quelle - fragwürdig zumindest dahingehend dass man sie einer politischen Gruppierung zuordnen muss, die - vorsichtig formuliert - tendentiell eine eher unbefriedigende Bildungspolitik betreibt (etwa die Studentenzahlen durch Studiengebühren reduziert oder Reformen des Bildungssystems aus monetären oder schlimmer ideologischen Gründen erfolgreich verhindert) und nun natürlich auch noch schamlos damit wirbt (siehe Link oben - Nachtrag: Inzwischen gelöscht).

Es verbleibt die Frage im Raum: Peinliche Panne oder Arglistige Absicht seitens der Agentur?

So oder so wirft diese Aktion kein gutes Licht auf die - ansonsten gute - Zusammenarbeit der FH mit der Agentur.

Schade, das können wir besser.

P.S: Ein Glück, dass ich seit gestern politisch blogge. ;-)

Labels: FH, politik

Wie man auf dem Photo rechts (dafür Danke an Daniel "Danny" Crane) sieht war an unserem schönen Institut der gemeine Fotograf los und hat tolle Werbebilder für neue Flyer geschossen.

Als Prominenter war es für mich natürlich keine Frage, dem Ruf der Kameras zu folgen. Um auch meinem schönen neuen T-Shirt gerecht zu werden, ist's hiermit geblockt.

Achja, noch ein Wort zur aktuellen Klimadiskussion: "Das Wetter ist nicht das Klima" (Prof. H. Lesch)
Technorati Profile

Labels: FH, Fun

... meine Alma Mater hat ein Einsehen gehabt und mich als Assistent für Technische Informatik und Signalverarbeitung eingestellt. Dann schauen wir dochmal, was sich da an Synergieeffekten für mein Masterstudium rausholen lässt.

Heute wurde ich erstmal von den neuen Kollegen freundlich aufgenommen und ich freue mich schon drauf, wenn ich meine Arbeitsmaterialien (Kleinigkeiten, wie Rechner oder Schreibtisch) zusammen habe und richtig loslegen kann.

P.S: Jetzt wird auch wieder gebloggt, 2 Wochen Krankheit reichen nämlich echt, jetzt. :)
Technorati Profile

Labels: FH