WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 5 weeks ago

#21583 new enhancement

Improve discoverability and visual design of Screen Options and Help Panels

Reported by: chexee Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Help/About Keywords: needs-patch early
Focuses: Cc:

Description

The Screen Options and Help panels are not very discoverable and, in part because of this, aren't very helpful to our users.

Here are the problems with them right now:

  • Most users are blind to these tabs.
  • The labels and positioning give little indication as to what these tabs actually do.
  • For a lot of users, Help is not that helpful.

*They’re position in the admin creates yet another point of navigation for users to be aware of (and per #1, most of them aren’t).

  • The very wide container for text makes a lot of the help text difficult to read.

Here are some proposals to improve the design and discoverability of these tabs (related images and mockups are here: http://make.wordpress.org/ui/2012/08/06/we-did-some-brainstorming-at-dev-day-today/) :

  • Adding icons to these tabs would (hopefully) both make these tabs more visible and give a better indication as to what these tabs too.
  • Moving these to the right side of the toolbar would give even more context to what these do, as they would be grouped with other user-specific settings.
  • (6) The toolbar dropdown would allow for a slimmer content area for better readability.
  • (7) The slimmer content area would let us make screen options read like a list for better scannability.
  • (4/5) Putting the gear on the upper right would standardise with several other web apps (Twitter, etc).

Related: #21326

Attachments (28)

21583.diff (3.6 KB) - added by ryan 3 years ago.
Just playing
21583.2.diff (10.5 KB) - added by ryan 3 years ago.
21583.3.diff (14.2 KB) - added by ryan 3 years ago.
21583.4.diff (13.9 KB) - added by ryan 3 years ago.
21583.5.diff (16.3 KB) - added by ryelle 3 years ago.
21583.6.diff (19.4 KB) - added by taylorde 3 years ago.
admin-bar-sprite-2x.psd (53.2 KB) - added by taylorde 3 years ago.
The PSD I worked with to add the sticky menu indicator arrows
admin-bar-sprite-2x.png (4.2 KB) - added by taylorde 3 years ago.
/wp-includes/images/
admin-bar-sprite.png (2.4 KB) - added by taylorde 3 years ago.
/wp-includes/images/
21583.7.diff (21.5 KB) - added by meliko 3 years ago.
admin-bar-sprite.2.png (5.2 KB) - added by meliko 3 years ago.
Added the cog into the admin menu sprite. I couldn't find a good Creative Commons non-attribution cog, so I ended up just making one myself.
admin-bar-sprite-2x.2.png (8.2 KB) - added by meliko 3 years ago.
2x revision of the admin bar sprite with added cog icon.
admin-bar-sprite.psd (95.3 KB) - added by meliko 3 years ago.
Updated psd with cogs.
admin-bar-sprite-2x.2.psd (99.5 KB) - added by meliko 3 years ago.
2x admin bar psd with added cog
21583.8.diff (21.3 KB) - added by lessbloat 3 years ago.
21583.9.diff (27.5 KB) - added by ryan 3 years ago.
Refresh .8.diff. Move help from render_screen_meta() into render_help() sans the other junk.
21583.10.diff (27.9 KB) - added by lessbloat 3 years ago.
21583.11.diff (28.8 KB) - added by ryan 3 years ago.
Add html_callback meta arg to add_menu(). Move help rendering to _render_help() callback.
21583.12.diff (28.8 KB) - added by meliko 3 years ago.
Removed label in "items per page" section, styled number input field.
21583.13.diff (34.0 KB) - added by ryelle 3 years ago.
21583.13.1.diff (34.2 KB) - added by ryelle 3 years ago.
21583.14.diff (9.9 KB) - added by ryan 3 years ago.
Do over. screen-options-wrap and contextual-help-wrap outside of admin bar.
21583.15.diff (10.4 KB) - added by ryan 3 years ago.
Markup fixes
21583.16.diff (10.4 KB) - added by ryan 3 years ago.
Gear to the far right
21583.17.diff (11.3 KB) - added by kadamwhite 3 years ago.
21583.18.a.diff (12.4 KB) - added by ryelle 3 years ago.
21583.18.b.diff (12.5 KB) - added by ryelle 3 years ago.
sticky-admin-bar.png (34.5 KB) - added by MikeHansenMe 3 years ago.
new sticky admin bar

Download all attachments as: .zip

Change History (76)

comment:1 @sabreuse3 years ago

  • Cc sabreuse@… added

comment:2 @chexee3 years ago

  • Cc helen.y.hou@… added

comment:3 @ocean903 years ago

  • Cc ocean90 added

@ryan3 years ago

Just playing

comment:4 @ryan3 years ago

After a quick chat with @nacin, it seems that most of the functions/methods for rendering screen options markup should be emptied and deprecated. In their places, introduce a new top-level render method with methods to handle each section (show on screen, layout, per page, ...). Take the opportunity to continue the screen cleanup.

@ryan3 years ago

comment:5 @DrewAPicture3 years ago

  • Cc xoodrew@… added

comment:6 @Mamaduka3 years ago

  • Cc georgemamadashvili@… added

comment:7 @scribu3 years ago

  • Keywords has-patch added

comment:8 @meliko3 years ago

  • Cc melissachoyce@… added

@ryan3 years ago

comment:9 @ryan3 years ago

That handles most of screen options. Todo:

  • Handle _screen_settings
  • Handle form and nonce for per page

Contextual help hasn't been touched yet. Nor has any styling been updated to make any of this remotely good looking. :-)

@ryan3 years ago

comment:10 @taylorde3 years ago

  • Cc td@… added

comment:11 @taylorde3 years ago

Just a thought here. Currently the help tab, once clicked, will push the content on the page down and it will stay open (until page refresh or explicitly collapsed again). Moving it to the admin bar would, by default, make it lose that functionality which I think may be valuable for help (probably not for screen options).

So, to fix that, a sticky flag or something for menu items in the admin bar which would cause the menu to stick open on click with an up/down arrow to indicate the menu's current status of collapsed or open?

comment:12 @ryelle3 years ago

I added a check for title when creating the HTML for the menu, so we don't get an empty div taking up space. I also added the ab-item class to the new items in the menu. The rest of the actual styling will be up to @melchoyce.

@ryelle3 years ago

@taylorde3 years ago

@taylorde3 years ago

The PSD I worked with to add the sticky menu indicator arrows

@taylorde3 years ago

/wp-includes/images/

@taylorde3 years ago

/wp-includes/images/

comment:13 @taylorde3 years ago

21583.6.diff adds the ability to define a menu as sticky (opens on click vs on hover). This ability is indicated by an open/close arrow. I've attached the updated admin-bar-sprite.png.

Need to add the help file into the admin bar, make it sticky, make it styled.

@melchoyce is still working on styles for the screen options.

comment:14 @betzster3 years ago

  • Cc j@… added

@meliko3 years ago

comment:15 @meliko3 years ago

I've uploaded what I've managed to do so far (21583.7.diff). "Show on screen" and "Column layout" should be styled correctly on all pages that access those options, but I ran into some trouble styling "Items per page," so it would be great if someone could take a look at that. @ryelle helped add class names to some items we thought needed them.

@meliko3 years ago

Added the cog into the admin menu sprite. I couldn't find a good Creative Commons non-attribution cog, so I ended up just making one myself.

@meliko3 years ago

2x revision of the admin bar sprite with added cog icon.

@meliko3 years ago

Updated psd with cogs.

@meliko3 years ago

2x admin bar psd with added cog

@lessbloat3 years ago

comment:16 @lessbloat3 years ago

Looking really good Melchoyce!

In 21583.8.diff:

  • Changed .ab-item container from <div> to <a>, to allow tabbing to this menu.
  • Altered checkbox margins to work slightly better cross browser

Remaining items

Several things I noticed:

  • Help tab disappeared, but I don't see any new code for it in the toolbar.
  • Need to hide the cog on pages where there are no screen options (e.g media-new.php).
  • "Items per page" on edit.php and other list pages, needs some CSS love.
  • Changing "Number of columns" doesn't do anything.
  • When your browser height is less than the height of the dropdown, there is no way to see all of the options (http://cl.ly/image/0m220W382g2O).
Version 1, edited 3 years ago by lessbloat (previous) (next) (diff)

comment:17 @lessbloat3 years ago

  • Keywords needs-patch added; has-patch removed

@ryan3 years ago

Refresh .8.diff. Move help from render_screen_meta() into render_help() sans the other junk.

@lessbloat3 years ago

comment:18 @lessbloat3 years ago

In 21583.10.diff I worked on:

  • Need to hide the cog on pages where there are no screen options (e.g media-new.php).
  • Changing "Number of columns" doesn't do anything.
  • When your browser height is less than the height of the dropdown, there is no way to see all of the options.

@meliko - let me know if you want to work together on "Items per page" on edit.php and other list pages, needs some CSS love.

Remaining items

  • "Items per page" on edit.php and other list pages, needs some CSS love.
  • Styling/formatting for help screen.
Last edited 3 years ago by lessbloat (previous) (diff)

@ryan3 years ago

Add html_callback meta arg to add_menu(). Move help rendering to _render_help() callback.

comment:19 @ryan3 years ago

That outputs the big blob of help markup as a submenu. I introduced an 'html_callback' meta arg to compliment 'html' because I was too lazy to change the help rendering to stuff everything in a var rather than output directly. Naturally, this looks completely awful, needs styling, and just might be silly.

comment:20 @JerrySarcastic3 years ago

  • Cc fittingsites@… added

@meliko3 years ago

Removed label in "items per page" section, styled number input field.

comment:21 follow-up: @meliko3 years ago

So, I'm running into an issue trying to style the "apply" button for this ticket. I want it to inherit the styles for the .button class but it's being overwritten by "#wpadminbar *", which is forcing a set of styles onto everything in the admin bar. I'm insure what to do in this situation. Does anyone have more experience with this kind of problem?

comment:22 @ryan3 years ago

Looking good. If we can get help styled to the point of readability we can land this and iterate.

comment:23 in reply to: ↑ 21 ; follow-up: @koopersmith3 years ago

Replying to meliko:

So, I'm running into an issue trying to style the "apply" button for this ticket. I want it to inherit the styles for the .button class but it's being overwritten by "#wpadminbar *", which is forcing a set of styles onto everything in the admin bar. I'm insure what to do in this situation. Does anyone have more experience with this kind of problem?

In this particular situation, I think adding the help and screen options panel outside of the admin bar div is a valid option. Since the admin bar is visible on the front end, we're exceptionally aggressive with its CSS. Attempting to override it all will likely involve a world of pain.

comment:24 in reply to: ↑ 23 @ryelle3 years ago

Styling for Help. I ended up pulling the help tab styling out of wp-admin.css & putting it into admin-bar.css, since it made sense to move. There are still rough edges here - it's not responsive in the slightest, the content doesn't scroll if your browser is short, and needs browser testing.

Replying to koopersmith:

In this particular situation, I think adding the help and screen options panel outside of the admin bar div is a valid option. Since the admin bar is visible on the front end, we're exceptionally aggressive with its CSS. Attempting to override it all will likely involve a world of pain.

The admin bar CSS means I did have to redefine bold & italic tags for the help content, so it'd be great to not do that - but I don't understand how this would work. Taking the items out of the div basically takes them out of the bar, doesn't it? At least, it did when I tried.

@ryelle3 years ago

comment:25 follow-up: @lessbloat3 years ago

Looking great Ryelle. One small thing I noticed, when you mouse over the menu, the tab is white, but directly over the grey right column of the drop down. What do you think of adjusting the positioning of just the help menu to line the white tab up with the white portion of the drop down. Something like:

http://f.cl.ly/items/3r0d22012q3M3g173o06/help-menu-position.jpg

@ryelle3 years ago

comment:26 in reply to: ↑ 25 @ryelle3 years ago

Changed alignment per lessbloat's suggestion.

@ryan3 years ago

Do over. screen-options-wrap and contextual-help-wrap outside of admin bar.

comment:27 @ryan3 years ago

New approach. Retain the old php with some minor tweaks. contextual-help-wrap and screen-options-wrap are now output outside of the admin bar. They will need to be styled again and attached to their appropriate admin bar menus with some js.

@ryan3 years ago

Markup fixes

@ryan3 years ago

Gear to the far right

comment:28 @kadamwhite3 years ago

  • Cc kadamwhite added

@kadamwhite3 years ago

comment:29 @kadamwhite3 years ago

All I have done so far is to re-enable the click-button-and-corresponding-panel-appears toggle behavior. Other than removing JS that was no longer relevant based on the latest markup, very little has changed.

@meliko, please let me know if you need more to get started on the styles—I was confused by the comment that the panels would have to be "moved" in chat today, so I may have missed something.

I couldn't find any reference to whether both panels should be allowed to be open at once, but if not I will add a check to close the other if necessary. I also wanted to see if anybody in the thread (@koopersmith?) knew what the standard is for use of jQuery's .on() vs shortcut methods like .click().

This is the first patch I've uploaded, so if anything is out of sorts please let me know. Thanks!

comment:30 @meliko3 years ago

@ryan, why are we moving the position of the gear? I may have just missed that conversation, but I thought we were keeping it to the left of the "my account" dropdown. We reasoned that users are used to having account info/log out in the top right corner of screens across a variety of sites and apps.

@kadamwhite, thanks for getting this started so @ryelle and I can style.

@ryelle3 years ago

@ryelle3 years ago

comment:31 @ryelle3 years ago

I started styling the panels to match the other submenus (21583.18.a.diff). With this, Help is basically finished. Screen Options needs a lot of work, and I'll let @melchoyce take over redoing that.

I also noticed that help & screen options were working on click only, rather than hover like the rest of the admin bar. I tried using hoverIntent to make the functionality match, but I'm not confident about this being the right approach. I uploaded my efforts in 21583.18.b.diff (so this has all of 18.a's styling, plus JS).

comment:32 @kadamwhite3 years ago

Hover... tough one. I agree that it is inconsistent as-is, but I worry that having the menus disappear on hover-off would be a bad user experience—the purpose of these menus is not really analogous to that of the existing menus, because they are meant to be informational more than navigational. How would you envision the hover behavior working, e.g. when somebody moves their cursor back down to the edit form?

comment:33 @meliko3 years ago

I think if it's in the admin bar area, it needs to hover. If I hover over an item and it doesn't drop down a menu, I assume that it's a link to a different page. One of the ideas behind this ticket is to make both contextual help and screen options easier to discover. If you have to click to expand those menus, then they're not as easy to discover and understand.

On the help menu, the target is large enough to not hinder usability. The screen options menu is no less usable than any other menu in the admin bar. I don't really see any UX issues with hover -- if only, it reinforces and enhances user experience through consistency.

comment:34 @nacin3 years ago

  • Type changed from enhancement to task (blessed)

comment:35 follow-up: @lessbloat3 years ago

In reviewing these latest patches, I can see the benefit of having the "screen options" and "Help" buttons in the toolbar. However, I'm not 100% convinced that we've discovered a solution for the containers themselves that's significantly better than what we've got now.

At this point (with hard freeze coming on fast), my thoughts would be to either:

A) Move the "screen options" and "Help" buttons to the toolbar, but leave the existing "help" and "screen options" containers/styles as is. Clicking either button would slide down/up the appropriate container, exactly how they function now.

B) Or, punt this ticket until we can spend a some more time coming up with something that is at least measurably better than the current solution.

