Introduction

I've just joined drupalib so I thought I'd post this introduction to the community.

My name is Michael Baynger and I am a usability expert with a growing interest in Drupal. I am also interested in finding out more about how Drupal is being used in libraries so I’m glad to have found this site.

In particular, I’m interested in how library staff users are coping with content administration tasks and what site administrators are doing with regard to setting up UIs for their end users. Of course there are many issues that relate to library patrons as well.

Those are just a couple of areas that I hope to have discussions with you about. There are many more that will no doubt come up and I’m willing to bet that everyone here has a list of issues and ideas for making Drupal more usable and productive.

FYI, my background is a combination of usability design and software engineering with roots in the creative arts. You can find out more about my user advocate perspectives at my main blog and more about my professional background at my personal web site. I'm based in Toronto and Ottawa, Canada.

Looking forward to future exchanges.

Michael (useradvocate)

The User Advocate Group "Bridging The Gap Between End Users and Engineers"

Comments

Recent usability experience

Hi Michael,

I'd like to share a recent experience that seems relevant to your interests. I set up a Drupal instance and enabled some useful features such as a rich text editor, an integrated file manager, a block containing a list of the current user's recently modified pages (the workgroup module wasn't ready for Drupal 6 at the time), etc. for a group of librarians who were interested in implementing some of their ideas around structuring library research guides (this is in an academic library). I introduced Drupal's book functionality to them as one possible way of structuring the guides. After creating a couple of guides, one of the librarians reported that she felt Drupal wasn't as usable as another product that she had tried, Springshare's LibGuides (direct link to demo).

Her main criticism was that LibGuides allowed her to create a tabbed interface for users of her guides. I have to admit that LibGuides is slick, and that for content creators who want to provide a tabbed interface to their pages, the product does offer some very polished, easy-to-use tools. Looking around at the modules available for Drupal, I could not find any that made it possible to compete with LibGuide's ability to allow content creators to integrate tabs into their pages (although there are several modules that allow module developers to build tabbed interfaces).

Another feature of LibGuides' that is very nice is that it makes it very easy for content creators to add blocks to their pages. The librarians I was working with want to add guide-specific syndication feeds as blocks, as well as meebo and other IM-style widgets. Both of these tasks are possible in Drupal, but again, LibGuides makes it very easy to do so compared to Drupal. LibGuides allows content creators to drag and drop blocks, a feature limited to Drupal site admins.

I needed to remind myself that LibGuides is specialized whereas Drupal is generalized, and I still argue that as a general package Drupal is one of the most flexible content management frameworks you will encounter. However, first impressions are important and if potential library staff users feel that specialized products like LibGuides are a better choice than Drupal for the types of content that they create (and they very well might be within that limited context), it makes it difficult to convince them that Drupal is worth using as a general tool. I'd love to be able to develop a module that allows content creators to produce tabbed interfaces to Drupal books, for example, to compete with LibGuides at least in that respect. But to justify that development effort, I would first need to convince my users of the overall advantages that Drupal as a general CMF has over a commercial product. Small gains in usability would go a long way to making that argument easier.

Thanks for this scenario

Mark,

Thanks for this very good account of a real life scenario - and your thoughts on the larger issues surrounding 'simplicity' for library staff. It was hearing rumblings of similar stories that got me interested in the library context.

As you mentioned, it's a classic case of an evidently simpler, target-specific tool (LibGuides) weighed against an essentially more complex, general tool (Drupal). In general simpler means less flexible. I never use the word 'simple' in design discussions. It's not useful as a requirement. I use the word 'target' to refer to the specific usage context and the scenario you described does indeed suggest some clearly definable usability requirements. (I have a blog post about the 'simple' question here.)

I share your perspective about wanting Drupal to be both flexible and 'simple' for end users and I can see how it must be difficult to 'sell' Drupal to your clients because of its, shall we say, 'problematic' interface. Yes, it would be great to have a module (or several) to help address the library related target contexts. The really good thing about Drupal is the collective intelligence behind it as an Open Source product with modules being produced and shared all the time.

So if library specific modules were to be created then it should be based on taking in scenarios such as the one you've presented as a source of real usability and functional requirements. That's the fun stuff.

I'm very interested in finding out more specific details about this scenario. For example, I'm intrigued by the desire for a 'tabbed interface'. Do you know what it as was about tabs that would make tasks easier for these users? Actually, that question is premature. I really would want to know more about what the tasks were in general. If you or others are interested, perhaps we can work out a way to capture these details.

Once the usability requirements are established, then we could look at what it would take to produce some modules that would help people in your position 'sell' Drupal and in fact produce a powerful tool for your clients.

Michael

Michael Baynger www.TheUserAdvocateGroup.com

In situ block configuration more impressive than tabs

Hi Michael,

I don't think that the wish for top-of-the-page tabs in the subject guides was motivated by any particular reason other than they are a popular navigational feature that provides a compact way of moving between related pages easily. I am not aware of any empirical research on whether users find tabs to be more effective than vertical menus (such as Drupal's navigation menus) for moving between related pages of content but it would be interesting to see if that's the case.

I think a more useful feature for the creators of library subject guides is the ability to add blocks containing syndication feeds and other dynamic content or widgets. In Drupal it is possible to give users the Administer blocks permission, but the interface is block-oriented, not page-oriented -- by that I mean that the user is presented with a list of all blocks and then needs to use a combination of Region and Operations tasks to make a block appear on a specific page or set of pages. This all needs to be done outside the context of the page(s) that the block is to appear on. The drag and drop placement feature in D6 is great (I've seen developers and site admins drool over it), but to allow a user to add a block from the page they want it to appear on by dragging it where they want it and then configuring what it does using a few simple choices would be a truly killer feature in library sites (or any others) where there are a large number of content creators who may want to add blocks to their pages.

I like your idea of defining the usability requirements for library sites. If drupalibers want to pursue this I suggest setting up a forum topic on it. Let me know and I can do that, or feel free to do it yourself.

Not a lot of info on in situ block configuration out there

Just done some poking around -- googling drupal blocks usability doesn't get you anything on this idea, and the topic hasn't risen on g.d.o/usability, so maybe this is worth spending some time on. Also, from an implementation point of view, it might be worth looking at Panels to see if it can provide this sort of functionality and if so, evaluating that. Maybe someone who has some experience with Panels could comment. But, before we evaluate a tool, it would be interesting to define some requirements....

Some core usability issues

There are many core issues arising here and I can see this discussion expanding into a number of key threads. I’ll just touch base on a few points and let’s see where we go from there.

Tabbed Interfaces

I don't think that the wish for top-of-the-page tabs in the subject guides was motivated by any particular reason other than they are a popular navigational feature that provides a compact way of moving between related pages easily

It sounds like we’re talking about basic familiarity and comfort zones for the end users. What triggers my spider sense here is the phrase ‘moving between related pages easily’. Off the top of my head that raises questions about:

  • user tasks (what motivates their moving between pages?)
  • information architecture (how are the pages related?)
  • awareness context (what is the typical user’s mindset and value system?)

There could be other similar questions to explore.

Usability Studies and Design Solutions

I am not aware of any empirical research on whether users find tabs to be more effective than vertical menus

With regard to empirical evidence, I think it makes most sense to do usability testing for a well targeted context. Here’s my take on it: Coming up with user interface design solutions is like a hitting a baseball. The usability challenge is like the pitch. Each pitch is unique and must be assessed by the batter. Each pitch has to be played for what it is.

Solutions for usability problems need to take in as much specific context as is reasonably possible within realistic time and budget constraints. A novice might try to hit a home run for every pitch, or worse, they might use the same swing for each pitch. This is like imposing a personal solution onto a general problem. At the other extreme is a purely theoretical approach where one just studies all the balls as they fly by. At some point we have to play ball and make a design decision. Play it for what it is, with our eyes open. That preparedness comes from usability requirements gathering based on well targeted user roles.

Calling Functionality from Context

to allow a user to add a block from the page they want it to appear on by dragging it where they want it and then configuring what it does using a few simple choices would be a truly killer feature

I think adding content directly in the page represents the biggest potential usability gain - but it is also the biggest technical challenge. This amounts to allowing the user to work with a more sensible and comprehendible spatial structure. I believe that a great deal of usability gain comes from people having a comfortable sense of their work space. The space created by the Drupal admin UI is, frankly, a mess. It’s not an intentionally designed space. There’s our problem.

I recently gave a presentation at the Toronto Drupal Camp that focused on this very need. Much of the problems that I’ve seen with Drupal management UI (admin and content management) seem to come from the fact that the functionality is pushed into the user's context. This comes about because the UIs are determined abstractly through various code patterns that do little more than expose database fields in a very generic fashion. Hence, the potential for good usability dies on the spot. It’s not the developers’ “fault”. It’s just the current state of Drupal’s evolution that many people are working to transcend.

As you said Mark, I think what is really required in most end user scenarios is that the functionality should be called from the user's context. That is, pulled into the user’s context when it means something to that individual. (This leads into the meaning and significance of ‘Roles’ which I can get into another time.)

Moving Forward

Getting a real solution to this will take some time and it is something where my associates and I are hoping to contribute some solutions. Getting this kind of direct feedback from the user context is very valuable in this regard.

Which brings me to your last point about setting up a forum topic for usability requirements. I think that’s a good idea, I’ll put a post up shortly.

Michael

Michael Baynger www.TheUserAdvocateGroup.com

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You may post code using <code>...</code> (generic) or <?php ... ?> (highlighted PHP) tags.

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.