Structurally I think mixing top level items with user configurable buttons is problematic. When I first watched the usability test videos I was convinced that the lower header was a submenu and you actually had “Content” selected on the upper header but had forgotten to highlight it. The hierarchical menus pattern is so accepted by users that we naturally see it, even when it is not meant to be there! Even though the 2 lines are differentiated with bg colours and icons, I don’t think that’s enough since they’re both aligned left. Possible solutions might be to lose the gap between “Modules & Config” and “Hello” or centre the items on the lower header. Or I could be completely wrong and it’s just be a design issue – like putting the text underneath the button icons rather than alongside to shift the text further away from the upper header.

Upper Header:
“Structure” is much better than “IA”.

I’m really not keen on “People” as a menu. I understand where you’re coming from on it but watching through the usability videos, it was a point of confusion about whether it meant content about people or admin/authenticated users on the site. I think the term “Users” is very well understood within the audience and while I agree it’s not the friendliest term, there can be little confusion about its meaning. People are very familiar with having a “user name” for instance. They would know at a glance that “Users” meant people that have user accounts rather a piece of content about a member of staff.

“Modules & Config” feels a bit weird to me for a few reasons. Partly because it’s two words rather than one, also because “Config” as an abbreviation feels a bit techy and unapproachable and finally because it feels that “Modules” should sit within “Configuration” rather than being at the same level. I would say there should just be “Configuration”. Could also be argued that this is too techy and “Settings” might be more friendly.

Lower Header:
Would these be a set number of options that could be enabled or disabled on a role basis?
“Add” makes sense but what would happen next? List of content types would appear in the main screen?
“Edit” confuses me as it infers that you are choosing the action before the item you’re applying it to.
“Find Content” is fine but feels like it should be under “Content”
“Dashboard” feels like it should be on the upper header.

Final thought – This might be taking things in a totally different direction but I wonder whether the lower header should be contextual. I’m thinking about the buttons (Cancel, Preview, Save, Delete etc) that are usually right at the bottom of form pages being brought up to the lower header, so the available actions on a page are very visible and the user no longer has to scroll down the page to see them.

That’s a good point. I think the HUD concept though could still be applied, to appear at the viewport top and NOT at the canvas top by keystroke combination.

In other words… an example use case:

The menus sits at the page top (ie canvas top). A user scrolls down the page where the menus go out of site… He can always get back to it at canvas top by scrolling back up the page. OR, while way down the page, he can hit a key stroke (eg Control+Shift+D, that in effect, makes the menus slide down the canvas to where you’re at on the visible page, and rest again at the viewport top.

After a handful of seconds after the area shows no mouse activity, or keyboard focus/movement between links, then it fades away and moves back to rest at the top of the canvas.

Perhaps I’m going overboard with the effects but anyway, there are quite a few nice jQuery effects that can be used with out the need for additional plugins like the additional jquery UI script. I feel like Drupal could take lots more advantage of these default effects that are downloaded anyway on nearly all pages with the jquery.js file.

I don’t like the idea of a centered window, though – I really think that having hierarchical bars one under another is a good visual aid.

I was also wondering about something like a list of most commonly visited functions – like the good’ol XP Start manu has. Then, instead of arguing which functions are most commonly used, we would have just that – a list of most commonly used functions

With a keystroke combination you could make it appear or dissapear, much like a lightbox on any page, and it would of course appear centered on the viewport, nomatter where you are vertically on the page (means you dont have to scroll to the top, AND it doesnt eat your screen real estate by those who would make it a “static” element riding the viewport top). Also the ability to tab through the list of items, having them highlited as you tab through them would be another essential visual queue.

I really like this idea Pawel, and it sparked another similar idea… What about an interface just for searching the admin menu? When you have a module list a mile long, and some modules with certain configurations in certain places… perhaps an interface like the Help Menu Search in Mac OS Leopard would be really welcome interface usability helper until you or your sites administrators familiarize themselves with the structure.

Let’s think about what we are trying to do: we have a huge set of Drupal functions that we want to cram into a tree, while some of these functions belong in more than one place. Someone even suggested that everything should be flat on one level.

How about we just relax and let some things appear in more than one place? For example: functions made available by contributed modules can be found under “Modules”, but also in other sections depending on what a given module does. Is there any reason to only make them available from one of these places?

If I install Views for the first time, I will go looking for Views-specific actions under Modules > Views; but later I will know that Views are about Site Building and that’s where I will go to. In fact, the entries under Modules > Views could just redirect to Site Building > Views, so that I’m gently taught where to go looking next time.

Another example: “Search content” could be under Content > Find (or Search, whatever); but then, let’s say we have a “Search” menu somewhere. Wouldn’t it make sense for this “Search” tab to also have “Search content”, next to “Search users”, “Search newsletter subscriptions” etc. etc.?

We might want to use more qualified names for the actions, for example “Add Content” instead of “Add”, so that it’s understandable in a different context (or perhaps menu items should have two names, one to be used in their “home” context, and one to be used when being a “shortcut” placed in a different section of the menu?).

This kind of reminds me of what Drupal did to storing content. There used to be hierarchical structure on websites, and you had to decide whether something is “news” or “parrots”. Now we have taxonomy, and your parrot news have two homes. Maybe we can do the same to menus?