Formal Models and Design Spaces for Interaction Techniques

下载 1

知秋一叶

发布于

1866

人观看

#信息技术

The course is mainly about Formal Models and Design Spaces for Interaction Techniques.Generally covered Transition Diagrams, Pragmatic Lexical Syntactic Semantic Conceptual, Conceptual-Semantic-Syntactic-Lexical-Pragmatic, Seeheim Model.

展开查看详情

2 .Why Models? Help understand the space of possible interaction techniques May identify opportunities for new ones Provide a precise description of how interaction techniques work May identify missing parts of design Help evaluate performance and other aspects of interaction techniques E.g., Keystroke Model and GOMS © 2014 - Brad Myers 2

3 .Transition Diagrams Set of states and set of arcs States represent modes of the interaction Arcs go from state to state based on an event © 2014 - Brad Myers 3 Start hover selected Mouse over Mouse away Mouse button pressed Mouse button released Pressed but outside Mouse away Mouse over Do action Mouse button released

4 .Transition Diagrams Set of states and set of arcs States represent modes of the interaction Arcs go from state to state based on an event © 2014 - Brad Myers 3 Start hover selected Mouse over Mouse away Mouse button pressed Mouse button released Pressed but outside Mouse away Mouse over Do action Mouse button released

5 .Transition Diagrams, cont. Simplest form, arcs are user input events. arcs can be extended by listing feedback (output) and semantic actions on the arcs actions usually written in a conventional language (e.g. Java) picture, Olsen text, p. 37 (Fig 3:1) Olsen Jr., D.R., User Interface Management Systems: Models and Algorithms. 1992, San Mateo, CA: Morgan Kaufmann. 5 © 2014 - Brad Myers

8 .Transition Diagrams, cont. "Pervasive states" to handle help, abort, undo, etc. "Escape" transitions to abort (permanently leave) a dialog picture, Olsen p. 53 (Fig 3:11) "Re-enter" sub-dialogs for temporary excursions that return to same place. E.g., help, use calculator, etc. picture, Olsen p. 55 (Fig 3:12) Transitions are taken if no specific arcs from node 8 © 2014 - Brad Myers

9 .Transition Diagrams, cont. " Augmented transition networks" local variables function on arcs can determine transitions "guards" determine whether transition is legal "conditional transitions" calculate where to go picture, Olsen p. 57 (Fig 3:14) upgrades the power to context-free-grammar 9 © 2014 - Brad Myers

10 .Transition Diagrams, evaluation Good Make explicit the interpretation of all events in each state Emphasize the temporal sequence of user and system actions Natural and easily understood if small easy to teach, learn, and read Appropriate for some parts of GUIs: widget behaviors, dialog box transitions, etc. May be appropriate to model transitions around web sites 10 © 2014 - Brad Myers

11 .Transition Diagrams, evaluation Bad Does not scale: 150 commands with 3 or 4 states each explosion of lines and states for normal interfaces: "maze of wires" unordered inputs picture, Olsen p. 91 (Fig 6:1) Doesnt handle GUI mode-free style well What to do with un-specified input? crash, ignore input Doesnt address output 11 © 2014 - Brad Myers

12 .Foley & Wallace, 1974 James D. Foley, Victor L. Wallace and Peggy Chan. “The Human Factors of Computer Graphics Interaction Techniques,” IEEE Computer Graphics and Applications . Nov, 1984. 4(11). pp. 13-48. http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6429355 “Virtual devices” Pick – identify user-defined objects Button – identify system-defined objects (menus) Locator – identify location and/or orientation in drawing space Valuator – indicate a single real number value Also talked about: Lexical, Syntactic, and Semantic levels Lexical & syntactic are the level of interaction techniques © 2014 - Brad Myers 12

13 .13 Pragmatic Lexical Syntactic Semantic Conceptual William Buxton, "Lexical and Pragmatic Considerations of Input Structures," Computer Graphics , January, 1983, (17)1, pp. 31-37. http://dl.acm.org/citation.cfm?id=988586 or local html . Derived from compiler theory and language work. Added 2 more levels to the ones in Foley & Wallace Pragmatic How the physical input devices work required "gestures" to make the input. Ergonomics skilled performance : "muscle memory" press down and hold, vs. click-click © 2014 - Brad Myers

14 .14 Pragmatic Lexical Syntactic Semantic Conceptual, cont. Lexical (as subdivided by Buxton) Spelling and composition of tokens “add” vs. “append” vs. “^a” vs. Where items are placed on the display “Key-stroke” level analysis For input, is the design of the interaction techniques: how mouse and keyboard combined into menu, button, string, pick, etc. Performed by reflex, requires response in about 50 msec. – [Foley, 74] © 2014 - Brad Myers

15 .15 Pragmatic Lexical Syntactic Semantic Conceptual, cont. Syntactic Sequence of inputs and outputs. For input, the sequence may be represented as a grammar: rules for combining tokens into a legal sentence For output, includes spatial and temporal factors Example: prefix vs. postfix “Sentence level” – response of 0.5  2 sec [Foley’74] © 2014 - Brad Myers

16 .16 Conceptual-Semantic-Syntactic-Lexical-Pragmatic, cont. Semantic Functionality of the system; what can be expressed What information is needed for each operation on object What errors can occur Application level – typically not interaction techniques Semantic vs. UI is key issue in UI tools but "semantic" is different than meaning in compilers "Semantic Feedback“ Depends on meaning of items Example: only appropriate items highlight during drag © 2014 - Brad Myers

17 .17 Pragmatic Lexical Syntactic Semantic Conceptual, cont. Conceptual Extra level, added by Foley & Van Dam: James D. Foley, Richard L. Phillips, John F. Hughes, Andries van Dam, and Steven K. Feiner. 1994. Introduction to Computer Graphics . Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. (1 st edition) Key application concepts that must be understood by user User model Objects and classes of objects Relationships among them Operations on them Example: text editor objects = characters, files, paragraphs relationships = files contain paragraphs contain chars operations = insert, delete, etc. © 2014 - Brad Myers

18 .18 Seeheim Model © 2014 - Brad Myers Resulted from the 1st UI software tools workshop which took place in Seeheim , Germany. Nov 1-3, 1983. Logical model of a UIMS UIMS = User Interface Management System (old name for user interface software) All UI software must support these components, but are they separated? How interface? Note that input and output are entirely separate

22 .22 Model-View-Controller Glenn Krasner and Stephen T. Pope, "A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80", Journal of Object-Oriented Programming (JOOP). August-September, 1988. vol. 1, no. 3. pp. 26-49. pdf scan at UCI Invented in Smalltalk, about 1980 Idea: separate out presentation (View), user input handling (Controller) and "semantics" (Model) which does the work Fairly straightforward in principal, hard to carry through Never adequately explained (one article, hard to find) Goals program a new model, and then re-use existing views and controllers multiple, different kinds of views on same model © 2014 - Brad Myers

24 .24 MVC Model Simple as an integer for a counter; string for an editor Complex as a molecular simulator Views Everything graphical Layout, subviews , composites Can be multiple per model Controller Schedule interactions with other VCs A menu is a controller Usually 1-to-1 with Views © 2014 - Brad Myers

25 .Interactors [Myers, 1990] Brad A. Myers. 1990. A new model for handling input. ACM Trans. Inf. Syst. 8, 3 (July 1990), pp. 289-320. http://doi.acm.org/10.1145/98188.98204 or local pdf . Idea: provide reusable behavior objects that would encapsulate all parameterizations needed Create all widgets and other interactions using just these behavior objects Independent of the graphics Parameterized by which event causes it to start/stop/abort, objects affected, call-back when finished, feedback type, etc. First successful implementation of the “C” part of MVC Kinds (as revised in Amulet ) Choice- lnteractor – choose one or more of a set Move-Grow- Interactor – move or grow existing objects, with gridding, minimum size, flip-if-change size, etc. New-Point- Interactor – enter 1 or 2 or n new points Angle- Interactor - rotation Text- Interactor – text editing Gesture- Interactor – traces that can be recognized © 2014 - Brad Myers 25

26 .Human Performance Modeling John, B. E. (2003) "Information processing and skilled behavior." Chapter 4 In J. M. Carroll, (Ed.), Toward a multidisciplinary science of human computer interaction . Morgan Kaufman. pp. 55-101. Goal: Compute measures of human performance without needing to do user tests Use a “model” of how people work, that has been validated to be reasonably accurate, given certain assumptions Works well for low-level, expert tasks “How long will it take to enter this sequence of commands?” Errors (both novice and skilled) Research on higher-level, problem solving tasks Visual search, figure out how to do things, etc. 26 © 2014 - Brad Myers

27 .© 2014 - Brad Myers Wouldn’t it be great… Reference: Stuart K. Card, Thomas P. Moran and Allen Newell. The Psychology of Human-Computer Interaction. Hillsdale, NJ, Lawrence Erlbaum Associates. 1983. Just point Mr. Bubblehead (the Model Human Processor) at a system, automatically generate performance measures, in context, AND see what’s inside its “mind” and “heart”? Better yet, point Mr. Bubblehead at design ideas (systems that haven’t been built yet) Fast, cheap, easy to interpret Quantitative measures to help persuade 27

29 .© 2014 - Brad Myers The simplest model : the Keystroke-Level Model (KLM) Stuart K. Card, Thomas P. Moran, and Allen Newell. 1980. The keystroke-level model for user performance time with interactive systems. Commun . ACM 23, 7 (July 1980), pp. 396-410. http://dl.acm.org/citation.cfm?id=358895 Pre-defined level of detail: K (keystroke), P (point with mouse), H (home between devices), M (mental operator), R (system response time) Procedure for constructing a sequence of operators that perform a task Heuristics for placing mental operators Input: A suite of benchmark tasks that are important to your design or evaluation A specification of the proposed system Output: A prediction of the time it would take a skilled user to perform the benchmark tasks on the proposed system Accurate to within about 20% of observed performance Appropriate for skilled performance, without problem solving 29

0点赞

0收藏

1下载