We have a prototype in Engineering that does something very similar to that.

Well, the big trick here is creating a system that doesn't require too much hidden knowledge and "magic" timing - anything we do must be readily discoverable without anyone reading a manual.  While many approaches are easy once you know them, the problem is figuring them out in the first place.

This means "press and hold for two seconds" or "press and tilt" and things of that ilk aren't very good candidates.

As a historical aside, there was a big debate early on in the product design about the use of the switch to open the Control Panel in the first place - it was felt by many that it was "hidden functionality", and we weren't sure whether people were going to figure it out.  So far, so good.

Now that we have units in the field, and see how real people are actually using the devices and what's important to them to be able to do quickly, we are looking closely at how to evolve the chumby's behavior over time to accomodate them.

I was thinking of writing a daemon that would monitor the accelerometer independently of the flashplayer.  If I slap the Chumby on the right, I'd have the Chumby advance the widget.  If I slap it on the left, I'd have it go backwards, or show the clock, or something.

But I haven't actually tried to do this yet.  I don't know where to read the accelerometer just yet.  I see there is a "PainThreshold" setting, though.  *snicker*

Also, I don't know how to advance the widgets programatically yet.  And, yes, if an app needed a slap on the side of the Chumby as part of its normal operation, this would interfere with that sort of user input.

Phil

Not to necropost, but how it the prototype playing out?