Show 3d model results in the search result page

[fcoveram]

Problem

For the 3D model support milestone, we need to display 3D model results on the search results page in two ways, as part of the All content layout and as a unique view.

Considerations

Try reusing the All content layout for the standalone view showing only 3D model results.

Solution

Here are two screen recordings with the whole flow from the search results page to the single result view, and the mockups related to the search results.

Desktop

Screen recording

https://user-images.githubusercontent.com/895819/169101493-7185bbeb-9f77-48d5-81e5-61d8ea895bde.mp4

Mockups

All content	All content + Switcher open

Search results. 3D models

Mobile

Screen recording

https://user-images.githubusercontent.com/895819/169101916-9ffe5a59-152d-45a8-92aa-ceefd640835c.mp4

Mockups

All content	Content switcher	Search results. 3D models

Mockup

Figma: 3D model support

Description

On desktop, the 3D model component is the same box as the image one for both search results and 3d model results. Following the currently implemented behavior, the box also resizes as the filter sidebar appears.

On mobile, the element is the same image box as in all content results; but on 3d results-only, the element is wider like in the single result view and it has the license visible below. I am thinking of using the same single-column layout for image results after we discussed keeping the row layout on desktop. This should ease the arrangement of elements.

I am hesitant about showing the content links to see Images, Audio, or 3D models on both desktop and mobile. They fit perfectly on desktop, despite not working well with future content integrations, but also because the list pushes the content downwards significantly on mobile. What are your thoughts on this?

Looking forward to see your comments

[zackkrida]

Looks good! I have some thoughts:

Right now we're showing 5 results across on desktop, so the three switcher buttons would look like this:

I think on desktop it will be okay to show multiple rows of the content switcher buttons when we have more items. It doesn't take up too much vertical space and seems very useful to the user. I do agree on mobile that it's a harder decision. Maybe a single row that is scrollable? Or we simply rely on the header content switcher?

Flickr has a lot of images that are screenshots of 3D renders: https://wordpress.org/openverse/image/13ef4cec-5775-47ee-84aa-047c96e4136a How would we differentiate those from actual 3D models in the search results? It introduces a new concept but I feel like we would need to display icons or another way to differentiate different content types. Related to this, I've noticed that on mobile it's really unclear that audio files are audio files:

Without the waveform, play button, or perhaps some kind of audio icon, it really isn't clear what type of media those yellow boxes are.

Regarding the single result, this is basically the same as images, with a fixed aspect ratio for the model viewer? That seems good to me. Some places this page could use some more details are:

• Here's the list of fields we have so far. It would be a good idea to start thinking about some of these. Some models, for example on Thingiverse, have screenshots of printed examples of the models. Would we want to include those in our UI, or do we think they should go to Thingiverse to view those?
• It's very likely we will start the page by showing a static image for the 3D model, and when the user clicks on a 'play' button we will load the actual 3D model viewer. It's possible design could start on this play button and a loading state for the model.
• The attribution should be updated to say 'This model' instead of 'this image'.
• The issue of how to distinguish between screenshots of 3D models on Flickr vs. actual 3D models is still an issue here.

[fcoveram]

It doesn't take up too much vertical space and seems very useful to the user.

I would not assume this as we have not collected user data, and previous tests did not show the need for this type of result. I would rely on the content switcher on mobile as the page starts showing navigational elements in a header. Besides, the experience starts from the homepage, where the switcher stands out more.

The content link might blend with the box gallery as both have row orientation. I can try other ideas for the content link component and share them here.

Flickr has a lot of images that are screenshots of 3D renders: https://wordpress.org/openverse/image/13ef4cec-5775-47ee-84aa-047c96e4136a

The link opens a page to download an image. To me this is not a 3D render but an image, and I think we should not tackle scenarios like this. Another example is a photo of a painting; is it a painting or a photo? That answer goes beyond our current tools for identifying content.

I've noticed that on mobile it's really unclear that audio files are audio files. Without the waveform, play button, or perhaps some kind of audio icon, it really isn't clear what type of media those yellow boxes are.

