Our UX Principles: 1. Make the most frequent tasks easy and less frequent tasks achievable. 2. Design for the 80% 3. Privilege the Content Creator 4. Make the default settings smart

1.0 Header

Posted: April 16th, 2009 | Author: | Filed under: 1.0 Header | Tags: | 80 Comments »

Admin Header
Admin Header
wireframe updated 27 May 09

Description: A global header which would be shown when logged in to the site (for admin roles (site owners) but not site members (people who ‘sign up’ or ‘register’ to a site).

Global navigation is: Content, Structure, People, Appearance, Modules & Config, <Your Name – Profile>, Log out, Help

Current thinking/roadmap:

  • The top line of navigation is the global Information Architecture and navigation for the adminstration interface. The second line are a short selection of iconographical shortcuts that are customisable per role for fast access to most common tasks
  • Users are able to toggle the header to show only the top line navigation if preferred.
  • No use of javascript flyout menus, although admin menu module could be installed to override this if preferred.
  • The header will remain at top of screen all the time (even when scrolling)

Outstanding issues:

  • creation of library of icons. Need to define a short list of required icons and perhaps commission a designer to create custom icons for use in this theme (recommended re: GPL)

Aggregated Feed (Pipe) of Related Discussions

Please feel free to add your thoughts as comments below or if you’d rather publish them elsewhere you can have them the pipe by using this tag #d7ux_1_0

go back to Project Framework to view all project components

80 Comments on “1.0 Header”

  1. 1 Drupal 7 User Experience Project » Blog Archive » Project Framework said at 12:29 pm on April 16th, 2009:

    [...] Header (#d7ux_1_0) 2.0 Dashboard (#d7ux_2_0) (includes widgets for dashboard) 3.0 My Profile (#d7ux_3_0) [...]

  2. 2 Jerome said at 12:53 pm on April 16th, 2009:

    If the visual style is to be ‘application-like’, then I think the header should remain in the window all the time, like an application toolbar.

  3. 3 Tim Lee said at 12:59 pm on April 16th, 2009:

    Suggest to reference Admin Menu Dropdown and have the feature of hiding by shortcut

  4. 4 Roger said at 1:01 pm on April 16th, 2009:

    I like this header really.

    My suggestion is that we take the administration menu as a floating menu on top and give a drop down style and make it expandable too to look like the menus presented here http://is.gd/oP8b.

    The list structure is already there and with some jquery magic it should be easy to do so.

    The second bar should be a mix of page specific actions. The tabs and form buttons should go there to edit, save or cancel a node.

  5. 5 Tim Millwood said at 1:13 pm on April 16th, 2009:

    I was wondering which roles would see this menu? If it’s a site like Drupal.org where any user can add content will it be seen by all users in some form?

    I think it should work very similar to the admin menu module with similar defaults and options / settings.

  6. 6 CK Ng said at 1:52 pm on April 16th, 2009:

    The local tasks menu can be merged to the second level together with other general smart defaults.

    The Add and Edit on the 2nd level is confusing though. Does Add is to has additional level to show the content types or redirect to node/add? Edit is to edit current page or …?

  7. 7 James said at 3:37 pm on April 16th, 2009:

    The order of the items in the menu bar should be considered as well for usability. The admin_menu module puts the most commonly used stuff (ex, Content Creation) top-left and the user stuff all the way to the right, whereas you’re showing username top-left. Considering the F-shaped visual scanning (http://www.useit.com/alertbox/reading_pattern.html), I would agree that admin_menu is doing it correctly.

  8. 8 mcrittenden said at 3:59 pm on April 16th, 2009:

    I’d image it would be like admin_menu module which has an “Access Admin Menu” permissions so you can control access yourself.

  9. 9 mcrittenden said at 4:41 pm on April 16th, 2009:

    image = imagine. Sorry guys :).

  10. 10 mcrittenden said at 4:49 pm on April 16th, 2009:

    My initial reaction is that a two-level navbar is tough to pull off without a VERY clear distinction between the two levels, and I don’t really see a clear distinction there (first level global and second level customizable doesn’t work as well as if the second level were subnav items of the first level’s selected item or something).

    Also, clarity is importance. Words like “Structure” and “Appearance” can really mean the same thing and don’t tell you what you’re getting into by clicking.

  11. 11 Leisa Reichelt said at 9:25 pm on April 16th, 2009:

    hi James, we’ve described the current order of the top menu as ‘by scary-ness’ where the items to the left are less scary and to the right are more scary. Except for help. Not sure this is the right ordering, and agree that the profile/name link is not well positioned (aside from regularity of usage, top right seems to be a more conventional placement for that element).

    Stay tuned for changes!

  12. 12 James said at 9:52 pm on April 16th, 2009:

    You’re spot on with the ordering by scary-ness, or I would say more technically complexity/level of responsibility. The order of the items in this admin Header goes hand in hand with various roles/permissions where there are hierarchical orders of access to increasingly complex administrative tasks… and conversely get limited to less and less users/roles.

    Ex. a simple three level admin use case:
    - an Editor can only Edit/Create content
    - a Publisher can Edit/Create IA elements (i take IA in your Header to mean stuff like taxonomies, menus etc)
    - an Administrator can do all the above as well as change site and module configurations
    - the super user (uid=1) can obviously add/edit/delete modules, change perms and enable/disable site (do everything :)

    In each case, effectively, an additional item would get added to the menu bar to the right. Again, exactly the way admin_menu currently works.

    Also, I’d vote for, and assume that this new “Header” be available for modifications & reordering in the Admin Menus section. Probably needn’t be said though that the default layout should be the ‘optimal’ one.

  13. 13 Dmitri "dmitrig01" Gaskin said at 4:12 am on April 17th, 2009:

    Why are there two levels of navigation? It makes it seem a lot more complex, especially since some of the stuff could be interpreted as the same — for example, “content” on top, “find content” on the bottom, and “add” on the bottom are ambiguous.

    I think that these should be consolidated into one level of navigation. That way there is no ambiguity, and less important stuff should not be visible from the header anyway. I think that the bottom can stay, the top can go, and a new item can be added to the current bottom (in my version, the only menu), “Administer”, which somehow contains the other items.

  14. 14 Leisa Reichelt said at 11:10 am on April 17th, 2009:

    I think the visual design will help a lot in creating the distinction, also at this stage we’re thinking to only use icons on the second level, so that would also distinguish. As you say, it’s not a simple task, we’ll see how it goes.

    We’ve done a little testing on the terms used in the navigation so far and people do seem to understand ‘appearance’, ‘structure’ is still a work in progress. We’ll do a bunch more testing before we settle on anything here.

    thanks for your feedback :)

  15. 15 Leisa Reichelt said at 11:12 am on April 17th, 2009:

    Edit is current page at the moment, would ‘switch on’ editing mode.

    Add we think will launch an overlay where you can select what you want to add… although, as you can probably tell, this hasn’t been completely thought through yet – we’ll be spending a lot of time on this piece of work in the next week or so. Stay tuned!

  16. 16 Jeff Noyes said at 4:22 pm on April 17th, 2009:

    If that’s the case, maybe help belongs over by logout. I’d almost expect to find it there anyways.

  17. 17 jeff noyes said at 4:31 pm on April 17th, 2009:

    I like it. I have no issues with the two levels. In fact I think there has to be two levels to triage the task at hand.

    Only issue I might have is the big nav (add, edit, find), seems to be a child of the upper element (content, structure, appearnce). In the case of your visual, I’d expect that Dashboard is a dashboard of content – which I’m not sure is the intention. If it is, I’ll be interested to see what the Dashboard looks like for Appearance, Strurcture and Config.

    In my world, it would make more sense if Dashboard, and maybe find were up with Help and [username].

    My test participant though the second nav (add, edit), was reserved for “live” things. For example, add live content, edit live conent. I like that model better. For a given parent, lets say, Structure, maybe Change Appearnce would live on the “live” bar.

  18. 18 Chris Brookins said at 4:49 pm on April 17th, 2009:

    I like it. My thoughts:
    - The menu should be on the screen 100% of the time and I should be able to hide/show it or reduce/enlarge it size with 1 click. We need easily recognizable icons to do so.
    - It does seem like the 2 levels of menus are a hierarchy but they are not. Something needs to change there.
    - I think the nomenclature has some issues in terms of recognition. Structure vs Appearance is vague. Do we really need both Modules and Configuration as top level choices? I’d change it to be:
    – Structure > Layout
    – Appearance > Style
    – Put Modules under Configuration
    - I don’t understand why we would use ALL CAPS for the menu choices.
    - The icon for the dashboard doesn’t say to me what I would see.
    - Would be good to understand what hover text is over these menu choices. We need some.
    - Overall the bottom menu seems too large a default. Space is precious and too much has been sacrificed.

  19. 19 Linea Rowe said at 4:49 pm on April 17th, 2009:

    I like this a lot. I think the lower header with icons will make non-techy users feel more confident and be more efficient. Giving people quick access to the things they do 80% of the time is a great idea.

    I like the idea of giving people the option of rolling up the lower header into the upper to maximize screen space. Seems like this option would be good for people working on small screens.

  20. 20 webchick said at 5:45 pm on April 17th, 2009:

    Are there thoughts yet on what goes under the rest of these top-level items (Structure, Appearance, etc.)? I am particularly interested in how “Configuration” is going to handle eleventy-billion contributed modules cramming their stuff under there. ;)

    I assume either the icons part will have to be able to either horizontally scroll infinitely, and/or it’ll show the 5-10 highest-weighted links and then have a “more” link that takes you to some sort of admin landing page akin to our current admin/build or admin/settings?

    The top-level categories make sense to me, although I’m not sure about “Modules.” I can guess at things I would find under all of the other items, but not under that one.

  21. 21 Jason Reed said at 5:55 pm on April 17th, 2009:

    Looking good! A few thoughts:

    - I’m with Jeff- I think Help could go over to the right next to Logout.
    - I also wonder if Configuration and Dashboard might make sense over there.
    - I agree w/ Chris w/r/t the size of the bottom section- it does feel just a bit big.

    I think there are three distinct sections here: working with the site on a global level (top left), working with the page you’re on (bottom row) and your more global config/state/profile stuff (top right). At present, it feels like there might need to be more distinction between these areas (of course, that is if you agree w/ my assessment of what each area is largely for).

    Either way, I think this is a great step.

    W/r/t your comments, I’d say that the bar should ideally remain fixed at the top of the viewport if the user scrolls. I also think the ability to minimize the entire bar (and not just the secondary bar) might make sense.

  22. 22 mcrittenden said at 7:24 pm on April 17th, 2009:

    Seems like feelings are mixed about the mockup.

    I actually like it a lot, but I think that the ability to change colors is a MUST, even if our choices are only gray, black, and white, I need to be able to choose which header color I want for which site.

  23. 23 webchick said at 7:30 pm on April 17th, 2009:

    IMO, that’s what CSS is for. :) We also don’t allow you to modify the colors of the system messages, watchdog icons, etc. from core, and I think doing so would be “settings overload.” Themes take care of this.

    It’s fully possible someone could release a contrib module to slap a UI on top of changing the bar colour/icons, though.

  24. 24 mcrittenden said at 7:37 pm on April 17th, 2009:

    Good point. Didn’t even consider the fact that the bar is just as themeable as the rest of the UI. :-/

  25. 25 Bojhan said at 7:38 pm on April 17th, 2009:

    So my largest concern is that this navigation will be unable to tackle the navigational flexibility of Drupal. As webchick portrait the share amount of modules enabled, will greatly impact the usability of the configuration page – even with the normal amount of modules enabled, one role beyond content creator will have far more difficulty using any of this (the impact of this experience strategy is big).

    Visually it creates a non-drupalish identity, I wrote down the color – before I looked at the screenshot and it matched. So my expectation matched with a ‘application’ type navigation and more notably with wordpress/squarespace. Although this visual approach is likeable by some, I do see it distracting to much from the content. We should blend in, being part of the site – not be an application, that for a long time has a design principle we worked towards.

    I am still not convinced that you really need a “find content” button, none of the previous tests actually prevailed that people “wouldn’t go look under content” its rather that they didn’t look at administer. On content it just sucks to find your content.

    I am not sure what you mean by roles, does this mean we will have two distinct menus? Or does that mean you will have content being the only one with smart defaults?

    Interesting, this is from own experience – the word appearance never rings a bell with me. Design does, but appearance sounds like an abstracted out word ( I just encountered it again in wordpress)

  26. 26 perandre said at 9:14 pm on April 17th, 2009:

    I like the toolbar, and I think it should stay simple; we probably don’t need to be able to put in icons for ALL tasks.

    What icons that go in could be set in a certain browser drag & drop-style:

  27. 27 sun said at 9:49 pm on April 17th, 2009:

    I’m commenting here, but I could duplicate this note on most other pages:

    This means that Drupal’s user interface won’t work without JavaScript being enabled. (admin_menu still [also] works with pure CSS)

    The size of this widget/menu/edit mode/taskbar most likely prevents usage on mobile phones or any other smaller/reduced browsers.

    If you ever were required to change or alter Drupal’s (current) default UI to a different one, then you know that this is a royal pain. All those nifty widgets add to this complexity, introduce even more ‘default behavior’, and will make it even harder (impossible?) to customize Drupal’s default UI.

    To me it looks like these proposals (as well as Lullabot’s work on Buzzr) focus a very certain use-case for Drupal, using user interface concepts that solely apply to this use-case. At the very least, this means (at least) to me that all of this user interface magic MUST be provided by optional modules, which still can be disabled. Drupal and Drupal’s user interface MUST work without them.

  28. 28 webchick said at 10:04 pm on April 17th, 2009:

    Hm. Could you explain why what’s shown here couldn’t degrade and be fully customizable as anything else in Drupal can?

    All I see here is a 2-level deep hierarchical menu like we currently have under “Administer,” in a bulleted list themed to hide the bullets and display horizontally, and some CSS image styling next to the expanded sub-nav. Some CSS/JS nicety to make it expand out when you hover over it, which, with JS/CSS disabled, would default to the current ka-chunk, ka-chunk, ka-chunk clicking one. item. at. a time. like we currently have to do.

    I don’t see any reason mobile.css/print.css couldn’t remove this styling altogether and go back to a basic set of links.

    Am I missing something?

  29. 29 David Rothstein said at 10:22 pm on April 17th, 2009:

    I agree with webchick. The way I see it, these are just plain old Drupal menus, but themed in a particular way. So like anything else that’s themable, it should be easy to override them. Also like any other Drupal menu, it should be possible for the site administrator to disable it, move it to a different region of the page, change the items that are in it, so on and so forth…

    Imposing any special restrictions on this particular menu would be a bad idea (and would take extra work to implement anyway!) but I’m pretty sure that’s not what’s being proposed here.

  30. 30 Dries said at 6:42 am on April 18th, 2009:

    I like it a lot, but also agree with many of the comments above. Certainly heading in the right direction, IMO.

  31. 31 Mark Boulton said at 8:00 am on April 18th, 2009:

    So, here’s some of my rationale/thoughts cross-posted from Flickr:

    - I’ve gone for textured grey for the background. Safe colour and it will fit on any background. Disadvantage is that it clashes with browser chrome. Also, this MTV site is a good example as the grey could clash with the site. But grey or black is probably going to be the best choice here. Blending the colour with the site could be achieved by some simple config changes.

    - I’ve swapped username with the menu items, although, the down side to that is that when we have a downstate (shown here for ‘content’), it looks like the icons are a subnav of main nav.

    - I’ve chucked in some icons. These have the feel I’m after, but perhaps not exactly. I’ve yet to add some shadows and things on here as well.

    - I’ve yet to make the bottom bit look like a ‘drawer’. Still thinking of the best way to do that visually.

    - At the bottom of the footer, I’ve included a gradient with a transparency. This will be a useful visual device to show the layering effect I reckon.

    - Of course, all of this should gracefully degrade in ‘browsers’ like IE6. I propose we take Progressive Enhancement by the horns.

    So, these are just first ideas. Just getting down some of my thoughts. Let me know yours.

  32. 32 Mark Boulton said at 9:48 am on April 18th, 2009:

    That’s absolutely right, David. We’re proposing this is the theme that is shipped, but, it’s just a theme. The icons, colours, etc. could all be overridden, just like any other Drupal Menu.

  33. 33 Mark Boulton said at 9:51 am on April 18th, 2009:

    I’m not sure what we’re proposing here does *require* javascript. Sure, this *presentation* does, but, as webchick said, I see no reason why this couldn’t gracefully degrade to be visible on a large number of browsers and devices.

  34. 34 joshmiller said at 6:55 pm on April 18th, 2009:

    I’ll chime in here — When I first saw the screenshot, I was looking for something that branded this toolbar “Drupal.” Without that branding, I wasn’t sure what system was running this as the Druplicon/New Drupal Logo and “Blue” are missing.

    It’s sexy, it just doesn’t feel “Drupally” enough.

    We have a theme logo / default logo / favicon — why not use it here in some “branded” way (similar to Root Candy).

    Otherwise, you guys are spot-on and I can’t wait to see what Boulton comes up with for icons.

  35. 35 webchick said at 4:36 pm on April 19th, 2009:

    To me, I view the lack of “Drupalness” in the header as an asset rather than a detriment. If it were there, the branding would need to be themed out on every. single. client. site. ever created. Sounds like a pain in the butt to me.

    Currently, Drupal actually goes pretty far out of its way to be as non-descript as possible, and act as a generic white-label website building framework. Once you change the theme, there’s only the subtle “Powered by Drupal” block, which is easily disabled.

  36. 36 joshmiller said at 11:13 am on April 20th, 2009:

    White label = Enthusiastic Yes.

    Easily Brandable, default to Drupal = Yes

    admin menu and rootcandy both use the favicon, which is default druplicon, in the design of their navigation. We create these little icons for each site anyway, provides a seamless way to brand your menu for the company. This might mean sticking with a literal 50% gray for main color — or maybe a easy color scheme picker like basecamp, istock, et. al. have.

    When in doubt, though, Angie’s opinions are always rock solid.

  37. 37 Tim Millwood said at 3:08 pm on April 20th, 2009:

    I agree the branding should be as non-drupal as possible, but I also like the Admin_menu idea of using the favicon.

    Therefore the branding will automatically change when the favicon is changed.

  38. 38 Jeff Geerling said at 5:55 am on April 24th, 2009:

    I like the direction this is moving, especially if someone can write a quick module for re-theming the admin bar (for newer Drupal users who’d be intimidated having to theme a menu bar).

    The killer feature, imo, would be to have the items in the menu be easily rearranged by users with the proper permissions, as per perandre’s post above. Have a link that says ‘rearrange this menu’ or something similar, and then a lightbox pops up and lets you drag buttons/elements in and out of the menu.

    Also, allow people to create their own buttons (just like a normal menu).

  39. 39 Matt Young said at 11:54 am on April 25th, 2009:

    I really like that idea of changing the buttons per user. Different users have different needs and while the defaults should suit most they won’t suit all and as time goes on frequently accessed tasks change so the user would want to easily change them. Contributed modules would need to add their buttons for module specific tasks to the available buttons list presented to the user.

    I think that the header should show by default with the user able to choose an option to hide the header by default for them. There could be a hover area, maybe a small tab that sticks to the top of the browser window so then when you hover on it the header shows.

    If the header is not hidden users with a small screen would have a very small window if one at all to view the site below the menu if the menu sticks to the top of the browser while scrolling. IMO it would be better for the header to stick to the browser top if hidden so it can always be accesssed but if not hidden be inserted above the top of the page so you can scroll past it on a small screen.

  40. 40 john cooper said at 9:43 pm on May 4th, 2009:

    how about considering the option to have the header moved to the side rather than the top depending on screen ratio?

  41. 41 Leisa Reichelt said at 10:07 am on May 6th, 2009:

    hello! A question for those of you who are following this thread.

    Considering the user roles Content Creator, Site Editor, Site Admin and Site Builder (as described in the Audience Matrix), what do you think would be the top three tasks that they would be most likely to do on a day to day basis (hence would make logical default buttons in the shortcut area of the header)

  42. 42 evl said at 10:19 am on May 6th, 2009:

    Personally I dont like it. Would hope it would be a module that you can choose to install or not, under core.

  43. 43 Leisa Reichelt said at 10:23 am on May 6th, 2009:

    evl – it would be helpful to know what it is about the header you don’t like. And yes, I’m sure that using the header will be optional for those who’d rather not use it.

  44. 44 evl said at 10:32 am on May 6th, 2009:

    I think its the style. I dont know css and my suggestion is to give it the same style automatically as the primary menu.

    Dont know if that will work because i dont know css, but Something that will look exactly like the theme the person is using by default would be great.

  45. 45 Ross Kendall said at 10:37 am on May 6th, 2009:

    Good question, and obviously important to developing a usable interface.

    It would be easier to answer the question if you could refer to a fairly comprehensive list of actions that each role could perform.

    Another thing, it sounds like you are soliciting anecdotal evidence, might this be important enough to try and collect real-world data from a broad audience (drupal module anyone?)

  46. 46 Jerome Danthinne said at 10:55 am on May 6th, 2009:

    Content creator: Add content, Find content, List new content/revisions

    Site editor: Find content, List new content/revisions, Reject/Feedback on content

    Site admin: Users, Content Types, Information Architecture

    Site builder: Content Types/Templates, Modules, Logs

  47. 47 Leisa Reichelt said at 10:59 am on May 6th, 2009:

    hi Ross, we did outline the main actions/tasks in the Audience Matrix (ref: the link in my original note above), we’ll use that as our starting point, just wanted to cross check amongst Drupal users here :)

    re: real-world data – what?! there’s not a Drupal module for that already? :)

  48. 48 Anthony Hunt said at 11:21 am on May 6th, 2009:

    Site editor:
    Create content, Edit existing content, Find content

    Site admin:
    Moderate comments, Moderate posts, Promote content.

    Site builder:
    Create content, Create content types, Create Fields

  49. 49 Anthony Hunt said at 11:25 am on May 6th, 2009:

    Content creator:
    Create content, Upload media assets, Create forum/group topics and posts

  50. 50 Oliver Walker said at 3:05 pm on May 6th, 2009:

    Content creator:
    Add content, Find Content, Edit Content

    Site editor:
    Find content, List/View Revisions, Publish/Unpublish Content

    Site admin:
    Administer Users, Administer Comments, View Reports/Logs

    Site builder:
    Add/Edit Content Types, Add/Edit Views, Manage Modules (tied with Manage Blocks!)

  51. 51 drupalsliu said at 3:43 pm on May 6th, 2009:


  52. 52 PWolanin said at 4:52 pm on May 9th, 2009:

    Having the drop-down menu above the buttons seems to be inviting continuous mis-clicking. Even with the D6 admin menu it can be difficult at times to click the link you are aiming for.

    While I like admin menu, I kind of think that this conception of 2 levels is a mistake – I’d think core should have something more simple just like the 2nd level menu here which can be customized per user, perhaps, with a few “favorite” links.

    Per Sun’s comments above, we should follow the lead of the current admin menu that does pretty much all the work via CSS.

  53. 53 Leisa Reichelt said at 4:56 pm on May 9th, 2009:

    I agree that a dropdown over the second level navigation would be tricky, but at this stage we don’t have any plans to implement a ‘dropdown’ state from the top level navigation. Clicking on an item in that navigation would trigger an overlay window rather than a sub-navigation.

    I know on the surface that sounds as though we’re adding in a layer of ‘work’ but initial investigations seem to indicate that it works quite well – we’re also (as you can see) looking to simplify the number of elements in the navigation system.

    *very* soon we’ll have something starting to come together that you can actually click through to get a feel for it – it is tricky evaluating and responding to these things ‘in theory’, isn’t it!

  54. 54 PWolanin said at 4:59 pm on May 9th, 2009:

    Thinking about this a little more – an alternative conception of this would be to place all the “local tasks” (i.e. tabs at the top of a node) into such a format. That might greatly help the usability of tabs.

    To make this useful though, we’d have to revisiting the issue of dynamic local tasks, see: http://drupal.org/node/353208

  55. 55 David Rothstein said at 2:00 pm on May 11th, 2009:

    Peter, that sounds like a really interesting idea – because on most pages in Drupal, the local tasks are actually the main “action items” that people are likely to take on that page… (Or to put it another way, if the header were to show on those pages and contain anything *except* the local tasks, it might distract from them.) Also seems like ‘CK Ng’ may have also suggested something similar in a comment above.

    What’s a bit complicated, though, is that it might make more sense for some local tasks than others. For example, with nodes, the local tasks are very closely tied to the node itself (“view”, “edit”, “revisions”, etc) so I like the fact that they appear right next to it — of course, they are almost invisible in Garland, but that’s a problem with the Garland theme itself more than the navigation model. For a lot of other pages in Drupal, though (pretty much any page within /admin), your idea of moving the local tasks to the header sounds like it might make perfect sense.

  56. 56 Jeff Noyes said at 2:43 pm on May 11th, 2009:

    Peter, I had trouble following you, but through talking with David R., I think we were able to understand. I believe you were suggesting to make the second level of the header be dynamic based on the selection in the first menu. (e.g click content and get List, Add, Edit content). Not positive though.

    Regardless, I think the best feedback you, **and everyone else** can give is to provide concrete problems this design might have, and allow Mark and or Liesa to respond verbally, or by showing users completing the challenge you propose via a test. For example, Nathan Haug did a great job at outlining why edit on page posed problems (http://img509.imageshack.us/img509/7676/audioviewandedit.png). Mark and Leisa don’t know what they don’t know, so it’s up to us to help them know via problems vs solutions.

  57. 57 jeff said at 5:13 pm on May 11th, 2009:

    Leading by example, I’m interested to see how the following would work:

    1. How would I get to child elements of the parents you’ve listed like:

    a) how would I get to menus to add/edit them?
    (current: site building > menus > add menu)

    b) How would I change the directory for file uploads
    (current: site configuration > file uploads)

    c) how would I add/edit taxonomy (viewing my vocabulary and edit terms
    (current: Contnt Mgt > Taxonomy > Add Vocabulary)

  58. 58 Leisa Reichelt said at 8:47 am on May 12th, 2009:

    thanks Jeff, here’s where we’re at with your questions at the moment:

    a) we’re still not exactly sure how menus will work. adding/editing will happen in the ‘Structure’ section and you will (probably) be able to do this either using the ‘direct manipulation’ (drag/drop) tool and/or using a more rapid text based system. You’ll be able to add content to menus on a ‘page by page’ (not strict use of the term ‘page’) basis in the ‘meta’ section of the Add/Edit Content overlay.

    b) This would be a setting in the modules & config section of the site under the ‘config’ tab (I don’t think we’ve got wireframes for the amalgamated config and modules section up yet, they’re coming v soon!)

    c) taxonomy is another bag of worms we’re going to be tackling as part of the ‘Structure’ section – I’ll get back to you on that, but suffice to say that you’d go into Structure and the next step will/should be self evident.

    How’s all that sound? (Will be much easier in the v near future when I can start to show you some of this connected up!)

  59. 59 Leisa Reichelt said at 8:50 am on May 12th, 2009:

    it’s definitely an interesting idea and something that we may explore further, however I think we’d have to make it look a lot more like a conventional ‘secondary navigation’ rather than the button type approach that we’ve used, in order to avoid confusion.

    I think a lot of questions about the two-part navigation will come out in the wash as we move into more interactive usability testing – we’re completely prepared to re-work the current approach if it’s not proving to support a good user experience :)

    indications to date are that it’s fairly easy for people to understand in the context of use, but we’ll see how it goes as it is more rigorously (and interactively!) tested.

  60. 60 sun said at 9:54 am on May 12th, 2009:

    Reading through recent follow-ups on this post, especially on local tasks:

    Those sub-menus in the second row of this header bar are more or less “administrative” local tasks. The Administration menu module already has a similar, configurable setting that allows you to move local tasks into the administration menu, resulting in a very comparable header bar as proposed here (different look, of course).

    Real-world problems:

    1) Drupal does not “classify” local tasks in admin-facing and user-facing – instead they are displayed based on user permissions. For good reason, because no one can predict the use-case scenario of a Drupal site upfront. While local tasks on the Modules/Themes configuration pages might be a trivial case, local tasks e.g. on nodes and users are not; on some sites some of them are administrative, on other sites, some of them are not, perhaps depending on the content-type as well as on permissions of the current user.
    To provide an actual correlation to the mockup/screenshot visible above: “Add” and “Edit” are displayed here, which presumes that the current user is a site editor/administrator, allowed to add content to the current page, or edit existing content blocks. However, Drupal’s permission system allows that the current user does not need to be a site editor/administrator to edit this page. Hence, the first menu row in the header bar is gone. Additionally, Drupal’s permission system allows that the current user might only be allowed to edit this very page. Hence, all task icons in the second row except “Add” and “Edit” are gone. This leaves you, as a site builder, with a user interface that might work for editors/admins, but not for regular users.

    2) There can be second level of local tasks, expanding on a selected local task in the first level. Usually used to split up the same task to different targets. (Build modes, Per-theme settings, Comment moderation queues, etc.)

    3) Usage of icons (http://drupal.org/node/443300) is utopical unless we have a dedicated icon design team that provides icons for 4,000+ contributed modules.

  61. 61 joshmiller said at 10:00 am on May 12th, 2009:

    “usage of icons is utopical”

    What if we created icons for “classes” of modules (menu, third-party, etc) and then let the module override their icon within the .info file. Most themes provide a preview. Almost all computer applications come with icons.

    In short, if we build it and give them reasonable defaults, they will come.

  62. 62 Leisa Reichelt said at 10:04 am on May 12th, 2009:

    on the icon issue, I think that the key to using icons in Drupal is to define *when* is an appropriate time to use icons and to design a set of icons that meet the requirements of those conditions – then to provide guidelines to developers as to how/when to use icons (the simpler the better!)

    if we need an icon team dedicated to making icons for Drupal then we have *way* to many icons and their effect will be nullified.

  63. 63 sun said at 10:33 am on May 12th, 2009:

    You can have a look at the Panels module, which ships with several, nicely designed icons for certain content block categories. As much as I love this effort, you will soon find out that it only works for certain content block types only.

    You might want to have a look at the screenshot that guy posted for admin_menu (http://drupal.org/files/issues/admin_icon.gif) to get an initial idea of how difficult icon design for something flexible as Drupal is.

    What’s content, what is not? Does “add” really always mean “add”?
    Are all settings settings?
    What’s the difference from editing something to configuring something?

  64. 64 jeff noyes said at 12:50 pm on May 12th, 2009:

    The usability team and Mark have talked a bit about icons and will probably come up with something. However, any app that needs 4000 icons, is an app that needs to be overhauled. I’m aware of the numerous threads on icons; I believe —and hope— the latest thoughts are to tackle primary actions only with as few exceptions as possible.

  65. 65 Jeff Noyes said at 1:07 pm on May 12th, 2009:

    Thanks Leisa.

    For these examples, I went broad and picked one subcategory for each main category (e.g. menu = sitebuilding, file uploads = config, etc).

    To fully appreciate your answer to A & C, I need to dive into one particular area. If menu is accessible via structure and “directly manipulated,” that suggests to me that Menu’s is what you’re editing directly after clicking Structure. How then would one edit Blocks? (current = Site Building > Blocks)

    Getting more to the point, your current navigation hierarchy appears flat, whereas Drupal’s navigation system is not. That said, to fully appreciate your design, it would be helpful to understand how one will access many of the sub menu features in Drupal. If it would help, I’ll gladly detail a fairly complex example of a configured Drupal sites menu system – just say the word.

  66. 66 Simon said at 7:48 am on May 13th, 2009:

    Default setup: a few nice icons in a _few_ important places.

    Graphics geeks: the ability to change default icons, and add in where they like.

    But let’s be honest, this is for the admin. There are other things that need to look nice for the audience first.

  67. 67 Simon said at 7:52 am on May 13th, 2009:

    Sorry – admin and content creators etc.

    The icons will have to be pretty generic so that they go well with many themes.

    Themes will obviously want to have some consistency.

  68. 68 Leisa Reichelt said at 9:36 am on May 13th, 2009:


    content creators and site administrators are are key audiences for this project – who are you thinking of when you’re saying ‘the audience’?

  69. 69 Dave Connerth said at 3:25 am on May 14th, 2009:

    Why not have a configurable toolbar accross the top for each user? Icons are easier to use and can be customized. The Admin menu is ackward – you could have a toolbar icon that goes to an admin control panel (like Windows or cPanel – a main screen with icons that take you to each configuration area). Also, it would be nice to have a set of recent links that take you to the most recent screens you have visited – I often find myself having to make a bunch of mouse clicks in Drupal to get back to the same admin screen I was just on e.g. configuring a specific view etc.

  70. 70 xqbzzr said at 2:41 pm on May 15th, 2009:

    If anyone is capable of providing a theme, then why not provide a theme-related iconset with it?
    Is there anyone in control of icons for iphone apps? no! its just 64x64px full color.
    Trust the community!

    And i am repeating myself – i love the one-page admin-overview we have with drupal right now.
    one click on “admin” another click on settings:”whatever” and you are where you want to go.
    With this special menu-bar you have to go through dozens of clicks to achive things.
    I don´t like it! ;-( Despite – what do you mean with”structure”? where will “people” lead me?

  71. 71 Pawel Pohl said at 1:14 am on May 21st, 2009:

    Hierarchical header: good idea. I think most people here agree. However, there seems to be a lot of discussion over what belongs where.

    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?

  72. 72 James said at 1:45 am on May 21st, 2009:

    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.

    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.

  73. 73 James said at 1:56 am on May 21st, 2009:

    For the keyboard drivers out there, that like to get things done with keyboard shortcuts, but ALSO like the visual queues I’ll add in a vote for making the “larger” of the two menubars into a HUD.

    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.

  74. 74 Pawel Pohl said at 2:02 am on May 21st, 2009:

    Hey that looks interesting, kinda like the search in Start menu in Vista? http://www.youtube.com/watch?v=V0WyCysxWIs

    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 :)

  75. 75 Pawel Pohl said at 2:04 am on May 21st, 2009:

    … this solution would also help settle the “Site Configuration” vs. “Site Building” dispute.

  76. 76 Pawel Pohl said at 2:11 am on May 21st, 2009:

    +1 on tabbing through and keyboard navi in general

    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.

  77. 77 James said at 3:09 am on May 21st, 2009:

    > I don’t like the idea of a centered window

    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 :D 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.

  78. 78 Leisa Reichelt said at 12:24 pm on May 27th, 2009:

    screenshot and overview notes updated.

  79. 79 Martin Baker said at 12:54 pm on May 28th, 2009:

    Sorry this is very long…
    I like the idea about showing the admin menus in an area that is separated from the main site and sticks to the top of the window. This is definitely a good step IMHO! However I’ve got a few concerns about the design as it is.

    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.

  80. 80 tstoeckler said at 10:28 pm on June 17th, 2009:

    Sorry, that I haven’t read all the other comments, so might be duplicate:
    Just wanted to note that on http://drupal.org/node/484820, which is the issue to implement the header, it was numerously stated that the fact that the lower set of links is NOT context sensitive is unclear upon first view. Currently this is being discussed over there (which is probably not the best thing, but hey…).

Your free messaging with whatsapp here only | gladiator slot | Adult SEO