-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Homepage Update #213
Comments
I've made most of these changes on trunk except the footer. @ryelle Do you think it makes sense to add a footer variation for this homepage? |
Hm... with the "expressive" sites, they'll probably introduce other footer variations with other colors. Do you think we should just keep adding variations, or maybe switch to enabling colors on the footer block, and set the background/text/link colors on the block instead? The long color bars are the intended accents for those sites. Header would still need variations, since it uses specific hover colors and such, and we wouldn't be able to set those via block settings. If it impacts your opinion at all, there's also this new issue to add borders to the header & footer, and I was thinking that would be easier done with enabling border support rather than duplicating the styles to add a "with border" version. |
Yeah, that makes sense. Let's make the block configurable. |
Made that an issue on the mu-plugins repo: WordPress/wporg-mu-plugins#341 Once that's done you can set the colors on this page. |
@ryelle the docs team is looking into the new color added to the site. They don't agree on the use of green for the banners so I am checking with the design team to see if we can go back to the black version that was already approved. Whenever you work on this, go ahead with the design, it is just the color that is in question. I'll let you know what we resolve |
CC @WordPress/meta-design |
As a personal opinion I like the use of color to ambiguate major sections of the site. I tend to have multiple tabs open, and having some basic and very light-weight color coding, gree or otherwise, helps me ambiguate quickly. |
What's the issue/concern the team has with the color @estelaris? |
@beafialho The use of color is not banned, they welcome it, just not green or red (I would add yellow but that one is rarely used) as they are used as warnings, for example. Here is the specific comment from docs team:
You could use the pink or any of the grays from the color palette if you wish to change colors. |
On another note, why was the code reference dropped from this menu and replaced by the HTTP API? I will review tomorrow during the meeting but we are not aware of any changes and the menu was requested, after a conversation with several teams. I think we should keep menus as requested by the teams that use the pages, unless there is an imminent change in the WP.org site and it has been communicated to the teams. |
Specific colors aside, I wanted to quickly respond to this one part:
I think we should be increasingly aware that using red and green as semantic affirmative and negative colors, as these colors don't take color blindness into account. Google recently wrote about relying more on text and icon, than color, for those cases, acknowledging that the typical stoplight colors can leave out up to 10% of people. |
A point we are aware of, but WordPress doesn't write the global rules in coding and neither do we. In the documentation, we are not using green/red as warnings, but will retain the use of the blue3, blue 4 and light gray (from the palette) for explanations and warnings, same as will be in the /documentation/ site. When the design of the documentation sites began, I stated clearly that due to the type of content (either full of images for tutorials or code example blocks for developers), the background or template must be as simple and minimalistic as possible. The use of decorative green banners does not fulfil this requirement. |
I'd like to emphasise the question of where HTTP API is going to land and why is Code reference removed from the menu. Regarding color: what is the reason to choose exactly that color for documentation site? Out of all colors in the palette above, that is one of two that have specific usage in documentation (not just WordPress documentation but documentation in general). We can argue if those colors should be used for meaningful context and whether it is recommended to start banning the usage but at this point, green and red colors (and their close variations) are used widely to represent success/errors/warnings. We can agree not to use those colors in such a purpose any more but let's agree not to use those colors as purely decorative in places where they still can bring the initial meaning and make confusion. At least until we all are sure that such confusions won't happen. |
I'm afraid I lack context on the menu item replacements as I jumped in late in the process. Regarding the colors, here are my two cents:
|
A note about the item replaced on the homepage, not on the menu. I am following up with @StevenDufresne on Figma at the moment, as all the notes seem to be there. Link to the discussion https://www.figma.com/file/2WxlJFzMJvqPfZL1EkAOVp?node-id=2014:17394#382849416. |
I wasn't really involved in the design's conception, so I can't speak to that, but as mentioned in the figma thread, the code reference landing page was absorbed by the main page. The search bar was added to the header and the code reference landing page content was repatriated to the main homepage in various ways. The code reference is the same, save for the deprecated landing page. I think @javierarce could provide more context. If we do want to re-add, we have this early design iteration that we would need to implement: We would also need to add "Reference" back into the breadcrumb. |
The new design which is ready for dev: ![]() |
Should we update the OP? |
The homepage has undergone another iteration.
Here is the latest design:Update Aug '23:
The new design which is ready for dev:
The text was updated successfully, but these errors were encountered: