Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem
- The new toolbar takes up too much screen-estate.
- Its size alone draws too much attention on it and away from the actual page content.
- As if the size wasn't enough already, it further draws away attention by its chrome. (background colors, icons, etc.pp.)
Before
After
Attached patch is a proof of concept fix. Obviously, the icons need to be redone to work on dark background.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | image001.jpg | 15.28 KB | james.elliott |
| #6 | image002.jpg | 18.35 KB | james.elliott |
| toolbar-chrome-after.png | 48.08 KB | sun | |
| toolbar-chrome-before.png | 49.12 KB | sun | |
| drupal8.toolbar-chrome.0.patch | 5.85 KB | sun | |
Comments
Comment #1
Bojhan CreditAttribution: Bojhan commentedDisagreeing with the design is not a bug. I would largely agree with your problem statements, however they do lack argumentation when it comes to the visual side. Lack of argumentation on the visual side, is generally what gets us these problems in the first place :)
It is my understanding, post freeze we visually clean up all the stuff that was cramped into core. I'm making no active stride to do that now, but would encourage others to do so if they feel like it.
This is something tkolery should provide context upon, as I wasn't involved in these decisions around size, icons etc.
Comment #2
tkoleary CreditAttribution: tkoleary commentedThe size of the icons and the bar is optimized to best practices for touch devices (in fact it's a little on the small side for them). I don't think we should make any changes until we see usability data from Dharmesh on this. Until then it's just a battle of opinions.
Comment #3
moshe weitzman CreditAttribution: moshe weitzman commentedWe should consider tightening up the toolbar on non-touch devices. I think it is perfectly fine for it to vary based on touch-api.
Comment #4
sunWrongly assumed there'd be some hope to eliminate admin_menu for D8. Not interested in uphill battles.
Comment #5
David_Rothstein CreditAttribution: David_Rothstein commentedNot sure why this was closed but it seems very legit to tighten it up (maybe just when in the horizontal orientation, rather than specifically checking for touch devices? - if you have a small touch device you won't be using the horizontal orientation anyway).
Just personal preference, but I also like the (D7-style) gray for the bottom bar more than the white. It draws less attention, and if your site has a white background, like many do, a white toolbar seems especially problematic.
Comment #6
james.elliott CreditAttribution: james.elliott commentedI agree with David_Rothstein that doing a check for touch would be the ideal way to determine the spacing and size of the toolbar. An example of this behavior working well can be found in Office 2013. If I right click I get a menu with tight spacing. If instead I use touch and hold to right click I get a spaced out menu that is adjusted for touch optimization.
Mouse
Touch
Comment #7
jessebeach CreditAttribution: jessebeach commentedI'm on board.
Comment #8
Wim Leers#6: woah, that's a *stellar* example! Thanks for posting that!
Comment #9
tkoleary CreditAttribution: tkoleary commented@james.elliott yeah, that's awesome. thanks
Comment #10
sun@james.elliott: That's indeed a good example for doing it right, thanks!
@David_Rothstein:
I agree. It's not only the background color of the website. The Toolbar additionally competes with the browser's native chrome.
The job of an administrative toolbar is to achieve a [web] application experience within a [native browser] application experience. Clearly separating the two, and in addition, clearly separating it from the actual web page.
By using high-contrast colors, that fundamental goal is not achieved: The main line items and secondary line items visually appear as separate units, which do not have a relationship.
One of the first things that every baby/child learns is: Red ball belongs into red bin, green ball belongs into green bin, white into white, and black into black. The current toolbar requires every human to re-evaluate visual 101 basics, because white belongs to black.
An administrative toolbar needs to present a single visual unit, with its own application specific chrome, under all possible circumstances.
And unless dealing with thick fingers, the toolbar has to be as small and compact as possible. The term "toolbar" sufficiently clarifies on its own linguistically:
A toolbar is a tool bar, and not the primary interaction.
Consider a wall, a nail, and you. You only need a hammer if the wall and the nail aren't both designed in a way that enables you to do what you want. Now change the primary interaction, replace nail with pin and it's almost guaranteed that you do not need a hammer.
You do not need a tool if an action can be performed without the tool. Consequently, a tool must stay a tool, and a toolbar must not be more dominant than a toolbox. How often do you need a hammer?
Comment #11
Bojhan CreditAttribution: Bojhan commentedI am not really sure about this, can we get some actual working code? Because the resizing probably involves some magic.
Although I am not sure about the color analogy. There is little visual connection between the active tab and the menu bar below - thats more the problem, than the actual colouring.
Comment #12
Wim LeersLooking at the (awesome!) screenshots in #6, I'm thinking this will have to be deferred to 8.1.0, where it would be a nice usability-enhancing feature.
Also clarifying the title, by appending . Which also points out one fundamental problem: what is the default state going to be? Some devices support both pointer- and touch-based interaction (like the example in #6 shows). So either we default to condensed, but then it's bad for touch interactions, or we default to touch, but then it's bad for pointer interactions.
I propose that if we can reliably detect whether a device supports ONLY pointer interactions, then we can default to a condensed toolbar, otherwise we must default to the current toolbar, otherwise touch interactions would be too painful. Which begs the question: what if you're on a touch-capable device but are using a pointer device? Changing the toolbar's visuals after the user has interacted already seems … jarring.
Which IMHO indicates that we should do this:
Thoughts?
Comment #20
nod_