I’m officially declaring this the year of the kiosks. I just finished a couple touchscreen kiosk projects with the amazingly talented, creative and friendly team at Second Story Interactive Studios. I am also working with a new client on six other touchscreen kiosks due early next year.
The Second Story project consists of three kiosks—they architected and designed the kiosks as well as handled all of the massive content production. I developed the kiosks using Flash. The project was a great challenge. I faced many hurdles that I’d never faced in the past, I learned a lot, and had a blast developing these. The Paleoparadoxiid kiosk was one of those projects where, well, I looked at the designs provided to me and sat there scratching my head for about 3 days wondering how in the hell I was going to make this thing work. I believe I created at least 30 to 40 small proof of concepts for that kiosk, many of which Second Story never saw. In this industry, there isn’t a higher personal high than when you’re faced with a development challenge, something you’ve never done, and you get it to finally work.
The kiosk are installed at the Natural History Museum in Los Angeles. For more information on the project, I’ll let Second Story tell the ’story’ on their site: How Do We Know and Paleoparadoxiid. Below are two screen videos I’ve taken of the kiosks in action.
EDIT: After reading this article, you can view better Vimeo videos via posts by Second Story. The show a person actually interacting with the kiosk giving it much better context than my screen-capture videos. You can view How Do We Know here, and view Paleoparadoxiid here.
6 Comments
Thank you for all the pointers.
For checking frame rate / memory usage at runtime within the application, I use a FrameRater I found here http://blog.oaxoa.com/ (I can’t find it now) and added System memory visuals to it. Just google Flash memory profiler, or Flash frame and memory profiler, there are a number of them out there, some much more advanced than the one I use.
I test a lot on the Mac before taking it over and testing on a PC. I usually test an SWF within the standalone Flash debug player. I use ThunderBoltAS3 for reading traces. With .app and .exe files, as far as I know, they won’t work with ThunderBoltAS3 as they don’t have access to the mm.cfg file on your computer due to the embedded release player.
For mouse click and touch press recording, I use Keyboard and Mouse Recorder for the Mac, I’m testing a number of these on the PC, so I don’t feel comfortable recommending one yet. Just go to http://download.cnet.com/ and search for mouse or screen or keyboard recorder, there are a number there that I’m testing.
Thank you so much for your prompt response. Your suggestions are quite valuable, specially as I am embarking on my first Kiosk application.
For catching the Flash memory leaks do you suggest any profiler for mac as well as pc?
You also mentioned that you use some software on both mac and pc to record touches on the screen; could you suggest the name of that please? I guess I need to be armored with these tools to make use of your advice and avoid the pitfalls.
I appreciate your mentioning about the scroll bar usage. I came across exactly the same problem in my previous application.
Thanks again for all your advice. I look forward to see your new Kiosk app videos.
Thank you for the compliments—note that Second Story designed the applications, I just handled the development, but we’re all happy with the results.
The kiosks I’m currently working on are the first kiosks where I have the hardware to test them on. Yes, I too develop kiosks on a Mac and publish SWFs that may be wrapped in other technology, or publish .exe files to run on the PC. The Flash player has always run better on a PC as far as I know. TESTING is the absolute, most important aspect of kiosk development—kiosks are a world apart from Flash development for the Web, or even for a CD. You HAVE to test the kiosk on the actual hardware (Monitor and CPU), this is so important as in the past I’ve learned the hard way. If you have a speedy Mac, and the end application is placed on a slower CPU, the kiosk may run slow and clunky.
The biggest advice I can offer are these points:
a) Consider how a child would use the application: two hands, all fingers hitting buttons at the same time, tons of repetitious presses at the same time. If you don’t develop for this, your application will crash. If it’s in a public setting, that means a dead kiosk that will wait until an employee notices this and finds someone or the time to restart the application. You want to avoid this at all costs.
b) Memory: if you don’t catch every single memory leak, if there are 50 users a day using the interactive, your application and likely the OS will crash if all the memory is consumed. You can’t just ‘restart’ the browser. I use (on both Mac and PC) software that can record the touches on a screen: I literally beat the hell out of the application with touches on the screen, record those presses, and then set the software to loop those presses. I let the software loop those presses for at least 40 hours to simulate constant use.
c) Get people that have never seen your application to test on the actual touchscreen. As the developer, you ‘think’ you know how people will use this, you think they’ll ‘get’ the application and use it as you’ve planned—this is rarely the case. For example, I’m working on a timeline animation with a scrubber that will RW/FF the animation–I avoided adding the ability for the user to click on the scroll track. Every new user automatically clicks on the scroll track as that behavior has become intuitive via most any application they’ve used.
I hope these tips help—before taking on a kiosk application, be confident you either 1) can develop well enough to conquer the above considerations, or 2) you’ll have enough time to learn and figure out how to fix the above problems as you go. I’ve only developed 9 kiosk applications and I feel I have tons yet to learn, especially as technology changes. When beta testing every single kiosk application I’ve developed, I find bugs and memory leaks, then work through them. Problem solving is extremely important—you should never expect that your application will work the first time you run it on the actual hardware—I’d go as far to say it will definitely crash during the beta testing phase, and if it doesn’t, you’re not hammering on the application as the real world would. I have a new guilty pleasure of actually trying to crash any kiosk application I stumble upon at the mall or a museum—it helps me learn, and in my opinion, betters the developers of those kiosks if they need to continue to debug.
Very nice, they really look beautiful. As you have so much experience in this area, could I ask some advice? I am getting involved in developing flash as3 application for kiosk on pc. Would you have some suggestions/pitfalls about the development process? Do I need to have pc-kiosk for development or can I develop it on mac and just do the final testing on pc-kiosk? Many thanks in advance.
Well done, these look brilliant. It’s always satisfying to try something new and come out with a great result, and it certainly looks like you did. I’d love to work with a client like the Natural History Museum!