In a previous article on getting started developing kiosk software I briefly covered my thoughts on the pros and cons of developing kiosk applications as a website vs. a native Windows application.
It boils down to a case of client-side vs. server-side and deciding which approach best fits your needs.
My goal for this 2-part series is to define the pros and cons of each approach to better help kiosk application developers make an informed decision.
Let’s start by exploring the option of developing kiosk applications as a website since this seems to be the more popular option, probably due to its simplicity.
In our scenario you would create a website specifically designed to run on a touchscreen kiosk environment and deploy it to your web server.
With the assistance of some kiosk software it’s simply a matter of configuring the kiosk to only allow the user to be able to view your website. Sounds easy enough right? Well it is, but there’s some other variables that you should consider before getting started.
- Quickly deploy updates to a centralized code-base. Deploying updates to your website is just a matter of updating the website on the server, rather than deploying updates to individual kiosks.
- As a shortcut you can reuse your existing website or just rework it to be more touch friendly.
- Basic website development typically has a shorter learning curve than Windows software.
- Sensitive information can be stored on the server and never redistributed to individual kiosks which could be compromised.
- Using frameworks like Angular, Knockout, etc…, you don’t have to transfer any html per page, only data, which can make the website behave more like a native Windows application.
Cons of developing your kiosk application as a website:
- If an update goes bad you break all of your kiosks at once. The ease of deploying updates to a web server can be a double-edged sword when something goes wrong with the updates.
- Hardware vendors often provide limited integration support for ActiveX/Applets.
- UI responsiveness is typically slower because it requires more bandwidth so you end up purchasing a more expensive (faster) internet connection.
- Web browsers make it a challenge to implement effective retry and caching logic.
- Increases the load on the server processing when generating pages and responses.
- The need to account for session expiration and application pool recycling on the server.
Another con that typically comes to mind when considering developing websites is cross-browser capability.
Fortunately this is not a concern in the kiosk environment since the kiosk is restricted to only run a single web browser. In other words, the kiosk user doesn’t get to pick their web browser, they use whatever web browser the kiosk is setup for.
You’ll want to make sure all of your kiosks use the same web browser version for consistency in appearance.
What’s the Right Answer? It Depends on the Nature of Your Kiosk Application
When deciding on a technology for developing your kiosk application the kiosk functionality is also a major factor.
The kiosk applications we develop tend to involve complex financial transactions with a need for high reliability and robust retry logic should the internet ever get flakey.
This is one of the reasons we prefer to develop our kiosk applications as a native Windows application but by all means go with whatever strategy works best for your needs.
My goal for this series is not to steer you in a particular direction but empower you to make an informed decision. The second part in this series will explore the pros and cons of developing your kiosk application as a native Windows application running directly on your kiosk.
Articles in This Series
- Part 1 – 5 Reasons to Develop Your Kiosk Application as a Website
- Part 2 – 6 Reasons to Develop Your Kiosk Application as a Native Windows Application
- Avoid These 12 Mistakes Companies Make on Their First Payment Kiosk - April 6, 2019
- 6 Tips for Boosting Customer Engagement at Your Kiosks - March 23, 2019
- How to Create a Customer Survey Kiosk - November 8, 2017