WordPress.org

Make WordPress Core

Opened 21 months ago

Last modified 8 months 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 21 months ago.
Just playing
21583.2.diff (10.5 KB) - added by ryan 21 months ago.
21583.3.diff (14.2 KB) - added by ryan 20 months ago.
21583.4.diff (13.9 KB) - added by ryan 20 months ago.
21583.5.diff (16.3 KB) - added by ryelle 20 months ago.
21583.6.diff (19.4 KB) - added by taylorde 20 months ago.
admin-bar-sprite-2x.psd (53.2 KB) - added by taylorde 20 months ago.
The PSD I worked with to add the sticky menu indicator arrows
admin-bar-sprite-2x.png (4.2 KB) - added by taylorde 20 months ago.
/wp-includes/images/
admin-bar-sprite.png (2.4 KB) - added by taylorde 20 months ago.
/wp-includes/images/
21583.7.diff (21.5 KB) - added by meliko 20 months ago.
admin-bar-sprite.2.png (5.2 KB) - added by meliko 20 months 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 20 months ago.
2x revision of the admin bar sprite with added cog icon.
admin-bar-sprite.psd (95.3 KB) - added by meliko 20 months ago.
Updated psd with cogs.
admin-bar-sprite-2x.2.psd (99.5 KB) - added by meliko 20 months ago.
2x admin bar psd with added cog
21583.8.diff (21.3 KB) - added by lessbloat 20 months ago.
21583.9.diff (27.5 KB) - added by ryan 20 months 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 20 months ago.
21583.11.diff (28.8 KB) - added by ryan 20 months 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 20 months ago.
Removed label in "items per page" section, styled number input field.
21583.13.diff (34.0 KB) - added by ryelle 20 months ago.
21583.13.1.diff (34.2 KB) - added by ryelle 20 months ago.
21583.14.diff (9.9 KB) - added by ryan 20 months ago.
Do over. screen-options-wrap and contextual-help-wrap outside of admin bar.
21583.15.diff (10.4 KB) - added by ryan 20 months ago.
Markup fixes
21583.16.diff (10.4 KB) - added by ryan 20 months ago.
Gear to the far right
21583.17.diff (11.3 KB) - added by kadamwhite 20 months ago.
21583.18.a.diff (12.4 KB) - added by ryelle 20 months ago.
21583.18.b.diff (12.5 KB) - added by ryelle 20 months ago.
sticky-admin-bar.png (34.5 KB) - added by MikeHansenMe 19 months ago.
new sticky admin bar

Download all attachments as: .zip

Change History (73)

comment:1 sabreuse21 months ago

  • Cc sabreuse@… added

comment:2 chexee21 months ago

  • Cc helen.y.hou@… added

comment:3 ocean9021 months ago

  • Cc ocean90 added

ryan21 months ago

Just playing

comment:4 ryan21 months 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.

ryan21 months ago

comment:5 DrewAPicture20 months ago

  • Cc xoodrew@… added

comment:6 Mamaduka20 months ago

  • Cc georgemamadashvili@… added

comment:7 scribu20 months ago

  • Keywords has-patch added

comment:8 meliko20 months ago

  • Cc melissachoyce@… added

ryan20 months ago

comment:9 ryan20 months 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. :-)

ryan20 months ago

comment:10 taylorde20 months ago

  • Cc td@… added

comment:11 taylorde20 months 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 ryelle20 months 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.

ryelle20 months ago

taylorde20 months ago

taylorde20 months ago

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

taylorde20 months ago

/wp-includes/images/

taylorde20 months ago

/wp-includes/images/

comment:13 taylorde20 months 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 betzster20 months ago

  • Cc j@… added

meliko20 months ago

comment:15 meliko20 months 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.

meliko20 months 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.

meliko20 months ago

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

meliko20 months ago

Updated psd with cogs.

meliko20 months ago

2x admin bar psd with added cog

lessbloat20 months ago

comment:16 lessbloat20 months 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 0, edited 20 months ago by lessbloat (next)

comment:17 lessbloat20 months ago

  • Keywords needs-patch added; has-patch removed

ryan20 months ago

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

lessbloat20 months ago

comment:18 lessbloat20 months 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 20 months ago by lessbloat (previous) (diff)

ryan20 months ago

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

comment:19 ryan20 months 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 JerrySarcastic20 months ago

  • Cc fittingsites@… added

meliko20 months ago

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

comment:21 follow-up: meliko20 months 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 ryan20 months 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: koopersmith20 months 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 ryelle20 months 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.

ryelle20 months ago

comment:25 follow-up: lessbloat20 months 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

ryelle20 months ago

comment:26 in reply to: ↑ 25 ryelle20 months ago

Changed alignment per lessbloat's suggestion.

ryan20 months ago

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

comment:27 ryan20 months 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.

ryan20 months ago

Markup fixes

ryan20 months ago

Gear to the far right

comment:28 kadamwhite20 months ago

  • Cc kadamwhite added

kadamwhite20 months ago

comment:29 kadamwhite20 months 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 meliko20 months 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.

ryelle20 months ago

ryelle20 months ago

comment:31 ryelle20 months 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 kadamwhite20 months 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 meliko20 months 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 nacin19 months ago

  • Type changed from enhancement to task (blessed)

comment:35 follow-up: lessbloat19 months 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 ericmann19 months 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 JerrySarcastic19 months ago

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

comment:38 helenyhou19 months 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.

MikeHansenMe19 months ago

new sticky admin bar

comment:39 MikeHansenMe19 months 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 19 months ago by MikeHansenMe (previous) (diff)

comment:40 hidgw18 months ago

  • Cc hidgw added

comment:41 sillybean9 months ago

  • Cc steph@… added

comment:42 Hanni9 months ago

  • Cc h@… added

comment:43 dllh8 months ago

  • Cc daryl@… added

comment:44 jazzs3quence8 months ago

  • Cc chris@… added

comment:45 jazzs3quence8 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 8 months ago by jazzs3quence (previous) (diff)
Note: See TracTickets for help on using tickets.