This article was first published on 5 August 2005.
Here’s an idea: software’s usability is measured with reference to its effectiveness, efficiency, and user satisfaction (ISO 9241). Simple and straightforward stuff that every usability person should know and much can be inferred from running even just a few observational studies - sit the users down in front of a computer, tell them to do a particular task, and watch them make mistakes, maybe get them to complete a questionnaire with a Likert-type scale. As an aside, I’ve always been wary when no mistakes are made by the users. It either means that the users are too familiar with the software, or that the task wasn’t hard enough. Don’t forget that there needs to be a bit of a challenge in these tasks!
But this makes me think of problems with observational data. Yes it is argued that they possess a high degree of ecological validity (in other words, they are quite realistic tasks), but they are not real-life. Because putting camera’s in work places unknown to the staff and observing them that way is probably illegal - don’t do it! - and hard to control (just when you want them to perform a task, say editing a document, they may go off and have a cup of coffee or a natter.
Information Overload
But a recent article showed that many workers are constantly interrupted from their work with emails, ‘phone calls, meetings, and who knows what other demands leading to cognitive overload (called “information overload” originally by Jan Noyes). And of course, if somebody is in the middle of doing something, such distractions can cause delays as the person tries to remember a) what they were doing, and b) how far they had got before they were interrupted. Sometimes, important knowledge stored in short term memory may have been forgotten completely. This is not good for effectiveness, efficiency, etc.
In a worst case scenario, the user will completely forget their task and have to begin again. At best, the user will have enough information available to continue after giving themselves a short recap of what they were doing. Both cause a slight delay though the latter is acceptable and the former intolerable.
If workers are interrupted so much these days, should designers change tack? Instead of assuming that users have a nice task to sit down and do until completion, should we assume that at any point they might be fatally interrupted? (by “fatal", I mean fatal to the task, not the user!)
Considering users to be amnesic would help us to model the effect of interruptions upon task completion and therefore the integrity of the interface.
I’m thinking that maybe we should consider users to be mildly amnesic rather than fully switched on professionals dedicating their lives to the task and nothing else. Considering users to be amnesic would help us to model the effect of interruptions upon task completion and therefore the integrity of the interface.
So what is amnesia?
Amnesia is a condition where people have problems using their long term memory. Information they learned when amnesic is not available. It may be due to reasons of encoding (in which case the information was never there to be remembered) or decoding (the information could be remembered, but cannot be accessed). Personally, I think that decoding is most commonly the responsible bit - people with amnesia (complete long term memory loss after a traumatic event) sometimes can learn new things but not in the same way as non-amnesics (that’s you and me). The information appears to be procedural rather than episodic, takes a very long time to learn, and doesn’t appear to be available to conscious access.
Designing for Amnesia
But consider designing an interface. A person with amnesia will be told of a task and will begin to execute it after an appropriate amount of planning. However, there is a good chance that when performing an intricate subtask, the main task will be forgotten. I’ve been in this situation myself from time to time and it’s annoying ("What on earth was I trying to do?"). If we design for amnesia, we can offer enough information within the interface to remind the user of their task. Reminding them of the context is a different matter though and is probably not possible. Consider: if my task is to write a letter to my bank manager, I begin by finding out his or her address and then typing this information in (at least, that is the way I approach it). If I was amnesic, I might forget my main task just after I had completed my subtask. I sit there trying to remember what I was doing, but the interface only tells me that I was writing a letter to my bank manager and nothing else. Without explicitly informing the machine of my task (itself an interruption), the system can offer little clue as to the task context.
Systems already provide some information: for example,, dialog boxes have titles that inform a user of the task they have selected, but can be useful to remind them of what they were doing when they return to a task.
If we design for amnesia, we can offer enough information within the interface to remind the user of their task.
However, the benefit of such a system is that it offers room for the user to open a dialogue with the machine (note spelling: I don’t mean “dialog box", but “dialogue” as in discourse) to help them perform their task. The real benefit is that with contextual information, a user could have all the interruptions in the world (even a years holiday), come back and recover their position without too much trouble. Even somebody else could sit down at the machine with no knowledge of the previous user or the system and could yet understand what was meant to be done. In terms of collaborative working, this system would be very useful indeed.
I see the future of systems as being able to provide a rich enough level of detail for any user to be able to infer the original context of the task. However, this information is placed firmly at the subtask level. You might remember that you were saving a document called “letter to bank manager", but does that remind you exactly of what you meant to say? It can help, but it’s no guarantee.
And how to do this
The problem is that many tasks have a large history which cannot be readily put into a nice and neat summary. The information required to accurately infer the original task’s context may differ from person to person, but is there is likely to be a core of information that will suffice for the purpose.
I would guess that the history of tasks by the user would be the most ready way of providing contextual information. Problems will arise when the person multi-tasks as different subtasks may not be related to each other and is hence misleading information. However, the history of actions may be a useful way of doing this. I think I will do an experiment to see what a person can infer from a web browsers history list and see if it’s possible to infer a real-life task from historical information.
Initial results will be published here. Assuming of course that I cannot find any other studies on this topic! Leave a comment or email if you can find anything.
Designing for Amnesia
Here’s an idea: software’s usability is measured with reference to its effectiveness, efficiency, and user satisfaction (ISO 9241). Simple and straightforward stuff that every usability person should know and much can be inferred from running even just a few observational studies - sit the users down in front of a computer, tell them to do a particular task, and watch them make mistakes, maybe get them to complete a questionnaire with a Likert-type scale. As an aside, I’ve always been wary when no mistakes are made by the users. It either means that the users are too familiar with the software, or that the task wasn’t hard enough. Don’t forget that there needs to be a bit of a challenge in these tasks!
But this makes me think of problems with observational data. Yes it is argued that they possess a high degree of ecological validity (in other words, they are quite realistic tasks), but they are not real-life. Because putting camera’s in work places unknown to the staff and observing them that way is probably illegal - don’t do it! - and hard to control (just when you want them to perform a task, say editing a document, they may go off and have a cup of coffee or a natter.
Information Overload
But a recent article showed that many workers are constantly interrupted from their work with emails, ‘phone calls, meetings, and who knows what other demands leading to cognitive overload (called “information overload” originally by Jan Noyes). And of course, if somebody is in the middle of doing something, such distractions can cause delays as the person tries to remember a) what they were doing, and b) how far they had got before they were interrupted. Sometimes, important knowledge stored in short term memory may have been forgotten completely. This is not good for effectiveness, efficiency, etc.
In a worst case scenario, the user will completely forget their task and have to begin again. At best, the user will have enough information available to continue after giving themselves a short recap of what they were doing. Both cause a slight delay though the latter is acceptable and the former intolerable.
If workers are interrupted so much these days, should designers change tack? Instead of assuming that users have a nice task to sit down and do until completion, should we assume that at any point they might be fatally interrupted? (by “fatal", I mean fatal to the task, not the user!)
Considering users to be amnesic would help us to model the effect of interruptions upon task completion and therefore the integrity of the interface.
I’m thinking that maybe we should consider users to be mildly amnesic rather than fully switched on professionals dedicating their lives to the task and nothing else. Considering users to be amnesic would help us to model the effect of interruptions upon task completion and therefore the integrity of the interface.
So what is amnesia?
Amnesia is a condition where people have problems using their long term memory. Information they learned when amnesic is not available. It may be due to reasons of encoding (in which case the information was never there to be remembered) or decoding (the information could be remembered, but cannot be accessed). Personally, I think that decoding is most commonly the responsible bit - people with amnesia (complete long term memory loss after a traumatic event) sometimes can learn new things but not in the same way as non-amnesics (that’s you and me). The information appears to be procedural rather than episodic, takes a very long time to learn, and doesn’t appear to be available to conscious access.
Designing for Amnesia
But consider designing an interface. A person with amnesia will be told of a task and will begin to execute it after an appropriate amount of planning. However, there is a good chance that when performing an intricate subtask, the main task will be forgotten. I’ve been in this situation myself from time to time and it’s annoying ("What on earth was I trying to do?"). If we design for amnesia, we can offer enough information within the interface to remind the user of their task. Reminding them of the context is a different matter though and is probably not possible. Consider: if my task is to write a letter to my bank manager, I begin by finding out his or her address and then typing this information in (at least, that is the way I approach it). If I was amnesic, I might forget my main task just after I had completed my subtask. I sit there trying to remember what I was doing, but the interface only tells me that I was writing a letter to my bank manager and nothing else. Without explicitly informing the machine of my task (itself an interruption), the system can offer little clue as to the task context.
Systems already provide some information: for example,, dialog boxes have titles that inform a user of the task they have selected, but can be useful to remind them of what they were doing when they return to a task.
If we design for amnesia, we can offer enough information within the interface to remind the user of their task.
However, the benefit of such a system is that it offers room for the user to open a dialogue with the machine (note spelling: I don’t mean “dialog box", but “dialogue” as in discourse) to help them perform their task. The real benefit is that with contextual information, a user could have all the interruptions in the world (even a years holiday), come back and recover their position without too much trouble. Even somebody else could sit down at the machine with no knowledge of the previous user or the system and could yet understand what was meant to be done. In terms of collaborative working, this system would be very useful indeed.
I see the future of systems as being able to provide a rich enough level of detail for any user to be able to infer the original context of the task. However, this information is placed firmly at the subtask level. You might remember that you were saving a document called “letter to bank manager", but does that remind you exactly of what you meant to say? It can help, but it’s no guarantee.
And how to do this
The problem is that many tasks have a large history which cannot be readily put into a nice and neat summary. The information required to accurately infer the original task’s context may differ from person to person, but is there is likely to be a core of information that will suffice for the purpose.
I would guess that the history of tasks by the user would be the most ready way of providing contextual information. Problems will arise when the person multi-tasks as different subtasks may not be related to each other and is hence misleading information. However, the history of actions may be a useful way of doing this. I think I will do an experiment to see what a person can infer from a web browsers history list and see if it’s possible to infer a real-life task from historical information.
Initial results will be published here. Assuming of course that I cannot find any other studies on this topic! Leave a comment or email if you can find anything.
1 comment:
Given how popular actual cash on-line roulette betting websites are, it's not hard to encounter on-line casinos with faulty and terrine gaming services and history. There are many on-line methods and variations to play roulette for actual cash. So if you’re on the lookout for specific on-line gambling roulette websites, you should to} at all times take a second to learn the casino’s lobby to ensure that|to make certain that} 온라인카지노 they supply selection of|quite a lot of|a big selection of} roulette video games. This would supply a wider variety variety|a greater diversity} of video games and enhance your gaming expertise.
Post a Comment