At the OSCMS Summit, Amazon led a workgroup to discuss various issues with Drupal usability. I led a small group specifically discussing the usability of Drupal administration.
Right now, Drupal lumps all of the administrative items under 'administer'. There is no organization to these items at all, and it can be very difficult to figure out how to do tasks that should be relatively straightforward. To this end, we demonstrated the Administration Module.
This module re-organizes your menus into an easier to cope with set of groupings, and provides a master administration page to help those tasks. There are currently two different settings in the administration module, the 'default' settings, put together by David Reed, the author of the administration module, and the 'civicspace' settings, put together by Amazon based upon user surveys.
At this time, we would like to get feedback from the community at large about what groupings make the most sense to people, and which visual format is the most appealing. There are two screenshots available on the module, the first being David's and the second being CivicSpace's. They both take very different approaches, and feedback what is most appealing -- both to look at and to actually use to administrate a site -- could be very useful in determining how to go forward with Drupal.
Dries agreed that Drupal needs to re-organize its menus, and we will use this feedback to directly reorganize Drupal menus either in this coming version (if we can get this done quickly enough) or in 4.8 if we cannot. In otherwords, speed may be of the essence here. The version in core won't re-organize your menus--instead, Drupal will specifically put its menus in the right location, and the administration module will simply provide an overview and statistics to make site administration nicer and more friendly.
In any case, we encourage anyone interested in this topic to download the module, install it on a 4.7 test installation, and play around with it. Here are some specific areas we want feedback:
- Do the groupings (of either set) make sense. Does one grouping make more sense than another? Are there groupings we may have missed? (At least one came up during the talk, but I don't wish to bias responses).
- We haven't really addressed contrib modules, but we would need to do that: Where would popular contrib modules put their menu items?
- Are items mis-filed? If so, where should these items be?
Any feedback we get on this issue would be very appreciated!
Comments
Configurability!
I have yet to look at the code, but it would be nice if these different approaches could be encapsulated in .inc files, so that people with an interest in tinkering with the admin interface can easily experiment and develop these settings on a separate track from the module developer.
This could lead to different admin profiles being a standard configuration of a site, just like a theme.
------
Personal: Outlandish Josh
Professional: Trellon
------
Personal: Outlandish Josh
Professional: Pantheon
On the screenshots
Initial thoughts on the images:
In general I like the how civicspace screen has a heading for "build your site," and also in terms of how it tries to explain things a little bit, but I like the look and layout of David's better.
However, in a perfect world I want something even simpler than either of these. Still too many choices. Could we break it into tabs: basic, advanced, etc?
More graphics! People recognize icons more quickly than they pick up drupal-admin-lingo.
Drive convergance with controlpanel.module?
------
Personal: Outlandish Josh
Professional: Trellon
------
Personal: Outlandish Josh
Professional: Pantheon
David is also the author of
David is also the author of controlpanel, so we are definitely in contact.
-- Merlin
[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]
-- Merlin
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]
control panel
The control panel already provides a function that takes a menu ID and displays the child menu items as icons. It would be trivial to incorporate any given admin panel as a graphical control panel. Here's what it would look like . It's really just a question of design, usability, (and end user preference)
default can show icons
With the default configuration you can turn on menu icons. Here is a screenshot.
already works that way
Thanks to merlinofchaos addition to my module the module aready works that way. There is a default.inc and a civicspace.inc and you can choose between the two. If you want to provide you own you could just create a new inc (along with the css file for it) and it will automatically show up as a new choice.
layouts -- eye movement when reading
I think if you could track eye movement of people reading these two different admin screens, David's would be easier to read. For a reader to go through the different tasks in one section, in David's, your eye just has to traverse a vertical list. With CivicSpace, the eye has to also move left to right and cross any white space between the two lists. I also noticed that when I read the CivicSpace admin menu the first time, I was torn between reading back and forth within a section, left to right and then down, or down the list vertically and then over to the next list. This is because we naturally want to read left to right (or for some languages, right to left, but the analysis still applies).
Der's interface
I don't know about the usability surveys, but I am more comfortable with Der's interface and I daresay that will be the common experience.
cel4145 makes a very good point about the eye having to traverse the white space- I found it quite hard to understand what the Civicspace interface is all about because of this.
Other things I don't like about the CS interface:
1.) Introducing unnecessary technical terms (applications) and then explaining them again using parentheses (modules). In my opinion, this just adds to the cognitive load.
2.) Inconsistent writing style for both the section titles and the explanations- view each section and you will notice different parts of grammar being used- 'Administering', 'View' etc etc. I suppose it could be corrected with some good technical writing.
3.) Hard to read fonts- I am not 40 yet(;-)), but find it really difficult to read the stuff on the page.
Even from an admin-task point of view, Der's is better organised than the CS example. I can't figure out what managing users is doing under 'Site overview'.
I am not criticising the CS effort. This is just my honest feedback.
Merging the two interfaces
We are going to merge a couple of the ideas into some new interfaces.
This won't be a design by committee experience!
The CivicSpace design was based on an old prototype design.
-The grey brings focus so we will use that.
-Icons are not used in many latest generation web applications, and take up space that could be used to explain concepts to new users.
-This interface will be targetting new users, not just site developers or drupal programmers so we will be introducing concepts with terms that new users can understand.
-The content of the administration interface will focus on helping users accomplish the common tasks, as determined through user interviews and our administration surveys.
Everyone reading this is way more technical than the new users and you should be prepared to see several important design compromises that meet their needs, such as terminology.
Kieran Lal
Amazon’s comments seemed
Amazon’s comments seemed to have stifled the conversation on this thread. I agree that this shouldn’t be a “design by committee experience”. That often leads to a design that nobody likes instead of a design that the appeals to the majority. But I do think there is merit in discussing the categorization of the admin menu items. Can we at least get feedback on what the major sections should be and some opinions about which admin items go where?
Yes, definitely; I think
Yes, definitely; I think this is important and exactly what I'm most interested in focusing on.
-- Merlin
[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]
-- Merlin
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]
and a second
Yes. There's a difference between "design by committee" and getting feedback for the purpose of improving design. Feedback doesn't necessairly constitute a vote in the decision making process. There seems no reason not to involve the community in offering suggestions.
Optimized Admin Menu
Regrouping and restructuring the admin section of Drupal is definitely the most important task for improving usability. It is also certainly nice to have some demos to talk about. However, before starting to work on code and design I would rather like to trigger some discussion on the basic goals and principles of administration tasks first (Ber has some thoughts on that subject too).
Why do we need an organized admin menu structure (and possibly a default admin theme) ?
- to make it easy to understand and work with for common users (which in return reliefs developers from having to respond to many newbie-questions)
- to have a generalized workflow for most of the common tasks
- to establish and improve interface guidlines
- to have a generalized way to integrate non-core-modules
- to reduce complexity without losing flexibility
- to enhance logic and predictability
- to make it easy to theme
To make this really happen I see three phases for discussion, that should build upon each other:
1. Structure
2. Interface
3. Code
My approach would roughly be, to see the following menu structure as a starting point. It´s a bit like thinking of Drupal as a container hub (or a node hub) and therefore it is also a very generalized approach. You fill a container with whatever you like ("create content"), add information about the content of the container ("structure content"), and manage the appearance of your container items ("manage content").
This menu structure should be easily extendable with specific topics for high level tasks like ecommerce or CRM for faster access.
-------------------------------------------
Reinhard Knobelspies
www.hyperlocal.org