New About page

[fcoveram]

Problem

The current site displays content related to various aspects of the project on multiple pages in the homepage header. Due to this, the navigation component appears visually cluttered and lacks space for more items. Additionally, there are a few tickets in the repository requesting additional content to explain how both existing and upcoming features work.

It is necessary to revisit how we present Openverse to both current and prospective users and devise a solution that helps visitors easily locate all relevant information.

Related issues

The original idea comes from this comment in #3564, but I went back to all tickets tagged with design: needed requesting for adding content, and the following ones relate to this topic in one way or another.

• 4303, as part of #431 project

• 459

• 611

• 2595

Proposal

Given that all the information relates to Openverse's essence, the About page meets the goal perfectly. But before showing the proposals, I put down this brief to align our expectations over this idea:

Main goal:

• Introduce Openverse as a tool that surfaces openly-licensed content from the web.

Secondary goals

• Move most content from current header pages into a single one under a storytelling that goes from broad concept into the specs.
• Create a more appealing page by pushing the brand further

Users

• New visitors who know nothing about Openverse
• Current and/or expert users looking for how Openverse works

Offset box grid (i1.2)

https://github.com/WordPress/openverse/assets/895819/380fdea1-73a2-40ff-ae19-85616165065e

https://github.com/WordPress/openverse/assets/895819/91de64b1-21f0-43d9-a2af-92368a09bfc4

This version introduces Openverse by playing with the spacings of the "All content" results grid to reach a more appealing version. The result is real media content from the "jazz" search and each element links to their respective details page. The dark section below describes more the concept showed above and includes some source logos to reinforce the search-engine core value of the project.

Funky layout (i1.5)

https://github.com/WordPress/openverse/assets/895819/65ae43ec-de44-4a7a-b980-69e5362ba809

https://github.com/WordPress/openverse/assets/895819/d3a2cff2-c6bb-454a-966f-7ed4766700a6

This version distributes image and audio track items in a device's full-height area with a jazzy layout and a big heading at the center. The dark section below is the same as in the previous version.

---

Next steps

If you notice, there are a few style tweaks on the homepage as well to connect the visual language used. In that vein, this proposal also relates to a segment of #4157's designs. Meanwhile, I will ping comms folk asking for help writing the page. I envision big collaboration between folks as the tickets related mentioned above involve expert knowledge and technical terms that will require careful revision.

But most importantly, I would like you thoughts about the versions and which one feels better. Check the links below to interact with the prototypes, although some elements are not fully accurate with the interaction, you will get the main idea.

Mockups

• Figma: New About page
• All prototypes. Click on the top left sidebar action to see them all.

