SNEPO: integrating strange back-ends with slick flash front-ends
“we’re so haptic we could squirt”
haptic — interaction through touching
kiosk, POS systems, iPhone, etc.
RULES OF THUMB:
-inform user what it is
-inform user how to begin
-others will be watching the user doing his thing, and therefore learning
-people tend to hit the whole screen at once by leaning on it when they press
-solution: move buttons to the bottom of the screen
-web metaphors don-t extend too well to kiosks
MAKE BUTTONS BIG AND OBVIOUS
-only button presses—no mouseover, no keyboard
-some allow dragging, but dragging on a touch-screen is iffy, at best
-have actions happen on PRESS, not on RELEASE
-visually impaired = high contrast, large fonts
-these are in the public arena, so there is no target audience. Prepare for everyone!
-allow for wheelchair/height challenged. Allow for content to be lowered down the screen
-just because they start something, doesn’t mean they will finish it.
-allow for proper timeout/reset time, based on complexity of application
-how easy is it to build the application?
-should be easy to install on the hardware
-TURN THE MOUSE CURSOR OFF!!!
EXAMPLE: “wayfinder” for Westfield mall
about 1 year from beginning to end
-two months of paper prototyping
-four-five months of development, with two months of refining pathfinding algorithm
grand total of about 1 year
Make the application “aware” of its physical location and orientation
each installation comes with an administration mode to “initialize” the installation; e.g. meta-data about physical location of install.
-automated the map-making process for the store kiosk (from the example)
-TEST TEST TEST: Lots of paper prototyping
-logging every piece of user interaction
-make data available to client for subsidiary consideration—advertising, etc.
-TESTERS: replicate every possible human interaction. Try to break it. Account for irrational user behavior
-Snepo used interns who took great joy in pointing out developer mistakes
-discovered that touchscreens aren’t usable by people with artificial limbs — the screen didn’t register the touch
-each kiosk has a transaction server which sends a “heartbeat” back to the the main center. If there is no heartbeat, look for Flash process. If no Flash process, reboot the kiosk.
-public kiosk clients tend to have  a lot of money, and  not all that much technical savvy, and  a lot of equity invested in the project
WHAT DIDN’T WORK
-not a very ergonomic API for Flash developers
-Pathfinding algorithm was done in Flash — Dijkstra
-everything made out of steel
-dead hard drives
-public touchscreens lose calibration quickly
-updating had to be done individually
HOW WE IMPROVED THINGS
-we quit, then started our own company
GOT RID OF TXS
GOT RID OF XMLFS
CREATED “DEPOT” to replace XMLFS — based on HTTP standards
-pulled Dijkstra out of flash and put it on the server—1000% performance improvement
lesson: Things which require a LOT of processor power may be better shuffled off to the back end. Flash is now just the interface, not part of the logic layer
DISC DEATH and WHAT-NOT
-don’t get bent out of shape about hardware failure
CHECK-IN/CHECK-OUT SYSTEM â€“ custom Chinese hardware; had to write drivers form scratch
-kiosk interaction software for cell phone. Buy media from kiosk, blue-tooth it to a cell phone.
-RESEARCH IS VERY IMPORTANT
-haptic technology allows for MASSIVE scope
“ERLANG” language for making kiosks talk to each other through a network
FROM KIOSK to POINT OF SALE
UPSIDES of TOUCHSCREEN (HAPTIC) TECHNOLOGIES
-you get to define EVERYTHING
-there’s money of be made
WHAT TOOLS ARE USED?
-rolled their own .swf wrappers in C or VB
Multi-touch? — installations in public spaces generally don’t require this technology
Error messaging — send a friendly message to the user,and a detailed message