-
Notifications
You must be signed in to change notification settings - Fork 32
docs: Add Gamut Style Guide under /Meta #3197
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
base: main
Are you sure you want to change the base?
Changes from all commits
a2ef92b
be93a53
6acf546
41ac0da
5637dea
60f0a66
d094255
5a55840
70901b8
bc10713
369bdca
94530ee
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,36 @@ | ||
| import { Meta } from '@storybook/blocks'; | ||
|
|
||
| import { | ||
| AboutHeader, | ||
| addParentPath, | ||
| TableOfContents, | ||
| } from '~styleguide/blocks'; | ||
|
|
||
| import { parameters as formattingParameters } from './Formatting.mdx'; | ||
| import { parameters as generalPrinciplesParameters } from './General Principles.mdx'; | ||
| import { parameters as languageAndGrammerParameters } from './Language and Grammer.mdx'; | ||
| import { parameters as linkingParameters } from './Linking.mdx'; | ||
| import { parameters as referencingCodeParameters } from './Referencing Code.mdx'; | ||
| import { parameters as storiesParameters } from './Stories.mdx'; | ||
|
|
||
| export const parameters = { | ||
| id: 'Meta/Gamut Writing Guide', | ||
| title: 'Gamut Writing Guide', | ||
| subtitle: | ||
| 'Guidelines and standards for creating consistent, clear, and effective documentation.', | ||
| }; | ||
|
|
||
| <Meta title="Meta/Gamut Writing Guide/About" /> | ||
|
|
||
| <AboutHeader {...parameters} /> | ||
|
|
||
| <TableOfContents | ||
| links={addParentPath(parameters.id, [ | ||
| generalPrinciplesParameters, | ||
| languageAndGrammerParameters, | ||
| formattingParameters, | ||
| linkingParameters, | ||
| referencingCodeParameters, | ||
| storiesParameters, | ||
| ])} | ||
| /> |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,71 @@ | ||
| import { Meta } from '@storybook/blocks'; | ||
|
|
||
| import { AboutHeader } from '~styleguide/blocks'; | ||
|
|
||
| export const parameters = { | ||
| id: 'Formatting', | ||
| title: 'Formatting', | ||
| subtitle: 'Standards for formatting text and content in documentation', | ||
| status: 'static', | ||
| }; | ||
|
|
||
| <Meta title="Meta/Gamut Writing Guide/Formatting" /> | ||
|
|
||
| <AboutHeader {...parameters} /> | ||
|
|
||
| Consistent formatting makes documentation easier to scan, understand, and implement. These standards ensure our content is predictable and professional across all Gamut components. | ||
|
|
||
| ## Numbers | ||
|
|
||
| - Use numerals for all numbers | ||
| - Use commas for thousands: 1,000 | ||
|
|
||
| ## Units of Measurement | ||
|
|
||
| - Use standard units: px, rem, em, % | ||
| - Include space between number and unit in prose: "16 pixels" | ||
| - No space in code: `16px`, `2rem` | ||
|
|
||
| ## Lists | ||
|
|
||
| Lists help break down complex information into digestible pieces. Use them to organize features, steps, or related concepts. | ||
|
|
||
| ### Bulleted lists: | ||
|
|
||
| - Use for unordered items | ||
| - Use parallel structure | ||
| - End with periods if items are complete sentences | ||
| - No periods if items are fragments | ||
|
|
||
| ### Numbered lists: | ||
|
|
||
| - Use for sequential steps or prioritized items | ||
| - Start each item with a capital letter | ||
|
|
||
| ## Code Blocks | ||
|
|
||
| - Use triple backticks (` ``` `) with language identifier (e.g., `tsx`, `javascript`, `css`) | ||
| - Include comments for complex examples | ||
| - Keep examples concise and focused | ||
|
|
||
| Example: | ||
|
|
||
| ```` | ||
| ```tsx | ||
| <TextButton onClick={handleClick}> Click me </TextButton> | ||
| ``` | ||
| ```` | ||
|
|
||
| ## Headings Hierarchy | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. One heading style thing that I realized while reviewing these docs is that I really don't like empty headings. If I have a heading that immediately leads into sub-sections, I always try to write a sentence that introduces the heading. It doesn't take much to add a short description to the heading (one sentence will do), but doing so improves clarity and makes the documentation feel more complete. For instance: ❌ bad
## Nintendo characters
(no content here)
### Protagonists
- Mario
- Luigi
- Link
### Antagonists
- Bowser
- Ganon✅ good
## Nintendo characters
Nintendo has over a billion characters across a gazillion games.
The following lists split them into two categories: good guys and bad guys.
### Protagonists
- Mario
- Luigi
- Link
### Antagonists
- Bowser
- Ganon |
||
|
|
||
| - H1: Page title (used once and set in the `parameters` object, not used explicitly) | ||
| - H2: Major sections | ||
| - H3: Subsections | ||
| - Maintain logical order — don't skip levels | ||
|
Comment on lines
+61
to
+64
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it would be more clear to say something like:
|
||
|
|
||
| ## Whitespace | ||
|
|
||
| - Use blank lines to separate sections | ||
| - Don't use multiple consecutive blank lines | ||
| - Indent code consistently (2 spaces for TypeScript/TSX) | ||
LinKCoding marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - If you prefer tabbing, then it should be set as 2 spaces | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,47 @@ | ||
| import { Meta } from '@storybook/blocks'; | ||
|
|
||
| import { AboutHeader } from '~styleguide/blocks'; | ||
|
|
||
| export const parameters = { | ||
| id: 'General Principles', | ||
| title: 'General Principles', | ||
| subtitle: 'Core principles for writing effective documentation', | ||
| status: 'static', | ||
| }; | ||
|
|
||
| <Meta title="Meta/Gamut Writing Guide/General Principles" /> | ||
|
|
||
| <AboutHeader {...parameters} /> | ||
|
|
||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It'd be good to have an introductory paragraph to this page especially, but we also might want that for every separate page. This page's introduction should be philosophical and inspirational, helping to answer "why" for subsequent style opinions. For instance: "Great documentation improves understanding. Not just for our readers but for us, the authors. The act of writing forces us to articulate our mental models clearly so that our readers can share in our framing and understanding." (don't use this, it's just off the dome) I'm also very partial to the Vue writing guide opening paragraph:
Aside from the clarity of their perspective on the point of documentation, I like their inclusion of "this ever-evolving guide" since it makes it immediately clear that their guidance isn't final. |
||
| Good documentation does more than describe — it helps people succeed. These principles guide how we write about Gamut components, with a focus on clarity, accessibility, and usefulness. Whether you're documenting a new component or updating existing content, prioritize being clear about what something does, honest about its limitations, and helpful in showing how to use it effectively. We want to remove barriers and make it easier for designers and developers to do great work. Like our design system itself, this guide is a living document — it will continue to evolve as we add new features and learn from our users. | ||
|
|
||
| ## Voice and tone | ||
|
|
||
| - Friendly and conversational: Write as if explaining to a colleague | ||
| - Direct and action-oriented: Use "you" to address readers | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I much prefer "we" in any writing where the reader is learning from an expert because it quietly invites the reader to be the expert, whereas "you" creates a line between author and reader: "I the expert am telling you the novice what's what." Or more simply, "we" is inclusive, "you" creates separation. My general advice here is to prefer "we" whenever possible because there will be times when "you" is the better choice. For instance, it wouldn't make sense to say "use our best judgment" if we're encouraging the reader to use their judgment, so "use your best judgment" would be fine. But those instances are surprisingly rare—we can usually use "we" for most things without much effort.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For product copy/UX writing we :) generally use "we" as the voice of the company, and we use "you" for a more conversational tone with learners. I can understand this sentiment of being inclusive for this context of documentation. One question: I remember seeing a reference to being explicit about "we" as Codecademy where applicable (can't seem to find it right now)... would we want to place that piece of information closer to this, since Gamut is public and referred to from some of our courses?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Our users are primarily (entirely?) other Skillsoft employees, which is one reason we might want this to be different from company style. As an aside, this was a very specific style point that was used to great effect at Norton. When we switched to using "we" in our composition list in particular, we saw huge growth (it was accompanied by lots of other changes, but this one was notable to our editor). Instead of an expert telling you—the learner—how to write, we were writing together.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Seems like we can take this in different directions —
I think it seems to lean more towards point 1, where we call out the usage of "we" (there is also a separate section in "Language and Grammar" that touches upon this. Will note that we should discuss as a group |
||
| - Encouraging without overpromising: Be supportive but realistic | ||
| - Global audience awareness: Avoid idioms, slang, and culturally-specific references | ||
|
|
||
| ## Inclusivity | ||
|
|
||
| - Use inclusive language that makes all contributors feel welcome | ||
| - Avoid jargon unless necessary — define terms when first introduced | ||
LinKCoding marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - Write for accessibility — ensure screen readers can parse content | ||
LinKCoding marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - Consider contributors of varying experience levels and roles (designers and developers) | ||
|
|
||
| ## Transparency | ||
|
|
||
| - Clearly indicate component status: | ||
| - `current`: Stable, recommended for use | ||
| - `updating`: In progress, API may change | ||
| - `deprecated`: Do not use for new work | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Small quibble: "deprecated" means still actively supported but an end is planned. I mention it because a lot of people think it means "no longer supported" in my experience.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Quick question, are these 4 component status labels considered "props"?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @sh0ji — is that to say I should update the definition to be more specific, like what you wrote? or something else? @uxemilylee — semantics semantics lol |
||
| - `static`: Reference material, no active development | ||
| - Link to source code and design files (Figma, GitHub) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Very nitpick 😅: Could we switch the order to match: Link to source code and design files (GitHub, Figma) |
||
| - Direct contributors to help channels (#gamut-team, Office Hours) | ||
LinKCoding marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ## Consistency | ||
|
|
||
| - Use the same terminology throughout documentation | ||
| - Match language between headings, body copy, and code examples | ||
LinKCoding marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - Maintain consistent component naming across packages | ||
| - Follow established patterns from existing components | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,62 @@ | ||
| import { Meta } from '@storybook/blocks'; | ||
|
|
||
| import { AboutHeader } from '~styleguide/blocks'; | ||
|
|
||
| export const parameters = { | ||
| id: 'Language and Grammer', | ||
| title: 'Language and Grammer', | ||
| subtitle: 'Guidelines for language usage and grammar in documentation', | ||
| status: 'static', | ||
| }; | ||
|
|
||
| <Meta title="Meta/Gamut Writing Guide/Language and Grammer" /> | ||
|
|
||
| <AboutHeader {...parameters} /> | ||
|
|
||
| ## Voice | ||
|
|
||
| - Use active voice: "The component renders..." not "The component is rendered by..." | ||
| - Use second person ("you") when addressing the reader | ||
| - Use imperative mood for instructions: "Add the component" not "You should add the component" | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Lol thanks for using this phrase! "imperative mood"
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it was the robot, I actually had to google that |
||
|
|
||
| ## Tense | ||
|
|
||
| - Use present tense for current functionality: "The Button accepts a variant prop" | ||
| - Use future tense sparingly, only for confirmed features | ||
| - Avoid past tense except in changelogs or historical context | ||
|
Comment on lines
+25
to
+26
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't disagree, but why? This is probably universal, but we should briefly explain why something is recommended.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe these references about plain language guidelines could help! The first one cites many references that support using the active voice and preference for present tense.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Updated, lmk your thoughts! |
||
|
|
||
| ## Pronouns | ||
|
|
||
| - Use "you" for the user | ||
| - Avoid "we" unless referring to the Codecademy team | ||
| - Avoid “I/my/me” entirely | ||
| - Avoid "your/my" in button labels: prefer "Go to dashboard" over "Go to your dashboard" | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this getting into the component-specific writing guidelines? Or are there parts of Storybook where contributors are writing buttons?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Very fair, I will remove |
||
|
|
||
| ## Articles | ||
|
|
||
| - Use articles (a, an, the) for clarity | ||
|
|
||
| - "The Box component" (first mention) → "the component" (subsequent mentions) | ||
| - When plural, the component should stay singular and the “component” is the pluralized, e.g | ||
| - ✅ “These Box components are…” | ||
| - ❌ “These Boxes are…” | ||
| - Omit articles in lists when appropriate for brevity | ||
|
|
||
| ## Prepositions | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could we find a better title here?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Kind of related... It looks like several of the bulleted items on the Language and grammar are about referring to components or other referents. Maybe some of these could be moved to the Referencing code section? Examples of what could be moved:
|
||
|
|
||
| - Platform-agnostic language: "select" or "choose" (not "tap" or "click") | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think something like "Prefer words that aren't specific to input devices" might be more clear here. It wasn't until I got to "tap" that I understood what this meant. Also strong quibble: "click" is device agnostic and often the best choice. Screen reader users can click, keyboard users can click, mouse users can click, and touch device users can click.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Interesting! The majority of preexisting writing guidelines I've encountered have said to use "select" as the most device-agnostic and inclusive term (often noting "click" and "tap" as being device-specific). Hmm... is touching the surface of a device a "click"? Or is the noted guidance an urban myth?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yea, this is an older thread: https://ux.stackexchange.com/questions/57666/documentation-do-we-click-push-press-or-select-a-button-on-a-touch-s |
||
| - Avoid directional language: not "the form on the right" or "in the section below" | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We need non-directional copy to accompany these directional examples. Maybe something like, "the following/adjacent form" and "in the next section"?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I often use "the previous __" and "the following __." |
||
| - Use "in" for code locations: "in the `componentName.mdx` file" | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why do we need guidance on this?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's helpful to have since we can have multiple files (maybe in a folder) for a single component. |
||
|
|
||
| ## Abbreviations and Acronyms | ||
|
|
||
| - Spell out on first use: "Web Content Accessibility Guidelines (WCAG)" | ||
| - Use abbreviations for common terms: HTML, CSS, API, UI, UX | ||
| - Avoid uncommon abbreviations without definition | ||
|
Comment on lines
+54
to
+55
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This would be more clear with something like, "common to the domain of web design and development." If I'm writing in other contexts, I would probably initialize API, UI, and UX, for instance.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "Use abbreviations for common terms in the domain of web design and development:" |
||
|
|
||
| ## Capitalization | ||
|
|
||
| - Sentence case for all headings, buttons, and UI text | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It looks like we need to make all the headings in the writing guidelines section conform to sentence case... Also a couple of copy editing items: |
||
| - PascalCase for component names: `MyComponent`, `ButtonGroup` | ||
| - camelCase for props and variables: `onClick`, `backgroundColor` | ||
| - Capitalize proper nouns: Codecademy, Storybook, Figma, GitHub | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Love the succinctness and clarity of the sections! |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,85 @@ | ||
| import { Meta } from '@storybook/blocks'; | ||
|
|
||
| import { AboutHeader, Callout } from '~styleguide/blocks'; | ||
|
|
||
| export const parameters = { | ||
| id: 'Linking', | ||
| title: 'Linking', | ||
| subtitle: 'Best practices for linking within documentation', | ||
| status: 'static', | ||
| }; | ||
|
|
||
| <Meta title="Meta/Gamut Writing Guide/Linking" /> | ||
|
|
||
| <AboutHeader {...parameters} /> | ||
|
|
||
| Use links to help users navigate between related components and resources. This guide covers linking within Storybook, to external sites, and writing clear link text. | ||
|
|
||
| ## Internal Links | ||
|
|
||
| Use the `LinkTo` component from ‘~styleguide/blocks' and set the id prop as the story’s id value. | ||
|
|
||
| ```tsx | ||
| import { LinkTo } from '~styleguide/blocks'; | ||
| <LinkTo id="Meta/Stories">Stories</LinkTo> | ||
| <LinkTo id="Atoms/Animations/About">Animation</LinkTo> | ||
| ``` | ||
|
|
||
| ### Guidelines: | ||
|
|
||
| - Link text describes the destination, not the action: "See the [Stories page](#)" not "[See the Stories page](#)" | ||
| - Use descriptive link text that makes sense out of context: "[Stories page](#)" not "[Click here](#)" | ||
| - Link component names to their documentation | ||
| - Verify that the link works correctly | ||
|
|
||
| ## External Links | ||
|
|
||
| ### Markdown Links: | ||
|
|
||
| You can use Markdown for external links, the examples below will open in a new tab: | ||
|
|
||
| ```markdown | ||
| [GitHub Repository](https://github.com/Codecademy/gamut) | ||
| [React Documentation](https://react.dev) | ||
| ``` | ||
|
|
||
| ### Anchor Component: | ||
|
|
||
| If you need more control over the link, you can use the Anchor component,the example below will open in the current tab: | ||
|
|
||
| ```tsx | ||
| <Anchor href="https://github.com/Codecademy/gamut">Gamut Repository</Anchor> | ||
| ``` | ||
|
|
||
| <Callout text='If you need external links to open in new tabs, use `target="_blank" rel="noreferrer"` together for security. However, avoid forcing this behavior unless necessary—users can choose to open links in new tabs themselves.' /> | ||
|
|
||
| ### URL Guidelines: | ||
|
|
||
| - Use full URLs for external resources | ||
| - Link to official documentation when referencing tools | ||
|
|
||
| ## MDX file parameters | ||
|
|
||
| For a component's `.mdx` file, add the following to the `parameters` object. Use the `main` branch for the `githubLink`. | ||
|
|
||
| ```tsx | ||
| source: { | ||
| repo: 'gamut', | ||
| githubLink: 'https://github.com/Codecademy/gamut/blob/main/packages/gamut/src/Button' | ||
| } | ||
| ``` | ||
|
|
||
| ```tsx | ||
| design: { | ||
| type: 'figma', | ||
| url: 'https://www.figma.com/file/ReGfRNillGABAj5SlITalN/%F0%9F%93%90-Gamut?node-id=993-0' | ||
| } | ||
|
|
||
| ``` | ||
|
Comment on lines
+61
to
+78
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was very confused about this section on first read because it's not about links. I realized part way through that it's about Storybook, not MDX or links. I'm also not too sure if we want this in our writing docs. It's more of a Gamut Storybook convention, which would be better to capture in code. For instance, maybe we could just make it required in the typing? interface GamutParameters extends Meta['parameters'] {
source: GamutSourceCode;
design: GamutDesignFile;
} |
||
|
|
||
| ## Link Text Guidelines | ||
|
|
||
| - 2-3 words minimum for easy clicking | ||
| - Unique link text when multiple links on page | ||
| - Meaningful and descriptive: conveys destination | ||
| - Action-oriented when appropriate: "View the component" | ||
|
Comment on lines
+80
to
+85
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why's this section separate from the first |
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@LinKCoding What do you think of the order of the sections? Would we want descending order based on priority? It looks like it's alphabetical in the left nav, and there's a mismatch between the left nav and when I'm on the About page.