Toolbar difficult to remember and predict

[enzus]

User Problem

The current state of the toolbar has the following issue that its difficult to remember and predict where each element is as they seem to be ordered in an almost random way.

History

Its current ordering and layout was determined by #482.

There are some internal issues with order of the toolbar because items are a combination of two different kinds of menu code which don't easily allow mixing. Currently all the greenbar dropdowns have to be kept as a single block until that code is rewritten. (@vangheem that's true,, right?)

Options

Grouping & Order

New content from @enzus As first element I put the + New as the creation of new content seems to be the most important interaction an editor could initiate. I know creating new content doesn't happen that often and it's almost never the case for many types of user that are not editors but, still, I think that creating structural (folders, collections...) and editorial (news, events, articles...) content deserves the most visible and reachable position in a CMS.

Mode from @enzus I grouped together those elements because I believe they relate each other. View, Edit and Contents are alternative ways to look at/interact with the content. Actions as well is another way to manipulate content.

Status from @enzus I grouped together the workflow state and the history, adding to the latter what type of action has been performed (created, edited, published...) and when. I also changed the icon of the state as I believe is important to communicate the idea of a flow although I'm not sure this one is the best option. I found it on the noun project.

View options from @enzus I grouped together Display and Portlets as they both relate to a sort of visual structure. I changed the icons for both.

Sharing from @enzus This element needs to stand alone as it deals with more permanent changes while the workflow is more about a cyclical series of transactions.

Last note: the horizontal dividers between the various groups are not strictly required as we don't state the name of each group but imply some sort of correlation and help improving the scannability of the bar.

Naming and icons

Sharing → Permissions from @enzus I changed the label into 'Permissions' as Sharing makes me think about social media sharing and therefore could be misleading. I also changed icon to include a third person as 3 people is the minimum to be considered a group.

Add New → + New from @enzus I also removed 'Add' from the label as the icon and 'New' seem to be sufficiently clear in other systems as well.

Edit → Edit {content type} from @djay

• pro: gives more information about the current context

  Long toolbars

Reintroduce More toolbar options from @enzus I reintroduced this because I reckon there are many use cases that we can't consider in advance and we need a place where add-ons could live (thinking of SEO, Cover and many others) maintaining a quick reachability.

Dynamic more options from @enzus

• only appears with all the toolbar elements that don't fit under a certain window height?

Scrolling long toolbar

• pro: if the screen is long enough you don't need to click more to see other options

Allow user rearrangement

• Lets the user put hidden menu options up the top could be
  • admin only
  • or editor and admin

    Reduce the items in toolbar

Reduces the need for some of the above solutions by having less clutter and shorter menu (This is @djay alternative solution to the one proposed by @enzus here which simply tries to reorganise the currents menu items)

• Get rid of "view" (from @djay)
  • Replace it with a close icon inside the UI for each backend UI page.
• Move display into edit form (from @djay)
  • pro: people don’t understand it and click on it by mistake often screwing up their landing pages. inside edit could give more context. #704
  • pro: could give more space to explain default pages - see #519
• Move state into edit form (from @djay)
  • pro: you can save and publish in one action which takes two now
  • pro: makes publishing a post request
  • pro: you can fast publish in contents anyway. It’s two clicks the same as more options.
  • con: takes two clicks to publish something
  • con: you lose the ability to see what the current state of the item is
• Move sharing into the state dropdown. (from @djay)
  • pro: conceptually related together
  • con: extra click to get at it
