Creating Dynamic or Interactive Kiosk Web Sites

Customers of The World who have their Web sites hosted by The World's high-end Kiosk Web Server (that is, "Kiosk Web Hosting" or "Kiosk Bundle" customers) can take advantage of various server-side advanced features, as well as all the usual client-side methods of adding interactivity to your site or creating "dynamic" pages. This introduction presents an overview of six different technologies you could use to make your Web site "do things" as opposed to just displaying text and pictures.

There are two categories of enhancements to basic Web technology. Server-side technologies are those which are controlled by our Web server, and are processed before the Web pages are sent to your visitors. Client-side technologies are those which are processed by your visitor's computer. In essence, server-side technologies are independent of who the visitor is (what kind of computer they have, what Web browser they have) as the server-side stuff "happens" before the page is sent to your visitor, while client-side technologies do things "on" your visitor's computer itself (requiring support for those specific technologies.) Each method has its advantages and disadvantages, summarized in this chart:

                         SERVER-SIDE             CLIENT-SIDE
                         ---------------------   ----------------------------

  Examples:              CGIs, XSSIs, PHP        Java, JavaScript, plug-ins

  When are these         As the page is being    After the page is sent, but
  technologies active?   transmitted.            these technologies continue
                                                 to run while the page is
                                                 still visible.

  How interactive are    "Dynamic" pages are     Pages can be truly inter-
  these technologies?    created as they are     active in the sense that
                         served.  A page must    things like videogames are
                         be reloaded or a form   possible.  Programs can
                         submitted for more      interact with the user
                         stuff to happen.        while the page is displayed.
  
  Who will see them?     Everyone.               Only people with browsers
                                                 which support the technology
                                                 and some implementations
                                                 may be incompatible.
  
  Can visitors           No, it always runs.     Yes, visitors can switch
  disable it?                                    these technologies off.
  
  How fast does it go?   Runs fast because       Can run fast or slow,
                         our high-end server     depending on the visitor's
                         deals with it.          computer.
  
  Can it access          Yes (but only to        No.
  database files         specific files, for
  on The World?          security reasons.)
  
  Can people "reverse    Usually not.            Definitely, in the case of
  engineer" your code                            JavaScript.
  to copy or hack it?

