Category: UserInterface
Proposed by: dmitrig01

Ever thought Drupal is hard to use? The task is to find out where, and to improve it. The task is to find two (2) pages with bad usability, and suggest two ways to improve them.

The steps are as follows:

* Install Drupal
* Play around a bit
* Find two pages that are hard to use
* Consult the primary contact on whether they are "the way Drupal works" or actual usability problems
* Repeat until you have two
* Suggest and mock up ways to improve both of those pages

The final deliverable will be an annotated screenshot and/or mockup in the form of the "Sample mockup" listed below, along with suggested improvements, posted to and reviewed by a member of the Drupal Usability group.

Resources:

* Usability group: http://groups.drupal.org/usability
* Sample mockup: http://drupal.org/files/issues/3-term-form.png

Estimated time:

2-4 days

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webchick’s picture

Status: Active » Postponed (maintainer needs more info)

Claimed by zacharyhamed (couldn't find d.o username)

webchick’s picture

Status: Postponed (maintainer needs more info) » Active

Time ran out on this task. Marking as re-opened.

add1sun’s picture

Status: Active » Postponed (maintainer needs more info)

Claimed by terror.australis

DanW’s picture

Alright, I've gone through quite a few pages, and haven't noticed any which were glaringly hard to use. I did notice a few, smaller usability issues though.

Blocks
-Would be great to be able to drag a block to its exact spot on the page. (not sure about the technical feasibility of this one)

URL Aliases
-Rename 'filter' to search & make it an 'as-you-type' search (I think the renaming would make it a little clearer what it does)

Permissions
-Would work better with some extra explanations of exactly what the permissions do. I can do a quick mockup of how I imagine it working, but I thought it would be best to make sure this idea isn't just me being crazy. ;)

User Settings
-The "Welcome, no approval required" email shouldn't be expanded by default. All the other ones are closed. I can't see any good reason this one shouldn't be.

Users
- Add the ability to search the users based on their username. I know there's a separate page for this, but it seems a bit silly.

All "Add Content" pages
-What about adding an optional WYSIWYG editor? This should make it easier for newbies to get everything looking just right.

Add Book Page
-Expand the "Book Outline" options by default. Seems only appropriate, since those options would be often used when a book page is being created.

If anybody thinks a couple of these are particularly glaring problems, I'll focus more on those pages and see what else I can find which needs to be improved. Otherwise I will continue the search for the Drupal page which is hardest to use. :)

webchick’s picture

A couple things to start:
* First, thank you SO much. It's great to get a fresh set of eyes on some of these pages. :)
* The difficulty in most of these pages is the flexibility of Drupal, which translates into difficulty in trying to keep user interfaces nice and simple. Ironic. :P I've tried to highlight places where you might have trouble.
* I mention a few places on some of your easier suggestions that you should file a core issue about those (if possible with a patch.. if you don't know how to do that, drop by #drupal or #drupal-ghop and we can walk you through it!). But please make sure you search first so I don't get yelled at for unleashing hordes of duplicate issues in the queue. ;)

Now, a review...

Blocks
-Would be great to be able to drag a block to its exact spot on the page. (not sure about the technical feasibility of this one)

Indeed. This one is challenging, because of the concepts of regions.

Each page can contain 1 to n regions. Most themes define basic "header," "footer," "left sidebar," "right sidebar," and "content" regions. However, you can go nuts here and have a "music review ad" region, which only appears in the content area of "Music review" content types. The pros are, this allows you to place blocks literally wherever you'd like on a page. But the cons are that it's not possible for the block administration page to possibly show all of these regions, as some of them may only exist in certain template files which are not loaded. Oh. And did I mention that the available regions can change depending on what theme you have loaded? ;)

There's also a challenge that the number of blocks a site has number in the dozens or more. Drupal.org, for example, runs the Aggregator module at Drupal Planet. Each feed listed there (and there are about 150 of them) generates a block in the admin panel. So the interface would need to deal nicely with this situation.

And finally, the visibility of blocks would need to be addressed. Blocks can be visible to only certain roles, on all pages except X, only on page X, or use custom PHP to determine the visibility.

