· · · · Theories Beyond the specifics of guidelines Principles are used to develop theories Descriptions/explanatory or predictive Motor task, perceptual, cognitive, or contextual Explanatory and predictive theories · Explanatory theories: · · · · · Observing behavior Describing activity Conceiving of designs Comparing high-level concepts of two designs Training · Predictive theories: · Enable designers to compare proposed designs for execution time or error rates Perceptual, Cognitive, Motor tasks, Contextual · · · · · · Perceptual or Cognitive subtasks theories Predicting reading times for free text, lists, or formatted displays Motor-task performance times theories: Predicting keystroking or pointing times Contextual theories Lack of predictive methods Taxonomy (explanatory theory) · · · · · Order on a complex set of phenomena Facilitate useful comparisons Organize a topic for newcomers Guide designers Indicate opportunities for novel products. Conceptual, semantic, syntactic, and lexical model Foley and van Dam four-level approach · · · · · · · · Conceptual level: User's mental model of the interactive system Semantic level: Describes the meanings conveyed by the user's command input and by the computer's output display Syntactic level: Defines how the units (words) that convey semantics are assembled into a complete sentence that instructs the computer to perform a certain task Lexical level: Deals with device dependencies and with the precise mechanisms by which a user specifies the syntax Approach is convenient for designers · · · Top-down nature is easy to explain Matches the software architecture Allows for useful modularity during design · · · · Relevance for high-level graphics? Model-View-Controller En model for strukturering af interaktionsprogrammering og -programmer Hvert object-of-interest som hhv model, view og controller Patterns Stages of action models Norman's seven stages of action 1. 1. 1. 1. Forming the goal Forming the intention Specifying the action Executing the action 1. 1. 1. Perceiving the system state Interpreting the system state Evaluating the outcome Gulfs of execution and evaluation Design og undersøgelse State and the action alternatives should be visible Should be a good conceptual model with a consistent system image Interface should include good mappings that reveal the relationships between stages User should receive continuous feedback · Four principles of good design · · · · · Four critical points where user failures can occur · · Users can form an inadequate goal Might not find the correct interface object because of an incomprehensible label or icon · action · Model Human Processor · · Card, Moran & Newell 1983 Engineering Psychology · "Design is where the action is in the interface, not evaluation" · · · Task analysis, Approximation, and Calculation May not know how to specify or execute a desired May receive inappropriate or misleading feedback · · · · The Model Human Processor GOMS = Goals, Operators, Methods, Selection rules Additiv Generaliserbar GOMS Performance tid er vigtig (men selvfølgelig ikke alt) Ekspert (der er forskel på brugere) Fejlfri gennemførelse (og altså ikke eksplorativ adfærd heller hvad angår selve opgaven) GOMS · · · · Goals: den opgave/task der skal udføres Operators: "adfærds atomer" Methods: en bestemt sekvens af operatorer (kan være på mange niveauer, se Card et al.) Selection rules: valg mellem metoder · · · · · Mange typer af mere eller mindre avancerede GOMS-modeller Transitionsdiagrammer · · · · Keystroke-level analyse Forudsige den tid det tager en ekspert at lave en fejlfri udførelse af en kendt opgave Unit task T =T +T task acquire execute Method- keystroke-level Operatorer: 4 slags - Keystroking, Pointing, Homing, Drawing M (den mentale operator) og R systemets svar. T =T +T +T +T +T +T execute K P H D M R Object/Action Interface model Syntactic-semantic model of human behavior · · · Distinction made between meaningfully-acquired semantic concepts and rotememorized syntactic details Semantic concepts of user's tasks well-organized and stable in memory Syntactic details of command languages arbitrary and required frequent rehearsal Object/Action Interface model Object-action design: 1. · · 1. 1. understand the task. real-world objects actions applied to those object create metaphoric representations of interface objects and actions designer makes interface actions visible to users OAI (oo-ahh) Et eksempel · Bibliotek · · Bøger, søgeresultater, kateloger Søgning, registrering, browsing (GÅ til bestemte steder) · Boghuset · · Hyggehjørnet, søgestedet, bøger Søgning, registrering, browsing Task hierarchies of objects and actions Computer system designers must generate a hierarchy of objects and actions to model users' tasks: · · · Representations in pixels on a screen Representations in physical devices Representations in voice or other audio cue Interface hierarchies of objects and actions Interface objects and actions based on familiar examples. Users learn interface objects and actions by: · · · seeing a demonstration hearing an explanation of features conducting trial-and-error sessions Principper for direkte manipulation Programmering for børn Et OAI eksempel på DM OAI-modellen som forklaring The OAI Model explanation of direct manipulation (cont.) · · · · · · · · Beneficial attributes: Novices learn quickly Experts work rapidly Intermittent users can retain concepts Error messages are rarely needed Users see if their actions are furthering their goals Users experience less anxiety Users gain confidence and mastery Discussion of Direct Manipulation Problems with direct manipulation · · · · · · Spatial or visual representations can be too spread out Designs may force valuable information off of the screen Users must learn the graphical representations The visual representation may be misleading Typing commands with the keyboard may be faster How direct is it? DM programmering versus syntax dBrug Øvelse 3 Dagen bruges på at analysere og evaluere prototypen fra sidst (en hjemmekontrol eller en pizzabestillingsautomat/website) 1. Læg en plan for dagen. 2. Beskriv jeres prototype i termer af Foleys 4 niveauer (s. 86). a. Diskuter hvordan I kan evaluere de enkelte niveauer b. Diskuter hvordan I kan redesigne jeres prototype så den tager systematisk hånd om alle niveauer (hvis den ikke gør det i forvejen) 3. Gennemfør en gennemgang af prototypen som følger Normans 7 trin (p. 87): 4. Beskriv jeres brug og prototype i Shneidermans OAIdiagrammer. 5. Vis prototypen til en anden gruppe. Hvordan vil gribe det an? Vil I se på, spørge? Hvordan husker I hvad I så og hørte? Hvad skal testpersonen/personerne? Tænke højt, snakke sammen, gennemføre en bestemt opgave, osv.? Foretag derefter en afprøvning, hvor I bytter 12 personer med en anden gruppe (I skal blive mindst 2 personer tilbage til at foretage testen). 6. Diskutér og opsummér hvilke ændringer I vil lave på prototypen efter dagens analyser. Besvarelse Dagens besvarelse opsummerer resultaterne af analyserne (max 3 sider): 1 I besvarelsen skal I give eksempler på hvilke designovervejelser, der hører til på hvilke an Foleys niveauer. I må også gerne diskutere hvor nyttig opdelingen i niveauer er, men det skal foregå med udgangspunkt og argumentation i jeres eksempler. 2. Vælg et vigtigt eksempel ud fra 7trins analysen, men gå IKKE systematisk igennem hele analysen. Derudover må I gerne reflektere over hvor let/svært det var at anvende Normans 7trinsmodel. 3. Præsenter et udsnit af OAIdiagrammet, samt udregningerne under b. Besvarelsen af spørgsmål a og c er ikke nødvendige for at bestå, men skal besvares hvis man vil mere end det. 4. Giv en detaljeret gennemgang af en væsentlig situation fra testen. 5. Skitsér kort forslag til justering af prototypen. 6. (for dem der gerne vil gøre lidt ekstra) Opsummér forskellen på de teoretiske og empiriske analyser af prototypen: Er der forskel på hvilken slags indsigt man opnår ved de to typer af metoder? I besvarelsen lægges vægt på at I kan arbejde systematisk med metoder og begreber, fastholde væsentlige resultater frem for mindre væsentlige, og opsummere resultaterne.