commit 0730557624a28835a85eec44e1d2a513e6961546 Author: claude Date: Thu Jul 30 08:34:50 2026 -0400 Initial mirror of the HPE Design System Readable mirror of https://design-system.hpe.design, sourced from github.com/grommet/hpe-design-system (Apache-2.0) at commit 567c4d5 (2026-07-16). The upstream site is a client-rendered Next.js export with no sitemap; it returns a 1.5 KB empty shell to curl. This repo is the same guidance in plain Markdown with every value resolved, plus the assets checked in. Docs: scope and authority model, brand foundations with resolved color and spacing tables, the design token tiers and version map, UI copy rules, accessibility conformance and the responsibility split, the component and template inventory, and an adoption/review checklist. Assets: 452 SVG icons, 5 HPE and Aruba word-marks, 282 documentation graphics. HOWTO-mirror-the-design-system.md is a verified runbook for rebuilding this from scratch against a newer upstream. Colors were resolved programmatically, not transcribed: token JSON stores references, not values. Apache-2.0 upstream. Note that it covers copyright, not trademark; Brand Central remains authoritative for the HPE marks. diff --git a/01-what-it-is.md b/01-what-it-is.md new file mode 100644 index 0000000..52913b8 --- /dev/null +++ b/01-what-it-is.md @@ -0,0 +1,112 @@ +# 01 — What the HPE Design System is + +## The short version + +An open-source library of UI components, design tokens, page templates, and +written guidance, published so that HPE software looks and reads like one +company. It is maintained in public on GitHub and documented at +`design-system.hpe.design`. + +It is built on Grommet, a React component library. HPE's brand styling is +applied to Grommet through a theme package, and the same styling is published +separately as tech-agnostic design tokens for teams that do not use React. + +## What ships + +Everything lives in one pnpm monorepo, `grommet/hpe-design-system`, under the +Apache-2.0 license. Published artifacts as of 2026-07-30: + +| Package | Version | What it is | +| --- | --- | --- | +| `hpe-design-tokens` | 2.2.3 | The design tokens, in multiple output formats | +| `@hpe-design/icons-grommet` | 1.2.0 | The HPE icon set as React components | +| `@hpe-design/icons-svg` | 0.2.0 | The same icons as raw SVG | +| `hpe-design-system-codemods` | 0.2.1 | Automated migrations between versions | + +Two related packages live outside this repo: + +- `grommet` — the underlying component library (v2, `v2.grommet.io`) +- `grommet-theme-hpe` — the HPE theme for Grommet + (`github.com/grommet/grommet-theme-hpe`) + +The pairing matters: `grommet-theme-hpe` v8.x carries `hpe-design-tokens` v2. +See `03-design-tokens.md` for the full version map. + +## What the documentation site contains + +Doc page counts, read from the repo on 2026-07-30: + +| Area | Pages | Purpose | +| --- | --- | --- | +| `foundation/` | 20 | Brand, color, typography, spacing, icons, accessibility, voice and tone | +| `design-tokens/` | 11 | Token model, naming, versioning, consumption | +| `components/` | 48 | One page per component, plus an `all-components` index | +| `templates/` | 27 | Multi-component patterns (dashboards, wizards, forms, navigation) | +| `learn/` | 4 | Tutorials (grid fundamentals, the box model, toolbar and datatable how-tos) | + +The site is a Next.js static export hosted on Netlify. It renders entirely in +the browser, publishes no sitemap, and returns 404 on `robots.txt`. Fetching a +page with `curl` gets you a 1.5 KB shell and no content. To read it +programmatically, read the MDX in the GitHub repo instead. + +## The stated philosophy + +Three pillars, quoted from `foundation/philosophy-and-principles`: + +- Human-centered design +- A common design language +- Collaboration and community + +Four design principles, each with concrete sub-rules on the page: + +1. **Focus on the experience.** Consider the use cases; simplify end to end. +2. **Simplify.** Reduce visual and cognitive overload; understand why each + element is needed. +3. **Be intuitive.** Use common UI paradigms and consistent terminology; make + designs self-documenting so users do not need the help docs. +4. **Lead people to success.** Show only choices that apply to the current + context; order fields most-common-first; reveal fields only when they apply; + add safeguards against destructive mistakes. + +The principles page states they apply to "anyone authoring or authorizing any +form of design on behalf of HPE," which includes people who are not designers. + +## Authoritative vs advisory + +This distinction comes up in reviews, so it is worth being precise. + +- **Brand Central** (`brandcentral.hpe.com`) owns the corporate brand: logo + files, logo usage rules, the master color specification, typography files, + photography. Logo usage is governed by the HPE Terms of Use. +- **The Design System** owns the digital product expression of that brand. It + says explicitly that its "color palette and guidance differ from Brand + Central," that the difference is deliberate, that it was made in partnership + with HPE Brand, and that product teams should "prioritize the HPE Design + System palette when selecting colors for app or web experiences." + +So for a shipping software UI, the Design System is the operative reference. +For a logo lockup, a printed asset, or anything marketing-facing, Brand Central +governs. + +## How to get help or contribute + +- Slack channel `#hpe-design-system`, on both `grommet.slack.com` (public + Grommet workspace) and the HPE enterprise Slack. +- Designers request access to the HPE Design System Figma team by creating a + Figma account with an HPE email address, then requesting to join the team + from the HPE icon in the Figma sidebar. +- The repo carries a `knowledge/` directory it describes as "the AI-first + knowledge system for the HPE Design System": agent orchestrators for + contributing to the design system itself. Six capabilities are listed + (docs refactor, component creation, pattern creation, design-tokens + publishing, package release, alignment audit), but only **docs-refactor** is + marked active. The rest are planned stubs. + +## Open questions + +- Is `grommet.slack.com` reachable from an HPE account without a separate + signup, or is the HPE enterprise Slack channel the practical route? +- Does the design system team take intake from product teams for new + components, and what is the lead time? +- Who owns the design system inside HPE (which org, which VP)? The docs name a + Slack channel but no owning organization. diff --git a/02-brand-foundations.md b/02-brand-foundations.md new file mode 100644 index 0000000..2a5069f --- /dev/null +++ b/02-brand-foundations.md @@ -0,0 +1,217 @@ +# 02 — Brand foundations + +Concrete values, so a review question can be settled without opening the site. + +## Logo and the Element + +HPE has two marks that matter for software. + +**The HPE logo** (the full word-mark) is for establishing the brand in layouts +with less dense content. Place it top-left or bottom-left. The docs state +neither placement is preferred over the other. + +**The Element** (the green symbol alone) is the one that governs product UI: + +> Always use the HPE Element at the top-left of your service or product +> experience. To ensure consistency across HPE, the Element should always be +> accompanied by the company name and product/service name. Do not veer from +> the layout and spacing of the elements. + +Three rules fall out of that, and they are the ones a product UI most often +breaks: + +1. Element top-left, not centered, not right. +2. Element alone is not enough. Company name plus product name must appear + with it. +3. The lockup spacing is fixed. Do not re-space it. + +Both marks have a positive and a reversed (dark background) variant: +`HPE_logo_full-clr_pos_rgb.svg` and `HPE_logo_full-clr_rev_rgb.svg`. + +All brand element usage is subject to the HPE Terms of Use. Logo files and the +full usage rules are on Brand Central, not in the design system. + +HPE Aruba Networking has its own word-mark rules, also on Brand Central. + +## HPE GreenLake badge: retired + +As of the current docs, the existing HPE GreenLake badge is **retired and must +not be added to any new material**. GreenLake is described as launching a new +brand "later this year" with a new logo, visual identity, messaging, and naming +updates. Until then, existing GreenLake materials are frozen: make no changes. + +This is a live constraint. Any new UI that would have carried a GreenLake badge +should not add one. + +## Color + +### The rule + +Do not put hex values in a product UI. Apply semantic tokens. The docs give +four reasons, and they are all practical rather than stylistic: + +- Alignment with the current theme, which changes without your involvement +- Accessibility contrast is already solved in the token pairs +- Light and dark mode switching works for free +- A theme update propagates by version bump instead of a find-and-replace + +### HPE green + +The brand green is primitive token `base.color.green.600`, value **`#01a982`**. +Its semantic name is `color.decorative.brand`. That is the green people mean +when they say "HPE green." + +Note that the *brand* green is not the *primary action* green. Interactive +primary surfaces use a darker value in light mode and a brighter one in dark +mode, for contrast reasons: + +| Purpose | Light mode | Dark mode | +| --- | --- | --- | +| `color.decorative.brand` | `green.600` `#01a982` | `green.600` `#01a982` | +| `color.background.primary.strong` (rest) | `green.700` `#068667` | `green.550` `#05cc93` | +| `color.background.primary.strong` (hover) | `green.800` `#006750` | `green.500` `#00e0af` | +| `color.text.primary` / `color.icon.primary` | `green.800` `#006750` | `green.550` `#05cc93` | + +The full green ramp: 100 `#d1ffee`, 125 `#aafade`, 400 `#00e0af`, 450 `#66ebcf`, +500 `#00e0af`, 550 `#05cc93`, 600 `#01a982`, 650 `#009a71`, 700 `#068667`, +800 `#006750`, 900 `#074738`, 1000 `#093d32`. + +### Surface and text values + +| Token | Light | Dark | +| --- | --- | --- | +| `color.background.back` | `#f7f7f7` | `#1d1f27` | +| `color.background.front` | `#ffffff` | `#292d3a` | +| `color.background.floating` | `#ffffff` | `#22252e` | +| `color.text.default` | `#3e4550` | `#e6e8e9` | +| `color.text.strong` / `color.text.heading` | `#292d3a` | `#ffffff` | +| `color.text.weak` | `#606a70` | `#b1b9be` | +| `color.border.default` | `#b1b9be` | white at 36% opacity | + +Layering convention: start a product on `background.back`, layer surfaces with +`background.front`, and use `background.floating` for elevated surfaces. Prefer +a contrast background over a border when separating dense regions, because a +border adds visual noise that a background change does not. + +`color.background.screenOverlay` dims inactive content behind a center layer, +side drawer, or dialog. + +### The eight color families + +Background, border, text, icon, decorative, data visualization, foreground, +status. Each has a defined job: + +- **Decorative** carries brand and accent but never status. Do not substitute a + decorative color for a status color. +- **Data visualization** is a categorical palette built to be distinguishable + and colorblind-friendly. Use it in series order, starting at the first token. + Consolidate thin series into an "other" bucket with drill-down rather than + extending the palette. +- **Foreground** fills quantitative regions: meters, progress bars, indicators. +- **Status** covers critical, warning, ok, informational, unknown. Use it only + where it carries meaning, and always pair it with an icon or a label. + +### Two accessibility rules on color + +1. **Pairing.** Strong background colors require the `onStrong` text and icon + tokens. Getting this wrong is the most common contrast failure. +2. **Never color alone.** Anything conveyed by color must also be conveyed by a + text label, an icon, a pattern, or an underline. + +## Typography + +The typeface is **HPE Graphik**, with **GraphikXXCondensed** as a condensed +companion. Digital experiences use Light, Regular, Medium, Semibold, and Bold. + +Weight tokens: thin 100, light 300, regular 400, medium 500, semibold 600, +bold 700, black 900. + +### Font delivery + +Point at the web-hosted fonts so users get the current version. The CDN base is +`https://www.hpe.com/content/dam/hpe/fonts/graphik/`, with files like +`HPEGraphik-Regular-Web.woff2`, `-Medium-`, `-Semibold-`, `-Bold-`, +`-Extralight-`. + +Grommet teams get these URLs from `grommet-theme-hpe` already. Non-Grommet +teams copy the `@font-face` block from the typography page. Offline or desktop +use requires downloading OTF or web files from Brand Central. + +### Heading rules + +Headings use `rem` units so they scale with the browser's font setting. + +The rule that gets broken: **pick the heading level for semantics, pick the +token for size.** Never demote an `

