Meta search should be disabled on all content results

[fcoveram]

Description

In all content results, the meta search section is visible at the end of the grid. This should be disabled as the section was designed to list sources related to a single content type and not multiple, as in this layout case. This logic applies to the outdated and the new design.

Reproduction

1. Search for something.
2. Go or switch to All content results.
3. See the final section, after the results grid.
4. See the meta search section.

Screenshots

Resolution

• 🙋 I would be interested in resolving this bug.

[ramadanomar]

I would be interested in resolving this bug.

[zackkrida]

@panchovm I'm concerned about hiding this feature form our default search view.

What do you think if we showed multiple dropdowns, one for each content type, or a single dropdown grouped by "image", "audio" and so on? We'd also need to change the language to "Try additional sources", removing the media type.

[fcoveram]

Why are you concerned? I think that showing the metasearch forces this layout unnecessarily. The external sources list is for visitors not finding what they want, and that makes more sense doing it on the content type result after loading several results.

I am curious to hear other thoughts.

[ramadanomar]

For further context, this is how it would look if we removed the metasearch on searches. I don't think it disturbs anyone, especially because it is located after the results.

[ramadanomar]

I agree with @zackkrida that we should add a more generic search text.
Currently we have it hard coded to display images for all content.

    const metaSearchFormType = computed(() => {
      if (mediaTypes.includes(props.searchType)) {
        return props.searchType
      }
      return IMAGE
    })

[fcoveram]

Not sure if I understood your point @ramadanomar correctly. Are you agree showing or hiding the metasearch section?

[ramadanomar]

Not sure if I understood your point @ramadanomar correctly. Are you agree showing or hiding the metasearch section?

Sorry! I think we should keep the metasearch section but change the copy to something more generic

[ramadanomar]

Any update on this issue?

[zackkrida]

My thinking here, @panchovm was that I don't like conditionally showing/hiding pieces of the UI without the user knowing about it.

A similar concern I have is in the filter sidebar. That might be a good example. I plan to make an issue for this today, but I do not like how the filter sidebar has fewer filters on the 'all results' view than the single media type views. Of course, this is necessary, but I think it would be great to have a message at the bottom of the filterbar that says something like 'Choose a single media type to view detailed source and media-specific filters', something like that.

My logic here is the same. I don't want 'all results' to be an inadequate experience if it doesn't have to be.

[fcoveram]

I don't like conditionally showing/hiding pieces of the UI without the user knowing about it.

I didn't understand this point, but I understand the core of your concern. If we think is useful, then let's tag it with needs design to design a solution.

I do not like how the filter sidebar has fewer filters on the 'all results' view than the single media type views.

Showing more or fewer filters should not be a concern as far as they relate to the result on the left. I have discussed this several times with other designers when designing the header interaction and tabs for content type/filters. Showing filters that impact just a portion of the results, like aspect ratio for images or duration for audio, is risky and could be very confusing.

My logic here is the same. I don't want 'all results' to be an inadequate experience if it doesn't have to be.

Fully agree with you. And because of that, I need to insist on an argument mentioned in previous discussions: if we do not know how visitors value and interact with this page, then we should not add more features.

[zackkrida]

Showing filters that impact just a portion of the results, like aspect ratio for images or duration for audio, is risky and could be very confusing.

I agree with this and definitely do not want to do it. I just want users to know that more filters are available. That's my core concern: if we have features that are only available in certain views, that aren't the default view, how can we make sure users know about them?

if we do not know how visitors value and interact with this page, then we should not add more features.

I'm not sure I agree with this. I definitely want user data to inform our decisions as much as possible, but there occasions where we have to use our expertise to make a best-guess. For example, we have no way of knowing how many Openverse users use screenreaders. Does that mean we shouldn't make things accessible? I don't think so, because accessibility is something we value and think is valuable to users, even if its a small subset of users.

I think we can work towards getting more data and make best-guess desicions using our judgement at the same time.

[fcoveram]

Now I understand better your point about filters. And I agree with you to convey the set of features for interacting with content.

Regarding knowing openverse visitors, I understand that completely. Especially as a designer having to design without content or stats to support design decisions. And that should not stop us from making a product, definitely.

My point was about what we consider an "inadequate experience". From a design perspective, features must explain themselves by matching people's expectations and their mental models. But this product definition discussion also relates to the decision-making process and what set of features we decide to set and follow. In that vein, a11y is a foundational aspect of the web and design, and both should embrace it at their cores.

[marko-srb]

Hi there. My intuitive thoughts are:

Having 'Metasearch' is a good thing.

After researching at Openverse, I'd need additional resources to find the appropriate content. Way to have it, while not overwhelming the user, in my opinion, is:

1. Have a dropdown or hover list of external resources, below the grid.
2. Have that dropdown or hover list only on specific (one type) content results and not in general search where all content results appear.

To expand.

1. Dropdown or hover list will condense the information and not confuse the user. Although an additional step, the user will happily hover or click when they need the content.
2. Why shouldn't 'All content results' include metasearch?
   We can confidently assume that content research goes like any other research. First, you research your topic very broadly, then narrow it down and focus on one thing at a time. The same shall apply to 'Openverse' or any other search engine. Once I find what I am seeking about my topic, I'll focus only on image results to find the image I need to use. Or audio. Or other. And once I am in the image results only, I may be thankful to learn about different resources ('Metasearch') if the results I see in Openverse are not what I need.

Additionally.
*And what about it being at the end of the page? Well, we don't need to suggest to the user that we have a helpful 'Metasearch' with external resources, we want them to use Openverse. Only if they don't find what they need, we want to be valuable enough and leave metasearch afterward. So, underneath the grid is a good place for me.

Hope this helps.

[jasmussen]

Great thoughts all around! Regardless of when/where/how the meta-search tool shows up, I would echo the opportunity to minimize its design to have less prominence, which could in turn make feature more glancable/actionable.

Whether it shows up only on individual filters, or even on the "all content search" I have a less strong opinion about. But it's worth noting that even if it does show up everywhere, the content of the dropdown will still change, as it doesn't make sense to suggest "soundcloud" on the Image filter, for example.

[fcoveram]

The Metasearch is definitely a great feature. It allows visitors to find relevant content when they do not find something in Openverse.

I agree with you @marko-srb that it makes more sense to show the external sites in the single-content results as it is consistent with the content seeking. The dropdown design idea was already designed, but its implementation in WordPress/openverse-frontend#734 is blocked by a shift in the term used for the sources in WordPress/openverse-frontend#1197.

Your point @jasmussen aligns with mine about adding a browsing complexity to the meaning of this page. If we go with keeping the feature, it would be necessary to split the dropdown and create a new variant of the menu.

Thanks for jumping in and sharing your thoughts.

[zackkrida]

Totally agree with visually minimizing the meta search feature, which should land in this PR in the next week:

WordPress/openverse-frontend#1665

The descriptions from @marko-srb about the desired user flow make sense to me. I'm still of the opinion that always having the feature at the bottom of the results with a scoped dropdown only containing the relevant media types is best for the sake of consistency and predictability. I don't see how doing so would be detrimental. Ignore my horrible styling but you get the idea:

I am fine with hiding it on the 'all results' view and unblocking this, however. Once we make progress on some analytics work and find out how often this feature is actually used, we'll be better able to make decisions about where to display it.

[fcoveram]

Hiding it on the 'all results' view and unblocking this

I like this idea. I am putting down the questions we want to respond to with user data. To continue, I will remove the needs design label and @ramadanomar can continue as he was interested in taking this issue.

[obulat]

@fcoveram, what if instead of hiding this on all results views, we show all of the external sources there? And to make it clear which media type the source has, we add a content type icon to the button (or another indication)? I tried adding it to the new popover:

[fcoveram]

All my points shared in previous messages on why not showing this component are rooted in the usefulness of this element and the idea of keeping a simple design, not about its visual style.

I thought we concluded this conversation with this message from Zack:

I am fine with hiding it on the 'all results' view and unblocking this, however. Once we make progress on some analytics work and find out how often this feature is actually used, we'll be better able to make decisions about where to display it.