Opened 3 years ago
Last modified 6 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)
Change History (76)
comment:4 @ryan — 3 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.
comment:5 @DrewAPicture — 3 years ago
- Cc xoodrew@… added
comment:9 @ryan — 3 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. :-)
comment:10 @taylorde — 3 years ago
- Cc td@… added
comment:11 @taylorde — 3 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 @ryelle — 3 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.
comment:13 @taylorde — 3 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 @betzster — 3 years ago
- Cc j@… added
comment:15 @meliko — 3 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 — 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.
@lessbloat — 3 years ago
comment:16 @lessbloat — 3 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).
comment:17 @lessbloat — 3 years ago
- Keywords needs-patch added; has-patch removed
@ryan — 3 years ago
Refresh .8.diff. Move help from render_screen_meta() into render_help() sans the other junk.
@lessbloat — 3 years ago
comment:18 @lessbloat — 3 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.
@ryan — 3 years ago
Add html_callback meta arg to add_menu(). Move help rendering to _render_help() callback.
comment:19 @ryan — 3 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 @JerrySarcastic — 3 years ago
- Cc fittingsites@… added
comment:21 follow-up: ↓ 23 @meliko — 3 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 @ryan — 3 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: ↓ 24 @koopersmith — 3 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 @ryelle — 3 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.
comment:25 follow-up: ↓ 26 @lessbloat — 3 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:
comment:26 in reply to: ↑ 25 @ryelle — 3 years ago
Changed alignment per lessbloat's suggestion.
comment:27 @ryan — 3 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.
comment:28 @kadamwhite — 3 years ago
- Cc kadamwhite added
@kadamwhite — 3 years ago
comment:29 @kadamwhite — 3 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 @meliko — 3 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.
comment:31 @ryelle — 3 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 @kadamwhite — 3 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 @meliko — 3 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 @nacin — 3 years ago
- Type changed from enhancement to task (blessed)
comment:35 follow-up: ↓ 36 @lessbloat — 3 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 @ericmann — 3 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 @JerrySarcastic — 3 years ago
+1 for punting the package—it would be better to nail this than to get it half-baked.
comment:38 @helenyhou — 3 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.
comment:39 @MikeHansenMe — 3 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.
comment:40 @hidgw — 3 years ago
- Cc hidgw added
comment:41 @sillybean — 2 years ago
- Cc steph@… added
comment:42 @Hanni — 2 years ago
- Cc h@… added
comment:43 @dllh — 2 years ago
- Cc daryl@… added
comment:44 @jazzs3quence — 2 years ago
- Cc chris@… added
comment:45 @jazzs3quence — 2 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.)
comment:46 @helen — 17 months ago
#28390 was marked as a duplicate.
comment:47 @slackbot — 7 months ago
This ticket was mentioned in Slack in #core-flow by drew. View the logs.
comment:48 @helen — 6 months ago
#31674 was marked as a duplicate.
Just playing