Toolbar collapsing is inefficient

Isn't the root of this problem the flexibility of the layout of Seven ? In terms of usability, the flexible layouts are often criticized for what you describe. And long mouse travels are also proven inefficient when you need to select something precisely (but oh well, the toolbar shortcuts are big enough). I was thinking about posting an issue yesterday about something related, all the HTML tables become really wide on flexible layouts, to the point that you are never sure of what you've just selected or which element you are going to edit or delete (when clicking on operation links). Those issue are all due to the flexible layout, I doubt we will drop this type of layout since Seven seems to fit many people... but has this been discussed already ?

P.S.: On a side note, in terms of accessibility, the button to trigger collapse/expand of the shortcuts is present even without Javascript and if you hover it, it will turn into the classic hand cursor, which makes you think it will do something when you click but won't do anything without Javascript. This button should be added via Javascript, but that could be another issue I guess.

I implemented some of catch's propositions (I think all... except the hover, for the moment), and also cleaned up the way the toggle element is added, so it is not present anymore when it cannot be used (when Javascript is disabled). I also modified the CSS a bit to avoid having the unncessecary space given for the toggle element when it is not added.

There is only one screenshot for the "before" situation, because it is exactly the same when Javascript is enabled or disabled (which is part of the problem ;)).
I did not make previews for the images, it would break d.o layout and wouldn't be very visible since it goes behing the right menu.

I agree with catch, getting the toggle element closer to the actions it can reveal/hide makes it more efficient... less mouse travels means more precision and better usability :)

There is still concerns for too wide tables, due to the flexible layout of Seven, but that might very well be another issue, what do you think ?

@TheRec

I applied the patch in #3. As a screen-reader user the "Show shortcuts" link is not recognized at all with JAWS 10.1154 / FF 3.5, and is appearing, but is not actionable with VoiceOver 10.5.7 / Safari 4.0.1.

My recommendation would be to make the span that contains the icon an anchor, and to set the title attribute of the anchor to "show shortcuts. Alternatively, make the span an anchor, do not use a CSS background image (the icon is not semantically a background), but use an img element inside of the span and set the alt attribute of the img to "Show shortcuts".

I think this makes sense, also disables me clicking logout all the time when I want to hide the shortcut bar.

The wide tables will probably be addressed by the overlays.

I've pointed Mark and Leisa to this issue as well. Curious about their feedback.

Everett Zufelt> Ok, but we are concerned by usability as a primary goal for this issue... once the usable way will be decided, I'll be glad to make a patch to take into account the accessibility, but this should be done in another issue and be postponed until this very issue is done... I do not think that doing everyting at the same time is the productive approach, maybe you could create another issue dedicated to the accessibility of the toolbar, and postpone it until this one is done (wether this patch gets in core or not, I'll be willing to improve accessility):

Everett Zufelt> I can tell you why, because I removed the empty HTML element used to toggle from toolbar.tpl.php and it is now added with Javascript... which improves usability when Javascript is disabled (users should not see a "button" they can't use). I suppose JAWS can see the link when you don't apply my patch, but you can't use it... my patch does not make accessibility regress, the toolbar is simply inaccessible in the first place... and this should be worked of course, but not at the same time.
Once the concept of the putting the toogling element on the left part of the layout is approved (and maybe toggling with hover... that is up for discussion), I'll consider improving the accessibility of it (either in this issue... or in another one if you decide to create one)... doing this work at the same time than changing the concept of toggling visibility is not the productive approach. Please let Mark and Leisa review usability.

I did not say it is accessible. We are discussing a change of concept in toolbar (moving the toogle and maybe change the way it is toggled). Accessibility is not the main concerne at that stage... And you did not answer, right now (with current HEAD, without the patch), can JAWS use the toggle ? As far as I know, it cannot... it can see it, but cannot use it (and that is bad usability... just like people without disabilites can see the toggle element when they have Javascript disabled, but cannot use it). Please let's review the conept, and then the application (which MUST be accessible, I told you I'll be glad to make a patch for this once the concept is approved).

