TMI 3053 -Human Computer Interaction

1. 2. Design phase

1.1. LU 7 - Work Reengineering and Conceptual Design

1.1.1. Work reengineering - identifying how a UI can best support users’ work. (task allocation)

1.1.1.1. Automation makes possible.

1.1.1.2. Supports business goals.

1.1.1.3. Minimize retraining by having new product tap.

1.1.2. Task allocation - deciding how various tasks will be shared between the user and the computer system

1.1.2.1. Designer needs to decide:

1.1.2.1.1. Who or what kind of data/knowledge necessary to accomplish a task.

1.1.2.1.2. Who or what will physically accomplish the task.

1.1.2.2. Use scenarios & essential use cases - for task allocation process

1.1.2.2.1. Use scenarios > essential UC > concrete UC

1.1.2.2.2. Use scenarios focus on the users and how they will carry out their tasks.

1.1.2.2.3. Essential UC does not contain any specific details. (e.g. tech used / task details)

1.1.2.2.4. Concrete UC added details to the essential UC.

1.1.2.2.5. Conceptual design - establishes underlying structure & organisation of the UI.

1.2. LU 8 - Design Guidance and Design Rationale

1.2.1. Sources of design guidance

1.2.1.1. 1. Design principles

1.2.1.1.1. 4 important design principles:

1.2.1.2. 2. Design rules

1.2.1.3. 3. Standards

1.2.1.3.1. A set of internationally agreed design principles/ approaches that define standards for UI design.

1.2.1.3.2. Standards doc. are official & publicly available.

1.2.1.3.3. International Organization for Standardization (ISO)

1.2.1.4. 4. Style guides

1.2.1.4.1. A description of the required interaction styles and the user interface controls, covering both the required look (appearance) and feel (behavior).

1.2.1.4.2. 2 types:

1.2.1.5. 5. Guidelines

1.2.1.5.1. Limitations:

1.2.2. Design for accessibility

1.2.2.1. 7 Principles of universal design to support accessibililty

1.2.2.1.1. 1. Equitable use

1.2.2.1.2. 2. Flexibility in use

1.2.2.1.3. 3. Simple & intuitive use

1.2.2.1.4. 4. Perceptible info

1.2.2.1.5. 5. Error tolerance

1.2.2.1.6. 6. Low physical effort

1.2.2.1.7. 7. Size & space for approach & use

1.2.2.2. 14 general principles of accessible design according to W3C

1.2.2.2.1. 1. Provide alt. to auditory & visual content.

1.2.2.2.2. 2. Don't rely on colour alone.

1.2.2.2.3. 3. Use markup & style sheets.

1.2.2.2.4. 4. Clarify usage of natural language.

1.2.2.2.5. 5. Create table that transform gracefully.

1.2.2.2.6. 6. Ensure pages featuring new tech. transform gracefully.

1.2.2.2.7. 7. Ensure user control of time-sensitive content (gif).

1.2.2.2.8. 8. Ensure direct accessibility of embedded UI.

1.2.2.2.9. 9. Design for device-independence.

1.2.2.2.10. 10. Use interim solutions (temporary accessibility).

1.2.2.2.11. 11. Use W3C tech. & guidelines.

1.2.2.2.12. 12. Provide context & orientation info.

1.2.2.2.13. 13. Provide clear navigation mechanism.

1.2.2.2.14. 14. Ensure that doc. are clear & simple.

1.2.3. Design rationale - design decision made & reason(s) why the decision was made.

1.2.3.1. The reasons & benefits for documenting it:

1.2.3.1.1. Provide info to justify.

1.2.3.1.2. Provide explicit representation

1.2.3.1.3. Provide systematic & principled way of doing things

1.2.3.1.4. Provide record

1.2.3.1.5. Provide documentation for people to understand

1.2.3.1.6. Provide ability to reuse parts of the UI

1.3. LU 9 - Interaction Design

1.3.1. Human Action Cycle, Norman (1998)

1.3.1.1. The cycle shows the way users perform actions and tasks to achieve their goals.

1.3.1.2. Adapted for understanding interaction process.

1.3.1.2.1. Form goal > Formulates tasks > Specifies actions > Does actions > Perceive outcome > Interprets outcome > Evaluates outcome

1.3.1.3. 3 main stages :

1.3.1.3.1. 1. Goal formation

1.3.1.3.2. 2. Execution stage

1.3.1.3.3. 3. Evaluation stage

1.3.2. Norman & Draper's view (1986)

1.3.2.1. Used to communicate the designer’s understanding of the system, while reflecting an awareness of the user’s existing mental model

1.3.2.2. Consists of:

1.3.2.2.1. Designer's model

1.3.2.2.2. User's model

1.3.2.2.3. System image

1.3.3. Use metaphors to develop accurate mental models

1.3.3.1. Figure of speech / analogy of some sort.

1.3.3.1.1. i.e.: The trash icon on the desktop resembles a trashcan irl. / the paper in MS Word.

1.3.3.2. All UIs are artificial environments created by the computer, which we can understand only because of our experience of the physical world

1.3.3.2.1. Users might not be familiar of certain metaphors due to age/culture differences

1.3.3.3. Should be iterative and user centered.

1.3.3.4. UI must be usable w/ or w/out metaphors.

1.4. LU 10 - Interaction Styles

1.4.1. The ways a user can communicate with a computer system (and vice versa), in term of appearance and behaviour of UI components.

