Drupal's flexible theming system has made lots of amazing site designs possible, from the respectably contemporary White House web site to Pete Droge's Drupal-driven Flash masterpiece. What most Drupal sites don't show off, however, is what content editors work with every day: the notoriously unglamorous content creation, editing, and management screens. Tools for those users are often neglected, even though their success is critical for any content-driven site.
At this year's DrupalCon in Chicago (and last year's Web Content Conference), Karen McGrane and I co-presented on content strategy and the importance of the backend experience for successful sites. In both presentations, we focused on techniques for discovering what pain points are most acute for a site's editors, and common patterns for solving those problems. The response we've received at both conferences has been unanimous: "Once we know what kind of tools are needed, how can we build them in Drupal?"
The great news is that there are quite a few flexible tools to streamline your Drupal site's day-to-day content management workflow without writing any custom code. In this article we'll explore a couple of the easy wins, highlight modules that can be used to build out more complex tools, and give you some useful next steps for taming the backend beast.
Making the the admin section stand out
Back in the dark ages, Drupal had a dedicated administration section. It used its own layout, locked out non-administrators, and (like most web apps) it made the split between visitor-facing content and admin-facing management tools very explicit. In 2004, Drupal 4.3 abandoned that approach in favor of "in place" administration. Settings forms, content editing tools, and so on all used the same visual styling as the front end, and user permissions controlled who had access to actions like editing and deleting content.
The downside, of course, is that separating the backend is sometimes a good thing. Highly customized sites often have themes that are badly suited for heavy duty management screens, and the visual cue that you're "behind the scenes" is useful for many site maintainers. Since Drupal 5, it's been possible to manually choose a separate theme for administration pages, but Drupal hasn't taken advantage of it out of the box.
Drupal 7, released this January, brings back dedicated administration tools in a big way. It ships with a new admin theme called "Seven" that sports a clean, neutral appearance and actually makes Drupal tabs and subtabs (the achilles heel of most themes) look nice. If you're using Drupal 6, the Seven theme is available as a separate download. A number of other dedicated administration themes are also available if Seven isn't to your liking: I prefer Rubik, a lesser-known theme that's been gaining popularity over the past year. I like Rubik's clean appearance, its slick handling of collapsed fieldsets, and the fact that it hides Drupal's often-verbose field descriptions until the appropriate one has focus.
If you need more control over where the administration theme is used, check out the Administration Theme module for Drupal 5, 6, and 7. It lets you specify specific paths that should use the admin theme even if they're located in other sections of the site. The similar Administrative Pages module also lets you change what paths should appear in Drupal 7's "Overlay" popup window.
Navigation for editors and administrators
Most administration themes hide things like Primary Links, sidebars, and so on to make room for edit forms and content lists. That means you'll need to use another tool to handle navigation while you're in the admin area. The Admin Menu module has long been a favorite: it puts a tidy dropdown menu at the top of every page, giving administrators quick access to the full navigation tree, including content creation. Using Drupal's default Menu module, you can also rearrange the options.
Drupal 7 includes a customizable administration toolbar as a compliment to the Seven theme: it hovers at the top of the page when browsing the site's normal content, and allows quick access to to the top-level administration links. A similar module, Toolbar, is available for Drupal 6. Although it isn't a direct port of Drupal 7's toolbar, it offers a similar look and feel.
My personal favorite for both versions of Drupal is the Admin module. It's a bit bulkier than Admin Menu, but its navigation panel is tucked behind an inconspicuous tab when it's not in use. Admin also allows admins to stick entire blocks into the flyout panel: the result is a customizable "dashboard" that's accessible on any page. While there are a handful of other modules that provide persistent navigation palettes and menus, Admin, Admin Menu, and Toolbar are all mature and well-maintained; pick the one you like and run with it.
Taming the node form: The easy stuff
With a fresh new look for the administration section and a consistent navigation system in place, it's time to look at Drupal's node form. It packs in a lot of functionality, but this workhorse can be overwhelming once features like revision control, extra input formats, and additional CCK fields have been added to the mix.
Your first line of defense is the Vertical Tabs module. This quick-and-easy fix turns the node form's multitude of collapsible fieldsets into a single "preferences panel" with a tab for each group of fields. It's a simple fix, but it can cut down quite a bit of clutter quickly. For those using Drupal 7, it's already built in.
Next up is the Node Form Settings module: it's a fantastic tool that smooths out a number of the node form's common annoyances. On a per-content-type basis, it can hide the "Revision Log" field, hide the "Input format instructions" that appear beneath every textarea, control the size of the node's Body field textarea, hide the Preview button, change the text of the Submit button, hide the confusing "Split summary" link that hovers above every body field, and more. It can also make many of the same tweaks to the comment form, and hide the Input Format fieldset beneath CCK-generated text fields. None of the changes are impressive alone, but together they eliminate a lot of visual clutter. Although it's not yet available for Drupal 7, a port is planned soon.
Taming the node form: Advanced techniques
Once those two modules have taken care of the low hanging fruit, a trickier problem remains: content types with lots of custom fields. Although CCK, Drupal's FieldAPI, and related modules give us a lot of flexibility, they add to the problem of widget overload when it comes time for a writer or editor to pound out new content. Three modules, Field Group, Auto Node Titles and Conditional Fields, allow us to hide fields that aren't needed, populating them automatically or revealing them when appropriate.
The Field Group module allows you to cluster related fields together for each node type, even wrapping them in a collapsible fieldset that tucks them out of the way unless they're needed. Although this seems like a simple thing, properly naming and grouping input fields is one of the easiest ways to help content editors make sense of potentially confusing forms. In Drupal 7, the module also allows you to group fields differently depending on whether you're viewing or editing a node and can take advantage of the Vertical Tabs display style mentioned earlier. Field Group is included with the core CCK downloaded in Drupal 6, but is maintained as a separate project for Drupal 7.
Auto Node Titles is straightforward: for each content type, you can hide the built-in Title field on the edit form and specify a pattern-based default that Drupal should use to populate it. This can be useful when you're using several small CCK fields for values like First Name and Last Name, or Event Date and Event Location, but want the visible title of the node to be a combination of several fields. It eliminates clutter and makes titles more consistent. Conditional Fields, meanwhile, is best used when you have large groups of CCK fields that only make sense in the presence of other selections. For example, the Street Address field on an event doesn't make sense if it's taking place online. Using Conditional Fields, you could create a Meeting Type field with several options: Conference Call, IRC Chat, or Physical Meeting. Phone Number, URL, and Street Address fields could be hidden or revealed based on the user's Meeting Type selection. This trick only makes sense when you have relatively complex content types, but it can help reduce confusion for new users quite a bit by hiding options that they don't need to worry about. Although Conditional Fields isn't yet available for Drupal 7, a similar module called Field Conditional State is currently under development. Keep an eye out for it as it evolves.