[openverse-bot]

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.](https://github.com/bytecodealliance/subscribe-to-label-action)

[jasmussen]

Lovely work. Lots to like.

I'm personally most drawn to this one:

Random is hard to get right. As a fashionista once said, and I'm probably paraphrasing: "it takes 45m to look like you just got out of bed". Random and disorderly like this is the same, true random rarely works. There needs to be some pattern in the chaos for you to recognize and latch on to. To be fair, there is such a pattern here, it's carefully scattered between light and dark around the center, and generally legible. If this is the one your heart beats for, can definitely work. But there's something very curated about the other gridded one, that looks great.

[sarayourfriend]

I also prefer the grid design, actually a lot more. Not just aesthetically, but also technically. It's easier to imagine how it would actually scale in and out with different breakpoints. Implementation in general would be more straightforward than the other design, and considering this in balance with other work Openverse is doing, that strikes me as an important consideration. I don't think we'd need any new positioning or organisation tools to implement it, whereas the jazzy layout would need entirely new approaches, ones that are sure to be complex (in particular full of edge cases).

For example, I'm a bit concerned about how the audio controls in particular would behave as the page scales within a breakpoint. We'd need to be at least be careful that the "pause" button was never hidden for any of the playable audio. Keyboard navigation for sighted users also seems hectic when I try to imagine it, unless we would skip those interactive elements for keyboard navigation. They are essentially presentational, but the demo highlights the interaction, and indeed it would be strangely frozen not to make them interactive if they were there. Speaking more generally (rather than about the theoretical technical implementation), the cut-off titles of the audio also give me a sense of disconnected context, like I was meant to be able to scroll up further, but there wasn't any further to scroll, or worse, like I'm drowning, caught in an up-close and claustrophobic view of the centre of some unknown whole. The edges of the images skew and bend due to some illusion. It's actually a fascinating experience, but maybe too dizzying or intense for the about page of what is just a search engine :sweat_smile:. Anyway, the gridded option is calmer and less challenging in this sense, at least for me.

I'm unclear whether you're also looking for feedback on some of the general language you've used for the leader text and the goals, and I understand there'll be collaboration for writing the full text of the page. However, given the prominence of this on the design, I want to share that I don't think that the verb "surfacing" is a clear or easy to follow one. For one, it comes across business/corporate-y (maybe ironic given jazz as the design inspiration). "Search the web's open content" is proximate to other tools users will be familiar with (Google Search, "search engine", etc), matches ways in which we already describe Openverse, and also acts as a call to action. "Surfacing" is about what Openverse does, "Search" is about what the user can do with Openverse (at least, that's how I interpret the difference it). Surfacing is also, incidentally, passive voice, which comes across hollow when it's the text leading the page.

[dhruvkb]

The box grid is the better option for practical concerns (like accessibility, responsiveness and technical implementation), although I love the look of the funky one more. I agree with the points raised by @sarayourfriend in the first two paragraphs.

As for language, I want to dissent. As the "About" page for Openverse, it should be about what Openverse does and so "surfacing" feels right to me. But I won't harp on it because a skilled copywriter can do a much better job of finding the right text to show here.

I like the use of B/W images on this page very much, so much so that I would recommend using B/W images exclusively and no color images. They look striking and go very well with our brand colors.

We could include a couple of audio objects in the grid layout as well, similar to the funky one, provided we assuage @sarayourfriend's concerns by ensuring that important parts of the audio component do not overflow off-screen.

[zackkrida]

I agree with a lot of the feedback so far! I would love to see if adding the audio players and the idea of having the elements extend out of the viewport could be added to the grid based design.

I really like the second block as well, which showcases some logos of the different sources in Openverse.

I do think the existing About page needs a major content overhaul. I would also like to see more "content block" styles to use further down the page. Even if they were initially designed with placeholder copy, I am confident we could use them with new copy once we have it with minimal modification.

I love where this is heading!

[fcoveram]

Thanks for all the feedback shared.

The jazzy version was intentionally shared to spark ideas about how folks felt about it and what opportunities we had implementing it while making it accessible. I also considered treating it just as a decorative image, without interaction. But if the grid version feels more coherent with the brand, then let's keep pushing that one.

I will iterate on a new version with the following in mind:

• Add audio content to the grid
• Try black and white images to keep the yellow + black duotone of the brand
• I created this document and will ping Lauren asking for help. Comments on the copy will be included.
• Consider other content blocks to style the biggest body content area.

Given that the next iteration will be based on the box grid, I wonder what options we have for the breakpoints behavior. I will propose something but it's open to new ideas for playing with the grid's off spaces and reach an appealing hero section for every viewport.

Regarding the page content, I think we've used the word "surfacing" to make web content visible through the search engine. And as @dhruvkb pointed out, it's in the context of describing Openverse as a product. I might be wrong about its previous uses, but in any case, especially if the word unfits, it would be good to have a set of words and sentences we can refer to here and in all Openverse comms to have a consistent voice tone.

Thanks again for the all your thoughts.

[AetherUnbound]

+1 to the grid layout, though the jazzy layout is very fun! The marque'd CC logos and rotating provider logos do give me an idea though: I'm not sure if this was intentional, but each of those could be a clickable element which then directs to a search using that as a filter! For instance, the CC license rotating items could link to a search filtered by that license, and the "SMK logo" in the black and white section below would link to an image search filtered down to SMK results. Just a thought 😄

[sarayourfriend]

@AetherUnbound We don't support query-less searches on the frontend at the moment, and don't have UI for it either. For the providers we can use the collection pages, but for licenses we don't have that and would need to create it. Just giving context for the scope of that suggestion, basically would be an entire new page rather than just a link to an existing page.

Regarding "surfacing", I don't see a single instance of it in the Openverse codebase to describe Openverse (it is used in one IP, but that's not project copy), so I do think it is new, and it is a significantly different way/mode of describing Openverse. I look forward to discussing it, and agree that more comprehensive guidance on the specific words used to describe Openverse in our copy would make things like this easier moving forward.

[AetherUnbound]

@AetherUnbound We don't support query-less searches on the frontend at the moment, and don't have UI for it either. For the providers we can use the collection pages, but for licenses we don't have that and would need to create it. Just giving context for the scope of that suggestion, basically would be an entire new page rather than just a link to an existing page.

You're totally right, that slipped my mind. The collection pages were what I was thinking of, though that does not extend to licenses in the way I described.

[obulat]

@AetherUnbound We don't support query-less searches on the frontend at the moment, and don't have UI for it either. For the providers we can use the collection pages, but for licenses we don't have that and would need to create it. Just giving context for the scope of that suggestion, basically would be an entire new page rather than just a link to an existing page.

To narrow the scope of this, we could use a random word of the top searches (based on Plausible data?), with that license selected. For instance, if you click on "CC0", you would go to https://openverse.org/search/?q=sky&license=cc0.

[fcoveram]

I don't want to neutralize the creative energy you are putting on this, but since we don't have ways to show results filtered by a CC license without a search term, it sounds easier to treat it as a decorative element.

[AetherUnbound]

I don't want to neutralize the creative energy you are putting on this, but since we don't have ways to show results filtered by a CC license without a search term, it sounds easier to treat it as a decorative element.

I agree

[thetinyl]

Thanks for the ping @fcoveram. I'd love to help out with revisiting/refining/refreshing the Openverse About page.

For what it's worth, I'd also throw my vote behind the grid version.

I would also like to see more "content block" styles to use further down the page.

I don't know if this aligns with what you meant, @zackkrida, but I wonder what's limiting the design from including other visuals interspersed with the content. Whether it's images or audio, it feels like a golden opportunity to tell AND show what Openverse has available (beyond a line of logos) and what it can do.

Regarding "surfacing", I don't see a single instance of it in the Openverse codebase to describe Openverse (it is used in one IP, but that's not project copy), so I do think it is new, and it is a significantly different way/mode of describing Openverse. I look forward to discussing it, and agree that more comprehensive guidance on the specific words used to describe Openverse in our copy would make things like this easier moving forward.

I think @sarayourfriend brings up a good point about what language to use and what might sound like Openverse. Does Openverse have a particular way of speaking? Is it meant to be different from WordPress's brand voice and tone? If it's of interest, maybe it's worth exploring that identity with this About page refresh along with the design.

[fcoveram]

… I wonder what's limiting the design from including other visuals interspersed with the content. Whether it's images or audio, it feels like a golden opportunity to tell AND show what Openverse has available (beyond a line of logos) and what it can do.

I don't envision significant limitations beyond adding component interactions and developing new elements that would require content integrations. In any case, we can iterate @thetinyl in the document and drop ideas as text or images to discuss them before any implementation that could push the project scope further. I agree with the opportunity to enhance the storytelling and convey something meaningful and appealing.

Does Openverse have a particular way of speaking? Is it meant to be different from WordPress's brand voice and tone? If it's of interest, maybe it's worth exploring that identity with this About page refresh along with the design.

I think we haven't talked about this before. And I personally don't see Openverse with a different brand voice and tone. To keep Openverse under the WordPress project umbrella, I would apply the guidelines already made and see how we feel about it. So far, all comms pieces feel consistent and robust with WordPress.

[thetinyl]

And I personally don't see Openverse with a different brand voice and tone. To keep Openverse under the WordPress project umbrella, I would apply the guidelines already made and see how we feel about it. So far, all comms pieces feel consistent and robust with WordPress.

This is what I've noticed until now, and didn't want to assume.

[fcoveram]

I chatted with @thetinyl internally to coordinate our times, and we can start crafting the page content the week of June 24th.

