Make WordPress Core

Opened 12 years ago

Last modified 11 months ago

#21583 new enhancement

Improve discoverability and visual design of Screen Options and Help Panels

Reported by: chexee's profile chexee Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Help/About Keywords: needs-patch has-screenshots
Focuses: ui, accessibility 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 12 years ago.
Just playing
21583.2.diff (10.5 KB) - added by ryan 12 years ago.
21583.3.diff (14.2 KB) - added by ryan 12 years ago.
21583.4.diff (13.9 KB) - added by ryan 12 years ago.
21583.5.diff (16.3 KB) - added by ryelle 12 years ago.
21583.6.diff (19.4 KB) - added by taylorde 12 years ago.
admin-bar-sprite-2x.psd (53.2 KB) - added by taylorde 12 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 12 years ago.
/wp-includes/images/
admin-bar-sprite.png (2.4 KB) - added by taylorde 12 years ago.
/wp-includes/images/
21583.7.diff (21.5 KB) - added by meliko 12 years ago.
admin-bar-sprite.2.png (5.2 KB) - added by meliko 12 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 12 years ago.
2x revision of the admin bar sprite with added cog icon.
admin-bar-sprite.psd (95.3 KB) - added by meliko 12 years ago.
Updated psd with cogs.
admin-bar-sprite-2x.2.psd (99.5 KB) - added by meliko 12 years ago.
2x admin bar psd with added cog
21583.8.diff (21.3 KB) - added by lessbloat 12 years ago.
21583.9.diff (27.5 KB) - added by ryan 12 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 12 years ago.
21583.11.diff (28.8 KB) - added by ryan 12 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 12 years ago.
Removed label in "items per page" section, styled number input field.
21583.13.diff (34.0 KB) - added by ryelle 12 years ago.
21583.13.1.diff (34.2 KB) - added by ryelle 12 years ago.
21583.14.diff (9.9 KB) - added by ryan 12 years ago.
Do over. screen-options-wrap and contextual-help-wrap outside of admin bar.
21583.15.diff (10.4 KB) - added by ryan 12 years ago.
Markup fixes
21583.16.diff (10.4 KB) - added by ryan 12 years ago.
Gear to the far right
21583.17.diff (11.3 KB) - added by kadamwhite 12 years ago.
21583.18.a.diff (12.4 KB) - added by ryelle 12 years ago.
21583.18.b.diff (12.5 KB) - added by ryelle 12 years ago.
sticky-admin-bar.png (34.5 KB) - added by MikeHansenMe 12 years ago.
new sticky admin bar

Download all attachments as: .zip

Change History (96)

#1 @sabreuse
12 years ago

  • Cc sabreuse@… added

#2 @chexee
12 years ago

  • Cc helen.y.hou@… added

#3 @ocean90
12 years ago

  • Cc ocean90 added

@ryan
12 years ago

Just playing

#4 @ryan
12 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.

@ryan
12 years ago

#5 @DrewAPicture
12 years ago

  • Cc xoodrew@… added

#6 @Mamaduka
12 years ago

  • Cc georgemamadashvili@… added

#7 @scribu
12 years ago

  • Keywords has-patch added

#8 @meliko
12 years ago

  • Cc melissachoyce@… added

@ryan
12 years ago

#9 @ryan
12 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. :-)

@ryan
12 years ago

#10 @taylorde
12 years ago

  • Cc td@… added

#11 @taylorde
12 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?

#12 @ryelle
12 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.

@ryelle
12 years ago

@taylorde
12 years ago

@taylorde
12 years ago

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

@taylorde
12 years ago

/wp-includes/images/

@taylorde
12 years ago

/wp-includes/images/

#13 @taylorde
12 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.

#14 @betzster
12 years ago

  • Cc j@… added

@meliko
12 years ago

#15 @meliko
12 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.

@meliko
12 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.

@meliko
12 years ago

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

@meliko
12 years ago

Updated psd with cogs.

@meliko
12 years ago

2x admin bar psd with added cog

@lessbloat
12 years ago

#16 @lessbloat
12 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).
Last edited 12 years ago by lessbloat (previous) (diff)

#17 @lessbloat
12 years ago

  • Keywords needs-patch added; has-patch removed

@ryan
12 years ago

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

@lessbloat
12 years ago

#18 @lessbloat
12 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 12 years ago by lessbloat (previous) (diff)

@ryan
12 years ago

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

#19 @ryan
12 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.

#20 @JerrySarcastic
12 years ago

  • Cc fittingsites@… added

@meliko
12 years ago

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

#21 follow-up: @meliko
12 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?

#22 @ryan
12 years ago

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

#23 in reply to: ↑ 21 ; follow-up: @koopersmith
12 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.

#24 in reply to: ↑ 23 @ryelle
12 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.

@ryelle
12 years ago

#25 follow-up: @lessbloat
12 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

@ryelle
12 years ago

#26 in reply to: ↑ 25 @ryelle
12 years ago

