Improve the swag banner
Closed this issue · 14 comments
Extracting from #253, and expanding with a little additional context or screenshots.
Swag Banner needs to be clickable as a full module.
That's this one:
I'm not sure the technically best way to accomplish this given it's in the block editor, but one way to do it would be to link the image to the mercantile site, and then change the heading + paragraph + link into one big link, with large text and curated underline inside.
Another approach could be to add a link with a custom CSS class, then use custom CSS with the text-indent hack (text-indent: 9999px) to hide the text visually, then abs-position that link to cover the entire box. Accessibility wise, you'd just want to author the link with descritpively useful text, then omit the actual hyperlink from the "mercantile" spelled out link in the text that follows. Custom CSS should be available in Global Styles now, so you could create a helper class to handle it.
Right now the only clickable element in a URL that reflects as a button/link when hovered. We need to add a clearer button or link.
The most basic solution I can think of is to just underline the link always:
Another option would be rephrasing the text a little bit, and making the link into a button:
Note that we'd still want the whole module clickable.
The products in the Swag Banner are laid out strangely in scale and proportion, also the shadows can be better and consistent.
In smaller desktop viewports, the banner pushes everything down too much. Could be less tall. In mobile it's even more obvious.
The copy say Show your wp20 excitement, but it doesn't explain it's the anniversary. Without making the copy too long, it'd be good to bring slightly better awareness of it. Text and call to action needs to be more specific, even for unawareness. Celebrate the 20th anniverssary with new swag. Show off WordPress 20th with fresh swag. Or alike.
This one is a bit tricky since the media & Text banner needs to scale to mobile. But here's a tweak that rearranges things a bit, rephrases, makes it less tall, and tries to tie it all together. Desktop:
- Facing, simpler illustration
- Stacking so that shadows shouldn't be needed but let me know if I got this wrong
- Simpler, smaller text, more context, 240px tall.
Mobile:
- Should still be feasible to build this using the Media & Text block
- About 370px tall
It's likely going to be a challenge to make this substantially smaller, due to how the responsiveness is built-in to the block. If we need a different approach here, let me know any technical ideas you might have.
Note that we'd still want the whole module clickable.
As I mentioned in this comment, we shouldn't have clickable elements inside clickable elements. If we make the whole element clickable, we'd remove the in-content link. If we want to add a button, the whole element would not be clickable.
My recommendation is to make the image clickable + replace the link with a button.
Custom CSS should be available in Global Styles now, so you could create a helper class to handle it.
Unfortunately we don't have a way of git-version-tracking the CSS there (yet… if this becomes a way that design wants to work on the site, Neso could make it happen as part of the sync+deploy process).
@StevenDufresne: is this worth our effort? At what point will this banner be removed?
Pulling this in here just to keep it in mind— while this banner may be temporary, I assume the pattern of a header banner will be reused, and usually it will need to be clickable. We could continue the pattern of Media & Text, with a clickable image + button in text; or we could create a new group block that functions as a linked wrapper element.
There are two outcomes here, as I read it, looking to confirm this:
- Neso updates the banner now to make the image clickable + replace the link with a button
- Plus the additional changes to wording/image? @jasmussen if that's ready, can you either edit the post directly or drop the new image here?
- A new issue is created on
wporg-mu-pluginsto create a link wrapper block for future header banners (and other uses, this has come up before).
Based on Joen's work and suggestions I am jumping in here with 3 potential solutions for the swag banner.
—
I'd love to point out the potential template and change in approach. Given my interaction with these banners for a while, we might want to make them as a small/narrow banners, instead of them being large as in the past. This would happen with most of the banner if approved/liked, while for very very important events, we could use banners with more height. I believe this should include marketing team, as they know how that may affect the clicks. @eidolonnight what do you think about having banners like in 'narrow-a and b' above for most of our campaigns?
In such scenario, this should be fully clickable. @ryelle is it possible (if approach is accepted) to make a block template that can have such banners fully clickable. I am speaking 60-100px height space (as in above 'narrow' examples). What do you think?
cc: @jasmussen @fcoveram
I personally like the very very thin line a lot, I can see it being an excellent pattern going forward. It's also likely that much easier to make one big clickable area.
I like the second option: thin banner with swag images. Showing products conveys the store page immediately. It also looks great how the sweatshirt aligns with the WordPress word on mobile.
However, I do miss a sentence with an arrow icon or similar reinforcing visiting the page. Something similar to "Checkout the store →." It feels vague without an action-oriented element. I will leave the final words to folks working on marketing.
Small banner is great :) Personally I like the 3rd option (just the sticker image), but that's not a strong opinion.
In such scenario, this should be fully clickable. @ryelle is it possible (if approach is accepted) to make a block template that can have such banners fully clickable. I am speaking 60-100px height space (as in above 'narrow' examples). What do you think?
The size doesn't really matter, we'll need to create a new link-wrapper block whether it's large or small. The small banner does have the advantage that it will probably not have invalid content (buttons) inside though 👍🏻
I've added on the [Status] Needs Design Feedback & [Status] Needs Copy Feedback labels, once the design & copy has been decided on, remove those and a dev can implement it.
I love the idea of two banner versions: one large and one small.
We do need to be wary of desensitizing visitors to this banner area, so having these options would allow us to mix things up.
As for WP20, given that the CTA is specifically for swag, v2 (the thin version with shirts) is my favorite. cc @DanSoschin
The size doesn't really matter, we'll need to create a new link-wrapper block whether it's large or small. The small banner does have the advantage that it will probably not have invalid content (buttons) inside though 👍🏻
We have a link wrapper component, used in the showcase redesign: https://github.com/WordPress/wporg-showcase-2022/blob/main/source/wp-content/themes/wporg-showcase-2022/src/link-group/index.php
Nicholas' note on the copy above seems enough to cover that aspect, and designwise I'm happy with the small stickered version. So that can hopefully unblock us.
The size doesn't really matter, we'll need to create a new link-wrapper block whether it's large or small. The small banner does have the advantage that it will probably not have invalid content (buttons) inside though 👍🏻
For any future desigbns, that included a button, we could make the button be decorative, i.e not button's but just a span or inline-block div that looks like a button. Or would that be bad practice?
We have a link wrapper component, used in the showcase redesign
I think that only links to the current post, this will need to take an arbitrary destination, but yeah, same concept 👍🏻
For any future desigbns, that included a button, we could make the button be decorative, i.e not button's but just a span or inline-block div that looks like a button. Or would that be bad practice?
It would not be great — unless the fake-button is all the text in the element, it wouldn't match the accessible text of the link (bad for voice control), and the button itself wouldn't react to hover/focus/etc. From a tech side, it would also be difficult to do. Either we create a new "fake button" block, or we need to do HTML regex to replace the <a> from a normal button block.
If you want to include a button in the banner, it shouldn't use the link wrapper - just the image + button can be links.
Nicholas' note on the copy above seems enough to cover that aspect, and designwise I'm happy with the small stickered version. So that can hopefully unblock us.
Okay, I'll re-remove the status labels to mark this as ready to build.
Here is the file (assets in clear area are the selected solution).
Let us know in case you need anything else.
Thank you!
Is there a reason why JavaScript can't be used to extract the click target of the primary/only action of the link, and apply it to the container - simulating the whole element being a link, without butchering the underlying HTML structure or semantics?
This is a pretty normal pattern on the web.
without butchering the underlying HTML structure or semantics
Can you be specific about what markup you are expecting and how this solution diverges?
I'd do something like this...
<div class="card">
<h2>Some heading</h2>
<img src="cat.jpg" />
<a href="/example-page/" data-link-target="true">Link</a>
</div>
Then some JS to make clicks on .card trigger a location update to the href value of the descendant data-link-target el (plus some CSS to apply suitable hover + active effects).
That's a much cleaner, more semantic approach than some of the alternatives discussed above, and it's a pretty common pattern across the rest of the web. It can also support multiple links/actions, which behave sensibly depending on which element is clicked.