Introduction
On 26 February, 1998, a total solar eclipse occured in the Carribean. The Eclipse'98 E-team was formed over the period 6/97-2/98 for the purposes of creating a website which would provide eclipse-related education and links pre and post-eclipse and provide a live webcast during the eclipse. The E-team's prior web experience was limited to various-themed home-sites on a small scale. On the day of the eclipse, 12 server sites supported Eclipse'98. It is estimated that accesses to Eclipse'98 on eclipse day alone were conservatively over the one million mark. One of our eleven mirrors had over 220,000 hits alone. Guestbook entries were overwhelmingly positive, upbeat, and appreciative.
Scope
This document is intended as the definitive lessons-learned for the Eclipse'98 webcast. A working document updated with comments from E-Team members, it provides an analysis of what worked and what didn't, and provides suggestions for improvements in future events.
Summary
TBD to be completed after inputs received.
Configuration Management
The Eclipse'98 site consists of over 700 files sourced by multiple authors. Getting the correct versions of files onto the site was one of our initial challenges. Nobody likes having their work overwritten and we would not want to copy files manually to create a site. Configuration management was provided by providing a single source of the official site and providing separate staging areas where developer files can be downloaded to the official site then uploaded to mirrors. This process was evolutionary in Eclipse'98 and caused some confusion and minimal loss. Our experience will now allow us to start off with a working solution.
Site Location
Initialy, the site was split between two of the team-member's home-sites. With the split came duplication of files and as a result, a larger number of files and greater upload time for creation of sites. When Netlab came on board, it was decided that their site would host the full Eclipse'98 site. The decision was made not to integrate the two subsites completely but to place them on separate subdirectories on the same server. This decision came about due to lack of time and increased risk that something might be broken in the integration. In the future, we should start with an integrated site approach from day one.
Site Architecture
The site architecture included static HTML pages, CGI scripting, Image FTP serving, and image distribution scripting. Two image server sites provided login access for reporters to download their images. Three server sites included FTP image distribution scripting to provide the images from the servers to the HTML page servers. Two sites provided CGI scripting; one for guestbook and one for the postoffice. A site by site breakdown is shown below.
| SITE | HTML
MIRROR | CGI | IMAGE
SERVING | IMAGE
DISTRIBUTION |
| C@fe Internet | yes | no | no | no |
| CCSSC | yes | no | no | no |
| Eclipse.Net | yes | no | no | yes |
| EduSurf | yes | no | yes | yes |
| EGE University | yes | no | no | no |
| IDS | no | yes | no | no |
| Nebula Digital | yes | no | no | no |
| Netlab North Dakota | yes | no | no | no |
| Netlab Kansas | yes | yes | yes | no |
| Setarnet | yes | no | no | no |
| UMASS Lowell | yes | no | no | no |
| WENET | yes | no | no | yes |
This architecture worked fine under reasonable loading conditions, but did not work well for the webcast portion under the saturation conditions of E-day. Having the image servers also host HTML mirrors was not an optimal design since the load on the mirrors prevented live images from being downloaded. It was not a good assumption that live FTP/logon and distribution can occur on or to a mirror under E-day conditions. A better design would have split the images over several dedicated image servers. Some method of prioritization of FTP over HTTP protocols would have been useful to make sure that live images on the image servers got priority to be downloaded. If different sets of images were downloaded to each image server and all mirrors pointed to all image servers, we would have had a better result for the webcast portion of Eclipse'98. These image servers would be sized according to the number of images they serve.
A more complex but more appealing approach would have the entire live webcast portion of Eclipse'98 (images and HTML) hosted on separate webcast servers not directly accessable except through a quota gateway. In this manner, the number of viewers can be controlled for a good experience for those who get through. Entry could be first come first serve like a queue or an electronic ticket office could provide E-tickets ahead of time and at the door for access at the show. The terms "sold-out" and "standing room only" would find new meaning. Of course we would require a bit of demographics information in the request for the ticket. Ticketed users could lose their spots if not connected at the prescribed time and slot made open for the "standing room only" queue. Standing room can be adjusted in real time to allow more people to attend impromptu, or not allow new viewers when others leave until the new quota is reached.
Compatibility
For a user to see the intended web content, the server they access must be configured properly to interpret the content, the browser the user uses must be compatible and on a compatible platform type. Based on the experience of the programmers, pages were created on PCs running Windows 95 and browsing using Netscape 4.x. Attention was not prioritized for other platforms, operating systems, and browsers. The web promise of standards and portability, we found, is a long way off and any compatibility is reached through painstaking effort.
Server Compatibility
Just because a site is working on one server doesn't necessarily mean that it will work on a mirror. You can copy the same files to the same directories as the master and it may not perform correctly. Prospective mirrors have configuration files specifying how their servers will interpret various file extensions. This is called MIME mapping. Commercial, mainstream, mirror candidates were not found to be problematic since their users had already requested the updated mapping which accompanies the newer browser capabilities. Educational sites and no-profit organizations, on the other hand, were found to have older versions of configuration maps which were not fully compatible with Eclipse'98 capabilities. Since these files are seldom touched by the server maintainers, considerable time in the order of weeks was necessary to straighten out incompatibilities. Some of our mirrors were loathe to touch their configuration files and were not fully functional on E-day. In the future, we need to line up mirrors earlier and insist on the configuration features we need.
Browser Compatibility
The major browsers are Netscape and Internet Explorer. These two browsers, while sharing many compatible features, have advanced features which the other doesn't support. When creating a web page, care must be taken to reach the widest audience possible without sacrificing the whiz-bang of advanced features which are meaningful for the site. Not only is this a problem between Internet Explorer and Netscape, but also with subversions of the same browser. Ideally one would create as common a web page as practical then add duplicate content coded in each of the major browser types. Without a web page production staff, this is not feasible due to the added time necessary for development. The correct level of effort was used in developing for Netscape 4.x.
Platform Compatibility
Even if the same browser is used from the same server, differences in the same browser version from platform to platform were found. Netscape 4.0 and Internet explorer were found to work poorly for our site on Macintosh computers and for screen sizes under 800x600. Windows 3.1 posed another set of compatibility problems. A great deal of experience and testing would be required to test the site for all platforms. This level of effort was not feasible in Eclipse'98. The correct level of effort was used in developing for a PC with Windows95 platform.
Communications
Communications worked pretty well for the team as a whole, considering the diverse locales of E-team members. E-mail was the principal communications medium with ICQ, Netmeeting, and AOL Instant Messenger peppered in for tighter communications. The feeling of "team", however, did not really gel, as would happen in face-to-face meetings. E-mail was not always responded to in a timely fashion. Though not unexpected in a young organization, this could have been remedied with a more structured management and reporting structure.
Testing
Testing was not well-attended by the E-team as a whole with just a handful of the team participating. This did not bode well for the live webcast when these individuals had to send their images to the site under difficult field conditions. Some were sending for the first time during the live webcast. We were not able to adequately stress the system with the small testing turnouts which added to our risk on E-day. Testing of static pages was barely adequate with the small test force but managed to find and fix a good deal of static errors in the site. In the future we need to get the whole team on-board for the testing of the site with multiple platforms and browsers. We also need to set up coordinated stress-tests periodically before the event.
Budgeting and Sponsorship
As a new team, sponsorship was difficult. It was easy to find companies willing to put their logos on our pages, but we really received little financial or technical benefit from them. Without the statistics and demographics which an experienced organization could provide, we were at a disadvantage in negotiating sponsorship. We did not get together as a team on a marketing strategy for Eclipse'98, but relied on one or two part-time but highly motivated individuals. As a result, the bulk of the cost of sponsoring the eclipse'98 webcast was borne by the team-members themselves. With the statistics we gather from our analysis of E-day, future sponsors should be more responsive and we can be more selective.
|
