Fix and improve arranging metaboxes

[azaozz]

Follow-up to #49288.

In 5.5 the drop-areas when dragging/arranging of metaboxes on the Dashboard and the old Edit Post screen were fixed/improved. However that introduced an always visible drop-area on the Dashboard when only one metabox is visible.

Seems better to fix that bug and at the same time improve/enhance how metaboxes are dragged/moved/arranged in general.

[azaozz]

Generally the dragging/arranging of metaboxes functionality is part of the "Screen Options". It is not "primary" or needed for the application to work, and is seldomly used. In that terms metabox drop areas should (probably) only be visible when the "Screen Options" tab is open.

It also seems to make sense to disable dragging/moving of the metaboxes when "Screen Options" tab is closed.

[pbiron]

However that introduced an always visible drop-area on the Dashboard when only one metabox is visible.

I may be misunderstanding this, but even when there is only metabox visible, I may still want to drag it from the 1st column and drop it in the 2nd.

So, I think having the drop areas visible regardless of the number of visible metaboxes is not a bug.

[azaozz]

Replying to pbiron:

I may be misunderstanding this, but even when there is only metabox visible, I may still want to drag it from the 1st column and drop it in the 2nd.

Right, this is going to be "fixed" with this ticket. All drop areas should be visible when Screen Options are open, and not visible otherwise. Also thinking dragging/arranging of metaboxes should not be possible when not setting the screen options.

On the code side that means Sortables will be enabled only when the screen-meta-active class is present on the button#show-settings-link.

[afercia]

All drop areas should be visible when Screen Options are open, and not visible otherwise.

I'd agree this would remediate to a historical inconsistency, where the visibility of the drop areas always worked differently in the Dashboard and in the Classic editor page.

I do think that the drop areas should be visible also while dragging though, which is one of the main purposes of the changes introduced in 5.5

Also thinking dragging/arranging of metaboxes should not be possible when not setting the screen options.

Hm, I think we should think a bit more in depth at this :) Making it behave that way would likely make re-arranging very difficult with keyboard only.

[azaozz]

Replying to afercia:

I do think that the drop areas should be visible also while dragging

Of course. This is also the default when using Sortables, users should be able to see where to "drop".

Also thinking dragging/arranging of metaboxes should not be possible when not setting the screen options.

Hm, I think we should think a bit more in depth at this :) Making it behave that way would likely make re-arranging very difficult with keyboard only.

Yeah, this will be a change to how it works currently. Thinking the Screen Options tab need a bit more text/explanation what is it for and what can be set/changed. Currently it only has "Boxes" and a row of chackboxes underneath. Not that helpful...

Screen Options are rarely set/changed. Many users don't ever look there, and if they do, it is not very clear. Thinking that adding some text at the top (a subtitle?) would be beneficial. Also explaining that "boxes" can be enabled/disabled by clicking on a checkbox and arranged by dragging or clicking the arrows in the box heading would make it a lot easier to understand.

[afercia]

Regarding the visibility of the Sortable areas, quoting some considerations from #49288 that maybe worth considering in this ticket.

1
On the dashboard, there's some JS in place to make the Sortable areas not visible when there's only one visible postbox. Historically, this was the case for the subscriber role. Also, users can always hide all postboxes except one. The JS implements a check for visible == 1 where visible is the amount of visible postboxes.
However, since the introduction of the "WordPress Events and News" dashboard widget, this check doesn't make much sense because the subscriber role now sees two widgets by default. At the very least, it should check for 2 or the whole behavior be rethinked.

2
In the Classic editor page and everywhere else the advanced Sortable area is in place, I think it's important to take into consideration this historical reconstruction from @azaozz, see: ticket:49288#comment:72

Right. The drop areas on the old Edit Post screen are actually three. However the second and third are always shown together. If I remember correctly the reason the third is three is that postboxes added by plugins were put by default in it; at the bottom under the editor. Also think at some point (over 10 years ago) that area used to be shown separately, but now is always shown together with the second area. So when dragging of postboxes was added to that screen, the three areas were kept as back-compat, but the third was (mostly) disabled. The users could drag boxes out but there's no reason for them to add boxes back in it, as they would show and work in exactly the same way as when in the second area. In that terms the changes here can either maintain the previous behavior or make the third area "droppable" again. This won't change how the screen works.

So maybe one option could be considering to remove the advanced area entirely.

[afercia]

This ticket was discussed during today's accessibility bug-scrub: to make sure all tickets milestoned for 5.6 do have an owner, @azaozz would you like to take ownership? :)

[azaozz]

In 50699.diff:

• Fix dragging of postboxes/metaboxes on the Dashboard and Edit Post screens. Change it to work when Screen Options tab is open.
• Show the dashed outlines of the "droppable" zones (including the "Drag here.." text), and the up/down arrows on the postbox headings when the Screen Options tab is open. That makes arranging of the UI elements easier.
• Add some explanation text to the Screen Options tab.

