MetaWeb is a web site for the maintenance and administration of other web sites. It provides form-based tools for the revision and maintenance of large, structured World Wide Web sites.
The project developed out of an effort to overhaul the existing web pages for the Georgia Tech School of Literature, Communication, and Culture. In order to provide accurate and up-to-date information, it was necessary for school faculty to maintain the content of the site. However, technical limitations made it impossible to give each faculty member direct access to the appropriate web pages. Additionally, several of the faculty were unfamiliar with the hypertext mark-up language (HTML) used to format the documents. A third concern focused on maintaining the design consistency of individual web pages within the school's site.
As a solution to this problem, the metaWeb system provides access for editing web pages using several common gateway interface (CGI) scripts and the web server's own built-in security. MetaWeb also reduces the need for HTML on the part of the user by separating presentation and content. Individuals edit the content of the pages via web-based forms, and that content is then applied to pre-existing HTML templates to create the final public web page.
Primary Audience
MetaWeb is primarily aimed at large, inclusive web sites for corporations or institutions; sites that provide standardized pages such as for divisions, employees, or company products. In such a setting, frequent and accurate updates are difficult because the information is often distributed across several departments or individuals. Accurate updating is also impeeded by the requirement that the individual be well versed in HTML.
It is unavoidable that a skilled web designer will be required for any significant web site development. The metaWeb project assumes that such an individual will be performing the initial installation and will provide the HTML templates and forms customized to meet the needs of the corporation or institution. Such an individual will be fluent in HTML and will be familiar with the operation and installation of CGI executables.
On the other hand, the individual who will interact most frequently with the metaWeb system will be the individual who is responsible for updating the content of the various web pages. This individual is expected to have a basic understanding of the nature of the World Wide Web, as well as a cursory understanding of the use of forms within a web browser. The individual is also expected to have access to a networked computer with a form-capable web browser installed from which web page updates may be performed. Anyone not meeting these qualifications will need additional training.
It is possible that some individuals using metaWeb to update information on the World Wide Web may have previous HTML training. Such an individual may wish to apply this training to further stylize or more effectively format the information to be presented. The metaWeb system is expected to accomodate such an individual.
Secondary Audience
It is important to recognize that the metaWeb system is being developed by graduate students who will likely present the system as part of their graduate portfolio. Thus, a secondary audience has been defined to be the professionals and academics who may wish to view the metaWeb system from the context of either considering to use such a system or to hire the creators. Such an individual is likely to have a thorough understanding of the issues surrounding the implementation of a large web site, and thus be in a position to recognize the value of such a system.
Style
For both reasons of usability and presentation, it is necessary that web pages that are unique to the metaWeb system be visually distinctive. This will help to develop a clear "metaWeb" identity, as well as to limit the potential confusion that users may otherwise experience when moving between the metaWeb system and the web site it is used to update.
One of the most effective methods for establishing consistency within a web site is the use of background color and texture. In the case of metaWeb, a subtle tan paper texture was created that is distinctive in appearance but also provides for excellent readability when used in conjunction with standard black text. Since much of metaWeb's functionality comes from the use of HTML forms, the background was carefully designed to contrast nicely with the white text-entry fields rendered by most browsers.
A metaWeb logo has also been created in addition to a standard color scheme that all metaWeb pages will utilize in one form or another. Together these design elements will serve as visual cues to both establish a clear identity for the metaWeb system and to help convey a sense of location within the web site to the user.
Functionality
There are five primary design goals concerning the functionality of the metaWeb system:
- Access. The metaWeb system needs to provide a method by which the user can access the file system of the web server in order to store changes made to the public web pages.
- Simplicity. The metaWeb system must allow users to update information on the public web pages in a simple, straight-forward way without requiring that they know HTML.
- Flexibility. The system must be flexible enough to give users who are well versed in HTML the option to use that knowledge to further enhance the formatting capabilities of the system.
- Modification. MetaWeb must provide a method by which users can return to pages at a later date to modify the existing contents without requiring them to recreate the material.
- Portability. The metaWeb system must not be limited to any one platform for accessing the system, as different users will have varied preferences for computer systems.
As a general principal it is safe to assume that anyone using the metaWeb system has "other more important things to do." For this reason, for metaWeb to be effective, it must avoid frustrating or otherwise discouraging the individual from using the system. If the system discourages the user from updating web site information, then it must be considered a design failure.
Web Sites for Updating Web Sites
When one has chosen to update the information on the web, it would seem to make sense that one naturally turn to the web where that information is stored to make the modifications. For this reason, it was decided that metaWeb should operate via the World Wide Web as opposed to some external application. In addition to being a more reasonable approach to updating web site information, operating via the web also satisfies the design goal of portability and platform independence, as stated above.
MetaWeb Gateway
The primary pathway for accessing the metaWeb system is through the metaWeb Gateway page. The Gateway page contains a selectable list of all metaWeb users and a button that takes the user to the corresponding metaWeb User Access Page. Although metaWeb users are not required to use this gateway to access their individual pages, it provides a single universal resource locator (URL) that may be used by all metaWeb users, instead of requiring that each remember a unique URL.
User Access Pages
Each metaWeb user has a password protected User Access Page, which lists each of the actions the user may perform. This allows information maintenance responsibilities to be personalized for each user. The page also serves as a simple menu for the user, from which one can easily choose what actions to perform.
The User Access Page also serves an important role of encapsulating levels of complexity and masking them from the user. Specifically, the links off of the User Action Page often call metaWeb CGI scripts that require several path and search arguments in the URL. It would be quite unreasonable to expect the user to have to remember such complicated URL's. Instead, the User Action Page encapsulates them within links from menu options which allow the user to simply pick and choose.
Forms
Although the design of the forms is defined by the web designer who is installing the metaWeb system, there are several recommendations to be followed. First, each form should make use of the standard metaWeb background texture and logo. As described earlier, this will help create a consistent identity for the metaWeb portion of the web site that will help avoid unnecessary confusion on the part of the user. Second, the forms should clearly define the information sought and, when possible, present the fields in a fashion that is similar to how the information will be formatted on the final page.
Despite these recommendations, it should be noted that primary functionality of the controls on a form cannot be controlled by the web designer. How the controls work is dependent upon the web browser that the user happens to be working with at the time.
Previews
Another interface element that is defined by the web designer is the web page preview. In fact, the metaWeb system does not require previews to be created, but it is strongly recommended. In general, a preview page should be generated for every form that is filled out. Such a preview would provide the user with a chance to see how the final public page will look before making the modifications permanent.
In most cases, the web page preview will be designed using the metaWeb "Preview" graphic included with the other metaWeb images. In addition, at the bottom of the page will be a metaWeb horizontal rule, another included image. Beneath the horizontal rule will be included a standard web page submission form consisting of a single button that triggers the installation of the modified page.
In virtually every other way, however, the preview page will resemble the final public page that gets installed. This includes background color and texture, font colors, etc. Due to the close resemblance between the preview and public pages, it is important to ensure that the "Preview" graphic remains centered at the top of the document, designed to clearly indicate that the page has not yet been installed.
Meta Symbol
Once installed, every document editted by metaWeb will contain a small trademark graphic of the metaWeb system. This unobtrusive small, red "m" serves two purposes. On the one hand, it distinguishes pages that are editable via metaWeb from those that are not accessible through the system. It also contains a link to the metaWeb Gateway page. Thus, if a user has forgotten the URL of the metaWeb Gateway, he or she can simply visit the page to be updated and click on the "m" in the lower right corner to link into the system.
It is essential that this Meta Symbol be kept relative small and unobtrusive in order to avoid distracting from the installed web pages. At the same time, the image has been designed to be consistent with the text styles and color schemes used throughout the metaWeb site, which should help make the connection clear between the trademark and the metaWeb system.
Flow Diagram
A typical session with metaWeb will take the user through five screens, and send information to four different CGI scripts.
- metaWeb Users List Form
On this screen, the user is presented with a simple form -- a scrolling list that includes the name of all LCC faculty members. The user hilights his or her own name on the list by clicking on it and then clicks the "Go" button. This passes the form's information along to the redirect.cgi.
- redirect.cgi
After being passed the proper user name from the form above, this script checks the name against a text file that contains matching URLs for each name on the list. It then returns this URL and redirects the browser to the appropriate faculty directory.
- Password Protection
Before allowing anyone into a metaWeb users directory, where they will potentially be able to write over existing information on the server, the server will ask for a username and password. For simplicity's sake, the usernames are the same as the faculty members' directories. (The passwords, of course, are chosen at random.)
- Individual User Actions
Once the user enters a password, he or she is permitted to view the index file of their directory. This file is a list of actions that that particular user has authority to perform. Obviously, this list varies by user and hence must be updated by the Web administrator on a regular basis.
- fillform.cgi
This script retrieves the user's existing information (stored as a .txt file from the last time the same page was edited) and applies the information to the fields of the form that the user will fill out. This eliminates the need for the user of having to type the information in each time he or she wants to make a slight revision.
- Update Request Form
This is the form that the user must complete in order to affect a change on the final page. The existing information has already been entered by the fillform.cgi, leaving the user free to enter only the desired changes and click the "Submit" button to send the information to template.cgi.
- template.cgi
This script takes the revised information that was gathered on the form above, and applies it to a predetermined HTML template document that lies on the server (the script knows which template to use because that information is passed along in the last form in a hidden field.) The template that this script uses will always be a preview template -- the final document template will not be used until the user has had a chance to review his or her changes.
- Preview Document
The page returned by the template.cgi looks exactly like the actual public page, with the exception of the metaWeb "Preview" graphics that run along the top and bottom (and the "Install This Page" button located at the bottom.) This page gives the user a final chance to spot any errors before his or her old page is overwritten on the server. When all changes have been approved, the user clicks the "Install" button and sends the information in the hidden fields of this page (which is actually a form) to the next script.
- install.cgi
This script strips the information that the user has just entered from a temporary text file and flows it into the final template that defines the document. There are security measures built into the script to prevent it from writing to any other directory than the one from which it was called. After the script has written the final, finished file to the server, it then returns the appropriate URL to redirect the user's browser to the actual, updated page.
- The Finished Page
This is the final version of the page that is now written to the server's hard drive and publicly accessible. Unfortunately, when the user's browser loads this page at the directions of install.cgi, the changes the user has just made are usually not apparent -- this is because the browser has most likely already cached a version of the page and rather than loading it again from the server, the browser will simply serve up the cached -- and now obsolete -- version. A simple reload of the page will reveal the true look of the revised document. Should the user desire further changes, he or she may use the browser's "Go Back" feature to return to the Update Request Form. Furthermore, the small red "m" that appears on the bottom of the page will always return the user to the metaWeb Users List (1.).Storyboard
Here are some screen shots that demonstrate the interface of metaWeb, as well as illustrating the varied types of document that can be edited with the system:
metaWeb User List
The central page that all metaWeb users visit to access their own personalized meta-directories. After picking their name from the scrolling list at left, they merely click "Go" to send them to their directory.
Password Verification
Before allowing anyone within any of the meta subdirectories, the server will prompt for an assigned username and password. This password verification uses the built-in capabilities of the server, Webstar, and hence is more secure than any propietary scheme that we could have developed for metaWeb.
Individualized List of Available Actions
Once the user's access privileges have been established, he or she is greeted with a list of actions that are available to them; this list will vary by user and must be manually updated by the web administrator as new actions are needed or old ones become defunct. Clicking on any of the available actions will launch the fillform.cgi script that retrieves the information that already exists for that page (if indeed a version of the page does exist) and puts it into the form that the user will enter changes into.
Revision Form
This, obviously, is the form that allows metaWeb users to perform edits on the information on their pages. When the form is first loaded, it already contains the information that currently resides on the page. This eliminates the need to reenter data each time a metaWeb edit is performed. When the information is complete to the user's satisfaction, the form is submitted using a button at the bottom of the page. ("Submit Form", not seen here.)
Preview Page
metaWeb returns a preview of any changes requested by the user before final installation on the server is completed. The preview provides an exact representation of the finished page, with the exception of the Preview graphics (not seen here is a footer graphic that graphically matches the header one.) These graphics are vital to let the user know that the edit on their page is not yet complete until it is submitted for installation. ("Install this Page", not seen here.) As such, it is also important to distinguish the Preview graphics from the other graphics on the screen; hence, they employ the distinctive meta background that the user has seen throughout the editing process.
The Final Page
The final CGI not only installs the requested changes to the document on the server, it also redirects the user's browser to the new page. Unfortunately, there is a possible point of confusion for the user here; if the user has already looked at this page during this web-surfing session, then his or her browser has most likely cached the document internally and simply displays that old version, rather than querying the server for the actual installed document. The user must hit "Reload" in order to view the actual page. Not visible here is the meta "m" that will lead the user back to the central metaWeb users page.)
Custom Action Form
Another example of a form that allows users to update pages over which they have no "actual" access privileges. This form uses totally different field information than the previous one, yet they both employ the same scripts and procedures.
Finished Custom Page
The final page generated by the information from the form above and a prewritten template residing on the server.
Another Custom Action
This very simple form gives more freedom to the user to employ HTML in their page. Obviously, it requires much more knowledge of HTML than the previous forms but, through initial testing of metaWeb, we have found that many users appreciate the system for the access it gives them to the server, and do not mind actually coding the HTML themselves. In such cases, a form with one big text entry field provides an ideal solution.
Finished Custom Page
Final installed page showing the wide range of page layout that can be accomplished with metaWeb's forms and templates; the web administrator can either provide detailed templates and very stringent forms or provide loose templates and forms. metaWeb's functionality and ease remain either way.
MetaWeb's greatest strength, as well as it's chief weakness, is the fact that it is an HTML and CGI-based application. In a way this makes perfect sense; methods for modification of the Web are best served on the Web. But the limitations inherent in processing information with HTML forms and server-based scripts have also presented many challenges to the capabilities of metaWeb.
Tool Choice
Applescript
The tools used to produce metaWeb were initially chosen to suit the specific circumstances of the LCC Web site that houses it; the LCC site is served by a Macintosh web server (Starnine's Webstar) which is scriptable by one of two means -- either through AppleScript, or MacPerl. Due to the easy availability of Apple's AppleScript Editor, and the large amount of documentation concerning Webstar and Applescript on the Web, we opted for AppleScript over MacPerl. This decision had several benefits as well a few drawbacks.
The principal shortcoming of the Applescript scripting language is its platform dependance. The current version of metaWeb can run only on a Macintosh server, whereas had the scripts been done using MacPerl, they would have been easily modified to run on other types of servers; the Perl scripting language is designed to operate within many different environments.
AppleScript is well suited for the early, developmental stages of metaWeb, though, due to its relatively easy learning curve, and the fact that it affords a fairly advanced level of control over the functions of the Webstar server and the Power Macintosh 8100 that runs it. One thing it does sacrifice is speed -- some of the metaWeb scripts take as long as thirty seconds to process the text fed to them. Future versions of metaWeb will utilize more powerful scripting approaches, possibly JavaScript or Java, and will attempt to increase speed and performance.
Webstar and MacHTTP Servers
We found it necessary during early stages of our development to create a "mirror site" to the actual LCC Web Site that would allow us to test metaWeb without adversely affecting the performance of the publicly accesible server. For this mirror site, we obtained a copy of the shareware equivalent of Webstar -- called MacHTTP and distributed by the very same company that markets Webstar, StarNine Technologies. MacHTTP and Webstart operate very similarly, with some minor exceptions that required some small adjustments when metaWeb was finally moved to the actual server.
Ancilliary Tools
Several tools have been especially useful throughout the production of metaWeb. Most notably, Barebones Software's BBEdit Lite 3.5 has been very beneficial for the large-scale coding of HTML; given the large number of documents contained within the metaWeb hierarchy, BBEdit's robust search-and-replace capabilities (it can search not only within a document, but within entire folders of documents at one time) proved invaluable in the production of metaWeb's HTML templates and forms.
Fractal Design Painter and Adobe Photoshop were used to produce the graphics and background texture that give metaWeb its distinctive look and feel.
Technical Constraints
Some of the most severe constraints upon metaWeb are due to the limitations of HTML and CGI scripting. After some initial user testing, one area of complaint seems to be related to the amount of interactivity that can be achieved using these simple tools -- some users have commented that they would prefer more choices on the forms, that they would like to see multiple buttons for performing different actions (ie. "Install this Page" and "Preview this Page" both on the same form, rather than at different stages of the session.) This, quite simply. is a shortcoming of current standard HTML. A document may only perform one action -- either "getting" or "posting" -- per form. Concerns such as these cannot be addressed until metaWeb progresses to tools that allow more freedom for building interactivity into a Web page. For further discussion of planned improvements to metaWeb, see Development Timeline, below.
Training
There are two levels of user that must be considered when discussing the training aspect of metaWeb: not only must the end user be trained in the use of metaWeb, but so too must the Web administrator be trained in the production of the templates and forms that are used by the scripts.
The end users are fairly easy to plan for; here at LCC, in our immediate plans for implementing metaWeb on a wide scale, we have developed a brief, concise demonstration of metaWeb's practicality that we can deliver to the entire faculty, either in whole or meeting with small groups. This demonstration walks the user through a typical interaction with metaWeb, reinforces the ease with which web page edits can be performed, and clarifies the steps the user need take to modify their own pages. The demonstration lasts less than ten minutes and provides all the information a potential user needs to access metaWeb on their own.
System administrators, on the other hand, will need more training in order to reliably construct the documents that support metaWeb's operations. The scripts for metaWeb are designed for flexibility, allowing them to be applied to many different types of document, provided the templates for those documents are accompanied by forms that supply them with the proper information. In order to construct these forms and templates correctly, system admins will necessarily need to be familiar with the workings of metaWeb and understand exactly how it applies information from a form to their pre-constructed templates. This level of "expertise" at metaWeb will undoubtedly require some written documentation. Perhaps a slim (30 page) manual that outlines the inner workings of metaWeb and gives step-by-step procedures for creating templates and the accompanying forms.
Development Timeline
Short-term Goal
Our immediate goal for metaWeb is to make the site it accompanies, that of Georgia Tech's School of Literature, Communication and Culture, fully integrated with metaWeb's capabilities. This would mean that every public page, whether a faculty homepage, calendar of events, course listing or class syllabus, would display the meta "m" and be editable using our system. Although we have a good start (currently all of the faculty homepages are metaWeb capable), the task ahead will require the adoption of tools that are not currently used in metaWeb.
Most notably, the need for more complex forms than the ones he have already developed will become a problem should we continue to develop metaWeb using Applescript and simple HTML forms. Some documents (syllabi, calendars) require a greater level of formatting -- and more freedom of formatting -- than the fairly simple faculty homepages that we're currently using. For example, on a class syllabus, the user will require the ability to add fields to the form to accomodate new entries. Each new entry could be any one of several types of information (a journal name, a book citation, a project description, etc.) There is simply no way to account for all of these eventualities with current HTML forms.
Additionally, sending information back and forth through forms puts an undue amount of strain on the server; processing the information via CGI, parsing the text and returning properly formatted HTML documents are all tasks that drain upon the server's resources and take away from its true mission -- that of simply serving up web pages. We are hoping that emerging Web technologies will help us deal with these problems of limited interactivity and server-side processing.
Long-term Goals
Eventually, we would like to incorporate Java programming into metaWeb's design. This would have several benefits: first and foremost, if we were to make metaWeb's forms into Java applets that operated within the browser's window, we would have much greater freedom of design. Fields could be added to forms interactively and dynamically. There would be no complicated, slow passing of information through HTML forms and hidden fields. Java programming would allow us to build a simple HTML editor that would be custom-tailored to the mission of metaWeb: allowing the user to control content but allowing the site designer to control form.
A secondary benefit to using Java is client-side data processing; our metaWeb applet would process all information and run all processor-intensive procedures on the user's computer, before any information is ever sent back to the server. This would take a great amount of strain off of the server, not to mention greatly increase the speed of metaWeb's operations.
Finally, turning metaWeb into a Java-based system would make it platform-independant; the procedures and tools we've developed to date have been tied down to one specific type of server -- one running on an Apple Macintosh. The Java programming language is designed to be executable on all different platforms. The scripts and procedures we write in Java can be ported over to other servers with an absolute minimum of reworking, possibly none at all. This will give us a great amount of freedom as designers.
We are currently in the first evaluative stage of developing metaWeb. The prototype has been functioning on the LCC web site for several weeks and several faculty members have been using the forms and templates to modify their own pages. Initial feedback from users has been both encouraging and informative. Many users seemed appreciative of the fact that they could now have some form of control over web pages which were previously off limits to them.
A few users have shown enough interest in metaWeb to request that we create additional templates for their use that would allow them to edit customized pages for personal projects. (See Joseph Petraglia-Bahri's Reality Check page.) Additionally, several of them have provided interface critiques and pointed out weaknesses in the current implementation of metaWeb; unfortunately, many of these criticisms are products of the limitations of the HTML forms. The inability of the browser to wrap text within text-entry fields and the ability to have no more than one active button on a form were limiting factors that users noticed and commented on.
Our initial testing has been performed with a small sampling of LCC faculty. With the coming quarter, we hope to widen our user base to include all people who are represented on the LCC web site (faculty and staff). At that time, we will start delivering mini-seminars to users -- brief ten-minute demonstrations of metaWeb's use. From that point on, evaluation will be carried out on an ongoing basis. As we expand metaWeb's capabilities, we will test new features as they come up.
The current version of metaWeb, though functional and a vast improvement over what was there before, is still just a prototype; it demonstrates that it is possible to build the features to modify a web site into that self-same site, but it does not go far enough. For metaWeb to truly become a uniquely new way to structure a site, it must be far-reaching. metaWeb must be able to modify any page on a site with a modicum of effort (on the part of the end user, that is.) It must remain secure, and it must give the web administrator the freedom to incorporate many different types of document within the site.
Fortunately, although it is now only a prototype, it is a good prototype. With the strong base we have to build from, our goals will be much more attainable -- we have already done most of the planning, now we just need to implement those plans. This will require us, as designers, to move on to more flexible tools and to learn new skills. Whether future implementations of metaWeb are Java-based or written in Perl, they will undoubtedly offer greater flexibility of design, allowing us to build in new features as the need arises.
Although we have no official reason to continue to develop metaWeb (for the past quarter we could at least claim course credit), the reactions we have been getting for the system are encouraging enough that we feel it is in our best interest to continue ahead with the project. metaWeb is now a labor of love.
Copyright Johnson & Glass, © 1996. All rights reserved.