Skip to content
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

Closed
enzus opened this issue Aug 5, 2015 · 22 comments
Closed

Toolbar difficult to remember and predict #802

enzus opened this issue Aug 5, 2015 · 22 comments

Comments

@enzus
Copy link

enzus commented Aug 5, 2015

User Problem

screen shot 2015-08-06 at 9 07 38 pm

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)
  • 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)

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.

plone toolbar

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

plone toolbar - desktop web

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

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

1-home

@vangheem
Copy link
Member

vangheem commented Aug 5, 2015

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
Copy link
Author

enzus commented Aug 5, 2015

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.

@vangheem vangheem added this to the Plone 5.1 milestone Aug 5, 2015
@enzus
Copy link
Author

enzus commented Aug 5, 2015

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

@hvelarde
Copy link
Member

hvelarde commented Aug 5, 2015

@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
Copy link
Author

enzus commented Aug 5, 2015

@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
Copy link
Member

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
Copy link
Member

djay commented Aug 6, 2015

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.
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
Copy link
Author

enzus commented Aug 6, 2015

@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
Copy link
Member

djay commented Aug 6, 2015

@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 djay changed the title Order of the elements in the toolbar Toolbar difficult to remember and predict Aug 6, 2015
@hvelarde
Copy link
Member

hvelarde commented Aug 6, 2015

@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
Copy link
Member

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
Copy link
Member

hvelarde commented Aug 6, 2015

@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
Copy link
Member

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
Copy link
Member

@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
Copy link
Author

enzus commented Aug 6, 2015

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

@davilima6
Copy link
Member

@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
Copy link
Author

enzus commented Aug 6, 2015

@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
Copy link
Member

@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
Copy link
Author

enzus commented Aug 6, 2015

@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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

jensens commented Mar 12, 2023

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.

@jensens jensens closed this as completed Mar 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants