Case Study, The New Georgia Encyclopedia
The New Georgia Encyclopedia (NGE) presented a formidable challenge: to encompass the entire history, geography, and culture of the state. In doing so, the client wanted to draw upon the unique opportunities of multimedia and the Web while still maintaining the authority and completeness of the traditional encyclopedia.
NGE called upon my company, Merrill-Hall to plan and develop the application in all of it's aspects, including information architecture, graphic design, and XML Schema and software development. We started by helping NGE to identify the multitude of intended audiences for the publicly facing part of the application: in-state, out-of-state; young and old; casual and educationally minded. We aimed for the public website to simultaneously serve each of these constituencies in the best manner possible. The website's graphical interface was designed to be both welcoming and authoritative; fun enough to attract web surfers, and yet serious enough to carry the heavy weight of its mission to the state and her people.
We also helped NGE to identify internal audiences, including not only the Encyclopedia editors and others who would be publishing content via the behind the scenes content management system application we would be developing, but also stakeholders who's interests need to be taken into account when making critical decisions about public facing aspects of the website.
This information architecture case study traces only a single aspect of the planning, design and implementation of the website application: the creation of a particular top-level navigation item, including the reasons for the addition of the navigation item, it's method of implementation, and the information architecture documents that supported the application development process. The navigation item in question is called "Destinations" and, in the final design, resides on a horizontal navigational menu near the top of the website screen.
Determining the Need, Framing the Issue, and Defining the Approach
Discussions with the client team, including project backers and partners, revealed specific challenges for the development effort. All parties involved agreed it was crucial the Encyclopedia maintain a voice of scholarly authority, and that the primary method of informational organization would be a traditional subject matter hierarchy. During group exercises on audience identification, however, the participants came to recognize that the subject matter hierarchy did not necessarily satisfy the needs of all identified audiences and stakeholders. One identified audience group was tourists, both in-state and out. A corollary interest group existed among the stakeholders; the Encyclopedia received some support funds from the State, which has an obvious interest in promoting tourism. The question then became how to address this issue in the context of the constraints faced by the client.
It was clear that the client could not spare resources to develop a series of unique articles or other content specifically directed at tourists in Georgia, so another solution had to be found. And as it turned out upon further analysis, the problem was not unique to this particular situation, so the solution had to address more than one situation in which a desired outcome was not directly supported by the subject matter hierarchy organization.
Once we had the problem defined and the constraints established, we had to come up with a solution. We knew that a search facility alone would not achieve the intended goal because it would require too much work on the part of our visitors to achieve a goal that should be readily available. Additionally, search would not provide the same kinds of insight into Georgia as a travel destination that an editorial approach, even a limited one, could bring to bear.
Our solution was to create a functionality that would permit the Editors to aggregate otherwise unconnected content into new groupings associated with particular places or types of places ("Locations" in our nomenclature) that tourists might find interesting. The Locations need not tied together strictly by geographic designation (e.g. Atlanta), but could also be tied together conceptually (e.g. Sherman's March). This aggregated content functioned somewhat like an article, but required much less editorial work than creating a completely new article. The editors need only author a short paragraph that functioned as the glue holding the articles together, and then the articles carried the wait of the information.
Because we were doing the development of both the public presentation side of the application ("Public Face") as well as the content management system ("Publishing Tool"), this solution involved the design of two related but very different systems.
Destinations: The Public Face
Of the two systems, the Public Face aspect of the issue was definitely easier to address than the Publishing Tool. Persona exercises helped us to understand that visitors were looking for two things, ideas on places to go and information about those places that would provide context for what the visitors would see. This meant that it would be important to make it clear to visitors there was more than one Location featured in the Destinations section, and it would also be important to make it easy for visitors to understand what was interesting about each Location. Once we had the idea, the execution was relatively straightforward and little changed from the initial high-level conception to the final detailed design through to execution.
Although the high-level flowchart and wireframe communicated enough information about the proposed solution so that NGE could understand and critique the approach and so that the programming team could evaluate the technical implications, there were still many details to be worked out. As part of the detailed design process, we needed to determine whether the Destinations main screen would be unique as a gateway to the other Locations, or whether all Location screens would contain within them links to other Locations as well as to the articles relevant to the particular Location featured on that screen. Ultimately, we decided for reasons of resource allocation and because the approach made sense to both NGE and us that the Destinations main screen would simply be a screen that showed a featured Location in its entirety, but that this screen would also provide links directly to other locations as well as to an archive of all Locations. In this way, we could use the same screen layout and programming for all Location screens within the Destination hierarchy, reducing the programming and design load, but still enable our visitors to accomplish their goals of locating interesting information about things to do and see in Georgia.
Location Screen Wireframe
We also had to address other challenges presented by the aggregated content approach, including questions about how to display articles that were linked to a Locationboth with regard to how those article references would appear on the Location screen itself and in what context those articles would be displayed if the user elected to view themas well as what kinds of content we would permit to be aggregated for purposes of creating a Location. For the former, NGE ultimately decided that articles should be displayed not within a special "Location" screen wrapper, but rather should be showed within their "home" category in the subject matter hierarchy. (Within the application, an article can be assigned to any number of categories within the subject matter hiearchy. All articles within the hierarchy have a "home" category, which is the default category used to place the article within the hierarchy when a visitor comes to that article via any method other than the subject matter hierarchy, e.g. search, location, etc.) For the latter, the initial decision was to exclude all content except for articles from the "Location" aggregation. The idea being that associated media would be found within the referenced articles. After the initial internal release, we added the ability to include Gallery Exhibits and Feature Stories within the aggregated content. It may be that, as time passes and feedback is accumulated, we will eventually move to a system where individual pieces of media content (video, audio, still images, maps, etc.) are capable of being tied to Locations, but for the time being this was determined to be too much of an editorial burden on NGE.
Now that we knew what we needed to build for the Public Face, we had to create the tool by which NGE would publish this content.
Destinations: The Publishing Tool
Location Publishing Tool Flowchart
When we began planning for the Publishing Tool, we decided to create it as a browser-based application in order to provide the cross-platform compatibility NGE needed. Our first instantiation of the Publishing Tool ran the application as a series of Java applets called from the browser interface. This approach led to a number of awkward interface choices and performance problems and was ultimately abandoned as impracticable and too limited. As a result of these problems, we ported the Publishing Tool to a Java/Swing application and used Java Webstart to load the application via the Internet. Because our internal users were most familiar with Windows-based interfaces, we chose to stay with the Windows idiom when designing the interface. Despite its Windows-styling, however, the application is capable of running on any platform that can run Java and has access to the Internet.
Location Data Entry Screen
Discussions with the internal users most familiar with the editing process helped us to determine the types of information it would be appropriate to aggregate for any particular Location and to specify useful data element groupings so that related information could be kept together in the interface for data entry and editing purposes. As part of the design process, and based upon these same discussions with the internal users, we extended our XML Schema to encompass a set of elements that defines information that can be part of a particular Location.
In the current version of the application, and changes are being made all of the time, we have used a "tabbed" (or "card stack") style interface for creation and editing of Locations. We used this approach because of its familiarity for Windows users and because there was a great deal of data that had to be dealt with in a relatively small pixel space. Each tab in the interface for Location editing corresponds to a set of data elements that can be added or edited, and the groupings are those which our client users identified as making most sense from an editorial perspective.
As you can see from the preceding, which represents only one small information architecture aspect of the overall project life, the development of the NGE was an extremely complex undertaking. The application as it currently exists represents some 5000+ hours of development time, and that number is growing all of the time as modifications are made based upon real-world usage. During the initial planning phases, including both high-level solution design and detailed implementation design, we generated thousands of pages of documentation and hundreds of computer files, including information architecture documents, Schema definitions, XSL and HTML prototypes, database structure definitions, graphic design comps, and other associated output reviewed by us and vetted by our client, the subject matter experts.
Planning for the project began in late 1999, and the first implementation of the application was available for NGE evaluation and preliminary use in early 2001. Interestingly, because planning was so comprehensive, it took only three months to create the first working version of the application. At this point, NGE expects to open in limited beta in late 2002, at which point they will have created and published enough content to justify release of the application to the public.