Thoughts?

comment:36 in reply to: ↑ 35 @ericmann3 years ago

Replying to lessbloat:

In reviewing these latest patches, I can see the benefit of having the "screen options" and "Help" buttons in the toolbar. However, I'm not 100% convinced that we've discovered a solution for the containers themselves that's significantly better than what we've got now.

I'm all for increasing discoverability, but pulling them into the toolbar doesn't (IMO) do much to that effect. Instead, it just further clutters a UI feature that is already being cluttered by plugins.

At this point (with hard freeze coming on fast), my thoughts would be to either:

A) Move the "screen options" and "Help" buttons to the toolbar, but leave the existing "help" and "screen options" containers/styles as is. Clicking either button would slide down/up the appropriate container, exactly how they function now.

B) Or, punt this ticket until we can spend a some more time coming up with something that is at least measurably better than the current solution.

I'd much rather punt and take some more time to come up with a solid solution than pull in some half-changes and need to revisit again with the next version. Changing locations now, and potentially usability later would be more disjointing to end users than making one change later down the road.

comment:37 @JerrySarcastic3 years ago

+1 for punting the package—it would be better to nail this than to get it half-baked.

comment:38 @helenyhou3 years ago

  • Keywords early added; ui-feedback ux-feedback removed
  • Milestone changed from 3.5 to Future Release
  • Type changed from task (blessed) to enhancement