In essence, server-side Web technologies work for all visitors (no matter what their browser is, and they can't be enabled) and they work rapidly and are very secure. But server-side technologies are not as flexible as client-side technologies, which can be used to make your page considerably more "alive", but which require your visitors to have a browser (and/or plug-ins) that support this technology and that they enable this support.

Because client-side technologies are implemented by your visitor's software, they can normally be used from any Web site, no matter what Internet server hosts it. The server-side technologies use features which are only available from certain Web servers (such as The World's Kiosk server) and so you may not be as familiar with such things as PHP and XSSIs (while you've undoubtedly heard of JavaScript.)

Which technology is right for which job? It depends on what you're doing. Let's take a brief look at each of the six technologies mentioned so far, starting with the client-side ones.

JavaScript (client-side)

JavaScript is a programming language related to -- but different from -- the Java programming language (see below), intended for "lightweight" scripting of browsers. A Netscape invention, JavaScript is intended to allow control of what happens when the visitor sees your page in their browser window: Events can be tied to the items on your page so that things happen when the items are clicked on or pointed at.

JavaScript is widely used these days (most often for "rollover" icons, that is, button images that light up when the mouse moves over them.) It is also sometimes used for navigational menus (such as pop-up menus of links), which renders some poorly-designed signs non-navigable without JavaScript. Other commonly-seen uses include special effects (such as making the page's background fade from one color to another) and form validation. And, of course, it provides those little floating advertisement windows that accompany any page hosted by GeoCities or Tripod.

The main problem with JavaScript is that there is no formal standard for this language. It was invented by Netscape, and Microsoft's implementation (sometimes called "J/Script") is different enough that many JavaScript programs developed for Netscape browsers will not work in Microsoft browsers, and vice versa. To make matters worse, JavaScript itself changes with each revision of these browsers. (The European Computer Manufacturers' Association has proposed an "ECMAScript" standard to address these issues, but at the moment JavaScript errors generated by incompatible scripts show up a lot.) Because of the frequency of such incompatibilities with some browsers (or because JavaScript is most often used for trivial things such as image rollovers, or because the GeoCities windows are just plain annoying) some people switch JavaScript off most of the time. There are also some browsers that do not have JavaScript support at all, although the number of people with browsers other than the Netscape/Microsoft ones is small (less than 10% according to some measurements, but that's still a significant enough fraction that you don't want to rule out those people by designing a Web site that _requires_ JavaScript to navigate.) JavaScript is probably best used for "frills" such as image rollovers and special effects.

Java (client-side)

Java is an object-oriented programming language, vaguely similar to C++. The main feature of Java (as it is used on the Web, anyway) is that its programs, called "applets", are designed to be portable: the programs are stored in a "byte code" that will function on any kind of computer (unlike regular programs) and there is a standard Java environment (a "virtual machine") which makes the same functions available on any computer which supports Java. This environment also provides a security feature: a "virtual machine" means that the Java program is isolated from the rest of the stuff on your computer.

Or at least that's the way it's supposed to work. Sun set the Java standard ("100% Pure Java" refers to this) but Microsoft, again, has gone in a different direction. Their "J/Direct" does not conform to Sun's standard, and to make matters worse, it allows Java programs to call Windows system functions, which means that some programs written for Microsoft Java can only run with the Microsoft Java virtual machine (not Netscape's) _and_ under a Microsoft operating system (not Apple's). But things which are "100% Pure Java" are likely to work with any virtual machine on any type of computer.

The main drawback is that, because Java involves a standardized environment, the program does not have access to the computer's operating system functions, and thus Java programs tend to have fairly limited-looking graphics (because they have to draw their own interfaces in Java, rather than just making a system call to some routine to do something fancy.) But Java applets can do just about anything (depending on how much programming you want to do.) They can be run either in a rectangular area of a Web page, or in a separate window. (Java applets often do not refresh when a window is scrolled or uncovered, so you should probably not place them at the bottom of long pages.)

Browser Plug-Ins (client-side)

There are hundreds of plug-ins for the Netscape and Microsoft browsers which support new types of interactivity developed by third parties. While JavaScript and Java are somewhat generalized, plug-ins tend to support more specialized sets of features, for instance, they may have better graphics or play better music than Java applets, but may not be as flexible for more generalized tasks.

Two popular plug-ins for making interactive content are Shockwave (for Director) and Flash, both developed by Macromedia. Shockwave allows you to take an interactive program developed with Macromedia's director and use it on the Web (provided your visitors have the necessary plug-in and a browser that the plug-in works with.) These programs can do highly interactive things with slick graphics and sound, such as video games. The Flash plug-in is for "vector animation", such as flying lettering or moving cartoon characters.

Other popular plug-ins include the RealMedia plug-ins for playing "streaming" audio and video, the Crescendo plug-in for playing MIDI music, and Apple's QuickTime 3 plug-in for playing many formats of video, still pictures, and sounds.

CGIs (server-side)

CGI stands for "Common Gateway Interface", which means a method of allowing the Web server to run programs that you write (which are stored in your Kiosk's /cgi-bin directory.) CGIs can be written in _any_ programming language (Perl is by far the most common, but you could use Python, C, or even an 'sh' script) and their output is generally in the form of HTML -- when the visitor follows a link to a CGI (or encounters a page with an "inline" CGI) the Web server runs the CGI program and transmits only the _output_ of the program to the visitor.

CGIs get input from visitors as fill-out forms (sometimes by other means.) For instance, when you fill out a form on a search engine's front page, what you typed is then sent to a CGI which performs the search and sends the results back to your browser as HTML.

CGIs are incredibly flexible, and because they're highly secure and have access to files stored on the server (provided those files are explicitly permitted for access) they are the normal solution for things such as message boards, on-line catalogs and "shopping carts", and so on. The most frequently-seen uses of CGIs are to turn Web forms into E-mail messages (such as with mailto.pl) or to display a "hits" counter (as with Count.cgi, which actually outputs a GIF image as opposed to the usual HTML.)

Because CGIs are handled by the Web server, they run _before_ the page is transmitted, so although CGIs are used to build "dynamic" pages that change for each visit, the pages are not "alive" after they're served. For instance, you could use CGIs to make a tic-tac-toe game -- where every time the visitor clicks on a square, the form is resubmitted and a new page is generated -- but for something like a Space Invaders game requiring moving objects, you'd need to use a client-side programming language such as Java or Shockwave.

There are thousands of publicly-available CGIs, and The World's Kiosk customers can install their own CGIs (either from those public sources or written from scratch.) This is important because generally CGIs need to be customized for every site they're used on, and because you won't want to share such things as a "shopping cart" with our other customers. Thus, you get to install whatever CGIs you want for your private use and configure them however you want. (mailto.pl and Count.cgi are the only "public" ones we provide, as they're commonly used and can be safely shared.)

Kiosk accounts are normally set up with a "/data" directory (folder) containing ten empty files which only you and the Web server ("nobody") can read or write, so using those files for your CGI's databases would ensure very high security (even people using the UNIX command line on The World shouldn't be able to snoop in them.)

