#32395 closed task (blessed) (fixed)
Truncation is not a good strategy for responsive list tables
Reported by: |
|
Owned by: |
|
---|---|---|---|
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:
- #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
Attachments (13)
Change History (79)
comment:2
@slackbot
— 4 months ago
This ticket was mentioned in Slack in #design by helen. View the logs.
comment:3
@slackbot
— 4 months ago
This ticket was mentioned in Slack in #design by helen. View the logs.
comment:4
@slackbot
— 3 months ago
This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.
comment:6
@slackbot
— 3 months ago
This ticket was mentioned in Slack in #core by helen. View the logs.
comment:7
follow-up:
↓ 9
@stephdau
— 3 months 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
comment:8
@slackbot
— 3 months ago
This ticket was mentioned in Slack in #design by helen. View the logs.
comment:9
in reply to:
↑ 7
;
follow-up:
↓ 11
@helen
— 3 months 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?
comment:10
@afercia
— 3 months ago
comment:11
in reply to:
↑ 9
@stephdau
— 3 months 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.
comment:12
follow-up:
↓ 13
@afercia
— 3 months 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).
comment:13
in reply to:
↑ 12
@stephdau
— 3 months 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
comment:14
follow-up:
↓ 16
@stephdau
— 3 months 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.
comment:15
@stephdau
— 3 months 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.
comment:16
in reply to:
↑ 14
@afercia
— 3 months 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.
comment:17
@helen
— 3 months 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.
comment:18
@slackbot
— 3 months ago
This ticket was mentioned in Slack in #design by helen. View the logs.
comment:19
@slackbot
— 3 months ago
This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.
comment:20
@stephdau
— 3 months 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).
comment:21
@stephdau
— 3 months 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.
comment:22
@helen
— 3 months 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 :)
comment:23
follow-up:
↓ 24
@celloexpressions
— 3 months 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.
comment:24
in reply to:
↑ 23
@melchoyce
— 3 months 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
comment:25
@helen
— 3 months 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:
comment:26
@helen
— 3 months 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.
comment:27
@slackbot
— 3 months ago
This ticket was mentioned in Slack in #core by helen. View the logs.
comment:28
@helen
— 3 months ago
Hidden columns are handled via class as of [32724].
comment:29
@stephdau
— 3 months 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.
comment:30
@slackbot
— 3 months ago
This ticket was mentioned in Slack in #core by helen. View the logs.
comment:31
@helen
— 3 months 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):
comment:32
@obenland
— 3 months 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.
comment:33
@slackbot
— 3 months ago
This ticket was mentioned in Slack in #core-flow by boren. View the logs.
comment:34
@slackbot
— 3 months ago
This ticket was mentioned in Slack in #design by helen. View the logs.
comment:35
@hugobaeta
— 3 months 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:
comment:36
@slackbot
— 3 months ago
This ticket was mentioned in Slack in #core by helen. View the logs.
comment:37
@helen
— 3 months ago
I don't know how it is that the patch still applies but it does. Refreshed in 32395.4.diff anyway.
comment:38
@slackbot
— 3 months ago
This ticket was mentioned in Slack in #design by stephdau. View the logs.
comment:39
@slackbot
— 2 months ago
This ticket was mentioned in Slack in #core by helen. View the logs.
comment:40
@helen
— 2 months 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.
comment:41
@slackbot
— 2 months ago
This ticket was mentioned in Slack in #design by helen. View the logs.
comment:42
@slackbot
— 2 months ago
This ticket was mentioned in Slack in #core-flow by boren. View the logs.
comment:43
@ryan
— 2 months ago
Visual survey and testing notes.
comment:44
@slackbot
— 2 months ago
This ticket was mentioned in Slack in #design by helen. View the logs.
comment:45
@helen
— 2 months ago
In 33016:
comment:46
@obenland
— 2 months ago
Just noticed that the .toggle-row button shows up in the comments list in edit.php. See screenshot above.
comment:47
@afercia
— 2 months 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
comment:48
@obenland
— 2 months ago
- Owner set to helen
- Status changed from new to assigned
comment:49
@slackbot
— 2 months ago
This ticket was mentioned in Slack in #design by helen. View the logs.
comment:50
@ryan
— 2 months ago
comment:51
@helen
— 2 months ago
In 33098:
comment:52
@helen
— 2 months ago
In 33099:
comment:53
@helen
— 2 months ago
In 33101:
comment:54
@helen
— 2 months ago
comment:55
@slackbot
— 2 months ago
This ticket was mentioned in Slack in #core by helen. View the logs.
comment:56
@slackbot
— 2 months ago
This ticket was mentioned in Slack in #design by helen. View the logs.
@hugobaeta
— 2 months ago
comment:57
@ryan
— 2 months ago
32395.8.diff isn't rooted at src/ so grunt patch can't handle it.
comment:58
in reply to:
↑ description
@sunnyratilal
— 2 months ago
comment:59
@helen
— 2 months ago
@sunnyratilal - is that somehow a consequence of work that's happening in this ticket?
comment:60
follow-up:
↓ 61
@sunnyratilal
— 2 months ago
@helen - it's happening on master as well as nightly. Should I open another ticket?
comment:61
in reply to:
↑ 60
@helen
— 2 months 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.
comment:62
@helen
— 2 months ago
In 33146:
comment:63
@helen
— 2 months 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.
comment:64
@ryan
— 8 weeks ago
I see focus styling on Macnchrome but not on an iPhone 6+.
comment:65
@slackbot
— 8 weeks ago
This ticket was mentioned in Slack in #core-flow by boren. View the logs.
comment:66
@slackbot
— 2 weeks ago
This ticket was mentioned in Slack in #core-flow by boren. View the logs.
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.