One of the things I’ve been doing in lieu of blogging over the past year is working at the University of Arizona College of Medicine. I was part of an excellent team (very high “awesome at their job” average, even with me factored in) which was given the job of designing a new website for the college. To my delight, we were also given the flexibility and the resources to do this well.

Poster post

This post is adapted from a poster I presented at a recent professional conference at the University of Arizona. It presents the structure of the current (new) website at medicine.arizona.edu as an example of how to handle web content and information architecture semantically using a highly modular, database-driven web platform like Drupal 7.

Disclaimer: This post is my opinion, and may not represent the opinion of the University of Arizona or the UA College of Medicine, which are quite capable of thinking for themselves.

Goals

  1. Replace an aging website for the College of Medicine – Tucson.
  2. Build an ecosystem that allows multiple web applications to share a common set of data about people, events and organizations.
  3. Establish oversight over a sprawling web presence by centralizing key features and improving workflows.

Resources

  • Smart, dedicated team: 1 designer, 2 developers, 2 persons of the network infrastructure persuasion. Plus me.
  • Strong institutional support: Leadership broadcast the importance of the project. This meant we found willing partners internally and in partner organizations who had skills, data, and systems we coveted.

A semantic information architecture

Bottom layer: Document structure and content (XML). Middle layer: metadata about the content (RDF, taxonomies). Top layer: Rules that process content and metadata.The semantic Web is a set of technologies and standards that allow computers to interpret the structure, nature and meaning—the semantics—of data. This makes it possible to build complex web applications by assigning different sets of rules to the same underlying data.

In this case, we used extensive hierarchical taxonomies (lists of related “tags”) to structure content types, then created multiple ways for users to view that content.

Capitalizing on consistency with queries

Drupal is a database application. What programs like Microsoft Access call “queries”—dynamic displays generated by looking for patterns in a core data set—Drupal calls “views.”

Some of the many benefits of using views extensively:

Edit something once, and it will update anywhere that information is shown. 

Example: The date of an event is used on the main calendar, the event page, and an “upcoming events” box.

Database feeds 1) a calendar page 2) an event page and 3) an upcoming events list

Searchable directories of events, personnel, policies and other information.

Example: Find events by type of event and date range; search for faculty members by last name.

A single event in the calendar list view for our Event content typeTwo entries in our directory view for the Person content type

Use one content type as a data source for another.

Example: When adding information about a recent grant award, select an employee from our personnel directory as the recipient to automatically populate several fields (i.e. department,  titles).

How the Person content type feeds the Research Grant Content type and its slideshow view

Lessons learned

Everything is a tradeoff

Using the same taxonomies for multiple content types has many benefits. It also lengthens the learning curve for new users, who must navigate long lists of possible tags (not all of which are relevant to a given task).

Reach out

Project request forms were meant to save us time, but we never got good information this way. Having regular conversations with other offices worked better—and earned goodwill that paperwork never can.

Nerf everything, at least at first

We give new content editors limited access to the site. Restrictions are eliminated over time, as a workflow develops. Individual skill sets play into this, as do the cultures and needs of individual units. The insight we gain from working closely with others informs ongoing development of the site.

Start from scratch

Our legacy site had no significant advantages in technology, content or workflow. This was good. With no need to support or upgrade existing functions, we were able to design new systems from the ground up.

 Talk and listen

Presenting frequent project updates helped the team maintain a fresh perspective. Leadership, staff, students and faculty all had different needs and expectations. Their ideas shaped the final site in many ways.

Set project boundaries

This was a multi-phase project. Putting many potential project components on hold allowed our relatively small team to execute mission-critical work quickly and to a high level of quality. Medical professionals were generally open to this idea of “technical triage.”

Technology

Drupal icon (looks like a drop of water with a face)We build this city on Drupal 7. A few of the key modules we used are below. Thanks to the outstanding Drupal development and support community, without whom this site could not have been created.