By jibbajabba on
Now that 4.3.0 is released, I think it might be a good idea to start assessing usability issues. I have particularly noticed that there needs to be some attention paid to issues introduced with new features. Maybe we should start discussing this here to explore some improvements.
Comments
Observations off the top of m
Observations off the top of my head so far...
Efficiency of use
* The number of clicks to accomplish some tasks has increased with the integrated admin module. For instance, it now takes 5 clicks to add a new feed for import.module. How can we reduce the number of clicks for power users? A sitemap/overview? Bookmarks?
* Related to the above, at a higher level, how can we uncover some of the admin functions that have been hidden because of our preference for deep rather than broad organization of admin tasks? A sitemap/overview of all branches?
Consistency
* We're not consistent with how we handle breadcrumbs and the integrated admin menu. For instance, clicking some of the links in the user menu expands to show sub-links, but in some cases, e.g. clicking "my account", the sub-links are shown in the body of the page below the title rather than in the menu. The same is true with import.module. How do we get consistency across all types of page views? Do we need or want consistency or are these special cases? If they are special, we need to justify that and generalize to some kind of rule.
* Headings in book.module aren't always implemented in a logical, hierarchical fashion. See my bug report.
This is all I can think of now, but with the growing community of users that have expatriated from various other tools, there are sure to be a lot of other ideas. Remember to focus on usability here.
Bookmarks
I have taken over the bookmarks module maintanance just because there were parts of my Drupal site deeply burried in menus. Now I can bookmark any page on the site (the previous bookmark module version was only capable of bookmarking nodes). I don't think that a sitemap is generally a good idea, as most site admins will only use a little subset of all the functions, and having a big list just makes the important points hard to find.
Visibility of menus
One of the problems with the menu right now is that many menu choices are so deeply buried that it takes a good deal of exploring and learning to find them. This reminds me of the black hole interface that is DOS and Unix command lines. If you don't know the available commands, you have to do a good deal of learning to find out how to make things work.
An overview of functions as an index showing all possible actions you can take might help in this regard. Think of this less as a site map and more as an index and maybe the effectiveness of making the invisible visible makes some sense?
Question of viewpoint
I think that we have a different viewpoint from where we see this useabilty issue. I am viewing this question from the 'using drupal' point, and you are coming with a 'learning drupal' point. As I have said, an extensive list of options is not ideal if you would like to use the site daily, but you are right that it might help learning the possibilities.
Yes, I think you're right
Yes, I think you're right. Bookmarks are a good way to create shortcuts to frequently used tasks a power user might have in mind. The problem with a deeply structured hierarchy is that users who don't create bookmarks will have to rely on first learning where the functions are by exploring the menus and creating a mental map. When they return, they have to hope that their mental map holds up and that they can recall where to go.
I don't take issue with the idea of bookmarks. I just fear that this is a band aid over a bigger problem of understanding the possible actions you can take with the system.
Overworked menu type
First: This version of Drupal is a vast improvement over an already great platform.
4.3 has introduced new features - leading to more crowded menus. The integrated admin menu does not really help here. But if we want an integrated menu - I think we need another type of menu. It is the way it works that is not good. I want a layer menu which works like my start menu in both windows and linux. That is: on mouse over - menu rolls out in a layer, and on mouse over on menu item - submenu item appears in a layer to one side of the menu item. I know it is probably (please don't shoot me now) javascript - client side scripting - and that some people do not favour this, but actually I do not care if you can get the same effect another way (Phplayersmenu: http://phplayersmenu.sourceforge.net/).
Thing is - this system now has the potential to be so big that we need a set of menus, and menus with new functionality/design/interaction.
I simply do not see that we can keep using the current tree menu functionality with success. I need pull down menus with layers. I need fast reaction from the menu.
There is another similar experience with the feeds. I believe that showing all feeds in one page - when I have close to 100 feeds - is not the best way to display feeds. I want paging there, or better yet: grouping by taxonomy terms :-)
Also - every feed generates a block. If I do not have use for these blocks, I would like to be able to filter them out of my view in the block admin section.
Just a few observations.
Best
Gunnar
Dropping in from Langemarks Cafe.
Menu management
Gunnar - I've posted a couple of times about this topic. It can be done with pure CSS - although it's a lot more work to manage the exact placement and layout of the menus so they work well. Javascript is certainly another method of doing it. I posted some topics, roughly covering what you are talking about, also discussing better control and management of the menu structures at:
I too would love to see the menus enhanced in the manner you speak of.
Menus are lists
Drupal should expose its menus in the form of a nested, unordered list. Once that's done, you can style it and activate it anyway you want; I'm fond of the navigation at quirksmode.org
Technically, that's not done as a nested list, but it could be.
Ditto to the parent's suggestion
A page with nested lists (say, on an /admin page) for each topic will provide power-users with the best tool they can get: stability of interface. They can "drill down" visually very quickly, and can return to an often-used section using muscle-memory.
How would such page look like?
How would such page look like? Like a site map? Can you make a mock-up or static example?
PHP Layers Menu
PHP Layers Menu seems to work quite nicely, and appears to be designed to degrade gracefully on old browsers. With the proper execution, it could be made functional on text-only browsers as well. (i.e. Lynx) This could be a very useful feature addition for Drupal.
For those who prefer the menu as-is, perhaps we could implement this as an option?
Tom
PHP Layers Module for Drupal
Yes, I agree, it's cool, so I'm working on this phplayers module for Drupal (still in beta, in my pc).
Right now I can create file and taxonomy based menus... will be ready in a few weeks...
https://reyero.net
Sounds good
Would you care to share it with the rest of us once it's done?
Dropping in from Langemarks Cafe.
PHPLayers Module, beta version
OK, you can get a beta version from my sandbox (jareyero).
https://reyero.net
Broad rather than deep
Instead of using Javascript-based solutions, I would prefer to make the menus less deep. That is, make the menu broad rather than deep.
Broad does not solve the problem
I know that you can solve some of the issues by changing to a broad model - but we have just moved to a DEEPER navigation model by integrating the admin section of a site with the public content section. This ADDS a level, and seriously affects the navigation.
Furthermore I don't think the problem goes away by spreading the content over a broader range of menus (one solution to broad). The click-tree model of the menu simply does not work as well.
If we can have a somewhat cross-browser compatible css layers menu, as suggested somewhere else in this thread, and it can gracefully degrade to the current menu, I believe it would be a VAST improvement in usability of this software!
:-)
Dropping in from Langemarks Cafe.
Dynamic or static menus
I am not for or against the current static model for the admin menu, but I do think a DHTML-based dynamic model might help some users. I just wouldn't want to require it for the admin menu to work. Think of users that don't turn JavaScript on or browsers that don't support JavaScript, especially on software for handheld devices.
I'm also not sure whether it will help or hinder progress to make the admin menu categorization broader rather than deep. Certainly, if it were optional to make the administration menu a block by itself rather than being subsumed under the user block, a level of clicking would be eliminated. Perhaps the approach to making the menu system work better should consider different approaches like that rather than merely flattening out the hierarchy?
I still have a problem with the deepness of the hierarchy making it difficult to learn the possible actions you can take on the site. You can see my comments on that elsewhere in this thread.
Document?
Can you point me to a document that describes how to create dynamic menus _without_ using Javascript and in such a way that the menu degrades gracefully (using
Topic map navigation
Most platforms have a left or right-hand columns full of links on the home page; these limks reappear needlessly on virtually all pages. All these platforms, including drupal, could benefit from autogenerated context sensitive navigation; not XFML faceted navigation, but full topic map navigation. In the same way a breadcrumb trail relies on a defined site structure, topic maps define a great deal more structure so that child, sibling, and various classes of related links, can be autogenerated for each page.
http://topicmaps.org
http://www.topicmap.com
Inconsistent page sizes?
Many administration pages show overview tables that are pageable. However, it just occurred to me that some tables show 15 items per page, while other tables show maybe 75 items per page or more. From the looks, these page size are chosen fairly arbitrary ...
Compliance with existing accessibility guidelines
Drupal isn't compliant with existing accessibility guidelines such as Section 508 and the W3C's WCAG. See for yourself by running a Bobby scan.
This is something that should be worked on as improving accessibility, improves usability (for visually impaired).
Admin Overview Page
One feature which would help is an "Admin Overview" page, so that when clicking on 'Administration' in the menu and in breadcrums, the user is presented with a page listing all the admin pages (in the style of a sitemap).
New users could see straight away everything available, and all options would be 2 clicks away from anywhere on the site.
------------------------------------------
Drupal Specialists: Consulting, Development & Training
Robert Castelo, CTO
Code Positive
London, United Kingdom
----
I agree
I totally agree, MegaGrunt. I've been trying to promote the idea of a site overview or an index here, but haven't gotten the impression that others think this is a good approach. We used to have this in v. 4.2. Would it help if I wireframed this to illustrate how it might work?
The idea of an overview page is to help you quickly see what kinds of tasks you can perform on the site without having to click over and over again. It uncovers the hidden functions burried deep in the tree, which is especially important for new users who haven't yet formed a mental model of the tree. There's shouldn't be any reason we can't have this overview and additionally allow admins to customize their admin menu with add-ons such as DHTML collapsing/expanding menus or bookmarks.
Can't you simply make a contr
Can't you simply make a contrib module to provide a sitemap?
--
Drupal services
My Drupal services
Yes; still not helpful to new users, though
Yes, I agree that it can be just done as an add-on as you suggest. But at some point we'll want to determine how much we believe this issue to be a problem in terms of usability. I wonder if the navigation problem get worse (not scale) as time goes along?
It clearly is more of a problem for new users. Advanced/veteran users can work around this problem if they add some other module. But that seems to me, still, to be a band aid to cover up a bigger navigation issue. Clearly we all agree, at least, that there is a navigation issue judging from this diuscussion
Usability is like love
Zeldman wrote: Usability is like love. You have to care, you have to listen, and you have to be willing to change. You’ll make mistakes along the way, but that’s where growth and forgiveness come in.
A polite request to Dries... ;)
When you have a moment, could you take a look at your ratings module? I've actually put off upgrading, for once, in favor of waiting for everything I use to be brought up to date, and this is the last item that hasn't been finished.
Proposal: Make admin menu a separate block and make it dynamic
Thinking about this issue, I was wondering what people thought about making the admin module a separate block rather then integrating it with the user navigation. This would eliminate one click. The more I think about this, the more I think I am also in favor of making the menu dynamic rather than static. As a system/application menu, it should offer quick access to any of the deeply nested functions for the system.
call for non dynamic menus
i agree that dynamic menus make getting around efficient, imagine using even the most basic app without drop down-pop up menus. However i think there should be the option for something a lot simpler as well.
What if I do not want a 'super two click does everything' style menu. I might think my user will enjoy the browsing process and will want to be presented with simple menus specific to the section of the site they are in.
Agree
I agree, kennysto. I think the ability to expand branches of trees that you are not currently browsing is the key here. When you have already traversed a path, the menu should show that branch expanded.
I wouldnt agree..
at least I wasnt going to until I realised that perhaps we are talking about different things. Re-reading your post I noticed you used the phrase 'system functions'. I was refering instead to web site sections. I am to new to drupal to know if the whole website as application/tool against website as collection of linked pages thing has been discussed. It seems to me each has it's own target audience and usability issues.
Some suggestions
Personaly I don't think it is necessary to put an admin section in the menu block, because when a site is set and configured, you don't actually need to change settings a lot.
I think it might be better to have a seperate page for admin use, which saves clicks and also database queries.
Another suggestion is that I would like a "toolbox" which can be displayed as a block or a menu, when a module page is called.
For example, when I choose blog, it can show "top 10 blogs", "add a new entry", "admin blog modules" sections as a block on the left hand side. Other non blog related are hidden, instead of showing all blocks on every single pages.
I think this can be done by adding an extra function in modules, without modifying the core system and themes can add module toolboxes wherever they want.
hidden logout
I just upgraded a production site to 4.3, and one thing that I'm concerned about is that the logout link is hidden under "my account." I'm concerned that users will become frustrated when they can't immediately find it.
BTW: Any suggestions on how I can unhide it?
I'd Like To Offer My (amateur) Usability Skills To Help!
Hi all,
I am willing to 'chip' my bit in and manage/direct/perform (probably gonna need helpers) a Usability Test using a dam good book I bought from Amazon 'Testing Applications on the Web second edition'. Thankfully a lot of it can be left out such as performing stress tests, boundary tests etc because Drupal is already quite solid in those departments because otherwise it would take months, possibly even years to complete ALL the tests!
Main focuses would be accessiblity and usability of interface, administration area, forms, manual and online help included with a drupal installation and any other areas that may be uncovered as being difficult.
Is anyone that is knowlegdeable in usability or testing willing to join me on this? Lee (at) steadnet co uk
Would also need 1 or 2 average or new to Drupal users to test how intuitive Drupal is.
I am already engaged in a project to conduct testing of http://www.fieldcommon.net (running Drupal 4.4.0) which will uncover some useful information that I will no doubtably be handing over to Drupal.org
recuerdos amigos