Feedback design implementation

As the date draws closer for our first practical demonstration of the WiiCane system, I am building computer application that processes the raw data and events recognized by Zach's driver.  As of now, I have created a single screen that I think includes data entry fields, indicators and graphics we will need for this first iteration. It should be noted that this design is preliminary and will undergo changes as we proceed.

In the image above, I divided the screen into four zones:

• Raw Data, where we see numeric values returned from both WiiMote units (cane mounted and body mounted).  
• Position, where we see a plan view of the WiiCane course. An avatar representing the user moves along the course to indicate progress, and a stick moves back and forth to show the cane's position at each tap event. 
• Indicators and Settings, which includes large color fields meant to be visible from the far end of the course. The indicators change color in synchronization with tap and veering events as perceived by the WiiCane system. Text boxes in this area allow the administrator to set threshold values for these items.
• Feedback. This section includes boxes where the administrator can create or edit text for each utterance that the system will speak into the user's wireless headphones as he walks along the course. 

In Gene's post of October 12, he discusses the variety of feedbacks that will be needed. I believe that I have captured his recommendations here, but this may require some discussion from the group, since the way that feedback is delivered is the key factor in affecting student learning and improvement. Keep in mind, we are only dealing with one case here, that is where feedback is being delivered in speech, not sound effects or vibration, and we are only, for now, looking at veering and coverage.

The six feedbacks for now are:

• Correct veering right
• Correct veering left
• Increase coverage right
• Increase coverage left
• Decrease coverage right
• Decrease coverage left

One question that still needs to be addressed is how often feedback should be issued for a particular condition. Gene mentioned three times for a particular behavior before issuing feedback. This needs to be considered carefully. Does the counter reset if a different error is observed?  I think that the only way to really know how to do this is by trying it out, so everyone should be prepared for the system to require a lot of revision before it becomes useful.