[azaozz]

As discussed on Slack yesterday (link above), going to commit this now to make it easy to test.

[azaozz]

In 49179:

Fix and improve arranging of postboxes/metaboxes:

• Enable arranging only when the Screen Options tab is open.
• Prevent accidental/unintended dragging. Seen it happen mostly on laptops when using the mousepad/trackpad.
• Improve discoverability and usefulness by always showing the "drop zones" outline when postboxes are draggable/arrangeable.
• Add some (brief) explanation to the Screen Options tab helping the user understand what options are available and how to change them. This is especially helpful for screen reader users to give an idea how to use the screen options and what to expect.
• Fix/enhance some of the code in postbox.js and make it coding standards compliant.

See #50699.

[johnbillion]

In 49180:

Administration: Fix a coding standards issue after [49179].

See #50699

[hellofromTonya]

Per scrub today, Sergey suggested to change this ticket to task as it can then go past Beta 1.

[helen]

Is there a plan for letting existing users know that moving metaboxes is now only when Screen Options is open? I'm not sure I would ever discover that as an existing user and would be convinced everything was broken if I updated with no context.

Other than that, I noticed a couple things:

• The draggable area outline stays visible after you close screen options again.
• The move cursor still shows on hover when not in screen options mode.

[azaozz]

Replying to helen:

Is there a plan for letting existing users know that moving metaboxes is now only when Screen Options is open?

As with other (minor) enhancements this will be in the release notes in the "What's new" section. Note that until now moving of metaboxes was an extremely hard feature to discover. Pretty much the discovering was only by accident. Then, even if the users knew about it, very very few would ever move/rearrange metaboxes (was also considering to remove it on the Dashboard screen, but it has been there for ages).

A significant part of the enhancement here is that moving of metaboxes is now very apparent, both visually (the "drop areas" dashed outlines) and it is described as an option in the Screen options tab.

Other than that, I noticed a couple things:

• The draggable area outline stays visible after you close screen options again.
• The move cursor still shows on hover when not in screen options mode.

Hmm, seems to be working here. This is controlled by CSS (a class is toggled on the body). Do you see any js errors, or perhaps may be caching?

[knutsp]

Well, I may be one of the very, very few using this dragging a lot, especially for new sites and/or new users. Have been teaching my clients this, how easy it is, since "forever".

The featured hat has been, and still is, hard to discover, is "Screen Options". Have seen users just closing unwanted meta boxes and stacking them lower right, not turning them off.

I'm not convinced restricting this draggability to only be possible when "Screen Options" is open, is a step forward. Empty column boxes has never bothered me.

I read almost all tickets and comments here on Trac, but missed the "solution", not only suggested, but committed. I feel this should have been discussed more broadly. It's based on assumptions, and believe them not to be correct.

[azaozz]

Replying to knutsp:

Well, I may be one of the very, very few using this dragging a lot

Ha, interesting! Could you tell a bit more about how many times you drag/arrange metaboxes on the Dashboard of a particular site, and what purpose it serves? From my (pretty limited) testing none of the users I talked about knew it was possible, and even after I told them most tried it and "shrugged it off" with something like "Aahh, okay, nice"...

Historically arranging postboxes on the old Edit Post screen was somewhat useful in some cases. Unfortunately it was really hard to discover. Then it was added to the Dashboard as an "enhancement" but was never refined/made really good there. Now that the old Edit Post screen is obsolete, having this only on the Dashboard is of a "questionable usefulness" :)

I'm not convinced restricting this draggability to only be possible when "Screen Options" is open, is a step forward.

What would be a "good step forward" for there? Arranging of screen elements on the Dashboard is a "screen option". Frankly I'm 50/50 on how useful it is to have at all though.

[pbiron]

Replying to azaozz:

Replying to knutsp:

Well, I may be one of the very, very few using this dragging a lot

Ha, interesting! Could you tell a bit more about how many times you drag/arrange metaboxes on the Dashboard of a particular site, and what purpose it serves?

I wouldn't say that I rearrange dashboard widgets "a lot", but it's not unusual for me.

The common reason is after activating a plugin that adds a new widget that, for whatever reason, "messes up" the arrangement of widgets I had previously. I'll then iterate on different arrangements with the new widget until I find something that works for me. Then won't rearrange them until I install yet another plugin that adds another widget.

From my (pretty limited) testing none of the users I talked about knew it was possible, and even after I told them most tried it and "shrugged it off" with something like "Aahh, okay, nice"...

I'm probably not typical, but I can't remember a time when I did not know that they could be dragged/dropped :-)

[johnjamesjacoby]

Sorry @azaozz, my friend, but I dislike r49179 and the general direction this is going.

Remember, that the meta-box API is not specific to Posts. It's used in Media and mocked in Comments, but the API itself is flexible enough to be used on any screen by plugins that register them. That means this affects more than just Core pages - it's every plugin that uses meta-boxes.

Anecdotally as a user, I rearrange meta-boxes all the time, and as a developer I rely on the meta-box API extensively in several plugins that anticipate the ability to easily rearrange them. BuddyPress, bbPress, WP User Profiles, Sugar Calendar, Easy Digital Downloads, all are using them with the expectation their meta-boxes can be easily dragged and dropped.

After #49288, what is in trunk now is actually the worst of both worlds – there is no keyboard navigation and there is no mouse navigation, and it's made extra weird that they can still be toggled open & closed but cannot be moved. All users now lose the ability to obviously customize screens that use meta-boxes, which is a fundamental UX that's been in WordPress since at least 2007.

I'm not sure I would ever discover that as an existing user and would be convinced everything was broken if I updated with no context.

This was me for 30 minutes this evening. I started by assuming some code of my own creation had broken all meta-boxes across my multi-network installation. After a brief panic and after deactivating all plugins, I narrowed it down to this change. It never occurred to me that "Screen Options" was the key to re-unlocking this behavior. There is simply no way this is easier for anyone.

In addition, because of the way this JavaScript is written and enqueued together, I don't see a reliable way to bring the old functionality back with a plugin without forking the old file, dequeueing this one, and hacking some JavaScript to remove the new text in Screen Options.

However that introduced an always visible drop-area on the Dashboard when only one metabox is visible.

Suggest to fix this as an isolated concern.

Seems better to fix that bug and at the same time improve/enhance how metaboxes are dragged/moved/arranged in general.

Suggest to deeply reconsider this elsewhere, perhaps on #51419.

[garrett-eclipse]

Yes, I'll have to second that this change was off putting for myself. It took me reading the ticket to learn about the Screen Options toggle and find that odd and cumbersome. I don't see why we can't just have the existing drag-drop. Or at worst change the drag handle to a single icon beside the expand icon as that's a convention that's not new.

[margaretschneider]

Hey there, sorry, I have to nth what @knutsp, @pbiron, @johnjamesjacoby, and @garrett-eclipse mentioned. A colleague let me know about this proposed feature change, and I'm concerned that this is going to be an issue in a few ways. I see that it's well-intended, and I respect the work you've put into figuring out how this might work, but I can say, as a trainer at an agency who has taught more than a thousand people to use WordPress at this point, on many large publishing teams across the U.S. and beyond, using both the Classic editor and the Gutenberg block editor, there are a few issues here.

First, Screen Options is often very difficult for people to even notice is there; it's unobtrusive bordering on invisible, and a large number of users, even after they've been taught about its existence repeatedly by an experienced trainer, forget about it or have trouble finding it. Sometimes they look right at it and just don't see it, because it looks like part of the browser UI, or they scroll down the page and then don't see it. Making something as essential as the ability to drag and drop items dependent upon being able to access Screen Options breaks patterns of visual personalization that are seen across the CMS. I'd guess it would mostly result in folks newer to the CMS rarely if ever dragging and dropping items, and the dashboard losing what little flexibility and utility it has for most users.

Among other outcomes, it will likely make what you're describing, folks not making use of the ability to drag and drop things on the dashboard, the default behavior, and that would be a choice we're making for them. I hear that in your experience, being able to easily drag and drop items on the dashboard hasn't been essential, but for others, it is. I think making this harder to do is a step away from, not toward, improving the dashboard.

Teaching people about Screen Options is a default part of our WordPress trainings, but as noted, folks still don't always use it, nor do they frequently need to, and it's increasingly something we don't get into in great detail with many clients. There simply isn't a lot that's useful or relevant to most folks on the dashboard from the start (which is its own issue; see below), and the only other place most folks I work with are likely to encounter Screen Options now is in places like the Posts list or the Classic editor interface for specific post types. In both of those places, we typically customize the interface to display certain types of meta boxes by default, depending on the needs for that post type, so folks don't often need to use Screen Options to customize their view and can safely ignore it. In many cases, as a result, Screen Options feels vestigial, and certainly isn't somewhere folks would think to go to enable drag-and-drop capabilities for meta boxes.

I entirely agree that the dashboard could be made more useful in most WordPress installs, and that it doesn't look amazing aesthetically when items aren't in those empty spots surrounded by a dashed border. I hope folks can work together to envision how we might make the dashboard more useful and surface more info there that's actively useful to users in the future. But forcing users to remember an arcane extra step to be able to personalize it isn't an ideal way to solve that, and will make it less likely that folks will make use of this personalization functionality.

Second, being able to drag and drop boxes to personalize the order of items in the CMS is a feature common to not only items on the dashboard, but also to meta boxes in the Classic editor interface and the new Gutenberg block editor interface. This is something we've trained, again, hundreds of users to do in those areas, and as @helen noted, most of those users are not likely to look at release notes to learn about changes to the CMS. They will assume it's broken or that they're doing something wrong, and that will diminish their confidence in the CMS and their own abilities. Tiny changes like this that make the CMS less usable and, as others alluded to above, less accessible by adding steps and hiding options can inadvertently undermine our efforts to foster adoption of and advocacy for the CMS.

