1.0 Header

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 thoughts on “1.0 Header”

  1. 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.

  2. 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.

  3. 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.

      1. 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.

        1. 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 πŸ™‚

  4. 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 …?

    1. 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!

  5. 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.

    1. 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!

      1. 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.

  6. 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.

    1. 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?

      1. 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.

        1. 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 πŸ™‚

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

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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.

    1. 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.

  13. 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)

  14. 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.

    1. 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?

      1. 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.

        1. 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.

    2. 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.

  15. 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.

  16. 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.

    1. 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.

      1. 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.

        1. 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.

  17. 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).

    1. 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.

  18. 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)

    1. 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?)

      1. 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? πŸ™‚

    2. 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

    3. 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

    4. 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!)

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

    1. 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.

      1. 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.

  20. 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.

    1. 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!

  21. 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

    1. 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.

      1. 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.

  22. 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.

    1. 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)

      1. 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!)

        1. 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.

  23. 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.

    1. “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.

      1. 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.

        1. 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?

    2. 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.

  24. 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.

    1. 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.

      1. Simon,

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

  25. 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.

  26. 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?

  27. 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.

    1. +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.

      1. > 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 πŸ˜€ 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.

  28. 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.

  29. 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…).

Comments are closed.