University of Vermont

Promoting a common template for a large university web site: The UVM Magicscript Project

Copyright by AACE. Reprinted from the WebNet 2001 Proceedings, October 2001 with permission of AACE (


Promoting a Constructive Template for a Large University Web Site: The University of Vermont MagicScript Project


Wesley Alan Wright, Academic Computing Services, University of Vermont, USA,


Tatianna Salcedo, University Web Team, University of Vermont, USA,


Meredith Woodward King, University Web Team, University of Vermont, USA,


Debra Goller, University Web Team, University of Vermont, USA,




Abstract: A large university Web site is a tool, an application utilized by a broad base of users with various purposes and goals. By employing a common interface such as a constructive template, a university can generate a standard graphic and navigational design throughout its Web site. We demonstrate how, by using a dynamic template that is composed of centrally located graphic and layout components integrated by scripts, we are able to achieve uniformity while allowing for varying degrees of creative freedom from Web site developers. Our template structure also can extract institutional content from central databases of personnel, calendar, news, and course information. We also will discuss how the template structure has an impact on Web support in a large campus environment.





The University of Vermont (UVM) published its first Web content in November 1993. In subsequent years, the number of HTML documents has grown to more than 80,000 Web pages created by users with a broad range of skill levels using a variety of tools and computing platforms. In the summer of 1998, the university made a concerted effort to address the issues of organizing the existing content and develop a consistent page layout and navigational structure. Just a few months earlier, Norsk Regnesentral, the Norwegian Computing Center, had begun developing its constructive template to address similar issues on its Web site (Østerby and Larsen, 1999).


To promote some level of design continuity at UVM, an archive of graphics and an official university logo previously had been made available to campus Web site developers. However, the use of common graphics alone only tacitly addressed the design issue and did not provide a solution for a uniform navigational structure.


The constructive template which emerged from the 1998 effort provided common design elements and a navigational framework that could be manually laid out by the Web site developer or dynamically generated by directory content. We chose to leverage existing tools in the university’s main UNIX servers, Apache Web server, PHP, and mySQL to develop the template.


Since its implementation, the template has undergone one major revision (in 2000) and countless minor revisions. Template users’ sub-sites successfully reflected the new template design and navigation.





On the technical front, the template project is compatible with existing university hardware and network infrastructure. Additional requirements include the ability to remain compatible with common Web-editing applications, to meet accessibility standards as established by the Web Accessibility Initiative (WAI) of the W3C, to be available to any university constituent and to provide varying degrees of customization for Web site developers.


The methodology for developing the template follows the Object-Oriented Hypermedia Design Method’s (OOHDM) four steps: conceptualize the data underpinning the Web site; develop a navigational structure for layering content; design an interface appearance and behavior; and map the data to the design. This type of model provides a better understanding of the design and perpetuates clear documentation (Lowe, 1999).





The strategy we chose to pursue involved the use of a constructive template. This strategy is cost-efficient in its reuse of navigational and graphic design. It relies on the separation of the document’s contents from its presentation. The presentation can be altered centrally without compromising the embedded data. This is an object-oriented approach and offers more flexibility over a cloning approach that does not allow automation of design adjustments and improvements. When implemented, the constructive template benefits Web site production and life cycle and creates a modularity that can be ported to alternative design strategies (Nanard, Nanard and Kahn, 1998).





The UVM template comes in many different styles. Template styles are, in most cases, determined automatically by what we dubbed the Magic Script, or MagicScript. Templates also can be manually selected by using a subcommand in the configuration file.



Figure 1: Constructive Template in action






1. UVM Banner (top)

2. Page Title (below Banner)

3. Main Menu type (below Page Title, in blue)

4. Optional Graphic (above Quick Links)

5. Optional Quick Links, et al (on right of page)

6. Content (below Main Menu type)

7. Jump Menu and Contact Info (bottom)

8. Optional Sub-Menu


The Main Menu represents the primary organizational hierarchy of the site. The Sub-Menus are used to expand Main Menu topics. "Quick Links” consists of several possible sub-items: Quick Links, News and Events, a To-Do List , a Q&A and/or Current Topics. These are designed to help expose important items on this sub-site that might be otherwise buried in the hierarchy. (Other campus sub-sites and off-campus sites might also be included in “Quick Links.”)



The MagicScript


The MagicScript was written using the PHP scripting language. PHP is an open source project, well integrated with the Apache Web server project. PHP provides a rich scripting environment. The PHP language interpreter is compiled as part of the Web server software; thus, the PHP scripts are parsed and processed directly by the Web server, resulting in fast execution. The MagicScript and its supporting code modules are installed on the university's centrally supported UNIX cluster, home to about half of the university's 80,000 Web pages.


We use a common PHP security feature, known as "SAFE MODE," on this UNIX cluster. This security feature necessitates that every user who wishes to employ the script must have a copy or clone of the script in their Web publishing directory. To use the MagicScript, content providers run a utility program that makes a copy of the magicscript.php3 file in their home Web publishing directory.


The clone script is rather bare bones: The code consists solely of a few "include" directives that suck up the real script code from elsewhere on the cluster using HTTP protocol. Thus, SAFE MODE restrictions are satisfied and the university’s Web Team can safely change the centrally controlled script sub-routines even though the "main program" clone is widely distributed.



The Menu Files


The MagicScript installation utility also creates two additional files that the user can then edit and deploy as they see fit. These files are named default.html and defaultmenu.html.


The defaultmenu.html file serves as the default Main Menu and overall site control file. The menu is defined by an HTML table, with three columns and as many rows as necessary.



Department Title Goes Here,tc=short


Menu Item 1



Menu Item 2



Menu Item 3



The first column represent the order in which the Menu Items will appear in the Main Menu of the Web page (except for Row 0, described below).


The second column represents the text labels that will be displayed as "Main Menu" choices for the Web site.


The third column represents the URLs associated with the labels in Column 2. The URL can be a simple HTML filename (e.g., page2.html), a complete URL (, or a keyword and string of additional script parameters that produce specialized content (See The Content Area).


Row 0 of defaultmenu.html has special meaning. Column 2 of Row 0 specifies the overall Page/Site Title. Column 3 allows the user to specify additional site parameters to the script, such as a contact e-mail address or a particular template style from our template library.


Additional menus, used as Sub-Menus or in special navigation areas, are constructed in an identical manner to defaultmenu.html, but without a Row 0.


Sub-Menus are identified to the script by passing the file name as a parameter (e.g., SM=submenu_name).


Items in the "Quick Links" area, (including Quick Links, Hot Topics, To-Do List) are generated by like-named files (quick_links.html, hot_topics.html, to-do_list.html). If these special menu files exist in the user’s folder, they are automatically displayed. Similarly, if a file named "default1.jpeg" exists, it is used as the optional site graphic.



The Content Area


If the URL specified in Column 3 of a menu is a simple HTML file name, the script will use it to construct an anchor of the form




The file identified by script parameter Page is read by the script to fill the "Content Area" of the template. Some processing of the file is performed to generate page META information.

We have a growing list of keywords that can be used in lieu of a file name. These keywords, together with additional user supplied parameters, generate "institutional content" such as course listings or campus maps. This institutional content is drawn from various administrative databases maintained by central campus services. For example, an entry in column 3 such as




will tap the campus Directory Server to produce a list of faculty in the School of Natural Resources, while




will query our BANNER Student Information System to produce a listing of Forestry courses.



Automatic Mode


The site model provided by defaultmenu.html and some small collection of Sub-Menus is good for about three levels of site depth. Beyond that, additional folders and defaultmenu.html files may be required; however, for very large or frequently updated collections of content, the maintenance of all these menus becomes an issue. Moreover, information architecture literature suggests that "the foundation of almost all good information architectures is a well-designed hierarchy” (Rosenfeld and Morville, 1998).


The directory and file structure of the typical Web server enforces a rather strong natural hierarchy: Barring the use of file aliases, a particular file of content, or “content chunk,” will exist in one and only one directory or folder.


Our MagicScript features a mode of operation that descends directory hierarchies and builds menus automatically. The script parses the folder in which it exists and indexes every HTML file and folder it finds there.


In each folder:


·       If the script finds a file named .noauto, it skips the folder and moves on to the next.

·       If it finds index.html, it reads index.html and looks for the document <TITLE>. It uses that title as the label for a Main Menu selection.

·       If it finds another MagicScript, it reads the associated defaultmenu.html and looks for the sub-site <TITLE>. It uses that title as the label for a Main Menu selection. The link is constructed to invoke the found MagicScript.

·       If it finds neither index.html nor a MagicScript, it uses the folder name as a Main Menu selection


For each HTML file, it reads the file and looks for the document <TITLE>. It uses that title as a Sub-Menu label.


Each Main Menu and Sub-Menu link is constructed such that the MagicScript again is invoked to display the selected file or folder.


When asked to display a folder, the script behaves as above, again displaying enclosed folder titles as Main Menu links. A link to the enclosing folder also is added. If there are no enclosed folders to display as Main Menu items, the Main Menu items don't change.


When asked to display a page, the menus remain intact and the page is displayed in the Content Area.


The navigation always reflects the current state of the document space; thus, careful attention needs to be paid to organization. Because the menus always display document Titles as links, careful attention must also be paid to document Titles. Document file names are mostly unimportant. Updating the Web site simply requires the content provider to add, delete, or edit the content files; navigation takes care of itself.


The script also recognizes JPEG or RealNetworks RealMedia files within a folder. For each it finds, it attempts to extract internal file descriptors (Title, Credits, Copyright, etc.) to use as menu labels. In the case of JPEG images, small-image thumbnails are built automatically and added to the menu. Clicking on the label (or thumbnail) displays the full-size image or movie.



Future Work


Our current system is loosely tied to our Oracle-based SCT-BANNER Student Information system via CGI-BIN-style PERL scripts. As we write this paper, we are converting these to PHP4 with Oracle support.


Our current campus directory server is ph/CSO. We are migrating this to LDAP, after which we will rewrite our directory server hooks to use native PHP LDAP support.


Using the Steltor CorporateTime calendar server, UVM has increased standardization of campuswide calendar services. Currently, and again using CGI-BIN, we can access our calendar database. We hope to streamline this using the PHP MCAL libraries.


Slowly, as we consolidate these elements, we hope to have a fully integrated "campus portal" incorporating calendar, course, and personnel database information.













Since its inception, the MagicScript methodology has achieved wide acceptance at UVM. Use of a common methodology has allowed the UVM Web Team to concentrate its support efforts on developing, promoting, and teaching the MagicScript. It also has saved time and resources for our users -- the administrative assistants and work-study students who ultimately are the departmental Web site managers. They now have a common framework in which they can concentrate on the timely update of content rather than on the complexities of design and navigation. In addition, the constructive template provides continuity for departments that use student workers, whose shorter tenures otherwise might lead to site-maintenance issues. Overall, we have been able to build a community of users who are now beginning to support themselves.


The constructive template also has allowed rapid prototyping of new designs. This was proven during the summer of 2000, when our staff of three people revamped hundreds of pages at the top level of UVM’s Web site, as well as 50 participating sub-sites, in less than four months. Most of our time was spent seeking approval from various audience groups on the redesign; implementation itself only took several weeks.





Ashenfelter, John Paul (1999). Web database development tools, metaphorically speaking. WebNet Journal, 1(3), 14-16.


Lowe, David. (1999). Web development methodologies: help or hindrance? WebNet Journal, 1(3).


Lowe, David. (1998-99). Web engineering or Web gardening? WebNet Journal [On-line].


Nanard, Marc, Jaqueline Nanard and Paul Kahn. (1998). Pushing reuse in hypermedia design: Golden rules, design patterns and constructive templates.” HyperText 98.


Østerby, Kasper and Arve Larsen. (1999). Maintaining legacy WWW sites using constructive templates. WebNet Journal, 1(3).


Rosenfeld, Louis and Morville, Peter. (1998). Information architecture for the World Wide Web. Sebastapol, CA: O'Reilly & Associates.

Last modified February 22 2008 08:37 AM

Accessibility | Privacy/Terms of Use | Contact UVM © 2020 The University of Vermont - Burlington, VT 05405 - (802) 656-3131