However, the most significant dev effort seems to be in the hero section where media components are. For the rest of the page, the sections intend to work as blocks arrangement that don't reshape the TOC area. Therefore, I can split the design file into two sections to begin implementing this first part separately without depending on having the whole content.

How does that sound?

[sarayourfriend]

I'd like clarification on how this would be prioritised, and what the expectations for implementing this are. @zackkrida can you help out with that? As it stands, I don't know where this fits in with the rest of our work, of which there is, to say it plainly, quite a lot.

I understand the motivation behind the page, but how is that balanced against the rest of the work we're doing? What do we hope to get out of this compared to the other things we're planning to work on? Etc. Would be great to have input from @zackkrida to clarify that, in collaboration with you @fcoveram, and in light of all the other things we've got going on.

[fcoveram]

In case we need to speed up the implementation, or if this design expands the times and scope initially assessed significantly, we could go with adding content needed for #431 and #2595 in the existing pages. Or include a new page is that's an unavoidable case.

[zackkrida]

@sarayourfriend and @fcoveram my feeling is that this design is great to have prepared, but that we should defer implementing these changes (and more) until next year.

There is value in having design explorations ready now. The page will need new copy written by our team. I believe that copy is currently blocked by:

• A refinement of the goals, audience, and principles governing Openverse
• Having clear "key performance indicators" (KPIs) for the project

@fcoveram I think you could continue to explore with another 1-2 "generic" content sections to expand the page, and then we could mark this as blocked until we have concrete plans to implement it.

[fcoveram]

I don't fully understand the reason for blocking this work.

From @sarayourfriend's comment shared here, it seems that the current workload does not allow adding this, whereas the two reasons for blocking this seem to treat the change as a project. Do I understand this correctly?

As per the two reasons

A refinement of the goals, audience, and principles governing Openverse

The secondary goals and the users pointed out in the initial comment set the baseline for the copy work that @thetinyl could help us with. What changes here is the voice and tone of text content, not the goals, audience, and principles governing Openverse.

Having clear "key performance indicators" (KPIs) for the project

The word "project" suggests this design needs to become a project, and therefore, follow the project flow. However, the documentation does not mentioned having KPIs as an evaluation criterion. Why does this change need to have a KPI?

At this point, the generic exploration are not really helpful given that the page layout does not change significantly and the text styles are already defined.

[zackkrida]

@fcoveram apologies, by "the project" I meant Openverse itself, not this specific "about page" project.

The main reason to block this is the team's work load and the fact that the page needs new copy.

I thought creating some generic sections could be a nice way to continue design explorations despite these blockers.

I am not exactly sure what you mean by "the page layout does not change significantly". Could you clarify? It seems okay for the about page to have a strong presentation that uses different text styles and layouts from the main search experience.

[fcoveram]

The main reason to block this is the team's work load and the fact that the page needs new copy.

That makes sense. I still believe that @thetinyl could write a draft document that we only need to revisit in terms of technical accuracy rather than voice and tone. Ticket #2595 could require more our attention as it involves new content.

I am not exactly sure what you mean by "the page layout does not change significantly". Could you clarify? It seems okay for the about page to have a strong presentation that uses different text styles and layouts from the main search experience.

Sorry for not being clear. I meant that the main content area will remain simple and using existing styles. Here is a quick mockups with notes of how the rest of sections intend to be.

Because of the same workload point is that I worked on a proposal that only introduces a new section at the beginning of the page while keeping the remaining areas simple without requiring extra code work.

---

I don't want to sound rigid about my position, but I would like to address this as the number of pages in header and the content clean up are the core goals of this proposal.

[thetinyl]

I'm happy to support with copy in whatever capacity makes sense for the team/process. Whether that's sooner or later. (Just wanted to throw that out there.)

[zackkrida]

@fcoveram thanks for clarifying your goals, that helps me understand a lot better where you're coming from. My point of view has been focused on the "Introduce Openverse as a tool that surfaces openly-licensed content from the web." goal and not the "number of pages in header and the content clean up" goals.

To be honest, I was so enamored with the "Hero" designs that I overlooked your goal to consolidate all of the existing pages into the "About" page. I actually don't think that is the best idea. I would rather the "About" page work like a traditional home page does, with more succinct copy explaining different facets of the project, and not have long "walls of text" like our more content-heavy pages.

Perhaps something like the sub pages on Wordpress.org's About page could work: https://wordpress.org/about/ but that would also require some significant work.

If the highest-priority goal is reducing the number of pages in the header, could we instead consider implementing a dropdown menu for many of the pages? Or another approach? I think we might want to separate the goals of creating a beautiful, narrative "About" page and cleaning up the Openverse nav. Another example: We could probably move "search help" from the site header and move it into the "recent searches" dropdown as a text link.

Also keep in mind, users spend the most time on the search view, where the header is moved to the footer of the site. The number of pages is less of a concern there.

what do you think @WordPress/openverse?

[sarayourfriend]

A few thoughts from me:

1. It'd be nice if content heavy pages weren't so tedious to code. Writing them in Markdown and rendering them into our Vue pages, for example, would make things a lot easier, though potentially more difficult for translation (would need to confer with GlotPress folks on that one). The existing content heavy pages are extremely tedious (especially in translation) and I'd be reluctant to add more of them without taking the oppotunity to improve things. That being said, this consolidates them, so it's a bit different :shrug:.
2. I'm indifferent to the content of the About page being short or long. I don't see the difference, especially if it's well organised (the table of contents sidebar makes sense to me, and will be familar to users of other websites with content heavy pages). Again, however, it's a lot of new components and currently manual wiring of things. Fine by me, but we'd need to intentionally push off something else to do this instead.
3. Dropdown in the homepage nav might be fine. Moving links to context sensitive places (like you suggested for the search help, Zack) makes a lot of sense to me. We could move get involved, feedback, terms, and privacy to the footer of the homepage, next to the WP foundation mark. That makes contextual sense to me, considering they have to do with meta information about the project as a whole rather than search. We could move the sources link out of the nav into the hero text of the homepage as well ("An extensive library of free stock photos, images, and audio, available for free use, thanks to the large community of sources hosting openly licensed media", or something like that) Licenses could also be justifiably relocated from the homepage header in a similar manner. If we don't move those two, that leaves About, Licenses, Sources, and API in the homepage header. Excepting the dropdown, these are all relatively easy changes to make to improve the number of links in the homepage header, if we want to target that problem as a specific subset of our overall page content issues.

In general I like these changes to the about page and the hero and stuff, I'm not opposed to any of them, and I think they could be fine to prioritise. Especially if coupled with taking a step back after the Nuxt 3 migration and making some key architectural decisions about how we want to move forward with the structure of the frontend code (especially the layout methodology), it's a good prompt to do so. We certainly have ample opportunity to improve the technical aspects of the frontend, and content management is no small part of that.