1.4.2. Types of interaction styles:

1.4.2.1. Command line

1.4.2.1.1. First interactive dialog style to be commonly used.

1.4.2.1.2. Pros:

1.4.2.1.3. Cons:

1.4.2.2. Menu selection

1.4.2.2.1. A set of options from which the user must choose.

1.4.2.2.2. Offer cues for user recognition rather than forcing the users to recall the syntax of a command. (Recognize > recall)

1.4.2.2.3. Name & icons should be self-explanatory

1.4.2.3. Form-fill

1.4.2.3.1. Allow for easy movement around the form and for some fields to be left blank.

1.4.2.3.2. Include correction facilities.

1.4.2.3.3. Mimic predictable order.

1.4.2.3.4. Guidelines:

1.4.2.4. Direct manipulation

1.4.2.4.1. Allows user to interact directly w/ UI objects.

1.4.2.4.2. i.e.: Drag a file from one folder to another.

1.4.2.4.3. WYSIWYG - what you see is what you get.

1.4.2.5. Anthropomorphic

1.4.2.5.1. Aims to interact with users in the same way that humans interact with each other.

1.4.2.5.2. Requires an understanding of hardware, software and how humans communicate with each other.

1.4.2.5.3. Why we need it?

1.5. LU 11 - Choosing Interaction Devices (hardware) and Interaction Elements (Software)

1.5.1. Hardware components

1.5.1.1. I/O devices

1.5.1.1.1. Keyboard / keypads / buttons

1.5.1.1.2. Pointing devices

1.5.1.1.3. Screens

1.5.1.1.4. Loudspeakers

1.5.1.1.5. Head mount display (HMD)

1.5.1.1.6. Stereoscopic displays

1.5.2. Software components

1.5.2.1. Text

1.5.2.1.1. Small files.

1.5.2.1.2. Can be manipulate easily.

1.5.2.1.3. Less ambiguous.

1.5.2.1.4. Factors affect legibility:

1.5.2.2. Colour

1.5.2.2.1. Why?

1.5.2.2.2. Intrinsic brightness

1.5.2.3. Images

1.5.2.3.1. Reasons:

1.5.2.3.2. Type of images:

1.5.2.4. Moving images

1.5.2.4.1. Animations & video clips

1.5.2.5. Sound

1.5.2.5.1. Useful as an output when people cannot easily see a visual prompt.

1.5.2.5.2. Requires when:

1.5.2.5.3. Sound effects can:

1.5.2.5.4. Michaelis & Wiggins (1982) - speech outputs is most effective when the message:

1.5.2.5.5. Sound is not good at conveying detailed information unless accompanied by text, video or still images. (concatenation prob.)

1.6. LU 12 - Moving from Choosing Components into Design Areas

1.6.1. Principles of good layout

1.6.1.1. 1. Create natural groupings

1.6.1.1.1. Group together all menus and icons relating to particular concept.

1.6.1.1.2. Make visible boundary around grouped menus / icons.

1.6.1.2. 2. Separate currently active components

1.6.1.2.1. The tab bars of a browser, active windows will be at the top while title bar will be highlighted. (hover effect)

1.6.1.3. 3. Emphasize important components

1.6.1.3.1. Stress on components that really matter.

1.6.1.3.2. Panic button is red colour.

1.6.1.4. 4. Use white space effectively

1.6.1.4.1. Areas on screen that do not contain any other software components.

1.6.1.4.2. Clarify the layout of the UI better.

1.6.1.5. 5. Make controls visible

1.6.1.5.1. Obvious function

1.6.1.5.2. Complements psychological principle, recognize > recall

1.6.1.6. 6. Balance aesthetics & usability

1.6.1.6.1. Coloured mobile phones targeted at teenagers

1.6.1.6.2. The limited coloured range of MacBooks.

1.6.2. Design areas

1.6.2.1. GUI

1.6.2.1.1. Choose and combine the correct widgets.

1.6.2.2. Web

1.6.2.3. Embedded systems

1.6.2.3.1. Technological convergence - merging of different design areas.

1.7. *LU 13 - Designing a Graphical User Interface (GUI)

1.7.1. Appearance of widgets in diff. pieces of software

1.7.1.1. Different OS has different widgets

1.7.1.1.1. i.e.: MacOS vs Windows OS

1.7.2. Choosing widgets to strucutre the interaction

1.7.2.1. 1. Primary windows

1.7.2.1.1. Often corresponds to the main task objects in conceptual design.

1.7.2.1.2. Acts as a base to which the user keeps returning. (Launch pad)

1.7.2.2. 2. Secondary windows

1.7.2.2.1. Complements primary window.

1.7.2.2.2. Provide additional functionality and support for the user.

1.7.2.3. 3. Tabs

1.7.2.3.1. For classifying the properties of a task object represented by a window.

1.7.2.3.2. Organize data = less complete screens.

1.7.3. Choosing widgets to control interaction

1.7.3.1. 1. Menus

1.7.3.1.1. Drop down menus

1.7.3.1.2. Cascading menus

1.7.3.1.3. Roll-up menus

1.7.3.1.4. Pop-up menus

1.7.3.2. 2. Tool bars

1.7.3.2.1. A program can have a selection of different tool bars each for different areas in the program’s functionalities. (The top thingy in MS Word)

1.7.3.2.2. Can be made invisible / hidden.

