Notes on the Drupal Usability Report

Indeed, this is a great usability report.

I scribbled these notes as I read it:

  • Statuses (such as "publish", "unpublish", "promote to frontpage") should not use checkboxes -- they should use BUTTONS. Clicking a button helps ensure that a user understands the gravity of their actions -- which is extremely important. These buttons should show a certain amount of intelligence. "Unpublish" or "Save Changes" for live content. "Publish" or "Save as Draft" for new content, and "Publish", "Save Changes" for unpublished content... etc...
  • "Promote to frontpage" is a checkbox that wants to read "Show on frontpage". It's a checkbox, because its an attribute that piece of content can have -- not necessarily an action the user makes on a piece of content. Above all it is of lesser importance than the buttons listed in the previous note -- forgetting to promote a piece of content to the front page will probably be a lot less embarrassing than what could appen if someone accidently publishes a less-than-ready draft. Especially when our interface merely reads "save" -- which is deceptively safe looking.
  • The "story" content type needs to either die, or be renamed "article".
  • "Book pages" should become simply "pages" with pages as we previously understood them thrown away. The behavior that I think users expect from "pages" is what the book module does best. The book metaphor isn't extended that much -- "child", and "parent" are the main terms used in the interface -- not "chapter" and "page" like you'd expect in a book.
  • Settings like front page path are deep enough in drupal admin hell, that a quick fix may have to be a special help box that appears in certain circumstances. Messages would read something along the lines of "Your frontpage is currently set to "/blog". [link] Where can I change this?" These boxes could serve as bandaids for some of our more complex usability problems that aren't going to be solved in a single release.
  • admin/content is important enough to have its own unique section dedicated to content management, and content management only. Site settings, user management, and content management are three very different things afterall. I believe they deserve their own individual sections outside of our behemoth misadministration console.
  • Yes most users really do expect a wysiwg editor of sorts. I speak of our userbase -- e.g. people who'll never visit drupal.org, or would ever need to know what kind of CMS is running a website. At bare minimum, it should let users add links, images, lists, and blockquotes. A message should instruct users that "[return] = paragraph/ [shift-return] = linebreak. TinyMCE is evil because of the number of options it provides.
  • Permissions themselves should be split out perhaps. There is quite a big difference between content related, admin related, and user related permissions. Perhaps splitting these permissions out into more intuitive locations (e.g. content permissions are found in content type settings) and offerring overview pages of what various users can do with various site components would help alleviate this problem.
  • There should be a region, and navagition devoted to admin tasks. I think it belongs at the very top of the page (but is not so high that it takes up too much room). Its separated from the main theme, and is design is always consistant no matter the theme currently being used.
  • The top admin bar, and admin page (as well as perhaps the content creation pages) can be modified, but not quite as readily as a "theme" as we know it. This roadblock frees up theme developers (ESPECIALLY NON DRUPAL EXPERT ONES) to focus on how sites look to their visitors -- they shouldn't nomrally need to worry about how the sites look to their admins/content managers as well. That should really be the the association of drupal ninja's concern.

Overall -- drupal's flexibility and configurability seems to be a curse to our users. The out of the box drupal should aim to offer a few good approaches to common needs that people are trying to satisfy with their website. Like an object, the more that we encapsulate these distinct needs and settings the better. Perhaps we lose "flexibility" -- but if I wanted pure flexibility, I'd write things from scratch, no?

,

Comments

Publishing buttons

I am a new user to drupal...6 weeks now with D6.4. I love it more every day and still everyday i get confused or a little frustrated. No big deal. The backend is a little difficult at first, but I like it now. The drop down admin bar module is very cool...
My biggest request, if i had one at this point...would be the ability to allow different roles to publish,un-publish,save without publish and delete without the ability to promote to front page. I don't want them to have front page promote ability. But i do want users to work on articles with out publishing.
Second i guess would be wysiwig built in with better integration. Being able to control plain text or rich text better, might be a newbee issue. I am using fckeditor and I like it so far..maybe a little awkward for some users.
The books have been good to have, the video tutorials by different people are invaluable, as well as the contributed modules. I am not a programmer, but i am starting to see the real power of drupal.
Thanks to everyone involved! dave

How can I install IVR software with WordPress?

Maybe you don't kown about IVR, in fact, I only need one method, so you
don't need to know it.
But if you want to, this is a sample instruction of IVR that I get from the google search:

IVR Introduction

IVR(Interactive Voice Response), is a phone technology that allows computer to detect voice and touch tones using a phone call. The software based on IVR can respond with pre-recorded or dynamically generated audio to further direct callers on how to proceed.

IVR can let people to interact with any software,such as modify database information, over the phone. So callers can use their touch-tone pad to input request or just say what then want to do, such as requesting account balance information. Then the IVR will use the text-to-speech software to read information back.

So the IVR can enable you to make hundreds of personalized calls with a single click.

IVR can broadcast voice messages by phone. Ideal for group event reminders, marketing, lead generation, political campaign promotions, school fundraising, church communications, emergency notifications, and much more.