Now that said, configuring and tweaking blocks are one of the most common tasks that people do on the site, so this would definitely qualify as a great area to focus on, if you have any good solutions, despite these limitations (ironically, flexibility in this case means limitations in making things work nice and simple :D).

URL Aliases
-Rename 'filter' to search & make it an 'as-you-type' search (I think the renaming would make it a little clearer what it does)

The renaming thing is a great idea, imo. How about post a task for that to the Drupal issue queue? I'm not sure the performance implications of a "filter as you type" kind of thing though. But the first would be simple and might even be able to qualify as your first core patch if you're feeling snappy. :)

Permissions
-Would work better with some extra explanations of exactly what the permissions do. I can do a quick mockup of how I imagine it working, but I thought it would be best to make sure this idea isn't just me being crazy. ;)

Oh this is another page that we use ALL the time and could really use some TLC. I would absolutely love to see your ideas on this!

About the only weird things about this page to keep in mind is that there can be 1-N roles, and 1-N modules, each with 1-N permissions. So whatever UI you come up with would need to allow for this. If you're feeling extra keen, there are also permissions associated with input formats (admin/settings/filters), and if you can envision a way to put all of those permissiony things on one screen, more power to you. :)

User Settings
-The "Welcome, no approval required" email shouldn't be expanded by default. All the other ones are closed. I can't see any good reason this one shouldn't be.

Good observation. Want to file a patch? :)

Users
- Add the ability to search the users based on their username. I know there's a separate page for this, but it seems a bit silly.

Oh, so an extra filter at the top for "Username is like [ ]" ? I like that idea. Could you file a feature request about that? That's might be a bit too involved to get into Drupal 6 at this point, but would be a nice thing to have in Drupal 7.

All "Add Content" pages
-What about adding an optional WYSIWYG editor? This should make it easier for newbies to get everything looking just right.

Allow me to intervene here before someone roasts you alive. ;) j/k

So we recognize that other systems like WordPress and such come with WYSIWYG editors by default, and Dries as well as most of our user base has recognized that this is where we need to go eventually (and probably sooner than later).

However, Drupal's flexibility brings with it some challenges in this regard:
* Input formats: By default, what you type into the text box is raw HTML. However, that doesn't have to be the case. You can download modules to change the input type to BBCode, Markdown, and so on.
* Filters: Additionally, filters can do things like explicitly forbid certain tags such as img for security. Or provide the ability to type in [map:london] A WYSIWYG editor would have to be flexible enough to deal with this kind of stuff.
* Standards compliance: The Drupal community is exceptionally anal when it comes to standards compliance. So editors that are generating crap like <FONT SIZE=+1><FONT COLOR=BLUE>&nbsp;</FONT></FONT> fill our developers with a certain kind of rage. ;)

That said, there are many optional WYSIWYG editors (TinyMCE, FCKEditor, etc.) that have modules in the download section to provide this functionality until we come up with something nice for core. So I think this one is already covered, at least for now.

Add Book Page
-Expand the "Book Outline" options by default. Seems only appropriate, since those options would be often used when a book page is being created.

Makes sense. Care to make a file an issue/make a patch? :)

If anybody thinks a couple of these are particularly glaring problems, I'll focus more on those pages and see what else I can find which needs to be improved. Otherwise I will continue the search for the Drupal page which is hardest to use. :)

Of those, my personal feeling is the permission screen would definitely be a great one to start on. Possibly the block admin screen too, if you can work within those parameters. Otherwise, keep up your great searching! I love seeing what you're coming up with. :)

DanW’s picture

Heh, looks like I'm gonna learn how to make a patch file . ;) I'll try to get those done tomorrow. :) (there, I just replied to 90% of the issues :P )

Allow me to intervene here before someone roasts you alive. ;) j/k

hehe, looks like I opened something I shouldn't have. I'll just quietly put this issue back to sleep. ;)

It looks like my fear was right about the block screen though. With all those problems, it's something I'll have to spend a bit of time thinking about before I can get a good idea which could actually work. :)

I've attached a picture of what my initial idea of how the help would work on the permissions screen. I'll need to spend a bit more time familiarizing myself with the permissions of input formats to know how well it would work there.

DanW’s picture

Here's a mockup of my thoughts for the blocks admin page.

webchick’s picture

Status: Postponed (maintainer needs more info) » Needs review

Margh. This was waiting on review but wasn't marked as such. Updating status.

EclipseGc’s picture

DanW,

Great work here, I think you've definitely found 2 admin pages that could use some serious work. I'm going to give you some comments and see if we can take this one more level of refinement or so before we call it done.

I'm going to start with the blocks page.

First off, I must say I really like the idea of putting blocks into their own fieldsets based on what module they come from. However, this might be easier if we do it based on "project". Which is already being done on the modules page. This will unify the UI between these two pages, which I think is good. Second, all active blocks would be sorted into their regions like normal, and the disabled ones would be in the fieldsets. I'd make all fieldsets open by default, this is the same way the modules page works.

Finally, I really like your idea concerning filters. I don't know if other people will or not, but if we're going to put it into the mockup, let's put it at the top of the page under the help section. This will make it similar to the content admin page and again, as much as we can unify our UI the better. Also, put it in it's own collapsible fieldset. If/when this mockup sees reality, I'd suggest that the fieldset be collapsed to begin with, but that's not really pertinent to this discussion, except to say I'd like to see a mockup both ways.

Now then, let's chat about the permissions page.

First off, you're absolutely correct, I think this page has been atrociously difficult to work with, although D6 fixes some of that. With that said, it'd be nice (imo) if there were direct links to the permission by roles pages here. The headers seem an obvious place for that to me. Also you might consider throwing the current UI out completely and starting over. Webchick made mention of some sort of draggable/droppable interface where users could drag the permissions to the role. I don't know if that does anything for you, but it might be interesting to see what such a UI would look like.

Remember, consistency as much as possible. If you've seen something similar in drupal elsewhere, copy it's interface as much as possible, but still make improvements.

All in all nice job, I can't wait to see the next revisions.

EclipseGc

DanW’s picture

I've given some more thought to the permissions page, and have started on a mockup which will make it look a lot like the current block page.

To use the blockpage analogy, each 'region' is a role, and you can drag the permissions into the role's list of permissions. My biggest worry with this one is that there are so many different permissions once you have more than a few modules enabled, that the lists will be long enough that it takes forever to get to the correct role. This only gets worse if you have more than two or three roles. My planned attempt to get around this is to put each role and/or the permissions into a collapsible fieldset, but I'm not sure how well that would work.

aclight’s picture

Status: Needs review » Needs work

It looks like this should probably be marked as code needs work.

DanW’s picture

FileSize
94.75 KB
94.75 KB

Here's another mockup for the permissions page. :)

add1sun’s picture

Status: Needs work » Needs review

marking for review. let's wrap this one up.

EclipseGc’s picture

DanW,

I REALLY like this. However, your concern is duly noted and I think valid as well. What is the page were split? Roles on one half (with collapsible "regions") and draggible permissions on the other half. That way we don't have a bunch of up and down movement on that page, and we can just have like a scrollbar or something for the permissions.

I dunno, just a though. I'd love to see some more feedback on this idea. I'm pretty happy with what I'm seeing now. It's a very interesting way to go, and pretty easy to use I'd think. My biggest worry is that drupal "super-users" will not like it because of the manual nature of every permission in the system. Still, let's finish this one up.

EclipseGc

DanW’s picture

FileSize
95.27 KB

I like the idea of 'splitting' the page. I think this mockup may work pretty well. :)

EclipseGc’s picture

Status: Needs review » Needs work

Dan,

This works fairly well, I was thinking of maybe a side-by-side approach? so two column instead of 2 rows, and then you could display a number on each of the collapsed roles to show how many perms are in them (updating as you drag and drop for feedback sake) I dunno, just some thoughts. I think this is coming along nicely. Why don't you give it one more shot?

In any case I think this is looking pretty good.

Eclipse

DanW’s picture

FileSize
98.77 KB

So something more like this?

Sorry I didn't reply sooner - I forgot to check this issue. :(

EDIT: Whoops! Forgot to attach the file.

Anonymous’s picture

Project: » Drupal core
Version: » 7.x-dev
Issue tags: +GHOP
aspilicious’s picture

Component: usability » base system
Status: Needs work » Closed (fixed)

Permission page is rewritten, going to close this discussion as it is to old an not relevant anymore.