-
-
Notifications
You must be signed in to change notification settings - Fork 188
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
Hide some menu items on folder_contents view. #1475
Comments
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:
You will just have to create the missing keywords, for instance:
Note: to run the test, do the following:
|
@ebrehault Please discuss my propose with the UX team. About test, I understood, but we need to modify |
@plone/ux-team any opinion? |
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? |
@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. |
@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? |
When selecting multiple items, Edit, View and Add new also become confusing. |
@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). |
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. |
I agree with @thet I prefer to think modal.. when I get into the I just need to have a simple way to get out of this mode in the toolbar (get out of |
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) |
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." |
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). |
@djay Great! |
Actually I think this is a duplicate of #1379 and should be merged in. anyone disagree? |
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? |
@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 |
@MatthewWilkes Please check this ticket again. |
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:
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. |
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
|
@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 |
@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. |
@tisto But there have also been a long list of bugs in mockup and the toolbar, causing confusion. For instance:
I connect that to what you wrote:
A range of issues with folder contents + toolbar operating on the wrong context has been fixed, see for instance: plone/mockup#857 |
@sunew thank you for your detailed response! Let's see if Plone 5.1.4 or 5.1.5 will fix this then... |
@tisto did anyone try reloading the toolbar via ajax on each folder change? |
@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 ;) |
@sunew I can confirm that the problem is gone with Plone 5.1.4-pending. Thanks for your help! |
@terapyon can you elaborate which issues are still unsolved in your opinion here? |
@tisto you mean 5.1.4-pending I assume :) |
@tisto thank your supporting. it great. |
@sunew yes, of course. I edited my previous comment. :) |
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:
Another example:
Related problems
Options (not in any particular order)
1. Hide some toolbar options in "contents" view
(main proposal which everyone is responding to below)
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
The text was updated successfully, but these errors were encountered: