- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Toolbar difficult to remember and predict #802
Comments
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 |
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. |
Forgot to include the @plone/ux-team |
@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. |
@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. 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. |
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. |
This is a duplicate of #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. |
@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? |
@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. |
@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. |
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. |
@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. |
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. |
@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. |
@davilima6 ah OK, I still believe that we can ditch arrows even on touch devices to keep the toolbar cleaner. |
@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) |
@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. |
@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. |
@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. |
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. |
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
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. |
I close the issue, because it addresses Plone 5.1 which is no longer supported. |
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
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
Scrolling long toolbar
Allow user rearrangement
could be
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)
sharing
into the state dropdown. (from @djay)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.
The text was updated successfully, but these errors were encountered: