To create two independent avatars, just click this link. Then, open this page in a different browser and click it again.

If you're curious, more information about how the site was developed and how it became the first site to use AJAX is provided below.

So first, a brief overview of AJAX: in the beginning, web pages had a distinct limitation. If you wanted to change anything on a web page, you would have to reload the whole page. Since this was a slow and inefficient process, web pages were generally static like the pages of a book. Other types of software did not have this problem, so it was a serious downside to producing content for the web.

Like many web developers in the late 90's, I wanted to find a way around this. I had previously worked with an interactive content development platform from Apple called Hypercard. While Hypercard had many of its own limitations, it did not suffer from the static page problem that the early web had. You could always add or remove information from the screen without having to reload the entire screen. When I started doing web development in 1994, I wanted web browsers to work as well as Hypercard did.

In 1996, when a new set of browsers came out featuring Javascript and frames, it became possible to use AJAX techniques. However, just because it was possible doesn't mean people actually did it. Basically, it took a while to figure out how to use these tools to send data back and forth from browser to server without reloading the page.

In 1997, I built an award-winning site for Contax Cameras that used Javascript and frames in a novel way. Frames at that time required a parent document called a frameset. On this project, we developed a technique for putting Javascript in the frameset document, which allowed for persistent data that could be accessed by all the frames in the document. If that doesn't make sense, don't worry ... it's all outmoded now. The main point of this innovation was that it made it possible to send data back and forth between the browser and the server without changing the content that was visible on the page.

We initially used this technology as a sort of predecessor to DHTML because it gave us greater freedom to hide and show elements on the page and to replace regions of the page with new content without reloading the entire page. After working with this technique for a few weeks, it dawned on me that instead of loading new frames to change the visible content on display, I could just as easily load new frames that simply carried data and then I could use Javascript to pass the data to scripts that control what appeared on the screen.

This is the essence of AJAX -- the ability to move data back and forth without affecting what the user sees.

Once I realized this, I told a friend of mine that I thought I could build a virtual world using standard web techniques. He said it couldn't be done ... which is how I came to build this site. Just to prove I could.

There were still many problems to be solved. Here is a list of some of them and how I solved them:

1. Cross-browser support. There were only two main browsers at the time, Netscape and Internet Explorer, and they implemented several important functions in very different ways. If you wanted to build something as complex as Valley of the Nile in a way that would work on both browsers, you had to contend with serious compatibility issues. To solve this problem, I made a list of the major inconsistencies between the two browsers and came up with a simplified set of functionality I needed. It came down to four basic activities: set style properties, read style properties, change an image, and delete an HTML entity. I created functions that would do these operations in the way required by the platform they were executed on. These functions could then be called from anywhere in the code without concern for which platform was being used. A new web standard was added in 2000, and I updated these functions at that time to execute in compliance with that standard, too. Even though several new browsers have emerged since then, the site still works well on all major browsers.

2. History navigation. When you use frames to load pages that carry data, the browser still thinks that the user has visited a new page. This means that if the user hits the back button on their browser, they will actually be re-requesting old data from the server, instead of navigating to the last page they saw. This can lead to all kinds of problems. My solution at the time was to present Valley of the Nile in a pop-up window with no back button showing. (On some browsers hitting the Backspace key will trigger a Back navigation, so you'll find it's possible to confuse Valley of the Nile by hitting the Back button repeatedly.)

3. Data formatting. All data that goes back and forth between the server and the browser is linear. By that I mean that it is organized in one long line. But there's a lot of useful data that is organized in more complex structures, such as a chart or a graph. In order to send "2-dimensional" data back and forth, it needs to be serialized and deserialized. There are some very cool techniques for doing that now, but there weren't any back then. (Actually XML was emerging, but it was new and I didn't like it.) To solve this problem, I developed a set of delimiters to break the line of data up into chunks that were essentially tagged by row and column so that the linear data could be reconstructed into 2-dimensional data after it has been transmitted.

4. Multi-nodal synchronization. The AJAX technique used by Valley of the Nile is very similar to the one used by Google for gMail and Google Maps about six years later. However, the overall architecture of Valley of the Nile remains unique. Unlike most implementations of AJAX, which simply gather and present new data in response to user requests, Valley of the Nile synchronizes data between multiple remote browsers. The system is designed to know when I type a message or move my avatar, and to spread that news to any other browser that may be viewing the area of the virtual world that my avatar is in. This requires a continuous loop, such that each browser is constantly sending status information up to the server and collecting status information from other browsers to be displayed locally. In other words, if my avatar sends a message, your avatar should see the message as soon as possible, and there is a continuous AJAX loop running on each browser that keeps all the different browsers up to date.

The best answer I can give is that I've looked for an earlier use and have not found one. If you read the Wikipedia article on AJAX, it claims that the earliest uses came around 1999 and they involved techniques that are not considered practical today, such as Java applets or animated gifs that never close their connection to the server and reload with new data as it arrives. By 2001, there were a couple of sites using frame-based AJAX similar to Valley of the Nile, but they were not widely known. Finally in 2005, Google released two major products that used frame-based AJAX. Both products gained a significant competitive advantage due to the use of AJAX, and the term AJAX was popularized.

Since then, AJAX has become a commonly-used web technique and browsers have standardized around a method for doing AJAX interactions that doesn't require using frames. Data formatting and techniques for managing history navigation are also more sophisticated today.

Valley of the Nile is a breakthrough site that was several years ahead of its time. However, because it was a hobby site and did not receive significant publicity, it remains obscure. In August of 1998, it received an award from Project Cool. Later, in 2005, Software World magazine wrote an article about the history of AJAX and mentioned Valley of the Nile as an early example of a technique that only Netscape supported. Although the article is correct that development on Valley of the Nile started in 1997, the Netscape technique mentioned in the article was not used because the technique could not be made cross-browser compatible.

I'm interested to hear any thoughts on this, so feel free to email me with questions at jbeezer@gmail.com. Thanks for reading.