1.7.3.2.3. Desirable properties (Horton, 1991):

1.7.3.3. 3. Command button

1.7.3.3.1. Used for controlling operations of dialog boxes.

1.7.3.3.2. Issues to be considered:

1.7.4. Choosing widgets to enter information

1.7.4.1. 1. Option buttons

1.7.4.1.1. A.K.A . radio button, can only select one.

1.7.4.2. 2. Check boxes

1.7.4.2.1. When user required to choose more than one.

1.7.4.3. 3. List boxes

1.7.4.3.1. Allow user to choose from large no. of options (country of origin).

1.7.4.4. 4. Text boxes

1.7.4.4.1. Use if it is not possible to anticipate user input or if you do not wish to constrain choice.

1.7.4.4.2. List box + Text box = combo box

1.7.5. Combining GUI widgets

1.7.5.1. i.e.: Your typical sign in page.

1.8. *LU 14 - Designing for the Web

1.8.1. *Design principles for websites (HOMERUN), Nielsen (2000)

1.8.1.1. 1. High quality content

1.8.1.1.1. Provide info / function that target users want.

1.8.1.2. 2. Often updated

1.8.1.2.1. Update content regularly

1.8.1.3. 3. Minimal download time

1.8.1.3.1. Slow download pages = frustration

1.8.1.3.2. Avoid unnecessary graphics / videos / animations.

1.8.1.4. 4. Ease of use

1.8.1.4.1. User can find what they need quickly and easily .

1.8.1.5. 5. Relevant to user's needs

1.8.1.5.1. Allow user to carry out the tasks they want to perform.

1.8.1.6. 6. Unique to online medium

1.8.1.6.1. Benefits of using a website vs. hardcopy.

1.8.1.7. 7. Net-centric corporate culture

1.8.1.7.1. Good websites can be the difference between success or failure .

1.8.2. Designing websites

1.8.2.1. 3 specific areas for designing websites:

1.8.2.1.1. Designing the website structure

1.8.2.1.2. Help users to know where they are

1.8.2.1.3. Help users to navigate around the site

1.8.2.2. Navigation aids

1.8.2.2.1. Provide users with an overview of the site structure and enable them to move around the site.

1.8.2.2.2. Link + link = navigation aids

1.8.3. Designing home page & interior page

1.8.3.1. 1. Home page

1.8.3.1.1. The first page you'll see when opening a website.

1.8.3.2. 2. Interior page

1.8.3.2.1. Other pages within site once home page is left.

1.8.4. Design issues for webpages

1.8.4.1. 1. Widgets on webpages

1.8.4.2. 2. Scrolling

1.8.4.2.1. Scrolling horizontally = interrupts reading flow

1.8.4.3. 3. Design for diff. screens & platform

1.8.4.3.1. Handheld devices = small screen issue

1.8.4.3.2. Visually impaired = larger type size

1.8.4.3.3. Specify image-safe area

1.8.4.4. 4. Use screen area effectively

1.8.4.4.1. White space, emphasizing info structure

1.8.4.4.2. > 50% screen content

1.8.4.5. 5. Improve download time

1.8.4.5.1. Cut down unnecessary content

1.8.4.6. 6. Design for accessibility

1.8.4.6.1. Low vision

1.8.5. Writing content of webpages

1.8.5.1. 1. Keep text to minimum

1.8.5.2. 2. Enable users to scan to pick important points

1.8.5.2.1. Meaningful headings

1.8.5.2.2. Include bulleted & numbered lists

1.8.5.2.3. Emphasize important issues & topics

1.8.5.3. 3. Divide long blocks of text into separate sections

1.8.5.3.1. Split into sections

1.8.5.3.2. Associate links

1.8.5.3.3. Split text into chunks

1.9. *LU 15 - Design of Embedded Computer Systems and Small Devices

1.9.1. Design of embedded computer systems

1.9.1.1. 1. Safety critical systems

1.9.1.1.1. Computer systems in which human and environmental safety are of paramount concern.

1.9.1.1.2. Take into account hazards that may arise & how users can be supported.

1.9.1.2. 2. Information Appliances (IA)

1.9.1.2.1. An application specialising in information, designed to perform specific task and the ability to share info among themselves.

1.9.1.3. Design guidelines:

1.9.1.3.1. 1. To select vs to type

1.9.1.3.2. 2. Be consistent

1.9.1.3.3. 3. Consistency between platforms

1.9.1.3.4. 4. Design stability

1.9.1.3.5. 5. Provide feedbacks

1.9.1.3.6. 6. Forgiveness

1.9.1.3.7. 7. Use metaphors

1.9.1.3.8. 8. Clickable graphics should look clickable

1.9.1.3.9. 9. Icons to clarify concepts

1.9.1.4. Guidelines specific to manufacturer

1.9.1.4.1. Follow the guidelines provided to create 3rd party app.

1.9.1.5. Guidelines for kiosks

1.9.1.5.1. Error tolerant

1.9.1.5.2. Easy to learn

1.9.1.5.3. Used by everyone

1.9.2. Guide to Mobile app UI design

1.9.2.1. 1. Minimize cognitive load

1.9.2.1.1. Less friction & user's confusion = higher chances user to retain the app.

1.9.2.2. 2. Optimize interactions for the medium

1.9.2.2.1. Consider the different constraints for desktops and handheld devices.

1.9.2.2.2. Designed elements should look like how they behave.