Third, the new Gutenberg block editor interface does not have Screen Options as a concept anymore (it's hidden away in a different form), but you can still personalize the interface by dragging and dropping meta boxes to rearrange them. We make heavy use of meta boxes to provide options for adding metadata to articles for our publishing clients, so meta boxes aren't a concept that's wholly going to go away immediately with the block editor. As others noted, many plugins add meta boxes as well. The options for personalizing the article editing interface by choosing which meta boxes and features of the interface are even visible in the block editor now live under Options, at the bottom of the vertical "..." More menu, which folks are even less likely to discover unless they're specifically trained to do so. I always point it out in block editor trainings, but I don't know how many users make use of it. Many users do quickly and readily understand how to drag and drop meta boxes in the article editing interface, though, and frequently comment on its convenience.

Overall, I feel like hiding the ability to drag and drop boxes on the dashboard would be a change for the worse that only marginally improves aesthetics, without much clear benefit in terms of usability. And it has several downsides in terms of consistency of UX elements within the CMS. As we move toward a future in which whole-site editing is possible and more areas of the CMS allow things to be dragged and dropped, such as in the Customizer for menus and in the block editor for meta boxes, we are taking a step backward if we require a set of arcane steps to enable dragging and dropping interface items.

[azaozz]

Hi @margaretschneider, @garrett-eclipse, @johnjamesjacoby, @pbiron, @knutsp, thanks for the feedback :)

The reasoning behind this change is that:

1. Arranging of screen elements is a "screen option".
2. This functionality is not essential. It is not even "secondary" as that would be folding and unfolding the postboxes/screen elements by clicking on their headings. The "third-grade" functionality would be hiding and showing of postboxes/screen elements by clicking on the checkboxes in the Screen Option tab. So this is a "forth-grade" functionality for the screen that is very rarely used, typically 1-2 times for the site's "lifetime" if the user discovers it.
3. If the dragging/arranging of screen elements is constantly enabled, the screen is in some sort of a "hybrid" state, both "production mode" and "options setting mode". That' doesn't seem to be a huge deal but makes the UI somewhat illogical.

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.

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.

Making something as essential as the ability to drag and drop items...

I'm really curious why do you consider the ability to arrange screen elements so essential. A follow-up question would be to try to discover how many times the users that you've tutored actually used that. My (limited) research was not quantitative, it was done by directly interviewing few users. None of them seemed particularly interested in this. Would be great if you could provide some more info :)

Sorry @azaozz, my friend, but I dislike r49179 and the general direction this is going.
...
Anecdotally as a user, I rearrange meta-boxes all the time, and as a developer I rely on the meta-box API extensively in several plugins that anticipate the ability to easily rearrange them.

I'll have to second that this change was off putting for myself.

Right, this change will "take by surprise" everybody that's used to arrange screen elements often. Frankly I'm not "married" to this either. It was just the most logical way to fix and enhance the above mentioned points (that should have been done many years ago).

Still, the screen being in a "hybrid" mode (setting the options/arranging the screen while using the elements) is not-so-good imho. This also leads to some very rare edge cases as dragging duplicates the elements IDs, etc. (think there is an old ticket about this).

So, what would be best to do here? :) I'm thinking that having some explanation text in the Screen Options tab is pretty essential to help with discoverability. Also, should probably stop calling these "Boxes" and use the more or less standard "Screen elements" instead.

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?

[knutsp]

I disagree with the non essentialness. It's more used and more useful than removing them. I see users move the less, or never, used boxes to the bottom, even when they know about "Screen options" (no so familiar).

It's quite common to change position of them on the dashboard, but also on CPT editing screens, like events or products, plus of course classic editor users (posts/pages).

I also use JJJ's plugin for a better user profiles, and as JJJ points out, the metabox API is general. I hope core soon will adopt it's own API for user profiles.

This "hybrid" state has been with is since "forever". Is there a way to fix the (accessibility?) issues but keeping this as is? I can't imagine Firefox disabling moving of tabs until you click a "Tab options" button, because "hybrid".

If this goes in, a pointer must be shown to guide users to "Screen options" (when trying to drag, preferably) and that panel must indicate that dragging boxes is now possible.

I feel this is an accessibility effort, if it is so, hurting accessibility for most.

[afercia]

Now that the old Edit Post screen is obsolete, having this only on the Dashboard is of a "questionable usefulness" :)

I'd argue that the Classic Editor plugin has more than 5 millions active installations (we don't know the exact number) thus the relevance of this feature on the "old" edit post screen is still very important :)

I do understand the reasoning that reordering should go in a special "mode" of the screen that is not the one used "in production". That makes sense to me and, for example, similar "mode switches" are already used in the Media Library screen for the "Bulk select" mode and in the Customizer.

However, the placement of this mode switch within the Screen Options panel seems far from ideal to me. It's really buried down in a place where most users never go.

Additionally, the new reordering buttons are a feature specifically introduced to solve an accessibility issue that existed since... forever. Making the keyboard interaction more difficult seems to defeat the purpose of the introduction of the new buttons. With this change, now keyboard users have to go through potentially dozens of additional tab stops to go back and forth from / to the Screen Options panel and the meta box they want to reorder.

Also mouse / touch users (at least 5 millions users) would find reordering more difficult simply because it's not so discoverable.

Ideally, the controls to reorder a meta box should be "in place" and not require to navigate with the keyboard most of the page to go to the Screen Options and then back to the meta boxes.

What about keeping the "mode switch" mechanism but, instead of burying down the switch within the Screen Options, use only one button placed in the meta box headers that switches the header to a "reorder mode"?

[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.

[joedolson]

After discussion during the Accessibility Team meeting on 23 October, we agreed as a team that we'd agree with the compromise proposed initially by Andrea, as described here:

1) Use a mode-switching button placed in the meta box header, rather than hidden in screen options.

2) On activation, the mode-switch reveals the reorder UI and enables dragging.

3) When enabled, headers would show the move buttons, a cancel button, and a drag handle in the header to make the available options clear.

Our proposed text label for the button would be 'Reorder'; though this could take some consideration to reach a final text.

[johnjamesjacoby]

After discussion during the Accessibility Team meeting on 23 October, we agreed as a team that we'd agree with the compromise proposed initially by Andrea, as described here:

This wasn't on ​the agenda. "5.6 beta 1 things" and "open floor" do not indicate to non-teammembers that decisions are being made.

It is unfair to the WordPress project and its users that decisions like this would be made without representation from people who have voiced opposition to it. I expect that everyone feels like what they're doing is right, and that they have someone's best interests in mind, but fast tracking decisions on the sly like this is not the correct approach.

This issue needs and deserves much more attention than it is getting.

Compromising everyone's experience is not necessary here, and I don't understand why the people pushing this through are ignoring that.

[joedolson]

Sorry; I misspoke. It was not in the team meeting, it was in the bug scrub preceding it. Having those back to back sometimes confuses me as to current context.

And there was no "decision" made other than those present agreeing that we could accept this compromise; this ticket, where we are conversing, is the place where a decision should be made.

[joedolson]

The idea that meta boxes would only be movable when screen options is largely unacceptable, for many reasons: the user experience for keyboard users would be extremely difficult; the discoverability is extremely poor; and the reduced available screen space to maneuver metaboxes would make organization more difficult. I can't see a way in which this change, as currently implemented, improves the experience for anybody.

The proposal from the accessibility team is how we could compromise to reduce the visual impact of the movers without compromising the usability of the system at this extreme level; but just *not* doing this would be something I'd find entirely acceptable, as well.

[johnjamesjacoby]

Chrome Inspector, highlighting draggable and droppable tabs

[johnjamesjacoby]

Attached above is a screenshot of Chrome's Web Inspector. Did you know the tabs I've emphasized can be dragged and dropped into whatever order you want them in? Whether you did or did not know this, it's a feature that exists, and has existed since nearly the beginning of the web inspector.

For all of the customizable preferences that Chrome Inspector does provide (and they provide extensive preferences compared to WordPress' Screen Options) tried for 10 minutes and could not find a way to reorder these tabs without using a cursor.

Do y'all believe Chrome should do what is being suggested in this ticket, and lock this ability behind a click-to-engage toggle? If so, then our opinions on how software can and should work continue to be completely at opposite ends of the spectrum.

WordPress itself has so many other instances of UI that are draggable and droppable with the same design language as meta-boxes, the slope with this ticket is extremely slippery. Widgets. Menus. Customizer controls. They have alternative interfaces that do not compromise the simplicity of dragging & dropping, and this is absolutely not a single bit different.

[azaozz]

Replying to 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.

Ha, sorry about repeating myself. Seems not all people are "on the same page" here, was trying to help with that.

Revert this change and never look back.
...
A lot like most of the Gutenberg UI and UX, the logic behind this concept is fundamentally flawed...

Didn't know you felt so strongly about preserving the status quo and against attempts to make things work better...

Lets try to get to a common ground :)

Could you, and everybody that commented here, please answer the following question (from your personal experience using WordPress in production):

Is arranging of posboxes on the Dashboard screen a "screen option" or not? Please keep in mind that this is not the same as arranging of widgets on the old widgets screen as that set the widgets order on the front-end. It is not the same as arranging menu items when creating menus as that sets them to top menus, sub-menus, etc. For widgets and menus this is a primary functionality. Similarly plugins that reuse the same concept may use it as a primary functionality or for (non-essential) setting of the screen appearance similar to number of columns, etc.

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.

Yeah, I agree. From my limited testing most users don't look there. Nevertheless having just "Boxes" and a row of checkboxes there can be enhanced with some more explanation.

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.

Hmmm, ok, if users just "gloss over" the Screen Options tab, what's the point in having it in its current state? What would be a good way to improve/enhance it?

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.

Think there's some misunderstanding here. "pivotal piece of WordPress UX" as in arranging screen elements on the Dashboard screen? Also, this patch was committed to facilitate testing, please see comment:14, and the ticket was left open awaiting reviews and feedback. Negative feedback, when constructive, is very valuable too :)

[azaozz]

Replying to johnjamesjacoby:

Attached above is a screenshot of Chrome's Web Inspector. Did you know the tabs I've emphasized can be dragged and dropped

No, I didn't know that. Been using the browser tools/console since the Firebug days, but never occurred to me to try that.

Frankly I don't think this is a good feature, being so unintuitive and hard to find...

[knutsp]

What you call this, Screen options, or rather preferences, is irrelevant. I'm talking about not removing the option to rearrange/move the boxes around, just by doing so with the pointer, as always. This is less cumbersome than opening Screen Options first.

The boxes may also be closed/opened. If moving is a screen option, then open/close is also a screen option. The "Screen Options" thing may be called "More screen options" if better semantics are important.

On a dashboard, moving info boxes according to personal preferences are quite essential. Even on editing screens, because there are so many added by plugins. And you don't yet if you will need them. Many are reluctant to go to screen options and remove them, since they are then not visible at all. Some (admins) are also not sure if this is for all users or just a personal preference. Moving seems less scary. And users are frequently scared of doing something they shouldn't have.

I do not agree that there is very big difference to moving widgets.

Stop this, revert it, and we may continue to refactor "Screen options", we need both general preferences and a container for unused boxes.

[johnstonphilip]

Hey all! Just wanted to throw out another thought, which is that on iPad, dragging a metabox is the same action as scrolling. Anecdotal of course, but I've seen accidental metabox moving happen on iPads a few times lately, mostly with my brother in law who just bought an iPad pro and demands it be used for everything now :D

[margaretschneider]

Is arranging of posboxes on the Dashboard screen a "screen option" or not? Please keep in mind that this is not the same as arranging of widgets on the old widgets screen as that set the widgets order on the front-end. It is not the same as arranging menu items when creating menus as that sets them to top menus, sub-menus, etc. For widgets and menus this is a primary functionality. Similarly plugins that reuse the same concept may use it as a primary functionality or for (non-essential) setting of the screen appearance similar to number of columns, etc.

No, I would not say this should be considered a screen option. If I had to describe what screen options are now, I'd say they're set-it-and-forget-it rules for which columns or boxes should even appear on a page, not for what order boxes should be in, and not for enabling the ability to move boxes. Screen options are meant to personalize the user experience at a high level, not for everyday use. As such, I typically suggest folks update screen options in one of a couple cases: 1. They're getting used to the CMS for the first time and going through some set-it-and-forget-it settings with the guidance of a trainer, to disable things the trainer knows they won't need to use, or 2. They've been using the CMS for a while and from their experience now know which things they're just never going to use as part of their workflow, so they're simplifying their display a bit.

As you suggest, the concept of screen options now isn't necessarily the way it has to remain. As knutsp notes, a lot of users are easily confused or concerned about whether their changes to interface items through screen options will apply for just them or for all users. The whole screen options concept could certainly stand some dedicated time and thought.

To address the second point in this paragraph, yeah, arranging boxes on the dashboard isn't the same as arranging menu items or widgets, but it's really important to remember that to everyday users, those things work the same way. It's a feature of WordPress that thought has been applied in a systematic way to keeping the user experience consistent throughout the CMS, and anything that would change that shouldn't be undertaken lightly. The underlying mechanisms and reasons for drag-and-drop capability in each location may not be the same, but the consistent functionality and appearance of items that can be dragged and dropped is an important cue to most users, just as consistent, semantic, easy-to-navigate markup is important to users primarily experiencing the site through a screen reader and keyboard. It's problematic to have elements that look the same in various areas of the site function in dramatically different ways, or to have to be trained to realize that certain elements can even be dragged and dropped. This should be to some degree self-documenting or at least intuitive, and a move to hide this functionality achieves the opposite.

This reminds me to some degree of the disparities that already exist across various user experiences, such as the disparate ways of handling menus and site appearance options in the Customizer versus under Appearance or Settings. The UX language of these areas could stand to be made more consistent, and will need to be addressed eventually on the road to full-site editing.

