Plugin Directory: Improve responsive design of tabs

[kevinwhoffman]

Goals:

1. Improve tabbed navigation across all viewports.
2. 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.
3. 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.

[kevinwhoffman]

Plugin Directory Navigation - Small Viewport

[kevinwhoffman]

Plugin Directory Navigation - Medium Viewport

[kevinwhoffman]

Plugin Directory Navigation - Large Viewport

[jb510]

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).

"Download" could also become an icon on mobile next to the heart.

[webdevmattcrom]

@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/

[mapk]

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.

[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.

[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.

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

[jb510]

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.

[jb510]

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.

[kevinwhoffman]

@jb510 It's worth discussing. Maybe in a new ticket... "Plugin Directory: Improve responsive design of header"

[Asif2BD]

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.

[mapk]

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.

[kevinwhoffman]

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 in one viewport upon arrival.

[mapk]

This isn't perfect, but it's a go at it.

Codepen: ​http://codepen.io/mapk/pen/GmroVL

[jb510]

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)

[jb510]

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.

[kevinwhoffman]

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:

1. Use the word "More" to better communicate its intended purpose. Both my arrow and Mark's ellipsis are a little ambiguous.
2. 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.

[kevinwhoffman]

Small viewport with More tab appearing in line with the others.

[mapk]

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!

[kevinwhoffman]

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

[tellyworth]

Needs someone to take a shot at adapting @mapk's JS.

[ck3lee]

Desktop

[ck3lee]

Tablet

[ck3lee]

Mobile

[ck3lee]

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.

[ck3lee]

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

[tellyworth]

In 8880:

Plugin directory theme: Improve responsive design of tabs.

This replaces the pure CSS tabs with a JS implementation that makes changes more manageable, and deals with some accessibility and responsiveness issues.

Props ck3lee
See #2776

[tellyworth]

In 8881:

Plugin directory theme: bust cache for [8880]

Props ck3lee
Fixes #2776

[tellyworth]

In 8882:

Plugin directory theme: revert [8881-8880]

The Support link is handled inconsistently and needs further thought.

See #2776

[ck3lee]

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.

[dd32]

In 9681:

Plugin Directory: Responsive Tabs: Prevent the menu vertical size jumping around while hovering menu items.

See #2776.

[dd32]

I'm going to close this, as the design has recently changed significantly, and as far as I can tell, this is no longer relevant.