The approach I used in the "example" patch (to demonstrate how it would work), can be accessible with few modifications, but it is not the main concern of this issue. Could you please point me the issue you were talking about, so we can continue the discussion there maybe ?

marked #547730: Fitts's law in full effect: I repeatedly logged myself out when wanting to collapse the shortcut bar duplicate

Gábor Hojtsy> This is true and can surely be implemented relatively easily, but it is also out of the scope of this patch (we are discussing the concept of toggling and its usability). You should suggest exactly the same in the issue Everett Zufelt pointed out in #2, it concerns the accessibility of this functionality (which is fairly broken right now, but we are working on it in this other issue). Thank you for your input :)

Testbot #34 was bogus according to the log... let's retry :)

Patch applies and tests pass locally.

Indeed thanks mgifford. I did not notice the jQuery.once() introduced a new CSS class for elements that have been processed, it now uses <css_id>-processed instead of just "processed". Here's a working patch... still waiting for a review of the concept (moving the toggle to the left). Screenshots of #3 still applies... and I cannot create previews see why here if you want to help : #561680: 'Trusted' drupal.org role with same perms as documentation ;)

I used the same space than there is between logout (when you put you mouse over "Logout" when patch is not applied you will see the same behavior, it is intended in my opinion) and the toggle element. Spacing is consistent with the current toolbar design.

The javascript alternative will not be implemented in here. We are discussing the concept of this toggle and it's place, not the graceful degradation. See my last 3 or 4 comments about this please.

mgifford> Well not really... the spacing between the elements is supposed to be this way, look at this screenshot (Safari 4, PC), that is HEAD without the patch, while having mouse over "Logout" side by side with HEAD + patch while having mouse over "Content" and spacing is the same. This spacing is on purpose, I just replicated the same design, it is designed to be this way in my opinion. If you find it ugly, fill another issue, who knows maybe you're not the only one ;)

There needs to be more space on the right hand side of the toggle. I'd suggest double the spacing between menu items. Then there is a relationship with the space, rather than it being arbitrary.

TheRec: spacing between the toggle and first menu item should be double the amount that's used to seperate individual menu items.

Of course there's spacing between the items, 20px even:

So the suggestion is to set the toggle 40px away from the first item.

Oh well... here's a patch with 10px more space between the toggle and the first menu element. Screenshot attached shows the difference (in comparison with #3) with mouse out and mouse over.

this looks much better :)
+1 from me

It looks like this has support from Mark and Leisa, and I know I've accidentally logged myself out on a number of occasions with the current position of the collapse bar. It also sounds like the accessibility issues are being sorted out in #540282: Accessibility improvements for the toolbar.

Therefore, committed to HEAD!

I understand your concerns and I totally agree that not all notions of why this collapsing was so bad are totally solid. I am not very keen on defending or working on this though. Branding is sadly the least of my worry here, I'd rather adress the other parts.

1. Agreed, it has a lot of visual prominence now it probably does not deserve. I don't want to guess the who will vs who wouldn't ratio.

2. It is, not sure whether it fully applies to this though - since its a navigational element, that is unique.

3. It would have, that was the actual first suggestion on it - its wrong to assume that was the main reason for this change though.

4. Agreed, as before it holds to much visual prominence, where the user should focus on the content.

Sadly, I am somewhat distracted by other UX-Team activities - Noyz if you could take this one up and provide some more reasoning and possibly solutions to the problems moving this item addressed, we can work on it. Although I completely agree on your notion of it being mostly an intermediate function, lets not underestimate the amount of that user group - hence why we initially went with that. It wasn't an uninformed decision, we took this intermediate use over the majority use - where an assumption was made that the experience wasn't hurt too much in balancing both cases. We could be wrong there.

Yes I'm aware of that. Yes it's a long distance to travel, but I don't think your case is the common case. You're an expert user that uses URL's most of the time, and you're on a 13 inch laptop.
If you need to expand and collapse that frequently, there's a larger problem at hand. I also think the problem your having may be an artifact of having an unsolved solution for shortcuts. At present, node/add is the only meaningful item in the shortcut bar for you. Had there been a solution for adding more meaningful items into the bar (as there is now), perhaps you'd be less apt to close it so frequently.

I'd be open to other solutions, but I'm immediately at odds with this design because I need to brand the bar and cant.

I don't disagree with the branding. Ease of use definitely comes first. I also won't disagree with 13' or 8-10" - I just don't believe that's the normal case. If it were, the web standard would be back to 800X600.

There were two problems identified in this thread:
1. accidental click of logout
2. not enough meaningful links to warrant the loss of real-estate. The distance you have to travel was also mentioned, but that problem is an artifact of having a lack of meaningful links.

Issue number 1 is easily solved with space
Issue number 2 is solved by allowing users to customize and make the bar meaningful.

I just think we prematurely moved the toggle, and as a result have a toggle an in unconventional place that will A) take prominence away from primary tasks B) make personalization harder. Instead we said, "since the links are meaningless, I need a faster way to expand and collapse"

I have to say that having actually played around with this the past few days I do find it quite awkward and it might be worth rolling this back and/or coming up with another solution.

The shortcut bar collapsing icon is ridiculously prominent now, and it pushes the primary IA links, where my attention is *supposed* to be, off to the right where I never see them. As a result my eyeball does this:

Those are in exact reverse over of their intended prominence.

And now, instead of accidentally clicking Log out when collapsing the bar, I now accidentally click the collapsing bar when I'm trying to click Content, which is not exactly a better situation, since I click Content far more often than I collapse/uncollapse the shortcut bar.

Over at #540282: Accessibility improvements for the toolbar, the collapsed/uncollapsed state of the shortcut bar moves to a session variable, which would hopefully satisfy the people who really REALLY REALLY want this to be collapsed all the time.

Catch, what do you think?

Well, I want to be collapsed all the time when moving around the site (and a session variable would help with that), but I also want to be able to click node/add with less movement than clicking on the address bar and typing, otherwise it's not a shortcut for me

If we allow people to collapse the toolbar, which has been in the design from day one, then it's quite obvious that people going to want to use that, and having several centimetres from everything else you want to click in the toolbar is a long way. So moving it back really doesn't help here.

One thing I experimented with, but don't have the js chops to mock-up, would be a larger hover area, where the toolbar expands or collapses when you mouseover it, then maybe an icon to lock it in position. Same as AWN for linux, or how I imagine the OSX one works (never used OSX though). Another option would be to allow the toolbar to be collapsed horizontally as well (again, various linux taskbars allow you to do this), so it's off-screen entirely apart from a small clickable area (on a 960 site this would be outside the normal viewport of the site itself, but still very accessible in top left/right corner), but can be brought back easily when you need it.

I also find it really, really unlikely that people who need to look at the front-end of their sites often (anyone doing development, anyone doing content moderation, anyone with admin privileges on a site they also use, like Drupal.org) would keep the toolbar expanded all the time while doing that - since it's intrusive during normal browsing - but that's also the situation were you might want to go to node/add real quick to post content.

Still think it comes down to content. If the bar is filled with meaningful links, you'll be less apt want to close it. I'm hopeful that Gardens will open Drupal up to a lot of new users, and I'm certain those users will not collapse the bar at the frequency you do.

I like webchicks idea to move logout/help, and I also like the idea of the OSX shelf that reveals itself on hover. In situations where a toggle is needed however, I'd still advocate for the right side vs left.

