Case Study

By Dr. Jonothan Maybaum. Professor of Pharmocology, University of Michigan.

Please note that UM.SiteMaker (University of Michigan's GVC.SiteMaker) has been nominated for the Computerworld's Honors Program. As a potential candidate to receive this award, the following case study was submitted by Dr. Jonathan Maybaum in the specific format requested by the Program. We realize this is not a traditional case study, nevertheless we thought this information would be very interesting and informative.

1. Short Summary

UM.SiteMaker allows individuals in academic institutions to make customized, access-controlled websites and web-enabled databases. We believe that that this is the first system to offer the flexibility and features necessary to perform this service, while still remaining simple enough for use by ordinary (non-technical) faculty, students and staff.

2. Introductory Overview

If you take a tour of websites at colleges and universities, you may be disappointed at what you find. Maybe not on the surface - most university gateways are pretty good. In many places the websites for schools and departments are also done well. But if you go deeper and look for websites that tell you in depth what individual scholars are really doing, in their own words and images, you will be lucky to find much of substance.

A few years ago, the scarcity of content-rich websites made by academic individuals might have been attributed to the lack of their motivation to create a web presence, since the value of doing so was not necessarily obvious. However, the web has now become an important (and perhaps predominant) avenue for recruiting, collaborating, job-hunting and many other basic functions of academic life, and the disadvantages of being absent from the web are clear. Why, then, is web publishing by academic individuals still stunted?

In a formal sense, anyone at a university can make a website - if they can execute the numerous steps involved in conventional web publishing. This includes designing the graphical aspects of the site, creating HTML pages, organizing them, moving them to their personal web directory, setting access permissions, etc. In reality, though, very few people can do this or afford to pay someone to do it. Even then, after the site is made it tends to get out of date quickly because maintenance is such a chore.

Of course, the question of how to simplify website building is not new, and there is a sizable industry focused on that very problem. Are there no adequate solutions available from that sector? If not, why not?

The approach used by virtually all web-publishing systems (including UM.SiteMaker) is to allow users to enter their information into forms on a web page and store it in a database, so that when a visitor comes to their "site" the data can be retrieved and plugged into a pre-formed template to generate an apparently ordinary web page. The basic principle here is that, by building into the system as many choices and actions as possible, one can reduce the number and complexity of tasks that the user needs to perform.

What makes one such system different from another? It is the set of assumptions and decisions made by program designers about which choices should be presented to whom, and how to present these choices. The eternal conflict is that the only way to get more customization is to allow users more choices, which means a more complex and difficult user interface. This presents an enormous challenge when trying to design a system that will meet the demand for a high level for flexibility by academic users, who at the same time will tolerate relatively little complexity. To our knowledge, no one had previously met this challenge.

A major purpose of this case study is to explain the decisions that were made in designing UM.SiteMaker, to give non-technical academic users the right choices, and thereby give them a practical way to make their voices heard on the web. We believe that the success of this effort is evident not only by the scope and number of the sites that have been made so far (about 700 websites in over 60 University of Michigan units) but by their variety of purpose, depth of content and degree of individual expression.

3. Benefits

The audience that we intended to benefit directly through development of UM.SiteMaker is the community of scholars who have creative works and ideas to share, and have no reasonable options for using the Web to share them. Beyond that, though, we also intend to benefit the people whose lives and pursuits are influenced by having access to the contents of rich, unique websites made by individual scholars. Below are a few examples that illustrate how both of these populations have been served by UM.SiteMaker.


CS2 Vector Resource (http://sitemaker.umich.edu/dlturner.vectors)

"The ease of creating and updating a web site using UM.SiteMaker has helped my laboratory share DNA sequences and related molecular biology information with other research laboratories around the world."

David Turner, Asst. Professor/Asst. Research Scientist
Mental Health Research Institute & Dept. of Biological Chemistry

When scientists like Dr. Turner create tools and information that can be used by other laboratories, they can be deluged with inquiries about those resources. This website provides an efficient way to handle those requests, and thereby assists both Dr. Turner and his collaborators.


UM Emergency Medicine EBM / Journal Club Home (http://sitemaker.umich.edu/emjournalclub)

"I would not have been able to spend the time or gather the resources to get our Emergency Medicine Journal Club online if it had not been for UM.SiteMaker. Our residents rotate to different hospitals and different services, and if they didn't check their box in our offices they often missed getting their Journal Club packet, and were not prepared for our discussions. Now, through our UM.SiteMaker site, our Faculty and Residents have much quicker and easier access to the materials that I distribute, to their assignment schedule, and to links to other relevant resources. UM.SiteMaker has helped me deliver on our educational mission without having to learn HTML or hire a programmer."

Robert Silbergleit, Assistant Professor
Department of Emergency Medicine

The site that Dr. Silbergleit created is not only helpful for him and the members of his residency program, but indirectly benefits their patients by facilitating the residents' training.


Shannon N. Bouton (http://sitemaker.umich.edu/snre-student-snbouton)

"UM.SiteMaker was incredibly quick and easy to use, and the result was impressive and professional. I am proud to send people to the page UM.SiteMaker helped me to create"

Shannon Bouton, Ph.D. pre-candidate, School of Natural Resources and Environment

Shannon is one of many students in her School who have created profiles/portfolios using UM.SiteMaker. Each student starts with a site that containing sample information. They are then free to replace the sample data with their own, and to add, delete and modify pages as it suits their needs. The site then serves as resource for the student and her advisors during her matriculation, and can also be used as a reference when seeking internships or a permanent job.


Multicultural and Gender Affairs Committee (http://sitemaker.umich.edu/mga)

"Very good, very easy, very accessible. Helps my international work in extraordinary ways. Easy to learn and maintain. Kudos for UM for promoting UM.SiteMaker."

Larry M. Gant, Professor, School of Social Work

It is typically hard to find support for making and maintaining websites for activities that are in the realm of scholarly service, like this committee. Professor Gant was able to use UM.SiteMaker to bridge that gap.


It is difficult to know if or how success with using UM.SiteMaker will affect people without studying them formally. However, it seems reasonable to speculate that a successful experience will substantially reduce any reluctance that they may have had previously about web publishing, and that the idea of making a new site for some specific project or purpose may eventually become one of the first items of business in planning that project, rather than being an afterthought.

UM.SiteMaker gives people a means of communications that they previously lacked. We hope that by supplying this ability, we will instigate a fundamental change in how scholars approach the idea of communication with peers, mentors, potential employers and the public in general. It is unlikely that this change would happen overnight, because it requires that when the need for communication arises, the person is aware of UM.SiteMaker as a potential solution for that need. So far, the pattern that we have observed is one that is typical of many kinds of technologies, where there are initially waves of trailblazers and early adopters who discover and use the product, followed by diffusion to early and late majorities. General indicators of UM.SiteMaker usage suggest that it is currently doubling over each six-month period, although it is too early to tell how this will play out over several years.

It should also be noted that, along with benefits, facilitation of web publishing presents challenges, such as the possibility that the system will be used for offensive or illegal purposes. At some point, human intervention based on thoughtful policies is the only way to deal such situations. However, it is worth noting that UM.SiteMaker allows sites to be suspended administratively without destroying them, should there be a need to do so.

4. Importance of Information Technology

Clearly, since UM.SiteMaker is a web publishing system, it is in one sense almost entirely a software development project (and, therefore, an information technology project). The evolution of object-oriented programming in general (and WebObjects, in particular) played a significant role in enabling this project to succeed, due to the efficiencies of both development and maintenance that are afforded by use of such modern practices and mature frameworks. As is usually the case for university-based projects, the budget for development of UM.SiteMaker has been quite modest, and if this effort had been mounted before the availability of these tools, it is unlikely that it would have been feasible with the available funds. Another critical factor is that the price/performance ratio of servers has dropped enormously over the past several years. The processing demands of a program like UM.SiteMaker are substantial, and the cost of hardware to deploy it effectively would have been out of reach a few years ago. Now, even modestly priced systems are adequate to support thousands or tens of thousands of users.

Throughout this case study we characterize the primary function of UM.SiteMaker as facilitating communication by academic citizens, through simplified construction of websites. By itself, this capability has already allowed people to communicate in ways that they previously had not done. Nevertheless, the modes of communications afforded by UM.SiteMaker will be enhanced quite a bit further upon the addition of the "Data Tables" feature, within the next few months. Among other things, site owners will be able to include databases in their websites that not only facilitate sharing their own information, but that also support inclusion of simple forms so that visitors can contribute to the contents of the site. Features like guestbooks and surveys are common examples of this type of interaction that are seen in commercial sites made by programmers. Data Tables will allow non-programmers to add such types of interactive features to their websites.

As described in detail in item 5 (Originality), the innovative nature of the project is not primarily in the establishment of fundamentally new technologies, but rather the thoughtful application of existing technologies. From a technical point of view, the most innovative aspect of the project is the implementation of Data Tables. In this approach, a Data Table made by a website owner does not correspond directly to a table in the underlying database; rather, the table and all of its elements (rows, columns, cells) are abstracted as objects, within the UM.SiteMaker program. The advantage of this approach is that it significantly increases the flexibility of operations that can be done with the Data Table, by freeing it from the constraints of the underlying database, as well as eliminating reliance on any particular database vendor.

5. Originality

As far as we are aware, no other college or university has put into production a template-driven application that assists individuals who want to make highly customized websites, and we therefore believe that UM.SiteMaker is unique in that regard. However, there are other types of template-driven web publishing systems that are widely used in academia (and elsewhere), and we think that in order to appreciate the original aspects of UM.SiteMaker, it is necessary to understand what these other types of systems are intended to do, and why UM.SiteMaker is distinct from them.


As noted in the Introduction, template-driven web publishing systems are distinguished from each other by the sets of choices that are presented to users, as well as by the manner in which these choices are presented. At one end of the spectrum are programs that are designed to produce websites with a very specific, pre-determined look and purpose, such as course management systems. Because many of the basic requirements for a class website can be predicted (e.g., places to post a syllabus, resources, assignments, announcements, access limited to class participants and guests, standard layout and graphics) designers of a course management system can justifiably make many assumptions about these features and build them into every site, requiring the site owners to make only a few, simple choices. As a result, course management systems are efficient tools for their intended purpose. At the same time, these built-in decisions make course management systems unsuitable for publishing websites that require significant customization.

Another type of web publishing system that becoming common at universities is the personalized portal, where a user can log in and then be shown information from many "channels". Some channels carry public information (like news and weather) while other channels contain private data (Email, class registration status and schedule, grades). Users are typically free to add and remove channels, to rearrange the layout and order of their presentation, and to add some of their own data, such as favorite links. While many people find portals to be a convenient way to gather disparate sources of information into one place, they are not intended as a way to export information, for use by others.

Content management systems represent a third type of template-driven web publishing that is starting to be adopted at universities. Unlike course management systems and personalized portals, content managements systems are meant to handle information that is mostly intended for public viewing (although many such systems do allow limits to be placed on who can view certain pages). These systems are at the opposite end of the spectrum from course management systems in the sense that they are very flexible, but also quite complex to use. Operation of a content management system typically involves a team of people who accept specific roles such as author, editor, site designer, site administrator and system administrator. In practice, these systems are appropriate for publication of institutional or unit-based administrative sites; however, they are not a good solution for individual websites, since an individual student or faculty member would probably not be able to perform all of the necessary tasks to produce a site without considerable training.


Our main conclusion from reviewing the existing methods of template-based web publishing at universities was that the principles behind these systems are sound but that, prior to UM.SiteMaker, no one had yet applied those principles to development of a system for building websites for academic individuals. We believe that the key thing that was missing was a clear understanding on the part of program designers of the requirements, attitudes and expectations of these users.

In the case of UM.SiteMaker, this problem was overcome by the fact that the project's specific goals and requirements were defined by faculty (Drs. Maybaum and Neubig; see item 7 for a more complete project history) who were intimately familiar with the intended user audience, as well as being experienced in software development. As a result of this knowledge and experience, they were able to identify a critical set of requirements that would produce a useful tool for their colleagues and students, while still adhering to sound principles of software design, and remaining within the available budget.

Here are some of the more critical items that were identified, the combination of which add up to produce UM.SiteMaker's unique capability:

  • "Quick Start": The interface must be clear and simple enough so that non-technical users can create a very simple site in a few minutes, without training or documentation. (Immediate and obvious success is necessary to avoid new users giving up right away. This encourages the investment in time needed to use more advanced features)
  • "Content Organization": Website owners need to be able to easily add and remove pages, as well as to specify and change the way that pages in the site are named and ordered, including creation of levels of hierarchy as their site matures. (Most people have not fully designed their site when they start building it, and need to feel that they can easily "erase" mistakes and re-do parts of it without great penalty)
  • "Navigation": User-initiated changes in organization of the site must be reflected automatically in the navigation links for the site. Also, the URL that is behind each of these links should be context independent, so that it can always be bookmarked or Emailed to others. (Links that contain information about session status or other context-dependencies will fail if used at a later time or by a different user, thus giving the impression of an unreliable system)
  • "Access Control": All pages may be set for either public or private access, except the home page of each site, which is always public; access groups are created and controlled by the users through a web interface, and may contain both internal (i.e., University-affiliated) and external people; internal people are authenticated by the standard, University-supported method and external people maintain their own password through a mail-back mechanism, so that neither administrators nor website owners have responsibility for creating accounts for individuals, or for maintaining anyone's passwords.
  • "Graphic Design":Users must have at least a few reasonable choices for the overall graphics of their site, including an option that is compatible with the existing web identity for their local organizational unit. (Control and responsibility for localized graphics should reside with local staff)

Perhaps the best demonstration of the unique functionality offered by UM.SiteMaker is to consider the following list of sites that individuals have made with it, and then ask yourself: How would someone do this at my institution?


(Judges please note: The project history is contained in item 7, "Difficulties", where it fits more naturally into our narrative)

6. Success

After being used in successive pilot modes for several years, UM.SiteMaker was made available campus-wide in November, 2001, then upgraded to production status (24 x 7 server support) in August, 2002, and is considered to be fully operational. User support is available by phone, Email or walk-in during regular business hours, and training sessions are offered several times throughout each term. Since the original scope of the project was to include only Medical School faculty, the fact that it now serves all categories of users throughout the entire campus is an indication that it has far exceeded it's original goals. Moreover, the product has been licensed for use by our local school district (Ann Arbor Public Schools).

At the end of the pilot period, about one year ago, the system contained about 200 websites and was receiving about 600 visits per week. Currently there are about 700 active websites and 5,000 visits per week. Although there is no specific model on which to base projections for usage trends, we have estimated that activity may plateau at around 5,000 - 20,000 websites and 100,000 - 200,000 visits per week, in 3 to 5 years.

One of the most difficult aspects of designing UM.SiteMaker was to make things easy enough for the completely naïve user while still maintaining enough flexibility to produce an attractive website that functions well, and allows more advanced users to leverage their knowledge, as well. The following quotes support the conclusion that we have been successful in that regard:


"I'm not a Web wizard, so SiteMaker gave me two things: the tools to build a site -- easily -- and the flexibility that has allowed me practice building with html so I can learn more about the Web."

Bill Clayton, Editor, College of Engineering


"UM.SiteMaker provides an opportunity for researchers and project mangers to develop interactive sites. More importantly, most people don't need training to develop a site."

Teri Adams, Computer Support Manager, School of Nursing


"I'd like to thank you for the UM.SiteMaker services! It's a wonderful product that greatly simplified my worklife. A website is the ideal way to distribute information. But like most faculty, I have little time to tinker with my site. What I want is something that's simple to maintain, doesn't need extensive training, but is nevertheless functional and aesthetically pleasing. Well, my past attempts took much more time than I ever wanted to invest and were clumsy nevertheless. UM.SiteMaker changed that. Setting up the whole thing didn't take more than some 20 minutes and updating it takes little more than copying a file to another drive. Very convenient and efficient! Thanks!"

Norbert Schwarz, Professor, Psychology Dept.


"UM.SiteMaker is convenient and user-friendly. Even for those who are gifted when it comes to computer skills, it is accessible and easy to work with."

Sarah Goralewski, Student, College of Architecture and Urban Planning


"UM.SiteMaker provided an easy-to-use, accessible method for starting a Web page to disseminate clinical information to clinicians at the University of Michigan on geriatrics. I had never built a Web page. Without UM.SiteMaker we would likely have spent enormous amounts of time in development. As it was, we were up and running with just a few hours of input. UM.SiteMaker has about the right balance of pre-formatted and flexible input to allow us to do what we wanted, with very little prior experience."

Brent Williams, Associate Professor, Department of Internal Medicine


Finally, a factor that we expect to greatly increase demand for UM.SiteMaker is that the next version (3.0, to be released in January, 2003) will add the ability for website owners to include simple databases (Data Tables) in their websites. It is somewhat ironic that, even though every template-based web publishing system has a database at its core, none of them allow site owners to actually use it like a database. There are a handful of commercial systems that provide this functionality to some extent (e.g., QuickBase, eCriteria), but we know of no such capability at any university. Furthermore, the level of customization for layouts and default behaviors in UM.SiteMaker Data Tables will exceed that of any system that we know of.

Considering the cost and effort involved in web-enabling even a simple database, we expect this feature to attract an additional audience of users who are more experienced and who will understand and appreciate the efficiency of using UM.SiteMaker for modest database applications, where they might not have considered it for building a simpler website. We envision a variety of uses of Data Tables, including inventories of items or data in the research setting, address lists, image galleries, meeting registration and abstract submission forms, performance studio guestbooks, etc.

More broadly, since we believe that the capabilities of UM.SiteMaker are not available in any other system, and that it would benefit most other campuses, we have tried to create a licensing situation that will promote its use at other colleges and universities.


7. Difficulty (discussed in the context of the total project history)

UM.SiteMaker started in 1998 with a proposal written by Dr. Jonathan Maybaum, Professor of Pharmacology, who was at that time serving as Director of Academic Information Technology for the UM Medical Center. The goal was to provide Medical School faculty with a tool to help them create and maintain well-organized, professional-looking websites and simple web-enabled databases, without the need for extensive help from technical staff. With support by Interim Dean A. Lorris Betz and UM CIO Jose-Marie Griffiths, the project was funded for a three year period under the ITD (Information Technology Division) Partnership program. During 1998-99, Dr. Maybaum worked with ITD programmer Melody Alfather and colleague Richard Neubig (also a Professor in Pharmacology) to define the basic outlines of the system and to produce a first prototype. Because of the scope and complexity of the desired product, it was necessary to use an object-oriented development environment that was mature and scalable. After evaluating various choices, WebObjects was selected.

Ms. Alfather produced the first prototype of SiteMaker, using WebObjects, in the Fall of 1999. However, she left UM shortly after that time and we then encountered one of our first major hurdles, which was the lack of availability of internal programming staff. Eventually, we concluded that internal programmers were simply not available to carry the project forward. However, because UM had negotiated with Apple Computer a contract that allowed us to use their programmers on a contract basis while still retaining intellectual property rights to the resulting code, we had an opportunity to have the next phase of the project done there.. The work was picked up by Brian Fitzpatrick of Apple Enterprise Software (now Apple iServices), and version 1.0 of SiteMaker was made available to a limited number of pilot users in the Spring of 2000.

Although version 1.0 was designed for use within the Medical School, pilot users both within and outside of the Medical School found SiteMaker to be a very effective tool. It therefore seemed appropriate to explore the possibility of extending its scope across campus. This path was enabled by the establishment of a new organization within the UM CIO office called CARAT (Collaboratory for Advanced Research and Academic Technologies). Under the leadership of Profs. Victor Wong and Carl Berger, CARAT was formed to provide a home for initiatives that cross the boundaries between Schools, Colleges and other major units. Dr. Maybaum submitted a proposal to CARAT, to modify SiteMaker so that it could be used throughout the University, which was funded for a two-year period beginning in July 2000 (overlapping with the last year of the Medical School partnership phase). Development of version 2.0 was again contracted to Apple iServices and was completed in the Summer of 2001.

It was fortuitous that CARAT was formed at the same time that funding was required for continuing SiteMaker development, since it would have been difficult to locate another source that would support a project that did not fall neatly into any single academic or administrative unit. Even so, while development of the campus-wide version of SiteMaker was just beginning, it became clear that a long-term plan was needed to ensure the program's continuity, without counting on significant funding from university sources. We ultimately decided to pursue the idea of supporting continued development of SiteMaker through an arrangement with an existing commercial developer. Therefore, while version 2.0 was in progress, we began to seek such a developer and ultimately reached an agreement with Global Village Consulting (GVC; Vancouver, CA) in June 2001, by which exclusive licensing rights were granted in exchange for royalties and other considerations. From this point forward, the system was called UM.SiteMaker at the University of Michigan, and GVC.SiteMaker when used elsewhere, under the licensing agreement.

Chuck Hill (GVC) took over as the lead programmer and completed version 2.1 in November, 2001. This version was the first one that was ready for campus-wide use. Version 2.5 was completed and deployed in August 2002. This version included a substantial revision of several underlying parts of the application and also added, for the first time, an interface to allow distributed control over authoring and testing of graphical templates (styles) and integration of Kerberos authentication into UM.SiteMaker.

!