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

[trepmal]

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.

[helenyhou]

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

[nacin]

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

This is the direction #20335 headed.

[helenyhou]

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

[azaozz]

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

[celloexpressions]

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?

[helen]

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

[helen]

Related: #16774

[helen]

View mode is sticky now.

[helen]

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.

[helen]

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]

First pass at moving view mode icons to screen options

[Oxymoron]

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

[Oxymoron]

some adjustments that hopefully make this better

[Oxymoron]

quick fix for using $_POST over $_REQUEST

[helen]

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]

updates per Helen's notes

[Oxymoron]

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

[afercia]

Related: #33646

[afercia]

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.

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.

[helen]

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

[Oxymoron]

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

[helen]

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.

[afercia]

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]

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.

[helen]

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.

[helen]

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]

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

[johnjamesjacoby]

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.

[johnjamesjacoby]

Also bleeding into Categories & Tags pages

[DeBAAT]

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

[Michael Arestad]

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

[helen]

In 35461:

View mode is only a screen option for posts lists.

see #22222.

[DeBAAT]

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

[helen]

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.

[DeBAAT]

Found a plugin doing what I mean: ​http://codecanyon.net/item/admin-post-grid/11405282