In the 7.x toolbar module, I had the menu items (top level only) and the shortcuts visible at the same time.

In the current 8.x toolbar, I have to choose whether I want shortcuts or menu.

To me this is a UI regression, because (a) I can't see both at the same time and (b) it takes me more clicks to get to what I want to get to, if I happen to have the wrong choice visible at the moment.

Also I would wonder whether the average non-developer user would understand the distinction between shortcuts and menu at all? When I create sites for clients, I would want to set up shortcuts and have them always visible for the common admin tasks. If they go away when they click "Menu", it kind of defeats the purpose of having set them up with the shortcuts in the first place.

Comments

Bojhan’s picture

I see no way to solve this, other than a radical change in the design. This is a decision in the design, which causes the regression - as we make large changes, some changes will have a negative impact. However this is more suitable to be responded upon by tkoleary and/or others involved in the design.

jhodgdon’s picture

Well, I'll just say that this one change is enough of a regression that in sites I build for clients I would definitely consider contrib alternatives, or going back to what I used to do in Drupal 6 (creating an "Admin Links" Menu, and displaying it on the sidebar for logged-in admin users). In Drupal 7 I could get by with just using shortcuts for the "common admin links" use case, but in 8 I don't think Shortcuts will be good enough if they are not always visible.

So... Let me just be clear -- here is my use case story:

Jennifer is an experienced Drupal site builder. She is setting up a Drupal site for non-profit ABC.org. Various people with little web-editing and no Drupal experience will need to do various tasks on the site, such as editing blocks, locating and editing content, etc. Most of them cannot be expected to find the tasks they need to do in the admin menu system, so Jennifer wants to set up shortcut links for them for the most common tasks. The links need to be readily available (always visible in an obvious location). One more advanced user at ABC.org (as well as Jennifer) will also need access to the full Menu.

This use case story is not well satisfied by the current design, because (a) I have to click something to even get the "shortcuts" to be visible, and they are hidden if the menu is visible (b) I don't think choosing "shortcuts" vs. "menu" is intuitive to inexperienced users (c) most users would be confused by the menu, even if limited to what they have permission to do.

chris_h’s picture

Perhaps there should be a way to configure what's in the top level nav in the same way you can the secondary items - as a menu.

jhodgdon’s picture

Yeah, that would be good. The current top level is practically useless IMO. If I could put the shortcuts there, it would be more useful. As it is, there are just a couple of links there, which would probably fit just as well in the 2nd row... Previously the first row was the menu (yes, drop-down is better than buttons, but I don't even have that in horizontal mode, which is a separate issue though), and the 2nd row was the shortcuts, and both visible. Now the first row is pretty much nothing.

Bojhan’s picture

I see no way to fix this other than a radical change - which basically turns it into our old toolbar design with just a position change. I doubt that's desirable and/or repeatable to the vertical version.

Again, asking for tkoleary to look into this - as I have no idea, why we removed the shortcuts from initial sight.

jhodgdon’s picture

The thing is, shortcuts are kind of dumb in the vertical alignment (since they don't have sub-items like Menu does). So how about just adding them to the top (black) bar, which is pretty just wasted space in the current Toolbar?

tkoleary’s picture

It's possible that this is an issue but let's see if it comes up in testing before we act. My assumption has always been that the user who clicks on shortcuts knows that they have bookmarked something (or had it bookmarked for them) and the user that clicks menu is making an explicit statement that there is no shortcut to where they want to go.

yoroy’s picture

@tkoleary: I don't understand the distinction you are making. Consequently I also don't understand how that assumption justifies removing shortcut functionality. Can you elaborate a bit?

yoroy’s picture

Issue tags:+Usability

doh, tagging

tkoleary’s picture

Ok so I'm thinking through this and I see that there are issues but I don't think they are the ones uncovered above. Given Jhodgdon's hypothetical:

"Jennifer is an experienced Drupal site builder. She is setting up a Drupal site for non-profit ABC.org. Various people with little web-editing and no Drupal experience will need to do various tasks on the site, such as editing blocks, locating and editing content, etc. Most of them cannot be expected to find the tasks they need to do in the admin menu system, so Jennifer wants to set up shortcut links for them for the most common tasks. The links need to be readily available (always visible in an obvious location). One more advanced user at ABC.org (as well as Jennifer) will also need access to the full Menu.

This use case story is not well satisfied by the current design, because (a) I have to click something to even get the "shortcuts" to be visible, and they are hidden if the menu is visible (b) I don't think choosing "shortcuts" vs. "menu" is intuitive to inexperienced users (c) most users would be confused by the menu, even if limited to what they have permission to do."

...we have three personas, 1) the administrator (Jennifer), 2) the more advanced user (let's call her Barbara), and 3) the inexperienced non-technical user (let's call him Kevin).

The best-practices scenario is:

  1. Jennifer builds the site and creates a role for Kevin called "content author".
  2. "Content author" does not have permission to see the menu but does have permission to see the rest of the toolbar.
  3. Jennifer creates two shortcuts for Kevin "Blocks" and "Content".
  4. Jennifer enables the shortcut set for Kevin
  5. Jennifer creates another role called "Editor".
  6. The "Editor" role has permission to see the menu.
  7. Jennifer gives Barbara the "editor" role.
  8. Jennifer enables the shortcut set for the Editor role.

Now:

  1. Jennifer sees the full menu and can keep it open at all times because it persists through a page load
  2. Barbara sees the menu and the shortcuts and can toggle back and forth between them
  3. Kevin sees only the shortcuts and once he has opened them he can leave them open

The implications of this are:

  1. We need to remember the last state of the toolbar per user and reload it (this is already done with cookies but fails if the user changes device)
  2. Menu permissions need to be set independently of toolbar
  3. We should probably allow permission sets to be enabled by role
  4. We should add roles like the ones above to the default set and apply smart defaults to them (I am already working on this)

I think that #2 is most important. We need to have more granular permissions that at least allow the admin to select which top-level toolbar tabs are available.

jessebeach’s picture

The top black bar has become more of an application control bar. It allows modules to expose a top-level tab, or even a more complex piece of functionality, like a search box or dropdown menu. The "tabs" are accounted for as a basic UI component of toolbar. Anything else is custom and needs to be controlled by the implementing module.

benjifisher and I are discussing how to improve the dx of hook_toolbar here: #1847198: Update the structure returned by hook_toolbar()

The issue above also have several use cases we're considering. Please add more and we'll take them into account.

Technically, we could pull the shortcut list into the administration bar and out of a tray. My concern is one of layout. It's difficult to know when to down-step the layout from a horizontal list to a dropbutton before the list ends up wrapping due to lack of space. If a user adds 10 shortcuts, the list will most likely end up wrapping somehow. We just need to think out what a design does at the margins of available screen space. I'm sure we can technically achieve almost any design.

jhodgdon’s picture

RE #11 - that use case of it being an "application control bar" is only really good for advanced site-builder types of users (the "Jennifer" persona in #10). In fact, it makes the situation even worse for users of the "Kevin" persona, IMO.

pjcdawkins’s picture

@#10

  1. We need to remember the last state of the toolbar per user and reload it (this is already done with cookies but fails if the user changes device)
  2. Menu permissions need to be set independently of toolbar
  3. We should probably allow permission sets to be enabled by role
  4. We should add roles like the ones above to the default set and apply smart defaults to them (I am already working on this)

Points 1 and 2 make a lot of sense.

Permission sets wouldn't be specific to Toolbar at all. Default sets of complex permissions sound like they could cause a lot of needless arguments and it would be difficult to work out what would satisfy the majority of users. Unless I've misunderstood the scope of what you suggest in 3 and 4 they don't really sound like Core issues.

tkoleary’s picture

@pjcdawkins

Permission sets wouldn't be specific to Toolbar at all.

Yeah that's correct. It really should be a separate issue anyway. And in any event it requires more thinking on my part. I will pull that back into sandbox till I have it more well baked.

David_Rothstein’s picture

Priority:Normal» Major

I'm bumping this to major because #1847116: Provide users with an easy-to-access action to create content from the toolbar was originally supposed to be a major followup of #1137920: Fix toolbar on small screen sizes and redesign toolbar for desktop; however, I think this issue identifies the root cause.

I'm wondering to what extent it's possible to have the "desktop" (i.e., horizontal) version of the toolbar look more like the one in Drupal 7... (Conceptually, that would be similar to the current D8 implementation except with some of the menus having their contents spilled out into the top bar.) The vertical version of the toolbar would stay as it is, but I think it's OK since the vertical layout is more targeted for mobile users and there's only so much that can be done with a small screen. But I think it's a problem that we introduced this regression for desktop users.

tkoleary’s picture

@David_Rothstein

I'm wondering to what extent it's possible to have the "desktop" (i.e., horizontal) version of the toolbar look more like the one in Drupal 7...

In order to validate that this is in fact a usability regression we need to see test data. Dharmesh will be re-testing the toolbar sometime in the next month and if at that point we see that this is indeed a problem, we can address it with a revised design (this type of UX fix is not bound by freeze AFAIK).

jhodgdon’s picture

RE #16 - it may not be a usability regression for the average new-to-Drupal user that you will (I assume?) be testing in your usability tests (and I apologize if that is not the correct assumption about the upcoming usability tests, but I think that is the type of user who has typically been involved in Drupal usability testing, right?).

But it is a major usability regression for people like me. See comment #2 above for my user story. I think/hope my "site builder for clients" use case is just as valid as the "new user" persona? Otherwise I would not have filed this issue in the first place.

tkoleary’s picture

@jhodgdon

I see that this is an issue for you and other power users, but I believe the toolbar is extensible enough for a user like you to configure it just as you want.

For the new user I feel—and have always felt—that shortcuts are a kludge introduced to paper over poor navigation patterns and information architecture. We have already gone a long way towards improving the interaction pattern and Lisa Rex will be spending time on the IA (your help in that area would be much appreciated).

Also, there is another proposal which I believe solves this power user issue much better than shortcuts if we can get it in to core: https://drupal.org/project/commandbar

jhodgdon’s picture

RE #18 - how exactly can I configure it to satisfy my use case in #2? I haven't tested D8 in a while, but when I filed this issue there wasn't a way for me to use the core toolbar the way I could in D7. Please explain...

jhodgdon’s picture

Anyway, this issue *is* about the "power user" UI regression. Please do not hijack it to be about anything else besides what is in the title: that shortcuts and toolbar are not visible at the same time, as they were in D7. File a separate issue if there are other usability problems.

tkoleary’s picture

@jhodgdon

I certainly didn't intent to hijack the issue. My intent was to abstract the issue from a request for a specific implementation change to a discussion about the user need that does not confine itself to a pre-determined conclusion about how and where that need can be best met.

I would define the user needs as:

"As a regular user of Drupal I want to bypass the menu tree and rapidly access specific content or administrative interfaces"

and

"As a regular user of Drupal I want a set of links to content or interfaces I commonly visit"

and

"As an administrator of a Drupal site I want to create a set of administrative links for a specific type of user"

Commandbar fits the first use case much better than shortcuts IMHO. The second is covered by shortcuts but the issue is that the user needs to open them. My personal view is that this is not an issue since the bar persists through a page load so it only needs to be opened once per session, but even if an administrator considered that a problem they could simply add links to the top level of the administrative menu, which covers the third case (but not the second because they would not be per user shortcuts, just links)

A module developer can also specify new top level tabs in the toolbar which covers the third case in a more holistic way. For example if commerce wants to make a "cart" tab that shows a menu of commerce related links in the tray they can do that.

The only issue I see that blocks you from configuring a site to fit your use case is that the user cannot add user-specific links to any menu, only to the shortcut menu. If we added the parent field to config/user-interface/shortcut/link/* that would solve that, but I don't know if it's trivial or not.

There are also two other things that might help this a bit. One would be if we made the state of the toolbar persistent across sessions per per-user, so If I had the shortcuts open and logged out and back in, it would still be open. The other is if we made the top level of the toolbar collapsible, which would then give you pretty much what you have in 7.

I would not be opposed to any or all of those three.

jhodgdon’s picture

I repeat... This issue is specifically about the fact that the core Toolbar and Shortcuts module in D7 satisfied this one particular use case of mine, and in D8 it doesn't. The title says it all. I realize there are many other methods for satisfying this use case, including using contrib modules, making menus, etc. But this issue asserts that the D8 changes to these two core modules made this particularly straightforward core method of providing links across the top of the screen, which worked fine in D7, not viable in D8.

End of story for this issue. If there are other usability concerns, file separate issues.

And perhaps the correct response to this issue is "this is the desired D8 behavior and you have to go use a contrib module now to accomplish this". If so, the correct response is to mark this "works as designed" not to use this issue to address other unrelated usability concerns. OK?

klonos’s picture

jessebeach’s picture

@klonos, that's totally cool to use a contrib module to meet your needs. I know we had very high expectations for core, but it seems we're always going to fall short of achieving them given the long development cycles for big changes.

@jhodgdon, I recognize the regression. We ended up trading this behavior for a menu bar that displays well on screens from 100px wide to many px wide. Fundamentally, I'd love to introduce the behavior described here into Toolbar. Practically, we sorely lack front end developers who step up and build these things. What this issues needs now is a patch, no? If you find someone to put forth a proposal, I'll look through it and offer guidance.

jhodgdon’s picture

@jessebeach: Do you have any guidance on whether this is even possible? I mean if the UI/UX people have decided that supporting Mobile is more important than this particular regression, and the two are incompatible (I don't have any ideas myself on how to keep the new behavior, which I hate anyway, while retaining the old behavior, which I used all the time)... Maybe the correct response is just to close this as "works as designed", sorry, go use a contrib module?

I think that is an acceptable response. There are always tradeoffs in development, especially in user interfaces, and I fully understand that mobile is important these days, although neither I nor my clients tend to use it to manage a complex professional Drupal-backed web site. Perhaps that is because it hasn't really been feasible in the past though? Anyway I know that when I'm managing a complex site, I like having a large window to work with.

So really... Do you think it's possible to support the mobile use case that was deemed to be more important, and the use case outlined in this issue, with one UI? If not, let's just close this down and move on, and I'll investigate contrib modules for D8 like CommandBar or whatever.

But really... All I was trying to say here on this issue was that in D7, you could have both menu and shortcuts visible at the same time -- there were two ribbons across the top. In D8 you cannot, even if you are on a nice big browser window. I don't really understand why the new situation is better for anyone -- as described on the other issue referenced by klonos in the previous comment, it takes a lot more clicks to get anything done in the D8 toolbar than it did in d7. It's annoying, and if D8 ships with this mess there is no way I'll be using it.

Thoughts?

klonos’s picture

Status:Active» Closed (works as designed)

I think that we are all in agreement here and there's no point debating over this, so I'm pretty sure that if I don't do ahead and mark this as 'works as designed', somebody else will. As you both put it very well this is why contrib solutions like admin_menu (my personal favorite) exist.

Now, for those like me that like to jump into conclusions by examining stats:

- In D6, a bit over half installations used admin_menu
- In D7, that percentage drastically dropped to ~25%. I personally translate this fact as core toolbar.module success (either that or people are too lazy to look for alternatives to the defaults being fed to them).

Perhaps the only thing to do is watch how that percentage evolves during the D8 cycle and then we'll know if we did a great or crappy job. Since by then it will be to late to react, people like me will be able to once again jump into conclusions about whether most people care about doing admin work on mobile or actually getting around the admin UI as fast as possible :D

jhodgdon’s picture

klonos: just to be clear, admin menu does *not* cover the use case of "have the shortcuts and menu visible at the same time on the toolbar" as far as I know, so it's really not relevant for this issue.

The point of the shortcuts in the user story for this issue is that less experienced users are overwhelmed by the choices in the main admin navigation (whether in the form of the toolbar buttons of D7 or the admin menu module -- the only main difference there being whether it drops down or not). So the shortcuts are useful to provide one-click links to their usual tasks. I am not aware of admin menu doing this.

David_Rothstein’s picture

Status:Closed (works as designed)» Active

So really... Do you think it's possible to support the mobile use case that was deemed to be more important, and the use case outlined in this issue, with one UI?

No, but we don't have to. The toolbar already has two UIs (horizontal and vertical). It makes sense for the vertical layout to be optimized for mobile, but the horizontal layout should be optimized for wider screens. Especially because it already is (on narrow screens it already breaks, and the code even forces you to use the vertical orientation in that case unless you specifically re-choose horizontal).

That doesn't mean thinking about desktop only either... as the viewport gets narrower, if there's not enough space to show all the links we want to show, we could still collapse the shortcuts at that point. I even had some prototype code (granted it was ugly) in the original toolbar issue that did this.

David_Rothstein’s picture

Also, although not directly related to this issue, the user menu is another one that would be good to "uncollapse" when possible. (That's because the placement of the "log out" link in the toolbar tray on a wide screen is very unusual; it winds up about 20% from the left side of my monitor, which is definitely not where I'm used to seeing log out links on most websites.)

jessebeach’s picture

@jhodgdon, sure sure, I think we can do much to bend the code in clever ways and get improved behavior. When I first saw this issue, I had the idea to allow the shortcuts tray to exist in a horizontal layout if any other tray were open in a vertical layout. Something like this:

Wireframe showing the menu tray open and docked to the left edge of the screen. The shortcuts tray is open and docked to the top edge of the screen under the admin bar.

We would alter the behavior of the Shortcut module JavaScript. I could describe the intervention points in the code to an interested developer in 15 minutes.

I think it's also good to keep in mind that in addition to the responsive layout behavior of Toolbar, the Drupal 8 version is also a container that other modules can plug components into. Edit and Tour module do this already. Responsive Preview takes advantage of this plugability as well. I know of one distro using the Navbar (D7 version) that puts a tab into the toolbar area. The D8 Toolbar is an extensible application bar. The behavior being described in this queue is probably an enhancement to the Shortcut module. One would need to alter this module in contrib, not Toolbar.

klonos’s picture

StatusFileSize
new79.82 KB

@jhodgdon, #27:

just to be clear, admin menu does *not* cover the use case of "have the shortcuts and menu visible at the same time on the toolbar" as far as I know, so it's really not relevant for this issue.

... I am not aware of admin menu doing this.

Yes it does (though not enabled by default) and thus yes it is relevant:

admin_menu_shortcuts_support.png

jhodgdon’s picture

Good to know klonos, thanks! I haven't used Admin Menu since D6, since the toolbar/shortcuts solution was working well for me in sites I developed for others. :)

@jessebeach... So now I'm confused again. Are you saying I should not be able to get to a situation where the menu and toolbar are both displayed across the top without having to click anything, as they were in D6, if I'm on a big browser? What I'd like is to be able to turn off the worthless (on a big browser) Home/Menu/Shortcuts button line, which takes up space while adding zero value, and instead display the menu horizontally across the top and shortcuts right underneath, with no clicking, just like it was in D7. Or at least have that be an option.

jessebeach’s picture

Are you saying I should not be able to get to a situation where the menu and toolbar are both displayed across the top without having to click anything, as they were in D6, if I'm on a big browser?

@jhodgdon, if we prioritize the display of the main menu and shortcuts, then we need a design that provides a means to accomodate tabs from contributed modules within that framework. Does that make sense? I agree that the big, ever-present menu bar at the top of the screen adds little value straight out of core. I for one welcome alternate designs that maintain flexibility for contributed modules to plug arbitrary HTML into the Toolbar and short-circuit access to menu items while also providing the opportunity to apply standardized styling and behavior. I'm not trying to be flippant nor am I trying to bluster. What we need now are wireframes that begin to get at how we keep the flexibility we have and that also accomodate the presentation requested in this issue. I don't have the time to lead this effort, but I will pledge time to provide constructive input to ideas that move us from discussion into design and then coding. But I implore that we can't backtrack on the plugability of the toolbar. I also fully acknowledge that we can improve the design. I mean, it's already 7 months old. It's one of the older pieces of code in Drupal 8 at this point!

jhodgdon’s picture

OK... here's an idea for how it could potentially work -- just a brainstorm:

There could be a little "configure" wheel in the Toolbar area.

If you clicked the configure wheel, you would have the opportunity, for each widget/tab/whatever they are called that is made available by core and contributed modules, to choose between:
- Off
- Horizontal
- Vertical
- Responsive
This would be a per-user configuration. Ideally I would be able to drag the widgets around to change the order too.

One of the widgets you could configure could be the "Chooser" (by which I mean the current thing that has buttons for the Menu, Toolbar, and other widgets/tabs/whatever they are), which I could then disable, and I could set both Menu and Toolbar to be horizontal, thereby making me happy without destroying the default mobile-friendly design.

Does that make sense? I'm not any good at making UI mockups...

jessebeach’s picture

This would be a per-user configuration. Ideally I would be able to drag the widgets around to change the order too.

Configuration is indeed missing. Really, I'd love love love for us to get this level of personalization into the module. To anyone following this issue who has the inclination to put together a wireframe, please do, so we can start hashing out details. @jhodgdon's description in #34 is a great place to start.

jhodgdon’s picture

Are there any good open source tools available for Ubuntu that are good for making UI wireframes? Libre Office Paint and Gimp are about the pinnacle of my graphics expertise, maybe Inkspot on a good day... Any suggestions?

klonos’s picture

The Pencil Project is...

An open-source GUI prototyping tool that's available for ALL platforms.

(There's even a firefox extension!)

jhodgdon’s picture

Looks interesting... Have you used this Pencil Project software? I'm always a bit wary of installing software and/or Firefox extensions that are not in the official Ubuntu/Mozilla repos (you never know what they could be doing to/with your files/data unless you read the source code, and who has time?). This one is not in either official spot.

klonos’s picture

Well, I'm currently using it on Windows and this far I never needed it in my Ubuntu Desktops. I guess being a XUL app will make it look and feel just about the same in either environment, but I cannot vouch for the things that seem to be of concern to you like reading its code for example in order to know what it does under the hood - if I did that for every application or OS I use, I'd be speaking assembly now :P

I guess if you want to go the safe way you can create a separate firefox profile and install only the pencil addon. If you are not happy with it, simply delete the respective firefox profile ;)

jhodgdon’s picture

StatusFileSize
new51.62 KB
new71.71 KB

OK, your endorsement was enough. I tried it out and here is a mockup; have attached a PNG file as well as the Pencil source (the file extension should be ".ep" but I put .txt afterwards so I could upload it) in case someone else wants to edit it to make it better. It's a bit rough but I think you'll get the idea...
Mockup of UI described in comment #34

jhodgdon’s picture

StatusFileSize
new9.7 KB

Here's the SVG also which seems to be complete except it is missing the text in the yellow balloon box.

WHAT? we cannot upload SVG files. OK, zipped SVG. :)

klonos’s picture

Ok, and what would having both shortcuts and menu visible look like in this mockup? Would the horizontal menu lines stack in parallel on top of each other? I guess that this would then mean changing the current behavior in order for menus to be "sticky" between clicks...

Before:

1. Click on "Menu" -> Have the menu line show up below the toolbar
2. Click on "Shortcuts" -> the menu line is replaced by the shortcuts line
3. Click on "Menu" again -> the shortcuts line is replaced by the menu line
4. Click on "Shortcuts" again -> the menu line is replaced by the shortcuts line

After:

1. Click on "Menu" -> Have the menu line show up below the toolbar
2. Click on "Shortcuts" -> the shortcuts line is added below the menu line
3. Click on "Menu" again -> the menu line is hidden while the shortcuts line is still shown below the toolbar
4. Click on "Shortcuts" again -> the shortcuts line is hidden too

Does that sound right?

jhodgdon’s picture

Good question. I don't think what I drew/described does make sense, because I think you should either use the Chooser to select what is visible, or you should use a static configuration

So, the choices in the Config box should be first:
a) Use Widget Chooser
b) Use static widget configuration

If (a) is chosen, you get the current D8 behavior, where the Chooser selects which widget is visible and it adapts in placement to the screen size etc.

If (b) is chosen, more choices appear for configuration -- just like the mockup I did in #40 (except that Chooser would not be one of the widgets to configure -- you would just configure visibility for the rest of the available widgets).

Does that make sense? I can't make a mockup right now... maybe Monday if no one beats me to it.

klonos’s picture

What is the Widget Chooser?? Is it a module?

jhodgdon’s picture

Oh sorry! That's just the name I made up for the bar with the Home, Menu, Toolbar buttons on it (the buttons that currently let you choose which "widget" is visible, which is another name I made up because I think they're not really called widgets here?). A better name should probably be chosen for the "widget chooser".

klonos’s picture

ok #43 now makes sense ;)

jhodgdon’s picture

StatusFileSize
new58.42 KB
new65.59 KB

OK, here's a new UI mockup. I've used the name "Toggle buttons" instead of "Toolbar chooser" since it is probably more obvious what it means.
new mockup of toolbar configuration

jessebeach’s picture

Great stuff! So here are my naive impressions:

  1. What is a widget? What would a toggle button widget do? And static configuration?
  2. So in the case of Static Configuration, I would be selecting the Menu horizontally? Selecting something "horizontally" doesn't quite make sense to me. It's the flow of the language of the configuration that needs tweaking. "How to select Widgets" -> through "Static Configuration" -> and then "Horizontal". In this way, Horizontal wants to be an adverb, which doesn't quite fit.
  3. We'd need a way to rearrange the widgets in addition drag/drop, like through a weight value.

What if we took a more "desktop toolbar" approach, like the one that a browser uses, where there a slots that a widget can be placed in. So we'd have a horizontal slot and a vertical slot when screen real estate were sufficient. We'd need to come up with a way to present these elements in a narrow view. Maybe they'd all be vertical in a narrow view and the top-most widget in the list would take priority. This would be similar to what you've proposed, except that a user would just specify horizontal, they'd specify a region for the widget to appear in in a wide screen.

jhodgdon’s picture

Thanks for the feedback!

1. I don't know the right word to use. What do you call the "things that the Toolbar can display"? I have used the term "widget" here as a placeholder until I find out what they are supposed to be called. What are they, "elements"? "drawers"? I don't know what they are supposed to be called, and moreover, what they are called that would make sense to a user.

2. Definitely the UI text in my mockup definitely needs tweaking... I was thinking of this as a functional mockup (how I would want it to function) rather than the final UI design... Let's see:
- Probably "How to select widgets" should say "Select displayed elements" and the choices should be "Dynamically (display buttons)" and "Statically (configure here)" or something that gets this across. And then the Configuration sections should say:
* Shortcuts display:
-- Horizontal
-- Vertical
-- Adaptive
-- None

3. Yes, absolutely, we should use the standard "turn off weights" vs. drag-and-drop paradigm. I didn't put that in my rough sketch (yet).

4. I don't like the idea of having slots, not at all really. As soon as you say "you can only have one horizontal and one vertical slot", I am unhappy because I want both Menu and Shortcuts to display horizontally across my screen, and again my use case that prompted me to file this issue is not satisfied very well (I don't want something on the left moving my whole site over to the right). And if you say "you can have only two horizontal slots", someone else will be unhappy.

Can't we just have weights and horizontal/vertical placement, and have all "on" widgets/elements display one after the other in the desired/specified area? Is there a strong reason why someone couldn't have 10 horizontal bars across the top if they want to?

jessebeach’s picture

Can't we just have weights and horizontal/vertical placement, and have all "on" widgets/elements display one after the other in the desired/specified area? Is there a strong reason why someone couldn't have 10 horizontal bars across the top if they want to?

That makes me remember the days of IE and the extension bars: http://www.austinfree.net/wp-content/uploads/2010/12/01_Ask-web-page.jpg

I'm struggling to rectify the placement flexibility with displaying well across any screen size.

What if we just made the menu a special flower and gave it a dropdown behavior, so you could keep the shortcuts open all the time and navigate the menu through mousemoves?

jhodgdon’s picture

IMO, the idea of having configurable is to make it configurable, not to dictate what a "good" configuration would be. Right? I am not suggesting that anyone would actually want to have 10 horizontal stripes across the top of their site. But I personally want 2 for sites that I build (menu and toolbar, and get rid of those stupid buttons)... Someone else might have a different use case.

I think that if you let the person configure their toolbar, and they choose "horizontal" or "vertical" for certain of the widget/elements, then they give up the ability to have it adapt well to different screen sizes. Which is my exact use case: the people maintaining the site are *always* at work on their nice big desktop screens, and forcing them to use an inferior mobile-oriented design in this case is not very nice.

Anyway, you were the one who suggested it be configurable.... I just don't think someone can have both "I want the config to do what I tell it to do" and "I want the design to adapt to my screen". Maybe if it's set to "static config" we take out the "adapt" option and just have horizontal, vertical, and off?

jessebeach’s picture

I just don't think someone can have both "I want the config to do what I tell it to do" and "I want the design to adapt to my screen".

Right. At a minimum, it's really complex to accomodate both.

I think that if you let the person configure their toolbar, and they choose "horizontal" or "vertical" for certain of the widget/elements, then they give up the ability to have it adapt well to different screen sizes. Which is my exact use case: the people maintaining the site are *always* at work on their nice big desktop screens

The Admin Menu module does this, right? I think in this case, that might be the best option.

jhodgdon’s picture

OK. It sounds like you are wanting to go back to closing this issue as "works as designed". Which is OK with me, though I'll be a bit sad of course.

jessebeach’s picture

Which is OK with me, though I'll be a bit sad of course.

I'm sorry to make you sad :( There must be a solution. There always is. It's not jumping out at me.

jhodgdon’s picture

StatusFileSize
new74.23 KB
new86.74 KB

I am not seeing the problem with the proposal in #47:
- By default, the buttons are visible and whichever button you click, the appropriate toolbar element/widget appears in an adaptive fashion (horizontal or vertical), making the previously-visible one disappear.
- For users who want a static configuration, they can choose "static" and define which widgets/elements are visible and where.

Hmmm...

How about this? I think it would be simpler. Again, I'm not sure about the UI text...
Another UI mockup suggestion for the Toolbar

jessebeach’s picture

#55 is moving in a good direction. The tradeoff in this design is that you will not have access to tours, the in-place edit toggle, or user account actions, unless you add another horizontal bar for each of those.

jessebeach’s picture

Maybe we could keep the main toolbar with the tabs visible all the time, but really collapse it down like a crushed soda can when it's not in focus. That would make the other actions reachable without forcing them into prominence all the time

#1856672: Toolbar is too large and involves too much chrome: make it spacious on touch interaction, condensed on pointer interaction

One way to get at the "pegged" behavior faster would be to make just the menu and shortcut bars behave like this and separate out the configuration work. We'd just give both a "peg" toggle, maybe as a dropbutton off the side of the orientation toggle.

jhodgdon’s picture

I guess I need to fire up an updated Drupal 8 to test this out. Last time I tried the Toolbar (when I filed this issue), all it was presenting was buttons for Menu and Shortcuts. And in Drupal 7, the user account edit button was on the right side of the menu... is that not the case in Drupal 8, so it's now a separate widget/component/element? Sigh. Maybe the Toolbar module is doomed (as far as my use case is concerned) and I will just need to use klonos's suggestion of turning it off and using the contrib Admin Menu module.

(rant) I realize we supposedly need to "design for mobile first", but are people really going to be doing content editing and site configuration for the type of sites that Drupal is really useful for on a phone (i.e., I'm not talking blogs, but complex professional sites where you really do need Drupal)? I'd like to see the statistics on that. The sites I build for clients (business and non-profit), the people who are managing them are doing so during their full-time job workday. They are using computers with monitors, not phones, and if the toolbar is optimized for back-end usability on a phone and has terrible usability (many more clicks than was necessary in D7 to accomplish the same goal) when used on a desktop, and we can't fix it so that desktop users get the basic usability and functionality they had in D7 (plus the new features of D8), then there's always the off switch. (/end rant)

Pancho’s picture

Tried to read the whole thread, and hope I got it right, but I believe it's no good idea to provide a static configuration that overrides adaptive behaviour, meaning that you can have only one or the other.
We probably don't want to allow toolbar configuration sets for each screen size/orientation, but at least there should be one configuration set for horizontal orientation and another one for vertical orientation, IMHO.
Would probably be okay if the dialog for vertical configuration is available in vertical mode only and the horizontal configuration dialog in horizontal mode only. But configuring the toolbar to your needs on the desktop shouldn't completely bork appearance on your mobile.

jhodgdon’s picture

RE #59 - that is actually a very good suggestion.

So the idea would be:
- Have the Toolbar be adaptive (horizontal or vertical).
- Have a configure-wheel button.
- When you click Configure, you set up configuration (order and visibility of components) for the Horizontal and Vertical configurations separately. And if you have the Help module turned on, hopefully it would tell you what this means, something like

The Toolbar adapts to your browser size: it is displayed horizontally across the top of your screen when your browser is wide, and vertically down the left side when your browser is narrow. In this dialog, you can set the default toolbar components to be displayed in horizontal and vertical configurations.

The only problem is that I'm still not sure about in that case would be the "button bar" or whatever it is called (the thing that's currently what comes up in Toolbar, which presents buttons for Home, Menu, Shortcuts, Tour). What would you do with it, and is it necessary? If it's not visible, how can you access a tour?

And would we want to still have the dynamic/buttons vs. static choice for both horizontal and vertical configurations?

pjcdawkins’s picture

And would we want to still have the dynamic/buttons vs. static choice for both horizontal and vertical configurations?

I'm jumping in here with my two cents: the idea of separate horizontal/vertical configuration sets sounds like it's adding a lot more complexity. I would be more comfortable with something like configurable 'plugins', which know the Toolbar is responsive and control their own output to be appropriate for narrow/wide layouts. So if you had 5 plugins (maybe Menu, Shortcut, Tour, Search, Edit) in the wide layout, then all five are also present in the narrow layout (or "horizontal" and "vertical" if you like).

A central idea of responsive design is that there is one web[site]. All of the content, and all or most of the functionality, should be available on all screen sizes. I don't have much idea how all that can translate into visual design, but responsive toolbars including search, shortcuts, and menus are not unusual (e.g. look at the Facebook mobile site).

tkoleary’s picture

@pjcdawkins

I agree. The toolbar is already built to be responsive. In fact that's the reason we built it. Varying configuration based on position is ok if what varies is the presentation—we already do this by showing only icons in the top bar for smaller devices—but varying the content would indeed introduce an unsupportable level of complexity.

jhodgdon’s picture

OK... So is this whole idea and my whole use case dead in the water? If so, please can the maintainers of this module mark this "won't fix" and I'll just use Admin Menu as suggested above. I don't want to keep making suggestions and repeating my use case if it isn't one that the Toolbar maintainers care to support.

Bojhan’s picture

@jhodgdon I am not sure this is handeld correctly. Your concerns are real. Jesse promotes the idea of using a contrib for this, that is not actually a solution that is a work around. We introduced shortcuts to make them quickly accessible, defacto the new design decreases the importance of shortcuts. This issue can only be put on won't fix, if we conclude that decreasing the importance of shortcuts improves usability. You make a clear case that it doesn't, and following that we should change the design of the toolbar. Configuration is the same as using a contrib, a work around to the real problem.

I am interested in solving the real problem, making work around (like a UI to configure the toolbar) just creates UI overhead that people don't wish to deal with. Keep in mind most users don't actually involve themselves with customisation of the UI. A good read on this is http://www.uie.com/brainsparks/2011/09/14/do-users-change-their-settings/ and http://limi.net/checkboxes-that-kill/

jhodgdon’s picture

Besides de-emphasizing Shortcuts, my other concern here is that with the current design, it takes an extra click to do anything useful at all with the Toolbar, because the only thing visible when it comes up is a row of buttons asking me what I want to display.

So... here is yet another idea:
- When I first visit the site and log in, the toolbar is adaptive as it is now, and I see just the main Toolbar controller area (the row of Home, Menu, Shortcuts buttons -- I still don't know what this is called).
- Buttons for bar-type elements/widgets/whatever-they-are-called that can be displayed in Toolbar (Shortcuts, Menu, etc.) are toggles. So if I click Shortcuts and then Menu, both are visible, rather than the current behavior, which is that only one is visible at a time, and if I click a button a second time, the corresponding bar goes away. They just stack vertically one under the other.
- As I continue my browsing session, Toolbar remembers which "bars" are visible and keeps them visible until I toggle them back off by clicking buttons in the main Toolbar controller area.

By the way... What is the name for:
- The row of home, menu, and shortcuts buttons?
- The other bar-type things that can be displayed, such as Menu, Shortcuts, etc.?

klonos’s picture

I like the idea in #65.

tim.plunkett’s picture

Title:Toolbar UI regression: shortcuts and menu not visible at same time» Toolbar UI: shortcuts and menu could be visible at the same time
Category:Bug report» Feature request
Issue summary:View changes

This was a purposeful decision, to reverse that would be a feature request.

jhodgdon’s picture

I still don't see why a major regression in usability for what I think is the normal case of people who have a complex Drupal site to manage for their business or non-profit, from their office, on a Desktop browser, is not a bug.

But obviously the "we must have this usable from a phone" camp won out. Whatever.

dawehner’s picture

Technically it might also be a regression coming from Drupal 7. Using shortcuts is a great tool for authors, as it really speeds up their navigation on the side, as well as sitebuilders.

Even this was a decision before does not mean we should not talk about it and maybe change it. Iteration is a great part of our community.

jhodgdon’s picture

I would be very interested to see the results of a survey of how many people really plan to manage a Drupal site on their phones vs. on a desktop browser anyway. In my experience building sites for non-profit and business clients, they all do their site management from offices with desks and monitors, not from phones. I'm all for making it *possible* to do tasks from a phone in a pinch, but I really don't think most users are going to want to use a phone for most of their day-to-day content editing and management, are they? And if that is correct, why would we want to have a UI that makes the "usual" case less easy, or why couldn't we at least have a large browser friendly alternative available?

And again, why is it not a bug when the UI regresses in usability from how it was in 7?

klonos’s picture

I would be very interested to see the results of a survey of how many people really plan to manage a Drupal site on their phones vs. on a desktop browser anyway...

Don't get me started on that :/

AFAIK we have breakpoints in core. Why not use that and adjust the shortcuts for desktop (shown) or mobile (hidden)?

David_Rothstein’s picture

Title:Toolbar UI: shortcuts and menu could be visible at the same time» Toolbar UI regression: shortcuts and menu not visible at same time
Category:Feature request» Task

I don't think this is a feature request; it's a limitation of the design that was discussed as a problem in the original issue and was agreed to be a major followup (see here and here). Although it would have been much better to resolve it before commit because it may indeed require substantial design changes to fix.

I think the "easiest" (conceptually) fix for this is still #28, just make the desktop toolbar work differently than the mobile one such that the links are pulled out from underneath their headings and "spilled out" horizontally when the screen is large enough to support that. The desktop toolbar would look more like the Drupal 7 toolbar in that case. If the difference in behavior between mobile and desktop isn't acceptable, then try some of the other ideas.

Realistically, though, I'm not sure any solution is getting into Drupal 8 core at this point, so something that at least solves the specific case of the "Add content" link (#1847116: Provide users with an easy-to-access action to create content from the toolbar; and see also the proposed change along these lines that is part of #2419387: Remove Shortcut module from core) is maybe the best to hope for :(

jhodgdon’s picture

Well one of those two issues you cited is "wont' fix" and the other is "postponed". So we probably need to work out something here.

If this is classified as a bug, it can get into Core. I still think it's a bug (major usability regression), but I'm not getting into an issue classification war.

doakym’s picture

Issue tags:+admin_menu, +ux

I install Drupal 8 since few days ago, and first that i see was the menu administrative the core and... I don't like, for four razon:
1.- Two menus in the head (why? is unnecessary).
2.- Height that have this both menus is excessive.
3.- Many clics for realize a task, (really?!!) for create a content type (four clicks), where's cron (five clics) or clear caches(five clics)?.
4.- Icons its good for final user (user anonymous or authenticated), but not for the user one.
The admin_menu module in drupal 7 works good, why wasn't considerate for the core?