Topic: a way to make click detection work better
So how fluidly click detection works I think has huge effect on the feel of the Chumby UI. I'm guessing that there's a layer hooked up to the touch sensor, and it has some thresholds to figure out what's a click and what's not. If something is a click, it posts some sort of click(x,y) event, and that finds its way into the Flash layer. Ok fine, that's the standard way to do it.
However, on my Chumby at least, the click detection is pretty iffy. I often have to click a few times to get things to go through. Maybe it's my unit, or I'm doing it wrong, or my fingers are fat.
Anyway, here's the idea:
In the flash layer, in some cases, you *know* where the buttons are (or you could have extra markup addable by the author that encodes it). Use that information at the hardware filtering level! Use a lower threshold if the potential-click is near a known button, and consider counting the click even if it's outside the formal button bounds. This is certainly an abstraction layer violation, but the click detection is such a huge part of the Chumby user experience, making it fluid and effortlessly responsive is a huge win. This strategy would need a lot of tuning and UI testing, but it builds off the basic advantage that most of the widgets have a very small number of buttons. Also, with this fuzzy-hit type logic, the buttons could use up fewer oh-so-scarce pixels, while remaining clickable by a larger virtual area. Of course for random click-not-on-a-button you can use the current thresholding. It would also be interesting to use all the quiet time to build a per-unit noise profile for the touch sensor on each unit, and feed that into the thresholds.
Cheers,
Nick