We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byAlexis Dolan
Modified over 3 years ago
TietoEnator © 2003 EEA – Usability workshop June 28, 2004
TietoEnator © 2003 Agenda 13.00 – 13.15Welcome Guidelines for Web Usability 13.15 – 13.30 First rule of usability: Know your users! 13.30 – 14.00Heuristics – Usabilitys Rules of thumb 14.00 – 14.45Exercise: Heuristic evaluation 14.45 – 15.00Break Methods for improving usability 15.00 – 15.20Usability testing as a way of improving the web site 15.20 – 15.30Other user studies Writing for the web 15.30 – 16.00How to write good text for the web 16.00 – 16.45Exercise: Web writing 16.45 – 17.00Wrap-up
TietoEnator © 2003 Welcome and introduction Antonio de Marinis
TietoEnator © 2003 Know your users! First rule of usability
TietoEnator © 2003 Target groups and communication objectives Many under estimate the importance of knowing ones target groups and defining clear communication objectives Some producers of web content wrongly assume that users are similar to themselves or that all users are the same Sometimes it is necessary to prioritize some groups in connection to certain content, thereby down-prioritizing other groups.
TietoEnator © 2003 Communication objectives What are the goals of the web site? How should the web site support the overall objectives of the EEA? What do we want to achieve with the communication? Which concrete goals do we have for the web site? Which problems should the web site help solve? Can critical success factors for the web site be defined?
TietoEnator © 2003 The message, the medium, the users, the goals –Who says –What? –Through which medium? –To whom? –With which (desired) effect ? It must be clear what our message is, who we are talking to, how we want to use the medium and what our goals are. –Who seeks –What? –Through which medium? –From whom? –With which desired effect? –And with which behaviour It must also be clear what the target users expects from the communication, the image of the sender and the medium. And it is of course necessary to know the users reasons for visiting the page and his ultimate goals for using it. And finally we must know how their behaviour si Laswells model of communication:
TietoEnator © 2003 So what do we know about your users? The survey tells us a lot about who your users are It gives some indications of what they think of you It says a little about what they use it for It says a little about what they want from it It says almost nothing about the practical use of the page – whether or not it is usable. This can be clarified through a usability test or other user study
TietoEnator © 2003 The Heuristics Usabilitys Rules of Thumb
TietoEnator © 2003 The heuristics Rules of thumb in usability A set of principles and best practice recommendations for user friendly web design Used by producers of web sites and usability specialists as a memory aid for usability issues
TietoEnator © 2003 The Heuristics Support the Users Sense of Control and Freedom Speak the Users Language Support Sense of Place, Provide Overviews Provide Feedback Minimize the Users Memory Load (Recognition rather than Recall) Be Consistent Support Flexible Patterns of Use Support Efficient Use Follow De Facto Standards Provide Help Prevent Errors, Make Recovery Easy
TietoEnator © 2003 Support the Users Sense of Control and Freedom Users should be able to feel in control of the situation and that it is easy to perform the actions required to get what they want from the solution. Dont lock users into unwanted states, and take care to provide clearly marked emergency exits.
TietoEnator © 2003 Support the Users Sense of Control and Freedom - Good example
TietoEnator © 2003 Support the Users Sense of Control and Freedom - Bad example
TietoEnator © 2003 Speak the Users Language As far as possible, use terminology, concepts, symbols and interaction styles the user is already familiar with, and that support the users existing worldview. Avoid system centric engineering terms and organization centred concepts that are irrelevant from the users point of view. Use as simple, concrete and friendly language as other goals for the solution allows.
TietoEnator © 2003 Speak the Users Language – Consumers
TietoEnator © 2003 Speak the Users Language - Professionals
TietoEnator © 2003 Speak the Users Language – Bad example
TietoEnator © 2003 Support Sense of Place, Provide Overviews Make it easy for users to discover where they are, what they can do there and where they can go from there. Also, always make it easy for the user to get an overview of his or her possibilities in the solution.
TietoEnator © 2003 Support Sense of Place, Provide Overviews – Good example
TietoEnator © 2003 Support Sense of Place, Provide Overviews – Bad example
TietoEnator © 2003 Provide Feedback When a user performs an action, clearly and immediately communicate what has happened as a result of this. Also, provide hints to what can be done next. For example Registration has been completed, Caution: File was not saved, please try again, Check complete: No new messages.
TietoEnator © 2003 Provide Feedback – Good examples
TietoEnator © 2003 Provide Feedback – Bad example
TietoEnator © 2003 Minimize the Users Memory Load (Recognition rather than Recall) Make all currently relevant parts of the solution clearly visible. Do not require users to remember information from one part of the solution to another. Make instructions for how to use the solution clearly visible or easy to find.
TietoEnator © 2003 Minimize the Users Memory Load – Bad example
TietoEnator © 2003 Be Consistent Use the same terminology, concepts, symbols and interaction styles throughout the solution. Do not give the same thing different names, or different behaviours, in different situations.
TietoEnator © 2003 Consistency – Bad example
TietoEnator © 2003 Support Flexible Patterns of Use People have different preferences and abilities with respect to interaction mechanism. For example, some people may find it difficult to operate a computer mouse but have fewer problems with keyboard input. And some people may prefer using a search engine to browsing a hierarchy for finding what they are looking for. Therefore, to the furthest extent possible, support several, redundant interaction styles for performing the same actions in the solution.
TietoEnator © 2003 Support Flexible Patterns of Use – Good example
TietoEnator © 2003 Flexible use – bad example
TietoEnator © 2003 Support Efficient Use User interfaces that are used frequently must afford efficiency. For example, it is often just as important to focus on making a solution usable with the keyboard as it is to make it usable with the mouse.
TietoEnator © 2003 Efficient use – Good example
TietoEnator © 2003 Efficient use – Bad example
TietoEnator © 2003 Efficient use – Bad example
TietoEnator © 2003 Follow De Facto Standards Consider if standard solutions exist to your problems. Wherever feasible, follow interaction design standards for the platform or type of solution you are designing for. In most cases, de facto standards exist, such as the interaction style of an entire program or suite of programs. For example Microsoft Outlook type icons can be used with some advantages if all users of a new solution are known to be Outlook users.
TietoEnator © 2003 De facto standards – Good example
TietoEnator © 2003 De facto standards – Bad example
TietoEnator © 2003 Provide Help Ideally, the solution should be designed to be usable without the need for explicit help. However in complex solutions with diverse users, it will often be necessary to make explanations of terminology or procedures available. As a general rule, help for terminology or functionality should be provided contextually. Procedural help, guiding the user in how to get from point A to B in a fixed sequence of actions, is often also necessary. The language of any help should conform to the guideline above.
TietoEnator © 2003 Help – Good example
TietoEnator © 2003 Prevent Errors, Make Recovery Easy To the furthest extent possible, anticipate possible user errors and remove error prone design elements from of the solution. If an error occurs, make sure it has the least possible negative consequences for the user. As far as possible, re-establish the users context prior to the error, and dont require users to retype information already entered.
TietoEnator © 2003 Errors – Good example
TietoEnator © 2003 Errors – Bad example
TietoEnator © 2003 Exercise: Heuristic Evaluation Go to http://www.defra.gov.uk (the UKs Department for Environment, Food and Rural Affair) and try to evaluate the web site using the heuristicshttp://www.defra.gov.uk
TietoEnator © 2003 Methods for improving usability
TietoEnator © 2003 Usability testing – Why? The website will be tested by the users –You can decide whether you will run the test before launch –or after launch Do-say Triangle
TietoEnator © 2003 Usability testing – What do you get? Qualitative tests –You dont get a grade but you get help Knowledge about users behaviour No need to guess… Possibility to identify which parts work and which parts dont work
TietoEnator © 2003 Usability testing – how? (1) Thinking aloud method Identify target groups 4-6 users / target group Simple set-up –One user –One test facilitator –One observer –Website –Video camera
TietoEnator © 2003 Usability testing – How? (2) Introduction Tasks for the user –The user reads and thinks aloud Maybe interview Maybe questionnaire Take notes Present results to web writers and web developers Change what is needed
TietoEnator © 2003 Other methods for improving usability Focus group studies (to get to know your user population) Contextual user studies (to get a full picture of the users and their working environment) User surveys (to gather quantitative data about your users)
TietoEnator © 2003 Writing for the web
TietoEnator © 2003 The characteristics of the media Non-linear (theres no telling where the reader will start) Interactive –Active, not passive –Expectations of action –The reader can reply –The reader can engage others We must trust readers to take what they need, not what we want to give them
TietoEnator © 2003 Reading on screen The screen –Blink rate drops from 12 to 5 times per minute –Dehydration The reading situation –Screen and reader has low mobility –Scrolling text (not more than two pages down) –Nausea What does this mean? –Reading screen text takes 25 % longer than reading conventional text
TietoEnator © 2003 Scanning The reading situation results in: –79% of readers scan the text –11 % read word-by-word Therefore: –Write short –Break up the text in short chunks to improve scanability –Use sub headers –Use bullets –Use Bold (not italics or underscore)
TietoEnator © 2003 Header Sub header introductory paragraph introductory paragraph introductory paragraph introductory paragraph introductory paragraph introductory paragraph introductory paragraph Copy Copy Copy Copy Copy Copy Copy Copy Copy Copy Copy Copy Copy Copy Copy Copy Copy Copy Copy Copy Copy Sub header Copy Copy Copy Copy Copy Copy Copy
TietoEnator © 2003
Linear structure Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7
TietoEnator © 2003 Hypertext-structure
TietoEnator © 2003 The inversed news triangle Short summary, keywords Identification of Who, What, When Explain How Explain Why Consequences Comparisons Perspectives
TietoEnator © 2003 Rules of web writing Structure the text using the inverted news triangle Divide the text into paragraphs Use informative subheadings Use bullets when the text allows for Limit text to that which is necessary Avoid superfluous words - write shortly and clearly Use short sentences – one thought per period Use active verbs Update the text frequently Use oral language and address the user directly Be careful when using bold, italic or underlining. Be consistent in your style and consider the target group carefully
TietoEnator © 2003 Exercise: Writing for the web Defra home page What's new on this site News releases > Current Defra news releases > Other news releases Other Defra news > News stories > Weekly focus articles > Statements Local authorities (and in exceptional circumstances, the Secretary of State) have powers to make changes to the footpath and bridleway networks in their area. They can create new routes, or divert or extinguish existing routes. Orders that create such changes are normally referred to as "public path orders". Anyone may ask their local authority to make a public path order, but, unlike definitive map modification orders, the powers are discretionary rather than a duty. New routes may be created either through an agreement between the local authority and the landowner, or compulsorily by order. Local authorities may create footpaths or bridleways where they believe there is a need. In considering the need for a new route the authority must take into account how much the way would add to public enjoyment of the network and the effect the creation would have on the rights of the landowner. Compensation for created routes may also be payable depending on the effect of the creation on the landowners interest in the land. Extinguishment of a footpath or bridleway can only be achieved where it can be shown that there is no longer a need for the way. In deciding this, an authority must take into account how much the route is likely to be used by the public before extinguishment and the effect of the extinguishment on the land over which the route passes. The Countryside and Rights of Way Act 2000 will introduce new powers for the creation, diversion and extinguishment of rights of way. These include the right for landowners and occupiers to apply for diversion or extinguishment in the interests of agriculture, forestry or the breeding or keeping of horses, the diversion or extinguishment in the interests of crime prevention, the diversion or extinguishment in the case of rights of way that cross school premises in the interest of protecting pupils and staff at the school and the diversion for the protection of Sites of Special Scientific Interest. Temporary diversion of a footpath or bridleway for up to fourteen days is also possible in cases where dangerous works are being carried out.
Part 4: Evaluation Days 25, 27, 29, 31 Chapter 20: Why evaluate? Chapter 21: Deciding on what to evaluate: the strategy Chapter 22: Planning who, what,
Ten Usability Heuristics These are ten general principles for user interface design. They are called "heuristics" because they are more in the nature of.
Basic Elements. Design is the process of collecting ideas, and aesthetically arranging and implementing them, guided by certain principles for a specific.
Nielsen’s Ten Usability Heuristics
Multimedia Specification Design and Production 2012 / Semester 1 / week 5 Lecturer: Dr. Nikos Gazepidis
DEVELOPING A METHODOLOGY FOR MS3305 CW2 Some guidance.
11 HCI - Lesson 5.1 Heuristic Inspection (Nielsen’s Heuristics) Prof. Garzotto.
Usability Evaluation/LP Usability: how to judge it.
Developed by Tim Bell Department of Computer Science and Software Engineering University of Canterbury Human Computer Interaction.
© 2016 Cognizant. © 2016 Cognizant Introduction PREREQUISITES SCOPE Heuristic evaluation is a discount usability engineering method for quick, cheap,
SAMPLE HEURISTIC EVALUATION FOR 680NEWS.COM Glenn Teneycke.
Heuristic Evaluation Short tutorial to heuristic evaluation
10 Usability Heuristics for User Interface Design.
1 SKODA-AUTO.CZ prototype evaluation Poznań, 23th of March 2015.
Today’s class Group Presentation More about principles, guidelines, style guides and standards In-class exercises More about usability Norman’s model of.
Heuristic evaluation Functionality: Visual Design: Efficiency:
SEG3120 User Interfaces Design and Implementation
Electronic Communications Usability Primer.
© 2012 Adobe Systems Incorporated. All Rights Reserved. Copyright 2012 Adobe Systems Incorporated. All rights reserved. ® WRITING FOR THE WEB.
© 2017 SlidePlayer.com Inc. All rights reserved.