WordPress.org

Making WordPress.org

Opened 2 years ago

Last modified 2 months ago

#2776 reopened enhancement

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:

  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.

Attachments (15)

comparison-small-viewport.jpg (285.1 KB) - added by kevinwhoffman 2 years ago.
Plugin Directory Navigation - Small Viewport
comparison-medium-viewport.jpg (336.8 KB) - added by kevinwhoffman 2 years ago.
Plugin Directory Navigation - Medium Viewport
comparison-large-viewport.jpg (267.6 KB) - added by kevinwhoffman 2 years ago.
Plugin Directory Navigation - Large Viewport
2017-04-24 at 10.39 AM.jpg (47.2 KB) - added by jb510 2 years ago.
2017-04-24 at 11.43 AM.jpg (38.5 KB) - added by jb510 2 years ago.
small-viewport-more.jpg (34.0 KB) - added by kevinwhoffman 2 years ago.
Small viewport with More tab appearing in line with the others.
2776.diff (14.3 KB) - added by ck3lee 4 months ago.
2776 desktop.png (574.6 KB) - added by ck3lee 4 months ago.
Desktop
2776 tablet.png (365.3 KB) - added by ck3lee 4 months ago.
Tablet
2776 mobile.png (168.9 KB) - added by ck3lee 4 months ago.
Mobile
2776.1.diff (13.8 KB) - added by ck3lee 4 months ago.
2776.2.diff (665.9 KB) - added by ck3lee 3 months ago.
2776.3.diff (1.1 MB) - added by ck3lee 3 months ago.
2776.4.diff (13.7 KB) - added by ck3lee 3 months ago.
2776.5.diff (13.8 KB) - added by ck3lee 3 months ago.

Change History (46)

@kevinwhoffman
2 years ago

Plugin Directory Navigation - Small Viewport

@kevinwhoffman
2 years ago

Plugin Directory Navigation - Medium Viewport

@kevinwhoffman
2 years ago

Plugin Directory Navigation - Large Viewport

#1 @jb510
2 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).

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

Last edited 2 years ago by jb510 (previous) (diff)

#2 follow-up: @webdevmattcrom
2 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 @mapk
2 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: @mapk
2 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: @kevinwhoffman
2 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 @jb510
2 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: @jb510
2 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 @kevinwhoffman
2 years ago

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

#9 @Asif2BD
2 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: @mapk
2 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 @kevinwhoffman
2 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.

Last edited 2 years ago by kevinwhoffman (previous) (diff)

#12 follow-up: @mapk
2 years ago

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

https://cldup.com/2hiZWMdz0z.gif

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

#13 @jb510
2 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 @jb510
2 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.

Last edited 2 years ago by jb510 (previous) (diff)

#15 @kevinwhoffman
2 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:

  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
2 years ago

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

This ticket was mentioned in Slack in #meta by kevinwhoffman. View the logs.


2 years ago

#17 @mapk
2 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!

https://cldup.com/F6ONY3YLsM.gif

#18 @kevinwhoffman
2 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.


2 years ago

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


2 years ago

This ticket was mentioned in Slack in #meta by kevinwhoffman. View the logs.


2 years ago

#22 @tellyworth
22 months ago

  • Keywords needs-patch added

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

@ck3lee
4 months ago

@ck3lee
4 months ago

Desktop

@ck3lee
4 months ago

Tablet

@ck3lee
4 months ago

Mobile

#23 @ck3lee
4 months 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.

@ck3lee
4 months ago

#24 @ck3lee
4 months 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.

#25 @tellyworth
3 months ago

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

#26 @tellyworth
3 months ago

  • Owner set to tellyworth
  • Resolution set to fixed
  • Status changed from new to closed

In 8881:

Plugin directory theme: bust cache for [8880]

Props ck3lee
Fixes #2776

This ticket was mentioned in Slack in #forums by tellyworth. View the logs.


3 months ago

#28 @tellyworth
3 months ago

In 8882:

Plugin directory theme: revert [8881-8880]

The Support link is handled inconsistently and needs further thought.

See #2776

#29 @tellyworth
3 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

@ck3lee
3 months ago

@ck3lee
3 months ago

@ck3lee
3 months ago

@ck3lee
3 months ago

#30 @ck3lee
3 months 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.

This ticket was mentioned in Slack in #meta by tellyworth. View the logs.


2 months ago

Note: See TracTickets for help on using tickets.