too many dots on publishing "State" sub-menu

[3dogMcNeill]

too many colored dots: rather than have a bulleted list with an associated color dot to indicate current published state, drop the bullets and change the background color of the current state to highlight it.

added: so I see now all of the submenus have blue bullets—keep it simple and make it the same color as the text

[jensens]

or what about colouring the bullet dot and skipping the dots at the end except the selected?

[3dogMcNeill]

@jensens I don't see the purpose of having bullets colored, what value does it add? On the other hand, there is value is color-coding states.

[vangheem]

Isn't the blue dot the current state and the red to denote the state will change to unpublished?

If a page is unpublished, the top dot is red and the "publish" transition is blue to denote that the state will change to being published.

I think they are fine and a visual queue to the user on the public visibility of items.

[3dogMcNeill]

@vangheem Yes. I'm questioning having the bullets colored. Typically, bullets match text color, so in this case, they should be white.

I'm definitely in favor of color coding publishing states—it's that the color coding for the states are colored circles and so are the bullets for menu items that are confusing, especially when published state dot is the same color blue as the bullet. I think colored bullets are unnecessary because they do not add value and they are also visually confusing alongside the published state color coding.

[agitator]

I also think the red one is confusing and would get rid of it

• keep the bullet points on the left but probably better in white
• keep the state color matching dot on the "State:" line to the right

[hvelarde]

why don't just keep things like they are right now? private is red; pending is orange; published is green…

those colors are there for a good reason (they remind us traffic lights) and I think is a bad idea to change or remove them.

[agitator]

nothing against colors...

if we keep the red one at "Send back" there also should be the same for "Retract"
but would rather vote to just display the actual state with a colored dot to the right

[enzus]

Don't know how much we can change at this stage but that's my idea of this sub menu:

First the title of the sub menu to make clear what it is about. Here we have more space than on the 120pixel of the toolbar so we can be more communicative. In the example above is "Workflow". Than I would put the current state with the label colour coded as usual.
The other elements of the list don't need bullet points if distanciated enough which is also more touch friendly (44px is the minimum height suggested but in my experience 40px are OK too).

[agitator]

With a first useable plone 5 release as target, could we focus on the actual and most prominent problems? There will be lots of room for improvement in the 5.x series based on actual user feedback and we will have more time for discussions there.

Nothing against this idea at all, but that would impact all other submenus that don't have that problem right now.

I see the red dot as foremost problem here, let's solve just that for now?

p.s. i like the portlets/display icon which are already in discussion here #740

[3dogMcNeill]

My comments are from actual user feedback; they're not a personal preference.

To @enzus's point, bullet lists aren't necessary if li.plone-toolbar-submenu-header(s) are removed, which is redundant in all the submenus (see "Actions" is listed twice in image below).

[agitator]

with actual user feedback, i meant more "voices" and didn't mean to offend ;-)

@enzus example still has the plone-toolbar-submenu-header, which I think is good (at least for now)

[3dogMcNeill]

@agitator no worries, I'm not offended! This is my first time participating in a release and I'm finding it difficult to tell whether commments are biased from personal preferences or impartial results from user testing and feedback.

[djay]

@3dogMcNeill I think that's the hardest problem we face. Everyone has an opinion. Some biased by being very familar with plone and not wanting it to change. Some biased by having small customers. Some by large, some by internets, etc etc. The danger is that plone will become the product of only things that are non controversial. And good UX is never non-controversial I believe.
Somehow the @plone/ux-team needs to work out how do some form of quick/cheap user testing so we can have data guide our decisions.

[hvelarde]

@djay that's a very good point indeed… and it's worst: everybody has a strong opinion.

I know that I sometimes make my points not in the best possible way, but it's difficult to keep following all changes you guys are doing; I'm spending a lot of time on this and sometimes that means I need to go to bed late after having passed the whole day seated in front of my screen instead of taking care of my tomatoes and enjoying the place where I live now.

on the past we had some community leaders who were really visionaries and most of us knew even less of Plone and the web than we do know; and we still made mistakes, obviously.

many of us have a lot of Plone sites that we have to take care and breaking something for no good reason means a lot of work for nothing; that's why I became part of the Conservative Party on this (the other reason may be I'm just getting old).

we have that saying, if it ain’t broke, don’t fix it, that is true until you have to deal with technology and planned obsolescent: yes, we need to change, and we need to break many things, but we have to think about it in a broader and inclusive way and we need to find that way.

[enzus]

@agitator agree we need to focus and not rush other solutions but the current implementation of sub-menus is confusing and not just because of too many bullets.

