WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 21 months ago

Last modified 14 months ago

#22222 closed defect (bug) (fixed)

"Mode" buttons bumped below (in 1024x768) when long category name exists

Reported by: trepmal Owned by: Oxymoron
Milestone: 4.4 Priority: normal
Severity: minor Version:
Component: Posts, Post Types Keywords: good-first-bug has-screenshots 2nd-opinion needs-testing
Focuses: ui, accessibility, administration, multisite Cc:

Description

If there's a long category name, the category filter <select> menu widens. On a 1024x768 screen, this causes the list/excerpt mode buttons to get bumped down.

screenshot: http://kdl.dropmark.com/25665/1130400

One thought was to move that option to Screen Options, which I think makes more sense anyway.

Attachments (7)

22222.patch (4.5 KB) - added by Oxymoron 22 months ago.
First pass at moving view mode icons to screen options
22222.2.patch (4.5 KB) - added by Oxymoron 22 months ago.
some adjustments that hopefully make this better
22222.3.patch (4.5 KB) - added by Oxymoron 22 months ago.
quick fix for using $_POST over $_REQUEST
22222.4.patch (4.3 KB) - added by Oxymoron 22 months ago.
updates per Helen's notes
22222.diff (4.1 KB) - added by helen 21 months ago.
Screen Shot 2015-10-27 at 8.48.00 AM.png (102.1 KB) - added by johnjamesjacoby 21 months ago.
New view-switching UI is also visible on "Add New" posts screen-options
Screen Shot 2015-10-28 at 3.09.45 PM.png (42.7 KB) - added by johnjamesjacoby 21 months ago.
Also bleeding into Categories & Tags pages

Download all attachments as: .zip

Change History (47)

#1 @helenyhou
5 years ago

I like the idea of moving the view mode into Screen Options.

#2 @nacin
5 years ago

That would also mean that the view mode should become sticky. Right now it isn't remembered.

This is the direction #20335 headed.

#3 @helenyhou
5 years ago

... I thought it was sticky. Shows you how often I actually use it :) Well, +1 to #20335 for the user option, then.

#4 @SergeyBiryukov
4 years ago

  • Component changed from General to Administration
  • Keywords ui-focus added

#5 @azaozz
4 years ago

Also there is no reason for the selects there to be that wide, perhaps reduce the max-width to 150px.

#6 @celloexpressions
3 years ago

This is still an issue with the more-responsive admin of 3.8, for viewports between roughly 1050 and 1112px wide (with admin menu expanded), with the categories from the theme unit test. Once the paging navigation is also dropped down to its own line it looks okay. Maybe we should make both of those drop to a second line together, so that it looks okay regardless of the size of the selects?

#7 @helen
3 years ago

I would still like to do #20335 and have a user option that's sticky. Then no more mode buttons, but screen options instead.

#8 @nacin
3 years ago

  • Component changed from Administration to Posts, Post Types
  • Focuses administration added

#9 @helen
3 years ago

Related: #16774

#10 @helen
3 years ago

View mode is sticky now.

#11 @helen
2 years ago

  • Milestone changed from Awaiting Review to 4.4

Would like to make a decision one way or another in 4.4 as to whether to move view mode into screen options. I think it is far more appropriate there rather than mixing in with navigation/filtering and would give users more context than iconography does, so my vote is yes.

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


22 months ago

#13 @SergeyBiryukov
22 months ago

  • Keywords needs-patch added

#14 @helen
22 months ago

  • Keywords good-first-bug added

Existing strings: "List View" and "Excerpt View". I suppose we would call it a "View Mode"? Also note the screen help: "You can view posts in a simple title list or with an excerpt. Choose the view you prefer by clicking on the icons at the top of the list on the right."

@Oxymoron
22 months ago

First pass at moving view mode icons to screen options

#15 @Oxymoron
22 months ago

  • Keywords dev-feedback added

I went ahead and attempted to take care of this. At first I thought it would be pretty straightforward (ha) but it ended up needing adjustments in a few places. Please provide any feedback you can about what needs to change and I'll happily add a new patch! :)

#16 @helen
22 months ago

  • Keywords has-patch added; needs-patch removed
  • Owner set to Oxymoron
  • Status changed from new to assigned

@Oxymoron
22 months ago

some adjustments that hopefully make this better

@Oxymoron
22 months ago

quick fix for using $_POST over $_REQUEST

#17 @helen
22 months ago

  • Keywords needs-patch added; dev-feedback has-patch removed

