Page MenuHomePhabricator

Implement the redesign of the style guide color page on Codex docs site
Closed, ResolvedPublic3 Estimated Story Points

Description

Overview

As we expand the Codex color palette as a part of T360494, we need to update the color page of the Codex style guide to latest design.

colors.jpg (3×1 px, 1 MB)

Considerations

  1. Should we connect the colors tokens in wikimedia-ui.json to this page, so that as we might make future updates this page would be automatically updated?
  2. If we do link the tokens to this page as described in question 1 then we could potentially complete this redesign before we release the new color palette.

Acceptance criteria

  • Codex docs site has been updated to use the latest design of the style guide color page as found in T360077.
  • The color block at the top of the page is built using values from the option tokens.
  • When option tokens are updated in Codex, the new values are automatically reflected in the colors page.
  • All colors on the page should be generated as HTML from the option tokens (no images).

Event Timeline

CCiufo-WMF updated the task description. (Show Details)
CCiufo-WMF set the point value for this task to 3.

Change #1071023 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] docs: Update Colors page of the Style Guide

https://gerrit.wikimedia.org/r/1071023

AnneT changed the task status from Open to In Progress.Sep 5 2024, 8:04 PM
AnneT claimed this task.

@DTorsani-WMF This was so fun to work on :D Here's the demo. Some questions/comments for you:

  1. For the primary colors at the top of the page: should I be using option tokens or application tokens here? There aren't application tokens for all the values in the design (the status colors), but I wasn't sure if the color palette expansion would include new application tokens as well. If not, I can use option tokens for all (well, I can use hard-coded hex values, since we don't make option tokens available as Less variables). The problem with that is that the colors will not automatically change in dark mode. For now, I used color-error, color-warning, and color-success for the status colors.

Light mode:

image.png (470×1 px, 13 KB)

Dark mode:
Screenshot 2024-09-05 at 4.11.21 PM.png (452×1 px, 16 KB)

  1. I needed to add an h2 before the color lists so that the h3s would be semantic - I added "Color options", but let me know if you'd prefer something different.

Screenshot 2024-09-05 at 4.11.59 PM.png (890×1 px, 102 KB)

  1. You may notice some unfortunate behavior with the H3s:
    1. They don't have links to copy a link to the heading, because VitePress doesn't support generating these links for dynamic headings (since the headings aren't hardcoded, they're generated based on the name of the color category)
    2. On large screens where there's a 2-column layout, if you click in the outline menu on a color in the first column, you'll notice that the color next to it gets highlighted in the outline menu. I don't think there's anything we can do about this, and it's not *that* bad, but it's not ideal.

Screenshot 2024-09-05 at 4.12.33 PM.png (1×1 px, 232 KB)

Let me know if you have any other feedback!

@DTorsani-WMF one more thing...obviously, the colors being output are quite different than the ones in your design. The new color categories (orange, lime, and pink) will show up automatically once they're added. All of the colors are output in the order they appear in the wikimedia-ui.json file, and a color is outputted if it begins with one of the allowed categories (see the colorCategories variable in this file):

const colorCategories = [ 'white', 'black', 'gray', 'red', 'orange', 'yellow', 'lime', 'green', 'blue', 'purple', 'pink', 'maroon' ];

So, there are colors like yellow999 and blue999 showing up. I'm not sure if you're removing those with the color palette expansion, but just be aware that this is the way the logic currently works, and if you want to exclude certain colors, we'll need to add that logic.

Thanks for putting this together @AnneT. This looks amazing. Some thoughts and feedback:

  1. For the colors at the top, let's use application tokens so that they change with the swapping of modes. From left to right, then down in the gray section, let's use color-subtle, background-color-neutral, background-color-neutral-subtle, color-base. The blue should be color-progressive. And from top to bottom of the status colors, let's use color-error, color-warning, and color-success.
  2. This makes sense, and I think "Color options" works well. I guess the only other option would be to make all of the colors h2's, right? Not sure this would look great since all the color names would be bigger. But then they would get a "link to copy", right?
  3. The behavior happening in point B is strange, but I get it, and it doesn't seem terrible if there's nothing simple we could do about that.
  4. Totally makes sense about the colors being different. This is great that we can do this work now and when colors are updated they will automatically appear. My only request would be to make the 999 colors exempt from this list. These won't go away until we address diff colors in a future task, and they are very specific only for that purpose, so they just don't really belong here. If it's possible to remove the 999 colors from this page that would be great.

Thanks for the feedback @DTorsani-WMF!

  1. For the colors at the top, let's use application tokens...

Done!

  1. This makes sense, and I think "Color options" works well. I guess the only other option would be to make all of the colors h2's, right? Not sure this would look great since all the color names would be bigger. But then they would get a "link to copy", right?

Unfortunately using an h2 won't get us the link to copy - the only way to do this is to use a markdown link (e.g. ### Maroon), but because the headings are dynamically generated, we'd actually be writing ### {{ set.category }} which VitePress outputs as the anchor link #set-category. This is a bug in VitePress.

If we didn't want the "Color options" h2, we could make the color names h2s, but like you said they would be bigger and have a larger margin top and a border top. We could undo all of this to style them like h3s, but we tend to try to avoid doing that.

  1. Totally makes sense about the colors being different. This is great that we can do this work now and when colors are updated they will automatically appear. My only request would be to make the 999 colors exempt from this list. These won't go away until we address diff colors in a future task, and they are very specific only for that purpose, so they just don't really belong here. If it's possible to remove the 999 colors from this page that would be great.

Sounds good; I've removed the colors with 999 in the name.

@DTorsani-WMF I'm moving this from design to code review, but please feel free to give more feedback as needed

@AnneT Okay great, thanks for these updates and the info. Let's leave the "Color options" h2 and the color names as h3 as is. At this time I have no other feedback. This is really exciting! Thanks for doing this work and I'm excited to see this page updated and then filled out once the color expansion work is published.

Change #1071023 merged by jenkins-bot:

[design/codex@main] docs: Update Colors page of the Style Guide

https://gerrit.wikimedia.org/r/1071023

Change #1073562 had a related patch set uploaded (by LWatson; author: LWatson):

[mediawiki/core@master] Update Codex from v1.12.0 to v1.13.0

https://gerrit.wikimedia.org/r/1073562