Closed jasmussen closed 1 year ago
@jasmussen Fortunately, there's a handy section in the Brand Writing Guide that covers web formatting for WP.org. The default should be sentence case for titles/headlines, CTAs, tags, etc. 👍
e-commerce → E-commerce Eyeglasses → can we delete in favor of Eyewear? home decor → Home decor Hospitatlity → Hospitality household cleaners → Household cleaners? Maybe delete? interior design → Interior design MadeInJapan → Can we delete this? It only has one site in it. quartz → Quartz, maybe delete? Sunglasses → Maybe delete since there's only one in it? Eyewear may be the catchall.
I'm on board with all of these suggestions for initial launch. That being said, there may have been a strategy behind having so many same-same, but different tags (ex: eyewear, eyeglasses, sunglasses) that I'm not aware of, so I'll look into that further.
but just reviewing a few of the 87 sites, there are a couple of things.
I can do a QA/copyediting pass on the individual site pages along with addressing your notes.
I like the "Why is it in the showcase" section. That section seems unique to this particular page, do we need it in other places too? The only gotcha is that it seems to answer a question I didn't have, so I'm mainly curious if we need to keep the heading or maybe just remove it?
Right now this is an assumption, but there is a required question on the Submit a site form that asks about why a site is being submitted to show case ("What makes this site unique or interesting?"). So for future sites, we should have this information for all that come in. I'm just not sure if we have it for legacy sites, which would explain why some of these pages have that information and others don't. I definitely agree that it should be consistent in how it appears across each site page (where currently applicable).
That being said, there may have been a strategy behind having so many same-same, but different tags (ex: eyewear, eyeglasses, sunglasses) that I'm not aware of, so I'll look into that further.
To clarify, I don't necessarily mind a larger amount of tags if it helps as a taxonomy across the depth of the archive. The main aspect where it would be good to build confidence is in the case where a particular tag is used only ever for a single site, in that case it seems less useful as a navigational aid.
but there is a required question on the Submit a site form that asks about why a site is being submitted to show case ("What makes this site unique or interesting?")
Ah yes, good point. I think the reasoning is valid enough, whether it is something that is used only to decide whether a site is worth adding, or whether it's also included in the prose.
There's likely a bit of an editorial responsibility as to what subsequently happens, and it might make sense to have either some content guidelines, or just an excellent post to point to as a "template" or sites. What do you think?
On focusing the search field, we should either make the entire field have a white background (including the loupe), or not change the gray backround color to white.
The entire input is white, the issue is that's a button next to it, not part of the search. I mentioned this issue in the PR where I implemented this design. I think it would make more sense to leave the entire thing grey, otherwise you get this floating button/text effect:
Focus on input | Focus on button |
---|---|
Main index page tags
Should this be a content rule- limit chosen tags to <=3, or just the display here restricted in code?
Tag review
This is a content change, so I'll leave that to @thetinyl — these can be changed directly on the site, whatever you decide.
Submit a site
This page hasn't even been addressed yet. You can see the issue is still open here.
Some of the thumbnails didn't load for me, or were missing:
The loading ones are still being processed by mshots. The should show up on the next page load. The white image for "The National Puerto Rican Day Parade" seems to be what mshots sees, so if we want to keep that site it should get a custom image.
We decided separately that it's okay for colors to be auto deduced, but for Tonal specifically, let's update to use #d3c0b7 as the header BG color.
Okay, I assumed marketing or design would go in and change those colors once I added the UI. Do you need me to change that? and for any other site or just Tonal?
It seems we haven't designed a quote style, is this inherited from News?
Probably, feel free to create a new issue on the parent theme to style it differently (unless you want a custom style for showcase, in which case create it on showcase 🙂 )
On the homepage, the last row shows 2 items on the wide breakpoint:
This is also a content issue- there are only 11 items in the "Featured" category. Once the content is updated and 12 items are picked, it should line up in 2 and 3 column layouts.
It would be nice if through flex magic we could avoid the text ever wrapping (white-space: nowrap) until the mobile breakpoint where they stack.
I'll have to look at how this works on the main site, IIRC it was built this way to ensure the arrow was always the full width across and didn't break off the screen. Changing it will also affect the homepage, since it's the same pattern.
Pulling all this together into an actionable-for-dev list, this is what I've got:
The entire input is white, the issue is that's a button next to it, not part of the search.
Right, thanks for the clarification. It seems that wp-block-search__inside-wrapper
would be the colored container whose background should be updated, and since it's a parent to the focused item, that's non trivial. Keeping it gray even on focus (i.e. removing the white from the focus style) could work too, contrast seems to still work. And if we can't, that's okay too.
Should this be a content rule- limit chosen tags to <=3, or just the display here restricted in code?
I'm happy to defer to content authors on the amount of tags to show. This is mainly an inquiry, can we restrict it just in code? If yes, then that would be great.
Okay, I assumed marketing or design would go in and change those colors once I added the UI. Do you need me to change that? and for any other site or just Tonal?
I'm happy to do it, I don't know if Lauren will be involved with some of the copy work, if yes she could do it too. Forgive me if you've shared this already, and I couldn't find it in the wiki, how do I do this?
This is also a content issue- there are only 11 items in the "Featured" category. Once the content is updated and 12 items are picked, it should line up in 2 and 3 column layouts.
Fantastic, thank you for the clarification.
This is also a content issue- there are only 11 items in the "Featured" category. Once the content is updated and 12 items are picked, it should line up in 2 and 3 column layouts.
👍 👍
Thanks for tackling this. The following are less important in prioritiy, in case it helps triage:
Animate the border color on thumbnail hover Remove underline on view tags (parent theme) Pagination feedback
Should this be a content rule- limit chosen tags to <=3, or just the display here restricted in code?
I'm happy to defer to content authors on the amount of tags to show. This is mainly an inquiry, can we restrict it just in code? If yes, then that would be great.
I would limit it in code so we don't implement a limitation that leads to sparse archives or make content authors decide which categories are the most fitting.
I also find the truncation distracting on mobile, and maybe should consider only showing 2 on mobile.
400w |
---|
We can also include a blanket 2-tag limitation.
Just wanted to note that "View all sites" no longer has left/right padding.
I moved the tags conversation into a new issue: https://github.com/WordPress/wporg-showcase-2022/issues/158 — I've left it as "in discussion" in case anyone wants to add to it, but I'll probably move it to "to do" with the approach in my comment tomorrow.
I moved the tags conversation into a new issue: https://github.com/WordPress/wporg-showcase-2022/issues/158 — I've left it as "in discussion" in case anyone wants to add to it, but I'll probably move it to "to do" with the approach in my comment tomorrow.
Just wanted to note that "View all sites" no longer has left/right padding.
Yeah… I accidentally introduced that with the constrained width change
Forgive me if you've shared this already, and I couldn't find it in the wiki, how do I do this?
That page is very out of date. The UI in the editor should be explaination enough, but just in case I've also updated the wiki page.
Note that I realize I shared the wrong screenshot of the search field. What I meant to share was this:
Sorry about the detour, but it seems like you captured it right, and that the solution, probably, is to not change the bg color on focus.
@jasmussen Thanks again for your notes above, I believe most (if not all) have been addressed for the 12 featured sites. In terms of the orphaned words, I'm not quite sure what the best way to fix those would be, as they'll be dependent on a visitor's screen size, right? With the responsiveness?
The UI in the editor should be explaination enough, but just in case I've also updated the wiki page.
Also, TIL that we can control the colors. How fun! Thanks @ryelle for updating the Wiki. I took a quick look at them based on Joen's notes and it looks like all the color changes (for the featured sites, at least) were applied.
@jasmussen I've updated the site hero dots, I think I've got it as close to what you're describing as possible given how browsers scale. I tried a few other approaches (border-image
, 3 separate backgrounds using ::before
& ::after
, various positioning and repeat rules…), and each had issues with cutting off dots or skewing the dots. The solution I landed on shows a single frame of dots around left, top, right sides, and does not skew or cut off any dots. On small screens, it only shows the line of dots above the screenshot.
If that's still not what you expected, a codepen or some changes from your browser's inspector would be helpful.
I found a few more items in testing:
Thank you all for looking, what a huge improvement this did, both contentwise and design wise. This is getting very close, so nice to see.
I'm not quite sure what the best way to fix those would be, as they'll be dependent on a visitor's screen size, right? With the responsiveness?
Indeed, I do believe that @adamwoodnz had some ideas for a code snippet that would (potentially?) work across wp.org to automatically fix orphans across breakpoints. I wouldn't say this is something we have to do for launch, this is more of a less-urgent enhancement that would be nice to roll out across.
However until then, I think we can leverage the fact that on the desktop view, there's a max-width of 680px, so we can at least optimize for this one breakpoint and make sure that the view which presumably is used the most often, looks good. Here's the Noma example:
That "combination" will always be orphaned on this breakpoint, but we could change it to the following and it would be balanced at least in this view:
☝️ please don't take the above edit as anything but a quick experiment, I'll naturally defer to you, Lauren, on the exact copy.
And yes, to your point, even that copy can be orphaned, here a breakpoint somewhere between tablet and desktop:
But it still feels worth it to optimize it for the stable-width desktop breakpoint, IMO. I didn't find that many orphans at that size, so it shouldn't be too big of a lift, hopefully.
I've updated the site hero dots, I think I've got it as close to what you're describing as possible given how browsers scale.
Thanks, this is really close, and it might just be good. I still want to try and take a stab in a codepen, see if the aspect ratio idea can work for us, but I appreciate your efforts here 🙏
I'll return with an update in a bit.
@ryelle I ended up creating this codepen with caveats:
I think it uses mostly the same approach that you, insofar as it uses absolute positioning to place the feature image on top of the dots background. I fiddled a bit with the clamp values for the inner padding (--hero-padding in the codepen) and did not get them just right, but hopefully they get the general behavior across.
The main place where the codepen diverges a little bit from what's shipping is that it applies an aspect-ratio combined with a min-height and a max-width to fluidly scale the overall height of the feature area, like so:
By changing that height fluidly, it avoids this awkward case on the current staging site, where suddenly there's a ton of whitespace above a bottom-aligned feature:
My hope is that the aspect ratio pieces can be mostly copied over from the codepen 🤞 — let me know if this is helpful!
I am noticing that the background color in Showcase for the header/footer and homepage top section is #1e1e1e (Charcoal) while similar redesigned sections in other areas of the site, like Developer Resources and Patterns, are #23282d (Charcoal 2). The current site header/footer are also #23282d (Charcoal 2). Should we standardize on #23282d?
I think charcoal was intentionally chosen here, as the reduced saturation and lightness works well putting the focus on the site itself. But good attention to detail.
Reminds me, as I was web-inspecting the site, I noticed that the breadcrumb bar is 57px tall. It should be exactly 60px, across every breadcrumb bar in fact. Depending on where that component lives, it may be showcase specific, or it may be parent page specific, but wanted to note it. Let me know if this needs a separate issue.
I think charcoal was intentionally chosen here, as the reduced saturation and lightness works well putting the focus on the site itself. But good attention to detail.
Sounds good. We may want to choose a different background color for the primary nav dropdown then. It looks good with #23282d but feels too close to #1e1e1e.
I think we can leverage the fact that on the desktop view, there's a max-width of 680px, so we can at least optimize for this one breakpoint and make sure that the view which presumably is used the most often, looks good.
@jasmussen This makes sense. I've looked at all the featured showcase pages and gave the remaining widows some company based on the suggested max-width.
I've addressed all the items I pulled out in the checklist. I think it was all straightforward, the only thing that didn't work out was the "View all sites" wrapping— if it does not wrap, there's not enough space for the arrow on a mid-sized screen, causing a horizontal overflow scroll. I've tweaked it so that it won't wrap on Showcase above 1100px wide (previously it wrapped at 1280ish). If that needs to be tweaked more, @jasmussen, can you create an issue on the parent theme and consider how it will apply to that pattern as a whole?
We may want to choose a different background color for the primary nav dropdown then. It looks good with #23282d but feels too close to #1e1e1e.
The global header lives in wporg-mu-plugins, and those colors are set as custom properties here. @ndiego Do you want to create a new issue on the wporg-mu-plugins repo to discuss this? or does it need to happen before final showcase review?
I noticed that the breadcrumb bar is 57px tall. It should be exactly 60px, across every breadcrumb bar in fact.
Showcase doesn't have breadcrumbs, but I'm guessing you meant the local nav bar. I've updated the padding to make it 60px exactly.
The global header lives in wporg-mu-plugins, and those colors are set as custom properties here. @ndiego Do you want to create a new issue on the wporg-mu-plugins repo to discuss this? or does it need to happen before final showcase review?
The color of the dropdown looks good on all sites except on Showcase (IMO). I don't think any modifications need to be made to the base colors, just how we handle the colors on Showcase. I'm not sure what the best course of action here is, so defer to @jasmussen and @marko-srb.
Showcase | Other Pages |
---|---|
Right, the charcoal-1
header is a variation of the global header, and the colors used in it are controlled there. Changing the dropdown color for charcoal-1
, even if it's currently only used on showcase, would need to happen in wporg-mu-plugins, in the file I linked.
Right, the charcoal-1 header is a variation of the global header, and the colors used in it are controlled there.
Oh gotcha, sorry I misunderstood that this was a variation. I'll add an issue over there in a bit.
When the background is charcoal-1, the dropdown is charcoal. We can invert that so when the background is charcoal, the dropdown is charcoal-1. Would that work?
When the background is charcoal-1, the dropdown is charcoal. We can invert that so when the background is charcoal, the dropdown is charcoal-1. Would that work?
I added an exploration here: https://github.com/WordPress/wporg-mu-plugins/issues/451
@jasmussen Thanks for the codepen, it was helpful to see your take on it. I've updated the site hero again, and it appears to be centered correctly now. I also updated the style for when it switches to a single column.
I think that addresses all of the dev tasks in this issue, is that correct?
Glad it helped! That said, I'm still seeing this happen (a lot of whitespace above the feature image around the tablet breakpoint), and no aspect-ratio
applied. Let me know if I'm seeing a cached version or something.
I think that addresses all of the dev tasks in this issue, is that correct?
Nice! Huge improvement across. Lots of good details. A few small things, that I would say are not blocking. In the Figma, the gap between submenu items is 24px. I know that's off-grid, I wonder if it's a piece that Francisco missed. We can go with the 20px gap for now and revisit when he's back to see if it's 20 or 30 or indeed 24. But if it's easy, might want to go with 24 for now, and then correct across the componentry at a later time.
In the super detail territory, there seems to be an errant margin in the filter dropdown inner part, just on the taglist not no the button combo. See the yellow in this screenshot:
Compare with:
I didn't immediately find anything else, and the only important thing is still the header piece. Can the aspect-ratio trick help here?
Just to better illustrate the issue with the whitespace above the feature, here is the desired state, where the top row of dots is always aligning with the top footprint of the "Showcase" heading:
On one of the between mobile and desktop breakpoints, I'm seeing the feature with dots being attached to the bottom of the feature area, thus disconnecting the dots with the showcase heading:
This is why I think the aspect-ratio change is likely necessary, so that the overall height of the feature are can still enable the positioning we are looking for.
no aspect-ratio applied.
It’s applied to the cover block itself because it did not work with the display of the columns block. As you mentioned in your codepen, that CSS was not handling mid & small screens well. I grabbed what was helpful, and ended up with the aspect-ratio on the cover instead.
But if it's easy, might want to go with 24 for now, and then correct across the componentry at a later time.
I’d rather not create an exception to the component behavior until we know it’s intentional, so let’s wait for @fcoveram’s input.
In the super detail territory, there seems to be an errant margin in the filter dropdown inner part
That'll be fixed shortly :)
Just to better illustrate the issue with the whitespace above the feature, here is the desired state, where the top row of dots is always aligning with the top footprint of the "Showcase" heading:
This is more helpful, that was not clear before. I'll see what I can do.
It’s applied to the cover block itself because it did not work with the display of the columns block. As you mentioned in your codepen, that CSS was not handling mid & small screens well. I grabbed what was helpful, and ended up with the aspect-ratio on the cover instead.
Understood, but we'll almost certainly need to revisit this again, though, because we need to avoid those dots going under that red line.
Here's the latest— I've got the margin and padding scaling a bit in that problem zone (1280-1180 wide), so the meta column is never taller than the screenshot. I also updated the spacer a bit to scale as well, so that it should always be aligned.
Here's a video (the red line just for illustration, of course), this is also live on staging if you want to test it.
https://github.com/WordPress/wporg-showcase-2022/assets/541093/a9d3ec0e-83d2-4837-ab99-d341caa80423
I do believe that @adamwoodnz had some ideas for a code snippet
We used this function on WP20 to prevent widows in titles, and selectively for other content strings, examples.
Wow. This is good. Let the record show that I officially owe you a milkshake, or beverage of your choice. Thank you @ryelle, from my perspective this works.
Looks great @ryelle 💪
I think we're done with everything here, then! New issues can be opened for anything else 🙂
To the space between local nav links
In the Figma, the gap between submenu items is 24px. I know that's off-grid, I wonder if it's a piece that Francisco missed. We can go with the 20px gap for now and revisit when he's back to see if it's 20 or 30 or indeed 24. But if it's easy, might want to go with 24 for now, and then correct across the componentry at a later time.
Yes. I missed that change, sorry for that. 20px looks too tight next to the global header.
I did a quick review of the showcase work in progress and have a couple of notes. A lot of the feedback here is likely given on work already in progress and is prematurely given, apologies if that's the case. Mainly wanted to capture all of it.
On focusing the search field, we should either make the entire field have a white background (including the loupe), or not change the gray backround color to white.
Main showcase feature
I recognize the following is challenging, but it's also important to get right. The shape of the top header area as it scales responsively, and how the dots appear behind the main feature, should be a bit more rigid. From the mockups, very wide, wide, and normal desktop widths:
Note in those three how the framed/featured site always sits in exactly the same place on top of the dots. On the website, the dots tile and get cropped, as the featured image scales fluidly and the height of the main box remains fixed:
We might need to employ some
aspect-ratio
magic on the main header feature, so that the ratio between dots and featured site frame remain locked in how they scale. Note as part of that how the padding in the main feature box also changes between the monitor and desktop landing sizes:Let me know if you have a path forward here, otherwise I'll try and dive into a codepen, see if we can get this right, it's an important detail.
Subheader links
The mockups use titlecase and have different phrasing and order:
The desktop uses sentence case and sort "All sites" first:
If we have a separate rule to use sentence case for all such links, fine to be consistent here, but we can hopefully fix the verbiage and order.
Filter bar
The Popular tags, Flavors and Categories have a 16px font size, and should be 14 like Search. Ideally we also sort Flavors last.
The whole filter bar should also be 40px tall. Right now the search field is 37.5px and the tag buttons are 44px tall:
This is okay to correct across any site that uses this componentry.
Main index page tags
Is it possible to limit the display of tags on this page to at most 3?
Ideally that could help us avoid the eliding (...) of the text tht happens.
There's also a typo in "Hospitatlity", and some of the tags are lowercase:
Tag review
As per the typo above, here's the current list of tags:
A few corrections, and I'm assuming here we go with sentence case, if we need to be title-case I'll defer to @thetinyl.
Thumbnail
Can you add a small easeInOut transition, perhaps 0.2s in duration, to fade in the the border color? If you need to turn that off for accessibility, here's a good mixin:
Filter dropdown
The token shown on category links looks good, by the way!
Submit a site
Feels close, nice work. Can we use a "centered column" template instead of having the title on the left? There's also a dot pattern at the top that would be good to add:
The footer should also be the dark version, not the light version:
All sites
Very close, nice!
The gap is 60, in the mockups it's 50.
Pagination looks good, but the spacing isn't entirely right (it's wider in the mockups):
a
tags for bigger hit areas.There is a dots banner at the bottom missing:
The 70 sites token, and the sort button on the right are misaligned. This is likely because the Sort button is 16px font size, which should be 14 as mentioned for the filter bar:
Some of the thumbnails didn't load for me, or were missing:
This could be related to legacy content, just want to note for awareness.
Indiviual sites
Tonal web
Tonal figma
Coming along really well, nice.
It seems we haven't designed a quote style, is this inherited from News?
It looks good enough, but we might separately want to update this to be same font+size as the body, no left padding, and a light gray left border instead.
A couple of responsive things
On the homepage, the last row shows 2 items on the wide breakpoint:
and one item on the desktop breakpoint:
If we showed 12 items instead of 11, it seems like it would line up with full rows across both breakpoints.
There's a missing max-width on the "view all links" and the footer CTAs. Here on a wide screen it goes edge to edge:
In the mockups, this is bounded to 1920:
View all sites
Again a case of deciding if we capitalize or not (mockups suggeset "View All Sites") so just want to make sure we decide here and stick with it.
It would be nice if through flex magic we could avoid the text ever wrapping (white-space: nowrap) until the mobile breakpoint where they stack. Mockup:
Desktop breakpoint:
Some copy considerations
I'll defer to @thetinyl if she has any input, but just reviewing a few of the 87 sites, there are a couple of things.
Noma:
http://noma.dk
instead ofhttps://noma.dk
)The Line Hotels:
Qualtrics
Caesarstone
cbc1bb might be a better spot color
Tonal
RollingStone
WhiteHouse
Meta Newsroom
TechCrunch
Method
This might be an older submission, the screenshot is very out of date, but I wanted to bring it up because in the copy, under "source: Wikipedia", the link links to
_wp_link_placeholder
and thus, is broken.I'm happy to review additional sites, but this is a good starting point/pattern, and there may be a better/separate place to do this, so I'll stop here for now.