ON-THE-FLY
EPHEMERAL WEBPAGES

Vicky Vickers

Ephemeral: 1a. lasting or existing briefly. 1b. of interest or value for only a short time. 2. devoted to what is of temporary interest. Temporary, fleeting, topical, transient. (Webster's Third New International Dictionary)

Note: this is not a highly technical, how-to article. Rather, it is meant to explain the concept of temporary or "dynamic" webpages which provide very specific information and only last as long as they appear in your browser window.

A lot of webpages are static, showing little or no change over time, unless the person who designed them makes some changes manually. These webpages are created with the language of the web, HTML (HyperText Markup Language), a fairly simple set of tags which tell the browser (Netscape, Internet Explorer, etc.) how to arrange the information in its window. However, a growing number of webpages don't exist until you click on a link or perform a search - they are truly ephemeral! These webpages are often called dynamic webpages.

How do I know I'm on a dynamic webpage?
If you have performed a search, the results are displayed on a dynamic webpage. Another example is a "shopping cart" where you can travel from webpage to webpage on a site clicking on items you'd like to purchase, then when you've finished shopping, you're given a list of those purchases complete with the total owing.

One way to tell if it's a dynamic webpage is to look at the URL at the top of the webpage. If you see "cgi" anywhere in the URL, then it's probably a dynamic webpage. Also any webpage you see that has a question (?) mark in the URL would also be a dynamic webpage. If the webpage is the result of a search, look closely after the question mark and you should be able to pick out the word or words you used in your search.

Why are there dynamic webpages?
As more and more detailed information is placed on the web, and, more and more people with widely differing requirements browse the web, webmasters had to find an simpler, faster way to maintain and produce information in a format which would allow WWW (World Wide Web) users to find the information quickly and easily.

As an example, say we had an on-line bookstore. We could produce different webpages for each author and each category (not only fiction and non-fiction, but also their subcategories, e.g. mystery, romance, science fiction, biography, technical, etc.). This would probably result in thousands of separate webpages and several index webpages. It would also be very difficult and time-consuming to keep the website up-to-date.

To make things more complicated, some authors are multi-talented, writing in several different genre or categories. One of my favourite mystery writers, Carole Nelson Douglas, writes two different mystery series, historical and cat, each with its own series character (Irene Adler and Midnight Louie). She also writes science fiction and romance novels. Not being a romance or sci-fi reader, I don't know if these novels have sub-categories and multiple series characters. However, even if they don't, this author would appear on six different webpages (mysteries, Carole Nelson Douglas, historical mysteries, cat mysteries, Irene Adler and Midnight Louie). And that's just one author, imagine how many webpages we would need for several thousand authors!

So, what is the answer to this problem? Dynamic webpages of course!

How are dynamic webpages produced?
In our bookstore example, an on-line database would be used to organize the type of information required, making that information a lot easier to up-date and maintain. Next a search webpage would be designed to allow the visitors to the bookstore to access the database. Then shell webpages would be designed either with instructions in an imbeded script or with instructions to access scripts residing elsewhere on the server. By shell webpage, I mean that the webpage has virtually no information on it, just instructions to the server on how to find the information requested and how to display it on the webpage.

Note: A server is just as it sounds, it serves up all the Internet items (e-mail, news groups, websites, etc.) to the members of an ISP (Internet Service Provider) and other members of the web browsing public.

One way to do this is with Common Gateway Interface (CGI) scripts, which reside on the ISP's server. CGI scripts are produced with much more complicated computer languages than HTML. Fairly recently (in web terms), a second and somewhat easier way has appeared with PHP.

Now we get a little complicated! PHP (Hypertext Preprocessor) is an HTML-embedded scripting language that lets you embed special tags to create your script right in an HTML file to produce dynamic webpages. If you're interested in more information, the PHP3 webpage is located at uk.php.net/.

Usually produced with a computer language called Perl (and occasionally with C++ and others) CGI is a lot more complicated. CGI scripts are also used in static webpages, e.g. counters, current local date & time, forms, etc. and are sometimes called gadgets by ISPs.

The National Center for Supercomputing Applications (NCSA) at the University of Illinois in Urbana-Champaign. (hoohoo.ncsa.uiuc.edu/cgi/) designed one of the first web browsers, Mosiac. Mosaic Beta 2, released on Monday, September 26, 1993 was the first public release for the Macintosh. This is the web browser that I cut my Web teeth on. NCSA provides the following information on CGI which explains the process much better than I can:

"The Common Gateway Interface (CGI) is a standard for interfacing external applications with information servers, such as HTTP or Web servers. A plain HTML document that the Web daemon retrieves is static, which means it exists in a constant state: a text file that doesn't change. A CGI program, on the other hand, is executed in real-time, so that it can output dynamic information.

"For example, let's say that you wanted to "hook up" your Unix database to the World Wide Web, to allow people from all over the world to query it. Basically, you need to create a CGI program that the Web daemon will execute to transmit information to the database engine, and receive the results back again and display them to the client. This is an example of a gateway, and this is where CGI got its origins.

"The database example is a simple idea, but most of the time rather difficult to implement. There really is no limit as to what you can hook up to the Web. The only thing you need to remember is that whatever your CGI program does, it should not take too long to process. Otherwise, the user will just be staring at their browser waiting for something to happen."

What does all this mean to me?
There is one minor problem which needs to be addressed with this technology. Occasionally, when you find some great information which you would like to share with a friend, the URL you send to them, only produces an error message, something like "Page not found on this server". Or you bookmark a great webpage, only to find that the bookmark produces the same dreaded "page not found" message.

These problems are only growing pains. As time goes on, the WWW will become faster, easier to use, more reliable, more accurate and more up-to-date as the technology for producing dynamic webpages becomes more sophisticated.

Acknowledgements
This article was published in the July 1998 issue of the Victoria Macintosh Users Group's monthly newsletter "MACtalk" in Vicky's monthly article "VMUG On-Line".

Thanks to Murray Fallen, President of WEAV and owner of CVC Productions West Ltd. (cvcprod.ca/west/) for his advice in writing this article.

Vicky Vickers is the owner of Word Crunchers, Etc. which specializes in website design and HTML training. She is a past-president (1994-6) and former webmaster (1995-8) of Victoria Macintosh Users Group (VMUG). She also founded and was the first president (1996) of the Web Enthusiasts Association of Victoria (WEAV).

All rights reserved. For commercial purposes, no part of this page may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording, Internet, or any information storage and retrieval system, without the express permission in writing from the author.

Return to Library Index


Call me today at 250-595-6593 to discuss your website design
or e-mail me at vicky@crunchers.bc.ca

Vicky Vickers, Word Crunchers, Etc.
3290 Shelley Street, Victoria, BC, V8P 4A5
Fax: 250-595-7384 (call first)


Copyright 2000 by Word Crunchers, Etc. ([an error occurred while processing this directive])