1.9.2.3. 3. Design finger-friendly tap targets

1.9.2.3.1. The case of "fat fingers", hehehehe

1.9.2.3.2. Make actionable elements in mobile interfaces big enough & w/ proper spacing in between.

1.9.2.3.3. Rule of thumb: design controls that have touch area of 7-10 mm.

1.9.2.3.4. Consider thumb zone

1.9.2.4. 4. Design for interruption

1.9.2.4.1. Allow users to re-engage w/ an app when they return to it after interruption.

1.9.2.4.2. Doesn't refresh notifications automatically.

1.9.2.5. 5. Intuitive gestures

1.9.2.5.1. Only use gestures that are most natural for an app.

1.9.2.5.2. When visible control is replaced w/ a gesture = increase learning curve for app

1.9.2.6. 6. Make the app appear fast w/ skeleton screens

1.9.2.6.1. Mobile app must be fast and responsive, but it may not be possible at all time, due to Internet connection.

1.9.2.6.2. It doesn't involve data loading hence user's attention can focus on the progress instead of wait time.

1.9.2.7. 7. Design zero state

1.9.2.7.1. The state in which nothing has yet to occur.

1.9.2.7.2. Provide direction & guidance for getting up & running w/ the app.

1.9.2.7.3. Never show a blank canvas or dead-end interface.

1.9.2.7.4. Make error message readable & helpful.

1.9.2.8. 8. Use functional animation to improve interaction

1.9.2.8.1. Make the interface alive and responsive.

1.9.2.8.2. Visible system status.

1.9.2.8.3. Visual sign of progress = sense of control over app

1.9.2.9. 9. Role of animation in mobile app

1.9.2.9.1. Navigational transition

1.9.2.9.2. Visual feedback

1.9.2.10. 10. Humanize digital experience

1.9.2.10.1. Personalization

1.9.2.10.2. Delightful animation

1.9.2.11. 11. Push the value

1.9.2.11.1. Each notification should be valuable & well-timed.

1.9.2.11.2. Avoid sending too many notifications in short period

1.9.2.11.3. Time your notification

1.9.2.11.4. Consider other channels to deliver your message

1.9.3. UI Design Guide for Wearable technologies UI design

1.9.3.1. 1. Design for glanceability

1.9.3.1.1. Info being designed for short moments of interaction.

1.9.3.1.2. Only display crucial info on the screen.

1.9.3.2. 2. Design for context

1.9.3.2.1. Context is the backbone for a wearable device.

1.9.3.2.2. Provide info in a glance.

1.9.3.2.3. Utilise built-in device sensor (Geolocation).

1.9.3.3. 3. Design lightweight interactions

1.9.3.3.1. User interaction as short as possible (not more than 10 secs).

1.9.3.3.2. Minimize interaction & simple interface.

1.9.3.3.3. Offer quick response & voice input features.

1.9.3.4. 4. Design a clear minimalistic interface

1.9.3.4.1. Able to read whatever displayed on the screen.

1.9.3.4.2. Able to interact with it while in moving condition.

1.9.3.4.3. Sharp contrast.

1.9.3.4.4. Simple typography.

1.9.3.4.5. Enough space between elements.

1.9.3.5. 5. Minimize interruption

1.9.3.5.1. Info pushed to a user via wearable should be filtered.

1.9.3.5.2. Minimal frequency of notifications.

1.9.3.5.3. Allow user to configure timing & types of notifications they want to receive.

1.9.3.6. 6. Opt for more privacy

1.9.3.6.1. Be aware of which way the device is facing and display content accordingly.

1.9.3.6.2. Vibrate first, display second.

1.9.3.7. 7. Leverage non-visual user interface

1.9.3.7.1. Voice input to compose text message / schedule activities.

1.9.3.8. 8. Interaction w/ other devices is important

1.9.3.8.1. Wearable devices should not be an isolated devices.

1.9.3.8.2. Integrate a wearable with existing devices in the digital ecosystem of a user.

1.9.3.9. 9. Design for offline usage

1.9.3.9.1. Provide core functionality in offline mode.

1.9.3.10. 10. Check what is viable

1.9.3.10.1. Consider both the capabilities and limitations of the platform when designing apps for wearables.

1.9.3.10.2. Use software development kit (SDK) as design guidance.

2. 3. Evaluation phase

2.1. LU 16 - Why Evaluate the Usability of User Interface Designs?

2.1.1. A.K.A. usability testing, user testing, user try-out, inspection

2.1.2. Usability evaluation helps to

2.1.2.1. To understand the user's experience.

2.1.2.2. Identify difficulties / problems & find ways to improve.

2.1.2.3. If UI meets requirements specified.

2.1.3. Why evaluate usability of UI designs?

