Clash(Mode) error understanding

Mode Error is;

• From "Usability First" (http://www.usabilityfirst.com/glossary/main.cgi?function=display_term&term_id=655)
• a type of slip where a user performs an action appropriate to one situation in another situation, common in software with multiple modes
• From Wiki
• A mode is a state of the interface which influences the perceived effect of actions. A mode error occurs when a user of something performs an action that is appropriate to a different mode and gets an unexpected and undesired response. A mode error can be quite startling and disorienting as the user copes with the sudden violation of his or her user expectations.

QuasiMode;

• From Wiki
• The application enters into that mode as long as the user is performing a conscious action
• I.E. Holding down a control button.

http://www.cs.bath.ac.uk/~hci/papers/Hourizi-Johnson-HCI2001.pdf discusses the effect of mode error in a cockpit and offers a solution which is effectively, an added step of confirmation of the instruction given. While interesting the paper deals with complex, real0time critical systems, not completely appropriate but nice reason is present


Dealing with clashes.
For this;
An instruction is a task perform by the user
A version of an instruction is defined by it's mode (assuming all instructions have modes)
A mode is a set of functions the system controls
A function is the action the system performs

The fundamental problem is the fact the relationship between instruction and mode can be

• Relationship:
  
• Occurs when
  
• Possible Responses
• 1-to-none:
  
• no mode is present
• instruction is not recognized
• instruction not supported
  
• mode doesn't use the instruction
  
• The instruction maps to nothing
  
• The instruction maps to the most similar function
• The instruction maps to the last used function
• The system throws a mode error
  
• 1-to-1:
  
• instruction only support in one mode
  
• every instruction is mapped to a function (radial menu)
  
• The function is consistent from all modes (I.E back button, mode swap instruction)
• only one mode present (mode restriction)
  
• The system performs the function
• 1-to-many: Instruction is the same from multiple modes
• Instruction is Dependant on the mode
• Instruction performs multiple functions
  
• The instruction maps to the current mode
• The system is given choice control
  
• The instruction maps to the most used version of the instruction
• The instruction maps to the last used version of th instruction
• The instruction is based on the other modes running/present
  
• The system throws an error
• The user is given choice control
• Representation of choices is controlled by system
• Is consistent, Modes in the same place each time
• Changes, the system chooses the most appropriate chice and makes that easier to select

Solutions to clashes
System Fixes (Mode error is reduced by the system)

1. Total Menu: A menu containing all choices.
   
1. Take advantage of the menu design's ability to place opposing functions effectively (opposite sides of the menu) and loses 1-to-many problems.
   
2. An instruction to access the menu is still needed
   
2. Mode Menus: Perform a gesture to select the mode menu to appear.
1. Reduces mode clash since the mode is defined before actions
2. Modes might not present. I.E. play while watching TV. Overcome with user selection of task, Prompt to open new mode or prompt for action to perform.
3. Super Mode: Lock the tasks to a specific mode
1. No clash between instructions
2. Access to different modes may is limited or less usable.

User Fixes: (Mode error is apparent, but solved by the user)

1. Running Gestures: User performs multiple gestures to define mode and function
1. Removes mode errors
2. Learning of the gestures, Must alway perform multiple gestures
2. Error prompt: The user is given choice control when an error occurs
1. User choice, Less effect from mode error because it is expected.
2. The unexpectedness of the choice could annoy people (Add some identification before the clash will occur, I.E. number in the icon)
3. User Choice: User defines the set of instructions to perform given the mode present
   
1. Can be learned by the system or through user programming, or a combination of both. Make the systems learn to act as it should.
   
2. If the selection is wrong a corrective measure must be added.
   
4. User Correction: System guesses the correct response and changes of the user perform some action
1. System can learn from corrective measures, is user based, similar to task switching. Measurable improvement of system usage if test and is effective
   
2. Errors must not piss the user off if constantly wrong, Assumes the user performs the same tasks. Might need a Non-learning mode for on of activitis (I.E. party mode)