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

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