Make WordPress Core

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#32395 closed task (blessed) (fixed)

Truncation is not a good strategy for responsive list tables

Reported by: helen's profile helen Owned by: helen's profile helen
Milestone: 4.3 Priority: normal
Severity: normal Version: 3.8
Component: Administration Keywords: has-patch needs-testing
Focuses: ui, accessibility Cc:

Description

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:

Attachments (13)

Screen Shot 2011-09-10 at 4.10.03 PM.png (164.3 KB) - added by helen 9 years ago.
32395.diff (6.5 KB) - added by helen 9 years ago.
32395.2.diff (5.7 KB) - added by helen 9 years ago.
32395.3.diff (6.2 KB) - added by helen 9 years ago.
32395.4.diff (6.2 KB) - added by helen 9 years ago.
32395.5.diff (21.0 KB) - added by helen 9 years ago.
32395.6.diff (21.2 KB) - added by helen 9 years ago.
32395.7.diff (25.7 KB) - added by helen 9 years ago.
Screen Shot 2015-07-01 at 7.36.27 AM.png (49.7 KB) - added by obenland 9 years ago.
32395.8.diff (964 bytes) - added by hugobaeta 9 years ago.
minor tweaks to the focus styles. Needs more extensive testing I think, but the idea is there: [[Image(...)]]
32395.9.diff (1015 bytes) - added by helen 9 years ago.
list table focus styles expanded macnchrome.png (298.3 KB) - added by ryan 9 years ago.
Focus style, expanded, macnchrome
list table focus styles collapsed macnchrome.png (295.1 KB) - added by ryan 9 years ago.
Focus style, collapsed, macnchrome

Download all attachments as: .zip

Change History (79)

#1 @helen
9 years ago

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.

Last edited 9 years ago by helen (previous) (diff)

This ticket was mentioned in Slack in #design by helen. View the logs.


9 years ago

This ticket was mentioned in Slack in #design by helen. View the logs.


9 years ago

This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.


9 years ago

#5 @helen
9 years ago

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.

This ticket was mentioned in Slack in #core by helen. View the logs.


9 years ago

#7 follow-up: @stephdau
9 years ago

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

This ticket was mentioned in Slack in #design by helen. View the logs.


9 years ago

#9 in reply to: ↑ 7 ; follow-up: @helen
9 years ago

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?

#10 @afercia
9 years ago

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

https://cldup.com/7_h11MDIUH.png

#11 in reply to: ↑ 9 @stephdau
9 years ago

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.

#12 follow-up: @afercia
9 years ago

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

#13 in reply to: ↑ 12 @stephdau
9 years ago

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

#14 follow-up: @stephdau
9 years ago

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.

#15 @stephdau
9 years ago

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.

#16 in reply to: ↑ 14 @afercia
9 years ago

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
9 years ago

#17 @helen
9 years ago

  • Keywords has-patch added

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.

http://s.hyhs.me/bWQ5/image.png http://s.hyhs.me/bYVG/image.png

This ticket was mentioned in Slack in #design by helen. View the logs.


9 years ago

This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.


9 years ago

#20 @stephdau
9 years ago

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

#21 @stephdau
9 years ago

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.

Last edited 9 years ago by stephdau (previous) (diff)

#22 @helen
9 years ago

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 :)

#23 follow-up: @celloexpressions
9 years ago

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.

#24 in reply to: ↑ 23 @melchoyce
9 years ago

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

#25 @helen
9 years ago

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:

http://s.hyhs.me/bbVI/image.gif

#26 @helen
9 years ago

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.

This ticket was mentioned in Slack in #core by helen. View the logs.


9 years ago

@helen
9 years ago

#28 @helen
9 years ago

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

#29 @stephdau
9 years ago

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

This ticket was mentioned in Slack in #core by helen. View the logs.


9 years ago

@helen
9 years ago

#31 @helen
9 years ago

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):

http://s.hyhs.me/bbNT/image.gif

Last edited 9 years ago by helen (previous) (diff)

#32 @obenland
9 years ago

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.

This ticket was mentioned in Slack in #core-flow by boren. View the logs.


9 years ago

This ticket was mentioned in Slack in #design by helen. View the logs.


9 years ago

#35 @hugobaeta
9 years ago

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:

https://cldup.com/minN1RQxqt.png

This ticket was mentioned in Slack in #core by helen. View the logs.


9 years ago

@helen
9 years ago

#37 @helen
9 years ago

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

This ticket was mentioned in Slack in #design by stephdau. View the logs.


9 years ago

This ticket was mentioned in Slack in #core by helen. View the logs.


9 years ago

@helen
9 years ago

#40 @helen
9 years ago

  • Keywords needs-testing added

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.

Last edited 9 years ago by helen (previous) (diff)

This ticket was mentioned in Slack in #design by helen. View the logs.


9 years ago

This ticket was mentioned in Slack in #core-flow by boren. View the logs.


9 years ago

This ticket was mentioned in Slack in #design by helen. View the logs.


9 years ago

@helen
9 years ago

@helen
9 years ago

#45 @helen
9 years ago

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.

#46 @obenland
9 years ago

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

#47 @afercia
9 years ago

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

https://cldup.com/z2mj8rSuwA.png

#48 @obenland
9 years ago

  • Owner set to helen
  • Status changed from new to assigned

This ticket was mentioned in Slack in #design by helen. View the logs.


9 years ago

#51 @helen
9 years ago

In 33098:

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

fixes #32900. see #32395.

#52 @helen
9 years ago

In 33099:

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

see #32395.

#53 @helen
9 years ago

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.

#54 @helen
9 years ago

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.

This ticket was mentioned in Slack in #core by helen. View the logs.


9 years ago

This ticket was mentioned in Slack in #design by helen. View the logs.


9 years ago

@hugobaeta
9 years ago

minor tweaks to the focus styles. Needs more extensive testing I think, but the idea is there: https://cldup.com/pobrtoZzb0.png

#57 @ryan
9 years ago

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

#58 in reply to: ↑ description @sunnyratilal
9 years ago

https://cldup.com/Daws15AjdJ.png

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

#59 @helen
9 years ago

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

#60 follow-up: @sunnyratilal
9 years ago

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

@helen
9 years ago

#61 in reply to: ↑ 60 @helen
9 years ago

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.

#62 @helen
9 years ago

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.

#63 @helen
9 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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

@ryan
9 years ago

Focus style, expanded, macnchrome

@ryan
9 years ago

Focus style, collapsed, macnchrome

#64 @ryan
9 years ago

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

This ticket was mentioned in Slack in #core-flow by boren. View the logs.


9 years ago

This ticket was mentioned in Slack in #core-flow by boren. View the logs.


9 years ago

Note: See TracTickets for help on using tickets.