7 Rules of Building High Availability Kiosk Applications

by Dmitry Kirsanov 17. February 2012 11:19

RigasSatiksmeWhat could be easier, for a software developer, than to write a kiosk application? You set the rules, you have only 4 buttons to deal with and users just can’t do anything bad or unexpected. What could be wrong with such solution?

The absence of proactive thinking.

Unless you have an open, proactive mindset, of course.

How often you look at the ATM or vending machine and see the picture like this? In this particular case it’s electronic ticket vending machine for city transportation. Apparently, it’s running Windows. And it looks like there is a problem in reading the C:\AgentPP directory. What’s even better – although the photo was taken at February 15th, it was still the same 2 days later. One would say that multi-million company running the transportation infrastructure of a capital city should have an IT guy assigned to handle such cases, but I think it’s just an illustration of a more deep and serious problem, which is not only specific to mentioned company and not even to that city or country. And no, it’s not Windows-specific, although I find that fact amusing.

Gatwick airport error screen

Apparently, Gatwick Airport is proud to use Windows as well. And you might be out of luck if you’re departing from B Gates:

Airport error screen

I remember a night in Munich airport, about 11 years ago. My evening flight was delayed for about 14 hours (that’s why I never fly Polish Airlines since then!) but I didn’t want to go to hotel and decided to stay in the airport for the whole night. I’ve seen airport loosing electricity for a few minutes, and after that all screens were blue for about 4 hours, seems like system administrators of that airport had a bad night.

Well, back to the business. When your clients are good, the only one left to blame is you, a software developer. And you have a very dangerous task at hands – to keep the GUI application up and running without you being around, with infinite uptime.

I think we can forgive the elders who had to make kiosk applications 12 years ago, using Windows NT 4 and custom frameworks – they were the pioneers, and their efforts added to your responsibility of writing the error-free code. So here is the basic list of best practices you should consider (not necessarily follow) when starting a new kiosk project:

Kiosk Application Development Best Practices

1. Choose the Best Hardware

Unless you’ve got the assembled kiosk hardware, the decision you make on what hard drive you’re about to use could significantly affect the fate of your solution. Although usually neglected, the importance of choosing the right hard drive, or to say it more universally – storage, can’t be overvalued.

Is it fast? Can it suffer the expected operational temperatures? Does it produce heat or is it solid state drive (SSD)? Ask the repair technicians about how often this model of hard drive is returned.

For example, there was an epic hard drive from IBM – the IBM DeskStar 40Gb, which was the champion of hardware failures of it’s time. Even though that was a long time ago and IBM doesn’t manufacture hard drives for about 9 years, I still remember it, and so does the technician whom you’ll ask about the worst hard drives of our time.

If you’re not sure, find the shop that is specializing on hard drives, and ask them.

RAM is another issue. I would recommend to get more RAM than you need, so in case of problem with your application it wouldn’t fill all of your memory. When memory is full, Windows starts using your hard drive, and you won’t like the result of such activity.

2. Choose the best Operating System

Ok, even though we are talking about the Windows OS, you need to consider what flavor of OS will it be. What is the disadvantage of having that particular edition. Limitations, issues, your own experience.

I noticed many specialists tend to choose what they know best instead of what’s better. For example, I know one Windows specialist who’s fond of “good old” Windows XP and Windows Server 2003. He is just not proficient and experienced enough with Windows 7 or Windows Server 2008 R2, so he believes that he could repair the problem of old system easier, than of the new one. And that’s just silly. What would be more expensive for you – to deal with periodic system crash, or to read a book?

However, you should only choose what you know good, and it doesn’t mean that you should choose from what you know good. It means that you should choose, then make sure you know it best and then, if needed, choose again.

That way you may come up with idea of using Linux, which is only a good idea if you know Linux well. Anyway, in most cases you should stay away from client operating systems and use what’s made for servers, like Windows ThinPC, Windows Server or in case of Linux – CentOS.

3. Choose the Right Platform

An example of bad choice could be using .NET 2.0. Because it’s old and is full of deprecated elements and you’ll have a good time making sure you can upgrade from it later.

Or choosing .NET 4.5, when it’s in Developer Preview phase. The rule of a thumb here is the same as with operating system – choose the best and make sure you know it well.

Always think 2 steps ahead. The platform and environment may offer you something you don’t need right now but may want to use in the future. Make sure you have reserved the opportunity to grow, in all senses of that word – quality, scalability, security, availability et.c.

4. Make sure you handle system errors

When someone sees an error on your screen, your image takes damage. And it’s not a unicorn that dies every time your application crashes – it could be well expressed in the Universal Metric Unit of Informational Technology – the U.S. Dollar.

Make sure the kiosk system has setting enabled which reboots the system on blue screen. Don’t show it to your customers.

If your windows service can’t be started after third attempt – just shut it down and display the maintenance window.

Send error message to your office every time you’ve got any error message logged in your Windows Event Log. It’s not just about your application – the problem could be anywhere and you have to react to that fast.

You should have an external windows service which makes sure that your application is having focus, and pings your application time after time. Even if the error message is shown on top of the screen – try to get the focus. In any case – if you detect that any window is taking focus from you – make a screenshot and send it to your office. In fact, send it periodically to make sure the system is running fine, but make sure it’s not used by the customer at that moment, because then you could capture the confidential data, and you don’t want to deal with that.

If there is a critical error registered, make sure you have SMS messaging set up to ensure the lowest latency in response to the issue. If your reaction is fast, your faults will be treated easier.

5. Unit tests are desired for others, but for you they are obligatory

Others can test when they want to, and what they want to. You must test everything and always. In your case there is no administrator sitting next door from the kiosk – it could be running hundreds or thousands kilometers away from you and would require personal assistance in case of severe system fault. Make sure you have 100% code coverage and everything you ship is tested.

6. Always rely on professionals

The system administration is what system administrators do. The software development is what software developers do. Don’t mix it unless the one who is performing the operation is a real pro. Better a certified one.

I’ve seen it too often, when software developers tried to set up their solutions and left terrible security holes in production environment. Or made decisions which led to catastrophic failures, which wouldn’t happen, if the task would be performed by MCSE-grade specialist. This may sound like a hassle, but it could likely turn out to be the best piece of advice you’ve ever neglected.

7. Disable automatic updates

Really, if you know you need to update something, anything, you can do it by issuing a command, when you can control the outcome. Not by receiving a call in the middle of the night with your boss explaining you there is a Java runtime upgrade crashing the airport infrastructure.

8. Set your application as shell

Did you know, that in Windows you can set any application to be your shell, instead of Windows Explorer? Meaning that you won’t have the taskbar and other things that are not needed for your kiosk application to run? Well, you can. It’s just a single record in Windows registry which defines which application should run as your shell.

9. Disable the screensaver

Better yet, delete all screensavers from your machine. They are stored as .scr files in your Windows system directory.


As you can see, only a few rules of a thumb which are not very hard to follow but which were not followed by those who wrote the application, which just crashed in ATM in front of you. Anyway, the golden thread that waves through all of these rules and best practices is that you should always come prepared and armed with knowledge. The proven one, not the false sense of knowing everything. You should learn every bit you touch, when starting developing your new high availability application, and when you realize you can’t possess all the knowledge in the world – don’t hesitate to ask those who do have the required piece of knowledge. After all, the ignorance is never a bliss.

blog comments powered by Disqus