Opened 8 years ago
Closed 7 months ago
#2776 closed enhancement (fixed)
Plugin Directory: Improve responsive design of tabs
Reported by: | kevinwhoffman | Owned by: | tellyworth |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Plugin Directory | Keywords: | ui-feedback ux-feedback has-screenshots has-patch |
Cc: |
Description
Goals:
- Improve tabbed navigation across all viewports.
- Remove the limitation of viewport width when determining the ideal number of tabs. In other words, desktop navigation should not be limited by the space available on a small tablet.
- Improve the accessibility and discoverability of important pieces of content such as Screenshots, FAQ, and Stats.
By improving the responsive design of the tabbed navigation, large viewports can make the most of the available space while improving the presentation and user experience on smaller viewports.
The attached mockups contain designs and rationale to address the challenges of small, medium, and large viewports.
Attachments (15)
Change History (49)
#1
@
8 years ago
This looks REALLY good.
Suggestion: On mobile drop the banner and keep the logo. To make room for the logo left of the title, drop or since we can't really do that, minimize the download button. The download button doesn't make sense on mobile anyway. It's only there because technically people can get to that width on a desktop and because we'd all like to pretend it was an "install" button that magically opened up the site and installed the plugin (totally different ticket).
#2
follow-up:
↓ 4
@
8 years ago
@jb510 I think horizontal space is a major concern with keeping the logo. Some plugins have very long titles. Examples:
https://wordpress.org/plugins/give/
https://wordpress.org/plugins/caldera-forms/
https://wordpress.org/plugins/google-analytics-for-wordpress/
#3
@
8 years ago
These are great, @kevinwhoffman! Here's some comments...
Small & Medium viewports
I personally would like to stay away from a complete accordion-style subnav because having two similarly styled accordion navs gets a little wonky. Maybe we could keep your Medium Viewport styling for the Small viewport too?
Something like this:
http://codepen.io/kvana/pen/ZbENqr
So it's just a gradually responsive menu that only tucks items under a dropdown when the viewport necessitates it. This feels better to me. Ideally the two or three menu items on the left side would be the most important, so they'd be always visible no matter the viewport.
#4
in reply to:
↑ 2
;
follow-up:
↓ 6
@
8 years ago
Replying to webdevmattcrom:
@jb510 I think horizontal space is a major concern with keeping the logo. Some plugins have very long titles. Examples:
I'm all for keeping the avatar hidden on the smaller viewports as well.
#5
follow-ups:
↓ 7
↓ 10
@
8 years ago
There's a discussion to be had regarding icons and banners, but let's keep this ticket focused on navigation. I did clean up the header on mobile, but only to better communicate the proposed navigation changes.
@mapk I see your point about the dual accordions. I also considered using the medium viewport styling on small viewports. The reason I decided against it is because I don't see more than two tabs fitting alongside a "more" button or icon in a 320px viewport. With two tabs visible, the expansion menu essentially becomes an accordion anyways.
With that said, I would be in favor of decreasing the min-width of the mobile breakpoint when at least three tabs are visible. We should also consider other languages and keep in mind that tab width may vary. Breakpoints may need adjusted for some languages or at least handled in a conservative manner across the board.
#6
in reply to:
↑ 4
@
8 years ago
Replying to mapk:
Replying to webdevmattcrom:
@jb510 I think horizontal space is a major concern with keeping the logo. Some plugins have very long titles. Examples:
I'm all for keeping the avatar hidden on the smaller viewports as well.
I understand the concern for horizontal space, but vertical space is an issue too. The banner adds nothing of value on mobile. Using mobile first principles the banner should get added when there is extra space but isn't really needed at smaller sizes. There should be some visual indicator, but the logo/avatar is sufficient for that. Maybe have the logo left of the text, maybe above and inline with fav/download. I just don't think laying out the download button above the title makes much sense.
Then (excuse the mockup doesn't show this) we could put the rating and active install count on that same line. These two things (from the users tests I watched) seemed to be the most important info for people, but on mobile they're demoted to bottom of the page.
#7
in reply to:
↑ 5
;
follow-up:
↓ 8
@
8 years ago
Replying to kevinwhoffman:
There's a discussion to be had regarding icons and banners, but let's keep this ticket focused on navigation. I did clean up the header on mobile, but only to better communicate the proposed navigation changes.
Good point... going quiet on the banner/logo.
#8
in reply to:
↑ 7
@
8 years ago
@jb510 It's worth discussing. Maybe in a new ticket... "Plugin Directory: Improve responsive design of header"
#9
@
8 years ago
If this ticket gets accepted(which it should), we are kind of back in where it begins, but for good reason. The discussion of removing Tabs was never accepted by anybody from any discussion, besides that imaginary imposed 80%. Here points by @kevinwhoffman is very logical and well placed. Need the community to back it now.
#10
in reply to:
↑ 5
;
follow-up:
↓ 11
@
8 years ago
Replying to kevinwhoffman:
@mapk I see your point about the dual accordions. I also considered using the medium viewport styling on small viewports. The reason I decided against it is because I don't see more than two tabs fitting alongside a "more" button or icon in a 320px viewport. With two tabs visible, the expansion menu essentially becomes an accordion anyways.
I think that's okay. Showing two tabs next to a 'more' link (dare I say a 'read more' link - haha) is good in my opinion. Those should be the two most important tabs which allow for a one-click interaction to view them. If it's done using JS as in the example I shared, we don't need to worry about media queries, and just rely on math to figure it out.
#11
in reply to:
↑ 10
@
8 years ago
Replying to mapk:
...Those should be the two most important tabs which allow for a one-click interaction to view them. If it's done using JS as in the example I shared, we don't need to worry about media queries, and just rely on math to figure it out.
I've been thinking about this more and the two tabs may work alongside an expansion button, especially if we move Screenshots back to a dedicated tab. Then having Details and Screenshots tabs one click away on all viewports would be helpful. IMO Details and Screenshots are the two pieces of content that allow the user to grasp the essence of a plugin, followed closely by Reviews when making a download decision.
Furthermore, if we were able to include the overall star rating in the header like @jb510 suggested, then we'd be providing access to three of the most influential pieces of content (Details, Screenshots, Reviews) in one viewport upon arrival.
#13
@
8 years ago
Looking more at this. I like the idea of continuing to stuff overflow items in the drop down menu (comparison-medium-viewport.jpg) all the way down to it just being "Details \/" A very sloppy codepen: http://codepen.io/jb510/pen/RVKRxp
This also has the added benefit of not being a full-width vertical accordion, it can just open "partial width" just like the global wp.org menu's hamburger icon (only right justified instead of left)
#14
in reply to:
↑ 12
@
8 years ago
Replying to mapk:
This isn't perfect, but it's a go at it.
[snip]
Codepen: http://codepen.io/mapk/pen/GmroVL
LOL... I hereby retract my sloppy CodePen... this is exactly what I was aiming for.
#15
@
8 years ago
I like this direction. Thank you both for the CodePens. Mark has styled the dropdown in a way that looks like the other tabs, which makes me think the "more" functionality could work as an extension of the existing tab set, rather than a separate experience like I originally proposed with the arrow button. Two suggestions:
- Use the word "More" to better communicate its intended purpose. Both my arrow and Mark's ellipsis are a little ambiguous.
- Keep the "More" tab aligned left with the others, so that it appears exactly as if it was the 3rd, 4th, 5th tab, etc. until it's no longer needed. This will make it more obvious that it's part of the navigation.
This ticket was mentioned in Slack in #meta by kevinwhoffman. View the logs.
8 years ago
#17
@
8 years ago
I've got it just about dialed in with really bad JS. :)
The responsiveness of the tabs works pretty well. Try it out here:
http://codepen.io/mapk/full/BRWGWQ/
If anyone has any suggestions or feedback, please speak up. We'll be looking to get this implemented as soon as the JS gets worked out better. Thanks!
#18
@
8 years ago
@mapk This looks really good to me. Keep in mind there is also an Installation
tab on the live Plugin Directory, but the way you are calculating widths means the number of tabs should not matter. Good stuff.
This ticket was mentioned in Slack in #meta by kevinwhoffman. View the logs.
8 years ago
This ticket was mentioned in Slack in #accessibility by kevinwhoffman. View the logs.
8 years ago
This ticket was mentioned in Slack in #meta by kevinwhoffman. View the logs.
8 years ago
#23
@
6 years ago
- Keywords has-patch added; needs-patch removed
Hi @kevinwhoffman @mapk @jb510 @tellyworth,
I’m taking a stab at this old ticket, with the primary goal to improve accessibility for tab navigation and simplifying the CSS. Please have a look at attachment:2776.diff. Let me know what you think. Happy to make changes/fix if necessary.
Current state:
- Tab buttons and tab panels are missing appropriate
aria
attributes. - Using
anchor
as tab buttons can be confusing - tab does not link to another page. Support
links to another page but it looks like a tab button.
Proposed:
- Add appropriate aria attributes.
- Use
button
for tab buttons. - Style Support link as a link.
- Move Support link to the the most right.
- Wrap tab buttons using
flex
for responsiveness. - Implement the tab switching in JavaScript, instead of CSS.
Notes:
- I'm using
flex
for responsiveness to keep things simple. Definitely not as nice as mapk’s JS approach. - I usually shy away from JS to calculate width and handle resizing. But, I can implement the JS approach if you think flex/wrapping approach is not good enough for responsiveness.
- Kept the handling of
#
to open target tab on page load.
#24
@
6 years ago
@tellyworth gave me feedback about using onclick
with inline JavaScript on html elements.
attachment:2776.1.diff consists all the proposed changes with refactoring to take advantage of jQuery.
#26
@
6 years ago
- Owner set to tellyworth
- Resolution set to fixed
- Status changed from new to closed
In 8881:
This ticket was mentioned in Slack in #forums by tellyworth. View the logs.
6 years ago
#30
@
6 years ago
Thank you, @tellyworth.
In attachment:2776.5.diff, it restores the position and styling of Support link to the current implementation. Please test and review when you get a chance, I hope this works.
Please ignore other diffs. They were uploaded by mistake.
Plugin Directory Navigation - Small Viewport