Scope

For the scope of this project, we're defining navigation as a sub-topic of usability. As such, it will refer to the ease and efficiency with which users can go from point A to point B in the system. We should focus our efforts on common starting point A's and common desired destination point B's (for example: the search results page is a very common point A and the "print these results" action is a very common point B from there).

Specifically for CiviCRM 2.3, we will work on improving the top-level menu navigation (i.e. Home, Manage Groups, Find Contacts, etc.) and the pages you land on once those are clicked (possibly implementing Michael's suggestion below about having the most commonly-used task appear right away with links to the others), adding some customizability to the home page for ease-of-navigation (i.e. a customizable shortcut widget), and the post-search actions (since these are used quite commonly and it's unfortunate that they're hidden behind search results).

Discussion

Usability Pain Points

Prefix your entries with your (first name) to facilitate further discussion.

This focus area includes menus (style, order, naming, page location ...), tabs, and possibly configurable links for frequently used tasks.
Use this section to list pain points. Include the use case(s) / workflow(s) where it occurs and some idea of severity of problem (using 1 to 10 scale where 10 is the most urgent). Let's try to keep these sorted by severity.
(Xavier) The navigation system is confusing. Too many clics.... I suggest that to celebrate the 25 years of the mac we offer civicrm a drop down menu, like, well every single GUI since quite a while I pushed a draft on the svn (trunk), have a look and hopefully you'll find it clearer than the current system
(Brian) Strongly agree. The current submenu items are actually generated when the first tier items are clicked. Why can't the full menu be a static ul/li list (with code to control ACL and component enabled status); then use simple suckerfish css to handle flyouts.
(Wes) I would have to be convinced here. Most drop-down menu implementations I've seen on the web are hack-ish at best, downright unusable at worst. I agree with the basic sentiment that navigation should be improved. But why must it be with drop-down menus? The web is not a desktop app. What if we started more simply and used color-coded tabs instead, with a sub-menu presented once inside the tab (or insert any other simple, more web-friendly option here)? SugarCRM and Salesforce.com do it this way too (minus the color-coding, which is fine, that's an implementation detail).

(Wes) I would also suggest dropping the "CiviMember", "CiviMail", and other "Civi-" names in the navigation and switch to a description of what they do. So CiviMember would become "Memberships", CiviMail -> "Mass Mailings", CiviContribute -> "Contributions", etc. People know they're using CiviCRM, and the extra branding is just redundant and decreases usability.

(Wes) Another usability pain point for me and my users is how much functionality is hidden behind search results. In my mind, creating a smart group or sending an e-mail to a specific sub-set of a group doesn't start with "Find Contacts." These would start somewhere in the Manage Groups tool and in CiviMail, respectively. Additionally, the actions that are there after a search returns are hidden in a small drop-down with little to know order or categorization. So it would be good to both re-design the post-search-results actions nav and think about exposing more of those actions in the nav of other tools. The latter can just link to the search tool, but remember what action they wanted once results were returned and handle that intelligently somehow (perhaps by skipping the usual results page and going straight to the next page like they'd selected that action from the drop-down; you could display the results in an expandable div or something).

(Dave) I find it frustrating that I can't access a 2nd-level menu item directly. Example - I need to find a contribution record, and have to click CiviContribute menu first before I can to Find Contributions.

(Michael) Top level menus items focus on the most common tasks like finding / adding.  This is especially the case for all components, like event, member, etc.  Whilst the membership summary screen is useful, it's not what I want to see all the time and in most cases, it should be swapped with one the most common subtask.  Referring to Dave's example above, Find contributions is the more commonly used task so that should be where you get to when you click on Contribute.  We can go through a similar thought process for events, members.

(Michael) Import is an administrative function and - in my experience - rarely used by your standard CiviCRM user.  So we should remove import participants, members and contributions from the component menu items and group them with import (one less rarely used menu item to see)

(Michael) Events - there is significant overlap (but also significant differences) between the event summary box on the CiviEvent home page and the Find Events selector - users get confused as to which page they are at and wonder why the same options aren't available on each page. Maybe we can rethink what options are available in each table and where they are situated.

(Pete) CiviMail - collapsing the Token boxes on Step 3

Solution Concepts

Use this section for ideas about general approaches - with rationales (how does this approach fix things, what pain points does it address, what use cases does it serve / serve better than the current approach).

(Xavier) added a menu in the sandbox. most of the links aren't working, but the idea is there.

See also Usability - April 2009 developer camp session notes / consider transferring them here.

I think we need to move the configuration where it is used. Eg. put the CiviMail configuration in the civimail menu...

The search being the main activity, I added a search feature similar to the one in the block for in drupal. Few differences: the type of contact is clearly showned in the result, and I wish to have a "search engine selector" (as done in firefox), where you can restrict the searches to only the organisations, only the individuals, search by email only...

Read a good article from Jakob Nielsen it seems that big dropdown menus are the best option.

(Wes) I'm feeling pretty neutral on the whole admin options in the menus of the components they apply to vs. centrally-located debate. I see pros and cons of both. Couldn't we just do both? They're just links to the same thing. I also really like the Jakob Nielsen link above and the mega-dropdown approach it suggests. Everyone should read that. Another big thing that I think makes or breaks web page dropdowns is how they behave. They absolutely must only open when clicked on, not when hovered over. And once opened, they should remain open no matter where the mouse pointer goes until an option in the menu is clicked, a close option/control is clicked (and there should be one), or the original menu title is re-clicked.

Cynthia-begin) I've attached a spreadsheet that provides a view of my thoughts on how we might change site navigation. It's a pretty extensive overhaul and I may have gone too far but I thought I'd put it out there anyway. Also, I am not knowledgeable about HTML so I may be way off base about possibilities.

I envision a series of "main" links that would appear at the top of every page. This would allow the user to get to almost any page from wherever they were at present.

The main links would have any number of related items that would appear either as flyouts (which I like) or as drop-down lists. Ideally, the items could be added by the user, which would provide a tremendous amount of flexibility.

The "logout" link would appear on every page, allowing the user to logout from wherever they were.

There would be a main link for "My Favorites", which would be user configurable.

I used Excel to give an idea of what I mean. The items in bold at the top of each list are the main links. Items that appear below each main link would be the flyout or drop-down items. Each list is in alphabetical order. This is probably not the right approach but I think that the lists, unless they are user configurable, should be in some sort of order and we should be consistent in our approach. I tried to group items where I thought they "belonged". Basically I was trying to provide as much flexibility as possible.

I also may have gone too far in moving stuff out of the Administration menu. I would though, like to see the "Miscellaneous" link renamed or something?

Whatever we come up wih we need to be sure to test with different browsers and with on both Drupal and Joomla as, Brian, I think said. (Cynthia-end)

(Wes) Cynthia, can you summarize your suggestions in here so we have everything in one place? If they must be in a spreadsheet, that's OK as long as you can attach it to this page somehow. I don't see it on here...

(Cynthia-begin) I think my previous post pretty much summarizes the approach I'm suggesting, and the spreadsheet make it instantly clear in a visual sense. To view the spreadhseet, log in and click on "Tools" in the upper right-hand corner of the screen. Then, click on attachments. (Cynthia-end)

Specifications

Use this section (or a separate page) for detailed specifications for the chosen solution(s).