Truncation is not a good strategy for responsive list tables

[helen]

Our current strategy for dealing with list tables on narrow screens is to just chop off columns. This is terrible for a number of reasons:

• We use CSS and column classes (that are based on the column name) to hide things at fairy arbitrary breakpoints that have nothing to do with the sizes of the columns. The intent is not easily understood and is not contextual to the type of content being displayed in the list table in the first place, leading to conflicts between different list tables. This also makes for unpleasant CSS that is difficult to maintain.
• If we presume that a significant percentage of narrow-screened browser usage is also on limited data plans, it is silly that we're loading all this markup that goes for nothing, and require another page load to see information that the user may need to make a decision as to what to do next.
• Custom columns get no consideration whatsoever, leading to particularly poor list tables outside of the built-in ones.

Related:

• #25408: Ability to specify that a list table column is "primary" - this is also important here, as this becomes the column that is always shown
• #26302: Specify display priority for list table columns - likely a wontfix if we get rid of the truncation strategy

[helen]

The attached screenshot is still my proposal, from experiments on #18198 back in 2011. The essence of the technical method is to set table cells to display: block, add a data attribute on cells and use :before with CSS attr() (we could also do this in JS, but it's actually a fairly well-supported CSS function), add a JS expand/collapse toggle, and do some other styling. I am not married to this and it reflects an old admin design; other strategies and thoughts more than welcome. We'll be discussing this in weekly meetings beginning later today as well.

[helen]

In 32687:

Media: move the thumbnail into the title column in list view.

This gives us more space for the title and row actions, and will make a responsive list table enhancement significantly easier.

props bradt for the initial patch.
fixes #29993 and #32255. see #32509 and #32395.

[stephdau]

Since the thumbnail is always a square in the column, we could float it to the right and gain vertical space back, too.

See first row, at multiple width, in ​https://cloudup.com/cbebr9hANXf

[helen]

Replying to stephdau:

Since the thumbnail is always a square in the column, we could float it to the right and gain vertical space back, too.

Hmm I'm not sure what's up with your screenshots - the comments column should be gone and the image fixed on the left (scannability). CSS cache?

[afercia]

Worth considering the thumbnail is not always a square. Just set an header image, for example in Twenty Thirteen, applying the crop with the suggested image dimensions or crop one in the image editor using "Apply changes to: Thumbnail".

[stephdau]

Replying to helen:

Replying to stephdau:
Hmm I'm not sure what's up with your screenshots - the comments column should be gone and the image fixed on the left (scannability). CSS cache?

Hahah, lol, ok, your work makes a lot more sense now: ​https://cloudup.com/cYX7xjQfTrE
I couldn't understand why that thunmbnail was sitting on top. :)
Never mind then.

[afercia]

Sorry, re my previous comment what I meant is the cropped thumbnail height is wrong, and yes the width is now fixed (screenshot was taken before last commit).

[stephdau]

Replying to afercia:

Sorry, re my previous comment what I meant is the cropped thumbnail height is wrong, and yes the width is now fixed (screenshot was taken before last commit).

Seems all good now. The image's height is set to auto, and width to 60px (with a max-width of also 60px), in current trunk: ​https://cloudup.com/cy8wTCDo1Yo

[stephdau]

Note that the 2nd file in the list in ​https://cloudup.com/cy8wTCDo1Yo is also a cropped file, with portrait-like proportions (Twenty Fifteen vertical "header" image), rightfully displaying as a square here.

[stephdau]

Happy to report that quick-edit shouldn't give us trouble with our own collapse/expand, provided it adds its own row and hides the listing one: https://core.trac.wordpress.org/browser/trunk/src/wp-admin/js/inline-edit-post.js?rev=32694#L132

The proposed UX doesn't change our row structure, so whatever we do to it can/will be self-contained.

[afercia]

Replying to stephdau:

Note that the 2nd file in the list in ​https://cloudup.com/cy8wTCDo1Yo is also a cropped file, with portrait-like proportions (Twenty Fifteen vertical "header" image), rightfully displaying as a square here.

Just to clarify, it depends on the existing sizes. Given a requested size of 60x60, it will try to pick up the image which is "closer" to that size. In my case the cropped image had an height of 53px which is closer to 60px than the actual "thumbnail" size which is 150x150.

[helen]

