Author: Elaine

At work we’re in the process of converting from our current CMS (proprietary system which I will not name) to Drupal. One of my big goals is making a really great experience for our several dozen (maybe 100+) editor-authors. I’ve been eagerly following work by Eileen Webb (her UX Burlington keynote is amazing) and Johanna Bates (forex, this great piece on authoring homepages) on the topic, and particularly on implementing with Drupal.

Yesterday we did usability testing with three of our editors. We got a nice mix, both in their overall tech-savviness and in which parts of the current system they use regularly. (We have two separate setups, one for the “old template” and one for the “new template”.) Justin was the person in the room with them — because I’m waaaaaay to close to it — and one of our student workers, another site editor, Susan, and I were observing. It was a fairly short test because of time constraints, only about a half an hour. We picked the most common tasks based in part on our experience and in part on a survey we did back in the spring.

• Explore the dashboard (Workbench, in our case) and look at the pages in the fake site they’d been assigned.
• Update some text based on a Word document. (Advanced: add bullet point and correct the spelling.) The text was in our “Primary Content” field.
• Add some links to some existing text; some of the linked content was in Drupal, some was not. The text was in our “Secondary Content” field.
• Upload an image and style it to match the main design.

The final task was going to be uploading and linking to a PDF, but there’s still too much wonkiness with that and Media CKEditor. But we did ask if there was anything else that they would do normally that we hadn’t asked them to do, and that did come up twice, so the follow-up to that was to ask them to explore how they might do that.

Here’s what we discovered really needed work:

• If you’re using the CAS module for authentication, logging out via the Admin menu doesn’t actually log out of CAS! After the first test, we discovered we had to close Firefox entirely and reopen.
• Nobody sees vertical tabs. I know people are really into them in Drupal editing screens, but for those secondary content links, it was way too hidden for the first two users. I switched it to horizontal tabs before the third user came in, and wow was that better. Our student worker noted that it was a much better match for how people’s eyes move across the screen. I’m inclined to agree.
• Styling terminology needs to be pretty verbose. A style labeled “Image” in the CKEditor Styles drop-down was a bit  vague.
• For our uses, alt text really needs to be required, and one of our testers skipped that but entered the title text, which is kind of pointless.

Other than that, it was really successful! They got the hang of the basics right away and expressed a lot of happiness about how “clean” and “simple” everything looked.

(Also: people who deal with lots of documents really want to be able to upload multiple documents. They can’t in our current system, but one of our testers uploads quite a bit of Excel, and other quite a bit of both PDF and Excel. They both found their way to the (broken, because libraries) multiple uploading functionality, but couldn’t use it. I’ll definitely be testing that in more detail.)

And the stuff that needed work: it’s all done already.

• The simplest way to handle the CAS logout issue is to set a Rule: when a user logs out, redirect them through /caslogout. I feel like this needs to be added to the CAS module documentation.
• Horizontal tabs FTW.
• Justin changed “Image” to “Image Right-Aligned” — we’ll see how that plays out next time around.
• Structure > File Types > Image > manage fields. Remove Title and make Alt Text required.

I know there’s still more complex stuff coming, and I have work to do wrangling Media CKEditor to handle documents the way I want them, but overall I’m really really pleased. These folks walked in without any training in using Drupal as editors, and walked out having accomplished the very most common tasks they need to do to be successful.

PS: making fake website content is just too much fun.

Today I talked about Workbench (a suite of Drupal modules) at the Olympia users group. Here’s the notes I wrote to get ready. I’m posting it here for my own reference and in case it’s of interest to anyone else!

Also, here’s the links I posted to groups.drupal.org:

• The Workbench module
• How to override My Workbench with Panels
• bonus video: Eileen Webb on Improving the Author Experience

Workbench is several different things. But one aspect of it is a way to better manage the author experience. I’m really big on author experience right now, because these folks are the people using Drupal the most but they don’t “do” Drupal. And because it’s so flexible, it’s up to us to make it a good time for them and to make their day a little nicer.

The main Workbench module provides a really nice page for getting around in reviewing and creating content.

On My Workbench, I can see all the pages I have access to and the things I edited most recently. There’s also a spot that can be used for custom help or site news. I have a tab for creating new content, too.

So from here I can see all of my content and create new things. Which you could do with the built-in Dashboard, but Workbench also has an Access module and a Moderation module, and those give you more options.

Workbench Access allows you to limit who can edit which pieces of content, and to let a group of people all work together on their own content.

This is what it looks like when I’m logged in as an average site editor. In this case, I’m set up to edit the “advising” section of the site. My toolbar only gives me access to My Workbench, and when I go there, it’s just the content for my site section. I can also edit content that someone else in my group created.

As an administrator, it’s pretty easy to set or review access for the different sections. I can either go to the Workbench Access settings and see that “advising” has one editor, or I can go to the “user” profile and see that they’re set to the “advising” section.

In our case, we’re also using Workbench Access to set some standard content that differs between sites. If anybody’s curious, I’d be happy to talk about it another time. [ed: there was actually a LOT of interest in that, so I ended up talking about it for a while. There’s some crazy Taxonomy+Views stuff going on to make it work.]

Workbench Moderation provides a way to work with draft content and to have review states for content. I’m going to switch over to a draft of a Calendar that students and staff can submit to and then specific staff can review and post.

As a student, I belong to a group that’s hosting an event on campus. I can log in and go to the Post an event link, which is just a normal node entry form. They can save it, but they can’t edit it. I’m still working on some tweaks so they know what’s going to happen next.

What’s going to happen next is that the staff member who reviews these items is going to go to their workbench. I’m working on integration with the Rules module so they get an email, but let’s just say they have a regular time to check. Joe here is already logged in, and on his workbench he has a tab called Needs Review and here it shows the events that Jane has submitted.

The other thing you can do with this that I don’t have a demo for is if you have changes that you know about but can’t show to the public yet, you can create a new draft and save it while still leaving the old version visible. You can also use Workbench Moderation to look back at the history of changes to a piece of content.

So I’m finding Workbench and its modules really useful for making a site that is friendlier for our authors and editors.

I’ve been noodling around with Features*, but I finally sat down and watched the Drupalize.me video series (I’ve gotten all the way thru Ch 8), then set up a tiny test site to try things out. I’ll probably be using this same project to try out Migrate, FWIW.

Some things I cleared up in my own head:

• After you initially create a Feature, you should install it on the site where you created it! That makes it waaaaaaay easier to incorporate updates.
• Recreate = make a new export zip file with all the code
• Revert = go back to the code version of the feature (and hey, sometimes that includes NEW code from an export, because old stuff that you already set looks like an override when the new code comes in)
• drush features-update [featurename] is like Recreate, but works directly on the code in the module folder.

Also, what I did for my test project was one local repository for the code, not in a site, one repo for the dev site, and one for the live site, all coordinated through an origin on GitHub. Which takes some wrangling with Tower (omg command line git) but can be done.

Also also, “is there Features support?” is one of my new module criteria. I’m not 100% sure how I feel about that.

* I think I first heard about Features at a PNW Drupal Summit in Vancouver BC in 2010. Took me until literally this year to actually really understand what the hell it’s for, and why it’s kinda magical. I wish there were more intros for button-clickers (site builders) out in the wild, because there’s a pretty big conceptual leap for non-developer types IMHO.