The final day of DrupalCon Chicago is underway with Jared Spool's keynote about intuitive design (which he says is invisible, like air conditioning). One key session is on the radar today before departing for the airport: Workbench: Managing Content Management. Workbench is a new set of tools aimed at content management, and I am looking to compare the tools-based approach with the guidance provided in yesterday's administration session (focus on the people not the tools). Spool's presentation this morning emphasized similar points from the people-based approach, such as observing users in the wild on field visits (he called it a Jane Goodall experience: "Users in the Mist").
In the keynote, Spool provided an interesting review of the evolution of products from technology to features to experience. The shift from features to experience comes at the point in a release cycle when you (or your competitor) realizes that within a robust feature set, only a few are actually used. The product should be scaled back to narrow focus to what is in use.
Workbench: Managing Content Management
by Robin Barre, Colleen Carroll and Ken Rickard
Suite of modules for Drupal 7, released last week.
Use case for the module was based upon museums, universities and other institutional non-profits.
Common scenarios:
- I see some content needs cleanup, I can work on that offline, right? (issue is there is no in-between with published/unpublished by default in Drupal). Workbench allows a non-published draft.
- Need to lock users out of sections of the site. Drupal default is based on content type, not specific instances of content (1 page in the tree).
- Can't I see just the content I maintain? Default content list is overwhelming for editors.
Hierarchical Access: identify editorial groups for your site and assign editors and/or roles to those groups.
Map Editorial Groups to content: layer your site map over editorial groups
Walked through example with 2 roles: Contributor and Editor.
Login starts with a nice dashboard under a "My Content" tab. Other tabs for Create Content, File List, My Sections and My Drafts.
File list shows uploaded files with a column to identify nodes where it is attached
Frontend tools for the site. Uses help text to overcommunicate permissions and access based on role. Tells you what section you are in and whether you can edit. Extra tabs beyond "View/Edit" to View Published, View draft, Edit draft and Moderate. Potential new feature could be to use diff module to show what's changed in revisions.
On node/edit has a Workbench access menu that can control who has access to edit.
Moderation options exposed at top of screen after save within the help text, nice feature to streamline moderation tasks - e.g. after save use dropdown to set it to "Needs Review"
Switching to user with more permissions (Editor), adds an extra tab to dashboard for "Needs Review" - for access to list of drafts to review/approve.
Moderate tab uses color coding and information for overview of revisions for a piece of content
"Couldn't you do all this in Drupal 6?" Yes, but 8 or 9 modules with varying interface concepts would have been needed, so the training level would have been too complex. Instead, wanted to identify common use cases and pain points, and make sure to architect modules in a way that turning each on or off is a business decision. Have common training materials ready to share.
Isolating parts of the site to target specific users to be able to control.
Tried to solve this problem in Drupal 6 with menu node edit module (not optimal) - declare any part of the menu system as a section. But the user interface was crude.
Why not use: Organic Groups, Taxonomy Access, Taxonomy Access Light, Content Access, Module X? Hierarchical access was the blocker.
Installing the workbench accessby default it installs a taxonomy and sets up a vocabulary based on the site. Can edit from there.
Any tool to be used for hierarchical management (example - menu instead of taxonomy) could be plugged into workbench access API if desired (you aren't locked into the module engineer's default decisions)
Workbench Access has a suite of administrative screens, e.g. viewing and setting active sections, section view by role, section view by users.
Access control: controls permissions (create, edit, delete, moderate), does not filter listings,
Access integrates with: Workbench moderation, views, menu, taxonomy, Other modules via API. "We know that if you turn them off, things will not break"
Roadmap: native form element handling, multiple section assignment, access rules per content type, additional module support.
Workbench Moderation: tabs to define states, transitions and check permissions,
Workbench roadmap: moderation rules by content type, edit default states (Draft and Published), scheduled state transitions, non-linear approval workflow.
Where is this headed?
- Is there a demo site? No
- Installation profile - panel thinks this is more useful than a demo.
- Scheduled content publication
- Workflow notifications - help to answer the question if you have anything to review without logging into Drupal
- Files -> Asset Management - dedicated to integration with media module
- Check the Issue Queue
Released the module to drupal.org and transitioned from own ticketing system to d.o issue queue. Acknowledged the company can't maintain this alone. Contributions welcome.
Q: what about the workflow module? A: D7 release cycle by Workflow module's maintainer was not in line with the client obligations that helped drive this project.
Summary: Lots of potential here for content administration in Drupal 7. This project seems founded in the usability sensibilities that have been a frequent topic at this conference: listen to your clients and the content editors before building. But, unlike the other sessions this one had more than talk - they showed how they had listened to their clients and have delivered a set of tools aimed to solve the real-worl problems, and have shared them with the community.