That is a good point. For now, we are relying solely on the category label (music, podcast, audio effect, etc), but on mobile, the audio is not interactable. We can explore the idea of showing the audio control and the global player on mobile. But again, we will be providing different experiences per breakpoint as you can only play and pause on desktop and not seek time.

I would like other folks' thoughts on this point.

It's very likely we will start the page by showing a static image for the 3D model, and when the user clicks on a 'play' button we will load the actual 3D model viewer. It's possible design could start on this play button and a loading state for the model.

I would see more about how others allow interaction on mobile. At first sight, it sounds very UX unfriendly interacting inside the 3D model view.

[zackkrida]

Regarding Flickr, @panchovm Let me explain a bit more. How does the user, looking at Openverse's 'all content' search results, tell the difference between an item that is a picture of a 3D model on Flickr versus an actual model, from a source like Sketchfab?

The issue I see is that images and 3D models are presented exactly the same way in the results, so the user is unable to distinguish between them in the 'all results' view.

[zackkrida]

previous tests did not show the need for this type of result.

What was the motivation for including the content type buttons above the search results in the designs then @panchovm ? I think they are really useful personally, I use them a lot when I am clicking through the sites. Sometimes I want to start on 'all results', then narrow my search, and those buttons are a convenient one-click way to do it instead of two clicks with the content switcher dropdown. I completely agree with your point that we need to solve how much space these buttons will occupy when we have even more content types.

[fcoveram]

I did not explain myself correctly. I agree that in "All content" is necessary to distinguish a 3d model versus an image. Opening the source site lands to a different content and that needs to be clear in advance. In this case specifically, the image is a 3D model screenshot but the content and the file downloaded from Flickr is an image. That can lead to frustration.

The motivation for including the content type buttons above the search results was to make more explicit the content displayed on All content results. Some people would like to browse across content.

But despite personal preferences, whether I use it or not, I have shared before my thoughts and doubts about having a "All content gallery" and its value to users. I need to argue design decisions based on user needs and hypotheses that we can test and iterate. Nonetheless, I understand that decision-making does not pass only through my bias, and I am happily embracing that open source context.

[zackkrida]

At first sight, it sounds very UX unfriendly interacting inside the 3D model view.

What I was describing was the same approach that is currently live for Sketchfab models:

https://wordpress.org/openverse/image/00a6a7a4-6605-4cba-bacf-a08b0da546b9

Specifically, how there is a static image with a 'play' button over it:

Which, when clicked, loads the interactive model:

[fcoveram]

Yes. I was thinking of the same viewer. Here is my interaction with it

https://user-images.githubusercontent.com/895819/169159433-a7cbf6b2-1dc8-4d1e-b071-c666c1108e74.mp4

The touch and drag to rotate works pretty well, but I wonder if we can hide the other elements as the single result view has links to see the author and open the 3d model on the source site.

[zackkrida]

The motivation for including the content type buttons above the search results was to make more explicit the content displayed on All content results. Some people would like to browse across content.

This makes sense!

But despite personal preferences, whether I use it or not, I have shared before my thoughts and doubts about having a "All content gallery" and its value to users. I need to argue design decisions based on user needs and hypotheses that we can test and iterate.

I hope we can develop a plan to get you more user data soon. It would be great to identify which parts of the UI we're the 'least confident' in right now so we could make plans to test for them.

The 'all content' view is interesting, because while I can see how it might not be useful to all users I really admire what you've designed and how it showcases the way Openverse uniquely contains these multiple media types. You're so right that it would be great to get data on this. It also makes me curious if there are ways to showcase the 'multimedia' nature of Openverse with UI that you personally think is valuable as well.

[dhruvkb]

In the search results page, the results for image and 3d model are very similar looking. Is it possible that someone accidentally clicks one thinking it's the other? Should the thumbnails include the model icon in the hover overlay to denote what they are?

[AetherUnbound]

@dhruvkb I think that's exactly what @zackkrida is suggesting! I think all of this looks great, but yes I agree - having the 3D model "icon" in the bottom left (or some indicator that it's a 3D model) would be useful in the all content view.

[obulat]

I love the designs! And have the same question regarding the 3D model indicator as everyone else :)

how it showcases the way Openverse uniquely contains these multiple media types