Changed alignment per lessbloat's suggestion.

@ryan
12 years ago

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

#27 @ryan
12 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.

@ryan
12 years ago

Markup fixes

@ryan
12 years ago

Gear to the far right

#28 @kadamwhite
12 years ago

  • Cc kadamwhite added

@kadamwhite
12 years ago

#29 @kadamwhite
12 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!

#30 @meliko
12 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.

@ryelle
12 years ago

@ryelle
12 years ago

#31 @ryelle
12 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).

#32 @kadamwhite
12 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?

#33 @meliko
12 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.

#34 @nacin
12 years ago

  • Type changed from enhancement to task (blessed)

#35 follow-up: @lessbloat
12 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?

#36 in reply to: ↑ 35 @ericmann
12 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.

#37 @JerrySarcastic
12 years ago

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

#38 @helenyhou
12 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.

@MikeHansenMe
12 years ago

new sticky admin bar

#39 @MikeHansenMe
12 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 12 years ago by MikeHansenMe (previous) (diff)

#40 @hidgw
12 years ago

  • Cc hidgw added

#41 @sillybean
11 years ago

  • Cc steph@… added

#42 @Hanni
11 years ago

  • Cc h@… added

#43 @dllh
11 years ago

  • Cc daryl@… added

#44 @jazzs3quence
11 years ago

  • Cc chris@… added

#45 @jazzs3quence
11 years 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 11 years ago by jazzs3quence (previous) (diff)

#46 @helen
10 years ago

#28390 was marked as a duplicate.

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


10 years ago

#48 @helen
10 years ago

#31674 was marked as a duplicate.

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


8 years ago

#50 @afercia
8 years ago

  • Focuses ui accessibility added
  • Keywords early removed

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


8 years ago

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


8 years ago

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


8 years ago

#54 @rianrietveld
8 years ago

We discussed this in the accessibility bug scrub.
In fact this is a design issue.
From our point of view: the tabs should be added after the main heading in the source, the rest is up to the designer.
This could be a nice design feature project.
Plan is to also look at it on the WordCamp Netherlands contributors day.

Edited for clarity: added the main heading > added after the main heading

Last edited 7 years ago by afercia (previous) (diff)

#55 @hedgefield
7 years ago

I see this ticket has been inactive for a while now. For starters, I'd like to drop this mockup that @melchoyce made in #28390 https://choycedesign.com/wpadmin-ui/screen-options.html I like the icons that she used there, I was going to make a similar mockup. As a first step at least, could we replace the text on the tabs now with these icons?

Version 0, edited 7 years ago by hedgefield (next)

#56 @afercia
7 years ago

  • Keywords has-screenshots added

For many users, content navigation is a linearised process. Ideally, the content order in the source should follow a logical flow, and this would benefit all users.

Currently, when landing in the main content, the first things in the source order are the Help and Screen Options (they're floated right, so "Help" is the first one). Basically users will find something related to Help and Screen Options even before they're informed about what the page is about (because this info is given by the main heading, which comes after).

Moving Help and Screen Options after the main heading in the source order would be a nice improvement. However, the technical issue is those tabs are printed out with render_screen_meta() in admin-header.php. That's clean, but happens before any output in the main content. It would be great to find a good technical solution to keep the code clean enough and at the same time output Help and Screen Options later.

Icons-only control:
not sure they're the best solution for usability and accessibility. Usability: see https://www.nngroup.com/articles/icon-usability/ suggesting icons should always use a text label for universal understanding. For a11y, same: they should have an universal meaning and some meaningful alternate text.

Fly-out popups (or whatever we want to call them :)):
they're a bit tricky: they should be treated as modal dialogs: tabbing should be constrained within the popup, focus should be managed when opening/closing the popup etc. Also, they look nice with the Screen Options form fields, not sure if they would fit so well with the Help content which is, often, very long. Maybe worth exploring alternate, simpler, solutions.

From a design perspective, worth noting in other WP screens the space to the right already has the search form and other stuff:

https://cldup.com/8pCVx3--KO.png

A redesign should maybe re-think the whole "top area" of the admin screens, trying to reorganise and group the various controls based on their functionality. Personally, I'd start with the "Add" button :)
About the search, see also #31818.

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


7 years ago

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


5 years ago

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


3 years ago

#60 @oglekler
20 months ago

#51006 is a proposal about Tooltips, and from my point of view this functionality can be related to this new-look implementation.

I believe that this question mark in a circle is a default standard for Help, and it will be more noticeable. The same is for Screen options, I am forgetting that they exist from times to times.

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


19 months ago

#62 @joedolson
19 months ago

There are some design ideas in the work on the feature proposal for a notifications hub that may be useful here. It would make sense to group options/help/notifications as set of controls, so all of that could be redesigned together.

See https://github.com/WordPress/wp-feature-notifications

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


19 months ago

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


19 months ago

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


18 months ago

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


15 months ago

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


12 months ago

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


11 months ago

Note: See TracTickets for help on using tickets.