Skip to content
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

Closed
StevenDufresne opened this issue Feb 10, 2023 · 18 comments · Fixed by #285
Closed

Homepage Update #213

StevenDufresne opened this issue Feb 10, 2023 · 18 comments · Fixed by #285
Assignees
Milestone

Comments

@StevenDufresne
Copy link
Contributor

StevenDufresne commented Feb 10, 2023

The homepage has undergone another iteration.

Here is the latest design:

Update Aug '23:

The new design which is ready for dev:

@StevenDufresne
Copy link
Contributor Author

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?

Screen Shot 2023-02-14 at 2 18 40 PM

@ryelle
Copy link
Contributor

ryelle commented Feb 14, 2023

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?

Screenshot 2023-02-14 at 12 00 31 PM

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.

@StevenDufresne
Copy link
Contributor Author

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?

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.

@ryelle
Copy link
Contributor

ryelle commented Feb 15, 2023

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.

@estelaris
Copy link
Member

@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

@StevenDufresne
Copy link
Contributor Author

@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

@jasmussen
Copy link
Collaborator

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.

@beafialho
Copy link

They don't agree on the use of green for the banners

What's the issue/concern the team has with the color @estelaris?

@estelaris
Copy link
Member

@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:

We don't want green headings or any contextual colour in text that is pure decorative. If it was purple we wouldn't mind but green has meaning in documentation and in code so no to green

You could use the pink or any of the grays from the color palette if you wish to change colors.

@estelaris
Copy link
Member

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.

@jasmussen
Copy link
Collaborator

Specific colors aside, I wanted to quickly respond to this one part:

We don't want green headings or any contextual colour in text that is pure decorative. If it was purple we wouldn't mind but green has meaning in documentation and in code so no to green

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.

@estelaris
Copy link
Member

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.

@zzap
Copy link
Member

zzap commented Mar 7, 2023

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.

@beafialho
Copy link

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:

  • Like @jasmussen mentions, one of the most important rules in UI design states is about not relying on color alone to convey the meaning. The interfaces that use color alone (in this case red and green) pose the risk of confusing color blind users.

  • Additionally, I have the perception there's a very clear difference in seeing a green background color that's part of the theme's color palette, which is obvious in this design, and a green background of a success message such as these callouts for instance. The shades of green are clearly different, but my main point is the context is what differentiates the two, with additional information presented, such as icons and text messages for error and success.

@estelaris
Copy link
Member

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.

@StevenDufresne
Copy link
Contributor Author

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:

image

We would also need to add "Reference" back into the breadcrumb.

@adamwoodnz
Copy link
Contributor

The new design which is ready for dev:

@jasmussen
Copy link
Collaborator

Should we update the OP?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants