Top 10 UX improvements for Drupal 7

I read from previous posts in this group. One of the big problem is usability consistency between each modules (even in core). Is it the time for having HIG?

This is a minor usability concern from the perspective of a site's readers. If I allow anonymous comments, but require anonymous commenters to leave their name, they will see an error if they happen to have the same name as a user of the system.

I have a hypothetical user with the username 'John Smith', but another John Smith wishes to leave a comment. When he tries to leave a comment using his own name, he gets an error saying that the name is already used by a system user. And while I know the explanation for why this is, my reader -- the person I want to hook and keep -- does not and doesn't care.

The commenter has now been demotivated:

• Other sites (like those powered by Blogger or Wordpress) don't produce this error, so it's not something the commenter has likely seen before.
• The commenter now has to try to come up with some variation on his own name in order to leave a comment.
• This error may be misinterpreted as a requirement to register on the site.

When it comes to breaking down the ux improvement process I like to see it in three steps

-Research (Most certified usability professionals work at this stage)
-Designing a solution whether it be static prototypes or more hi fidelity prototypes (there can be multiple designs catering to different user requirements)
-Implementing the solution (there can be multiple modules based on the multiple prototypes that cater to different user needs)

Each of the above step can be broken down further into another 3 steps

-Input
-Processing
-Output of Deliverables

In the case of research

Input

User feedback on the issue. (rant: Most usability courses and professionals tend to be in the field of research rather than design or programming.)

Processing

Take in user feedback and use usability research guidelines to create a report/summary of relevant issues/hurdles that users face on that particular issue (spotlight topic.)

Output

A summary of the issues (and feasible suggestions if any) relevant to the spotlight.

In the case of designing a solution

Input

Summaries of stakeholder's feedback (mostly user feedback in the form of usability test reports and similar) on the issue and user suggestions on how to improve the interface.

Processing

Take in summarized user feedback (if none the designer can rely on his own analysis) and use their (designer's) knowledge of usability/interaction design guidelines and come up with a solution that takes into account the functions and limitations of the web browser and JQuery.

Output:

Static wire frames and/or more high fidelity prototypes.

In the case of implementing the solution

Input

Hi fidelity prototypes, wire frames and possibly usability reports (in the event a developer can expand on the designed solution)

Processing

Turn prototypes into Drupal compatible code.

Output

Working module, improved interface code etc..

Do note (as posted earlier on d.o and g.d.o) coders can do user feedback and solution design themselves. Solution designers can do user feedback collection themselves but the reverse is not applicable. Usability Analysts tend not to be able to design a solution (based on discussions at ixda.org) or produce working code (anecdotal evidence.) Interaction/Solution designers tend not to be the best module developers (anecdotal evidence.)

(rant: Solo efforts can go quite far but team/organized efforts tend to go much further when lead or driven well.)

• Admin "overwhelming" too much content.
• Trouble distinguising between admin and what's shown to the outside world ("major issue - participants didn't get that the admin menu overlays the website itself).

I think these two go hand in hand. By not having a completely separate admin interface like some other systems do (think Joomla), it's quite difficult to picture what it looks like to another role. Not only that, it also introduces the possibility for completely forgetting to give a role the necessary permission to see something you want them to see.

That does NOT mean a separate admin interface is necessarily better. In fact, even in those systems you need role-based differences in what is exposed in the interface, so it's definitely no magic pill. What could be improved upon easily is the ability to see what you want to see. If I'm logged in as the admin, I can only see everything and need to log in as another role to see fewer options, even tho I'm already inheriting these roles. Similar for a role like "author" for example. Even tho every author is also an authenticated user, the "authenticated user" view isn't available to them. As an admin I can at least create a user for each role and log in as them, but we shouldn't have to do that.

If a user has more than one role, then these roles can serve as a filter for the level of complexity they need to see at any given point. If I'm just reading through content, let me be a "authenticated user". Writing content? Let me put on my "author" hat. Adding a user? Just a sec, need my admin role. That way I'm never confronted with stuff I don't need to see, and have the power when I need it.

But how to switch between the roles? I think we can agree that the only way we can do that now is also the worst option: create different users for each role and log in with that user. That really only works at all for the admin, and even for them it's far from ideal. Another option would be manually switching between any of the roles you are a member of, i.e. in your profile, or better yet a location that's more immediately available, like the drop-down menu of the the admin menu contrib module. A more direct, but also more difficult to implement option is to make visibility dependent of context.

This is incredibly difficult to achieve, because we give the user so many ways to do one thing that there's a lot of ambiguity. For example, I can edit a post's front page promotion status from the admin interface under "content", by going to a post and click edit, or through a view. This kind of flexibility can be powerful and we shouldn't thoughtlessly dispense of it, but it also complicates the issue: how would the system know what I want to do? If I click on the edit tab, am I going to change the content text or set the front-page promotion status? There is currently no way of knowing so we can't limit the options based solely on context. We can however go a certain way towards it.

I think the update page is another crucial usability problem that should be improved for D7. I'm not sure if any progress has been made on that already, so please let me know of any relevant threads.

In D6, update.php is almost unusable. It doesn't always find all the updates you installed, and the names in the drop-down list (6000,6001,1,2,3) make absolutely no sense to the admin. Instead of a long list of modules (that btw also don't correspond to module names, i.e. "cck" isn't in there, but I suspect that's under "content") the page should list only the updates it found, and list them by the name and version number that the admin used when downloading and installing the module. I suspect the items in the drop down lists are for rolling back versions, but how that is supposed to work isn't clear either. If I'm overwriting a module I can't roll back, so what are all those numbers doing in there?

I'm sure this must have been discussed before but I can't find a useful thread about it.

Jeff Whatcott's recent article, When bad things happen to good Drupal site owners, inspired me to compile a list of usability issues that can lead to (avoidable) disasters.

Most of the issues haven't been fixed yet and I'm hoping that people here can help me figure out which ones are already in the Drupal issue queue. Thanks!