Kiosk Software Basics – Part 1

My goal for this series of articles on kiosk software development is to give an overview on the basics of developing kiosk software that’s both a joy for your customers to use and adheres to the guidelines of PCI-Compliance. This is more of a series of general guidelines and tips based on my 7+ years of experience developing and dealing with other people’s kiosk software not a comprehensive how-to guide. When I use the term “kiosk software” I’m referring to any software running on a kiosk in a self-service (unattended) environment regardless of the technology used. The kiosks our company commonly deals with are running Microsoft Windows so I’ll use terms like “Web app” or “Windows app” when referring to the kiosk software but feel free to substitute whatever technology is appropriate for your environment. This first article in the series will cover the basic considerations you’ll have when getting started on your first kiosk software project and later articles I’ll get into more advanced topics like security, payment processing and more.

Should my kiosk software be web based or a Windows app?

Originally we did all of our kiosk software development as web based (specifically ASP.NET web applications) because the kiosk lockdown software we were using only supported locking down the Internet Explorer web browser not a Windows application. After several years of trial and error I now prefer developing Windows based .NET WPF apps for our kiosk. We’ve found it’s much more responsive because the processing is done client-side and also reduces the load on the server. Interfacing with complex hardware devices is also easier when the logic is performed client-side. Speed of the internet connection is much more of a factor when using the web browser since a lot more bandwidth is used to deliver the content. We had cases where the kiosk would perform great at most client’s sites and then we’d come across a site where the client had opted for a cheap (slow) internet connection and the web browser would get really laggy and occasionally fail to load content. To which we would lamely respond with recommending a better internet connection. In short if you value responsiveness and want to minimize bandwidth and load on the server then create your kiosk software as Windows software not web based.

Replace the Window Explorer shell with your own kiosk software

This is a really cool feature of Windows that allows you to run your kiosk software as the Windows shell instead of explorer.exe. This means that Windows will boot right into your kiosk software at start-up. This can be accomplished easily enough by modifying the Windows registry value “HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell” and replacing explorer.exe with your kiosk software. This is a great way to minimize memory usage when launching Windows and is perfect for a kiosk environment. If you need to launch additional software take a look at the registry value HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

Making your kiosk software touchscreen friendly

This was a must for our kiosk software since many of our client’s kiosks did not include a physical keyboard. It was surprisingly involved to create a “skinnable” touchscreen keyboard that was easily “brandable” to our client’s look and feel but I’m going to save you some heartache here. We originally wasted a bunch of time creating an HTML keyboard and styling it via CSS but we had cases where the web browser control failed to load the keyboard (even though it was stored locally) and so we ditched that idea. Instead we ended up creating a XAML keyboard and loading it via our WPF kiosk software. It ended up being much more responsive and reliable which is one more reason I prefer creating our kiosk software as Windows software over a web app.

Summary

Developing kiosk software that is both a joy to use and secure is a daunting task but many others have done it before you so take heart. Using a kiosk lockdown software can also help offload much of the development I’ve outlined above and address the security concerns I’ll cover in the next article.

Our company has created some easy to use kiosk lockdown software called KioskSimple (www.KioskSimple.com) to do just that so you can focus on developing your kiosk software and leave the security of your kiosk to us.

The next article in my series will focus on the security aspects of “hardening” your kiosk software. Please follow me on Facebook at facebook.com/kiosksimple or Twitter @kiosksimple