-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Document settings: Move 'Mark as pending', 'Revision history' and 'Trash post' to new ellipsis menu in Summary panel #42175
Conversation
Not quite finished yet but ready for early feedback 🙏 |
Size Change: +1.99 kB (0%) Total Size: 1.26 MB
ℹ️ View Unchanged
|
It took me a moment to realize (based on the screencast) that "Stick to the top" is post-action and not the panel's 😅 |
packages/edit-post/src/components/sidebar/post-status/header/post-last-revision.js
Show resolved
Hide resolved
If you open the menu right after you create a new post, there's an empty space where the trash button goes:
That's a good point. We'll need to find a better label… or a better placement: @shaunandrews proposed to place that action in the header of the Visibility panel, which could be a good solution. ads/2021/09/Screen-Shot-2021-09-09-at-3.25.41-PM.png |
Maybe Stick post to top of blog?
I pushed d598b0e which does this. Here's how it looks. Kapture.2022-07-07.at.16.26.01.mp4I'm wondering if the problem is that we've trained ourselves (and users) to think that an ellipsis menu always contains settings and buttons that are to do with the block editor chrome. Which toolbars are shown, which controls are enabled, whether we're in visual or text mode, etc. Maybe we could show the dropdown next to the post title, like Figma does? Here's a crappy mockup that doesn't really make any sense (what happens if there is no title?) to illustrate. Let me know what you want to do. I'm easy! |
I think the "Sticky" post option is too hidden now. I wonder how many support requests this might generate 😅
💯 But it might be too late to untrain ourselves and users. I would deffer to @javierarce on design matters 🙇 I noticed a few cases when I could see empty menu groups. For example, I usually have revisions disabled locally, so the top menu group is always empty for me on published posts. |
Yep, working on the empty menu group issue. Requires a little bit of refactoring 😀 edit: OK that's all fixed now! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At first glance, I am really not thrilled with these UX. Hiding options that are related to this area of the editor seems strange. Is it really necessary to add yet another drop down menu?
I've fixed the tests failures and this is ready for review now @javierarce @Mamaduka.
I'll defer to @javierarce and the design team for what to do here. There's definitely a balance to strike regarding which options we show prominently. Trash post for example appears primarily in the post list so I'm not worried about burying that one. |
I understand your concerns, @alexstine, but having a lot of fields and controls in the UI makes the sidebar difficult to use and scale.
I think @jameskoster has talked about moving this section of the UI/certain items to the post title. I think that's another possibility but, at the same time, I feel having a summary of the content visible at all times is very useful. Regarding the placement for the "stick to the top" functionality… I think putting it inside the Visibility popover (as d598b0e does) works fine… but I agree with @Mamaduka and @noisysocks that maybe is a bit too hidden. The idea @noisysocks proposes could work too. And if we are heading in the direction of adding the featured image and the title on top of the section, I think that's a sensible solution. Here's an iteration of Robert's proposal so the popover always appears in the same position. I think this last idea is promising, but I'd love to hear more thoughts from @WordPress/gutenberg-design. |
Difficult for who? My point is, we should be very careful adding more and more drop down menus to Gutenberg because it already takes to many key presses to do anything as a keyboard-only user. For me, this probably should have been a bigger UX discussion for accessibility. Sometimes cleaning things up visually creates a bigger mess for non-visual interactions. I think this could easily turn in to one of those times. I just hate to get us in a situation where users have to explore an entire panel just to find what they are looking for is not there. Then they go diving down in drop downs. This makes sense visually because you can skim the page, but for the blind, this UX is nothing short of terrible and frustrating. Surely there can be some middle ground without more drop downs. Thanks. |
Still makes sense to me, for many reasons:
... anyways 😅
Hmm, doesn't the chevron make this section look like an accordion? There seems to be a convention contradiction there. I would +1 putting the sticky option in the visibility panel – that seems conceptually aligned to me. 'Mark as pending' feels like it should be in the same place as 'Switch to draft', since both affect the post status. |
Oh, shoot, you are right, the chevron doesn't make sense at all here. |
Difficult for the majority of users. I understand your frustration, and it's not my intention to make the UI more difficult to use or just make it prettier hiding things inside popovers and menus. In the previous interface everything had more or less the same importance: "Stick to the top of the blog" was next to "Pending review", the author dropdown, and "Move to trash". With the new changes the information architecture is improved and the most important details for the post appears on top of the sidebar, making it easier to reach and discover. For example, placing the delete action inside an ellipsis menu is consistent with other use cases, like removing blocks. And it's true that secondary actions, like "Stick to the top of the blog" or "Pending review", will require an extra click… but I'm not sure that's a bad thing for actions that are probably less common. |
This may be true for most users, but this will not prove true for accessibility. I understand not wanting to give users overload, but I do not think this is the solution.
This is also debatable. This makes sense considering formatting bars cannot be infinite. Users, I think, have expectations to look for commonly unused options in the context of a formatting bar but not necessarily in a sidebar. Generally, sidebars already hold the stuff that is supposed to be out of the way. I'd rather see more sections added to the sidebar as at least users will get a good idea of what is there vs. having to click in to drop downs. I also want to point out that this is not strictly related to this PR alone. I just want others to see that hiding things in menus period is something that should be avoided for UX reasons for all users vs. most. Adding extra clicks is never a good thing and it is something that this project suffers from, at large. I can get a whole lot more done in record time in the classic editor compared to Gutenberg, and I am trying to make sure the problem does not get worse. |
Thanks for the good discussion everyone! Just a logistical note: I'm going to leave this with @javierarce to work with the design team and community to decide on how we should proceed. In the meantime, I'll work on landing #42352 first. |
- Makes the Summary panel non-collapsible. - Adds an ellipsis toolbar button that opens a menu. - Moves 'Stick to the top', 'Mark as pending', 'Revision history' and 'Trash post' buttons into the ellipsis menu.
e0c2b79
to
36f91c4
Compare
Let's close this out since there's consensus on trying a different approach. See #39082 (comment). |
What?
Why?
Part of #39082.
How?
All of the new functionality is contained within a new
PostStatusHeader
component in@wordpress/edit-post
. This replaces thePostSticky
,PostPendingStatus
,PostLastRevision
andPostTrash
components in@wordpress/edit-post
.The
PostSticky
,PostPendingStatus
,PostLastRevision
andPostTrash
components components in@wordpress/editor
remain as is. We can't touch these due to backwards compatibility. It's not great that this is now all dead code. I'm unsure whether we should deprecate them, try to use them inPostStatusHeader
(difficult because we want menu items, not buttons), or do nothing. Open to suggestions.I am thinking maybe
PostStatusHeader
should go into@wordpress/editor
too so that non-WordPress post editors can make use of it. Not 100% sure of this yet.Testing Instructions
Screenshots or screencast
Kapture.2022-07-06.at.15.49.36.mp4