-
Notifications
You must be signed in to change notification settings - Fork 25
[Docs] T-shirt/Spacing - Updated content for t-shirt sizing and layout and spacing #5521
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: master
Are you sure you want to change the base?
Conversation
This is a first draft. Images are still outdated.
❌ Deploy Preview for hpe-theme-preview failed. Why did it fail? →
|
❌ Deploy Preview for unrivaled-bublanina-3a9bae failed. Why did it fail? →
|
|
✅ Deploy Preview for hpe-design-icons-grommet ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| | `xlarge` | 1152px | `xxlarge` | 1024px | Value adjusted and renamed for clarity | | ||
| | `xxlarge` | 1536px | `3xlarge` | 1536px | Renamed for clarity | | ||
|
|
||
| #### Radius |
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.
Radius looks misaligned to actual v6 and v7 values:
Useful links:
Migrating from HPE Theme 6.x to 7.x
All design tokens
grommet-theme-hpe v6.5.1
grommet-theme-hpe v7.0.2
v6 values (from the grommet-theme-hpe v6.5.1)
radius: {
none: '0px',
hair: '1px', // for Chart
xxsmall: ${baseSpacing / 8}px, // 3
xsmall: ${baseSpacing / 4}px, // 6
small: ${baseSpacing / 2}px, // 12
medium: ${baseSpacing}px, // 24
large: ${baseSpacing * 2}px, // 48
xlarge: ${baseSpacing * 4}px, // 96
responsiveBreakpoint: 'small',
v7
hpe.radius.none: {0px}
hpe.radius.hair: {1px}
hpe.radius.xxsmall: {4px}
hpe.radius.xsmall {6px}
hpe.radius.small: {8px}
hpe.radius.medium: {12px}
hpe.radius.large: {16px}
hpe.radius.xlarge: {24px}
hpe.radius.xxlarge: {32px}
hpe.radius.full: {9999px}
| </ContentPane> | ||
|
|
||
| ## Responsiveness | ||
| ## Versioning |
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.
Content seems to be mixing platform-agnostic design tokens with implementation-specific versioning (Grommet). This will confuse a non-Grommet user.
Should it even be on this page, can we not link to the migration guide? While it's critical for developers migrating from the v6 to v7 theme, it's possibly noisy for everyone else.
If this content needs to stay on this page, suggest the following headings instead:
New headings:
Grommet implementation details
Grommet-theme-hpe v7
About v6
v6 -> v7 migration mappings
Grommet-theme-hpe migration details
Old and new together:
Versioning becomes -> Grommet implementation details
Current version: v7 becomes -> Grommet-theme-hpe v7
About v6 (stays the same)
v6 -> v7 Migration mappings (stays the same)
Migration guide becomes -> Grommet-theme-hpe migration details
This will contain migration information so non-grommet users know to skip it. The current versioning heading seems too generic and implies it's about the design systems own versions.
cc: @jcfilben @halocline
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.
Great point! I think it would be helpful to include a brief snippet of information on the website and then link to the migration guides for more details. I completely agree that we need clearer wording to distinguish what is Grommet versus non-Grommet. How can we best explain this difference for users who aren’t familiar with Grommet?
For example, is there a distinction between token versions that we could leverage instead of referring only to grommet versions?
I’m also on the fence about including all these migration tables here, since much of this information already exists in the migration guide.
Curious to hear what @halocline @jcfilben think
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.
I don't think versioning is appropriate here. Design tokens documentation should be treated as a reference guides.
We can cross link from the "scale system" documentation.
We may choose to add a feature which allows a user to look up design token values based on a theme version, but for now they should present the latest version.
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.
yes @halocline I see your point - and agree. However for this phase of the restructure we are trying to not create new pages but rather move content around (so we are able to expedite the process of landmark-related content) and the versioning was part of the latest iteration of the t-shirt sizing page. For now, where do you think this info should leave?
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.
Offline discussion between myself and @julauxen: Concern of scope creep due to learning curve regarding creating new pages. @halocline will contribute new pages to address scope creep concern. @julauxen will source images for new pages' navigational cards.
| <Image src="/box-sizing.png" alt="Demonstration of t-shirt sizing on Box" /> | ||
| </Box> | ||
|
|
||
| ## Spacing |
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.
Think this content was removed from the Spacing and Layout page, but was never added to the Foundations /T shirt sizing page:
Spacing uses proximity principles to define relationships between content and create hierarchy within a page. Spacing design tokens define the padding within, margin around, or gap between content.
Spacing guides users’ eyes through the page, helping them understand the relationships between different elements. The HPE Design System minimizes use of borders to separate content. Instead spacing, typography, and background color are combined to create visual hierarchy
@julauxen Do you feel we should add this back, or was it intentionally removed?
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.
I think this should be moved to a dedicated "Spacing" page and agree that this content is valuable. These pages are about explanation.
https://hpe.atlassian.net/wiki/spaces/DS/pages/3944973461/DRAFT+Spacing+sizes
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.
I am happy to put back the content in here. When it comes to dividing the content, that would be a second round of work. For this PR we are trying to rearrange the content between t-shirt sizing and layout and spacing. In the future, I do plan to break down the content and rewrite what's necessary (which will take more time). Would you be happy for this to be a next step @halocline?
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.
Co-authored-by: oliverHPE <[email protected]>
Co-authored-by: oliverHPE <[email protected]>
| import { SpacingBestPractices } from '../../examples'; | ||
|
|
||
| The proximity and grouping of elements establish a clear content hierarchy that facilitates a user in accomplishing their goals, free of distraction. | ||
| Layout and spacing tokens define the dimensional foundation for building consistent interfaces. These tokens control container sizes, spacing, corner radius, and border widths. |
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.
| Layout and spacing tokens define the dimensional foundation for building consistent interfaces. These tokens control container sizes, spacing, corner radius, and border widths. | |
| Layout and spacing tokens define the dimensional foundation for building consistent interfaces. These tokens control [container sizes](#containers), [spacing](#spacing), [corner radius](#radius), and [border widths](#border-width). |
| Container tokens are particularly useful when defining grid layouts. In other cases, consider the approach of [content-driven layouts](/templates/content-layouts#content-driven-layouts) to avoid artificially restricting content. | ||
|
|
||
| There are 11 container tokens to provide flexibility to cater to various design needs. | ||
| Container tokens define `width` and `height` dimensions for components such as [Box](/components/box). |
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.
| Container tokens define `width` and `height` dimensions for components such as [Box](/components/box). | |
| Container design tokens specify the minimum, maximum, or fixed height and width of [content areas](insert cross-link to content container sizing). |
| </Example> | ||
| </BestPracticeGroup> | ||
|
|
||
| ## Borders |
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.
This should be part of the "Container sizes" page.
|
|
||
| Use container size tokens for width and height constraints to preserve responsive flow. Avoid over‑constraining; prefer [content-driven layouts](/templates/content-layouts#content-driven-layouts). | ||
|
|
||
| ## Radius |
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.
Move to "Container sizes" page.
|
|
||
| Apply larger radius tokens to high‑level sections and smaller radii to inner elements to maintain visual hierarchy. | ||
|
|
||
| ## Default Size |
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.
Move to "Component sizing" page.
| <ButtonSizingExample /> | ||
| </Example> | ||
|
|
||
| ## Responsiveness |
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.
Probably deserves to be a dedicated page.
Co-authored-by: oliverHPE <[email protected]>
Co-authored-by: Matthew Glissmann <[email protected]>
Co-authored-by: Matthew Glissmann <[email protected]>
Co-authored-by: Matthew Glissmann <[email protected]>
Co-authored-by: Matthew Glissmann <[email protected]>
Co-authored-by: Matthew Glissmann <[email protected]>
…ign-system into layout-content-2
* fixed sortByCardOrder when cardOrder undefined * Added scale system navigational card * Added textual content to Scale system page * added composable scale diagram * trigger feature branch deploy * trigger feature branch deploy * yarn.lock * convert typescript to javascript * Refined principles wording. * Content refinements. * fixed typo * Update aries-site/src/pages/foundation/scale-system.mdx Co-authored-by: julauxen <[email protected]> --------- Co-authored-by: julauxen <[email protected]>
Deploy Preview
What does this PR do?
Updates both the t-shirt sizes page under foundations and layout and spacing under design tokens.
Where should the reviewer start?
What testing has been done on this PR?
In addition to the feature you are implementing, have you checked the following:
General UX Checks
Accessibility Checks
Code Quality Checks
How should this be manually tested?
Any background context you want to provide?
What are the relevant issues?
Screenshots (if appropriate)
Should this PR be mentioned in Design System updates?
Is this change backwards compatible or is it a breaking change?