How to Design a Responsive Kiosk User Interface – Part 2
Developing a kiosk user interface that’s both responsive and a pleasure to use is a critical component of any successful kiosk project. In this second part of my two-part series on developing a responsive kiosk user interface, we’ll focus on design considerations at the system level. Follow these tips to ensure that your kiosk user interface is quick to react to your customers’ touch.
Kiosk performance can degrade over time
Just because your kiosk performed well when it was first installed doesn’t mean it’s performing well today. Following deployment, there are a number of factors that may change and impact your kiosk. Today there may be more users, more data, more software installed on the kiosk, bandwidth changes, memory leaks, disk fragmentation, etc…
Enter robust QA and maintenance schedules. It is important to periodically exercise production kiosks so that you can observe and remedy any declines in performance. Users will not always notify the kiosk operator of sluggish performance. In many cases, they just won’t use a disagreeable kiosk and opt for a cashier instead. It’s up to the kiosk operator to periodically test their kiosks in order to ensure responsive performance long after the kiosk is first installed.
Regular database maintenance
If your kiosk application makes use of a database then you should take steps to ensure that your database is regularly maintained or performance at the kiosk will suffer. In order for your database to function at an optimal level, its indexes must be in good working order. Database indexes get fragmented as database access occurs so your database will required regular maintenance, especially if it’s processing a heavy load. As a general rule you should rebuild your indexes when fragmentation exceeds 30% and below that you can you can simply defragment them.
Minimize real-time communication with external servers
Sometimes your kiosk application will need to push or pull information from a 3rd party server or API for any number of reasons (i.e. synchronizing inventory, processing payments, etc…). If the reliability or responsiveness of the 3rd party server is questionable, you’ll want to avoid risking your kiosk application’s responsiveness while waiting for a server outside of your control. Real-time communication should be avoided when possible in favor of caching and bulk transfers.
For example, many of the kiosk applications we’ve developed are POS front-ends for a retail system running on a central server administrated by a 3rd party. All of the inventory and product photos are stored on the central server and need to be downloaded to the kiosks in order for customers to shop. In order to ensure responsiveness at our kiosks, we only communicate with the server in real-time when the data is operationally time sensitive. The majority of our server exchanges involve synchronizing inventory and product photos, which we perform on its own periodic thread. We’re not stalling the UI thread with lengthy data-sync methods nor do we decommission the kiosk while it performs inventory maintenance as customers roam the store. When a transaction is completed at the kiosk, this does need to be sent back to the server in real-time in order to fulfil the order.
Consider minimizing large data transfers and long running processes during moments where the user would have to wait (i.e. when the user clicks next, don’t transfer 500k of data over the network before the next screen can load). We always try to minimize the number of real-time interactions between our kiosk and server to reduce the chance that the customer will be staring at a loading animation on the kiosk while the kiosk is waiting for the server to respond.
Make use of local servers and storage whenever possible
When reliability and responsiveness are of high priority you’ll want to take advantage of local servers and storage whenever possible. The more points the data has to pass-through between your kiosk and its final destination the longer the transfer will take, which may result in the customer staring at a loading animation on the kiosk. A great way to make use of local storage at the kiosk is to caching transient data in memory or store it in a local database. This way you avoid unnecessarily accessing a central server.
Build a solid domain model to support the kiosk system (doesn’t utilize data intensive operations, model small and operations are quick)
Conclusion
Constructing a responsive kiosk user interface also involves design considerations at the kiosk level which was the topic of my first article in this two-part series. If you develop kiosk user interfaces then checkout my complementary article about� creating a touch friendly kiosk user interface design. If you have any other suggestions for designing a responsive kiosk user interface please post them in the comments section below.