` to an `

` because you wanted +smaller text. Apply a heading token instead. + +``` +Correct:

Card title

+Incorrect:

Card title

(to get the size) +``` + +Levels beyond 3 are described as rarely needed and a signal the content is too +dense. Before reaching for h4 through h6, reorganize. + +Paragraphs differ from plain text in that they carry a `maxWidth`, which caps +line length for readability. Use the `maxWidth` token that matches the text +t-shirt size. + +## Spacing + +Spacing is a subset of the scale system, expressed as t-shirt sizes. The +resolved pixel values: + +| Token | px | Token | px | +| --- | --- | --- | --- | +| `hair` | 1 | `small` | 16 | +| `6xsmall` | 2 | `medium` | 24 | +| `5xsmall` | 3 | `large` | 32 | +| `4xsmall` | 4 | `xlarge` | 48 | +| `3xsmall` | 6 | `xxlarge` | 64 | +| `xxsmall` | 8 | `3xlarge` | 96 | +| `xsmall` | 12 | | | + +Three rules: + +1. **Spacing tokens are for layout, not elements.** Use them on cards, layers, + grids. For element-level components use component tokens or element tokens, + which size correctly across screen sizes. +2. **Use gap and padding. Avoid margin.** Margin produces unpredictable + responsive behavior. +3. **Prefer spacing over borders.** The system deliberately minimizes borders, + building hierarchy from spacing, typography, and background color instead. + +## Icons + +Icons ship as `@hpe-design/icons-grommet` (React) and `@hpe-design/icons-svg`. +There is an interactive Storybook at `hpe-design-icons-grommet.netlify.app` and +a Figma production file. A migration guide covers moving from `grommet-icons` +to the HPE set. + +Usage rules: + +- Universal symbols (search, delete, close) can stand alone. Anything less + common needs a label. +- If an icon always needs a label to be understood, drop the icon and use text. +- Never use the same symbol for different meanings across products. +- Default size is medium; sizes align to the typography scale. When inline with + text, set `height` to match the text size prop. +- Default color token is `icon-default`. Emphasis variants: `icon-strong`, + `icon-weak`, `icon-disabled`, `icon-primary`. +- Brand or third-party SVGs keep their native colors via `color="plain"`. +- Status icons are reserved for system health. Do not use them decoratively. +- Every icon carries an `aria-label`; override it with `a11yTitle`. Purely + decorative icons need `aria-hidden` so screen readers skip them. + +The icon library is semantically named and carries metadata, so search by +intent rather than by shape. + +## Open questions + +- What is the full `onStrong` token set, and is there a published contrast + matrix, or is pairing verified per-case? +- Are the data visualization palette values fixed across theme versions, or do + they shift on a major bump? A shift would break saved dashboards. +- Does HPE Graphik cover the character sets needed for the languages HPE + products ship in, or is there a fallback stack for CJK and Cyrillic? diff --git a/03-design-tokens.md b/03-design-tokens.md new file mode 100644 index 0000000..e28c99d --- /dev/null +++ b/03-design-tokens.md @@ -0,0 +1,168 @@ +# 03 — Design tokens + +Design tokens are the delivery mechanism for HPE's visual style. They are the +reason a product can adopt a brand refresh with a version bump instead of a +redesign, and they are the answer to "how do we do this without React." + +## What a token is + +A named value carrying its intended usage. Four properties, two required: + +| Property | Required | Example | +| --- | --- | --- | +| Name | yes | `hpe.color.background.back` | +| Value | yes | `#f7f7f7` | +| Type | no | color, dimension, shadow | +| Description | no | how the token should be used | + +The point is that consumers reference the **name**, never the value. When HPE +updates the value, every consumer pointing at the name picks it up on upgrade. + +## The three tiers + +Tokens are layered by specificity. The rule for consuming them: + +> Begin with the most specific token level available. Look first to see if a +> component token exists. If not available, use semantic tokens as a fallback. + +### Primitive + +The raw palette. Names describe the value, not where to use it. Values are +always concrete CSS values: a hex code, a pixel, a rem. + +``` +hpe.base.color.green.600 → #01a982 +hpe.base.dimension.400 → 16 +``` + +**Primitive tokens must not be used directly in a product.** They exist to be +referenced by the tiers above. + +### Semantic + +Names say when and where to apply. Values reference a primitive or another +semantic token. + +``` +hpe.color.background.back → {base.color.grey.50} in light, {base.color.grey.1300} in dark +hpe.spacing.large → differs by viewport width +``` + +This is where context-dependence lives. One semantic name resolves to different +values in light versus dark mode, or wide versus narrow viewport. That is the +whole mechanism behind free dark mode. + +### Component + +Decisions for a single component or a family. Values reference any lower tier. + +``` +hpe.button.primary.rest.background +``` + +Component tokens encode state (rest, hover, active, disabled, focus) as part of +the name. See the site's `design-tokens/component-states` page for the state +model. + +## Token file layout in the repo + +`packages/hpe-design-tokens/tokens/`: + +- `primitive/` — `primitives.default.json`, plus pinned `.v0` and `.v1` files +- `semantic/` — `color.light.json`, `color.dark.json`, `dimension.default.json`, + `dimension.small.json`, `global.default.json`, plus `.v0` and `.v1` variants +- `component/` — `component.default.json`, `element.default.json`, plus variants + +Two things to notice. First, the old major versions are kept in-tree rather than +only in git history, which is what makes opt-in-by-mode work in Figma. Second, +`dimension.small.json` alongside `dimension.default.json` is the responsive +mechanism: the same semantic dimension name resolves smaller on narrow +viewports. + +There is also a `deprecated.*` namespace inside the primitives, which is where +superseded values go. `deprecated.base.color.green.400` is `#17eba0` where the +live `base.color.green.400` is `#00e0af`, so a stale reference will render a +visibly different green. + +## Versioning + +`hpe-design-tokens` follows semver with one adaptation: **a major version can be +triggered by a brand change alone**, with no API break. + +| Increment | Trigger | +| --- | --- | +| MAJOR | Significant change to HPE's brand expression, or an incompatible API change | +| MINOR | New token, or a small expected value change (darkening a text color after user testing) | +| PATCH | Backward-compatible fix (a typo in a value, a color corrected to meet contrast) | + +The reason a brand change alone forces a major: if service A is on v1 and +service B is on v2, the two will not look like the same company. The major +version is the signal that a mismatch exists. + +### Version map + +| Tokens | Theme | Period | Notes | +| --- | --- | --- | --- | +| `^2.0.0` "v2-Landmark" | `grommet-theme-hpe` 8.x | Oct 2025 to present | Landmark palette, HPE Graphik font face. Default in the Figma V2 library. Current release 2.2.3 | +| `^1.0.0` | `grommet-theme-hpe` 6.x–7.x | Feb 2025 to Sep 2025 | Opt-in via "v1" modes in Figma | +| `^0.9.0` | `grommet-theme-hpe` 5.x | May 2023 to Jan 2025 | Opt-in via "v0" modes in Figma | + +v2-Landmark is a breaking change from v1. Migration guides live in the GitHub +wikis for both `hpe-design-system` and `grommet-theme-hpe`. + +v0.9.0 to v1.0.0 had **no breaking API changes in the tokens** (only value +changes), but `grommet-theme-hpe` v5 to v7 did break, and the migration is +documented in two steps: 5.x to 6.x for visual treatments, then 6.x to 7.x for +expanded t-shirt sizing. + +### The recommended adoption trick + +For a product adopting tokens for the first time, the docs recommend mapping +local components to **v0.9.0 tokens first**. That reaches style parity with the +product's existing look, so QA is comparing against something familiar and any +diff is a real bug rather than an intended restyle. Only then upgrade forward. + +This is worth remembering. It converts one large risky change into two smaller +ones with a verifiable checkpoint between them. + +## Consuming tokens + +- **React plus Grommet:** install `grommet-theme-hpe`. Tokens, fonts, and + component defaults come with it. This is the environment the design system + targets and the one with the most examples. +- **Anything else:** consume `hpe-design-tokens` directly. It is published to + npm in multiple output formats and is tech-agnostic. The site page + `design-tokens/using-design-tokens-in-code` covers the formats. +- **Figma:** tokens appear as Figma variables. `design-tokens/using-design- + tokens-in-figma` covers setup, and the "Themes and modes" Figma file covers + switching between v0, v1, and v2 modes. + +The tokens are built with Style Dictionary. The repo has custom transforms and +formats under `packages/hpe-design-tokens/src/`, plus a +`apps/design-tokens-manager` application and a `contracts/schemas` directory +that validates token structure. + +### A detail worth knowing about units + +Dimension primitives are stored as **unitless numbers** (`base.dimension.400` is +the number `16`, not `"16px"`). The `numberToDimension` transform assigns units +at build time, and it does not treat them all the same: + +- `fontSize` and `lineHeight` are divided by 16 and emitted as **`rem`** +- everything else (spacing, radius, padding, width, height, border width, + breakpoints) is emitted as **`px`** + +So type scales with the user's browser font setting and layout does not. If you +read a raw token JSON value and see a bare number, that is why. + +`hpe-design-system-codemods` (v0.2.1) automates some migration edits. + +## Open questions + +- Which output formats does `hpe-design-tokens` actually publish (CSS custom + properties, SCSS, JSON, Swift, XML)? Read the package before promising a + non-web team it is covered. +- Is there a deprecation policy with a stated support window for a major + version, or does an old major just stop receiving fixes? +- How long did a real product take to migrate v1 to v2-Landmark? A worked + example would size the effort better than the migration guide does. diff --git a/04-voice-and-tone.md b/04-voice-and-tone.md new file mode 100644 index 0000000..eefeb76 --- /dev/null +++ b/04-voice-and-tone.md @@ -0,0 +1,186 @@ +# 04 — Voice and tone for UI strings + +Scope note: these are HPE's rules for **text inside a product UI**: labels, +buttons, error messages, notifications, help text, empty states. They are not +the rules for prose in this repo. See the note at the end. + +The source page (`foundation/voice-and-tone`) is by far the largest doc on the +site at roughly 55 KB, which is a signal in itself. HPE treats UI copy as a +design surface, not an afterthought. + +## Capitalization + +Five capitalization styles exist. HPE uses one of them for almost everything. + +**Sentence case is the default.** First letter capitalized, everything else +lowercase except proper nouns. Applied to: attribute labels, column headings, +legends, tabs, menus, paragraphs, tips, notifications, help, page titles, +dialog titles, section and subsection headings, and buttons. + +Two hard prohibitions: + +- **Never begin a sentence or phrase with a lowercase letter.** Too casual for + the brand. +- **Never use all caps.** It reads as yelling and increases user stress. + +**Title case is only for** the title of an event, program, or website, and for +proper nouns. HPE brand and product names are proper nouns. + +### The button exception + +Buttons take sentence case **except** those ending in one of these short +prepositions: `at, by, for, in, of, off, on, out, to, up`. Those get the +preposition capitalized. + +``` +Correct: Sign Up +Incorrect: Sign up +``` + +This one is counterintuitive and easy to get wrong in review, so it is worth +quoting verbatim when it comes up. + +### Do not promote common nouns + +The docs are direct about this: "Fight the urge to elevate normal nouns to +proper noun status." On a "data sources" page, write *data sources*, not +*Data Sources*, unless it is genuinely a proper noun. + +### Referring to UI elements + +When you describe an action generally, use lowercase. When you name a specific +button or page, match that element's actual case. + +- General action: "To create a data fabric you must first create a new cluster." +- Specific page: "First, go to the *Create a New Cluster* page to create a data + fabric." + +## Acronyms + +The stated position is that acronyms are exclusionary. They create an insider +language and force everyone else to decode before they comprehend. + +Two conditions, both required: + +1. Define it on first use. +2. Only use the acronym at all if it appears **multiple times** in the message. + +The worked example is unusually strict, so here it is in full: + +- Incorrect: *The UBC is meeting tomorrow.* +- Incorrect: *The UBC (University Building Council) is meeting tomorrow.* +- Incorrect: *The University Building Council (UBC) is meeting tomorrow.* +- Correct: *The University Building Council (UBC) is meeting tomorrow. If you + have UBC-related business, send it to the UBC administrator for addition to + the meeting agenda.* + +The third one is incorrect because the acronym is introduced and then never +used again. Expanding it earns nothing. + +## Product names + +Do not use full brand and product names in running messages. Set context once, +then shorten. The docs' own example: *HPE GreenLake Lighthouse* is a mouthful, +so use *Lighthouse* on second and subsequent references. + +## Point of view + +Three options, with the effect of each spelled out: + +- First person: "We noticed the server is malfunctioning." +- Second person: "Your server is malfunctioning." +- Third person: "The server is malfunctioning." (focus on neither writer nor + reader) + +The page presents these as choices rather than mandating one, so pick by +context and stay consistent within a flow. + +## Do + +- Use articles ("a", "an", "the") so the text does not read like a robot. +- Punctuate every sentence, correctly, including internally. +- **Use contractions.** "you're", "we'll", "isn't". This is explicitly + encouraged for a conversational tone. +- Put adjectives before nouns: *the specified operation is*, not *the operation + specified is*. +- Order multiple adjectives correctly: opinion, size, age, shape, color, origin, + material, purpose, then noun. So *two failing SATA SSD drives*, never *SSD + SATA failing two drives*. + +## Do not + +These are the rules that most often catch real error strings: + +- **Do not blame the user.** Never say *bad request*. Explain what is wrong. +- **Do not hedge.** Never tell a user to *try* or *attempt* something; it does + not convey confidence. Write *Reset the interconnect*, not *Try resetting the + interconnect*. +- **Do not say "retry the operation"** in most cases. If the user entered an + illegal value, telling them to supply a correct one is enough. The retry is + obvious. +- **Never say "retry after some time."** Be specific: *after 3 minutes*, or + *after the refresh has completed*. +- **Do not refer to "the" or "your" administrator.** The person reading the + message usually is the administrator. Name the actual role or action. +- **Limit "please."** It is allowed, but starting every action phrase with it + is not appropriate. +- **Avoid possessives.** Not *the server hardware's power is off*. +- **No run-on sentences.** +- **No internal terminology in external messaging.** +- **Do not use a resource's name as an adjective.** Write *the uplink set "ABC" + has…*, not *the ABC uplink set has…*. +- **Avoid "input" as a noun in instructions.** Write *Specify a valid + certificate*, not *Specify a valid certificate as input*. Write *One of the + parameters is null*, not *One of the input parameters is null*. +- **Parentheses:** no spaces inside, spaces outside. *this is bad (yes it is)*. + The exception is constructions like *server(s)*. + +## Term list + +Spelling and capitalization that must be exact: + +`Kubernetes`, `Ethernet`, `Fibre Channel`, `FCoE`, `SNMP`, `SNMPv3`, +`ID` (not id or Id), `OK` (not ok, Ok, or okay), `I/O` (not IO or i/o), +`API` (not xApi). + +Word choices: + +| Do not write | Write | +| --- | --- | +| app | application | +| internal error | unexpected problem | +| & | and | + +Distinctions: + +- **"Log in"** is a verb: *Log in to the server*. +- **"Login"** is a noun or adjective: *The login token has expired*. +- **"Filesystem"** is one word. +- **"Host name"** is the name of a host. **"Hostname"** is the Unix command. + +## Do not apply these rules to documentation + +Worth stating, because it causes real friction: these rules are tuned for +**short strings inside a running product**. They are not a house style for +prose. + +If your team already has a writing standard for docs, specs, or release notes, +expect it to disagree with this page in places. HPE wants contractions and a +conversational register in UI text, mandates a specific capitalization scheme +for labels, and permits constructions (*please*, used sparingly) that a tighter +prose standard would cut. + +Neither set overrides the other, because they govern different artifacts. Apply +the one that matches what you are writing. A button label follows this page. A +design document does not have to. + +## Open questions + +- Is there an approved localization process for UI strings, and does the + sentence-case rule survive translation into languages with different + capitalization conventions? The site has an `internationalization` template + page that may answer this. +- Does HPE run a copy review gate before a product UI ships, or is voice and + tone self-policed by the product team? +- The term list is short and clearly grown by accretion. Is there a longer + internal HPE terminology database that supersedes it? diff --git a/05-accessibility.md b/05-accessibility.md new file mode 100644 index 0000000..0f5f459 --- /dev/null +++ b/05-accessibility.md @@ -0,0 +1,129 @@ +# 05 — Accessibility + +HPE's stated position, quoted: **"We believe that being accessible is a +requirement, not an option."** + +## The standard + +HPE aligns to **WCAG level A and AA**, and to the four core principles +(perceivable, operable, understandable, robust). The page states the level +plainly: "The guidelines identified as level A and AA are the required design +elements for all applications and are incorporated in the US Section 508 +standard and HPE's Design System." AAA is not required. + +One inconsistency to be aware of: the top of the page cites **WCAG 2.2**, while +the government standards section further down links and cites **WCAG 2.1**. The +level commitment (A and AA) is consistent across both; the version reference is +not. Assume 2.2 for new work, since that is what the normative statement at the +top of the page says, but expect to see 2.1 cited in older HPE material. + +Named regulatory drivers on the same page: **US Section 508**, the +**Americans with Disabilities Act**, and the **European Accessibility Act**. +The EAA is the one most likely to bite on a product sold into the EU. + +The scope the docs describe is broader than the usual reading of +"accessibility." It covers keyboard navigation, speech input, screen readers, +alternative input devices such as head pointers, screen magnification, and color +blindness, and it explicitly includes temporary and situational disability. The +figure cited is that about 25% of the United States population lives with some +type of disability, permanent or not, sourced to the CDC. + +## Who is responsible for what + +This is the part that decides arguments, so it is worth having straight. The +answer depends on whether you use Grommet plus the HPE theme or only the +tokens. + +| Consideration | Grommet + HPE theme | Design tokens only | +| --- | --- | --- | +| Color contrast ratios | Handled | You apply the color, pairing, and usage guidance yourself | +| Typography (legibility, scaling, line height) | Handled | You implement from the typography system | +| Component behavior (keyboard nav, ARIA, focus) | Handled | You implement accessible behavior manually | +| Focus styles and states | Handled | You implement from the component-states tokens | +| ARIA roles and attributes | Handled, but you supply context-specific values | Fully your responsibility | +| Responsiveness across breakpoints | Handled | You implement from layout and spacing tokens | +| Semantic HTML structure | Handled | You ensure correct structure | +| Alt text and descriptions | **Yours** | **Yours** | +| Labeling (forms, buttons, errors) | **Yours** | **Yours** | +| Readability of copy | **Yours** (follow voice and tone) | **Yours** | + +Two conclusions fall out of this table. + +First, **Grommet plus the HPE theme buys most of the mechanical accessibility +work.** That is the strongest practical argument for the React path, stronger +than the visual consistency argument. + +Second, **the bottom three rows are never bought.** Alt text, labels, and +readable copy are the product team's job under either path. A team that adopts +Grommet and then ships unlabeled icon buttons has not become accessible. + +## Design-time coverage + +Every component and asset in the HPE Design System Figma library is built on +design tokens that align with accessibility standards. Using the prebuilt +components or applying the tokens as Figma variables gets you WCAG-compliant +styles without doing contrast math. + +This is worth stating plainly to designers: the contrast work is already done +inside the token pairs, and it is undone the moment someone picks a custom +color off the Figma color wheel. + +## Testing + +### The rule that sets expectations + +**Automated testing tools catch approximately 30 to 50% of accessibility +violations.** Manual testing is not optional. Any plan that consists of "we run +axe in CI" covers at best half the problem. + +### Recommended practice + +- **Shift left.** Violations avoided at design time cost nothing to fix. +- **Try it yourself.** Turn the monitor off and use a screen reader. Unplug the + mouse. Use simulator tools for color blindness, dyslexia, and tunnel vision. +- **Test with real users with disabilities.** The docs name Bill Tipton of the + HPE Product Accessibility Office as an internal resource for usability + testing. He has used a screen reader daily since losing his eyesight in 1999. + +### Tooling + +CI and automation: + +- Lighthouse GitHub Action (the design system runs this on its own PRs) +- `axe-core` (React integration available) +- `axe-testcafe` + +Browser extensions: + +- axe DevTools +- Access Assistant (Level Access), which saves reports to track compliance over + time +- WAVE +- Lighthouse (built into Chrome DevTools) +- ANDI + +Simulators: + +- Silktide (color blindness, dyslexia, tunnel vision, cataracts, blindness) +- WebAIM Color Contrast Checker +- Colorblind Web Page Filter (Toptal) + +## Internal HPE resources + +The docs link to the **HPE Product Accessibility Program Office** on SharePoint, +which publishes designer and developer guides, and to **HPE Accessible Design +Training**, a set of videos under 10 minutes each with an accompanying "Pocket +Guide" of takeaways. Both are on `hpe.sharepoint.com` and need an HPE login. + +## Open questions + +- Is there a required accessibility sign-off before a product release, and who + gives it? The docs describe resources and advocacy, not a gate. +- Does HPE publish VPATs or ACRs per product, and who writes them? This matters + for public sector deals where an ACR is a procurement requirement. +- Is the operative version 2.1 or 2.2? The page cites both. Worth asking the + accessibility office which one an audit would be run against. +- Does the accessibility office have capacity to test every product, or is Bill + Tipton's availability the practical bottleneck? +- What is HPE's compliance deadline posture on the European Accessibility Act, + and does it change the priority of any of this? diff --git a/06-components-templates.md b/06-components-templates.md new file mode 100644 index 0000000..21df3f5 --- /dev/null +++ b/06-components-templates.md @@ -0,0 +1,136 @@ +# 06 — Components and templates + +Two layers with different jobs. Components are single UI elements. Templates +are compositions of components that solve a recurring product problem, with the +design decisions already made. + +The practical value of the template layer is that it settles arguments. When a +team debates how a wizard should behave or where a destructive confirmation +goes, there is an HPE answer already written down. + +## Components + +48 documented component pages, plus an `all-components` index. Grouped by what +they do: + +**Layout and structure** +`box`, `grid`, `page`, `main`, `header`, `footer`, `pageheader`, `toolbar`, +`layer` + +**Input** +`textinput`, `textarea`, `maskedinput`, `dateinput`, `fileinput`, `rangeinput`, +`search`, `select`, `selectmultiple`, `checkbox`, `checkboxgroup`, +`radiobuttongroup`, `togglegroup` + +**Action and navigation** +`button`, `anchor`, `menu`, `tabs`, `pagination` + +**Content display** +`card` (with `call-to-action-card` and `navigational-card` variants), +`accordion`, `avatar`, `namevaluelist`, `tag`, `tip` + +**Feedback and state** +`notification`, `spinner`, `skeleton` + +**Data** +This is the largest family and the one most relevant to any management or +operations UI: +`data`, `datatable`, `datatablecolumns`, `datatablegroupby`, `dataview`, +`datafilter`, `datafilters`, `datasearch`, `datasort`, `datasummary` + +The `data` component is the container that wires the others together, giving +you search, filter, sort, and summary against one dataset without hand-wiring +state. Worth knowing before anyone builds a filterable table from scratch. + +## Templates + +27 template pages covering 26 topics. + +**Navigation** (five separate patterns, each for a different information shape) +- `navigation` (the overview) +- `ascending-navigation` — moving up a hierarchy +- `drill-down-navigation` — moving down into detail +- `side-to-side-navigation` — moving between peers +- `matrix-navigation` — moving across two dimensions +- `global-header` + +**Layout** +- `page-layouts` +- `content-layouts` +- `dashboards` + +**Data interaction** +- `filtering` +- `lists` +- `selector` +- `datatable-customization` +- `scrolling-and-pagination` + +**Forms and flows** +- `forms`, with a sub-page on `managing-child-objects` +- `wizard` +- `double-confirmation` — the pattern for destructive actions +- `empty-state` + +**Notifications** (three placements, three different jobs) +- `global-notifications` — system-wide, persistent +- `inline-notifications` — attached to content +- `toast-notifications` — transient + +**Other** +- `status-indicator` +- `popover` +- `code-blocks` +- `internationalization` +- `user-feedback-collection` + +## Which layer to reach for + +The stated token rule applies here by analogy: **start with the most specific +thing that exists.** + +1. Is there a template for this problem? Use it. The composition decisions are + made. +2. No template but components exist? Compose them. +3. Neither? Build from tokens, and consider raising it in + `#hpe-design-system`, since a gap that affects you likely affects others. + +## Learn + +Four tutorials, aimed at people new to Grommet rather than at design decisions: + +- `grid-fundamentals-part-one` +- `the-box-model-part-one` +- `how-to-add-additional-controls-to-a-toolbar` +- `how-to-add-search-and-filter-to-datatable-with-data` + +The "part one" naming on two of them with no part two suggests this section was +started and not finished. Treat it as a bonus, not a curriculum. + +## Reading component docs without the website + +The site renders in the browser and returns no useful content to `curl`. To +read a component's guidance programmatically, go to the MDX source: + +``` +https://github.com/grommet/hpe-design-system + → apps/docs/src/pages/components/.mdx + → apps/docs/src/pages/templates/.mdx +``` + +Raw file access works over `raw.githubusercontent.com`. The MDX carries the +prose and the best-practice do/don't pairs; the live examples are React +components imported from `apps/docs/src/examples/`. + +Component API reference (props) lives on Grommet's own site, +`v2.grommet.io/?theme=hpe`, not in the design system docs. The +design system says *when and why*; Grommet says *what the props are*. + +## Open questions + +- How much of the component set is HPE-specific versus plain Grommet with a + theme applied? This decides how much of the Grommet ecosystem transfers. +- Are the data components performant at the row counts a real usage dashboard + needs, or do they assume paged server-side data? +- Is there a template for the case of an application embedded inside another + HPE console, where the global header is owned by the host? diff --git a/07-adoption-and-compliance.md b/07-adoption-and-compliance.md new file mode 100644 index 0000000..55c07ef --- /dev/null +++ b/07-adoption-and-compliance.md @@ -0,0 +1,144 @@ +# 07 — Adoption and compliance + +What it actually costs to align a product UI with the HPE Design System, and +how to check whether one is aligned. + +## Three adoption paths + +### 1. React plus Grommet plus `grommet-theme-hpe` + +The path the design system is built for. Install the theme and you inherit +colors, fonts, component defaults, keyboard navigation, ARIA support, focus +handling, and responsive behavior. + +Cost: highest if the product is not already React. Lowest ongoing cost after +that, because brand refreshes arrive as a version bump. + +This is the only path where the accessibility table in `05-accessibility.md` +reads "handled" down most of the column. + +### 2. `hpe-design-tokens` only + +For any other stack. Tokens are tech-agnostic and published to npm. You get the +correct colors, type, and spacing. You do not get component behavior. + +Cost: moderate to adopt, permanent to maintain. Every accessible behavior +(keyboard, ARIA, focus, semantic structure, responsiveness) is yours to build +and re-verify. + +The docs recommend mapping to **v0.9.0 tokens first** to reach parity with the +product's current look, verify against familiar styling, then upgrade forward. +That turns one risky change into two with a checkpoint between them. + +### 3. Reference only + +Read the guidance, match by eye, use the templates as design references. Fine +for a prototype or an internal tool. Not defensible for a customer-facing HPE +product, because the values drift the moment the brand moves and nothing +signals that they have. + +## Review checklist + +Usable as a gate in a design or code review. Every item traces to a rule in the +docs, cited to its doc here. + +**Brand marks** (`02`) +- [ ] HPE Element is present at top-left of the product experience +- [ ] Element is accompanied by the company name and the product or service name +- [ ] Lockup spacing and layout are unmodified +- [ ] No HPE GreenLake badge on new material (the existing badge is retired) +- [ ] Correct positive or reversed logo variant for the background + +**Color** (`02`) +- [ ] No raw hex values in the UI. Semantic or component tokens only +- [ ] Primitive tokens are not referenced directly +- [ ] Status colors used only where they carry meaning, never decoratively +- [ ] Strong backgrounds pair with `onStrong` text and icon tokens +- [ ] Nothing is conveyed by color alone. Every case has a label, icon, pattern, + or underline as well +- [ ] Data visualization series start at the first token and proceed in order + +**Typography** (`02`) +- [ ] HPE Graphik loaded from the HPE CDN, not bundled or substituted +- [ ] Heading levels chosen for semantics; size set by token, never by demoting + a heading level +- [ ] Heading hierarchy has no skipped levels +- [ ] Paragraphs carry the `maxWidth` for their t-shirt size +- [ ] Sizes in `rem` so browser font settings scale the UI + +**Layout** (`02`) +- [ ] Spacing comes from the scale, not arbitrary pixel values +- [ ] Spacing tokens used for layout; component or element tokens for elements +- [ ] Gap and padding, not margin +- [ ] Borders only where spacing and background contrast are insufficient + +**Copy** (`04`) +- [ ] Sentence case throughout, including labels, columns, tabs, menus, dialogs +- [ ] Buttons ending in a short preposition capitalize it ("Sign Up") +- [ ] No all caps anywhere +- [ ] No string begins with a lowercase letter +- [ ] Acronyms defined on first use, and only used if repeated +- [ ] Long product names shortened after first reference +- [ ] Error messages do not blame the user, do not say "try", do not say + "retry after some time" +- [ ] No references to "your administrator" +- [ ] Term list observed: application not app, ID, OK, I/O, "log in" vs "login" + +**Accessibility** (`05`) +- [ ] Keyboard navigation reaches and operates every control +- [ ] Focus is visible on every focusable element +- [ ] All images and media have descriptive alt text +- [ ] All form fields, buttons, and errors have meaningful labels +- [ ] Decorative icons carry `aria-hidden`; meaningful icons carry a label +- [ ] Automated scan clean (axe or Lighthouse) +- [ ] **Manual test performed.** Automated tools catch 30 to 50% of violations, + so a clean scan is a floor and not a pass + +**Version hygiene** (`03`) +- [ ] Token major version recorded, and known to match sibling products. Two + HPE products on different majors will not look like the same company +- [ ] No references into the `deprecated.*` token namespace + +## What compliance is worth arguing about + +Not every item above carries the same weight. Ranked by consequence: + +1. **Accessibility failures.** These can be procurement blockers, and in some + jurisdictions legal exposure. Everything else on the list is cosmetic by + comparison. +2. **Element and logo misuse.** Governed by the HPE Terms of Use, and the one + category where a brand team is likely to intervene directly. +3. **Hardcoded hex values.** Not visible to a customer today, but this is what + makes the next brand refresh expensive rather than free. The cost lands + later, which is why it gets waved through. +4. **Copy rules.** Cheap to fix, visible to customers, and the thing that most + often makes an acquired product feel un-HPE. +5. **Spacing and type scale drift.** Real but low-stakes individually. It + accumulates into a UI that looks off without anyone being able to say why. + +## Where an acquired product typically stands + +Worth setting expectations before scoping any alignment work. A product that +joined HPE through acquisition usually has: its own component library, its own +color constants in code, its own typeface, its own copy conventions, and no +token layer at all. The realistic sequence is tokens first (path 2), copy +second (cheap, high visibility), component migration last if ever. + +The full React migration is rarely justified on brand grounds alone. It is +justified when the accessibility column in `05-accessibility.md` becomes a +requirement, because that is where the "handled" entries are worth real +engineering months. + +## Open questions + +- Is there an HPE-internal alignment audit or scorecard that products are + measured against? Nothing public suggests one. The design system repo does + carry an `alignment-audit` entry in its `knowledge/` directory, but it is a + planned stub scoped to auditing the design system's own docs, tokens, and + components, not product teams. Do not cite it as evidence of a product gate. +- What is the expected timeline for products to reach v2-Landmark, and is there + a deadline attached? +- For an embedded or OEM UI, whose brand governs, and does the Element rule + still apply? +- Does any HPE release process actually check the items above, or is this a + self-assessment? diff --git a/HOWTO-mirror-the-design-system.md b/HOWTO-mirror-the-design-system.md new file mode 100644 index 0000000..63ec587 --- /dev/null +++ b/HOWTO-mirror-the-design-system.md @@ -0,0 +1,417 @@ +# How to mirror the HPE Design System + +A runbook for reproducing everything in this folder: the guidance docs, the +452-icon set, the brand marks, and all 282 documentation graphics. + +Written to be handed to someone else and followed start to finish, by a person +or by an AI coding agent. Every command below was run and verified on +2026-07-30. Nothing here needs an HPE login, a VPN, or a token. + +Total time: about ten minutes, most of it the clone. + +--- + +## The problem you will hit first + +`https://design-system.hpe.design` looks like a normal documentation site. It +is not scrapeable. + +It is a **Next.js static export that renders entirely in the browser**. Fetch +any page and you get a 1.5 KB HTML shell with zero content: + +```bash +curl -s https://design-system.hpe.design/foundation/color | wc -c +# 1540 +``` + +There is also no sitemap and no robots.txt. Both 404: + +```bash +curl -s -o /dev/null -w '%{http_code}\n' https://design-system.hpe.design/sitemap.xml # 404 +curl -s -o /dev/null -w '%{http_code}\n' https://design-system.hpe.design/robots.txt # 404 +``` + +The Next.js data endpoint does not help either. The pages are `autoExport` with +empty `pageProps`, so `/_next/data//.json` returns 404. The +content is compiled into JavaScript chunks. + +**Do not try to scrape the site.** Do not reach for a headless browser. There +is a much better source. + +## The key insight + +The whole design system is **open source**: + +> `https://github.com/grommet/hpe-design-system` — Apache-2.0 + +Every page on that site is an MDX file in that repo. The icons, the graphics, +and the raw design token JSON are in there too. Clone it and you have +everything, in a form that greps. + +Find it yourself with: + +```bash +curl -s "https://api.github.com/search/repositories?q=hpe-design-system" \ + | grep -E '"full_name"|"html_url"' +``` + +## Step 1 — Clone + +Shallow clone. Full history is not needed and is much larger. + +```bash +git clone --depth 1 https://github.com/grommet/hpe-design-system.git hpeds +cd hpeds +git log -1 --format='%H %cI %s' # record this SHA for provenance +du -sh . # ~81 MB +``` + +Record the commit SHA. Version numbers in the docs move; citing a SHA makes +your notes checkable later. The mirror in this folder was taken at +`567c4d5` (2026-07-16). + +Do **not** run `pnpm install`. Nothing here needs a build. + +## Step 2 — Know the layout + +``` +hpeds/ +├── apps/ +│ ├── docs/ +│ │ ├── src/pages/ <- ALL documentation content, as .mdx +│ │ └── public/ <- ALL graphics (282 files, 32 MB) +│ └── design-tokens-manager/ +├── packages/ +│ ├── hpe-design-tokens/ +│ │ └── tokens/ <- raw token JSON (primitive/semantic/component) +│ ├── icons-svg/src/icons/ <- 452 raw SVG icons +│ ├── icons-grommet/ <- the same icons as React components +│ └── codemods/ +├── knowledge/ <- their own AI agent capability bundles +└── LICENSE <- Apache-2.0 +``` + +Content page counts, so you know when you have it all: + +```bash +find apps/docs/src/pages -name '*.mdx' | wc -l # 112 +for d in foundation design-tokens components templates learn; do + printf '%-16s %s\n' "$d" "$(find apps/docs/src/pages/$d -name '*.mdx' | wc -l)" +done +# foundation 20 +# design-tokens 11 +# components 49 (48 component pages + an all-components index) +# templates 27 +# learn 4 +``` + +Those five directories account for 111. The 112th is `whats-new.mdx` at the +page root. Widening the search to `apps/docs -type f \( -name '*.mdx' -o -name +'*.md' \)` returns 117, because it picks up repo READMEs outside the page tree. +Use the narrower count when checking coverage. + +## Step 3 — Get the full route list + +Useful as a checklist to confirm you covered everything. The site is a Next.js +export, so its build manifest lists every route. + +The build ID changes on every redeploy, so extract it rather than hardcoding +it. Save as `routes.sh`: + +```bash +#!/usr/bin/env bash +# Extract every route from the HPE Design System site (Next.js static export). +set -euo pipefail +UA="Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0 Safari/537.36" +BASE="https://design-system.hpe.design" +BUILD_ID=$(curl -sS -A "$UA" "$BASE/" \ + | grep -oE '/_next/static/[A-Za-z0-9_-]{16,}/_buildManifest\.js' | head -1) +echo "buildManifest: $BUILD_ID" >&2 +curl -sS -A "$UA" "$BASE$BUILD_ID" \ + | tr ',' '\n' | grep -oE '"/[^"]*"' | tr -d '"' | sort -u +``` + +```bash +chmod +x routes.sh && ./routes.sh | wc -l # 123 +``` + +## Step 4 — Read the content + +The MDX files are prose plus JSX examples. Read the prose; the `` and +`` tags import React components from +`apps/docs/src/examples/` and can be ignored unless you need a rendered figure. + +Priority order, highest value first: + +| File | Why | +| --- | --- | +| `foundation/voice-and-tone.mdx` | 55 KB, the largest doc on the site. UI copy rules | +| `foundation/accessibility.mdx` | 18 KB. WCAG level, responsibility split table | +| `foundation/date-and-time.mdx` | 15 KB | +| `foundation/typography.mdx` | Font CDN URLs, heading rules | +| `foundation/color.mdx` | The eight color families and their jobs | +| `foundation/our-brand.mdx` | Logo and Element placement rules | +| `foundation/distinctive-brand-assets.mdx` | GreenLake badge status | +| `design-tokens/overview.mdx` | The three-tier token model | +| `design-tokens/versioning.mdx` | Version-to-theme map, migration paths | +| `foundation/philosophy-and-principles.mdx` | The three pillars, four principles | + +Sort the rest by size to prioritize: + +```bash +wc -c apps/docs/src/pages/foundation/*.mdx apps/docs/src/pages/design-tokens/*.mdx | sort -n +``` + +Raw single-file access without cloning, if you only want one page: + +``` +https://raw.githubusercontent.com/grommet/hpe-design-system/master/apps/docs/src/pages/foundation/color.mdx +``` + +## Step 5 — Resolve design tokens to real values + +This is the part worth automating, and the part most likely to be got wrong. + +**Token JSON does not contain values.** It contains references. A semantic token +points at a primitive, which may point at another primitive. Reading +`color.light.json` directly gives you `{base.color.grey.50}`, not `#f7f7f7`. + +Two more traps: + +1. Semantic tokens carry a `.REST` suffix on the leaf that references often + omit, so a naive lookup misses. +2. There is a `deprecated.*` namespace holding superseded values. A stale + reference resolves to a visibly different color: + `deprecated.base.color.green.400` is `#17eba0` where the live + `base.color.green.400` is `#00e0af`. + +Save as `resolve-tokens.py`: + +```python +#!/usr/bin/env python3 +"""Resolve HPE design tokens to concrete values. + +Usage: resolve-tokens.py [filter-substring] +Tokens are stored as {references}; this follows them to real hex/number values. +""" +import json, sys, os + +root = sys.argv[1] +needle = sys.argv[2] if len(sys.argv) > 2 else '' +T = os.path.join(root, 'packages/hpe-design-tokens/tokens') + +def flat(o, p=''): + out = {} + if isinstance(o, dict): + if '$value' in o: + return {p: o['$value']} + for k, v in o.items(): + out.update(flat(v, f'{p}.{k}' if p else k)) + return out + +prim = flat(json.load(open(f'{T}/primitive/primitives.default.json'))) +light = flat(json.load(open(f'{T}/semantic/color.light.json'))) +dark = flat(json.load(open(f'{T}/semantic/color.dark.json'))) + +def resolve(v, tbl, depth=0): + while isinstance(v, str) and v.startswith('{') and depth < 10: + k = v.strip('{}') + v = prim.get(k, tbl.get(k + '.REST', tbl.get(k))) + depth += 1 + return v + +for k in sorted(light): + if needle and needle not in k: + continue + print(f'{k:52} light={str(resolve(light[k], light)):12} dark={resolve(dark.get(k), dark)}') +``` + +Run it: + +```bash +python3 resolve-tokens.py hpeds 'text.' +# color.text.default.REST light=#3e4550 dark=#e6e8e9 +# color.text.heading...REST light=#292d3a dark=#ffffff +# color.text.critical...REST light=#cc1f1a dark=#ff7b7b + +python3 resolve-tokens.py hpeds 'background.' +python3 resolve-tokens.py hpeds '' # everything, 108 semantic color tokens +``` + +### The units gotcha + +Dimension primitives are stored as **unitless numbers**. `base.dimension.400` +is the number `16`, not `"16px"`. Units are applied at build time by +`packages/hpe-design-tokens/src/transforms/numberToDimension.ts`, and not +uniformly: + +- `fontSize` and `lineHeight` are divided by 16 and emitted as **`rem`** +- everything else (spacing, radius, padding, width, height, border width, + breakpoints) is emitted as **`px`** + +If you report a raw number as a pixel value for a font size, you will be wrong +by a factor of 16. + +## Step 6 — Pull the assets + +### Icons (452 SVGs, 1.9 MB) + +```bash +mkdir -p out/icons +cp hpeds/packages/icons-svg/src/icons/*.svg out/icons/ +cp hpeds/packages/icons-svg/LICENSE hpeds/packages/icons-svg/COPYRIGHT.md out/icons/ +ls out/icons/*.svg | wc -l # 452 +``` + +Properties, verified: + +```bash +grep -ho 'viewBox="[^"]*"' out/icons/*.svg | sort | uniq -c | sort -rn +# 448 viewBox="0 0 24 24" +# 2 viewBox="0 0 24 25" (catalog.svg, chat.svg) +# 1 viewBox="0 0 48 24" (element.svg) +# 1 viewBox="0 0 24 26" (chat-conversation.svg) + +grep -l 'currentColor' out/icons/*.svg | wc -l # 451 of 452 +grep -ho 'fill="#[0-9A-Fa-f]*"' out/icons/*.svg | sort | uniq -c +# 1 fill="#01A982" (element.svg only) +``` + +**The HPE Element is `icons/element.svg`, not a logo file.** It is the one icon +with a hardcoded color, because the brand green must not inherit from its +container. + +### Brand marks + +```bash +mkdir -p out/brand +cp hpeds/apps/docs/public/HPE_logo_full-clr_{pos,rev}_rgb.svg out/brand/ +cp hpeds/apps/docs/public/static/images/{hpe-logo,hpe-logo-invert,aruba-logo}.svg out/brand/ +``` + +### All documentation graphics (282 files, 32 MB) + +```bash +mkdir -p out/site-images +cp -r hpeds/apps/docs/public/. out/site-images/ +find out/site-images -type f | wc -l # 282 +``` + +Two things to know before you commit 32 MB: + +- **About 14 MB is Unsplash stock photography** in + `learnImages/grid-fundamentals-part-1/`: four JPGs between 2.5 and 4.9 MB + used as filler in a Grommet grid tutorial. No HPE guidance in them. Drop that + one folder and you reclaim nearly half the total. +- **`logos/` holds partner logos, not HPE marks** (Apache, Dataiku, Dremio, H2O, + SingleStore, StreamSets and others). Third-party trademarks, not covered by + this repo's Apache-2.0 license. Do not mix them into a brand folder. + +## Step 7 — Verify before you trust it + +Do not skip this. Several claims that look obvious are wrong. + +**Verify color claims programmatically** rather than reading them off a page. +Every color value in this folder's docs was checked by resolving the token +reference chain and diffing against the written claim. Three examples that +catch people out: + +- **HPE green `#01a982` is `color.decorative.brand`, not the primary action + color.** Primary interactive surfaces use `#068667` in light mode and + `#05cc93` in dark. Calling a button "HPE green" and reaching for `#01a982` + produces the wrong button. +- `base.color.green.400` and `base.color.green.500` are **both** `#00e0af`. + That looks like a bug in your parser. It is not; the source really has both. +- `color.background.front` is `#ffffff` in light mode and `#292d3a` in dark, + while `color.text.strong` is `#292d3a` in light. The same hex serves opposite + roles across modes. Do not deduplicate by value. + +**Check the docs against themselves.** The accessibility page cites **WCAG 2.2** +at the top and **WCAG 2.1** in its government-standards section. The conformance +level is consistent (**A and AA required**, per: "The guidelines identified as +level A and AA are the required design elements for all applications") but the +version reference is not. Record the discrepancy rather than picking one +silently. + +**Do not infer from filenames.** The repo has a `knowledge/capabilities/ +alignment-audit/` entry that sounds like a product compliance audit. Reading it +shows a **planned stub** scoped to auditing the design system's own docs and +tokens. Only `docs-refactor` is marked active. Open the file. + +## Step 8 — Currency + +Two traps when judging how current something is: + +- **The site's "What's new" page is stale.** Its most recent entry is April + 2023. It is not a changelog. +- Use these instead: + - `packages/hpe-design-tokens/CHANGELOG.md` + - GitHub releases on `grommet/hpe-design-system` + - `apps/docs/src/pages/design-tokens/versioning.mdx` for the version-to-theme map + +As of 2026-07-30: `hpe-design-tokens` **2.2.3**, `@hpe-design/icons-grommet` +**1.2.0**, `@hpe-design/icons-svg` **0.2.0**. Current theme generation is +**v2-Landmark** (October 2025 onward), paired with `grommet-theme-hpe` **8.x**. + +## Licensing, and the one thing to be careful about + +The repo is **Apache-2.0**, "Copyright 2025 Hewlett Packard Enterprise +Development LP." Copying the content and assets into an internal knowledge repo +is fine, with attribution. + +**An open-source copyright license grants no trademark rights.** The HPE logo +and the Element are HPE trademarks. Their use is governed by the +[HPE Terms of Use](https://www.hpe.com/us/en/about/legal/terms-of-use.html), +with authoritative files and usage rules on +[Brand Central](https://brandcentral.hpe.com/home) (HPE login required). + +Practical consequence: a vendored logo is fine for reading and internal +reference, but pull the current file from Brand Central for anything that ships +or reaches a customer. A vendored mark goes stale silently, and the pending +HPE GreenLake rebrand is exactly the event that would make a copy wrong. + +Also worth flagging to whoever consumes your mirror: **Brand Central and the +Design System deliberately disagree on color.** The Design System says so +directly and instructs product teams to prefer its palette for app and web +work. Brand Central governs logos, print, and marketing. + +## Recommended output shape + +What this folder settled on, if it is useful as a template: + +``` +hpe-branding/ +├── README.md index, provenance, currency traps +├── HOWTO-mirror-the-design-system.md this file +├── 01-what-it-is.md scope, packages, authority model +├── 02-brand-foundations.md logo rules, resolved hex tables, spacing px +├── 03-design-tokens.md three tiers, version map, units +├── 04-voice-and-tone.md UI copy rules, term list +├── 05-accessibility.md conformance level, responsibility split +├── 06-components-templates.md 48 components, 27 templates +├── 07-adoption-and-compliance.md adoption paths, review checklist +└── assets/ + ├── icons/ 452 SVGs + LICENSE + ├── brand/ 5 word-marks + └── site-images/ 282 documentation graphics +``` + +The judgment call worth repeating: **write down the resolved values, not just +links to the site.** The whole reason this is work is that the site cannot be +read without a browser. A mirror that only links back to it solves nothing. + +## Quick reference + +| Thing | Where | +| --- | --- | +| Docs site | `https://design-system.hpe.design` (browser only) | +| Source repo | `https://github.com/grommet/hpe-design-system` (Apache-2.0) | +| MDX content | `apps/docs/src/pages/**/*.mdx` | +| Graphics | `apps/docs/public/` | +| Raw icons | `packages/icons-svg/src/icons/` | +| Token JSON | `packages/hpe-design-tokens/tokens/` | +| Grommet theme | `https://github.com/grommet/grommet-theme-hpe` | +| Component props | `https://v2.grommet.io/?theme=hpe` | +| Icon Storybook | `https://hpe-design-icons-grommet.netlify.app/` | +| Brand Central | `https://brandcentral.hpe.com/home` (HPE login) | +| Slack | `#hpe-design-system` on `grommet.slack.com` and HPE enterprise Slack | diff --git a/LICENSE b/LICENSE new file mode 100644 index 0000000..1c3e60f --- /dev/null +++ b/LICENSE @@ -0,0 +1,176 @@ + Apache License + Version 2.0, January 2004 + http://www.apache.org/licenses/ + +TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + +1. Definitions. + + "License" shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + "Licensor" shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + "Legal Entity" shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + "control" means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + "You" (or "Your") shall mean an individual or Legal Entity + exercising permissions granted by this License. + + "Source" form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + "Object" form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + "Work" shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + "Derivative Works" shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + "Contribution" shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, "submitted" + means any form of electronic, verbal, or written communication sent + to the Licensor or its representatives, including but not limited to + communication on electronic mailing lists, source code control systems, + and issue tracking systems that are managed by, or on behalf of, the + Licensor for the purpose of discussing and improving the Work, but + excluding communication that is conspicuously marked or otherwise + designated in writing by the copyright owner as "Not a Contribution." + + "Contributor" shall mean Licensor and any individual or Legal Entity + on behalf of whom a Contribution has been received by Licensor and + subsequently incorporated within the Work. + +2. Grant of Copyright License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + copyright license to reproduce, prepare Derivative Works of, + publicly display, publicly perform, sublicense, and distribute the + Work and such Derivative Works in Source or Object form. + +3. Grant of Patent License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + (except as stated in this section) patent license to make, have made, + use, offer to sell, sell, import, and otherwise transfer the Work, + where such license applies only to those patent claims licensable + by such Contributor that are necessarily infringed by their + Contribution(s) alone or by combination of their Contribution(s) + with the Work to which such Contribution(s) was submitted. If You + institute patent litigation against any entity (including a + cross-claim or counterclaim in a lawsuit) alleging that the Work + or a Contribution incorporated within the Work constitutes direct + or contributory patent infringement, then any patent licenses + granted to You under this License for that Work shall terminate + as of the date such litigation is filed. + +4. Redistribution. You may reproduce and distribute copies of the + Work or Derivative Works thereof in any medium, with or without + modifications, and in Source or Object form, provided that You + meet the following conditions: + + (a) You must give any other recipients of the Work or + Derivative Works a copy of this License; and + + (b) You must cause any modified files to carry prominent notices + stating that You changed the files; and + + (c) You must retain, in the Source form of any Derivative Works + that You distribute, all copyright, patent, trademark, and + attribution notices from the Source form of the Work, + excluding those notices that do not pertain to any part of + the Derivative Works; and + + (d) If the Work includes a "NOTICE" text file as part of its + distribution, then any Derivative Works that You distribute must + include a readable copy of the attribution notices contained + within such NOTICE file, excluding those notices that do not + pertain to any part of the Derivative Works, in at least one + of the following places: within a NOTICE text file distributed + as part of the Derivative Works; within the Source form or + documentation, if provided along with the Derivative Works; or, + within a display generated by the Derivative Works, if and + wherever such third-party notices normally appear. The contents + of the NOTICE file are for informational purposes only and + do not modify the License. You may add Your own attribution + notices within Derivative Works that You distribute, alongside + or as an addendum to the NOTICE text from the Work, provided + that such additional attribution notices cannot be construed + as modifying the License. + + You may add Your own copyright statement to Your modifications and + may provide additional or different license terms and conditions + for use, reproduction, or distribution of Your modifications, or + for any such Derivative Works as a whole, provided Your use, + reproduction, and distribution of the Work otherwise complies with + the conditions stated in this License. + +5. Submission of Contributions. Unless You explicitly state otherwise, + any Contribution intentionally submitted for inclusion in the Work + by You to the Licensor shall be under the terms and conditions of + this License, without any additional terms or conditions. + Notwithstanding the above, nothing herein shall supersede or modify + the terms of any separate license agreement you may have executed + with Licensor regarding such Contributions. + +6. Trademarks. This License does not grant permission to use the trade + names, trademarks, service marks, or product names of the Licensor, + except as required for reasonable and customary use in describing the + origin of the Work and reproducing the content of the NOTICE file. + +7. Disclaimer of Warranty. Unless required by applicable law or + agreed to in writing, Licensor provides the Work (and each + Contributor provides its Contributions) on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or + implied, including, without limitation, any warranties or conditions + of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A + PARTICULAR PURPOSE. You are solely responsible for determining the + appropriateness of using or redistributing the Work and assume any + risks associated with Your exercise of permissions under this License. + +8. Limitation of Liability. In no event and under no legal theory, + whether in tort (including negligence), contract, or otherwise, + unless required by applicable law (such as deliberate and grossly + negligent acts) or agreed to in writing, shall any Contributor be + liable to You for damages, including any direct, indirect, special, + incidental, or consequential damages of any character arising as a + result of this License or out of the use or inability to use the + Work (including but not limited to damages for loss of goodwill, + work stoppage, computer failure or malfunction, or any and all + other commercial damages or losses), even if such Contributor + has been advised of the possibility of such damages. + +9. Accepting Warranty or Additional Liability. While redistributing + the Work or Derivative Works thereof, You may choose to offer, + and charge a fee for, acceptance of support, warranty, indemnity, + or other liability obligations and/or rights consistent with this + License. However, in accepting such obligations, You may act only + on Your own behalf and on Your sole responsibility, not on behalf + of any other Contributor, and only if You agree to indemnify, + defend, and hold each Contributor harmless for any liability + incurred by, or claims asserted against, such Contributor by reason + of your accepting any such warranty or additional liability. + +END OF TERMS AND CONDITIONS diff --git a/README.md b/README.md new file mode 100644 index 0000000..5db74d0 --- /dev/null +++ b/README.md @@ -0,0 +1,113 @@ +# hpe-branding + +A readable mirror of the **HPE Design System**, HPE's brand standard for +software user interfaces: what an HPE product UI must look like, how its text +must read, and what accessibility it must meet. + +Canonical source: `https://design-system.hpe.design` +Upstream repo: `https://github.com/grommet/hpe-design-system` (Apache-2.0) + +## Why this exists + +The official site is a Next.js static export that renders entirely in the +browser. Fetch a page and you get a 1.5 KB empty shell: + +```bash +curl -s https://design-system.hpe.design/foundation/color | wc -c # 1540 +``` + +There is no sitemap and no robots.txt. That makes the guidance hard to grep, +hard to diff, and impossible to feed to a coding agent without a browser. + +This repo is the same material in plain Markdown, with the values resolved. +Every color here is a real hex code, not a token reference. Every spacing step +is a real pixel value. The icons and graphics are checked in. + +## Contents + +| Path | What it covers | +| --- | --- | +| [`01-what-it-is.md`](01-what-it-is.md) | Scope, published packages, how it ships, Brand Central vs Design System authority | +| [`02-brand-foundations.md`](02-brand-foundations.md) | Logo and Element placement, resolved color tables, HPE Graphik, the spacing scale, icon rules | +| [`03-design-tokens.md`](03-design-tokens.md) | The three token tiers, naming, the version map, how to consume them | +| [`04-voice-and-tone.md`](04-voice-and-tone.md) | UI string rules: capitalization, acronyms, banned phrasings, the term list | +| [`05-accessibility.md`](05-accessibility.md) | Conformance level, the responsibility split, testing tools | +| [`06-components-templates.md`](06-components-templates.md) | The 48-component and 27-template inventory, and what each layer is for | +| [`07-adoption-and-compliance.md`](07-adoption-and-compliance.md) | Three adoption paths, a review checklist, what is worth arguing about | +| [`HOWTO-mirror-the-design-system.md`](HOWTO-mirror-the-design-system.md) | **Runbook to rebuild this repo from scratch.** Verified commands and two scripts | +| [`assets/icons/`](assets/icons/) | All 452 SVG icons, the complete HPE set | +| [`assets/brand/`](assets/brand/) | HPE and HPE Aruba Networking word-marks | +| [`assets/site-images/`](assets/site-images/) | All 282 documentation graphics | + +New to this? Read `01`, then `02`. If you are about to build or review a UI, +skip to the checklist in `07`. + +To regenerate this against a newer upstream, the runbook is the whole +procedure, including the two scripts that do the awkward parts. + +## Things that surprise people + +- **HPE green `#01a982` is not the button color.** It is + `color.decorative.brand`. Primary interactive surfaces use `#068667` in light + mode and `#05cc93` in dark. Reaching for `#01a982` on a button produces the + wrong button. +- **The Element is an icon, not a logo file.** It is + [`assets/icons/element.svg`](assets/icons/element.svg), the only icon in the + set with a hardcoded color, because the brand green must not inherit. +- **Brand Central and the Design System disagree on color, deliberately.** The + Design System extends brand color for digital product use and instructs + product teams to prefer its palette for app and web work. Brand Central + governs logos, print, and marketing. +- **The HPE GreenLake badge is retired.** It must not be added to new material, + pending a GreenLake rebrand. +- **The upstream "What's new" page is stale.** Its most recent entry is April + 2023. It is not a changelog. Use the GitHub releases and the + `hpe-design-tokens` changelog instead. +- **Token JSON holds no values.** It holds references. Reading + `color.light.json` directly gives you `{base.color.grey.50}`, not `#f7f7f7`. + +## Provenance + +Content read from `grommet/hpe-design-system` at commit **`567c4d5`** +(2026-07-16), mirrored **2026-07-30**. + +Versions current at that date: `hpe-design-tokens` **2.2.3**, +`@hpe-design/icons-grommet` **1.2.0**, `@hpe-design/icons-svg` **0.2.0**. +Theme generation **v2-Landmark** (October 2025 onward), paired with +`grommet-theme-hpe` **8.x**. + +This is a **point-in-time snapshot and it will drift.** For anything that +ships, check upstream. The runbook exists so refreshing is cheap. + +Colors were not transcribed by hand. Because token JSON stores references, every +color in these docs was produced by resolving the reference chain with the +script in the runbook, then diffed against the written claim. + +## License and trademark + +Upstream is **Apache-2.0**, "Copyright 2025 Hewlett Packard Enterprise +Development LP." The license text ships with the icons at +[`assets/icons/LICENSE`](assets/icons/LICENSE). This mirror is redistributed +under the same terms. + +**An open-source copyright license grants no trademark rights.** The HPE logo +and the Element are HPE trademarks. Their use is governed by the +[HPE Terms of Use](https://www.hpe.com/us/en/about/legal/terms-of-use.html), +with authoritative files and usage rules on +[Brand Central](https://brandcentral.hpe.com/home) (HPE login required). + +Treat `assets/brand/` as a reference copy for reading. For anything that ships +or reaches a customer, pull the current file from Brand Central. A vendored +mark goes stale silently, and the pending GreenLake rebrand is exactly the +event that would make a copy wrong. + +`assets/site-images/logos/` holds **third-party partner logos** (Apache, +Dataiku, Dremio, H2O, SingleStore, StreamSets and others). Those marks belong +to their owners and are not covered by the Apache-2.0 license above. + +## Not affiliated + +An unofficial mirror kept for reference. Not published by, or endorsed by, the +HPE Design System team. Upstream is the authority: open issues against +[`grommet/hpe-design-system`](https://github.com/grommet/hpe-design-system), +not here. diff --git a/assets/README.md b/assets/README.md new file mode 100644 index 0000000..ccaa1c2 --- /dev/null +++ b/assets/README.md @@ -0,0 +1,187 @@ +# hpe-branding/assets — vendored HPE assets + +Copies of the icon set, brand marks, and documentation graphics from +`github.com/grommet/hpe-design-system`, taken at commit `567c4d5` (2026-07-16) +on 2026-07-30. Here so the marks, icons, and reference images are available +without a build step, an npm install, or loading a JavaScript site. + +| Folder | Contents | Size | +| --- | --- | --- | +| `icons/` | 452 SVG icons, the full HPE set | 1.9 MB | +| `brand/` | 5 HPE and Aruba word-marks | 34 KB | +| `site-images/` | 282 documentation graphics, mirrored from the docs site | 32 MB | + +## License and trademark + +The code and icons are **Apache-2.0**, "Copyright 2025 Hewlett Packard +Enterprise Development LP." The license text is in `icons/LICENSE`. + +The license is not the whole story for the brand marks. **An open-source +copyright license does not grant trademark rights.** The HPE logo and the +Element are HPE trademarks, and their use is governed by the +[HPE Terms of Use](https://www.hpe.com/us/en/about/legal/terms-of-use.html) +with the authoritative files and usage rules on +[Brand Central](https://brandcentral.hpe.com/home). + +Treat `brand/` as a convenience copy for reading and internal reference. For +anything that ships or goes to a customer, pull the current file from Brand +Central. A vendored logo goes stale silently, and the GreenLake rebrand noted +in `../02-brand-foundations.md` is exactly the kind of event that would make +this copy wrong. + +## brand/ + +| File | What it is | +| --- | --- | +| `HPE_logo_full-clr_pos_rgb.svg` | HPE word-mark, positive (light backgrounds) | +| `HPE_logo_full-clr_rev_rgb.svg` | HPE word-mark, reversed (dark backgrounds) | +| `hpe-logo.svg` | Site header variant of the word-mark | +| `hpe-logo-invert.svg` | Site header variant, inverted | +| `aruba-logo.svg` | HPE Aruba Networking word-mark | + +The **Element** (the green rectangle symbol) is not here. It ships as part of +the icon set: `icons/element.svg`. It is the only icon in the set with a +hardcoded color, `#01A982`, because the brand green is not allowed to inherit. +It is also one of the few icons that is not square, at 48x24. + +Placement rules for the Element and the logos are in +`../02-brand-foundations.md`. + +## icons/ + +452 SVGs, flat directory, one file per icon, named semantically. + +Properties worth knowing before using them: + +- **448 of 452 are 24x24.** The exceptions are `element.svg` (48x24), + `catalog.svg` and `chat.svg` (24x25), and `chat-conversation.svg` (24x26). + If you are laying out an icon grid, those four will not align. +- **451 of 452 use `fill="currentColor"`**, so they take the color of their + container with no edit. `element.svg` is the one exception. +- No ` + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/assets/site-images/whatis/base.svg b/assets/site-images/whatis/base.svg new file mode 100644 index 0000000..fa3eaa0 --- /dev/null +++ b/assets/site-images/whatis/base.svg @@ -0,0 +1,5 @@ + + + + + diff --git a/assets/site-images/whatis/combining.svg b/assets/site-images/whatis/combining.svg new file mode 100644 index 0000000..0c72b99 --- /dev/null +++ b/assets/site-images/whatis/combining.svg @@ -0,0 +1,6 @@ + + + + + + diff --git a/assets/site-images/whatis/tailor.svg b/assets/site-images/whatis/tailor.svg new file mode 100644 index 0000000..6dde8c6 --- /dev/null +++ b/assets/site-images/whatis/tailor.svg @@ -0,0 +1,16 @@ + + + + + + + + + + + + + + + + diff --git a/assets/site-images/whatis/tools.svg b/assets/site-images/whatis/tools.svg new file mode 100644 index 0000000..6d87c08 --- /dev/null +++ b/assets/site-images/whatis/tools.svg @@ -0,0 +1,17 @@ + + + + + + + + + + + + + + + + + diff --git a/assets/site-images/windows.svg b/assets/site-images/windows.svg new file mode 100644 index 0000000..08a3f28 --- /dev/null +++ b/assets/site-images/windows.svg @@ -0,0 +1,6 @@ + + + + + + diff --git a/assets/site-images/woman-glc.jpeg b/assets/site-images/woman-glc.jpeg new file mode 100644 index 0000000..970471a Binary files /dev/null and b/assets/site-images/woman-glc.jpeg differ diff --git a/assets/site-images/woman-man-server-room.jpeg b/assets/site-images/woman-man-server-room.jpeg new file mode 100644 index 0000000..40ab3e1 Binary files /dev/null and b/assets/site-images/woman-man-server-room.jpeg differ