The IVR overhead is a pay software,it's instructions are based on Windows operation system,so if I don't buy it, I can't get more helps.
Anybody can give me some hints?

I think there needs to be a

I think there needs to be a way to save drafts from existing content:
[Apply Changes] [Save as Draft] [Unpublish] [Delete]

Great note taking.

I tried Drupal long ago and ended up not doing anything with it because of the admin interface.

Recently I came back and made a more determined effort, and while I really like Drupal, and am amazed at some of the things it does elegantly in the front end, I have faced issues where I have searched through the admin section for the right place to set some setting or other for well over an hour. At times I have resorted to simply starting at the top of the menu and clicking through every link no matter how much I knew it couldn't be right, just because everything obvious to me had already been explored.

Now, a month and a half into playing with the system I am starting to develop a knack for walking away for a few minutes and coming back to see if I have a fresh perspective on where something might be. It works and I find things more quickly.

Still MANY things are simply not obvious. It seems like it would be in one place, but is actually in another. Sometimes one must go to three or four different plcaes within the admin to configure a single thing. Some more task at hand based grouping would go a long way to simplifying the interface without reducing the flexibility.

Too many places to configure small things

HI Nick,
I have been struggling to develop a site with Drupal and am amzed by its flexibility and the modules available, but at the same time frustrated with the usability. Take for example - the Search box. To make it visible to normal users in a new theme, I have to enable it in 3 disparate places - User permissions page, Theme and probably global settings. Also I have move the Search block into one of the regions to to be able tosee it properly.
I completely agree that the usability needs a major push more than anything else in Drupal. Thanks for bringing these issues to the fore.

Good points

Hi,

Great list of Usability points!
I highly agree with the admin region part, while it's nice to have a themed interface for the admin this probably isn't necessary for a large amount of users, the users that need it can theme it if they want too.

I agree almost all of your

I agree almost all of your points.

Anyway, I think the mess of admin page can by solved a lot if Drupal moves to use AJAX form submission (Save without reload a new page). I has been dreaming of clicking on any block in the front page and edit its configuration (similar to Apple Dashboard) for long time. This should be applicable for Menu as well.

Views2 gives us the good example of interface to manage very complex things. The use of AJAX shines a lot and it might be the path that Drupal Core should follow.

Drupal Usability

This article [story] speaks from my heart. Drupal could be so much easier for the user if it would use common language terms for the user interface and not all this Drupal specific vocabulary for certain things. Drupal could be so simple to use [its much simpler than others, especially typo3 in the German speaking countries].

These terms only confuse users who are non-techies [and are not supposed to be] who create and maintain content. A editor should find the same terms to give access permissions or to define content types as he/she is used to from other environment [think of print].

And yes - simplicity is a great thing. Many users probably don´t need to trillion options provided by certain options. That is what is great about silverstripe, but they have a very limited module base to choose from - but the interface is mum-prove and one doesn´t need to check in 2 or 2 different locations just to set a content type and whom is allowed to access, edit and delete it.

Another thing, quite common if you have a couple of modules installed, is the inconsistent upgrade process and parameters. Sometimes even a beta release is recommended as an update [as FCKeditor in 6.2 - it tells me to use 6.x-1.3-beta - why would it do that in a production environment]. Well, I guess the community knows that all, but I hope that a more standardized and user friendly approach can be found. This will help certainly to spread the platform, especially in enterprise environments.

Ugh

behemoth misadministration console

I find this kind of offensive and wrong-headed. I think our admin setup didn't end up completely properly organized, but you were around in the days of 4.7. Your treatment of the admin pages is incredibly unfair and insulting to those of us who labored to improve it.

Apologies, it was great

Apologies, it was great improvement from what we had in 4.7. I think the root of the problem is that too much is being asked of "/admin". No amount of clever design can contain the mass of information in it. Spliting "/admin" into differnt sections for different types of users is one way that could be solved. I should mockup this admin nav I'm thinking of...

node options buttons

you mean , the two possibilites presented by button-like elements so that one is depressed and the other is not but internally or without js is still checkbox? or ...?

Nah no fading out or

Nah no fading out or javascript -- just intelligent buttons:
For new content and unpublished content:

For published content:

Checkboxes would probably want to be in an always visible fieldset directly above the buttons, with 'sticky at top of page', 'visible on frontpage'. Not sure exactly where moderation options fit into this yet.

I could not agree more with that particular point

OOHHHH YESSS, yesssss, yessssssssss!

Learn from WordPress TinyMCE integration

These are some very good points.

Regarding TinyMCE I think Drupal should take a look atn the latest WordPress (2.5.x), they done wonders with customizing TinyMCE and reducing the clutter. It's actually very pleasant to use and the default setup of buttons is chosen wisely.

Thanks a

Thanks a lot!
--------------------------
IVR

Yeah... I realize the large,

Yeah... I realize the large, and disruptive api changes these ideas would entail... Just throwing out ideals.

Post new comment

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

More information about formatting options