Thanks for the patch @Oxymoron. Some notes:

  • All strings need to be internationalized, e.g. <h5><?php _e( 'View Mode' ); ?></h5>.
  • The default post types need to be everything that's not hierarchical as it currently is (see where the current view switcher is called). So you'd probably want to grab get_post_types( array( 'hierarchical' => false, 'show_ui' => true ) );
  • There are a couple of whitespace changes that seem unrelated - not a big deal, but is a little distracting when reviewing the diff. If this is something your editor is doing, you may want to look into whether you can set it to only clean up white space on lines you've modified.
  • The changes in wp-admin/includes/class-wp-screen.php don't need to break in and out of PHP quite so much :)
  • Not your fault, but the Apply button probably needs to be on its own line since it would save both of the settings above, not just the number of items per page.

@Oxymoron
22 months ago

updates per Helen's notes

#18 @Oxymoron
22 months ago

  • Keywords has-patch added; needs-patch removed

@helen I added a new patch that addresses each of your points!

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


22 months ago

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


22 months ago

#22 @afercia
22 months ago

  • Focuses accessibility added

#23 @afercia
22 months ago

  • Keywords needs-refresh added; has-patch removed

Sorry for asking for a new patch refresh :) After [34991] and [35010] we should avoid using a <h5> and use a fieldset + legend instead. Also, for consistency and cleaner code, this should be moved out of render_screen_options() and be in its own "render" method.
Discussed this a bit with @helen and we should make sure the "Apply" button is always displayed at the bottom as last thing. The button should also be a "primary" button. Plugins can add their own settings and we can't predict if they will add their own "Apply" button or not.
In the screenshot below, see an example of additional settings appended by plugins and on the right how it would look like moving the button at the bottom.

https://cldup.com/Oaa7b-skRV.png

Also, we've noticed the Apply button submits the whole form, also the "live" settings will be re-submitted. Not sure what to do here.

#24 @helen
22 months ago

Going to handle the apply button separately, so @Oxymoron a new patch would "just" need the separate render method and updated markup.

#25 @Oxymoron
22 months ago

@helen gotcha- will submit a patch once I can. thanks to @afercia for the feedback!

#26 @helen
22 months ago

In 35161:

Screen options: Improve the "Apply" button

Previously the button was output as a part of the per-page option rendering, inline with that input. While this was appropriate for core's usage, the screen_settings filter has allowed plugins to place additional items at the bottom of the panel, which a number take advantage of. This leads to confusing situations where plugins that don't save settings via Ajax either have to add their own button or piggyback onto the existing button, which doesn't make any sense in the flow of additional options. It also hinders core from adding any other options that need to be submitted.

Also, when the screen options panel is open, a submit button there is the primary action at that moment. The "Apply" button also does a full page load, which a primary button indicates better.

fixes #34295. see #22222, #23738.

#27 @afercia
22 months ago

  • Focuses multisite added

Wondering what should be done about the Network Admin screens, as far as I see the "mode" switcher is used on /network/sites.php and /network/users.php and switching views does very little. In the Sites screen, the excerpt view adds the site name and tagline, in the Users one it adds just the registered time?

@helen
21 months ago

#28 @helen
21 months ago

22222.diff is a refreshed/rebooted patch so we can grab this in time for beta, still working out the UX sadness of the Apply button for a bit though: #34295.

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


21 months ago

#30 @helen
21 months ago

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

In 35357:

List tables: Move the view mode switcher into screen options for posts.

Having a view mode switcher nestled within table navigation makes no sense, especially now that it's a sticky user option. While less convenient for frequent switching, there is no evidence as of yet that there is a large userbase of frequent view mode switchers.

Introduces a filter for view_mode_post_types, which by default is all hierarchical post types with edit UI on.

props Oxymoron.
fixes #22222.

#31 @helen
21 months ago

Apply button is still UX sadness, but we'll have to figure that out elsewhere and not tie this down with that right now.

@johnjamesjacoby
21 months ago

New view-switching UI is also visible on "Add New" posts screen-options

#32 @johnjamesjacoby
21 months ago

Maybe it's just because this is new, but I don't like this change very much (yet).

"Screen Options" is an intentionally vague description of yore, which makes it a great place to tuck noisy and not-often-used controls for manipulating the on-screen elements, but... I think a "view" switcher is a relatively common-enough interface preference to keep prominently displayed alongside the pagination.

Even Trac uses a similar view-switcher in the Notifications area (below comments & above the form) and I have a hunch that few people have complained about it's 2 icons.

If on-screen clutter is the complaint, there is more we can do to ease the feeling of claustrophobia without nixing these. I think, too, that making these views more useful is a better solution than hiding them in the junk drawer because they never matured.

If view persistence is the complaint, there are other ways to solve this problem (ajax, $_GET parameters, etc...)

