Developing a Web Based Information Kiosk

Used to seeing the Web from your monitor? At the University of Cincinnati, it emerges in a slightly different form...

by Jeffry Gordon and Dave Solko

Second, a number of people come to campus to attend CCM scheduled events. While on campus they want to see a description of the upcoming activities, but unless visitors are on a mailing list, they don't have any good ways of finding out about future events.

Various Solutions Considered

The CCM administration felt that technology could play a role in resolving these two issues and began exploring the possibility of acquiring a touchscreen based information kiosk which would house practice room schedules and descriptions of upcoming concerts. Initially, they looked at proprietary kiosks similar to those found in urban convention centers and hotels. The plan was for a student to query availability of a particular room using the kiosk. Then, once available times were determined, the student could call the scheduling office and reserve the room. The database would be immediately updated so that the next student would not be able to schedule a room at the same time.

While these proprietary kiosks clearly had the ``look and feel'' CCM wanted, there were serious problems with the administration of this solution. Database maintenance would be difficult in this environment. The Scheduling Office and kiosk are located in different buildings. Either the scheduler (a person) would have to physically go to the kiosk with floppy disk in hand or the scheduler's computer would have to call a modem in the kiosk. Walking over to the kiosk each time the data needed to be updated was obviously out of the question. Modem calls would not be acceptable either since the university is on a digital system and analog lines to each machine would cost about $80 per month. This was too expensive, too cumbersome, and inappropriate considering we have a perfectly good campus data backbone at our disposal. Certainly there had to be a way to use the existing infrastructure on campus to maintain the database.

At the time the initial plans for the kiosk were being formulated, another college on campus was creating an information kiosk in Visual Basic. We looked very closely at adopting this solution. By placing the kiosk data on a Novell file server, the problem of updating the database in real-time would be solved. This solution also resolved two other issues: first, students would be able to use any workstation on the network to determine when rooms were available. Secondly, we could make changes in the software as needed because the programmers would be on-campus employees. However, if a student wanted to check the information from home or from other locations on the Internet he would be out of luck. This solution restricted the kiosk information to an IPX-based network.

The Web Solution

At the same time, awareness of the web had reached critical mass, and individual colleges on campus were beginning to set up their own servers, so we explored the possibility of placing the kiosk information on a Web server. This approach gave us all of the advantages we needed from the LAN based solution and allowed access from home and across the Internet. It did, however, introduce a different problem: compared to the proprietary and Novell based environments, the screens would not be as physically attractive. At that point, backgrounds were not supported (pre-Netscape 1.1). Furthermore, days on the calendar would have to be created as graphic images. Thirty-one days required 31 connections just for the calendar. Even though caching the images would cut the time considerably, download time would probably be unacceptable for a touch-screen kiosk. We decided to test it by developing a CGI script which would generate calendar screens on the fly and bring in the scheduling data.

Since CCM wasn't sure how it wanted the information stored, we decided to allow them some flexibility and reduce our initial development time by storing the scheduling data in text files. Each date in each room is its own file. The filename and directory structure reflects the date and room location. While this may seem cumbersome, it actually worked very well in trials.

On a Windows NT 3.5 server we installed a C compiler to create the CGI scripts needed to generate the calendar capabilities. We selected EMWAC and then Internet Information Server (IIS) as the Webserver software.

Some of the information, including the faculty directory would be relatively static. This information was coded as straight HTML.

As development started, two new features in Netscape 1.1N improved the appearance and load time substantially. We could now use a colorful background to make the screens look more attractive, approaching the physical appearance level of other kiosk systems; and we could put the calendar into a table, eliminating the need to bring in 31 graphic images each time the calendar was displayed.

Server And Kiosk Hardware/Operating System Issues

Our original idea was to house the server software on the kiosk workstation and make the system serve itself. We felt that load time from the disk drive to itself would be faster than across the network. Of course, that doesn't work very well. The overhead involved from running both server and client software far outweighs the transfer time across the network. When both the client and server applications cohabitated on the same volume, the load time was more than 3 minutes---clearly unacceptable at a kiosk. When we moved the NT server software to a dedicated server and installed Windows 3.1 on the kiosk, load time was within about 5 seconds, acceptable for a kiosk environment. Later, when we installed Windows 95 on the kiosk workstation, the long load time became a problem again.The load time was again reduced to an acceptable 5 seconds when we upgraded the server from NT 3.5 to NT 3.51. The problem both times apparently was caused by having a 32-bit client working with NT 3.5 server and was rectified by the server upgrade to NT 3.51.

Final Design Considerations

We established a list of design considerations. They included:

1. The screens had to be physically attractive.
2. Use of the vertical scroll bar would not be allowed.
3. A navigation bar would be created at the bottom of each screen.
4. Touch areas would be large and separated by enough distance from each other.
5. Screens would appear within 5 seconds of being requested.
6. Large text files which would normally require vertical scrolling would be parsed into 14 line segments and displayed on a set of sequenced screens. Furthermore, this parsing would occur automatically so that lines and screens would not have to be counted manually.
7. The standard navigation provided by Windows and Netscape would disappear so that the user could not "escape" from the environment.
8. File updates by the scheduling office would be relatively easy and immediate using drag and drop software.
9. Audio files could be added into the environment at a later date.
10. Various web browsers would be tested for appearance and speed.
11. The screen would return to the kiosk's home page after 120 seconds of inactivity.