Many books are available on writing your own CGIs. (There is no more sophisticated feature than writing your own CGI -- this is the ultimate in flexibility, and obviously requires programming skill.) For novices, ready-made CGIs from the Web are generally not very difficult to configure and install. (Some experience with the UNIX command line is strongly recommended.)

XSSIs (server-side)

Server-Side Includes (SSIs) were invented by the National Center For Supercomputing Applications (NCSA) as a simple way of making dynamic Web pages: SSIs look like individual HTML tags, with names like "". Before the page is transmitted to your visitor, the server replaces the SSI "directives" with their output. Our server, Apache, supports a more advanced form of SSIs called XSSIs ("X" = "extended").

XSSIs can do tasks such as including a standard page-part on some or all of the pages on your site, displaying the date and time the page was last modified, or even displaying different versions of the page based on circumstances such as the browser being used or the time of day. XSSIs aren't as flexible as CGIs, but they're the easiest way of making the most common kinds of "dynamic" content involving pages that update when an external files is changed, or that are customized for different visitors.

And, a very nice feature is that you can use XSSIs to execute an "inline" CGI whenever your page is displayed. For instance, if you include the directive , then every time your page is visited that CGI will execute -- invisibly, if you so desire. This is great for logging visitors (especially as it cannot be bypassed) and can be used to embed the output of your CGI (such as a text string listing the number of "hits") in the middle of your page.

Web pages which use XSSIs (on our Kiosk server) are differentiated from "regular" pages by filenames ending with ".shtml". Incidentally, Microsoft's Web servers support "Active Server Page" (".asp") files which are related to XSSIs, so if you're familiar with ".asp" files, ".shtml" files look similar.

The World's own Web site (world.std.com) makes heavy use of XSSIs (although you can't tell where they are by viewing our pages' HTML in your browser, as the XSSIs are "done" by the time you receive it.) For instance, the "navigation bar" at the top of most of our pages resides in a small file which is included as needed, and thus when we change it, all the pages are automatically updated. (XSSI directives are processed nearly instantaneously, generally faster than more complex languages or client-side technologies.)

We have extensive documentation on XSSIs, including useful examples of every directive, on our Web site.

PHP (server-side)

PHP originally stood for "Personal Home Page" as a simple means of creating dynamic Web pages (akin to SSIs) but has since grown into a full programming language. (PHP code looks like C.) PHP scripts are embedded in your HTML, and are processed before your page is served, as with XSSIs. The difference is that PHP, being a full programming language, can use variables, do math, and even access database files.

In terms of ease of use and number of capabilities, PHP is between XSSIs and CGIs. It executes rapidly, and your script's source code will not be visible to your visitors (same as with XSSIs.)

PHP (on our Kiosk server) must be used in files with names ending with ".php", which means that you cannot use XSSIs and PHP scripting in the same file. In the ".php" file, the script is contained within a "<? ... >" tag.

PHP is not widely used.

For full documentation on PHP, see Chapter 11 of the Stronghold Administrator's Guide:

PHP documentation (Stronghold Administration Guide)
http://www.c2.net/products/stronghold/docs-2.3/admin_guide/HTML/PHP.html