WordPress.org

Make WordPress Core

Opened 4 months ago

Last modified 9 days ago

#49715 reopened task (blessed)

Alternate views for WP List Tables

Reported by: joedolson Owned by: audrasjb
Milestone: 5.6 Priority: normal
Severity: normal Version:
Component: Administration Keywords: needs-dev-note has-patch
Focuses: ui, accessibility Cc:

Description

Currently, the WP List Table supports two views: default and "excerpts". This distinction is confusing and doesn't easily allow for other differences between the two views.

As a way to create more flexibility in WP List Tables, we'd like to implement mechanisms for users to choose different views, similar to what's found in Gmail, e.g.: Compact, Default, Comfortable.

This would give us a lot more flexibility in being able to resolve issues where conflicts arise between design, space, and accessibility, because we could offer views where everything is spelled out in a spacious way and also views where information is more compact. As long as the user is able to choose a persistent view that gives them all the information they need, the alternate views can use designs that disclose less detail.

Example tickets that would be impacted include:

#48751
#32170
#35391

Attachments (9)

49715.diff (5.8 KB) - added by audrasjb 3 months ago.
First pass: Allow user to switch between Compact (default) and Extended modes for posts types list tables
Capture d’écran 2020-05-15 à 01.28.29.png (183.1 KB) - added by audrasjb 3 months ago.
49715.diff – "extended" mode displays excerpt (proposal) and row actions (not hidden for better accessibility)
49715.1.diff (8.0 KB) - added by audrasjb 3 months ago.
Add compact/extended view support for comments
49715.2.diff (8.7 KB) - added by audrasjb 3 months ago.
Provide alternate table views (compact/extended) for Posts, users, media and comments screens
49288.3.diff (7.3 KB) - added by audrasjb 2 months ago.
Add table-view-* classes and fix few WPCS issues. Also refreshes the previous patch
49715.4.diff (11.4 KB) - added by audrasjb 5 weeks ago.
Add extensibility via filters and action hooks
49715.5.diff (9.2 KB) - added by audrasjb 4 weeks ago.
Introduce extensibility to posts and comments list table views, for accessibility purposes
49715.6.diff (9.5 KB) - added by audrasjb 4 weeks ago.
Introduce extensibility to posts and comments list table views, for accessibility purposes
49715.7.diff (3.2 KB) - added by audrasjb 10 days ago.
Reverts table_view_mode filter introduction as per discussion that happened in ticket #49715

Download all attachments as: .zip

Change History (59)

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


4 months ago

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


4 months ago

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


4 months ago

This ticket was mentioned in Slack in #accessibility by nrqsnchz. View the logs.


4 months ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 months ago

#6 @afercia
3 months ago

  • Milestone changed from Awaiting Review to 5.5
  • Owner set to audrasjb

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 months ago

@audrasjb
3 months ago

First pass: Allow user to switch between Compact (default) and Extended modes for posts types list tables

@audrasjb
3 months ago

49715.diff – "extended" mode displays excerpt (proposal) and row actions (not hidden for better accessibility)

#8 @audrasjb
3 months ago

  • Keywords has-patch needs-refresh needs-testing dev-feedback 2nd-opinion needs-design-feedback added

49715.diff is a first pass:

  • it replaces default list mode with compact mode. I didn't change list value for better backward compatibility, so it's only a wording change.
  • it replaces optional excerpt mode with extended mode. I added some code to handle user settings migration.
  • when selected, extended mode displays post excerpt (it's a proposal, I'm not sure we want to display excerpts at all) and row actions (not hidden for better accessibility).

Todo:

  • Same for taxonomy terms
  • Same for users
  • Same for media
  • Check multisite/network related screens

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 months ago

@audrasjb
3 months ago

Add compact/extended view support for comments

@audrasjb
3 months ago

Provide alternate table views (compact/extended) for Posts, users, media and comments screens

#10 @audrasjb
3 months ago

  • Keywords needs-refresh needs-design-feedback removed

49715.2.diff provides alternate table views (compact/extended) for Posts, users, media and comments screens.

Former list (default) and excerpt views are replaced with compact (by default) and extended views. Users can switch from one view to another using screen options.

#11 @audrasjb
3 months ago

Note: we still need to add multisite support, but I'd like to get a review of the current workaround before moving forward on this :)

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


3 months ago

#13 @afercia
2 months ago

Thanks @audrasjb for the patches! Looking into 49715.2.diff I noticed a few things worth discussing in the next weekly accessibility meeting:

  • Related to #48751, my understanding is that the proposal was to make the "row actions" visible by default. Instead, with this patch they're visible in the non-default view.
  • I see the same user setting is used for all the various tables e.g. Posts, Comments, Users. What is users want to set a different view for each table? Should a specific user setting be provided for each table?
  • Minor: there are a few PHPCS issues to fix, mainly related to alignments.

Provide alternate table views (compact/extended) for Posts, users, media and comments screens

I can't see changes in the media table :)

#14 @afercia
2 months ago

One more thing: worth considering to make these table views useful for plugins and expose a CSS class on the table element. Something like table-view-{mode} may work.

