Sensor based interaction (2006 02 22) 
Discussion notes

Overall theme: Dealing with Uncertainty 
- sensors data that may be uncertain or ambiguous
- computers can make wrong assumptions when there are errors in the data
- computers may not know when they are wrong
- difference between factually correct but not contextually correct


**Making Sense of Sensing Systems: Five Questions for Designers and Researchers**
(Belotti et al)

Human-human interaction used to inform Human-computer interaction

Communication as shared responsibility

Consider Norman’s approximative model
- Goal
	o form goal
	o form intention
- Act
	o specify an action
	o executing an action
- Evaluation
	o perceiving the state of the world
	o interpreting the state of the world
	o evaluationn outcome

Mapping Norman’s model to the AAAAA model proposed in this paper 
	- not a strict mapping
	- Norman’s model describes the interaction as one round trip
	- Belotti’s model is more of a conversation where each step is one full cycle in Norman’s model
	- Jason: Does the Belotti model work for interactions where the user does not know they are using the system, especially in ubicomp systems where the interaction may be very natural and the computer is “invisible”?
	- Ben: How does Norman’s model apply to human-human interaction? 
	- Jason: Yhe paper presentation was funny; star trek person addressing two computers and both computers respond.

Five steps of human-human communication:
Address, Attention, Action, Alignment, Accident

Address:
       - normally it is direct manipulation when not ubiquitous; press keyboard means I am addressing the system
       - challenges
       - address only the system you want to address
       - can be noisy environment
       - computer might not respond 

Attention
	- how do I know the system is ready and attending to me?
	- Challenges
	o Feedback is useful for knowing this
	o Use of the peripheral
	
Question: why privacy /security concern?
	- you may address the wrong system; typing password inadvertently into the IM window

Action
	-challenge: identifying and selecting possible actions and specifying the objects of the action

Alignment
	- how to get feedback on what the system is doing
	- problem: by the time I realize something is wrong, it might be too late!
		o Especially for unrecoverable problem
	- Need for continuous alignment

	Madhu: Do these challenges apply to tangible interfaces too?  Tangibles provide better feedback and better recognition. How do tangible interfaces fit in with ubicomp?
	Jason: ambient, mobile, tangible are three (related) threads in ubicomp
	Sushmita: unrecoverable errors are can apply across the board too.

Accident
	- when something happens unexpectedly, then user may not know how to fix it or understand why
	- system can autocorrect when  users make obvious errors, which can lead to possibly 
		o Is this even possible?  Can the system recognize a problem, even if it made the problem in the first place?
		o Example: autorecover of file after incorrect shutdown
		Chris: Telling people when they in error may not be even possible for the computer.
		Jason: antilock brakes example: the wrong action for the driver is to just stomp on the brakes, so the ABS allows people do the wrong thing and “pumps” the brakes for people

Jason: the Wii, how do they address these issues?
	- Address: very sutble; Chris: controller has four dots that are blue to show which number player you are
		o Madhu: usually only one Wii, so there is only one device to communicate to
		o Adam: you can easily switch controllers
		o JJ: have to reassign Wii-motes from scratch, it’s a one time cost
		o Kami: Wiimotes don’t have to tangle wires anymore, just hand it over.
	- Attention
		o Madhu: wired is more straightforward, fewer things to go wrong
		o Jason: hard to determine when the system is not listening to me or dead is difficult
		o JJ/Chris: syncing Wii-mote gives no feedback, so if no sync then we don’t know
		o Jason: helping people understand the problems 
		o Kami: devices are too small to give meaningful feedback, need to sync with other devices
		o Madhu: dust motes can’t be big, if it were, then it would lose its usefulness
		o Jason: traditional GUI paradigms can allow people to design ubicomp systems better
	- Action
		o Jeff: How to map movements to actions: does the system respond to top spin in tennis game


Other questions:
Jeff: The paper does not address the condition where the system is addressing the user. Do the assumptions still hold?
- system-user alignment may need to use modeling
- Chris: stickykeys in windows, very annoying because the system commits an unintended action.
- Jason: cost-benefit tradeoff, for example even if it gets it wrong, then it’s not a bad, and when it gets it right, it’s pretty neat
- Kami/Jason: Clippy paper: a lot of modeling, but MS decided not to implement all the intelligence
- Madhu: GUI’s have fallbacks, but ubicomp systems do not always have an alternative form of input
- Jason: meta level for accident is what is to do when the whole system dies and not just the interaction
- Madhu: leverage regular error recovery strategies in ubicomp environment



**Distributed Mediation of Ambiguous Context in Aware Environments (Dey et al)**


Sometimes it’s necessary to ask the user to do something when there is an error.

Mediation of errors across many devices

Storage
	- Storing only mediated, unambiguous data is the best strategy.

Subscribers:
	- Some components care about correctness, and if they do care, then they have to mediate it themselves or wait for another component to mediate it
	- Mediated result needs to propagate to all interested components.

Pre-emption
	- Dealing with mediated data, ignoring old results and working with the mediated result.
	- Mediation may come back and have conflicting results, how do we resolve this problem?

Jeff: When does a component need to be mediated?  How the different clients of the system data can process (unambiguous) data in parallel independently.  Answer: It’s the application-specific smarts that decide when to mediate. 

Mediation by offering choices: the choices may or may not be helpful
Ben: typically systems allow users to mediate errors using the same modality; but in conversations, we have many other cues available
Jason/Matt: switching modality results in more correct answers, people tend to overcorrect when using the same modality

Forced Mediation
	- In situations where the system cannot wait, so forced mediation is valuable.
	- Truly distributed services, no one owns the data or has control over other components, so we can only request other components to mediate, but can’t force, but this architecture allows for some level of forcing.
	- There needs to be a model or intelligence to define which mediator is the right one to actually do the mediation.

Feedback
	- Telling the user that after the disambiguation, the system is ok.
	- Need to tell the user when system automatically corrected itself

Adam: Is mediation to create a new context or to choose an existing context?  Selection as a mediation strategy may not be the best way to fix errors.