Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filter counter in button and tab #482

Closed
fcoveram opened this issue Dec 1, 2022 · 7 comments · Fixed by #826 · May be fixed by WordPress/openverse-frontend#2143
Closed

Filter counter in button and tab #482

fcoveram opened this issue Dec 1, 2022 · 7 comments · Fixed by #826 · May be fixed by WordPress/openverse-frontend#2143
Assignees
Labels
🖼️ aspect: design Concerns related to design 🕹 aspect: interface Concerns end-users' experience with the software ✨ goal: improvement Improvement to an existing user-facing feature 🟨 priority: medium Not blocking but should be addressed soon 🧱 stack: frontend Related to the Nuxt frontend

Comments

@fcoveram
Copy link
Contributor

fcoveram commented Dec 1, 2022

Problem

The new header simplifies its layout by grouping elements as the viewport goes smaller, but at the same time, it hides the counter label of filters applied when visitors play with the feature.

This element helps users to remember the criteria set to narrow the results, and to convey the filter reset when shifting to a content type that does not match the filter criteria. For this second case, it is crucial to be clear that filters are no longer applied in this new content type.

Due to these two reasons, it becomes necessary to bring back the value and make it consistent in both the filter button and the drawer.

Related issues

The problem was identified by @zackkrida in WordPress/openverse-frontend#1861


Proposal

Desktop flow. lg

Filter.counter.XL.mp4

Mobile flow. sm

Filter.counter.SM.mp4

Mockups

Desktop lg Mobile sm
Filter counter (xl) Filter counter (sm)

Description

Now that we can separate the counter from the string, replacing the filter icon with the counter solves the shaking effect of the width change in the header.

The design keeps the 24px box for both filter icon and the counter across all breakpoints. For the filter button, the resting state has dark-charcoal-10 as background color to match the search input, whereas the active state has no background.

In the case of the drawer, both tabs have an icon visible all the time. The “Content type" tab shows the active content while “Filters” works as its desktop version to reach more consistency. Since both tabs show an icon, the label’s text style is label regular to reduce the layout contrast.

In lg breakpoint, the counter has a background just in the icon-size area, while its active state has a background in the button-size area, as shown below.

Filter counter LG

Since the design proposes to move the counter number into the drawer’s tab, there is no need to show it in the "Clear filters" action. In that vein, we reach consistency with its desktop version by showing the same element.


Feedback

The changes impact the drawer mostly, yet the tweaks make the flow more clear and consistent across breakpoints. What do you think of the idea?

Design assets

@fcoveram fcoveram added 🚦 status: awaiting triage Has not been triaged & therefore, not ready for work ✨ goal: improvement Improvement to an existing user-facing feature 🖼️ aspect: design Concerns related to design labels Dec 1, 2022
@openverse-bot
Copy link
Collaborator

Subscribe to Label Action

cc @WordPress/gutenberg-design, @WordPress/openverse

This issue or pull request has been labeled: "🖼️ aspect: design"

Thus the following users have been cc'd because of the following labels:

  • WordPress/gutenberg-design: 🖼️ aspect: design
  • WordPress/openverse: 🖼️ aspect: design

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

@jasmussen
Copy link

Nice work. I appreciate you've been able to unify the content type picker with the filter picker on mobile.

On desktop it makes a ton of sense to replace the filter icon with the number of filters applied, because the label remains as context. I wish a similar pattern culd work on mobile, though I suppose the unread dot can work in its place. Perhaps an alternative would be to have the number shown to the left of the Settings icon?

Related, the white background around the settings icon feels like a "holepunch" in the search box. I wonder if there's an opportunity there.

Perhaps on mobile the settings icon rests, sans background, on the gray search input. When a filter is applied, it gets a boundary — white or gray or a border — and the boundary is extended leftwards to leave room to show the the number of filters applied. What do you think? It's nitpick territory, the dot works.

@fcoveram
Copy link
Contributor Author

fcoveram commented Dec 1, 2022

On desktop it makes a ton of sense to replace the filter icon with the number of filters applied, because the label remains as context. I wish a similar pattern could work on mobile, though I suppose the unread dot can work in its place.

Actually, it does not. The dot indicator points that "you applied" one or several filters, but not "how many" or "which ones."

Think of the following scenario on mobile.

  1. User searches "cats" in images from the homepage.
  2. Open the Settings, and the drawer shows the content type tab.
  3. Tap on Filters tabs and enable "license: CC0" and "Image size: Large."
  4. See the results. The drawer closes.
  5. Open the Settings and the drawer shows the Filters tab.
  6. Tap on Content type to change to Audio
  7. Select audio

In the example, shifting to audio means that "License: CC0" remains, but there is no "Image size" criterion. For this we have two options:

  1. Just keep "License: CC0" enabled (Filters applied = 1)
  2. Reset filters (Filters applied = 0)

In both cases we need to convey that filters changed. And the dot indicator is insufficient for that purpose.

Even if we show the Filter counter next to the Settings button, I am afraid that it might not be fully visible. The change will happen in the background, behind the dark-opaque layer, while the focus is set on the drawer's content. Therefore, the drawer is the "safest" place to convey this info.

@zackkrida zackkrida added 🟨 priority: medium Not blocking but should be addressed soon and removed 🚦 status: awaiting triage Has not been triaged & therefore, not ready for work labels Dec 2, 2022
@obulat obulat self-assigned this Dec 6, 2022
@zackkrida
Copy link
Member

This looks like a great way to reduce movement in the UI. It's a different issue, but I'd also like to consider a fixed width for the searchbar or the content switcher to prevent motion there as well.

@zackkrida zackkrida mentioned this issue Dec 6, 2022
2 tasks
@fcoveram
Copy link
Contributor Author

fcoveram commented Dec 7, 2022

Consider a fixed width for the search bar or the content switcher to prevent motion there as well.

When designing the new header, I thought of a full-width search bar to avoid white spaces between the input and buttons. I assumed that filtering was a more typical action than shifting to another content type, so the motion effect is likely less visible.

For the 2xl breakpoint, the search is fixed. The full-width would look too prominent on large screens. Although I have not reviewed the implementation nor detailed the condition prior to the hands-off.

@fcoveram
Copy link
Contributor Author

fcoveram commented Dec 7, 2022

As mentioned during the weekly meeting, I will start preparing the assets for its implementation.

@fcoveram
Copy link
Contributor Author

fcoveram commented Dec 15, 2022

The assets are ready to start the implementation ✨

Please start with the Design page to understand the proposal, the Mockups for the design specs, and Prototype whether you want to interact with the mobile view.

I will update the initial message and status label for ready for work.

@fcoveram fcoveram added the 🏁 status: ready for work Ready for work label Dec 15, 2022
@obulat obulat transferred this issue from WordPress/openverse-frontend Feb 22, 2023
@obulat obulat added the 🧱 stack: frontend Related to the Nuxt frontend label Feb 22, 2023
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Openverse Backlog Feb 23, 2023
@obulat obulat moved this from 📋 Backlog to 🏗 In progress in Openverse Backlog Feb 24, 2023
@obulat obulat moved this from 🏗 In progress to 👀 In review in Openverse Backlog Feb 24, 2023
@obulat obulat moved this from 👀 In review to 🏗 In progress in Openverse Backlog Feb 24, 2023
@obulat obulat added 🕹 aspect: interface Concerns end-users' experience with the software and removed 🏁 status: ready for work Ready for work labels Feb 25, 2023
@github-project-automation github-project-automation bot moved this from 🏗 In progress to ✅ Done in Openverse Backlog Mar 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🖼️ aspect: design Concerns related to design 🕹 aspect: interface Concerns end-users' experience with the software ✨ goal: improvement Improvement to an existing user-facing feature 🟨 priority: medium Not blocking but should be addressed soon 🧱 stack: frontend Related to the Nuxt frontend
Projects
Archived in project
5 participants