Posts Tagged ‘HCI’
Replacing the Desktop?
Just under 40 years ago, the desktop metaphor was devised as a way to allow computer users to understand graphical interactions with their computer. Standard tasks, like using a calculator, or deleting files, were presented in a manner familiar to workers from a traditional office place, as an effort to build their experience of computing upon pre-existing knowledge. And, as is evident by this metaphor’s continued existence today, it was a massive success.
Just under 16 years ago Microsoft attempted to reinvent the desktop metaphor, and bring it up to date. The product, Microsoft Bob, aimed to shift computing from an office metaphor to a home metaphor. And it was a massive failure. My first home computer came with Bob installed, and so today I’ll be looking at why it failed, and what we can learn from this failure.
Usability advantages of the desktop metaphor.
So why has the desktop metaphor proved to be a lasting success? Introduced at a time when graphical methods of interacting with a computer were new, it had several key characteristics that led to its success.
...such as fun games
First of all, the desktop was familiar. Rather than having to learn context specific methods of interacting with a computer, it built upon the user’s pre-existing knowledge. For example, when deleting a file, a user could use their existing understanding of a trash can, and drag the file into it (rather than running a deltree command, which doesn’t map with any real-world knowledge). Therefore the desktop metaphor was easy to figure out, and consistent with real life experience, reducing the learning curve upon adoption. This meets Nielsen’s heuristic on a ‘match between the system and the real world’.
Building upon this familiarity was the appropriateness of the desktop metaphor for the tasks at hand. Before home computing, the workplace was the most likely place for users to use a computer, and the computer would be performing office-based tasks, such as word processing or calculating. Hence the adoption of a workplace metaphor seemed appropriate for developing a graphical user interface, as it registered with the target market. This meets Nielsen’s heuristic on ‘recognition rather than recall’.
Furthermore, the desktop metaphor was wide enough to expand to meet the growing roles that computers played. By extending the workplace metaphor through terms such as ‘cut’ and ‘paste’, and the development of graphical tools emulating image manipulation tasks, the desktop metaphor proved that it wasn’t static, and could extend to reach an ever growing range of requirements.
The desktop metaphor also met the heuristic requirement, of having a wide degree of flexibility, by allowing ‘experienced’ users to automate or speed up tasks, such as by selecting groups of objects, or utilizing keyboard shortcuts.
What did Bob try to do?
In the mid 90’s, Microsoft Bob was devised as the successor to the desktop metaphor. Recognising a growth in home computing, Microsoft aimed to shift the graphical interface model for computing from a business/creative focus, to the ‘home’. It was thought that this would open the computing world to a whole range of ‘novice’ users, who would have found the desktop metaphor inaccessible.
Bob presented the user with ‘their room’, covered with clickable objects, such as bookcases, clocks and a notepad. Clicking these things will launch the relevant program (or help you locate files), and you can add your own programs to the shelves. It’s just like your home! (assuming your home is littered with boxes that say ‘Internet Explorer’ and ‘Corel Draw’).
Bob in action
Why did Bob fail?
Microsoft Bob offered an alternative to using the desktop metaphor, aimed at novice users, but its primary failure was that it didn’t offer any significant advantages. For a product that came over twenty years after the ethos of its competitor, this wasn’t a good sign…
Despite being based on the home, Bob still had a learning curve, and so missed it’s key objective of being intuitive. Clicking on a clock to open a calendar, or a pen and paper, still required just as much learning as a calendar or notepad icon in a traditional desktop environment. More complex tasks than just opening programs still require further learning. Also, the enforced ‘home’ layout is just plain inefficient – rifling through a cabinet to find a file offers no advantage to browsing a list of files in a folder.
By attempting to change the way people interacted with computers, Bob alienated itself from existing computer users, and prevented new users from being able to ask for help from power-users. By offering only ‘simple’ ways of interacting with computers, the user was unable to allow users to grow, and learn superior (and more efficient) ways of performing tasks.
It’s also apparent that the ‘cuteness’ of Bob didn’t sit well with users. The two elements of this operating system which outlived the OS itself are among the most hated villains of computing – Virtual assistants like Clippy, and the Comic Sans font. Obviously Microsoft failed to understand the needs of their target market.
The final nail in Bob’s coffin came within a year of its release. Microsoft released Windows 95. It sold… quite well, and offered a fully-powered alternative to Bob based on the traditional desktop metaphor. Bill Gates punished those responsible for the mess that was Bob. He married lead project manager Melinda French. Burn.
What will replace the desktop?
It’s obvious through Bob’s failure that the Desktop cannot be beaten by a simple re-skin or appropriation of another metaphor without offering significant advantages.
As I wrote about in my review of The Humane Interface, Raskin proposes a ‘Zoomworld’ which offers a non-windows environment with no gaps between the operating system and the files. However development by Archy has stalled and they seem to have fallen off the internet…
Or maybe the future will be more like Google, and involve typing queries or commands into a prompt to find answers and perform tasks? Although this does seem like a regression, and breaks several key usability best practises.
So what other systems are out there that offer a viable alternative? Or will it be desktops forever? As ever, I’d be interested in hearing your thoughts in the comments below!
Watching ‘average users’: Word
It’s easy to forget how useful it is to watch less technical people use some common programs, and how helpful observation is as a tool to understand the ‘average’ user. I recently watched someone using MS Word (2003 I think), and it was…enlightening. They made a large number of ‘errors’ when using MS Word, but as we know as usability specialists, its not the the user that creates errors – the software does.
The task was relatively simple – design some worksheets, including textboxes, and pictures, and lay them out in an eye-pleasing manner. I’m sure there are many more appropriate packages to make this in than Word, but it was the user’s software of choice, due to familiarity, and the task shouldn’t be beyond MS Word. I observed, and let them lead the interaction, but advised when they asked for help (naughty I know, but it wasn’t a formal lab setting!)
The lab was busy that day anyway...
How my ‘less-technical user’ used Word:
I noted down (obviously away from the user) some of the more ‘interesting’ characteristics of how they used Word.
- Used the ‘cut’ function as a ‘delete’ (with no understanding of how it links to paste). Taken out of context from “cut and paste”, ‘cut’ would more likely imply removing or ending something, and so this mistake is understandable. Incidentally this method has some pluses. I still don’t know how to remove a table easily (not just the information within it), and cut seems to do this.
- No knowledge of the alignment tools, and so using spaces as a method to align text to the center or right. Obviously ran into problems when editing the text later, as changes would make the text run over the end of the line, ruining the formatting.
- Drew horizontal lines, across the page (i.e. a space to write in your own answer) with –‘s. Seems a pretty effective method, even though I’m sure Word has its own way of doing this. Is there a better way of doing it?
- Displayed difficulty moving images in Word. Is it right that you have to click on an image twice to move it? The first click just gives you resize options, which confused the user.
- Had difficulty with resizing objects. What happens if you make an image so big that it falls off the edge of the paper, and you cannot see the border to make it small again? I guess you could format picture, and manually change the size, but this is an entirely different method of resizing, and isn’t cognitively related to the standard way.
- Constant (constant!) rewriting of words, when word autocapitalised/auto formatted them in an undesired way (which was seemingly every autoformat). User had to delete the word, and re-write each time.
What could word do to improve?
This immediately throws up some questions about how Word was developed. It’s clear that the tools available, such as the alignment, or horizontal lines, are not making their functionality transparent to new users. It wasn’t clear to my user that they existed, or how they should be functioning. Obviously just having the icon on the toolbar isn’t enough, and this should be rethought.
This was also the case with image manipulation. The functions that the user needed do exist in Word (i.e. resizing, moving), but are modal in nature, and so are difficult to find, and don’t offer a consistent user experience to someone who is not familiar with Word’s nuances.
It’s also clear with auto format in particular that the system isn’t adapting to the user’s needs. The constant changes that Word was making to the user’s document, which were then undone each time only created a large degree of frustration in the user. The software should be learning how the user wants auto format to work, and adjust to their preference. In this user’s case, it was causing trouble, and should have turned itself off (or at least given the option)
What they need is some sort of helpful assistant
What should we learn from this?
It occurred to me that these issues were not unique to the user I watched since I encounter similar problems with Word. The difference is I’ve had enough familiarity to learn the workarounds, or solutions to these problems that Word throws at you. For example, it’s an unthinking reaction to press Ctrl+Z after Word incorrectly auto-formats things incorrectly. My user just hadn’t used the program for long enough to train that reaction, and so word’s error became more of a big deal.
Its important when considered usability to realise that users aren’t just like you. If you are in a position to make a difference with usability, it’s very likely you are not an ‘average user’, and as such its difficult to comprehend how ‘average users’ use software.
‘Average users’ are not stupid. They are your mum, and just don’t have the time, or effort to put into learning these workarounds, or making them second nature. The solution, rather than ‘educating’ users, is to make the programs better; make programmers understand who their users are, and how they use the programs. And make them program for the ‘average’ users, rather than the power users. And that is the point of usability.
Conducting an Expert Review
Within our HCI classes, we have started reviewing the UX of an upcoming multi-platform game from a prominent client, and are performing an expert review on it. An expert review, as opposed to a user-based study, involves having usability experts play the game themselves, and uses tools and their expertise to find faults. This is different to a user-based study, where the expert would observe another player playing the game. Because of the time constraints involved, we selected an expert review as the most effective method to review the UX of this game.
To get the best results possible, and be as helpful as possible to the client, we had to choose our methodology carefully. In this blog post, I’ll discuss how we chose to approach this task, why we chose these methods, and what the alternatives are.
The first rule placed on us is that we are to work in groups of 3. As described in an article by Laitinen on performing expert evaluations, the evaluation reaches its optimal group size between 3 and 4. Less experts than this may miss things. More experts than this fail to find a significantly larger number of faults.
plus too many cooks spoil the broth
The other restraint placed upon us is that we would only have a short amount of time with the game. We decided to use this time to play and evaluate the games separately, and then come together to discuss our findings. The alternatives to this would have been having one person play, and the other two take notes, or to have each person play for a bit (as we did), but the experts not playing would take notes then. All of these sessions would involve filming the game screen, and the participant.
Two experts watching one player
Advantages:
- One longer complete play through, so can see player development
- Experts can ask the player questions during their play session
Disadvantages:
- Only one play through, so difficult to see if issues are common or just for this user
- Questions asked during play through may distract/alter playing experience
Three experts playing together, in turns
Advantages:
- Three sessions played through, so can see reoccurring issues
- Experts can get a greater understanding of the game mechanics through playing it
Disadvantages:
- Players wouldn’t get as far as they would with a long session from one player
- Second and third experts play experience will be biased from the experience of the first
Three experts playing separately
Advantages:
- Each player gets an authentic ‘new player’ experience
- Comparing after can show what issues naturally arose for all
Disadvantages:
- Players wouldn’t get as far as in one long play through
- Have to perform expert evaluation after the game play, rather than during.
Since the sessions were all being recorded, we opted to do the last one, and hence have the ‘purest’ play experience recorded for each. There is, of course, no right answer – many other groups chose different approaches, and I’m sure they found equally valid issues. I’d welcome comments below if anyone has reasons for a preference with how to perform an expert evaluation.
Now having a video of a play test, we are individually analyzing them. I’m approaching it using heuristics, such as those made by Nielsen, Nokia, and the work of Federoff as a guide. Having identified the issues, I will then attempt to rate them by severity – the extent to which they will hinder the user’s enjoyment of the game. Then, in a group session with my team members, we will evaluate which issues we all agreed where particularly prominent and severe, and amalgamate our results, ending up with a list of issues with the game.
We will then have to present our data to the client. I posted before about writing a UX report, but the circumstances for this report will differ – Geographical location, and time constraints mean that this report will be an in-person presentation, with some take-aways. I will blog about these soon….!
The Humane Interface by Jef Raskin
Along with Alan Cooper’s book, when starting studying Human Computer Interaction, we were recommended to read Jef Raskin’s The Humane Interface. Having recently finished The Humane Interface, written by a designer of the original Mac (credited with the design of the one button mouse), I will briefly summarise its topics, and give my impressions.
My immediate thoughts are to compare this to Alan Cooper’s the inmates are running the asylum. This book is a harder read than Cooper’s – often going deep into highly technical topics (like how he would like to notate mouse clicks), and lacking the wit or lightness of Inmates. The most readable parts of Raskin’s books are the anecdotes about the development of the Mac and Canon Cat, and these are too few. However, this is likely due to a change in the intended audience, as Cooper’s book intends to sell usability concepts to a business audience, whereas Raskin aims his book directly at computing professionals.
Another key difference between Cooper and Raskin is they favour different methods of investigating the quality of an interface design. Whereas Cooper’s book favours qualitative data and methodology, through the establishment of persona’s and attempting to get inside user’s heads, Raskin favours quantitative methods. He includes a chapter on GOMS, a method of assigning arbitrary times for actions such as typing a keystroke, moving a mouse, thinking and moving from the mouse to the keyboard. Then by adding up the times it takes to do these actions, you can compare interaction methods by the time taken. (Its important to note that these times will not relate to the real world, as user’s act at different speeds, and can only be used to compare against other GOMS scores.)
My initial impression of this form of quantitative research is that it would highlight the speed/efficiency of an interaction, but not the quality – which is not necessarily the same thing. If a task takes a few seconds more, but is considered a lot more fulfilling, GOMS wouldn’t record this. This is particularly relevant to the field of videogames, where a purely GOMS based method to check interaction quality would lead to games such as this below:
Maybe the computer could press the button for you?
GOMS can be a useful tool to help compare interaction times, but should not be used exclusively.
Raskin also documents a number of problems with current interaction, with a particular dislike for modes (i.e. interactions that do different things in different concepts). A simple way to explain modes is the ‘caps lock’ key; turning on this mode will make ‘TEXT LIKE THIS’, despite my keystrokes being the same as when making ‘text like this’. He advocates an elimination of modes, as they introduce cognitive dissonance, and make it harder to form habits. A useful compromise, Raskin say’s is quasimodes, which is a mode that requires a constant input to achieve (and hence can be part of habit formation). This would include holding the shift key to produce capitals.
The elimination of modes extends into the elimination of applications – typing ‘SUM 7 + 6’ should produce ‘13’ everywhere, not just in a calculator. This improves the quality of interaction by allowing the user to be clear that the methods they have learnt will work anywhere. I believe this trend can be seen in current operating systems (such as the amalgamation of windows explorer and IE), and this is one of Google’s main aims with their OS.
Raskin also advocates an unlimited undo feature (even through closing and re-opening documents), and the elimination of dialog boxes asking ‘are you sure?’ These two are linked, giving that level of undo freedom would make ‘are you sure’ unnecessary, and is more technically feasible now than when the book was written. I assume it’s a matter of conventions, and momentum which would hinder people advocating these new interaction methods, and it is this mindset Raskin is trying to overturn.
An even more radical suggestion is Raskin’s radical redesign to information architecture. Looking at the hierarchical, folder methodology we have of storing files currently, Raskin notes that it is inefficient – from any point, you cannot see what’s in the folders below, or in the level above you. Since the book was published in 2000 we can see efforts have been made to combat these criticisms – in Windows, folder icons now show the file types inside (and previews if they are pictures), and have made it easier to go up a level. On Macs, they have additional folder view types that make it possible to see ‘up’ the hierarchy.
Raskin however has a more radical suggestion, which he calls ‘Zoom World’. Imagine, flying over a world with a series of zones, ‘I.e. pictures, home, work’. Then you zoom in on pictures (while still being able to see the others), and note that closer up we can see the pictures has it own sub zones, entitled ‘pictures of France’, ‘pictures of the dog’, ‘pictures of lily’ etc. Zooming in on ‘pictures of the dog’, now we are close we can see some individual pictures, one of the dog smiling, one of it playing with a ball
One of the dog playing counterstrike
Zooming in further on this picture would let us read and alter it, but we always have the option to quickly and freely zoom out and see any area of ZoomWorld. The advantage of this system is it solves the issues with being able to see the files above and below at any point, and not be restricted to your current folder. It has been implemented in ‘Archy’, which includes many features Raskin advocates in this book.
Ultimately its interesting seeing how many of the ideas Raskin advocates are ahead of their time, and were included in later revisions of Macs, and in general interaction. (such as searching starting from the first character you type, rather than waiting for you to press ‘enter’). As a book though, it’s harder to get through than Inmates, and does go on in exceptional depth about less than inspiring topics. Raskin talks endlessly about the Canon Cat, a system from the eighties with which he had tried to implement many of his interface ideas. He notes however that it met resistance from users who were used to the existing human computer interaction paradigm, and was not commercially successful. Perhaps, with the moves made by the leading Operating Systems, and Google OS breaking down the barriers between an OS and a browser, people would now be more susceptible to higher quality interaction with computers, and are prepared to unlearn their bad habits.
7 aspects of successful usability questionnaires
This week in HCI we’ve been thinking about questionnaires. They can be an important usability tool, although there are also many limitations. Primarily questionnaires are used as a quantitative data collection method (i.e. it will give back a large amount of responses), and so, compared to a qualitative methodology, are useful in pinpointing where problems exist, but less helpful in helping us understand why. As such, it is best to combine both forms of research, perhaps by starting off with questionnaires to identify frequent problem areas, and generalized opinions of systems, before moving into a qualitative method to understand why these areas are problems. An advantage of questionnaires include the fact that they are cheaper and quicker to get results from than many other methods, but this is balanced by some drawbacks – the data you record is more subjectively influenced by the researcher and participants opinions than in other methods, such as direct observation.
Nonetheless it is an important usability tool, and it is important that the responses received from questionnaires are of high quality, and useful. So, I’m going to share some of the areas that I, and other HCCS students, have identified as potential problems when dealing with questionnaires, in order to help you make better questionnaires. And since this is the internet, we’ll be presenting them in the form of a list, as everyone on the internet loves lists!
everyone on the internet also loves pictures of cats
So, here are seven important aspects to consider when creating questionnaires.
1. Answers can only be as good as your questions
When preparing a questionnaire, you need to think at length about the aspect of the subject you want to investigate, and go in knowing what you need to find out. Generalized questions, or being vague on the topic, won’t give useful data, and so it’s important to make sure the questions are actually asking relevant things. For example if you wanted to find out about… the most popular aisles in Sainsbury’s, asking questions about whether people prefer the supermarket to its rivals wouldn’t get closer to this goal. Also we all know it’s the cereal aisle. So, know what you want to find out from the questionnaire.
2. The questions need to cover the areas in depth.
When getting opinions, it helps to be specific. Don’t just ask ‘did you like this’, but follow it up with either a question asking for reasons why, or (if you’re after a data set that can be analyzed more uniformly), ask them to rate on a number of scales why they did or didn’t like it (i.e. “to what extent did the look of the webpage affect your opinion of it”). Not doing this will lead to closed answers (Did you like this? “no”), when it would be possible to get a much richer set of data from the participant. Whether you select an open question ‘why’ or a closed question (based on scales), depends on whether you are after purely quantitative data, or also want to include qualitative data as well.
3. Changing the questions mid-implementation taints your qualitative data
Halfway through a study, the results may start to show interesting trends that you’d want to find more about. Take caution when altering the questionnaire to investigate these trends. Adding more questions should be fine (except for the tired participants!), but when editing a question that already exists (i.e. from ‘did you like the look and feel of the website’ to ‘did you like the look and feel of the first page of the website’), keep in mind that this will invalidate getting a quantitative response (i.e. ‘85% of people liked the look and feel of the first page of the website’) from the entire dataset for that question, as the participants have been answering different questions.
4. Subjective answers need to be standardized
Remember, when asking whether something was ‘easy’ or ‘hard’, that answers to theses questions are going to be subjective. People are likely to have a wide range of expectations about how a system should be, and a wide range of experience, and so will be judging on separate scales.
Dr Graham McAllister tells a story related to this. When doing usability testing, he asked ‘did anyone have any problems with the program’… no reply. So he asked instead ‘did anyone think that someone else may have problems with this program’, and a whole host of replies were given from the same people.
Don’t forget that pride can be a factor preventing people from saying they found task’s hard. Shifting the focus of the questions from the participant to the medium can help prevent this.
Also, terms such as ‘often’ or ‘rarely’ mean different things to different people. Try and replace them with specific terms ‘every day’, ‘every week’ etc.
5. The questions reflect your opinion
Because of the close controlled environment that a questionnaire creates (i.e. the participants can only answer the questions they have been asked) it is important to make sure that the researchers opinions do not show through the questions. For example, leading questions, which make it easier to answer one way than the other. I saw an advert recently, for some sort of Christian business, that asked ‘Does god exist?’ with tick boxes for ‘Yes’ ‘Probably’ and ‘No’. This is a leading question – the only indefinite reply implies agreement. Where is ‘probably not’, ‘neither agree or disagree’ or ‘don’t know’? (Answer: not on an advert paid for by the church)
6. You need to give people a reason to participate
now thats an incentive
Before I go on with this list, I was wondering if you’d be happy to answer 25 questions on your opinions of southern English fauna and shrubbery. Please click here to fill it out.
Did I mention that filling out the survey gets you a £25 amazon voucher? Do you want that link again?
The point, as I’m sure you guessed, was that you need to offer an incentive for people to participate in your questionnaire, otherwise only people really interested in the subject will reply. Suitable incentives would be discounts, free products, a prize draw, or something related to the field you are investigating.
7. The data can be skewed towards extreme opinions
Failing to give a good enough incentive or no incentive at all, will end up with unrepresentative data – only people who feel so strongly about the subject matter to reply will bother to. In practise this will either be people who are really angry about it, or people who love it, and this will skew your data towards the extremes. To ensure you get a natural selection of participants, steps need to be taken, such as pre-selecting participants, or offering incentives as covered above.
So there we have it. Seven tips to help you make effective questionnaires. Enjoy asking people things!
