3.0: Payment Gateway Icons - Improve display

[amdrew]

I can't capture it in the screenshot but the cursor is set to move when you hover over each label in either the Payment Gateways section, or the Payment Method Icons section. This is confusing since the primary interaction should be to select a checkbox when clicking on a label, not to move it.

I propose we only make the cursor show the move icon...

When you interact with the draggable icons to the far right.

---

The icon used for drag and drop is '\f228':

This is typically an icon used for menus, and is used already in the WP admin menu bar at mobile sizes:

I think we should replace the icon we are using with something more suitable, perhaps dashicons-move?

[spencerfinnell]

https://cloudup.com/crWcVx7IVqm

Seems a bit repetitive to me. What about showing only on hover and having a tooltip that let you know you can drag to rearrange them?

[spencerfinnell]

I can open a PR that implements:

https://cloudup.com/cnhACcmZaB4 (hover state) https://cloudup.com/c1p6OsRhJZ2 (tool tip)

Also fixes the correct cursor showing when you are hovering over the label (hand shows instead of move when you are over text).

[amdrew]

@spencerfinnell I agree, an invisible UI with what you have proposed would be much nicer 👍We'd need to implement it for the payment gateways also.

[spencerfinnell]

Yep it easy to do on both sortable lists. I’ll open a PR soon.

[SeanTOSCD]

Love it. Working well on my end. :heart:

[amdrew]

@spencerfinnell @SDavisMedia

👍When hovering between each gateway (Firefox) the move icon appears briefly which can be disruptive if you do not intend to re-order. The move icon also appears based on the length of the label, which is different for each gateway.

Since the primary action is to toggle a gateway on or off (re-ordering is secondary) I would suggest we only make the move cursor appear when hovering over the arrow on the right. The move icon still appears when you click and drag a gateway (love that).

So move: cursor: move; from .form-table .edd-sortable-list li label and on to .edd-sortable-list li label:hover::after.

[spencerfinnell]

Nice that’s a great way to add hover intent without using the actual hoverIntent script. Much better.

[SeanTOSCD]

I went ahead and pushed that change up.

[JJJ]

I'm bias, because I designed the original, but now there's no indication they are sortable until they are hovered over. I really liked the way it was, and don't really prefer this. It doesn't feel right to me.

[JJJ]

I tried out the PR, and really tried to like it, but I still don't. Sorry, nothing personal. I'm going to defend some of my design decisions, but please know that I'm not feeling defensive in any way. 💌

This is confusing since the primary interaction should be to select a checkbox when clicking on a label, not to move it.

The current approach follows existing WordPress UI/UX conventions. Everything else uses the move cursor on draggable things: Menus, Widgets, Meta-boxes, Customizer, and so on. Their primary actions are to edit/click them. Those do not feel/look wrong, and neither does this, IMO.

I purposely omitted tooltips because they are distracting and busy. Dragging/dropping is a pretty simple & obvious thing. Hiding the functionality, then adding tooltip to say it's possible, hides the obviousness behind an annoying pop-up tooltip thing.

Don't pop a thing up in between the thing the user wants to interact with, kinda thing.

The hamburger menu used to be the icon to use for this interaction, simply because the sorting is veritcal-only. The up/down arrow combo works too, but doesn't always look as pleasing due to its sharp lines and acute angles.

I've seen other droppables use a 9-dot 3-by-3 kinda icon, but sadly Dashicons doesn't include one, and usually that's for multi-column targets.

If the meaning has changed so dramatically in recent times that it's unclear here, that happened without me noticing. BuddyPress still uses them in XProfile fields and it's received literally no negative feedback:

---

Which icon translates best is pretty situational. In these cases, our sortables are strictly vertical, and it's not 100% obvious to users that these items would even be sortable. So, to avoid inevitable "I'd really like to sort these" and "you can already!" support conversations, I would prefer we keep these more obvious than hidden.

---

By limiting the icons to appear only on hover, there is no visual indication of how wide the sortables are until you've already discovered how wide they are by hovering over them.

If you hover to the right of them, you'll never know it's sortable.

Without the icons always visible, the handle width appears rather arbitrary - there's no way (without more JS) to find the width of the widest span contents and enforce that value on the others.

Persistent icons guide users without forcing an interaction to happen to learn what hidden powers exist inside the elements.

---

My last design decision with having these always-visible, is that dragging & dropping is still one of those user interactions that requires some guessing. macOS and iOS, for examples, have tons of places where vertical-only 3-bar icons are used to eliminate the guesswork and communicate clearly that reordering is possible.

Note that in iOS, the primary function is removal (via the red round circle with a minus in it) yet the 3-bar icon is there to hint that reordering is also an available option.

---

I do like the simplicity of having fewer things onscreen, just as a general rule, always. If there's a way to do that without compromising discoverability and consistency within WordPress admin, I think this is worth iterating on. I also don't think this is so bad that it couldn't ship as-is in 3.0.

[spencerfinnell]

@JJJ Thanks for the feedback.

I agree with the points about the icon not fitting 100%, since there is only vertical sorting. What about https://developer.wordpress.org/resource/dashicons/#sort instead?

I think the ability to adjust the order would be pretty hard to miss as you're required to make payment gateway setting adjustments, so the chances of not seeing the icons on those interactions seems small.

The entire table row could be used as the hover trigger, which would keep the initial page UI elements down, but provide hard to miss indicators when making the setting adjustments.

The current approach follows existing WordPress UI/UX conventions. Everything else uses the move cursor on draggable things: Menus, Widgets, Meta-boxes, Customizer, and so on. Their primary actions are to edit/click them.

In my mind the primary action on those items is to move them, not to edit them. Metabox titles drag areas can only be used to move the meta box. Same with menu items -- the title is only edited through a separate input. Same with widgets -- there is no other interaction that can be taken besides just dragging when the cursor changes.

Widgets are also an example of where the 4-direction move cursor is used on items that can only be adjusted vertically.

---

All that being said I don't have super strong feelings about either direction, so I'm happy to go with whatever is decided if anyone else wants to chime in.

[spencerfinnell]

I also believe the three line icon on iOS is an icon that is more suited for touch devices. It makes sense as an indication that you can "grab" something and move it around when you're using your finger, but that interaction isn't as common on desktop devices and therefore I don't think the icon has the same implied meaning.

On the iOS note, I'm pretty sure those edit/drag icons only appear when you explicitly go in to a separate "Edit" mode right? So the order functionality is technically hidden by default as well in some instances.

[pippinsplugins]

I've spent a little while playing with both release/3.0 and issue/6872. I'll be honest, I really don't care for the experience in issue/6872 nearly as much as the experience in release/3.0.

I've pushed up a new PR that implements just @amdrew's original request of changing the move cursor such that it only shows when hovering over the drag icon. I think this is the best of both worlds and, unless there is objection, I'm going to merge it in and call this closed.