For the future, maybe consider to add a filter to extend / manipulate the modes.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 months ago

@audrasjb
2 months ago

Add table-view-* classes and fix few WPCS issues. Also refreshes the previous patch

#16 @audrasjb
2 months ago

Thanks for the review @afercia.

Related to #48751, my understanding is that the proposal was to make the "row actions" visible by default. Instead, with this patch they're visible in the non-default view.

Hum. I… I think it would be easier to address this in a specific ticket :D
That should be discussed in our next meeting.


I see the same user setting is used for all the various tables e.g. Posts, Comments, Users. What is users want to set a different view for each table? Should a specific user setting be provided for each table?

Good point. While I'm personnaly in favor of keeping on setting for the whole interface (excluding media screen, see my answer below), that should be discussed in our next meeting.


Minor: there are a few PHPCS issues to fix, mainly related to alignments.

I spotted and fixed some of them in the last patch.


I can't see changes in the media table :)

Yeah, we already have two modes: grid and list view :)


One more thing: worth considering to make these table views useful for plugins and expose a CSS class on the table element. Something like table-view-{mode} may work.

Done in the last patch!

This ticket was mentioned in Slack in #accessibility by nrqsnchz. View the logs.


8 weeks ago

#18 @joedolson
8 weeks ago

The end goal for this was originally to have 3 views, but it's a great starting point to use the two existing views & re-envision how they're used.

After discussing this in the accessibility meeting today, here's where we'd like to go next:

1) Re-model the view selection mechanism so that it can be extended. This is both so that we can add a 3rd view (probably a low-density view) in 5.6, but also so that the choices of table views can be extended by plugins that want to add or replace existing views.

2) Make the views configurable on a per-table basis. Probably also considering that the default view should be filterable, again so that plugins can default to their custom views.

3) Add a global default for user's to set their preferred view. This global default should probably support a distinction between public and private views. E.g., a plug-in can override the default for their own tables if it's a private view, and that view won't be shown in the global settings. But other views can be added that are globally available for selection. (Note: it may be possible to consider the media views as a private view in this context? Not sure.)

We're not going to aim for adding the 3rd view at this time, instead focusing on extensibility.

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


6 weeks ago

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


5 weeks ago

@audrasjb
5 weeks ago

Add extensibility via filters and action hooks

#21 @audrasjb
5 weeks ago

49715.4.diff is a first workaround to add extensibility (action and filter hooks) to the feature. I'll test it intensively tomorrow to see if it's good enough.

#22 @afercia
5 weeks ago

  • Keywords needs-refresh added

Testing 49715.4.diff it should be rebuilt on top of current trunk.

The patch is still based on a previous codebase. For example: we recently removed the abbr for the extended date but this patch restores a parameter $h_time that was removed. This also triggers a PHP notice:

Notice: Undefined variable: h_time in /srv/www/wordpress-develop/public_html/build/wp-admin/includes/class-wp-posts-list-table.php on line 1144.

Also, the patch removes a @since notation from the post_date_column_time filter docblock that should be kept.

Last edited 5 weeks ago by afercia (previous) (diff)

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


4 weeks ago

@audrasjb
4 weeks ago

Introduce extensibility to posts and comments list table views, for accessibility purposes

#24 @audrasjb
4 weeks ago

  • Keywords needs-testing dev-feedback 2nd-opinion needs-refresh removed

@afercia patch refreshed.

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


4 weeks ago

@audrasjb
4 weeks ago

Introduce extensibility to posts and comments list table views, for accessibility purposes

#26 @whyisjake
4 weeks ago

Looks great, y'all. Committing.

#27 @whyisjake
4 weeks ago

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

In 48398:

Administration: Introduce extensibility to posts and comments list table views, for accessibility purposes.

At default, expands the excerpt view to become an extended view. Includes a new table_view_mode filter to allow further configuration.

Fixes #49715.
Props joedolson, audrasjb, afercia, whyisjake.

#28 @afercia
4 weeks ago

  • Keywords needs-patch added; has-patch removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for docs improvements:

the new filter table_view_mode should be documented once in the main instance where it is used and then referenced in the other files by a doc inline comment like:

/** This filter is documented in {file-path-here} */

#29 @SergeyBiryukov
4 weeks ago

  • Type changed from enhancement to task (blessed)

#30 @Offereins
4 weeks ago

Reading the recent changeset I'd like to ask the following:

  • Couldn't $mode_class = 'extended' === $mode ? 'table-view-extended' : 'table-view-' . $mode; be more like $mode_class = 'table-view-' . $mode; or interpolated as $mode_class = "table-view-{$mode}";?
  • For the sake of (future) consistency, should a registration pattern for modes (eg array( key => label )) not be better suited? The new hooks (looking at wp_table_view_modes) provide a lot of room for deviations in HTML markup. Might I suggest to use a filterable list of modes, which would allow for removing and reordering modes, as well as a consistent output of HTML markup handled by core.
  • Also, why is renaming the excerpt mode key not expected to affect backwards compatibility?
Last edited 4 weeks ago by Offereins (previous) (diff)

#31 @afercia
4 weeks ago

Additionally, I think it would be nice to immediately show the changes when selecting the radio buttons in the Screen Options. For example, in the Posts page:

  • select "Extended View"
  • the "row actions" in the table should become visible
  • select "Compact View"
  • the "row actions" in the table should become not visible

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


4 weeks ago

#33 @SergeyBiryukov
4 weeks ago

In 48423:

Administration: Make some adjustments to WP_Screen::render_view_mode():

  • Restore the $mode global for backward compatibility.
  • Remove redundant check, as $mode is already set at this point, and already defaults to list via get_user_setting()'s second argument.
  • Use sentence case for "View mode" and "Extended view" labels.

Follow-up to [48398].

See #49715.

#34 @SergeyBiryukov
4 weeks ago

In 48424:

Administration: Bring some consistency to handling list table view modes.

  • Remove duplicate variables and DocBlocks.
  • Add missing description for the $mode global.
  • Use sentence case for "Compact view" and "Extended view" labels.

Follow-up to [48398], [48423].

Props afercia, Offereins, SergeyBiryukov.
See #49715.

#35 @SergeyBiryukov
4 weeks ago

It's not quite clear why the table_view_mode filter is only applied in:

  • WP_Screen::render_view_mode()
  • WP_List_Table::get_table_classes()
  • WP_Posts_List_Table::get_table_classes()

but not in other places whether the mode is referenced.

Is that enough for the mode switching to work as expected on all affected tables? Is there enough context for the filter?

I also agree with comment:30 that the wp_table_view_modes name might be better suited for a filterable list of modes, rather than an action that fires after the core's default modes.

#36 follow-up: @Offereins
4 weeks ago

@SergeyBiryukov If I'm reading [48424] correctly, renaming of the excerpt mode is now only undone in WP_MS_Users_List_Table but not in WP_Posts_List_Table.

Also, the $mode = apply_filters( 'table_view_mode', $mode ); part is now kept in the get_table_classes() method. Perhaps the filter is better applied where $mode is defined when the user setting is fetched in the prepare_items() method.

#37 in reply to: ↑ 36 @SergeyBiryukov
4 weeks ago

Replying to Offereins:

@SergeyBiryukov If I'm reading [48424] correctly, renaming of the excerpt mode is now only undone in WP_MS_Users_List_Table but not in WP_Posts_List_Table.

Just to clarify, [48424] didn't touch any of the renaming parts, it only moved that code block higher up for consistency with WP_MS_Sites_List_Table.

Good catch though, there are still some references to the old excerpt key, specifically:

  • In wp_ajax_inline_save().
  • In WP_MS_Sites_List_Table::prepare_items().
  • In WP_MS_Users_List_Table::prepare_items().

Either these all should be updated to use new extended mode, or all the other instances should be reverted back to the excerpt mode for backward compatibility.

Also, the $mode = apply_filters( 'table_view_mode', $mode ); part is now kept in the get_table_classes() method. Perhaps the filter is better applied where $mode is defined when the user setting is fetched in the prepare_items() method.

Yes, it would also be a good idea to better document the purpose of the filter. At the moment, it's not quite clear whether it just allows to choose between list and extended, or also allows for specifying any custom type. Apparently the former is the case.

#38 @SergeyBiryukov
4 weeks ago

In 48450:

Administration: Restore the excerpt key for the Extended view mode for backward compatibility for now.

Props Offereins.
See #49715.

#39 @SergeyBiryukov
4 weeks ago

I think this would benefit from a dedicated WP_List_Table class property and method for setting the mode, instead of relying on the $mode global and doing things a bit differently in each class.

Additionally, there seems to be some overlap between WP_List_Table::view_switcher() and WP_Screen::render_view_mode(), might be a good idea to review them closer.

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


3 weeks ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 weeks ago

#42 @desrosj
2 weeks ago

This one is running out of time (beta 3 is in a few hours and RC1 is in one week).

Is someone able to create a patch for the changes mentioned in comment:39? If that cannot happen in time, would a revert of any of the changesets on this ticket be required?

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 weeks ago

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


13 days ago

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


10 days ago

#46 @davidbaumwald
10 days ago

  • Keywords needs-dev-note added

With the new filters, this deserves a call out on the Misc Dev Note.

@audrasjb
10 days ago

Reverts table_view_mode filter introduction as per discussion that happened in ticket #49715

#47 @audrasjb
10 days ago

  • Keywords has-patch added; needs-patch removed

#48 @SergeyBiryukov
9 days ago

In 48668:

Administration: Pull the table_view_mode filter for now.

The extensibility of list table view modes will be explored in a future release.

Props audrasjb.
See #49715.

#49 @SergeyBiryukov
9 days ago

In 48670:

Administration: Don't override the $mode global in WP_Screen::render_view_mode() if it's already set.

Follow-up to [48398], [48423], [48424], [48450].

See #49715.

#50 @SergeyBiryukov
9 days ago

  • Milestone changed from 5.5 to 5.6
Note: See TracTickets for help on using tickets.