32395.diff​ is a rough patch that shows the concept at work on the posts list table - it's got plenty of not very pretty spots both visually and in code, and I think it breaks Quick Edit. There's a crufty bit where I changed the Comments text to a long string and forgot to remove before uploading the patch :) However, wanted to put it out there for early thoughts and reactions, particularly on the interaction and visual fronts. Screenshots are from iPhone (particularly ugly) and OSX Firefox.

[stephdau]

My only beef is with the arrow (expand/collapse), as I think it's going to make for an awful click target on mobile. See ​https://cloudup.com/cuKGbFI8XmA, with the circle being what is estimated to be a finger's contact area (per Chrome's device emulation tools).

[stephdau]

I now notice that the screenshot tool didn't capture said circle, but it's hard to click the arrow without triggering the checkbox instead.

[helen]

Yeah, it's definitely too close and doesn't meet touch target guidelines at all - maybe a different placement would allow it to be bigger without creating a bunch of whitespace? To the right, maybe, like other expanding UIs (accordion, widgets)? Will need good accessibility review on this when it's more fleshed out, too - I'm monitoring keyboard accessibility but only barely understand how to navigate and evaluate with a screen reader. I used a button, at least :)

[celloexpressions]

The expand/collapse concept is good, and would probably be a good idea to consider auto-accordion-ing it since this is on mobile (close other open sections when opening a section - Menu Customizer does this for menu items to help with focus and save space). I'd definitely put the arrow on the right (as it matches existing conventions through the admin), then with adequate padding the small icon would be less of an issue. I'd also put the action links within the toggle, leaving the primary edit action available with one tap via the post title. Not sure how fun that'll be with CSS only but definitely doable with JSS or if that's reworked a bit in general.

[melchoyce]

Replying to celloexpressions:

I'd definitely put the arrow on the right (as it matches existing conventions through the admin), then with adequate padding the small icon would be less of an issue.

+1

[helen]

I feel like I'd be frustrated about having to toggle to get to a quick edit or preview link, as I'm way more likely to be doing that than the full editor on, say, my phone. Not sure, though. Possibly worth exploring, wouldn't be a huge change if we keep on with the current method. Continuing work on this, a little preview GIF of the possibilities of a relatively small change, touch target is 40x40:

[helen]

Oops, didn't finish my comment. The above looks fine with the normal-sized arrow (20px), so should probably do that because the bigger size seems really heavy. Inline edit is showing now in what I've got, though I think we should collapse the row if it was expanded so cancel and save visually appear the same. Hidden columns need handling, likely need to do better than an inline display: none for those and commit that separately.

[helen]

Hidden columns are handled via class as of [32724].

[stephdau]

I <3 the arrow on the right. I thought the same post-comment last night, but apparently forgot to suggest it. Looks/feels awesome.

[helen]

32395.3.diff​ is a testable patch for the posts/pages list tables. The most important part is how the interaction feels, particularly natively on touch devices, then how it looks, and then the code (which was not created to be perfect). In particular with the CSS, do we need to worry about performance aspects with the :not pseudo-class? Browser support is not a worry; it's supported in all browsers that support media queries.

Patch affects all list tables, so some of them are probably somewhat broken by this patch. It does deal with quick edit, hidden columns, and long column names (truncated). Here are things I know need consideration:

• Column names can contain HTML or otherwise not really be a label (cough, comments). The patch manually deals with comments, but that seems suboptimal, especially once you get into custom columns. Having a separate label for this also feels a bit silly, though.
• Accessibility, particularly screen readers.
• Custom list tables that don't define a primary column - we probably need to figure out a fallback of some kind, or else nothing is going to show at all.
• Does handling it accordion-style (only one open at a time) make sense? Are users ever looking to reference more than one at a time?

And finally, a preview GIF (I don't know what I mis-clicked at the start, if it's consistent we should look at that too):

[obenland]

The small arrow top aligned in the big tap area feels a little off. I understand why it's the way it is and don't have a better solution, but it just doesn't feel right.

Toggling Quick Edit, I noticed how I went for the small arrow to toggle it close again. Given how QE is built separately from the list, I'm not sure how feasible it is to add a toggle there too, but being able to close it without having to scroll down to find the buttons would be good.

I think I'd prefer it to be accordion style. It's less clutter, I don't get as easily overwhelmed.

For lists lacking a primary column, a good guess might be the first column after the checkbox.

[hugobaeta]

As we discussed in slack chat, since the quick links will all be permanently visible on mobile, this could use some restructured type hierarchy.

