by Jeff Eaton on March 23, 2011 // Short URL

Baby Got Backend

Spinning up an awesome experience for your site's content editors

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.

Custom tools for your team

Most of the modules mentioned above focus on streamlining existing edit forms inside of Drupal, but on large sites, several other problems arise. Often, different teams or individuals have different pools of content they're responsible for; simply finding what you need to work on can be a chore with Drupal's one-size-fits-all content administration screen. In addition, many tasks like publishing lists of approved content are painfully cumbersome with the default admin screens. Other tasks, like editing metadata for multiple articles simultaneously, are impossible.

Fortunately, an old standby can come to the rescue. Using the Views module, it's easy to to create customized content listings, stick them onto a custom page in the administration section, and restrict access to users with specific roles. Using Views' Exposed Filters, editors and admins can also drill down on these lists to find content that matches just the criteria they care about.

With a tool like Panels, you can combine multiple Views (as well as other widgets) into highly customized dashboards for your content team, even building separate dashboards with different features for users with different responsibilities. Here on Lullabot.com, we have a simple dashboard with just two views. One lists the latest five articles published on the site, along with statistics like how many page views and comments they've received. The other view lists unpublished articles, sorted by the date they're slated for publication. That view also lists who's responsible for finishing each article, and any revision notes that have been made during the editing process.

We've used the Login Destination module to ensure that we're taken to the dashboard as soon as we log in. On one screen, we can see what's live, what's coming up, and what steps need to be taken to finish any articles that are in the queue. If you're looking for a solution that's a bit lighter than Panels, or you need to give individual users the ability to customize their own dashboards, check out HomeBox module. It's used on Drupal.org itself, and allows users to add any blocks to their own dashboards with a drag-and-drop interface.

Finally, there's the venerable Views Bulk Operations module. It allows you to turn any view into an administration tool that actually makes changes to content en masse. The available actions included publishing and deleting content, changing field values, changing authors, and more: other modules can expose additional actions as well. The available actions can be changed for each View, and dangerous actions can be hidden from users with insufficient permissions. It's an amazing Swiss Army Knife that can be used to build a wide variety of flexible, task-focused content tools.

A world of possibilities...

Amazingly enough, we've only scratched the surface of what can be done to streamline the content management experience. In future articles I'd like to look at how modules like Flag and Prepopulate can be used to smooth out complicated workflows; the use of Features to capture these administrative features and share them between sites; and upcoming projects like Workbench that capture some of the most common solutions in a single package.

As Karen and I mentioned in our DrupalCon session, the real challenge is figuring out what your site's content editors want and need. These modules can eliminate most of the coding, but nothing can replace talking to the people who'll be using the site every day.

What kinds of solutions have you found work best for the sites you've built?

Jeff Eaton

Senior Digital Strategist

Want Jeff Eaton to speak at your event? Contact us with the details and we’ll be in touch soon.

Comments

Jason Markantes

Great overview

Thanks for a nice overview. I agree, we can do a much better job targetting the content editors, for both small sites (simple and obvious tools like image management for a blogger) to large workflows (with dozens of editors in a complex workflow). A lot of effort in some large companies goes into custom programming for their specific workflow, and most of those ideas won't make it back into the public domain.

Wish I was able to make your session! I did enjoy the module building pre-conference training though. Thanks again,
Jason

Reply

Erik Newby

Nice followup

I really appreciated your session at DC Chicago. This topic needs to be on more designers' and developers' radars. Thanks for posting this follow up to the session. Some of these modules are new to me, and I can't WAIT to make my editors' lives easier! Of course, not forgetting that the first step is actually communication.

Reply

Alex Weber

Nice tips

Great article with some nice tips on an often overlooked area of Drupal site development and theming. Thanks!

Reply

dddave

I really appreciate this

I really appreciate this follow-up and I am looking forward to your next installment. To be honest I like this article more than the vid from your session (lack of examples and not so useful text-slides).
Anyways this is an important topic which rarely gets covered. Thanks!