That being said: I wonder if headless WP is an option here, especially if it would in any way make translation and authorship easier for large chunks of text? If we use WP as the CMS for these pages, and Nuxt just SSR renders the layout, TOC, etc, it might make some things better, and would demonstrate a way in which WP can be used to augment other types of pages. Kind of ties in nice with WP foundation concerns and contemporary discussions about using WP as a content backend. (Not to complicate things further, lol!... but if we're dreaming a bit... might as well dream?).

[fcoveram]

To @zackkrida's points

I would rather the "About" page work like a traditional home page does, with more succinct copy explaining different facets of the project, and not have long "walls of text" like our more content-heavy pages.

Perhaps something like the sub pages on Wordpress.org's About page could work: https://wordpress.org/about/ but that would also require some significant work.

This is also a good idea. It still needs a page introducing the topics with links to the internal pages, but worth exploring this suggestion.

If the highest-priority goal is reducing the number of pages in the header, could we instead consider implementing a dropdown menu for many of the pages?

Reducing the number of links comes from the potential path of adding more due to the tickets mentioned in the first comment. But the current header handles very well the shift from showing all items to the burger menu.

I think we might want to separate the goals of creating a beautiful, narrative "About" page and cleaning up the Openverse nav.

You’re right about this. The design shared approached the solution progressively. So, for this first release, the page aims to gather everything in a single place, while in future steps, we can push the page further and add more enriched content.

We could probably move "search help" from the site header and move it into the "recent searches" dropdown as a text link.

+100 to this. It’s in line with some comments shared before about showing info in context, but it suits better in a new ticket.

To @sarayourfriend's points

Your ideas about creating and editing these pages less tedious sound great. At this point, I don’t know exactly how to continue with the goal of making the header cleaner, either with @zackkrida's idea of something like the WordPress' About page or the design introduced here.

I also agree with you on not having a preference for long or short content, but the current set of links can definitely be introduced more clearly.

…We could move get involved, feedback, terms, and privacy to the footer of the homepage, next to the WP foundation mark. That makes contextual sense to me, considering they have to do with meta information about the project as a whole rather than search…

This could work, and adapting header and footer components to this doesn’t sound like a big task. It’s very straightforward.

I would not move elements out of the header and footer as having them handy from any page, even during the search flow, adds tremendous value. But your suggestions of linking to specific pages from other parts of the UI make plenty of sense to me.

---

I don’t know exactly how to continue with this, but the two following ideas sound good to me:

1. Update the About to host the other internal pages. Similar to WordPress’ About page structure.
2. Move certain links from header to footer and link to these from other parts of the UI.

I’m drawn to take the first path and implement its simplest version within the available time the team has. This solution can grow progressively and become having one or several pages with rich content.

Managing this content definitely requires deep thought, so I would leave in your hands what’s best for now.

[AetherUnbound]

@fcoveram your synthesis of the two primary ideas for moving forward sounds great to me! I would be fully on-board with those approaches, given the context Zack and Sara have supplied.

[sarayourfriend]

I'm fine with both, and I think we can do the full about page stuff at whatever pace we want, so I'm not sure we need to cut the scope of it. To me the question is: can we break it up into smaller milestones, keeping in mind there are other things that are of extremely high value (search relevancy) that we simply must spend a considerable amount of time looking at as a team. Changes to the header/footer link locations is an easy milestone to achieve, if that will improve things. Merging certain pages into a single About page with the existing layout tools we have (potentially with a minor addition of a ToC) is also an easily achievable milestone. Adding the about page hero could be the final milestone in this series of milestones, perhaps with changes and advancements to how we manage and render static textual content in general. To formalise my suggestion into an ordered list:

1. Move header links around to either include them in the footer, or make them contextual with existing copy on our home and search pages.
2. Merge textual content pages into a single about page, with the addition of a simple table of contents widget.
3. Develop the new about page hero, and potentially consider improvements/advancements to our management and rendering of static textual content.

Breaking it up that way (if that indeed achieves the overall end goal this conversation is getting at) makes it feel less like a potentially huge and gnarly project that would indeed take a significant portion of our attention, to a series of smaller achievements that could be done "on the side" to other things. It gives small, meaningful milestones. Especially because that approach pushes off the most technically complex part of this to the end, when we'll have a clearer view of just how many maintainers and how much of their time will need to be dedicated to the vast and technically complex work of search relevancy (and its various support projects).

[fcoveram]

I think we can do the full about page stuff at whatever pace we want, so I'm not sure we need to cut the scope of it

Agree

…can we break it up into smaller milestones, keeping in mind there are other things that are of extremely high value (search relevancy) that we simply must spend a considerable amount of time looking at as a team.

Absolutely. And I also agree with prioritizing other more relevant work.

---

Milestones

Based on @sarayourfriend's suggestions, here is how the iA could evolve.

Step 1. Links in header and footer

In this first milestone, the links are rearranged across the header and footer.

For the above, here are the mockups of the "internal" variants of header and footer.

No changes are needed for the "content" variants of both components. They can continue working as they are.

Step 2. Pages inside the About page

For the second milestone, the About page has minor style tweaks to index links to the pages noted in the diagram below.

These second-level pages would remain as they are in terms of content and style, and slugs could be set, for example, for the "Sources" page, like openverse.org/about/sources.

Step 3. New about page

Finally, the third and final stage introduces the new About page (based on the Offset box grid idea), where all content displayed in the previous internal pages is part of the "About" one.

---

I have the feeling we can skip step one and go immediately with the second one by applying minor style tweaks. I don't envision the need for a TOC as the page is straightforward and mainly shows links to child pages.

What do you think of this?