@3dogMcNeill I'm -1 to remove the submenu header as it can be used to state the general purpose of the whole submenu while in the toolbar we could just show the most relevant information from that submenu (like published in our example). Of course we could have some duplications some times or we might use the header to be more precise e.g. "Actions" in the toolbar and "Actions on folder" in the header so to help avoid that terrible mistake "I thought I was deleting the page and not the parent folder!"
Also can't we keep the li structure without showing the bullets?

[3dogMcNeill]

@djay @hvelarde good points, thanks for the insights.

[davilima6]

Bullet points should be same or similar as text color (which btw is not white but 90% of it and 75% on hover).

This is even more true in our case where we convention colors to represent workflow state (which btw should have the same colors as in Plone 4 and traffic lights as @hvelarde mentioned, I apologize if I miss the reason to change them).

Finally, @agitator, I don't think there's a problem having two items with red (destination) bullets since both really do result in the same wf state and that's what we want to communicate.

I can understand it might not be obvious until user test those links and realize both lead to Private (red) state, but it's actually difficult anyway to understand at first glance why there are two transitions leading to the same state. That only comes with time when user understands a Site Admin account aggregates Contributor, Editor and Reviewer permissions.

[enzus]

@davilima6 I'm challenging if there is really a need to communicate in any way (colours or not) the destination status of a transaction? I would rather keep the colour codes just for the states (green for published, orange for pending, red for private) and leave to the labels the duty to explain what's going to happen: "retract" sounds self-explanatory to me and if it's not a bit of red won't help.

The aim for me is to keep the UI as simple as possible without overloading the user with a lot of not so immediate information.

[agitator]

for me the most visible problem and i consider that a bug is, that "Send back" has a red dot and "Retract" not - either both have the corresponding colored dot or not.
Leaving that aside, I'm with @enzus that I don't feel the need to communicate the target states color on the action and just not dots on both sides.

I'd just remove the target state colored dots on the actions for now (and probably make the bullet points white as the text).

[hvelarde]

if something goes from green to red, or vice-versa, then the person making the change will now in advance that the action has implications; those colour codes are used everywhere and we are used to them; there's no need to remove a feature that is useful for no good reason, IMO.

[davilima6]

I think final state colors are a hinting enhancement that comes handy in here because user is actually reminded about next system state (info that isn't explicit in transition's title or description).

And I do believe often times people have a hard time remembering the difference between Send back and Retract, see:

• http://plone.293351.n2.nabble.com/why-quot-retract-quot-instead-of-quot-make-private-quot-td5976549.html
• https://dev.plone.org/ticket/11368

Besides I disagree the trade-off is high: right-side bullets are discrete and don't really overload. Actually I think it will be a new and nice DOM hook for integrators developing new workflow-based systems.

[enzus]

We don't need to keep something only because it was there in previous releases. The context has changed now since tabs and dropdowns once separeted on the green bar are now all menus part of the same toolbar. How the various submenus appear should be consistent.5

We should probably focus on finding more descriptive labels adding icons if not enough.

[davilima6]

Just a reminder: color hinting on transitions' final state wasn't there in previous releases. What was there and we should keep are wf states' color conventions, which is what I think @hvelarde was actually referring to.

Also, the bullets are too discreet to break consistency imo.

[hvelarde]

yes, that's exactly what I referring to

[pigeonflight]

I think what @3dogMcNeill is suggesting is that there is too much visual noise in the interface (this is why she uses the the phrase "too many" in her title). I don't necessarily agree with specific proposed solutions but I agree with their intended outcome which I believe aims to reduce the clutter.

I consider visual clutter to be a genuine UX problem and worth addressing. I've included screens with a proposed fix which I believe to be relatively trivial and I'll happily submit a pull request.

update: Here's an experiment based on @3dogMcNeill's suggestions and some of my thoughts (I'm purposely using something in a private state, I'm not sure yet how to deal with a published state where two transitions both move the state to private.)

The screenshot below illustrates how my proposed solution might look on another toolbar entry (the display menu)
How does this solution help?

1. reduces visual clutter
2. in the context of the display menu the greater contrast makes it more obvious which display is selected
3. keeps visual colour hints of future states (which I consider very valuable from UX perspective)
4. easy to implement (a few changes in a the stylesheets)
   

This would be my second choice it has the same goals of reducing visual clutter but does so by dulling the bullets rather than completely removing them.

My "dream solution" would be to do a "bullet-geddon" and get rid of all bullets in the interface that aren't absolutely necessary (this includes the ones in the portlets now).

[jensens]

anyway, its not solved dream-like, but solved.