• Merge sharing and state into one form (from @djay)
  • conceptually this are related and work together. State determines which riles are "active" and sharing determines who has those roles. For example a "extranet" hidden folder is achieved by using state: private and adding users to the viewer role. By bringing these together we are showing that relationship
  • pro: could help explain how sharing and workflow work together #462
  • pro: will help to change state of folder of a default page (#461)
  • con: extra click and load to change state.
  • is this offset by it being so quick to change state in "contents"?

    Remove arrows

(from @enzus) I removed the little arrows on the right side of elements with sub-menus because they add visual noise and possibly have little value but (on non touch devices) I would show the sub-menus on mouse hover.

Mockups

@enzus sketched a version with the grouping and name change options.

Here a view of the menu integrated in the page with an expanded sub-menu slightly different:

Obviously it's based on many assumptions that should be tested.

@djay created a mockup with the reduced number of items without the grouping.

[vangheem]

We spent a lot of time at the anniversary sprint going over this and rearranged them the best we could. The current toolbar implementation has some constraints on how some items can be moved due to the technology(we need a plip for 5.1).

Have you tested 5b3? Your mockups still show the "more" button which is gone.

We did the best we could with the constraints we had. For instance, we can't move the "add new" button t the top right now. Also, we felt folder contents was important enough to the user put at the top all the time.

We also can't do the separators in your mockup until we really change the underlying technology... Again, hopefully someone plips that for 5.1

[enzus]

Hi Nathan,

Thanks for your prompt reply. Yes I tested 5b3 but I'm suggesting to reintroduce the "more" button. I explained why I think it's a good idea. Obviously I'm not aware of the current technological constraints but I hope they will be overcomed one day.

[enzus]

Forgot to include the @plone/ux-team Also how can I tag the ticket with labels?

[hvelarde]

@enzus great work! please don't forget the horizontal toolbar on your analysis.

@vangheem this is exactly what I mean when I say that the toolbar is a concept not mature enough; and yes, I know it has been around since eons, but not everybody has time/resources to check stuff on early alpha releases.

[enzus]

@hvelarde Yeah I know! It's actually the version I would prefer on desktop but I wanted to focus on the vertical one as it's the default orientation out of the box. To me it's important to find a grouping of the elements being meaningful for our primary personas (editors that use Plone on a daily basis and need to make recurrent actions?) and informative for our secondary personas (newbies that have just installed Plone for the first time).

On the fact that the toolbar is not mature enough yet I could agree but, realistically, Plone needs new oxygen now and only a new shiny release within this year will save it from sure death. On the other side I learnt that a non perfect product is better than nothing first of all because it allows you to gather feedback from a lot more people (usually not interested in alpha releases) and learn from them what the next priorities are. Let's try to fix what is fixable now (better icons, more precise labels...) and let's leave the rest for Plone 5.1.

[davilima6]

I think toolbar's main problem is it currently lacks a recognizable mind model for us to memorize order and position of functionality so I'm really glad to say I'm +1 on all your suggestions. I really liked all the grouping and rationale. Just remember we can also use negative space for separators.

+1 on rewording Sharing because its default association is with social media nowadays. +1 on hover but keeping arrows on touch-devices. +1 on a new "flow icon" for workflow, only problem with the proposed one is that the arrows are too close. imo they aren't optimal for required size (current reminds me of an aim).

[djay]

This is a duplicate of https://github.com/plone/Products.CMFPlone/issues/482 "Toolbar: commonly used menu items to hard to get to or not where you expect" where a lot of options were discussed. It's much better to reopen that issue and add your ideas to the "options" section than open a new ticket. or at least copy over all the other possible options rather than present just one. I really think that tickets with proposals should be banned in favour of "bugs" that detail the problem first. Otherwise you get this +1 in multiple different tickets and its hard to reason about which is the best solution. If this proposal is aiming to solve multiple different problems then pick the biggest one, or split the ticket. @hvelarde: no it doesn't indicate there are problems with the toolbar until you clearly state the problems. Only then do we have a chance of working out how important those issues are to real users. Please do so. That is what a bug tracker is for.

[enzus]

@djay the implementation of the toolbar has changed after the last sprint, so I thought it would have been better to start over with a new fresh ticket. That should also help to keep the thread easier to read but, most of all, this ticket is about a very specific problem which is the lack of rational order and grouping of the elements in the toolbar. As @davilima6 suggested, this translates in a toolbar where it is difficult to remember and predict where each element is as they seem to be ordered in an almost random way. The other changes are mostly aesthetic and I can open different tickets if we need a deeper discussion on a specific question. So this is the usability/IA bug I'm trying to fix with this proposal. This analysis is based on my personal observation only so far and on various assumptions that should be tested. We could ask users to perform an assigned task on the two versions and measure how long that would take, the quickest the winner. Or even before that we could test the IA with tools like https://www.optimalworkshop.com/treejack but we need some budget for this.

@davilima6 what do you mean by "+1 on hover but keeping arrows on touch-devices."? Can you please elaborate more?

[djay]

@enzus ok. I'll rename this ticket "lack of rational order and grouping of the elements in the toolbar" and bring over any of the still relevent options from the old ticket.

[hvelarde]

@djay I think @enzus has clearly stated problems; seems to me we have an issue now with the release cycle as any change on the toolbar will have to wait for a Plone release (if you don't want to test from master).

Plone 5 will be ready when is ready, and I hope we haven't reached the point in which we want to release the "final" version at whatever the cost it's just because we are tired, frustrated and stressed and we to move on the next "cool" thing.

[davilima6]

It's not only that @hvelarde. There are market share and community engagement issues if P5 and all its goodness aren't released, say, this year. Despite that I agree with you it's no use releasing much earlier than "ready", so let's just focus on what @djay and @enzus suggested: fix only the core issue now (mental model/groupings/ordering/prediction) and leave harder to tackle enhancements for 5.1.

[hvelarde]

@davilima6 I agree in part: Plone isn't gonna die if we don't have a final release by year end. Some people will get obsessed but we'll survive at the end and we'll grow stronger with a better product.

I hope we learn something at the end and we can go back to release less features in short cycles like we did between Plone 4.1 and 4.3; that's saner, easier and less frustrating.

[davilima6]

But that's exactly the difference between minor and major versions. I just think we should remember better Plone 2 > 3 trauma when handling deprecations, specially of controversial removals, and when managing feature polishing vs rightful rush dilemma on a worldwide release.

Also, most (traumatic) changes in P5 are related to frontend cause we had no testing infrastructure, nobody touched many things for years so we got a bit late into recent frontend revolution. I'd expect "more dilluted" major versions from now on, with less need to break compatibility.

[davilima6]

@enzus I meant that I'm +1 for dropping arrows and displaying submenus on mouse hover but since that's impossible in touch-devices we should fallback to arrows and click-to-show submenus.

[enzus]

@davilima6 ah OK, I still believe that we can ditch arrows even on touch devices to keep the toolbar cleaner.

[davilima6]

@enzus Problem is we would lose common software functionality (hinting some items have submenus while others generate an instant browser redirect when clicked) in favor of aesthetics. Better not.

Maybe if arrows are a bit darker we can mitigate the issue. Currently they're at opacity 0.67 so I suggest 0.5. (btw I know opacity is hardware-accelerated but using a plain color is even more performant and also cleaner to override on a CMS)

[enzus]

@davilima6 It's not only an aesthetics matter as it implies a bigger cognitive load but I agree that they communicate a difference within the menus. Darker shade could help. But also the fact that those arrows are contained in the toolbar is not the best. Other related problem is the other type of arrow that appear in the contrary sense within the submenu creating a jumpy/odd behaviour. So I would keep only one type of arrow, the one within the submenu. This way we also free a bit of space on the toolbar. If you really want to go deeper the real issue is that some elements should be represented as buttons (sharing) or switches (contents/edit/view) while others as dropdown menus (translate, add, state, display, actions). So we are already betraying the natural affordance of the elements for a more polished UI.

[davilima6]

@enzus Since arrows would be there only for touch-devices I think it's a very acceptable fallback - in the same manner individual reordering arrows appear on folder contents for touch or JS disabled devices.

Re: the submenu closing arrow, it'd go away if we opt-in for mouse hovers. And for touch devices I suggest it being smaller, can't see the reason for not using the same size as the opening one.

[enzus]

@davilima6 OK then if the arrows are only for touch devices although there keeping it clean is even more important! We could probably go over and over but only an A/B testing could make up for an informed decision.

[tkimnguyen]

I updated the coredev buildout installation at http://dev.brianledwell.com:8081/Plone for you to test what's even newer than b3.

I think it's great to have this much interest and involvement, but please let's try to maintain focus on our internally agreed upon release date. Improvements can always happen later, either as add-ons or as PLIPs. The more we stir things up now at this late date, the less likely we will meet our internal target.

[polyester]

about the arrows: they are there not only for touch devices, also for accessibility reasons. A menu item should have a visual clue that there is a sub-menu. Hovering is not an option; hovering is

• badly supported on various assistive devices
• does not accommodate people with motor skills problems where hovering is difficult to impossible
• does not work for people using voice-navigation

and doing it with contrast brings along it a whole other range of problems. So I would be against removing arrows, unless we can find a valid a11y solution.

[jensens]

I close the issue, because it addresses Plone 5.1 which is no longer supported. If you think this is wrong please reopen the issue and assign a matching milestone.