Adding the accessible navigation arrows for all meta boxes helps with discoverability of that feature, as previously discussed, though it sounds like the feature needs refinement to address the tab stop issue for keyboard users. While I can entirely see a rationale for removing those navigation arrows when only one box is left on the dashboard, as noted in the original post, I don't agree with extending that rationale to justify hiding those arrows by default on all boxes and restricting the ability to move all boxes to when a hidden mode is enabled. I think many of us are largely in agreement that most casual users couldn't locate screen options even if you trained them to multiple times, which I have. So hiding these options there feels to me like an overreach of what could've been (and could still be) a simple update to address the UI inconsistency you mentioned at first.

Hmmm, ok, if users just "gloss over" the Screen Options tab, what's the point in having it in its current state? What would be a good way to improve/enhance it?

I agree with the implication that Screen Options might not be the most useful thing in its current state. As I noted, because I typically work in instances of WordPress that have been highly customized from the get-go, with custom meta boxes and careful consideration given to what is actually necessary in each interface, Screen Options is frequently vestigial where it appears on the dashboard, in posts lists, and in the classic editor. In a less customized version of the CMS, it might have more utility to empower users to customize their own experiences, but it's definitely still not easily noticeable in its location, and as such, it's not a good place to put something like a mode switch.

I'm thinking about the iPad example above and a mode switch could be one solution to that problem, but another solution would be adding clearer and more targeted handles or drag strips for moving meta boxes, so accidentally dragging meta boxes could be easily avoided when someone is simply scrolling. "Drag and drop tangibility should be immediately visible" is literally the first rule of one set of guidance for drag-and-drop interfaces, for just one example. There are probably more visual and semantic ways to address this, while also solving some of the other discoverability issues described for drag-and-drop capability, without involving a mode switch.

"pivotal piece of WordPress UX" as in arranging screen elements on the Dashboard screen?

It's a little frustrating to kind of have to do battle on multiple fronts in this discussion, which keeps getting refocused on screen options alone and the expressed disbelief that anyone cares that much about the order of dashboard items. It's my understanding that a change to the way these boxes function on the dashboard has immediate implications for the functionality of reordering meta boxes in the classic and Gutenberg post editors as well. Is that not the case? If it is, this is actually majorly important functionality that could be changed as a result of what you say is a tiny feature update that you admit you don't have a ton of real-world data on (while those of us who train users frequently have a large amount of anecdotal info against it). That doesn't sound like a tiny change, and I do think consistency matters in this regard.

Many of us are in agreement that users might not even be able to find this mode switch if it's located under screen options, and I'd posit that users absolutely will not be able to find such a mode switch if it's located under Options in the Gutenberg editor, since that's tucked away under the "..." more menu. It's also unclear how such a mode switch would even function under Options in Gutenberg, because what you're proposing would be dependent upon Screen Options being open—but when its Gutenberg analogue, Options, is open, that precludes doing other things in the block editor such as rearranging meta boxes.

I'll say again, I think the dashboard could be better out of the box—more usable, with more immediately relevant information and options surfaced. I'll continue to beat that drum, but this proposed change isn't the kind of thing I'm suggesting.

---

Before the weekend, and before the most recent comments, what I was thinking was that I'm not entirely opposed to the other version of this solution that it sounded like at one point was discussed in the accessibility meeting above, where it's possible to go into a mode that's activatable from the meta boxes' headers themselves. But it does sound like that would still depart from the way meta box rearrangement is managed in Gutenberg, which could add confusion.

I recognize the accessibility challenges here, which some touched on, among which is that drag-and-drop interfaces should also have a way of being activated and used with the keyboard. Again, hiding that in screen options is the opposite of a solution to that problem, but adding a better way of activating the ability to move things seems like it might be good and also partly address the iPad/mobile scrolling use case. It would be nice if both could coexist, where you'd retain the ability to drag things around whenever, as now, since that's still the pattern in Gutenberg, but also have a way to do that that's more readily useable via screen readers and keyboard (and less prone to accidental reordering on tablet/mobile). I keep coming back to the thought that the pattern everywhere things can be dragged and dropped should include more readily recognizable and accessible handles for moving meta boxes. I tell people a million times that they can drag those around, and demonstrate it, but it's still not obvious you can do that from much besides the cursor change when you hover over meta box headers (even with the addition of the navigation arrows), and people always forget how to do it.

I think all of these aspects of this problem touch on larger issues that we'd do well to consider in their proper context.

[azaozz]

Replying to johnstonphilip:

Just wanted to throw out another thought, which is that on iPad, dragging a metabox is the same action as scrolling. Anecdotal of course, but I've seen accidental metabox moving happen on iPads a few times lately...

Yep, that's one of about half a dozen fixes here. Not a "huge deal" but pretty annoying and a nice UX improvement :)

[azaozz]

Replying to margaretschneider:

No, I would not say this should be considered a screen option. If I had to describe what screen options are now, I'd say they're set-it-and-forget-it rules for which columns or boxes should even appear on a page...

Hmm, okay, if arranging of screen elements is not a "screen option", then what is it? It's definitely not a "primary application feature" as in "you need to do it or the app won't work properly". It affects setting how this particular screen looks only for the current user (it's not a "global" setting). It's perfectly okay to never touch it/change it, in fact none of the users I interviewed has even done that.

