[wp-trac] [WordPress Trac] #50699: Fix and improve arranging metaboxes

[WordPress Trac]

#50699: Fix and improve arranging metaboxes
-------------------------------------------------+-------------------------
 Reporter:  azaozz                               |       Owner:  azaozz
     Type:  task (blessed)                       |      Status:  assigned
 Priority:  normal                               |   Milestone:  5.6
Component:  Administration                       |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing needs-dev-   |     Focuses:  ui,
  note                                           |  accessibility
-------------------------------------------------+-------------------------

Comment (by johnjamesjacoby):

 I don’t think anyone is confused about your reasons, and we aren’t looking
 for you to retype them out differently to re-justify them. This isn’t all
 of us being resistant to change, and this isn’t just our initial shock.

 A few people have provided more than 5 legitimate reasons why this change
 is undesirable, and from reading your response, you’re going to do this
 regardless of the critical feedback to it.

 > So, what would be best to do here?

 Revert this change and never look back.

 > I'm really curious why do you consider the ability to arrange screen
 elements so essential.

 It’s similar to the ability to rearrange apps or files on your computer or
 phone. You select them, drag them, and you drop them where you want them.

 There are multiple ways to invoke these actions, and they differ slightly
 between operating systems, but it is a universal expectation across all of
 them that you have the ability to do it.

 Maybe you won’t rearrange every single file or app on every screen, but it
 is widely known and accepted that things that look a certain way on the
 screen can be manipulated via user input in certain other ways. Meta boxes
 look like they are draggable and droppable. That is their design
 intention.

 WordPress has given all users this ability for 13 years. This change is
 going to make people feel like that innate ability has been taken away
 from them, until they relearn how to do it via an invisible decision that
 has no on-screen or in-markup discovery method for the audience of people
 you are claiming to be helping, but are actually severely hurting.

 A lot like most of the Gutenberg UI and UX, the logic behind this concept
 is fundamentally flawed, and I am in disbelief it is even necessary to
 explain it.

 > I'm thinking that having some explanation text in the Screen Options tab
 is pretty essential to help with discoverability

 This is absolutely the worst place to put anything that it is essential.
 Users completely gloss over the very existence of the Screen Options and
 Help tabs. That was true back with Jen’s original user testing, and it is
 true today.

 > Regarding enabling dragging only when the Screen Options tab is open, do
 you think it would work well if there is an easy way for plugins to
 control it? Perhaps a PHP filter that outputs a js setting?

 No. I think the ability to move meta boxes should not be hidden behind a
 lock/unlock state, anywhere, ever.

 > This also leads to some very rare edge cases as dragging duplicates the
 elements IDs, etc. (think there is an old ticket about this).

 Then this bug should be addressed on its own ticket. This change doesn’t
 even fix that anyways.

 > In WP 5.5 two new buttons were added for each postbox/screen element to
 allow arranging without needing to drag. That nicely enabled keyboard
 users to arrange the screen elements. At the same time the new buttons
 introduced about 10-15 more virtually useless "tab stops" so now the users
 have to tab more to get through them. Again, that's not a "huge deal" just
 makes things a bit more lengthy/difficult.

 That approach being undesirable has very little to do with this approach
 being undesirable. And somehow this actually goes from bad to worse, and
 obfuscates the problem completely instead of addressing any of the actual
 quirks that do not appear to have their own Trac Tickets anywhere anyways.

 > Dragging/arranging of postboxes was (perhaps) useful on the old Edit
 Post screen, mostly to drag a postbox from the right column to under the
 editor and back. Initially it was somewhat useful on the Dashboard. That
 was long ago, when it was possible to set up to four columns there (before
 "responsive styling" was possible). Later the CSS was updated and made
 responsive, and the column setting was removed from Screen Options. Being
 able to drag/arrange screen elements on the Dashboard has been of a
 questionable usefulness since then.

 To you, perhaps. And the column setting makes perfect sense to be in
 Screen Options – it is a screen option. It could also be a user
 preference, which Screen Options is also frequently used for.

 There are numerous plugins who have not adopted the block editor and
 continue to use the legacy one because blocks do not make sense, and
 because Gutenberg UX and a11y is still so bad, many simply can’t afford to
 retrain their users and customers on it.

 Some plugins may never do so, no matter how bad you try to make the old
 experience on purpose, and I have to think that’s really what’s happening
 here, because there is no way this change improves the legacy meta-box
 experience, yet you’re asking contributors who are defending against this
 regression what compromises they would accept so you can push this
 through. My answer is zero compromises.

 > It was just the most logical way to fix and enhance the above mentioned
 points (that should have been done many years ago).

 This approach is not logical. It is highly illogical. It is neither a fix
 nor an enhancement. It should never happen, and should not be allowed to
 happen.

 I’m also very worried that it is still possible today for a single person
 to remove a pivotal piece of WordPress UX like this, hinting at a desire
 to abolish it completely, inside of a ticket with no related discussion -
 not even a nod of approval. Beta isn’t for getting feedback and then
 seeing what sticks; it’s for tightening things up that are already mostly
 good to go.

 > What about keeping the "mode switch" mechanism

 Why? Show us any other software people use with a keyboard and a mouse
 that requires unlocking the ability to customize it, and there will be 5
 more where it’s not necessary. This is a solution in search of a problem,
 and it’s not a good solution to a non-existent problem.

 IF, and that’s a big if, the actual problem is related to touch screens
 and mobile users on small screens, that should have been the emphasis of
 the ticket, and that specific issue should be targeted and resolved. And
 it needs to be done without massively nerfing the experience of literally
 everyone else. Cursors are never going away. Everyone deserves a first-
 class experience.

 I can’t believe I’m going to say this (the metaphor makes me sad) but here
 goes – people with the devices and dexterity to safely navigate meta-boxes
 all this time do not need anyone to save them from abusing something
 they’ve been safely using. Those users need to be left alone. The issues
 that exist for different audiences need to be addressed specifically for
 them in such a way that they are equally empowered.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50699#comment:32>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform