HCI Lecture 09 PDF
Document Details
Uploaded by StylishSpessartine
جامعة العلوم والتقانة
Tags
Summary
This document is a lecture on Human-Computer Interaction (HCI). It covers the elements of a WIMP (Windows, Icons, Menus, Pointers) interface, including windows, icons, menus, buttons, toolbars, and dialog boxes. The lecture also discusses menus, types of menus, and design issues, as well as the software lifecycle and the waterfall model.
Full Transcript
HCI Lecture 09 1 elements of the wimp interface windows, icons, menus, pointers +++ buttons, toolbars, palettes, dialog boxes also see supplementary material 2...
HCI Lecture 09 1 elements of the wimp interface windows, icons, menus, pointers +++ buttons, toolbars, palettes, dialog boxes also see supplementary material 2 on choosing wimp elements Windows Areas of the screen that behave as if they were independent – can contain text or graphics – can be moved or resized – can overlap and obscure each other, or can be laid out next to one another (tiled) scrollbars – allow the user to move the contents of the window up and down or from side to side title bars – describe the name of the window 3 Icons small picture or image represents some object in the interface – often a window or action windows can be closed down (iconised) – small representation if many accessible windows icons can be many and various – highly stylized – realistic representations. 4 Pointers important component – WIMP style relies on pointing and selecting things uses mouse, trackpad, joystick, trackball, cursor keys or keyboard shortcuts wide variety of graphical images 5 Menus Choice of operations or services offered on the screen Required option selected with pointer File Edit Options Font Typewriter Screen Times problem – take a lot of screen space solution – pop-up: menu appears when needed 6 Kinds of Menus Menu Bar at top of screen (normally), menu drags down – pull-down menu - mouse hold and drag down menu – drop-down menu - mouse click reveals menu – fall-down menus - mouse just moves over bar! Contextual menu appears where you are – pop-up menus - actions for selected object – pie menus - arranged in a circle easier to select item (larger target area) quicker (same distance to any option) … but not widely used! 7 Menus extras Cascading menus – hierarchical menu structure – menu selection opens new menu Keyboard accelerators – key combinations - same effect as menu item – two kinds active when menu open – usually first letter active when menu closed – usually Ctrl + letter usually different !!! 8 Menus design issues which kind to use what to include in menus at all words to use (action or description) how to group items choice of keyboard accelerators 9 Buttons individual and isolated regions within a display that can be selected to invoke an action Special kinds – radio buttons – set of mutually exclusive choices – check boxes – set of non-exclusive choices 10 Toolbars long lines of icons … … but what do they do? fast access to common actions often customizable: – choose which toolbars to see – choose what options are on it 11 Palettes and tear-off menus Problem menu not there when you want it Solution palettes – little windows of actions – shown/hidden via menu option e.g. available shapes in drawing package tear-off menus are usually those that are heavily graphical anyway, for example line-style or color selection in a drawing package. pin-up menus Some menus are pin-up menus, in that they can be ‘pinned’ to the screen, staying in place until explicitly asked to go away. 12 Dialogue boxes Windows information that pop up to inform of an important event or request information. e.g: when saving a file, a dialogue box is displayed to allow the user to specify the filename and location. Once the file is saved, the box disappears. 13 HCI in the software process 14 the software lifecycle Software engineering is the discipline for understanding the software design process, or life cycle Designing for usability occurs at all stages of the life cycle, not as a single isolated activity 15 The waterfall model Requirements Requirements specification specification Architectural Architectural design design Detailed Detailed design design Coding Coding and and unit unit testing testing Integration Integration and and testing testing Operation Operation and and maintenance maintenance 16 Activities in the life cycle Requirements specification designer and customer try capture what the system is expected to provide can be expressed in natural language or more precise languages, such as a task analysis would provide Architectural design high-level description of how the system will provide the services required factor system into major components of the system and how they are interrelated needs to satisfy both functional and nonfunctional requirements Detailed design refinement of architectural components and interrelations to identify modules to be implemented separately the refinement is governed by the nonfunctional requirements 17 The waterfall model Coding and unit testing – The detailed design for a component of the system should be in such a form that it is possible to implement it in some executable programming language. – After coding, the component can be tested to verify that it performs correctly, according to some test criteria that were determined in earlier activities. 18 The waterfall model Integration and testing – Once enough components have been implemented and individually tested, they must be integrated as described in the architectural design. – Further testing is done to ensure correct behavior and acceptable use of any shared resources. It is also possible at this time to perform some acceptance testing with the customers to ensure that the system meets their requirements. 19 The waterfall model Maintenance – After product release, all work on the system is considered under the category of maintenance, until such time as a new version of the product demands a total redesign or the product is phased out entirely. 20 Verification and validation Real-world requirements and constraints The formality gap Verification designing the product right Validation designing the right product The formality gap validation will always rely to some extent on subjective means of proof Management and contractual issues design in commercial and legal contexts 21 The life cycle for interactive systems cannot assume a linear Requirements Requirements sequence of activities specification specification as in the waterfall model Architectural Architectural design design Detailed Detailed design design Coding Coding and and unit unit testing testing lots of feedback! Integration Integration and and testing testing Operation Operation and and maintenance maintenance 22