2.1.3.1. To assess the dimensions of usability (Quesenbery's 5Es).

2.1.3.1.1. 1. Effective

2.1.3.1.2. 2. Efficient

2.1.3.1.3. 3. Engaging

2.1.3.1.4. 4. Error tolerant

2.1.3.1.5. 5. Easy to learn

2.1.3.2. Explore particular areas of concern in relation to usability.

2.1.3.3. Consider user's environment (actual / simulated).

2.1.4. Activities of usability evaluation

2.1.4.1. Process includes: (iterative process)

2.1.4.1.1. 1. Evaluation strategy

2.1.4.1.2. 2. Evaluation plan

2.1.4.1.3. 3. Evaluation sessions

2.1.4.1.4. 4. Analyze & interpret data

2.1.4.1.5. 5. Make changes / conduct further evaluation (if needed)

2.1.4.2. 3 possible situations:

2.1.4.2.1. 1. Usability requirements are MET

2.1.4.2.2. 2. UNSURE IF usability requirements are MET

2.1.4.2.3. 3. Usability requirements are NOT MET

2.1.4.3. Techniques:

2.1.4.3.1. 1. User observations

2.1.4.3.2. 2. Inspections of UI

2.1.4.3.3. 3. Other evaluation techniques

2.1.5. What happens in user observation evaluation session?

2.1.5.1. 1. Welcome

2.1.5.1.1. Explain the purpose of the evaluation and their role.

2.1.5.1.2. Obtain consent, don't make them feel pressure to do so.

2.1.5.1.3. Pre-test questionnaires (expectations).

2.1.5.1.4. Commercial product test, keep it confidential by signing NDA (Non disclosure agreement).

2.1.5.2. 2. Main part

2.1.5.2.1. Ask participants to complete tasks.

2.1.5.2.2. Observe & record.

2.1.5.3. 3. Completed task

2.1.5.3.1. Ask for participant's views on experience / complete post-test questionnaires.

2.1.5.4. 4. Closing

2.1.5.4.1. Make the participants feel appreciated.

2.2. LU 17 - Deciding on What You Need to Evaluate: The Strategy

2.2.1. Purpose of evaluation:

2.2.1.1. 1. Establish whether system meets usability requirements.

2.2.1.2. 2. Exploring concerns.

2.2.2. Types of usability requirements:

2.2.2.1. 1. Qualitative, (immeasurable)

2.2.2.1.1. Described desired features.

2.2.2.1.2. Subjective.

2.2.2.1.3. Not always easy to measure / quantify.

2.2.2.2. 2. Quantitative, (can be counted)

2.2.2.2.1. Explicit measures (percentages, timings, numbers, ratings).

2.2.2.2.2. A.K.A usability metrics.

2.2.2.2.3. Consider the type of user (novice vs expert).

2.2.3. Type of data to collect:

2.2.3.1. 1. Qualitative data

2.2.3.1.1. Data w/out numeric content

2.2.3.2. 2. Quantitative data

2.2.3.2.1. Numeric data derived from taking measurements

2.2.4. What am I evaluating???

2.2.4.1. Low fidelity

2.2.4.1.1. Limited to asking about proposed navigation, choice of colours (qualitative requirements).

2.2.4.1.2. Story board / content diagram.

2.2.4.2. High fidelity

2.2.4.2.1. Involves interactivity, detailed evaluation (quantitative measurement).

2.2.4.2.2. Interactive software prototype.

2.2.5. Constraints to be considered:

2.2.5.1. Money

2.2.5.2. Timescales

2.2.5.3. Availability of usability equipment

2.2.5.3.1. i.e.: Recording devices

2.2.5.4. Availability of participants & costs of recruiting them

2.2.5.5. Availability of evaluators

2.2.6. Document evaluation strategy

2.2.6.1. Basically a report after doing evaluation session.

2.2.6.2. - Specific concerns to ask users about.

2.2.6.3. - Data to collect.

2.2.6.4. - Prototype to be tested.

2.2.6.5. - Constraints.

2.3. LU 18 - Planning Who, What, When and Where

2.3.1. WHO? Choosing your users

2.3.1.1. Repeated session to get variety of views.

2.3.1.2. Aiming for real users (target user for the system).

2.3.1.3. 5 participants is sufficient.

2.3.1.3.1. More participants = more data to analyze

2.3.1.3.2. In case fails to turn up, recruit floaters (proxy).

2.3.1.3.3. Offer incentives afterwards.

2.3.1.4. How to look for real user?

2.3.1.4.1. Depends on circumstances.

2.3.1.5. Users working along / in pairs

2.3.1.5.1. In some situation, the participant needed an interpreter, but keep in mind to speak to the participant not the interpreter.

2.3.2. WHEN? Creating timetable

2.3.2.1. Duration: 30 to 90 mins.

2.3.2.1.1. Longer session = tired participant = ineffective evaluation

2.3.2.2. Based on working hours: 8 hrs per day.

2.3.2.3. Create timetable sooner, easier to keep track.

2.3.3. WHAT? Prepare task descriptions

2.3.3.1. Write task scenarios in plain language, simplified for evaluation.

2.3.3.2. Decide which task to administer, not feasible to evaluate all tasks.

2.3.3.3. No. of tasks influenced by:

2.3.3.3.1. 1. Complexity of individual tasks descriptions

2.3.3.3.2. 2. Time allocated for evaluation sessions

2.3.3.3.3. 3. Functionality provided by system / prototype

2.3.3.4. Task cards

2.3.3.4.1. Card w/ task description

2.3.3.4.2. Bring along during evaluation, easy to order tasks.

2.3.4. WHERE? Decide where to do evaluation

2.3.4.1. 1. Field studies

2.3.4.1.1. Environment within which the users work as well as the system.

2.3.4.1.2. Do in natural settings = understand what people do naturally & how products mediate their activities.

2.3.4.2. 2. Controlled studies

2.3.4.2.1. Evaluation at a place other than user's work environment.

2.3.5. Create checklists for all of the above.

2.4. LU 19 - Deciding How to Collect Data

2.4.1. Quantitative data (retrospective protocol)

2.4.1.1. Timing and logging actions

2.4.1.1.1. Use stopwatch / clock to record time related usability metrics.

2.4.1.1.2. Complex tasks, record the whole session.

2.4.1.1.3. Keep track of user's actions

2.4.1.1.4. No provision for aligning notes / comments from participant w/ log of actions.

2.4.2. Qualitative data

2.4.2.1. Observes and listen what participants have to say and do

2.4.2.1.1. 1. Think aloud and offering help

2.4.2.1.2. 2. Take notes when observing users

2.4.3. Conducting post-session discussion

2.4.3.1. Ask participant's further questions about experiences

2.4.3.2. Let participants to give overall feedbacks (reflection).

2.4.3.3. Reassure participants if something doesn't go as plan, never blame them!

2.4.3.4. Intermediate approach, break task into smaller subtasks (5 to 10 mins).

2.4.3.4.1. Include both thinking aloud and retrospective protocol.

2.4.4. Questionnaires

2.4.4.1. Advantages:

2.4.4.1.1. Easy to collect quantitative data.

2.4.4.2. Disadvantages:

2.4.4.2.1. Difficult to design well.

2.4.4.2.2. Predicts topic that users will want to tell.

2.4.4.2.3. Closed questions are easy to analyze but gives little info.

2.4.4.3. Interview them first to probe answers (trigger the participants to think).

2.4.5. Tech. to help recording

2.4.5.1. 1. Video recording

2.4.5.1.1. As backups, in case any observations / notes were missed.

2.4.5.2. 2. Audio recording

2.4.5.2.1. Less intrusive.

2.4.5.2.2. Difficult in relating what user & system are doing.

2.4.5.3. 3. Eye-tracking equipment

2.4.5.3.1. Record exactly what user is looking at.

2.4.5.3.2. Distinguish between glancing and fixing.

2.4.5.3.3. Difficult to set up.

2.4.5.3.4. Analyse frequently view parts of screen.

2.4.5.4. All in all, let the participant choose which they find comfortable.

2.5. LU 20 - Final Preparations for the Evaluation

2.5.1. NDA (Non-disclosure agreements)

2.5.1.1. In case system is proprietary or confidential in nature, ask participants to keep evaluation session confidential.

2.5.2. Consent form

2.5.2.1. Require agreement from participants to take part in evaluation and also permission to record evaluation.

2.5.3. Roles of evaluators

2.5.3.1. Good facilitator = good evaluating session

2.5.3.2. Ensure purpose of evaluation is fulfilled.

2.5.4. Roles & responsibilities of team members

2.5.4.1. Note-taker

2.5.4.1.1. Take note and observe what's happening during evaluation.

2.5.4.2. Equipment operator

2.5.4.2.1. In charge of equipment to reset to initial state.

2.5.4.3. Observer

2.5.4.4. Meeter & greeter

2.5.4.4.1. Access to facilities, refreshments, keep participants entertained if evaluations are running late. (an usher of some sort)

2.5.4.5. Recruiter

2.5.4.5.1. Finds participants and obtains permission to go to participants’ home work environment if field study.

2.5.4.6. Lone evaluator

2.5.4.6.1. All done by one person = allocate more time

2.5.5. Pilot test

2.5.5.1. Way of evaluating the evaluation session & ensure it works prior to a full-scale evaluation.

2.5.5.2. Process of debugging, testing evaluation material, planned time schedule, suitability of task descriptions, running of session.

2.5.5.3. Let participants use the almost complete functioning prototype.

2.6. LU 21 - Analysis and Interpretation of User Observation Evaluation Data

2.6.1. Analysis data

2.6.1.1. 1. Collating data

2.6.1.1.1. Source of data

2.6.1.1.2. Collect notes from all participant

2.6.1.2. 2. Summarize data

2.6.1.2.1. Extract key comments from data

2.6.1.3. 3. Review data to identify usability problems

2.6.1.3.1. If met requirement, analysis done

2.6.1.3.2. If not met, process of analysis continue

2.6.1.3.3. Usability defect

2.6.1.4. Quantitative data

2.6.1.4.1. Method to summarize data

2.6.1.5. Qualitative data

2.6.1.5.1. Insights data

2.6.1.5.2. Arrange data to a coding scheme

2.6.2. Interpret data

2.6.2.1. Decide what caused defect

2.6.2.1.1. Severity rating for usability defect

2.6.2.2. Prioritise recommended changes

2.7. LU 22 - Inspections of the User Interface

2.7.1. Nielsen's heuristics

2.7.1.1. Visibility of system status

2.7.1.1.1. Always update about the system

2.7.1.2. Match between system and real world

2.7.1.2.1. Use users' language

2.7.1.3. User control and freedom

2.7.1.3.1. Give clear instruction likes "undo" button

2.7.1.4. Consistency and standards

2.7.1.5. Error prevention

2.7.1.6. Recognition rather than recall

2.7.1.6.1. Provide visible instruction

2.7.1.7. Flexibility and efficiency of use

2.7.1.8. Aesthetic and minimalist design

2.7.1.8.1. Only put important information

2.7.1.9. Help users to recognize, diagnose and recover from errors

2.7.1.10. Help and documentation

2.7.1.10.1. Provide help and documentation

2.7.2. How to conduct heuristic evaluation?

2.7.2.1. Use recording when evaluation session with inspector

2.7.2.2. Set location of evaluation session

2.7.2.3. Collect evaluation form to analysis data

2.7.3. Consider benefits and limitation of HE

2.7.4. Usability inspection variations

2.7.4.1. Participatory heuristics evaluation

2.7.4.1.1. System status

2.7.4.1.2. User control and freedom

2.7.4.1.3. Consistency and relevancy

2.7.4.1.4. Error recognition and recovery

2.7.4.1.5. Task and work support

2.7.4.2. Review guideline

2.7.4.3. Standard inspections

2.7.4.4. Cognitive walkthrough

2.7.4.5. Peer reviews

2.8. LU 23 - Variations and More Comprehensive Evaluations

2.8.1. Element to compare user observation and heuristic evaluation

2.8.1.1. Observe

2.8.1.2. Compare

2.8.1.3. Listen

2.8.1.4. Measure

2.8.2. Get opinion without product by

2.8.2.1. Focus groups

2.8.2.2. Card sort

2.8.3. Evaluate without people by

2.8.3.1. Accessibility checkers & HTML validators

2.8.3.2. Usability checkers

2.8.3.3. Hybrid methods

3. Introduction

3.1. Definition

3.1.1. The study of how humans interact with the computer systems

3.2. User interface

3.2.1. Is the part of computer system which interact with users to use this system and achieve the goal

3.2.2. As the 'bridge' between users and system

3.3. Introduction to user interface design

3.3.1. A good user interface design should:

3.3.1.1. Easy to use

3.3.1.2. Easy to learn

3.3.1.3. Allow users to achieve goal w/ minimum frustration

3.3.2. Usability

3.3.2.1. i. Effectiveness

3.3.2.2. ii. Satisfaction

3.3.2.3. iii. Efficiency

3.3.2.4. Important to consider the context which used by the specified user

3.3.2.5. Usability is important in relation to design a good or bad interface

3.3.3. Poor design interface

3.3.3.1. Effect of poor designed interface:

3.3.3.1.1. a. User frustration and dissatisfaction

3.3.3.1.2. b. Loss of productivity, efficiency and money

3.3.3.1.3. c. Safety issues

3.3.3.1.4. d. Small irritations

3.4. User-Centered Design

3.4.1. An approach to user interface design and development

3.4.2. Principles:

3.4.2.1. Active involvement of users

3.4.2.2. An appropriate allocation of function between user and system

3.4.2.3. Iteration of design solutions

3.4.2.4. Multidisciplinary design teams

3.4.3. Activities:

3.4.3.1. Understand and specify the context of use

3.4.3.2. Specify the user and organizational requirements

3.4.3.3. Produce design solutions

3.4.3.4. Evaluate designs with users against requirements

3.5. Evaluation

3.5.1. When evaluation?

3.5.1.1. Early in the life cycle, (validate & predict)

3.5.1.1.1. To validate user's requirement

3.5.1.1.2. Predict the usability of the product

3.5.1.2. Later in the life cycle, (check & assess)

3.5.1.2.1. To assess how well the interface meets the users' needs

3.5.1.2.2. Check the usability of the nearly completed system

3.5.2. How to evaluate?

3.5.2.1. Observation

3.5.2.2. Interviewing/talking/asking questions

3.5.2.3. Make predictions

4. 1. Requirement phase

4.1. LU 2: Requirements Gathering Techniques

4.1.1. Observation

4.1.1.1. Direct Observation

4.1.1.1.1. Field studies

4.1.1.1.2. Controlled studies

4.1.1.2. Indirect Observation

4.1.1.2.1. Use video recording as it provide permanent record of the observation

4.1.1.2.2. Take more time to analysis, users feel awkward

4.1.2. Interview

4.1.2.1. Structured Interview

4.1.2.1.1. Pre-determined questions asked in sequence

4.1.2.1.2. No scope for additional topics,

4.1.2.2. Flexible Interview

4.1.2.2.1. Explore more topic for discuss

4.1.2.2.2. Less formal, interviewer free to explore additional topic

4.1.3. Surveys and Questionnaires

4.1.3.1. Use unambiguous questions, statements to gather information

4.1.3.2. Open questions

4.1.3.2.1. Free to respond related to question

4.1.3.2.2. Provide richer data although take more time to analyze

4.1.3.3. Closed questions

4.1.3.3.1. Only answer in a predefined way

4.1.3.3.2. Easier to analyze

4.2. LU 3: Users and Domain

4.2.1. Users

4.2.1.1. Primary users

4.2.1.1.1. Interact directly with the application

4.2.1.2. Secondary users

4.2.1.2.1. Interact with the application through primary user

4.2.1.3. Design based on -physical characteristics & psychological characteristics, physical limitations

4.2.2. User Profile, Personas

4.2.2.1. Describe users and characteristics

4.2.2.2. Analysis- process of taking information gathered and final conclusion translate to requirement

4.2.2.3. Persona- precise description of user based on imaginary examples

4.2.3. User's needs

4.2.3.1. Felt needs

4.2.3.1.1. Hidden/slow in identified

4.2.3.1.2. User not understand what they need

4.2.3.2. Expressed needs

4.2.3.2.1. What people say they want

4.3. LU 4: Tasks and Work

4.3.1. Tasks

4.3.1.1. Goal

4.3.1.1.1. End result to be achieved

4.3.1.2. Task

4.3.1.2.1. Structured set of related activities that are undertaken in some sequence

4.3.1.3. Action

4.3.1.3.1. Individual step/operation that needs to be done

4.3.2. Characteristics

4.3.2.1. Use to describe the task

4.3.2.2. Information gathered through interviews, observations, consulting documentations

4.3.3. Task Analysis

4.3.3.1. Process of examining the way where people perform their tasks

4.3.3.2. Work analysis

4.3.3.2.1. Horizontal pictures of how moves across people

4.3.3.2.2. describe how a group people cooperate to get the job done

4.3.3.3. Job analysis

4.3.3.3.1. Vertical pictures of all the type of work performed by particular individuals

4.3.3.3.2. Observe the responsibility of individual worker

4.3.3.4. Clues to analysis:

4.3.3.4.1. 1. Observe users

4.3.3.4.2. 2. Work around

4.3.3.4.3. 3. Artifact

4.3.3.5. Technique:

4.3.3.5.1. Task scenario

4.3.3.5.2. Concrete Use Case

4.3.3.5.3. Essential Use Case

4.3.3.5.4. Use Scenario

4.3.4. Mental models

4.3.4.1. Definition

4.3.4.1.1. an explanation of someone's thought process about how something works in the real world

4.3.4.2. Structural model

4.3.4.2.1. Structure of how a particular device or system works

4.3.4.2.2. Assume user has internalized in memory

4.3.4.2.3. e.g: LRT routes

4.3.4.3. Functional model

4.3.4.3.1. User has internalized procedural knowledge about how to use device or system

4.3.4.3.2. Developed from past knowledge

4.3.4.3.3. e.g.:How to get on and off the train

4.3.5. Environmental Considerations

4.3.5.1. Physical

4.3.5.1.1. Sufficient lighting? Dusty? Dirty?

4.3.5.2. Safety

4.3.5.2.1. Health & safety issue, hazards, pollutions, stress level

4.3.5.3. Social

4.3.5.3.1. Do they depend/help/distract each other?

4.3.5.4. Organizational

4.3.5.4.1. Purpose,mission and aims of the organizational

4.3.5.5. User support

4.3.5.5.1. Provide training/experts to guide novices

4.4. *LU 5: User Interface Design Knowledge

4.4.1. Psychological principles

4.4.1.1. 1. Users see what they expect to see

4.4.1.1.1. Principle of consistency

4.4.1.1.2. Principle of exploiting prior knowledge

4.4.1.2. 2. Users have difficulty focusing on more than one activity at a time

4.4.1.2.1. Principle of perceptual organization

4.4.1.2.2. Principle of importance

4.4.1.3. 3. It is easier to perceive a structured layout, (PC2S2)

4.4.1.3.1. Law of proximity

4.4.1.3.2. Law of similarity

4.4.1.3.3. Law of closure

4.4.1.3.4. Law of continuity

4.4.1.3.5. Law of symmetry

4.4.1.3.6. Figure-ground segregation

4.4.1.3.7. Banner blindness

4.4.1.4. 4. It is easier to recognize something than to recall it

4.4.1.4.1. Principle of recognition

4.4.2. Experience principles, (V.A.F)

4.4.2.1. Principles of visibility (WHAT)

4.4.2.1.1. Obvious what a control is used for

4.4.2.1.2. Start from the goal to be achieved

4.4.2.2. Principle of affordance (HOW)

4.4.2.2.1. Obvious how a control is used

4.4.2.2.2. Give suggestion on how to operate the system

4.4.2.3. Principle of feedback (WHEN)

4.4.2.3.1. Obvious when a control has been used

4.4.2.3.2. Receive feedback by the user about the improvement of the system

4.5. LU 6: Usability Requirements and Prototyping

4.5.1. Usability requirements

4.5.1.1. Process of compromise between different constraints and trade-offs

4.5.1.2. Qualitative

4.5.1.2.1. Describe desired features

4.5.1.2.2. Subjective

4.5.1.3. Quantitative

4.5.1.3.1. Usability metrics

4.5.1.4. Early views of usability

4.5.1.4.1. Bennett(1984)

4.5.1.4.2. Tyldesley (1988)

4.5.1.5. Modern of usability

4.5.1.5.1. Quesenbery's 5Es

4.5.1.6. Constraints that may affect

4.5.1.6.1. Costs/budgets/timescales

4.5.1.6.2. Technology available, interoperability with hardware and software

4.5.1.6.3. Stakeholder's agenda

4.5.1.6.4. Contradictory requirements

4.5.1.6.5. Organizational policies

4.5.1.7. Requirements specification

4.5.1.7.1. User Characteristics

4.5.1.7.2. Tasks and task characteristics

4.5.1.7.3. Various environmental factors

4.5.1.7.4. Usability requirements

4.5.1.7.5. Statements of constraints, trade-offs and any requirements negotiations

4.5.2. Prototyping

4.5.2.1. Incomplete design of an product/system

4.5.2.2. Can be used in 2 ways:

4.5.2.2.1. Early stage in design process

4.5.2.2.2. Later in design process

4.5.2.3. Purpose

4.5.2.3.1. To check feasibility of ideas with users

4.5.2.3.2. Test the usefulness of the application

4.5.2.3.3. Allow user contribute ideas to design

4.5.2.3.4. To validate and negotiate requirements

4.5.2.4. Type of prototype

4.5.2.4.1. Low-fidelity

4.5.2.4.2. High-fidelity