I’ve just finished a little project for a county government. The goal was to consolidate many distinct departmental websites into one site, on one platform (Drupal), while creating a new user-centered design to improve accessibility and still providing a departmental view of the content. I came into the project for implementation; others had already done the design, which provided a completely revamped, visitor-friendly navigation, and that design had been approved by the client stakeholders. My role was to help figure out how to build it, since I’ve had some experience with Drupal.
The situation, of course, will be PAINFULLY familiar to many…
Content owners think in “departments”
Each department has its own services and programs, and it has its own perspective on how things should be organized. As the reality of this new user-centered design sank in, the content owners started to ask, “Where’s OUR department site? Where are all OUR services and programs?”
I think that many redesign projects fail when in a well-intentioned response to these questions, the champion for user-centered design says, “We don’t have ‘departments’ anymore…” In one phrase, the whole implementation is plunged into jeopardy.
Beyond that, there is a design principle that says a piece of content should have only “one location” in the site architecture, and thus are drawn the rigid lines for the irreconcilable conflict: Either you have a user-centered design or an organization-centered design.
I think that’s a false dichotomy. We are no longer limited by having to put content files into directories on a web server. Fortunately, this was Drupal, which for all its perils as a “flexible” platform (i.e. “mind-bogglingly complex”), it can accommodate many simultaneous approaches to most challenges. We really can provide a solution to please everyone.
NB: It should go without saying that there will be as many solutions to this puzzle as there are drupalistas, but here is the solution I proposed and delivered.
Goals for the solution
I think it’s important to lay out my goals for making this multi-architecture work for all the users:
- Make URL paths, breadcrumbs, and menu navigation absolutely consistent. It seems a simple thing on the surface, but it is not so easy to do.
- Provide complete visitor and departmental views of the content, without disrupting the user experience for either visitor or content authors. In other words, I wanted for content authors to be able to put content exactly where they thought it should go, yet have it show up (also) where visitors expected to find it. I reasoned that if visitors knew the departmental structures, they would go there first.
- Minimize “development” by relying on Panels and Views to provide dynamic templates. If you know Drupal, you probably know that the Views and Panels modules, both by @merlinofchaos, provide an alternative to the “one site, one template” native approach in Drupal.
Here’s a chart that illustrates the parallel architectures. The green navigation illustrates the visitor-centric navigation, while the cyan navigation shows the “department” door into the organizational view of the content.
Visitor paths based on taxonomy
Drupal has a robust taxonomy engine, which has been augmented by many community-contributed modules to extend taxonomy to other aspects of site structure, including menus, paths, and breadcrumbs. I chose to implement the user-centric paths into the content by vocabularies in the taxonomy—one vocabulary for each path.
At each step in the path is a Panels page that can be configured to show the most popular and newest content “bubbled up” from deeper in the vocabulary, as well as a view of the terms that make up the rest of the path. At any point, the visitor can step off the path to see the content directly, or go deeper.
Organization paths based on content types
I also took advantage of the powerful Drupal content typing engine to provide a completely parallel set of relationships, beginning with the “Department” type, then adding other content types, which then could “belong” to the department:
As one follows the organizational path, just as with the taxonomy-based paths, Panels pages pull content dynamically to create a complete departmental subsite that will be clearly recognizable to the departmental staff—and any visitors who know that they need something from this content.
References make it work
Whenever a piece of content is created, in addition to its substance, the author associates it with a Department through the entity reference, then tags it with the terms of the visitor-centric vocabularies, so that it can appear anywhere it needs to. In addition, however, there is an additional, structured “topic” tag vocabulary that will ensure that the site search can pull appropriate results, regardless of its departmental or visitor path tags.
In conclusion, Drupal’s flexibility makes it possible to please everyone. The visitors get a site designed to address their particular interests and tasks, while the organization gets the administrative arrangement that it recognizes. Although it’s a fairly straightforward approach to describe, the implementation was actually very tricky, but that is the nature of Drupal. It is really a developer’s tool, built by developers for other developers. That is to take nothing away from Drupal’s power as a platform, but it is a fact that non-developer site builders have to face.