Drupal without Drupal – Looking for suggestions on how to dummy-fy the Drupal UI.

Over the past several years that I’ve been working with Drupal as a vendor I’ve become enamored by its power, its flexibility, its support and perhaps most of all with its awesome community.  There is one thing however I’ve personally never quite gotten around.  End Users.

See, the sad thing is most people I’ve met are…well…dummies.  The kind of people who are so tech illiterate they have no idea how illiterate they are.  And, typically I have to support these technological nincompoops.  So, I want to appeal to the Drupal community that is so great and so awesome, and ask how the other site providers among us deal with making Drupal — especially the content creation side — less “Drupal” for end users.

Less Drupal as in, no non-sense UI with few to no options.  Very task oriented and much less “powerful”, but much more self-describing.  Does anyone have any idea on how to do this with existing modules, themes, whathaveyou?  And, I promise when the dust settles to write another post documenting everything on simplifying the Drupal interface.  Deal?  Deal 🙂

17 thoughts on “Drupal without Drupal – Looking for suggestions on how to dummy-fy the Drupal UI.

  1. I’m with you so much on this. I’ve had so many projects that – on the surface, or to visitors – are great looking and successful, but supporting the end-user – or worse – the client with administrative tasks ends up turning a “win” into a nightmare. Here’s a few ideas that I’ve implemented at one point or another in the past that seem to ease common end-user tasks from a UI perspective:

    1) Create a custom menu or menus with links to ONLY the administrative tasks you want your end-user to have access to. For content editors I usually make one that has links to which content they create or edit. The Menu Per Role module is awesome for this, also, as you can usually get away with making one “admin” menu with many links, but segregate link visibility across multiple roles. And I tend to create my own custom menu(s) instead of modifying core’s menus because it’s just easier to deal with and already decoupled (in a sense) from core.

    2) Gratuitous use of panels. Panels allows us to completely control what content any user sees on any given page very easily. That speaks for itself. I also like that I can just place my custom admin menus anywhere that makes sense. I also make use of custom content panel panes for additional help text and such.

    3) Views Bulk Operations. What a godsend for content editors. I like creating custom administrative views for content and users and then enabling VBO with each action as a checkbox. Then it’s easy to just place the view in a panel pane and use CSS to make nice big buttons out of each task.

    Anyway, just a few simple ideas. Good luck in your searches. Look forward to hearing what you find out, definitely.

    -Bob

  2. For one, stop calling them dummies – thats a very poor and demeaning identifier for a group of people. If you want to design for them, please restate the audience you are trying to reach properly – their knowledge and experience, what the knowledge gap is you want to solve. Fior example do you want them to add content, or more? Are they familiar with word processing or casual web browsing.

    Thats when you can start thinking about what task flows you need to simplify and how you can tackle this very difficult problem. Starting at the end by introducing new modules or customized UI’s on your sites will not get you to the understanding you need in the future to build UI’s for this target group.

    1. @Bojhan I mean no disrespect, I’m using the term dummies much like the “for dummies” books (which, I hate coincidently). These are people who’s entire understanding of technology probably revolves around Facebook. These are people terms like “node” and “taxonomy” will scare, and who will not intuitively know to find (or even where to find) a “edit” or “content management” button. In my mind, these are people who don’t make a living maintaining a website, and are mainly just trying to do the best they can either because they volunteered to, or were just some member of office staff hanging around at the wrong time.

      /Robin

  3. Good question. I think there is no simple answer. Sadly there’s no magic theme or module that will do all the job for us. The drupal UI is by default very “all possibilities oriented”. As you rightly said, one must make it less powerful but more task oriented. But doing so require analysis of what task you want to give your users according to the context, so that the interface is not cluttered by too many options but just the necessary. I can find good 2 good examples in 2 Development Seed distributions : ManagingNews and OpenAtrium. According to the section in the website and his role, the user see only the relevant actions and configuration options, nothing more. The way they (cleverly) achieved this : the massive use of contextual tools (Context, Spaces, Purl) so menus and actions change according to the context ; the use of Views to display content AND actions related to it, so the create/view/edit/delete/share/whatever actions are directly accessible => less clicks ; live help texts, 1st login text, empty section texts, form elements description texts, so the user knows where he is and what to do.
    I could add some, but basically the guys really think about the end users. I recommend any of you looking at their distributions to see all work they did to make it “just work”.

  4. Modules like the admin, admin_menu, and vertical_tabs are a good starting point for making your Drupal UI more friendly (especially for users with experience with WordPress). String overrides can be useful for changing things like ‘taxonomy’ to ‘tags’ or ‘categories’ which might make more sense to your users.

    And like Bob said custom menus and administrative views can assist users in managing the site. I don’t necessarily agree with Bob about Panels, I think panels would be confusing to your ‘average’ content administrator.

  5. Not dummies, just not motivated. Everyone wants a website but few are willing to put much effort into adding and editing content.

    The one thing you can do that helps a ton is only give users permissions for the tasks they need to do and nothing else.

    That said I once made these nice docs for end users at docs.advanceitmn.org and gave training and all, but when push came to shove, no one was real motivated to learn and when they needed to add content, they needed help or just asked me to do it.

  6. I usually go for a combination of a different admin theme from the front end theme so users understand they are administering the site in some way. For this I use Rubik by Development Seed. I also use their Admin module to provide a left sidebar menu and I make sure permissions are suitably locked down to only show menu items that are relavent to that user. I also add a new menu to it called Quicklinks that has four or five links to things the user may do every day on the site. Then there are the numerous modules that help with permissions, small UI fixes, my own form alters… etc.

    Drupal 7 is a step in the right direction as far as naming menus and the layout of them, at least some thought has gone into it from an end user’s perspective. I’d love to see that work and thought continue for Drupal 8.

  7. @Ishmael: Oh, I wasn’t suggesting giving end-users access to administrating panels…been down that road and it isn’t pretty lol. I merely meant using panels to layout custom admin pages and for placing administrative UI elements on other pages (yay variants!). End-users should never have to deal with Panels’ or Views’ admin UI. I’ve spent literally entire days training “average” end-users on how to use them both and it still wasn’t enough. That’s not any knock on their intelligence or web-savvy, just to say that if you’re not intimately acquainted with Drupal its UI then there is a very high learning curve to meet.

    A lot of our administrative end-users that we must deal with are very intelligent, highly educated people, but just as I know nothing about editing a newspaper column or managing a team of molecular biologists, I don’t expect my end-users to understand web development or web-based content management. I think where the most of the stress comes from is the frustration that is felt from the steep learning curve Drupal has historically had for the end-user (which, I think, D7 has done a very impressive job in attempting to address). It’s important to also remember that most of these administrative end-users didn’t ask for the job of being put in charge of their company’s/department’s website content management. All too often I’ve had clients who have assigned some poor person the job of being in charge of their site’s content and this person is usually already overworked doing their “normal” day-to-day duties, but they happen or are assumed to have the most knowledge of the web amongst their work colleagues. It helps to try and be empathetic to them and their frustrations, even though that can be a very tall order when it’s equally frustrating for us attempting to translate something that comes so naturally to us to layman’s terms.

  8. Usually i make a couple of custom admin pages with a custom module, works really well for « predictable » content : new webforms, uc products and the likes.
    If they’re Drupal illiterate they won’t be able to do much else anyway so i just focus on making the less complicated tasks simpler.

    And documentation on how to use the admin too.

  9. As the author of context_admin (which Will already mentioned) this IS the reason I wrote the module. My use case, as the video should demonstrate is to generally place administration along side the content. If you’re building a news view, of news nodes, then it usually makes sense to your customer to go there to add new news. Thus I’m co-locating administrative tasks, like creation content and managing content IN the various sections that display the content.

    I’ve had a hard time getting the traction on this module that I really want, mostly because the community looks at it and either goes “page_manager… yuck”, or they see the word “context” in it’s title and assume it’s context module related (it’s not). Yes, there’s a lot of setup involved, but it’s TOTALLY worth the effort, and your pages can be exported into features. There are a lot of really high level use cases for the module as well (automatically filling out menu items, auto-populating node references etc etc) but most of that is something that I’ve had to guide people into manually, and I haven’t finished my help section yet. I really hope this helps you, it IS a good chunk of the answer to your question.

    Eclipse

    PS: I’m on irc pretty much all day every day, so… hunt me down and I’m happy to help and walk you through the module.

  10. NodeOne wrote an article awhile back lamenting about how they misunderstood the awesomeness of Ctools’ Page Manager to be awesomeness of Panels instead, and they dropped a mention of the Contextual Administration menu.
    http://drupal.org/project/context_admin

    This sounds like a super-dull module, but just watch the tutorial in the project description and it’ll get your mind going 🙂

    Related to that, my new UI philosophy that I’m working on, is to include my own admin shortcuts and tools where the content is present. So just like Drupal enforces this at the node level (with View, Edit, etc menu tabs above nodes), I’m trying to enforce this at a view level using context_admin. So a view might have a context tab which sends a user to the content admin VBO view that’s already filtered the for the appropriate content. Or maybe there’s a tab that says “Rearrange”, which leads to Draggable view (or maybe the Draggable view is simply how they see the content listing as an admin?)

    It’s great to have a centralized place for all the settings to live, but also nice to have links from the sections of the site that are being administered 🙂

  11. I for one have moved in the direction of:
    context. http://drupal.org/project/context
    admin http://drupal.org/project/admin
    boxes http://drupal.org/project/boxes
    rubik http://code.developmentseed.org/rubik

    The Context UI provides an administrative interface for dragging and dropping views, blocks etc anywhere on the page as it the page appears to their users. And boxes is a rethink and simplification of blocks. The other two just tie it all together nicely.

  12. I had one large project and decided that the best idea along with the training was to create video tutorials … they were not long, straight to the point and could be accessed from any of the admin pages with a small link. I dont think this would be useful in all cases but I think it helps the end user a bit, even if they still end up calling you for support you know what they have been through and this can make trouble shooting less painful.

    Also I find anything that pops out with js they tend to like and i think feel less intimidated when it starts to become interactive. I installed admin dashboard on one site and have had no trouble, only compliments .. admin is also very good and am using that more so now.

    Seriously my next site i am going to make the admin section look like facebook and see how they respond.

Leave a Reply