Reduce visual prominence of primary actions in table data views, and consolidate primary + secondary actions in ellipsis menu #59128
Conversation
jameskoster
added
[Type] Enhancement
jameskoster
requested review from
andrewhayward,
oandregal,
jorgefilipecosta,
ntsekouras and
pablohoneyhoney
|
Size Change: +169 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
|
How can we make sure it is still discoverable? |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Has there been any feedback from users about this interface being too cluttered? How does this work for users of screen magnification software? |
|
I'm not sure this proposed change helps usability and accessibility to get any better. Hiding content isn't the best way to make an user interface more usable. To me, the proposed change seems to aim to improve only the visuals, based on some subjective judgment, and doesn't help functionality. It seems to me that it prioritizes form over function, which is less than ideal IMHO. I'd think we should go the opposite direction instead, at the point I wanted to create an issue to propose to make the checkboxes always visible instead of showing them only on hover or focus. I'm going to create that issue soon. Besides that, I have to say that I'm uncomfortable with the process followed with this PR. I'm not sure a pull request is the right place to discuss process but I'd like to clarify why I'm uncomfortable with this. I'll try to discuss this point in more depth in a more appropriate place and time.
It's not my intent to blame the specific person who submitted this PR. As I mentioned above, there have been several cases of pull requests that didn't follow the established process. I'm reporting a general issue that I think needs to be discussed looking at the broader picture. I apologize in advance if anyone may feel personally targeted by my feedback but that's not my intent. |
There was a problem hiding this comment.
Has there been any feedback from users about this interface being too cluttered?
I'm worried the change will make it more difficult to use.
Just to echo @carolinan's thoughts, I'm not entirely sure as the motivation behind this is actually needed, or that it really improves things. Happy to discuss, regardless.
Aside from the various specific conceptual points brought up though, there are a couple of technical issues that we would need to resolve before advancing with this, should we do so.
The various action components have associated tooltips, which themselves appear on hover. However, when hovering over the tooltips, the components then disappear. It's not quite the typical failure of SC 1.4.13 (Content on Hover or Focus), but it's a failure nevertheless!
Similarly, when the "more actions" menu is activated, the action components disappear again. The illustration above shows only a keyboard focus failure, but the same issue applies with pointer users too.
|
Happened to be looking at Apple Podcasts, and noticed they only hide the primary actions, and reveal them on hover; the actions menu itself is always visible, and also contains the primary actions. Not quite the same paradigm, and not necessarily suggesting that just because someone else does it so should we, but food for thought, regardless.
|
|
Hi |
jameskoster
removed
the
Backport to WP 6.7 Beta/RC
|
@andrewhayward that pattern seems worth a try. It surfaces primary actions only when focussed on a specific row to manage prominence, and (hopefully) informs users that actions exist regardless, in a more minimal way. |
|
Plays a bit weird at the moment because of where menus are rendered in the DOM, and how we're relying on native hover/focus.
|
|
You mean how the action buttons disappear when you engage the ellipsis menu? I think that weirdness also applies to the hover state. As you alluded to, ideally an |
I added this. It works a bit better now – the hover styles and primary action buttons remain visible when you interact with the ellipsis menu: 
|
jameskoster
changed the title
|
I think more discussion is needed as to what approach is best, but I would like to introduce two apps. We may be able to get some hints from these apps. Google Drive
google-drive.mp4DropboxThe left button and ellipsis menu are only visible while hovering over a row. dropbox.mp4 |
|
Since this PR is 6.6 bound, I think it would be a great way to unstick this conversation to actually land it, and have feedback trickle in from its usage in the plugin. As is, this behavior is identical to what exists in Google Drive, and what has existed in WordPress for many years:
|
|
Yes this seems to be a common pattern:
This is a little different to the original convention we installed, but given we want to surface actions on right-click down the road (#59608), I think this moves us in a better direction. It's also similar to the existing wp-admin lists as pointed out above, with added scalability. |
|
One concern I have is that I don't know what primary actions are available for that item unless I hover over that row. For example, on a Pages page, both "View" and "Move to Trash" actions are always visible for any item. The actions available for each item are unified, so it may not be a problem if it is hidden by default. On the other hand, for example on a template page, the available actions change depending on the item's status. Sometimes there is no action, sometimes there is a reset or trash button. In this way, when the icon changes depending on the item's status, it is a little hesitant to hide the icon with the default. 9c61e7939e7578eac7293cd5a43ea6f4.mp4 |
|
@t-hamano I'm inclined to say that's a separate issue which also exists (albeit to a slightly lesser extent) on trunk. It's arguably confusing that different templates have different action buttons, regardless of how they appear. Solutions to that problem are perhaps best discussed in detail elsewhere, but options include; unifying the reset/delete actions, or making those secondary so all template actions live in the ellipsis menu. |
|
I also don't completely buy the argument that it's hard to know, both because this is an existing behavior in WordPress with the on-hover quick-actions, but also because every action you can take is consistently available in the ellipsis menu. |
|
There are a couple of things we need to ensure we're aligned on, but otherwise I think it's worth moving ahead with this; we're more likely to get feedback if it's directly available to users, and this feels like one of those ones that we could go back and forth on all day.
I'm always wary of copying patterns just because, but rightly or wrongly it's not uncommon. As @jasmussen points out, it already exists in WordPress, and this would actually be an improvement; while definitions of "perfect" vary, I'm all for small steps in the right direction. |
|
Those points seem reasonable to me 👍 |
If we're in agreement, I'm happy to proceed and iterate where necessary.
@afercia I'm largely in agreement with #59175, and it's definitely a conversation we should continue there. As this is a slightly different scenario, would love your thoughts on the alignment points above (cc @carolinan). |
|
Just leaving a note to say we should follow-up to evaluate action order, and which should have single-click access. The menu order in this PR is a little odd (Trash is given more prominence than Edit). I'll pick that up in #59551. |
|
@andrewhayward late to the party, but if you ask me, I'd make everything always visible by default. If a 'ligher' UI is desirable, that should be optional. It's not uncommon in large applications that need to account for different needs to have layout options like 'detailed', 'compact' and so on. However, the default should be usable and accessible for everyone.
That's not entirely accurate. In core, the 'view actions' in the List Tables are revealed on hover / focus for Posts, Pages, Users, etc. but for Plugins they're always visible and that's been the case since forever, I think. Mentioning it just to better clarify some statements in this conversation aren't entirely accurate. |
| @@ -168,10 +170,16 @@ export default function ItemActions( { item, actions, isCompact } ) { | |||
| icon={ moreVertical } | |||
| label={ __( 'Actions' ) } | |||
| disabled={ ! secondaryActions.length } | |||
| className="dataviews-view-table__all-actions-button" | |||
There was a problem hiding this comment.
We shouldn't use classnames for specific views in the generic component. I have opened a follow up PR for this.
What?
Why?
Permanently displaying the primary actions is quite noisy and adds a lot of repetition to the UI. Revealing them while focussing a specific row can better manage prominence.
The ellipsis button remains permanently visible so that users can intuit that actions exist at a glance.
Consolidating all actions into a single menu is helpful for orientation, and means we can use a single reference point for the right-click interaction (#59608).
How?
Primary actions are revealed using the same mechanics as the checkbox. That is; when a
trhasis-hoveredclass, or hasfocus-withinthe actions appear. Secondary actions (via ellipsis menu) are permanently visible.Testing Instructions
actions.mp4
Note: I'd say this is quite closely related to #59551. The placement of the Trash action in the menu seems a little odd. This would make more sense:
– Edit
– View
– Revisions
– Trash
Ideally these PR's are reviewed in tandem.