Content: Improve the About > Logos page

[ryelle]

Copied from #meta-7710 Created by @jdevalk

Our logo page needs some work: https://wordpress.org/about/logos/

I think we should:

• Remove the “Graphics & Logo” h1 and make the “Official WordPress logo” (currently the h2) the h1
• Replace “Downloads” with “Logo files”

• Add SVG versions of all the files (WordPress logo svg is actually sought a lot)

  Screenshot of proposed design changes

Oh and let's change the title to "Official WordPress logo" too.

[ryelle]

I like this suggestion, even just removing the double heading is nice. There's also an issue to update the "fauxgo" image https://github.com/WordPress/wporg-main-2022/issues/256, it would be nice to do both at once.

[jdevalk]

Agreed! Giving it a good og:image at the same time would be a nice thing too.

[fcoveram]

Here is an idea that taps into the suggestions made by @jdevalk plus other style tweaks that have been implemented.

I also included two content suggestions I hope are not hard to develop.

Open or download the SVG and PNG: Each logo type has a link to open or download both the SVG and PNG file. This comes from uses cases where, especially in design, the download adds an extra step when creating a visual. Following this logic, I also moved the "All logos" set to the end where both formats come in ZIP files.

New fauxgo diagram: Instead of having one visual with indications for the correct and incorrect version of the logo, I split it into four images and descriptive texts about what is right and wrong about them.

What do you think of this idea? Here is the mockup in dev mode, and here the logo assets in case they need to be exported again.

[jdevalk]

Looks good!

[ryelle]

@fcoveram Does this need a copy review?

Open or download the SVG and PNG:

Do these need to be two separate things? "Open" would link to the .svg/.png file, and "download" would likely also link to the .svg/.png file, unless you want to zip each SVG/PNG individually as well? I would have just the one link and have it link to the file directly (.png or .svg).

These links should also be more descriptive, for example "Download horizontal standard SVG" or even "Download horizontal-logo.svg" (or whatever we end up naming the file).

Does this mean we no longer need the PDF/AI file types? I know the SVG can fill the vector need, but just checking.

New fauxgo diagram: Instead of having one visual with indications for the correct and incorrect version of the logo, I split it into four images and descriptive texts about what is right and wrong about them.

I like the images, but the text is the same in both descriptions, so it's not clear if the "Taller x-height…" is correct or incorrect.

[fcoveram]

Does this need a copy review?

Yes. Thanks for asking. Pinging @thetinyl asking for help revisiting the content of this mockup.

Do these need to be two separate things? "Open" would link to the .svg/.png file, and "download" would likely also link to the .svg/.png file, unless you want to zip each SVG/PNG individually as well?

I was thinking of the use case when clicking on "Download" opens the OS modal, like this one from Mac OS, whereas "Open" takes you to see the file on a different page, like this Openverse logo in SVG. But a single link that lands on the file directly sounds like a great idea. I will create another mockup to reflect this change.

These links should also be more descriptive, for example "Download horizontal standard SVG" or even "Download horizontal-logo.svg" (or whatever we end up naming the file).

Why this? Isn't the context the card gives enough? I don't remember other common cases where file info is in the link label.

Does this mean we no longer need the PDF/AI file types? I know the SVG can fill the vector need, but just checking.

Exactly.

I like the images, but the text is the same in both descriptions, so it's not clear if the "Taller x-height…" is correct or incorrect.

I put the wrong content, now it's correct.

---

Mockup for SVG and PNG as single links

Here is an idea for this.

[thetinyl]

I'm not sure these links need to be framed as a call to action here with "Open __". It feels sufficient enough just to have the 'SVG' and 'Transparent PNG' be linked themselves.

These links should also be more descriptive, for example "Download horizontal standard SVG" or even "Download horizontal-logo.svg" (or whatever we end up naming the file).

Why this? Isn't the context the card gives enough? I don't remember other common cases where file info is in the link label.

Given there's no other copy in each card besides the name of the logo and then links to types of files, I want to agree with @fcoveram about leaning on the context vs. using the full file name in the link. This is a gap in my accessibility knowledge though—how would a screenreader work through this content?

@fcoveram I left one comment with a small copy edit in the Figma mockup that wasn't caught when this page was originally updated. I can make that edit directly in the Editor, but figured it could get fixed when all these other changes happen. 👍 The other copy seems fine for now.

[ryelle]

Given there's no other copy in each card besides the name of the logo and then links to types of files, I want to agree with @fcoveram about leaning on the context vs. using the full file name in the link. This is a gap in my accessibility knowledge though—how would a screenreader work through this content?

Screen reader users can navigate a page by links, so links should be understandable out of context. This is a good explanation of how to write good link text. This article has some videos showing this process, and the poor experience of these links out of context.

[thetinyl]

Screen reader users can navigate a page by links

Ah, this helps to know. Thanks for clarifying, @ryelle.

Given that we have a clear heading to contextualize the content ("Logo files"), what about using the descriptive links (as Kelly suggested above) without any kind of added heading so we're not being redundant?

Pardon my horrifying mockup destruction:

[fcoveram]

Thanks for the articles linked @ryelle. It's more clear now. I like @thetinyl's idea.

[fcoveram]

Is there something pending from the design side? Asking in case there are assets blocking the progress. Otherwise, all good. I don't want to sound like pushing the implementation.