The first technical hurdles to overcome were the standard browser navigation buttons and tool-bar menus. We designed each screen so that horizontal and vertical scrolling was not permitted. At the time, Netscape was the only browser that allowed us to incorporate backgrounds---a design requirement. Unfortunately, it does not have a kiosk mode on the PC side. While it is a simple matter to put Netscape into its kiosk mode on the Mac with ResEdit (see http://www.kempf.com/~kenwil/kiosk/#resources for details), there was no way to duplicate this on the PC side and hardware purchases had already determined the platform. In order to remove the tool bar, we simply adjusted the screen with the analog vertical and horizontal controls on the monitor until the browser navigation buttons and scroll bars were actually off of the screen out of reach of fingers. After we recalibrated the touch-screen to take this into account, the entire system worked quite well.

Once we got the system up and running with the NT server as the file server and Windows 3.1 on the kiosk, we encountered random blank lines appearing on screens generated by our CGI script. The script is designed to take the lines of the text file to be displayed, parse it into 14 line sections and display each set of 14 lines on a single screen. Unfortunately when these random blank lines would be displayed on the screen, the navigation bar was forced below the bottom of the screen. Since we planned to eliminate the vertical scroll bar because its use on a touch screen is problematic, the navigation bar was no longer accessible to the user. Interestingly, the problem only occurred on high speed Intel computers running Netscape (any version). Furthermore, these blank lines were not cached so that moving back or forward a page removed them. This problem began to manifest itself near the end of the project. It didn't exist with the Macintosh version of Netscape nor with Microsoft's Internet Explorer or Mosaic, which by this time had caught up with Netscape in the critical background and table features.

However, these browsers presented their own problems. Microsoft Explorer actually worked well but its table border made the calendar look unattractive. Mosaic's treatment of tables was physically appealing and allowed us complete control of all fonts, and it had a kiosk mode which eliminated the standard browser navigation buttons. We immediately decided to switch to Mosaic, However, once we tested it on the touchscreen, a bizarre bug in the browser manifested itself. Hyperlinks inside tables would not function on the touchscreen. All other links worked, and the links worked when we used a mouse or another browser on the client machine. For some reason, Mosaic would not register input from the touchscreen within tables.

This left us forced to solve our original problem, fixing the random spacing problems within Netscape. We considered several options, including changing our server software to either Netscape, Microsoft or WebSTAR. Before making the potentially time-consuming switch, we first attempted updating the software on the client side. It turned out that upgrading the server software to Windows NT 3.51 from 3.5 not only fixed the random spacing problem , but eliminated the long load times when using Netscape 1.1 or higher as the browser.

All that was left was to return the kiosk to the homepage after the user left. We decided that 2 minutes would more than suffice to allow the user to read all the information on a page. We incorporated a line of HTML code which returns the screen of the kiosk to the main home page after 120 seconds of no interaction. In the header we placed <META HTTP-EQUIV="REFRESH" CONTENT="120" URL=INDEX.HTML">

Description and Location of the Kiosk

The kiosk is a generic Pentium 90 with a 1.2GB hard drive, 16 MB of memory (although 8MB will work), a MicroTouch (Mitsubishi) touch-screen monitor, and a 3Com509 Ethernet card. Software includes Windows 95, the Windows 95 TCP/IP stack, Netscape 2.0, and the MicroTouch touch screen drivers for Windows 95.

The touch screen and computer were originally going to be placed in a decorative interior brick wall. The computer (with a keyboard and mouse for maintenance and service) was to be hidden behind a cabinet door. Only the monitor screen would be seen by the user. The monitor controls would be covered by the surrounding brick and a small metal frame acting as a bezel. The location of the computer created two concerns: first, ventilation for the Pentium would be a problem. Second, the architect of the building wanted to remove only enough brick for the monitor. He didn't like the appearance of a wooden door below the monitor. So instead, we decided to locate the computer, keyboard, and mouse 100 feet away in a downstairs office. The touch screen monitor would be in the brick wall, attached to the computer via a VGA cable and an RS-232 cable supporting the touch screen functionality. Both of which have a signal strong enough to run a 250-foot cable. Electrical power would be provided to the monitor through the wall.

Description and Location of the Scheduling Office Computer

The scheduling data files in the Scheduling Office are maintained on a generic 486-66 computer running Windows 3.1. This computer is attached to the campus network with a 3Com509 ethernet card. The software on the machine includes Notepad (which keeps the scheduling information) and Rapid Filer (A LanWorkPlace/Novell drag and drop FTP client).

When a student calls in requesting an available time, the student's name is entered into the text file for the date and room requested. This file is then immediately sent via FTP over to the NT server into the correct subdirectory. Since the display of that file is created through the CGI script, the page is never cached and the next person requesting that page will see the update.

Description And Location Of The File Server

A 486-66 Windows NT file server is dedicated to hosting the web applications for the kiosk. The machine currently is running Windows NT 3.51 server and the IIS web server software. We also have a C compiler on the system. The machine houses all of the datafiles for the project as well as the CGI scripts necessary to generate the calendar applications. This server is physically located in the network engineering area about 1/4 mile from either the kiosk or the Scheduling Office systems.

The Future

In the future we anticipate using an actual database program to store the scheduling information. Initially we were unsure what the CCM wanted to do with the data and we wanted to give them the flexibility to handle it in a variety of ways. We also anticipate installing multimedia teasers which would include audio as well as video clips. As the CCM expands into two more buildings on campus, additional kiosks feeding off of the same file server will be added to the network.

Brian Hagemann, Graduate Student, College of Education.

Dave Solko, Programmer Analyst and Webmaster.