I think doing this only in the "Posts" page will cause a few unique problems:

  • Inconsistency in the UI between Media, various Network screens, and many plugins that have adapted the previous UI
  • Plugins will want to follow suit by hiding their view-switching in there too, without consideration for their own unique UX and trusting that WordPress core devs did their due diligence and confirmed that "Screen Options" tested better with users
  • Users that are accustomed to switching their table views with buttons that have been around for almost a decade will need to rediscover where a feature disappeared to.

I'm interested to see where this idea goes and how it tests with users, and if I hear anything I'll report it back here.

#33 @johnjamesjacoby
21 months ago

  • Keywords has-screenshots 2nd-opinion needs-testing added; needs-refresh removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

@johnjamesjacoby
21 months ago

Also bleeding into Categories & Tags pages

#34 @DeBAAT
21 months ago

I fully agree with @johnjamesjacoby on the UX issue.
My recent experience with this was when I did research into why my posts list suddenly showed the excerpt info.
It looks like the view switcher on the posts list is only used to show the excerpt or not.
In my opinion, this is not a view switcher. The Media list shows what a view switcher should behave like: switching between list view and grid view.
I could imagine a grid view for posts as well where the featured image is used prominently to show the post. This however is for another change. ;-)

Regarding this issue, I would propose to keep the current post view switch functionality in the screen options panel. Only rename it to something like "Show excerpt" as a checkbox, similar to the functionality to show or hide a column (Author, Categories, Tags, etc).

#35 @Michael Arestad
21 months ago

"Screen Options" is an intentionally vague description of yore, which makes it a great place to tuck noisy and not-often-used controls...

I think it's a better spot than where the layout switcher currently is as it is definitely a screen option and fits with the other table options. Also, I've never seen anyone switch that view, but that's not a huge sampling for data. Not only that, but it is more clear what is happening than using just the icons.

I think doing this only in the "Posts" page will cause a few unique problems:

Inconsistency in the UI between Media, various Network screens, and many plugins that have adapted the previous UI

Plugins will want to follow suit by hiding their view-switching in there too

It kind of already is with the description field being toggle-able.

Users that are accustomed to switching their table views with buttons that have been around for almost a decade will need to rediscover where a feature disappeared to.

  1. How often do people really switch?
  2. If it's persistent, it shouldn't matter too much where it is.
  3. When moved up there, it removes one more thing fighting for attention in the UI.

without consideration for their own unique UX and trusting that WordPress core devs did their due diligence and confirmed that "Screen Options" tested better with users

Of course we should do some tests on which works better, but the bigger issue is whether it's all that useful in the first place. If not, it should probably be in <del>the junk drawer</del> screen options.

#36 follow-up: @helen
21 months ago

In 35461:

View mode is only a screen option for posts lists.

see #22222.

#37 in reply to: ↑ 36 ; follow-up: @DeBAAT
21 months ago

Replying to helen:

In 35461:

View mode is only a screen option for posts lists.

see #22222.

You can test in code that this functionality will only be effective in posts lists.
This will not change the fact that View Mode is used in Media lists to discriminate between LIST mode and GRID mode.
I still believe it will be confusing to users when they see different usages for View Mode.
And it might block future development when someone wants to introduce a <real> View Mode for posts lists.

As I said:

I would propose to keep the current post view switch functionality in the screen options panel. Only rename it to something like "Show excerpt" as a checkbox, similar to the functionality to show or hide a column (Author, Categories, Tags, etc).

Last edited 21 months ago by DeBAAT (previous) (diff)

#38 in reply to: ↑ 37 @helen
21 months ago

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

Replying to DeBAAT:

This will not change the fact that View Mode is used in Media lists to discriminate between LIST mode and GRID mode.
I still believe it will be confusing to users when they see different usages for View Mode.

Media doesn't have screen options in grid mode right now and I don't think this warrants introducing that UI there. The actual behavior, icons, and placement are also already different. I actually think this is better because it's useful in Media, not so much elsewhere.

And it might block future development when someone wants to introduce a <real> View Mode for posts lists.
As I said:

I would propose to keep the current post view switch functionality in the screen options panel. Only rename it to something like "Show excerpt" as a checkbox, similar to the functionality to show or hide a column (Author, Categories, Tags, etc).

We don't know what devs are doing with this, toggling the excerpt specifically is not going to always be correct. I don't think it blocks whatever a "real" view mode would be at all.

There is no reason for a sticky view switcher to be in a method named pagination() called within display_tablenav(), both of which actually describe what they're supposed to do (not always the case in core). It's not navigation or filtering. Where this dubiously useful switcher has been up until now doesn't change that the icons are cryptic and that all other persistent user settings are located in screen options.

Anything further regarding how useful posts view mode is belongs in another ticket. General issues with screen options (of which there are many) are also better served elsewhere, e.g. #34295, likely some existing tickets, or new tickets.

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


14 months ago

Note: See TracTickets for help on using tickets.