How to use a browser as a kiosk

When it comes to engaging with customers, interactive screens are an important tool to have in your arsenal. They need to be visually attractive, easy to use, and effective at conveying their message, whether that’s providing information or a particular service. For that reason, web applications are a good way of implementing such tools, because they are inherently visual and optimised for on-screen interaction. So how do you go about setting up and securing your kiosk application?

The context

You’ll find interactive screens in lots of places these days. When I visited the Warner Bros Studios last year I noticed they had several touch-screen computers dotted around, enabling visitors to explore some additional information about how they made the Harry Potter films. It was animated, styled like you’d expect a Harry Potter display to look, and was designed to be an engaging way for people to explore, and without needing an extra employee to operate it. It was a self-service kiosk.

I occasionally make kiosk applications for big shows. You know the kind of thing – events taking place at giant exhibition halls, where hundreds of companies rock up with their stands to try to sell you stuff. These days you’ll find many of them using interactive screens to grab the attention of the crowds as they pass, allowing them to engage with their brand in a more touchy-feely way. I tend to make these interfaces using web technologies, simply because they are primarily designed for on-screen interaction.

The problems

To come across as a professional kiosk, it should satisfy these criteria:

  • It should be full-screen, not showing any browser controls.
  • It should not reveal the underlying operating system.
  • It should not allow users to get out of the application.
  • It should not need staff to periodically reset it.
  • It should be completely self-explanatory, and not require a member of staff to explain how to use it.
  • It should respect people’s privacy.

Pressing F11 to enable full-screen mode in the browser is a good start, but it’s clearly not enough.

Opening your application in kiosk mode

All mainstream browsers come with a kiosk mode. The basic principle in all cases is to create a desktop shortcut with a special parameter in the target, and then make sure that shortcut is opened when the computer is started. Here is the process, assuming you’re using Chrome on Windows:

  • Right-click on an existing Chrome shortcut (e.g. in your start menu) and select Send To > Desktop (create shortcut).
  • Right-click on the new shortcut on your desktop and select Properties.
  • In the Target box, add --kiosk http://yourwebsitehere.co.uk to the end, putting in the URL of your web application.
  • Drag the shortcut into the startup folder of your start menu.

You should now find that when you log into the computer it will automatically load up your web application in full-screen mode. Users will not be able to use the back button, see or change the URL, or open a new tab. However, other features will still work, so we’ll need to lock those down too.

Preventing people exiting kiosk mode

If your kiosk uses an external keyboard, you could easily just hit Alt-F4 to close the application, and – bingo – they’ll be looking at the desktop with free reign over pretty much anything. Not great. People could also try to print, save a bookmark, or pretty much anything else that could be done with a keyboard shortcut.

One solution here is to intercept those keypresses using something like AutoHotkey. I won’t go into too much detail here, there are plenty of resources on their website to point you in the right direction. But, essentially, you’ll want to create a little script to detect when certain combinations of keys are pressed, and do absolutely nothing with them. It will be as if those keys haven’t been pressed at all, which means that the browser/computer won’t do anything. Depending on what browser you’re using, you may have different shortcuts to intercept, so it might be worth looking up a list of keyboard shortcuts that browser uses, and intercept all of them. Don’t forget to also catch any operating system shortcuts, so anything including the Windows key or function keys. You basically only want people pressing the letter and number keys.

Another option is to use a touch-screen computer instead, and not give people access to a keyboard at all. You’ll want to deactivate any operating system gestures though. And if you want to accept user input, you may want to consider using an on-screen keyboard. I wouldn’t rely on the operating system’s built-in on-screen keyboard, because that typically gives people access to the whole keyboard, which means you’ll need to catch them with AutoHotkey. A good alternative option is jQBTK (jQuery Bootstrap Touch Keyboard), which is a little jQuery plugin that generates a keyboard using Bootstrap components, making it easy to integrate and easy to style too. It’s a shameless plug, admittedly, because I wrote that particular script! But I haven’t come across anything better yet.

Application design

There are some things to remember when actually building your web application, too. For starters, be aware of your screen resolution, because you may not want people to be scrolling like they might on a normal web page. Because you know the size of the viewport, you don’t necessarily need to worry about responsive design or even browser compatibility – as long as it works on your kiosk machine, that’s all that matters.

Here are some other brief pointers to keep in mind:

  • Don’t include links to other websites.
  • Make sure the controls are a suitable size.
  • Make sure it’s really REALLY obvious how to use it.
  • Test it beforehand, ideally with someone who has never seen it before.
  • Think about error messages – are you happy for them to appear in operating system default windows, or would it be better to have it consistently styled within your app?
  • Include time-outs, so that if someone leaves your kiosk half-way through it will automatically reset itself after a certain delay, ready for the next person. But make sure it doesn’t reset while people are still using it!

Security and privacy

Beyond stopping people from exiting your app or doing unexpected things with it, there are other security-related things to bear in mind. Since you’re not revealing the URL, you probably* don’t need to worry too much about the usual XSS or SQL-injection concerns you might have on a ‘proper’ website. But remember that people will be using your web app in a public space – do they want their actions to be visible by other people?

An example would be any sort of data collection. If you’re asking people to enter their name, email address, or indeed any personal information into your app, they will be hesitant if they think the person behind them in the queue can see what they’re putting in. So think about the size of your form elements – keep them big enough to be easily visible by the person using it, but not big enough that other people around would be able to read it.

Also remember to set autocomplete="false" on your HTML inputs, so that the browser doesn’t try to put in details that someone else has already submitted!

Finally, NEVER ask people to log in on a public screen. Imagine the havoc that could be caused if someone logged in and then forgot to log out again. Depending on the context, there may be ways of doing it, if you’re really careful. But unless it’s absolutely critical I would avoid it completely.

* Actually, you should ALWAYS think about XSS and SQL-injection. It’s good practice, even if you never expect it to be a problem in your context. You don’t want some clever-clogs coming along and manually entering something in your email form that wipes all your data.

Final remarks

Anything I’ve missed? I’m sure there must be. Do let me know in the comments whether there are any other best practices you would employ when building a kiosk app.