Where's the Love for Drupal Content Editors? (UPDATED)

One of the great things about Drupal from a developer perspective is access to a large, supportive community of other Drupal developers from which I learn every day. If I'm having trouble figuring out how to achieve something, a quick Google search will often reveal the solution to my problem in just a few clicks.

But a large reason that Drupal has become such a popular tool is that it provides ease of use (or should when developed properly), for clients, who ultimately become the day to day users and maintainers of the sites we build. Once the site is handed over, there is usually a person or a small group of people responsible for maintaining the site, editing, and entering new content. Every project should include some time for training clients on how to manage the beautiful new site you have created for them.

The technical expertise of editors can vary widely—from knowledge of basic HTML, to folks who find anything more than checking their email scary and intimidating. Additionally, as has been pointed out before, Drupal is an extremely flexible framework, which can be put together in many different ways. Depending on the skill and knowledge of the developer, a client might end up with a basic blank form in which they have to create pages and images from scratch—or a user-friendly site with edit links on every major content block that keeps them from every having to touch the scary back end admin area.

Breaking content into sections makes content entry simpler for end users

I think this may be one reason why there are so few generic resources available online for end users. A search for 'Drupal content editor training' mostly yields links to a few university run courses (usually for staff) and the occasional online seminar. The lack of openly available web resources for new Drupal content editors seems to a huge void that not many people in the Drupal developer community have addressed.

Over the coming weeks, I will be thinking more about this and writing posts on specific aspects of Drupal that may be confusing to the new Drupal editor. Developers—what do you think are some baseline things content editors who have little Drupal experience need to know? Editors, what questions do you have about how to maintain your Drupal sites?

UPDATE: Commenter Marilyn Langfeld has taken this ball and run with it and created a new group for Drupal managers and content editors on Drupal.org. Hopefully this will be a central place to share some basic knowledge about administering Drupal and for new Drupal managers to get their questions answers. Head on over and join the conversation if you're so inclined.

Comments

I recognized some potential solutions to these problems over a year ago now, and actually put up a module to help site builders deal with them by making the administrative experience in Drupal easier for content editors.

The module is context_admin:
http://drupal.org/project/context_admin

And you can see some youtube videos of it in action here:
http://www.youtube.com/view_play_list?p=EFD8FDE69D61DCA3

I'm going to demo the entirety of what's available in context_admin in the video series, but I'm not even half way done. Hopefully it helps you out.

Also you might check out Palantir's new workbench module:
http://drupal.org/project/workbench

Good stuff going on in there as well.

Eclipse

Eclipse,

Thanks for all your great comments. Those modules look good, and we may even have used one or more of them in past projects (I'm pretty new to the company so couldn't say for sure). I will definitely keep them in mind.

It still doesn't address my main point though which is the gaping hole of resources for admin/editors/clients. Hopefully whoever they hire to create their site is thinking about and addressing the content management piece. But what if they aren't?

I recently took over a site that was basically handed off with no thought given to the user experience of the owners who maintain the site. It doesn't even have content types so they are basically dependent on the WYSIWYG form which doesn't even allow photo uploading. They don't have the budget to invest in a lot of training hours.

I'm sure this scenario is not unique. I agree that there's only so much 'generic' information that would be useful, but I think it's worth thinking about what that information might be.

And that is exactly what I'm getting at Kronda, the issue, and this is something we need to combat more on a daily basis, is not that drupal core doesn't provide these editor specific tools... frankly it can't provide them, not in any meaningful way. That is a job for a custom profile, and corporately you have to figure out what this means to you. What user experience will exemplify your customers' interactions with their drupal sites, how will your company be remembered from a drupal+UI perspective?