I propose increasing title font-size to 18px (also remember to increase the row padding), and reducing the opacity of the quick links to 0.8. Here's an inspector-made quick mockup:

[helen]

I don't know how it is that the patch still applies but it does. Refreshed in 32395.4.diff​ anyway.

[helen]

32395.5.diff​ is close to a first run, or even possibly a first run if we're comfortable with fixing the following afterward:

• Installed themes (multisite) and plugins list tables already had special treatment to show all columns all the time, so they don't need the toggle or data attribute label.
• Should we make titles larger, like plugins and themes? Example: ​http://s.hyhs.me/bleX
• Custom list tables that don't define a primary column show nothing in the collapsed view. We need to figure out how to handle a fallback here - perhaps the first column that isn't a checkbox.
• The special case for the post comments column because the "label" for it contains HTML.
• Any accessibility concerns, particularly screen readers.
• Should we do accordion style?
• Not sure if I made all strings translatable (can be handled pre-commit or in a new patch).

Please test and note anything else you might notice.

[ryan]

Visual survey and testing notes.

​https://make.wordpress.org/flow/2015/06/25/a-visual-survey-of-list-tables-with-32395-5-diff-iphone-6/

[helen]

In 33016:

List tables: A better responsive view.

Instead of truncating columns, the data that's already in the markup can now be toggled into view. Only seems appropriate to celebrate four years of contributing by finally doing the first thing I ever mocked up.

Known issues / concerns:

• Custom list tables that don't define a primary column will show nothing at all. These are not extremely common, as WP_List_Table isn't really recommended for plugin consumption, but it happens. We need to come up with some kind of fallback.
• Some visual elements, particularly whitespace, could use refining.
• Needs a11y review.
• Touch performance on iOS feels sluggish - is there anything we can do about that?
• Would this be better accordion-style (only one expanded at a time)?
• Is wp_strip_all_tags() good enough for column titles that have HTML in them? It's essentially a workaround for the fact that core's comments column does that for the icon, which maybe it shouldn't. Perhaps worth another ticket, as a markup change would be fairly independent.
• Visual hierarchy is not great when expanded (also worthy of another ticket).
• Quick edit now becomes noticeably more annoying to cancel out of, as you have to scroll all the way down and you lose your position from before it was opened. Again, worthy of another ticket.

props Michael Arestad, helen.
see #32395.

[obenland]

Just noticed that the .toggle-row button shows up in the comments list in edit.php. See screenshot above.

[afercia]

The plugins table needs some attention when there are updates on active plugins, also the standard active plugins (the ones with blue border and no updates) need some tweaking for the checkbox position.

Related: #26167

[ryan]

​https://make.wordpress.org/flow/2015/07/05/visual-survey-of-list-tables-iphone-6/

[helen]

In 33098:

List tables: Ensure the no items message appears on narrow screens.

fixes #32900. see #32395.

[helen]

In 33099:

List tables: Get rid of double borders for plugins and themes on narrow screens.

see #32395.

[helen]

In 33101:

List tables: Account for comments being reused on the post edit screen.

Adding the .wp-list-table class gets us a few responsive goodies for free. And now it won't show a strange button outline.

see #32395.

[helen]

The above commits should fix the things that were reported here after the first run commit. Most of my questions from 45 still stand - the first should be addressed in #25408 soon.

[hugobaeta]

minor tweaks to the focus styles. Needs more extensive testing I think, but the idea is there:

[ryan]

32395.8.diff isn't rooted at src/ so grunt patch can't handle it.

[sunnyratilal]

• select elements should have the same font size as other input elements

[helen]

@sunnyratilal - is that somehow a consequence of work that's happening in this ticket?

[sunnyratilal]

@helen - it's happening on master as well as nightly. Should I open another ticket?

[helen]

Replying to sunnyratilal:

@helen - it's happening on master as well as nightly. Should I open another ticket?

As far as I know it's completely unrelated to this ticket, so yes. I would also check 4.2 to see if it's different there.

[helen]

In 33146:

List tables: Better focus styling for the row toggle.

This circular focus styling could probably be expanded to other areas of the admin.

props hugobaeta.
see #32395.

[helen]

I'm marking this as fixed - new tickets for new issues, particularly anything from comment 45 that still stands.

[ryan]

Focus style, expanded, macnchrome

[ryan]

Focus style, collapsed, macnchrome

[ryan]

I see focus styling on Macnchrome but not on an iPhone 6+.