The fact that none of them has arranged the screen elements wasn't really a surprise. It is a well known fact that most users, as many as 95%, never change the default options/settings of an app unless they really have to. This also explains why the users "just glance over" the Screen Options tab and never use it.

To address the second point in this paragraph, yeah, arranging boxes on the dashboard isn't the same as arranging menu items or widgets, but it's really important to remember that to everyday users, those things work the same way.

Yeah, perhaps some users may misunderstand this when using the old widgets screen. It would be pretty hard to misunderstand what dragging menu items on the old menu screen does though. However when setting widgets and menus in the customizer it is pretty impossible to make this mistake, there's instant preview, etc.

Looking for examples, in most apps dragging is used to set what buttons to show on the toolbar, and (optionally) the order they are shown. This is done from a dedicated settings screen. Selecting what you see on the screen, and in what order you see it are closely related, and are... screen options? :)

[azaozz]

Replying to joedolson:

1) Use a mode-switching button placed in the meta box header, rather than hidden in screen options.

2) On activation, the mode-switch reveals the reorder UI and enables dragging.

3) When enabled, headers would show the move buttons, a cancel button, and a drag handle in the header to make the available options clear.

Our proposed text label for the button would be 'Reorder'; though this could take some consideration to reach a final text.

Yeah, this sounds like an improvement especially for keyboard/screen reader users. Tried to add some (initial) code to implement it but seems there are few (unresolved) details. Assuming the Reorder button will be visible at all times on each screen element's heading, would it make only the current element "arrangeable" or would it turn on "screen options mode" for the whole screen. Both of these have some drawbacks and would need more thought...

On top of the above there is some very vocal, extremely negative feedback (that ideally should have been made earlier, this ticket has been open for months).

As WP is in beta, don't think there's enough time to address all of this. Seems reverting it now and hopefully addressing this as part of a more general improvement to how Screen Options work would be best.

[azaozz]

Hmmm, when reverting thinking to leave the short explanation (in the Screen Options tab) of how the screen options work. Having just "Boxes" there seems... confusing?

[azaozz]

In 49325:

Revert the improvenents to arranging of postboxes/metaboxes, [49179]. The current patch fixes about half a dozen problems, but seems more general improvements are needed to how Screen Options work.

See #50699.

[joedolson]

A few pieces of feedback following the A11y team meeting on 15 Jan 2021:

The team generally agrees that the current UX, while much more accessible and generally easier to discover, is definitely a little too easy to accidentally use, and adds a lot of persistent controls to an already complex interface.

Having a control to enable/disable metabox moving within the screen options panel makes sense, as these controls are not generally needed on an ongoing basis; it is our assumption, lacking user testing, that the majority of users only intentionally move meta boxes occasionally.

We'd like to simplify our prior proposal, and suggest that a control should be added to screen options that enables/disables metabox movers, and that this should globally toggle whether metaboxes are currently movable. Locking them in position when disabled will prevent accidental changes. By default, it should be enabled, however, for discoverability.

[hedgefield]

Fair points @joedolson and all. I've left my feedback on the matter in #51419.

With that perhaps we should close this ticket and move discussion there?

[azaozz]

Replying to joedolson:

Having a control to enable/disable metabox moving within the screen options panel makes sense, as these controls are not generally needed on an ongoing basis; it is our assumption, lacking user testing, that the majority of users only intentionally move meta boxes occasionally.

We'd like to simplify our prior proposal, and suggest that a control should be added to screen options that enables/disables metabox movers, and that this should globally toggle whether metaboxes are currently movable. Locking them in position when disabled will prevent accidental changes. By default, it should be enabled, however, for discoverability.

Yes, that seems the best solution here. Perhaps can also try to set this to disabled by default on touch screen devices to fix that super annoying long standing bug where the user would try to scroll but will move a metabox instead.

To help make the screen options more discoverable a notice can be shown the first time metaboxes are arranged. That would tell the user to use the screen options to customize the appearance of the Dashboard. Also, perhaps, it's time to make the Screen Options button a bit more prominent and add a "hamburger" icon there?

Any designers interested in driving these changes?

[joedolson]

I'd like to try and finish this in 6.7. That may mean deciding not to do it, but this has lingered in the state of "we have agreed on a path, but nobody has done anything" for too long! Taking ownership; but feel free to take it back, @azaozz, if you wish to shepherd it.

[azaozz]

Replying to joedolson:

I'd like to try and finish this in 6.7. That may mean deciding not to do it...

Sounds good! Yea, this needs another look, and a decision on how and what to improve for the best UX. I'll probably be able to help a bit if you decide to add some improvements.

[joedolson]

Well, it's a week before beta and I just haven't had time for this. I'm going to move it to Future Release; but I intend to move it into 6.8 when that milestone is available.