Update Typography Page

[emsaiz]

Changes:

• Include only the fonts we use on our sites and what sites use those fonts in some way. I have an idea below but feel free to try something else if you want!
• Adding copy color hex codes
• I have a "font weight" section but idk if we need that. I'll talk to Euna and keep you posted!

[AlexVanK]

I've taken care of the Typography preview section, but I don't think I can add the copy/color text as those can change on a site basis depending on the style definitions at inception...

I see that you have some DOs and DONTs, could you go inside and fill them in?

[emsaiz]

Yes! I can update those sections today.

I understand your point. Why would be display typography previews for different sites on this page but only showcase one site's color palette? Perhaps they should be featured on the theming page instead?

This is really just a resource for QA and non-design system sites.

• Betsy always asks about the official hex codes for Grant's typography and links (it's a trick question lol) because we have so many variations! I think it would be really helpful to have the hex codes posted somewhere just for easy reference, so people don't have to ask designers, developers, or check the source code.
• Plus for other new sites like the media center backend that Mauricio is building with REACT, he technically can't use the design system, but it would be nice if he knew what colors to use so it looks like he did.

[emsaiz]

Also, now that I'm re-reading the guidance I wrote, not all of our site's typography colors are accessible. Especially when it comes to Link Luminosity (https://webaim.org/resources/linkcontrastchecker/).

So I feel like we should call out our desired copy colors somewhere whether it's here or on the theming page.

• If it's the theming page, I can link to it in the guidance.
• If we keep it here, maybe we could rename the H2 to something like "Accessible Copy Colors" or "Approved Copy Colors."

[AlexVanK]

Honestly, I do not remember why we have a typography preview. I think because we had defined the fonts that will EVER be used, not the fonts that are currently being used here and there.

I do not think that the style-guide should be a index to find website-specific rules. If 100 websites adopt the styleguide, we can't possibly list all the basics for those websites on the styleguide? So yes the styleguide is a resource for best practices, but not a resource for QAs to find information about the websites where the styleguide is being used.

So all the information they seek, they need to find it on the website they are interested in. The fact that grants and design-system styles coincide is a paradox, but somewhere we had to define a basis, and we've coincided that basis with the grants redesign effort. So it's just a coincidence that the rules for grants are to be found on the styleguide, but it shouldn't be that way.

The styleguide is prescriptive, not descriptive. It should inform the users on how things have to be done, not tell them how things are currently being done.

In other words, the styleguide is an abstraction of applied realities, so we can say "the body color has to have that accessibility, and contrast, etc. etc.", but we can't really say "the body color IS THIS HEX CODE"

So to your use cases:

• Betsy can find the hex-codes of grants by inspecting the styleguide - but I want to stress that it's just because we have decided that this is the base point, but when you have your 10th website, you can't find the hex code on the styleguide. Yes people have to ask the designers, because the designer have designed the look and feel of the future website LOL, not the styleguide. If they don't wanna ask them, then they can inspect, but if the website doesn't exist there's nothing to inspect.
• For the learning center, yes he CAN use the design system, if he makes the application design-agnostic and he only uses utilities instead of hard-defined styles. Once the application is deployed it will inherit the surrounding CSS ecosystem, but that will never happen if stuff is hard-coded (this however is probably a dedicated discussion in its own). For reference, the FAQ front-end is a REACT application that inherits the styles from the website it lives on, it can be done.

---

In short I would remove all reference to other websites from the style-guide as that creates confusion, and not make it a glossary of colors, fonts, and what not...

[emsaiz]

I 1000% agree with your points! Especially:

• "The styleguide is prescriptive, not descriptive. It should inform the users on how things have to be done, not tell them how things are currently being done."
• ^But aren't we prescribing the body copy color, link color, and visited link color from here forward? As more sites are built and redesigned they're going to be adopting the same typography values.

  ---

• "In short I would remove all reference to other websites from the style-guide as that creates confusion, and not make it a glossary of colors, fonts, and what not..."
• ^ Sounds good. Hopefully the you didn't waste too much time with the front-end previews!

Customers have a tendency to want to customize everything! This was my way of beating them to the punch -->We're not allowing new sites to dictate copy colors etc. But I'm always ok with less is more. So we can leave it off and then if we have questions or trouble with customers we can add it for them.

Also let me know if you want to huddle about this anytime!

[emsaiz]

So I guess what I'm proposing (instead of the design above) -- Is to make a little note in the Usability Guidance section about not customizing copy colors (NO HEX CODES!). Let me know if you disagree!

[AlexVanK]

Ok I removed the reference to the websites from the typography page...

To answer your question:

But aren't we prescribing the body copy color, link color, and visited link color from here forward? As more sites are built and redesigned they're going to be adopting the same typography values.

Nope. Copy, link, link-state colors styles are still subject to the general look and feel of the website. You can prescribe certain usability rules, but not the color themselves. What if the background of the website is not pure white, but some kind of pearl white color? Then the copy color will have to be different. Other more likely scenario, since eventually we will have to support dark-mode: how is a prescribed body color going to react to that? Bootstrap already takes care of making every color accessible, but if a stubborn designer wants to change them, they can, and we can tell them the how, not the into what. Makes sense?

---

Now the question is whether to do that also on the THEMING page... see the theming page is a bit a contradiction to what I stated yesterday, it serves no other purpose but to illustrate a preview of a theme that follows the Design Sys guidelines, and that is already deployed on a website. So in that case it is a bit descriptive and a bit of a resource. Adding a new packaged CSS stylesheet to that dropdown there is easy, as long as it's already completed and deployed. Perhaps the whole page shouldn't even be under "Getting Started", maybe under "Resources" or "About"? Let me know what you think.

[emsaiz]

Ok just to keep you in the loop, Euna and I have talked about limiting customers/sites with the typography choices. It's probably unrealistic to say "everyone uses open sans for everything," but I'm hesitant about simply providing a list of fonts. I want to avoid giving customers or designers the impression that they can freely choose any number of fonts or potentially select ones that don't complement or contrast well with each other.

I kinda like what NIAID did on their theming page. They provide a few heading options and body options. It gives people choice, flexibility, and branding opportunity with some guardrails. Sort of like the idea of component in that you're not starting completely from scratch. What do you think?

https://designsystem.niaid.nih.gov/builder/

---

I like the idea of including the theming page under "Resources"!

[emsaiz]

Sorry I also wanted to mention that this might be a better V2 addition. It's really not something we need now but something I was thinking about in general