A sad, sad punt. Needs way more time to resolve issues, refine, and test (and repeat) than we have for 3.5. Let's be sure to hit this way early next round.

@MikeHansenMe3 years ago

new sticky admin bar

comment:39 @MikeHansenMe3 years ago

  • Cc mdhansen@… added

I think this is even more important now with the new sticky admin bar. see screenshot.

Just realized it has been sticky for awhile now. Still think this is a good enhancement.

Last edited 3 years ago by MikeHansenMe (previous) (diff)

comment:40 @hidgw3 years ago

  • Cc hidgw added

comment:41 @sillybean22 months ago

  • Cc steph@… added

comment:42 @Hanni22 months ago

  • Cc h@… added

comment:43 @dllh22 months ago

  • Cc daryl@… added

comment:44 @jazzs3quence21 months ago

  • Cc chris@… added

comment:45 @jazzs3quence21 months ago

Thought I'd pop in here for anyone watching this ticket. We're looking at this on Make/Docs for the Admin Help project for WordPress 3.8. I've taken 21583.18 and turned it into a plugin (at least the Help tab stuff). Anyone interested in offering feedback or jumping into the discussion can head over to the P2 or join #wordpress-sfd on Mondays at 16:30 UTC.

(It should be noted that we're looking at -- and open to -- other options for the Help, as well, and are trying to get some user testing data for feedback on discoverability of the existing Help tab.)

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

comment:46 @helen12 months ago

#28390 was marked as a duplicate.

comment:47 @slackbot2 months ago

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

comment:48 @helen5 weeks ago

#31674 was marked as a duplicate.

Note: See TracTickets for help on using tickets.