A responsive kiosk user interface is a crucial component of developing a kiosk application that’s a pleasure for your customers to use. If your kiosk’s user interface appears sluggish, you can expect your customers will opt for interacting with a cashier, which defeats the purpose of having a self-service kiosk. This is a multi-faceted topic that includes design considerations at both the kiosk and system level. For this reason I’ll be breaking this article up into a 2-part series, the first of which will cover design considerations at the kiosk level.
The illusion of responsiveness matters
Sometimes delays are inevitable and the user will have to wait while your kiosk application performs some necessary background processing. In this case you can still give the illusion of responsiveness by displaying an animation indicating that the kiosk is processing their request (i.e. a spinner or progress bar). In too many cases the kiosk’s user interface will freeze while some background process is going on which is disconcerting to the user. The video below illustrates this point when the user presses the BACK button and the kiosk application hangs and then switches screens a couple seconds later.
Your kiosk should utilize responsive hardware and a sufficient internet connection
If your kiosk is running overly outdated hardware or the internet connection is slow it’s unlikely that your kiosk application will perform as intended. This is why it’s important to test your kiosk application onsite and ensure that it performs adequately. Making use of local storage can reduce the need to synchronize data with offsite servers, thereby lowering bandwidth requirements, which can also help offset a slower internet connection.
Run parallel processes in the background with threading
Modern processors support launching multiple processes to accomplish tasks in parallel, thereby allowing your kiosk application to perform work in the background. In .NET this is often referred to as worker threads because they work in the background without significantly slowing the user interface. You can utilize worker threads in your kiosk application to ensure that your kiosk’s user interface is always responsive. Examples of tasks you might perform with worker threads include caching data, calling 3rd party web services, or interacting with peripheral hardware.
Utilize local storage for caching transient data
Data which only needs to be stored temporarily and is then discarded is referred to as transient data. An example of transient data in a bill pay kiosk application might be a list of customers with outstanding water bills. Customers would use the kiosk to search for and pay their water bill, but once the bill is paid the kiosk application no longer needs to include the customer’s once outstanding bill in its searchable list. Transient data will ideally be stored in memory for quick retrieval, but a local database will also suffice if the data is too large to store it all in memory.
Use a splash screen for preliminary processing
When your kiosk application is first run or a new user session begins you can create a splash screen where the kiosk application has a chance to preform any preliminary caching or processing. This preliminary processing avoids performing these operations while the user is actually trying to interact with the kiosk and ensures that the user interface stays responsive. During this splash screen the user might see a popup window with a message stating that their session is being prepared and some animation indicating that the kiosk application is loading like a progress bar or spinner.
Use vector scalable graphics
Vector graphics use mathematical calculations to represent graphical images and are infinitely scalable, although there are some limits to how small they can scale. Vector graphics also require a smaller memory footprint, especially for larger resolution images, and allow you to easily scale to larger screen sizes while maintaining performance.
If you’re developing your kiosk application in HTML5 consider these optimizations
If you’re using HTML5 to develop your kiosk application then consider taking advantage of the new touch features in HTML5. You’ll also want to preload the entire application including all html templates, data models and scripts so the app isn’t wasting the user’s time doing requests mid-usersession. A good example of this is using client-side MVVM frameworks.
Hardware accelerated elements like the canvas utilizes the machines resources like GPU and VRAM. When doing animations or graphic intensive logic, using these will be much more responsive than using regular HTML/JS and even Flash.
Web sockets: Instead of polling the server for updates, have the server reach out to the client for necessary server->client communication. For example your transaction was finished processing. The server can then initiate the connection to the client to notify the client of the result. This is a more responsive approach to polling the server or having a request waiting open for a response.
Part 2 of this 2-part series will cover design considerations at the system level in order to ensure your kiosk user interface stays responsive. This will include topics like utilizing 3rd party services, building a solid domain model and synchronizing data. Also, if you develop kiosk user interfaces then checkout my complementary article about creating a touch friendly kiosk user interface design.
Latest posts by Andrew Savala (see all)
- Kiosk Idle Timeout: What Happens When They Walk Away… - May 25, 2019
- How to Plan Your Payment Kiosk Workflow - May 4, 2019
- Selecting Kiosk Payment Devices, Don’t Paint Yourself into A Corner - April 25, 2019