Reply

yoroy

Needs case studies

The thing that I took away from your session in Chicago was that Drupal was potentially best at creating customized publishing workflows, something other (commercial) systems would not be able to do.

I'd love to see real life examples of that.

Especially as we found that Drupal out of the box totally falls flat on the face for this (jury still out on this for how D7 improved here).

I understand this article as primarily an overview of the tools to do this. It would be great to hear from people how they used them to put together a specific publishing workflow indeed.

Reply

Kevin Webb (wfx)

Nice!

This article rocked! I've found some of these modules here and there but you offered a lot of new perspective and new tools I didn't know about.

I like Lullabot's simple 2 view dashboard, I'll try that on our site. There are so many things to be done to improve the content editing experience but this is a great place to start. Thanks so much for this article!

Reply

patcon

Masquerade module

Not done reading yet, but just wanted to say that Masquerade module is 100% perfect for placing its block in the Admin menu "dashboard". Quick switching between dummy accounts for each role when YOU'RE setting up, and a simple way for end-user admins to jump into user accounts for subordinate roles, which does wonders for their troubleshooting abilities with THEIR users :)

Reply

philipz

Two other modules that fit here

Great article! I'm using almost all of these and two more modules:

Node form cols is a great way to set node editing forms more like Wordpress editing forms and hide unnecessary fieldsets when needed. It goes nicely with Node Form Settings but I found it not looking good with Vertical Tabs. So it's kind of another choice if you want to shorten the long node form editing pages.

The other one is Total Control Admin Dashboard which sets the dashboard with Panels and administration Views for all content types.

Reply

Pinolo

Simple and plain

These tips and the underlying reasoning match my current routine for any Drupal site. And I feel so sorry when I put my hands on a site where other Drupal folks didn't give a damn about a friendly backend.
Now, back to taming that ugly OG way of exposing (or not) admin stuff :)

Reply

dddave

Examples please

I second yoroy's comment. Some examples would be a great addition.

btw: I've already switched my default admin theme to Rubik.

Reply

Stephen Barker

Node Form Columns

Don't forget about Node Form Columns ( http://drupal.org/project/nodeformcols ). I like this module since it is useful for determining which column certain fields are displayed in. It also provides "collapse" & "hide" options.

It allows me to place the main "meat" of the node that the user needs to address in the main column on the left and have more ancillary or admin-type fields on the right. For instance, you can have all the content entry on the left, and then taxonomy assignment on the right. And by setting certain fieldsets as collapsed or open, you can draw attention to those admin type fields that the user may interact with more often. Setting them closed or hidden keeps the user from thinking about these and creating clutter when more times than not they don't need to worry about these settings.

Reply

Jeff Walpole

Great subject

Not every customer/user appreciates these types of details, but the ones that do, really do. Thank you for the overview of the best approaches for ensuring the back-end gets as much attention as the site we see.

Reply

Alex Andrascu

Root Candy

You forgot to mention RootCandy theme. I always prefer it instead of Rubik.

Reply

Ryan Hanau

Node Form Column

Again a big vote for Node Form Column module. I prefer it over the Node Form module. It has more features such the ability to place fieldsets in columns and order their position on the page. Outside of hiding buttons and setting the textfield height, not sure that Node Form module offers anything Node Form Column does.

Reply

William Warren

Backend

Thank you so much for this post, the suggestion of rubik together with the admin module and vertical tabs has sorted alot of trouble we had with our back ends. Its not perfect yet but its a major step in the right direction.

Reply

Alltooeasy

Lullabot! Thanks

Lullabot,

Thanks so much for all the great updates and tutorials!

We launched our new website. www.alltooeasy.co.uk
We'd love some feedback from the pro's themselves.

We're also having a few issues with the D7 contact form.
very weird. Any ideas? Has anyone there come across anything similar.

Cheers

John

Reply