Hide some menu items on folder_contents view.

[terapyon]

User problem

It is currently confusing understanding what the toolbar items act on when in contents view. In particular when you select items in contents or open other folders.
Some menu items will mislead.

For example:

1. User clicks on toolbar's Contents
2. they select several items
3. they click on publish on the toolbar thinking it will publish these items. Instead it publishes the parent folder.

Another example:

1. User clicks on toolbar's Contents
2. they click to open a subfolder "news"
3. they click on publish on the toolbar thinking it will publish "news". Instead it publishes the parent folder.

Related problems

• It's sometimes not obvious to know if you are at the folder context or default page context. In Plone 4 and below, clicking the Contents tab helped make sure you were in the former.
• Title does not change to match the current folder when navigating folder_contents Title does not change to match the current folder when navigating folder_contents  #1379
• the idea of default pages in not obvious the idea of default pages in not obvious #519
• Not obvious how to edit/publish folder when it has a default page Not obvious how to edit/publish folder when it has a default page #461
• Toolbar difficult to remember and predict Toolbar difficult to remember and predict #802

Options (not in any particular order)

1. Hide some toolbar options in "contents" view

(main proposal which everyone is responding to below)

• Hide some menu items on folder_contents view
• With Plone 4, this feature existed.
• @terapyon wrote the following code, but no tests yet, cause it's difficult: https://github.com/plonejp/plone.app.contentmenu

2. Contents in modal

Fading out the background and preventing clicks on the toolbar will indicate these buttons do not relate to current context of what is open in the contents view. You would have to "close" the modal to use the toolbar again.

3. Refresh toolbar on contents move

AJAX reload so toolbar matches currently open folder in contents view

Risks

• "2. Contents in modal": you will have overlays on overlays which may look confusing.

[ebrehault]

Regarding the change you propose, I will let the UX team decide if it is accurate or not.

But regarding test, that's actually really easy: you just need to change the following Robot test:
https://github.com/plone/Products.CMFPlone/blob/master/Products/CMFPlone/tests/robot/test_folder_contents.robot
where you can add a new scenario like this:

Scenario: Toolbar menus visibility
    Given a logged-in site administrator
      and a folder with four pages
     When the folder contents view
     Then the State menu is not visible
      and the Action menu is not visible
      and the Display menu is not visible

You will just have to create the missing keywords, for instance:

the Action menu is not visible
    Element should not be visible  css=.plone-toolbar-main .plone-contentmenu-actions

Note: to run the test, do the following:

$ bin/robot-server --reload-path src/Products.CMFPlone/Products/CMFPlone/ Products.CMFPlone.testing.PRODUCTS_CMFPLONE_ROBOT_TESTING
$ bin/robot src/Products.CMFPlone/Products/CMFPlone/tests/robot/test_folder_contents.robot

[terapyon]

@ebrehault Please discuss my propose with the UX team.

About test, I understood, but we need to modify https://github.com/plone/plone.app.contentmenu/blob/master/plone/app/contentmenu/tests/test_menu.py, but it's difficult for me.

[ebrehault]

@plone/ux-team any opinion?

[davilima6]

I agree with @terapyon. Toolbar should affect/relate only to current context, and the fact folder_contents allows to select other items can easily mislead users to think they're able to use the toolbar to operate on them, e.g. #725.

Besides it might be considered a UX regression since those were hidden in previous Plone versions.

For consistency I suggest we also remove "Manage portlets" for this context.

Btw, the placement of toolbar buttons has been changing a lot, which is understandable, but we could however do something about it. For instance, we could map the most important screens (sharing, historyview, version history form, manage portlets, add/edit item) and centralize those decisions with mockups or at least a business level document. That should also help with decisions like this #1379 (comment) (an issue also raised because of the new toolbar ux). Would anybody from @plone/ux-team be interested on this?

[ebrehault]

@davilima6 I agree, but on the other hand, I have always considered very handy to go to the folder_contents page to make sure I am acting on the actual folder and not on its default view content, and I often recommend this practice to my users.
The good thing about the new folder page is it also allows to select the current folder and use all the actions on it just like if it was a contained item.
So it might mitigate the problem I just raised.

[davilima6]

@ebrehault I can see your point and although it's a bit harder (one extra click) I'm inclined to agree with your solution (selecting the parent to act on it).

Otoh I just noticed that if we remove Manage Portlets we must also remove Sharing and History View for the same reasoning, even though those were NOT hidden in Plone 4. So we get to this dilemma: ensure the mental model is consistent and regress on these 3 items (by making them not available) or assume those are a bit less bulk-oriented and may not confuse users as much as Actions or Workflow buttons (which are duplicated in content area anyway).

Finally Contents button should definitely be hidden since we won't ever need it inside folder_contents, will we?

So the slim version would have 3 buttons only: Edit, View, Add new. And if we with the more generous one (although a bit more confusing) we'd add: Display (not duplicated in content area), Manage Portlets, History View and Sharing. @terapyon What do u think?

[thet]

When selecting multiple items, Edit, View and Add new also become confusing.

[davilima6]

@thet, not as much imho. We'll have to balance practicality vs purity in this one, the alternative being completely hiding the toolbar, or rather leaving User Menu only (which I'm -1).

[thet]

That's doesn't sound consistent to me. The toolbar does always operate on the current context. That can be trained. I wouldn't hide some of the possibly confusing items while others equally confusing items stay there for reasons of practicality.

Still, I think having folder_contents in a fullscreen overlay (which also hides the toolbar) will resolve these usability issues. I'm currently experimenting with that.

[rodfersou]

I agree with @thet I prefer to think modal.. when I get into the folder_contents I want to get into the content edit mode and the toolbar doesn't make sense to me in this mode.

I just need to have a simple way to get out of this mode in the toolbar (get out of folder_contents).

[thet]

Well, there is not much to experiment with. I've created a actions.xml for opening toolbar items in a modal. more here: #1379 (comment)

[tkimnguyen]

I'm with @ebrehault that it is "very handy to go to the folder_contents page to make sure I am acting on the actual folder and not on its default view content, and I often recommend this practice to my users."

[djay]

Just a note, @plone/ux-team doesn't really exist at the moment. Don't stop mentioning however as its a good habit as one day they will return (with the help of someone in a better timezone and more time than me).
I hope its ok, but I'm going to try and restructure the proposal to try and represent everyones ideas and risks mentioned.

[djay]

@terapyon and others, please check I captured the problem and options presented.
@vangheem @enzus Thoughts?

[terapyon]

@djay Great!

[djay]

Actually I think this is a duplicate of #1379 and should be merged in. anyone disagree?

[tkimnguyen]

I don't think they are really the same problems. #1379 is about the context and what the browser thinks it's looking at. This issue is about whether we should hide toolbar icons. Or am I misunderstanding?

[terapyon]

@djay I think this is another problem with #1379.

[MatthewWilkes]

@alecpm and I discussed this at the 2016 conference sprint as we were working on toolbar UX. We agree with @terapyon that these menu items should be removed on folder contents. It is in fact a regression from 4.3 as limiting this was a deliberate decision because of user confusion.

I've made a PR at plone/plone.app.contentmenu#18 targeting Plone 5.1

[terapyon]

@MatthewWilkes Please check this ticket again.

[tisto]

I gave a Plone training this week and at least 5 of the 20 people that I gave this training for ran into the issue of triggering an action for the wrong content objects because they came from the folder contents view. Here is what most of them did:

1. Navigate to a subfolder via folder_contents
2. Click on workflow, action, display and accidentally triggered the action on the portal root

I think this is a major UX bug that we have to fix. I don't have a strong opinion if we should open folder_contents in a modal or hide the context-specific action. I just felt very embarrassed as a Plone core developer when I saw how many people ran into this, so I think we really have to fix this asap.

[sunew]

this is a bug in mockup - has been fixed. But similar bugs still exist. (on my phone will find ticket / pr numbers later)

On Fri, 28 Sep 2018 at 16.13, Timo Stollenwerk ***@***.***> wrote: I gave a Plone training this week and at least 5 of the 20 people that I gave this training for ran into the issue of triggering an action for the wrong content objects because they came from the folder contents view. Here is what most of them did: 1. Navigate to a subfolder via folder_contents 2. Click on workflow, action, display and accidentally triggered the action on the portal root I think this is a major UX bug that we have to fix. I don't have a strong opinion if we should open folder_contents in a modal or hide the context-specific action. I just felt very embarrassed as a Plone core developer when I saw how many people ran into this, so I think we really have to fix this asap. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1475 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA2g1q0M5xuUWYzY0rdsLygD8C834bczks5ufi5rgaJpZM4Hx8ES> .

-- Sune Brøndum Wøller +45 24256610 skype: sune.woeller

[tisto]

@sunew can you elaborate why this is a bug in mockup? If I understand things correctly folder_contents is written in React, so the toolbar has now way to automatically update itself when the context of folder_contents changes. The toolbar just can not reload automatically because it is static, right? To me, Matthew's fix to hide the context-specific toolbar items seems good enough for me: plone/plone.app.contentmenu#18

[djay]

@tisto I can't see how that PR fixes the issue well because every item in the toolbar is context specific. Edit, View, Actions, History, Display.... the only things that aren't are personal tools, so its basically disabling the toolbar. Probably its more clear just to load the folder contents in a modal or reload the toolbar via ajax.

[sunew]

@tisto
Sorry for my quick out of context reply. This issue mostly has to do with UX issues about what you act on if you have selected some items in the folder_contents view. This I do not address here.

But there have also been a long list of bugs in mockup and the toolbar, causing confusion.

For instance:

1. Begin on plone frontpage.
2. Go to folder contents.
3. navigate to a subfolder.
4. Add an item via the toolbar menu.
5. The item was added to the portal root instead of in the subfolder.
   This is a bug that has been fixed.

I connect that to what you wrote:

Navigate to a subfolder via folder_contents
Click on workflow, action, display and accidentally triggered the action on the portal root

A range of issues with folder contents + toolbar operating on the wrong context has been fixed, see for instance:

plone/mockup#857
#2395
#2452
#2531
#2322
(and more).

[tisto]

@sunew thank you for your detailed response! Let's see if Plone 5.1.4 or 5.1.5 will fix this then...

[djay]

@tisto did anyone try reloading the toolbar via ajax on each folder change?

[tisto]

@djay I guess that would fix the issue and I was under the assumption this is the actual default behavior. Though I have never touched mockup code in my life and I plan to stay at that level ;)

[tisto]

@sunew I can confirm that the problem is gone with Plone 5.1.4-pending. Thanks for your help!

[tisto]

@terapyon can you elaborate which issues are still unsolved in your opinion here?

[sunew]

@tisto you mean 5.1.4-pending I assume :)

[terapyon]

@tisto thank your supporting. it great.

[tisto]

@sunew yes, of course. I edited my previous comment. :)