Having this as a mouse over toggle only wouldn't be good for accessibility, typically users who are not using the mouse to navigate (navigation with TAB key for example), won't be able to toggle it (unless #540282: Accessibility improvements for the toolbar finds its way to core, then they could use the link to toggle I guess, if it's not an unaccessible link).

Moving "Help" doesn't convince me, I'd usually search for the last menu item of the main menu of an applcation to find the help link, not the right top (that's where I find the "X" to close my application... that's also why "Logout" is at the right spot there).

If the toggle ends up going on the right again, I suggest we should add some more space between it and "Logout", because the accidental logouts are really annoying... I would call that useful waste of space in this case.

catch,webchick> The status of visibility (collapsed/expanded) was always stored accross pages in a cookie (with Javascript ... and with #540282: Accessibility improvements for the toolbar, it's also stored through PHP when the toggle is used without Javascript).

The toggle button itself is quite big, we could look into scaling it down a bit as well.

I'm not sure if it's fair to throw in mobile platforms to support an argument here, I don't get the impression that 'make it work on an iphone' was part of the requirements for Seven.

Either way, I'm fine with rolling back and looking into other solutions.

Ok. I have reverted the previous patch. I agree with catch it makes sense to continue discussing this here since all of the relevant parties are subscribed. So let's take another stab at this.

I can't tell off-hand how the Ubuntu screenshots are supposed to work, but I don't think I'm opposed to having the toolbar slide in/out from the side. We should get Mark and Leisa's feedback, though.

Ok, here's a first take on this and few things to know about this patch :

1. This is a rough implementation of the ideas I have read in here and also adapted to what I think would really work.
2. I dropped the toggle for shortcuts visibility... I do not think it would be wise to have an hover effect for the whole toolbar AND a show/hide effect for the shortcuts inside it... now the space shortcuts take is not that much of an issue since we hide the whole thing when the user did not dock the toolbar.
3. I dropped the shadow of the toolbar because it does not fit with the current implementation in my opinon.
4. The toolbar, when undocked, is not going over the content of the page, this is an choice I made... I do not think it be a good idea to push the content of the page up and down each time we trigger the visibility of the toolbar... it is a possibility, but I do not like it.
5. I added a jQuery plugin called hoverIntent, it's under GPL and MIT (we can choose which of those two licences we want to use, so we'd choose the GPL). It is used to avoid accidental triggering of the new hover effect. I added it in /misc/jquery.hoverintent.js, it follows the logic of jquery.cookie.js which was also added in /misc/ when the toolbar started to use it... and this plugin might very well be used in other places in core if we decide to use hover for other things, it avoid problems when you move your mouse quicly over the triggering element (jQuery queues the mouseOver/mouseOut actions immedialty if you use .hover(), with .hoverIntent() the mouse mouvement is tracked and the actions are triggered only when you really intend to do them).
6. The "Dock toolbar" and "Undock toolbar" toggle is an anchor, it is added through Javascript because I do not see how it would be useful for the moment to have it as HTML, because right now, without Javascript the toolbar is docked by default, this avoid presenting an inaccessible (with the mouse) toolbar... that is part of the graceful degradation (if it has to be improved because there are visually impaired users who still use Javascript, we can do it in #540282: Accessibility improvements for the toolbar in my opinon).
7. The place of "Dock toolbar" and "Undock toolbar" toggle should be discussed, we might have the exact same problem if we place it at the top right, and if we place it at the bottom right it will be visible when the toolbar is collapsed. I did not push this too far right now because, most likely, it will be an icon at some point so I leace the design gurus give their opinons about how this should be achieved.
8. Screenshots attached are showing how it would look with (and NO I cannot make screenshots previews because of #561680: 'Trusted' drupal.org role with same perms as documentation. Please HELP!):
   1. Toolbar when Javascript is not available (note: no docking feature, all the links are visible, it take space ... it's graceful degradation).
   2. Mouse over and mouse out (it's the same) of the toolbar when it is docked.
   3. Mouse out of the toolbar when it is undocked.
   4. Mouse over toolbar when it is undocked.
9. Just so you know, this patch is not intended to be commited as is (I tried to take care about coding standards, but I am a bit in a rush so I'll do that later). I'd like to be sure that we are all on the same page for the concept of that hover effect and the dock/undock feature.

Anything else to do besides applying the patch to test this? I'm getting a half-visible shortcut bar without the top level menu items.
Hiding the top level menu items is a bad thing and, afaik, the discussion is about the shortcuts, not the top level IA menu items?

My install now looks like http://drupal.org/files/issues/555712-toolbar-docking-1-js-undocked-mous... and I don't see how I can make it show again.

Ok, after talking with yoroy and catch on IRC, here's another alternative (I'm not convinced yet that we cannot hide the whole toolbar). So with this one only the shortcuts are hidden and I added a dock/undock icon on the left most of the shortcuts. The icon used could very well be changed (it's under CC licence which is not compatible with GPL afaik) and it should be included in the toolbar.png that regroups all the other images related to the toolbar, but this shall be done if this alternative is the one chosed by the majority and also when the right icon will been found. The icon path is attached and should be placed here /modules/toolbar/toolbar-dock.png.

The trigger to display the shortcuts is achieved by hovering the main menu of the toolbar (in fact, any part of the #toolbar, which allows to keep it open even when you are outside the main menu). Unfortunately there is no visual hint for this... so I also changed the default behavior... by default the shortcuts are docked, if the user needs space he can click the anchor and they will disappear as soon as he moves his mouse outside the toolbar and reappear when the mouse is over the toolbar again.

I also re-added the shadow, yoroy was concerned that this wasn't the purpose of the issue to remove it, but it still find it ugly, even more when it is animated.

Some screenshots attached to show these changes, but as this relies on animation, you're always better of testing it live ... and please do not forget to clear Drupal's cache after applying the patch. One thing you won't see on the screenshot is that dock/undock toggle changes of background color when it is hovered. In the screenshot with the docked toolbar, the background color is also different so we are aware that it is "active".

sun> Well then.. is that +1 for the alternative solution in #67 ? Or you mean that it should even be hidden in a settings form instead of dirrectly accessible on the left of the shortcuts ?

A permanent cookie sounds ideal for this one - doesn't really matter if it gets lost, but good to keep it around as long as possible.

The last submitted patch failed testing.

The last submitted patch failed testing.

This is great. I only tried this for a few minutes to get screenshots, but makes things a lot easier.

The last submitted patch failed testing.

On Bojhan's advice, a version of the patch that only includes the cookie persistance across sessions (a.k.a after logout and/or session expiration). I post it here, as it also improves the toolbar collapsing efficiency and I don't see why I should create another issue only for this. We can always commit this one and continue the discussion about toolbar collapsing efficiency later.

To test it, you should verify that if you collapsed the toolbar it still stays collapsed across pages and then test if after a logout and re-login it stays in the state (collapsed/expanded) it was before logout.

Re-rolling the patch in #80 with hover toggle because of #609100: Should not be able to re-add same shortcut to same set twice.

The other one in #81 still works and is still waiting for reviews and tests.

I applied the patch in #83 and it worked fine.

Shouldn't most of these changes be in the "Shortcut" module, not the "Toolbar" module though?

The attached patch & the shortcut.png file moves everything except the changes to toolbar.js into the shortcut module instead. I'm going to move those javascript changes as well to a new file "shortcut.js" but I wanted to get the ball rolling towards moving everything into the right module.

Note that this patch no longer requires the toolbar-dock.png

TheRec requested that failed test be re-tested.

Also re-rolling the small patch which might not need to be re-rolled, but as it is the one you should review first (it is a really short one that give a longer life to the cookie storing the drawer visibility state). Test procedure can be found in #81.

This seems like a great compromise. :) Though let's definitely revisit discussion on other possible "docking" mechanisms (backed up by user tests, naturally) for D8.

Committed to HEAD.

Eh. I'm not sure about moving a 92-reply issue that's gone back and forth at least 3 times to D8 to continue discussion. It seems like starting a fresh issue about optimal docking mechanisms, cross-posting some of the useful mockups/patches over there, would be more effective. Though hey, it's not my itch, so do what you want... ;)

I think that most of the inputs in this issue are relevant and I'd have troubles to select only some. Fact is, all the solutions we investigated could still be used (providing we'd re-roll the patches of course), it's just a matter of knowing if they are usable or not (or if they are more efficient than the current solution). So I'm ok with continuing here.