How to Build a Web-Based Kiosk

Overview:
Recently one of our existing clients approached me about the possibility of constructing a web based kiosk system.  Our client had struck up a deal with a major U.S. retailer to offer access to their products within the retailer’s existing brick and mortar stores.  As part of the deal our client needed to supply the retailer with kiosks which would then be placed within these retail locations.  Our client currently operates on a custom ecommerce platform that we developed in 2006 and built using PHP and PostgreSQL.  Our client’s goal was to create a similar interface that was capable of interacting with their current website and database system but designed for a touch screen environment.

Requirements:
There were some very specific requirements for this project laid forth by our client and the retailer.  First, the kiosk must be secure and prevent users from browsing or utilizing any other windows functions other than the specific webpage that houses the kiosk.  Second, payment must take place using a card reader.  Third, the kiosk must print a label once the order is complete, and the final request was the kiosk should be a touch screen based kiosk to make it easy for users to navigate.

Fears:
As a web developer, I had little experience with many of these requests.  I had never worried much about printing, card readers, or controlling Windows functions.  As a web developer, a lot of these functions are out of our hands.  Each user has unique printers, browsers, and settings, preventing developers from attempting these types of techniques.  One benefit I quickly discovered was that with a kiosk I could totally control the user experience which made meeting these goals much easier.

Requirement 1: Prevent Users from Utilizing Windows Functionality:
This was not a task I could handle from the website by myself.  How I achieved this was through the purchase of a kiosk software package called SiteKiosk 6 developed by Provisio Software.  This product offers a huge range of functions that allow you to greatly restrict a user’s abilities in kiosk environments.  In my particular case I used this software to completely restrict Windows to use Internet Explorer only and I even further restricted the users to a single webpage.  Using the software I was able to design the user experience so that soon as Windows loaded it would open my website in full screen mode and there was no way for the user to exit out of the webpage because the system disabled all keys and key commands that could be used to exit out of Internet Explorer and return to the main Windows desktop.  It also removed all Internet Explorer menus and the address bar.  The kiosk was further restricted because the kiosk we used was purchased from Pheonix Kiosk and had a built in keyboard that didn’t contain an escape key or any of the customary function keys.  (During development I used an external USB keyboard that allowed me to use the escape key to exit full screen mode so I could exit back to the Windows desktop to manage the kiosk settings.)

Requirement 2: Payment Must be Taken Using a Credit Card Reader:
Previous to this project I had researched the feasibility to using card readers in web based applications and at the time most of the solutions I found pointed me to the use of ActiveX controls.  As a PHP programmer I don’t have a lot of experience utilizing Active X controls but I found a better method for this project.   When my client ordered the kiosk from Phoenix Kiosk we made sure to have it shipped with a wedge type card reader.  This type of credit card reader will read the data on the cards magnetic stripe and inject it into your script just like regular keyboard input.  So basically as soon as the card is removed from the credit card reader the wedge credit card reader inputs this data into your website like a keyboard.  To make sure I was able to get the data where I wanted I constructed a one field form and then used JavaScript to set the focus of the form to the correct field.  In my case the field was the only form element on the page and I used CSS to hide the form and its content from visibility.  When the page loads, the focus is set to the card reader.  When the card is removed from the reader the wedge credit card reader will input the content into the field.  I also used JavaScript to automatically submit the form using onchange.  This methodology seems to work quite well and would work across browsers assuming the right type of card reader is used.

Requirement 3: The System Must Automatically Print a Label:
Generally in web development we have little control over the ability or formatting of a users printed output.  In this case since I had control over the printer and the Internet Explorer settings I was able to easily print from a webpage onto a label.  We used a Zebra label printer to print 4” x 2” labels with a barcode on them.  I used the PEAR Barcode library to automatically generate the barcode images with PHP.  Once I was able to get the barcode going all I had to do was adjust my printer’s output size to the proper label size and modify the Internet Explorer print margins to .1.  After this was complete I formatted my output using XHTML/CSS on a blank page with no margins.  To print I utilized an Active X control and SiteKiosk 6 to print the label automatically with no user interaction.  Once the label printed I used JavaScript to redirect the user to the final confirmation page.  This methodology worked seamlessly once I was able to make sure that the XHTML output printed before the JavaScript redirect took place which took some experimentation.  The net result was the screen loaded and redirected so fast often the user was unaware they had visited the label page and they just landed on the confirmation page while the label printed out automatically below the keyboard.

Requirement 4: Touch Screen Based Website:
When I first accepted this job one of my biggest worries was the ability to navigate a webpage using a touch screen.  At the time I had no experience with touch screen environments but I assumed they function similar to a mouse.   Luckily my instincts were right.  The touch screen that came in our kiosk works just like a mouse.  It is not quite as functionally as the touch screen on my iPhone but it works well. The only problems I ran into were using some HTML elements like radio buttons and list menus can be difficult especially for users with fat fingers like yours truly.

Conclusion:
All in all, this project was less difficult but more time consuming than I expected.  Mentally I thought some functions would be considerably more difficult than they actually turned out to be.  Some of the processes like figuring out the printer and the SiteKiosk 6 software took me more time than they should have but that is always how things go the first time you do them.  With a project like this with so many unknowns and no available documentation sometimes things that aren’t too difficult can really become stumpers.   I searched all over Google for help to many of my issues on this project but there was little help or information.  It seems very few developers have attempted to build a web based kiosk and I hope this bit of discovered information is helpful to someone else who might be Googling for some of the information I had to discover on my own.

If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.

Created by: Zipline Interactive
Copyright 2010. Ryan Stemkoski. All rights reserved | Technorati Profile

• Home
• About Ryan Stemkoski
• About Zipline Interactive