Drupal has a bad rap in a lot of places, and this is due in part to the fact that many "drupal developers" have simply deployed what comes with drupal by default as the only interface their clients us. I personally never give clients access to /admin/* and instead opt for building custom interfaces for their administration. Context_admin allows me to do 99% of what I need in that regard, and my clients then don't have to learn the "drupalisms" that characterize our niche.

Bottom line: Drupal can't anticipate how you, or anyone else is going to setup a site, therefore it can't (and shouldn't) deploy meaningful editorial management in anything but the most specific of cases which means it's up to you to do so. I'm just trying to provide the tools for developers and companies to more easily do that. Hopefully in the context of your reply this makes sense.

I think in some respects Eclipse, we are having two different conversations. And btw, in the conversation you're having, we're on the same side. :)

But I'm not talking about tools for devs to make drupal more awesome and user friendly. My point is that the resources to do that are everywhere, as many replies in this thread have shown.

But check out Marilyn's excellent post on her blog. I think she sums it up really well.

There's no central place-no d.o. for managers if you will. And the reality is, there will continue to be clients who get left with a Drupal site that is still running the default interface. Where is the central repository of basic knowledge that they can look up to find out why they shouldn't paste text from a Word doc directly into a block form?

On the bright side, Marilyn is working on getting a managers group going on drupal.org, which I think is a step in the right direction.

One of the challenges is that since the Drupal philosophy is assembling a pile of legos, each site will be vastly different from a content management point of view.

This is something I run into more and more with clients: Drupal proves to be the best solution for powering their website, but can present a real challenge when handing over to them for content population and day-to-day admin.

Like most of us, I build sites primarily with Views and Panels. I try to make sure that everything content editors need can be accessed through add/edit content, rather than having to get their heads around changing View settings.

Let's consider a site for, say, video game reviews. The homepage has a 'what's new' block highlighting 3 featured reviews. No problem: create a View, select the 3 latest reviews and use a fancy display type with sliding banners or whatever. The client loves it.

Using the technique in the post you linked to, ("Creating Edit Content Links in Views"), the client can edit the featured review nodes directly from homepage edit links. nice.

But the client asks "instead of featuring the latest reviews, can I manually select the 3 reviews to feature on the homepage..?"

So we have two options: a) give the client access to the View settings b) add a checkbox to the reviews content type called 'featured'. Change to View to only list 3 reviews marked 'featured'. I'm not sure either option is ideal; the client expects to just be able to go to homepage settings and select from an easy list.

This is the kind of fiddly example I run into every day. I'm sure these issues are inherent in any CMS, but would love to hear any suggestions on current best practice to make life easier for content editors :)

One thing we've been discussing internally is the availably of documentation for content admins. I agree that D7UX has been a great success, and many excellent tools are available for us to build user-friendly sites. Providing your clients with an "owners' manual" is still a lot of work, though.

I also agree with Dalin that we shouldn't expect a "Drupal content administration" book anytime soon because every site is so different. One idea that interests me is building sites that can generate their own manuals. Kronda pointed out the Help Inject module which looks like a step in this direction.

Moshe,

Not really sure I agree here. Both palantir's new workbench module and my old context_admin module show some fairly compelling management ideas for content editors. I think D7UX did a lot to really push the generic UX of the basic drupal profile forward, and to provide tools other profiles could potentially make use of, but this is a small core argument (and one I intend to make to the community at large shortly) that profiles should be providing menu items, not modules. No module can ever really anticipate the needs of all user types for a specific site, and we need to recognize that as a community and code accordingly. That's not to belittle what D7ux did, just to say that the only place it's even approaching sufficient is the drupal standard profile.

Eclipse

Moshe,

I wasn't trying to imply that all the responsibility for this rests on core devs--and I agree that D7UX is a great improvement.

My goal was to get people thinking about the vast divide between freely available useful knowledge for developers vs freely available knowledge for editors.

As an example, the first hit on a Google search for 'How to edit a drupal node' brings up this screenshot from 2004 for editing in Drupal 4.2!

We can do better, don't you think?

i'm so glad you made your initial post, kronda; i believe you're speaking for a lot of people in similar situations

we're really just talking about there being a good enough critical mass of administrators and administrator-level documentation that developers shouldn't have to care much about a discussion like this one way or the other

it's a whole different part of the ecosystem

but once it begins to be established, it ought to make it possible for us to offer more intelligent inputs with better perspective on targeted feature requests to better address site administrator needs

the idea that a developer would custom-build an admin interface is very attractive to me; but, practically, i don't think a lot of clients would be up for bearing the expense; so, as you say, clear general info on the existing admin interface seems the best place to focus effort

"documentation" for Drupal still seems to mean documentation for programmers; we need more formal documentation for people who are just keeping sites going from one day to the next; and the only people who can really create that are the people doing it

this is brilliant and i'd like to help from the standpoint of a site and content administrator on the pretty technical, freehand PHP and MYSQL side from dinosaur days

in a perfect world, i'd have got started with drupal two or three years back and be doing my own development now

in the real world, my employer contracted for site development with a sharp Drupal shop called Mediacurrent; i specified, they built, we iterated; we continue with minor restructurings and small to medium-sized new features

i love to try to chase the developers, do all the research i can, look pretty deeply into the admin ... but, exactly as you say, there's a point where a developer just doesn't quite know what i mean or want, and doesn't really have time to care, when it comes to usability and documentation of the parts of Drupal that ARE Drupal for content people

the issue i struggle with is understanding the administration and maintenance consequences of new development cases i'm specifying

it's helped me a great deal to look at the many screencasts and tutorials available to get a sense of both what's possible and what's a best practice, but i'm never quite sure if i'm giving a developer too much detail, not enough or the wrong details

it seems like there's a glue layer of detail need to help the administrator needing a new feature to understand how to get it across to a developer

this may sound like it's drifting from your point, but i think it's just a variation of the same point

I couldn't agree more. I am a content editor/manager with almost one year of Drupal experience. I have a Web Managers Drupal - a subgroup to Web Managers group - on LinkedIn. Please join!

clearly that would be endless unpaid labor

and i know D7 is supposed to be much better (but i expect that being drupal it will be mind-bendingly complex in some new way for mere content administrators)

but it still seems like it ought to be possible to systematize some detailed knowledge for people who are technical but not developers; there's such a huge gap between "so easy your grandma could do it" and having to virtually become a programmer to talk to a programmer, who at that point is already two years beyond you again

It's so timely. And it's so true, though I would say the issue is for web administrators/web managers, who may or may not be web content editors.

I've been bouncing from one discussion to another, one initiative to another, looking for the space to discuss this very topic. I wound up writing up my comments on my blog, http://www.marilynsview.com if you're interested.

I'll add here that I believe that developers have a blind spot, seen in the comments here. Web administrators love you, need you, understand that you are critical to Drupal's success and are volunteering your time. We exist too, and need more than a few hours of training to be able to administrate a Drupal site.

You know that, but somehow there's a disconnect. We need a space to learn more about how Drupal sites work, what are the issues to be careful about, what can cause harm to pages, and how to help our editors do their jobs without taking down pages, or messing up image uploads.

Best, Marilyn

Marilyn,

Thanks so much for your thoughtful comment. I think you hit the nail on the head and I encourage everyone to go read the longer post on your site.

I think the reason I have been thinking about this is because I'm both a new(ish) developer and Drupal user so I can still see both sides of the issue.

I know from giving tech support to my family for years that sometimes developers think we're explaining something simply and clearly, but there are a lot of hidden assumptions based on things we take for granted.

Hi Kronda,

On the super-long discussion about wp.o vs d.o I noticed a very nice post by David Hernandez encouraging positive action. To make a long story short, he and I corresponded, and he made a wonderful suggestion: create a web manager/content editor group on d.o.

So I just did. Don't know if/when it will be approved, but encourage all who are interested in this topic to consider participating on drupal.org.

I also look forward to your upcoming posts here on your blog.

Best, Marilyn

This is a very important topic. We have to keep improving the tools and workflows for daily content management tasks. Much of this is very much a custom job for every site, but we have to look for ways to provide a better initial default for this in D8. I'd love to see that research, analysis and recommendations for improvements happening in the group. Do it! :)

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <cpp>, <java>, <php>. The supported tag styles are: <foo>, [foo].
  • Web page addresses and email addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Ready for transformation?