I wonder how the content type links would look like when we add another content type? Currently, the 3 types fit, but if we add one more they might not fit, and the "showcasing" of multiple media types might become difficult if you can't see all of them.

[fcoveram]

Thanks for the comments. I would definitely work on distinguishing between an image and a 3d model.

Regarding content type links, I think we should tackle that problem once we have it. It would be great to discuss the frequency of adding content types to think of a long-term solution. New content types impact several parts of the interface and it requires dedicated time to assess the consequences.

For now, I would leave it as it is. It fits above the box grid.

[fcoveram]

Here is an idea I like for distinguishing between images and 3d models.

https://user-images.githubusercontent.com/895819/170519058-7eaeaacd-005c-4ee3-9a6a-a566e63f1800.mp4

In :hover state, the thumb image simulates a rotation effect by loading several frames. This interaction is from Sketchfab and, if we all agree, we might split this implementation in two stages: first, adding the 3d model icon; second, developing the rotation effect.

The effect applies only to the 1:1 images, that is "All results" and "3D model" results on desktop (xl and 2xl breakpoints). On mobile, we do not need the effect since there is no :hover state and the thumb image is 16:9-ish.

Here is the mockup to see how the resting state looks like.

[fcoveram]

I shared this idea, and Christy gave me great feedback. Here are the changes I made.

• I added a full-width dark bar indicating the loading area to prevent contrast issues when having 3D models with yellow background.
• The rotation does not depend on the mouse cursor. This risked missing the interaction as the user needed to move the cursor to see the effect.
• I am considering replacing the 3D model icon with a rotate icon. This change is a state approach instead of a content-type approach. In the future, we might have 3d model content embedded in sites where the rotation effect is disabled.

[stacimc]

I had not realized the rotation was linked to the cursor! I think that idea is very cool, but ultimately I agree that it risks the interaction being missed. I like that it alternates between rotating clockwise/counter-clockwise.

I am considering replacing the 3D model icon with a rotate icon. This change is a state approach instead of a content-type approach.

Can you clarify what you mean here? Just that the rotate icon ties more clearly to the hover action, rather than describing the content type?

In the future, we might have 3d model content embedded in sites where the rotation effect is disabled.

In this case would it make more sense to keep the 3D model icon?

[sarayourfriend]

I love the design you've landed on here @panchovm, the 3d model icon over the thumbnail seems like a good way of visually indicating the difference. For screen readers we'll just need to make sure that the aria-label for the result indicates that it is a 3d model. I think we already do this between images and audio anyway, so it's not new.

Note: we also cannot link the rotation to the cursor movement or else it will be inaccessible to keyboard users. Having it activate on hover and keyboard focus makes it accessible to all sighted users regardless of what device(s) they use for navigating the web. I'm not sure exactly how to make it touch accessible, however. Maybe turning the 3d model icon into the rotation icon as you suggested would be the clearest, even requiring the user to interact with the rotate button explicitly could be best as it would:

• Prevent unnecessary/accidental loading of potentially heavy files, especially relevant for users on limited networks. If our frontend starts downloading a several megabyte 3d model just because you hovered over a result, it could be frustrating.
• Allow it to be touch accessible, as touch users can interact with the button the same way.

We already rely on similar interactions for playing audio from the results page. The main complication I can think of for this issue, however, is that the button will have to be a certain size to make it accessible. It might need to be large enough that it could obscure the result preview.

I am hesitant about showing the content links to see Images, Audio, or 3D models on both desktop and mobile. They fit perfectly on desktop, despite not working well with future content integrations, but also because the list pushes the content downwards significantly on mobile. What are your thoughts on this?

The horizontal scrolling header iteration you shared a few months ago seems like it would be a good solution to this for mobile. Hiding it altogether also seems appropriate considering the content switcher is clear in the mobile header.

[fcoveram]

@stacimc, I meant what you said; the rotate icon says about the hover action rather than describing the content type. And I assumed that embedding 3d model content in a site would have more context, so the 3d model icon would not be necessary. Nonetheless, it is a big assumption, and I have no clue to support my argument.

Thanks for the a11y clarification @sarayourfriend on the cursor dependency feature.

Initially, I thought the rotation effect would not be necessary on small breakpoints since there is no hover state in general. However, thinking more deeply, all search results need a preview instance from all content components to ease the browsing experience.

My main concern with adding an actionable element inside the thumbnail image is that it might lead to unintentional tappings. I will try putting it outside in the row where the CC icons are, but to meet a11y requirements, the button needs to be 42px or bigger and that will use a significant portion of the compontent. See the image below to get a clear idea of what I am referring to.

[zackkrida]

I wonder if the 'clickable / tappable' button could have a 'dead zone' around it that doesn't trigger the 'clickable / tappable area', something like this, where touching the red area would have no effect.

[sarayourfriend]

I wonder if the 'clickable / tappable' button could have a 'dead zone' around it that doesn't trigger the 'clickable / tappable area', something like this, where touching the red area would have no effect.

You could implement this with a container around the button that swallows pointer events... but I think this is not an accessible pattern for people who use a cursor. If something appears to be interactive but there is an unexplained and non-indicated dead zone then it will be confusing. Plus, the interactive area of the button itself needs to be the size that Francisco shared at minimum. The dead area would just expand the problems I think.

[zackkrida]

A better idea, potentially: since the licenses, which overlap the image on desktop, appear below the image on mobile, maybe the 'rotate' icon could as well? Clicking the icon could be a toggle that makes the model infinitely rotate until the button is clicked again.

Edit: Oops, Francisco mentioned this above the image in his last message.

[sarayourfriend]

A better idea, potentially: since the licenses, which overlap the image on desktop, appear below the image on mobile, maybe the 'rotate' icon could as well? Clicking the icon could be a toggle that makes the model infinitely rotate until the button is clicked again.

I think Francisco mentioned this possibility above but that it has the potential problem of the button needing to be bigger than the license icons are currently?

[fcoveram]

I have been testing the idea of having a 48px target area that inside has a 32px visible element. In the first image below the target area is the one with blue borders, while the second image is an example of the element placed inside the thumb image.

One question that comes up. Does the focus ring need to outline the target or the visible area?

[sarayourfriend]

Does the focus ring need to outline the target or the visible area?

My guess is that it does not matter (whichever is more visually appealing and clear, so probably the visible area). Just a guess though, I am not sure how to verify this.

[zackkrida]

Touch targets include the area that responds to user input. Touch targets extend beyond the visual bounds of an element: An element like an icon may appear to be 24x24dp but the padding surrounding it comprises the full 48x48dp touch target.

Consider making touch targets at least 48x48dp, separated by 8dp of space or more, to ensure balanced information density and usability. A touch target of 48x48dp results in a physical size of about 9mm, regardless of screen size. The recommended target size for touchscreen objects is 7-10mm.

https://support.google.com/accessibility/android/answer/7101858?hl=en

This doesn't answer all of our questions but provides some useful information. I think it's okay for the focus outline to go on the visible element, and not the target area.

This does seem to suggest that there should be an 8dp 'dead zone' between the two touch targets, though. But maybe not, since it doesn't say anything specifically about nested touch targets.

[fcoveram]

The Target Size documentation describes the success criterion tied to the target element, whereas the Focus Visible section refers to the visible component.

Target Size

The intent of this success criteria is to ensure that target sizes are large enough for users to easily activate them, even if the user is accessing content on a small handheld touch screen device, has limited dexterity, or has trouble activating small targets for other reasons.

The section also links the Material Design documentation as a source for more information.

Focus Visible

The purpose of this success criterion is to help a person know which element has the keyboard focus.

It must be possible for a person to know which element among multiple elements has the keyboard focus. If there is only one keyboard actionable control on the screen, the success criterion would be met because the visual design presents only one keyboard actionable item.

Therefore, it seems we can go with the idea of having a 48px target size with a 32px visible element.

[fcoveram]

I updated the 3D model component on the smallest breakpoint views, and here are the outcomes.

I also started a discussion (#1541) about the purpose of the All content results. I would love your thoughts since it sparkles the envision of component interactions.

Now I will update the final mockups to start the dev stage.

[sarayourfriend]

Closing as 3d models are indefinitely on hold and no work should be done on them until we re-plan this project.

The information and plans from this thread will absolutely be taken into account if/when we revisit 3d models.