diff --git a/apps/docs/package.json b/apps/docs/package.json
index f549ed199f..8b12dc9b92 100644
--- a/apps/docs/package.json
+++ b/apps/docs/package.json
@@ -6,11 +6,19 @@
   "main": "src/pages/index.js",
   "private": true,
   "dependencies": {
+    "@codemirror/commands": "^6.10.1",
+    "@codemirror/lang-javascript": "^6.2.4",
+    "@codemirror/language": "^6.12.1",
+    "@codemirror/state": "^6.5.4",
+    "@codemirror/theme-one-dark": "^6.1.3",
+    "@codemirror/view": "^6.39.12",
     "@hpe-design/icons-grommet": "catalog:",
+    "@lezer/highlight": "^1.2.3",
     "@mdx-js/loader": "^3.0.1",
     "@mdx-js/react": "^3.0.1",
     "@next/mdx": "^14.1.4",
     "@shared/aries-core": "workspace:*",
+    "@uiw/codemirror-theme-github": "^4.25.4",
     "grommet": "catalog:",
     "grommet-icons": "catalog:grommet-stable",
     "hpe-design-tokens": "^2.1.0",
diff --git a/apps/docs/src/components/content/CodeEditor.js b/apps/docs/src/components/content/CodeEditor.js
new file mode 100644
index 0000000000..3bb4979db8
--- /dev/null
+++ b/apps/docs/src/components/content/CodeEditor.js
@@ -0,0 +1,222 @@
+import React, { useContext, useRef, useEffect } from 'react';
+import PropTypes from 'prop-types';
+import { ThemeContext, Box } from 'grommet';
+import { EditorView, keymap } from '@codemirror/view';
+import { EditorState } from '@codemirror/state';
+import { javascript } from '@codemirror/lang-javascript';
+import { defaultKeymap, indentWithTab } from '@codemirror/commands';
+import { HighlightStyle, syntaxHighlighting } from '@codemirror/language';
+import { tags } from '@lezer/highlight';
+import { prism } from 'grommet-theme-hpe';
+
+export const CodeEditor = ({ code, onChange }) => {
+  const theme = useContext(ThemeContext);
+  const editorRef = useRef(null);
+  const viewRef = useRef(null);
+  const onChangeRef = useRef(onChange);
+  const isDark = theme.dark;
+
+  // Keep onChange ref updated without triggering recreation
+  useEffect(() => {
+    onChangeRef.current = onChange;
+  }, [onChange]);
+
+  useEffect(() => {
+    if (!editorRef.current) return undefined;
+
+    // Don't recreate if editor already exists with same theme mode
+    if (viewRef.current) {
+      return;
+    }
+
+    // Get HPE theme colors
+    const getColor = colorName => {
+      const colorValue = theme.global.colors[colorName];
+      if (typeof colorValue === 'object') {
+        return colorValue[isDark ? 'dark' : 'light'] || colorValue;
+      }
+      return colorValue || colorName;
+    };
+
+    // Get the HPE prism theme for syntax highlighting colors
+    const hpePrismTheme = isDark ? prism.dark : prism.light;
+
+    // Create HPE theme extension
+    const hpeTheme = EditorView.theme(
+      {
+        '&': {
+          height: '100%',
+          fontSize: '14px',
+          fontFamily:
+            'ui-monospace, SFMono-Regular, SF Mono, Consolas, Liberation Mono, Menlo, monospace',
+        },
+        '.cm-editor': {
+          backgroundColor: getColor('background-front'),
+          color: getColor('text-default'),
+          border: `1px solid ${getColor('border-weak')}`,
+          borderRadius: '4px',
+        },
+        '.cm-scroller': {
+          backgroundColor: 'transparent',
+          lineHeight: '1.5',
+        },
+        '.cm-content': {
+          backgroundColor: 'transparent',
+          color: getColor('text-default'),
+          padding: '12px',
+          caretColor: getColor('text-strong'),
+          minHeight: '100px',
+        },
+        '.cm-content[contenteditable="true"]': {
+          outline: 'none',
+        },
+        '.cm-line': {
+          padding: '0',
+        },
+        '.cm-gutters': {
+          display: 'none',
+        },
+        '.cm-focused': {
+          outline: `2px solid ${getColor('border-selected')}`,
+          outlineOffset: '-2px',
+        },
+        '&.cm-focused .cm-cursor': {
+          borderLeftColor: getColor('text-strong'),
+          borderLeftWidth: '2px',
+        },
+        '&.cm-focused .cm-selectionBackground, ::selection': {
+          backgroundColor: isDark
+            ? 'rgba(0, 255, 135, 0.2)'
+            : 'rgba(0, 125, 96, 0.2)',
+        },
+        '.cm-selectionBackground': {
+          backgroundColor: isDark
+            ? 'rgba(255, 255, 255, 0.1)'
+            : 'rgba(0, 0, 0, 0.1)',
+        },
+      },
+      { dark: isDark },
+    );
+
+    // Create HPE syntax highlighting style using exact prism theme colors
+    const hpeSyntaxHighlighting = HighlightStyle.define([
+      // Comments
+      {
+        tag: tags.comment,
+        color: hpePrismTheme.comment?.color,
+        fontStyle: 'italic',
+      },
+      // Keywords (import, export, const, let, var, function, etc.)
+      {
+        tag: [
+          tags.keyword,
+          tags.controlKeyword,
+          tags.definitionKeyword,
+          tags.modifier,
+          tags.moduleKeyword,
+        ],
+        color: hpePrismTheme.keyword?.color,
+        fontWeight: '500',
+      },
+      // Strings
+      {
+        tag: [tags.string, tags.special(tags.string)],
+        color: hpePrismTheme.string?.color,
+      },
+      // Numbers
+      {
+        tag: [tags.number, tags.literal],
+        color: hpePrismTheme.number?.color,
+      },
+      // Component names and functions
+      {
+        tag: [
+          tags.variableName,
+          tags.function(tags.variableName),
+          tags.definition(tags.variableName),
+        ],
+        color: hpePrismTheme['maybe-class-name']?.color,
+      },
+      // JSX Tags
+      {
+        tag: [tags.tagName],
+        color: hpePrismTheme.keyword?.color,
+        fontWeight: '500',
+      },
+      // Attributes
+      {
+        tag: [tags.attributeName, tags.propertyName],
+        color: hpePrismTheme['attr-name']?.color,
+      },
+      // Operators
+      {
+        tag: [tags.operator],
+        color: hpePrismTheme.operator?.color,
+      },
+      // Punctuation
+      {
+        tag: [tags.punctuation, tags.separator, tags.bracket],
+        color:
+          hpePrismTheme['code[class*="language-"]']?.color ||
+          getColor('text-default'),
+      },
+      // Boolean values
+      {
+        tag: [tags.bool],
+        color: hpePrismTheme.boolean?.color,
+      },
+    ]);
+
+    // Create editor state
+    const state = EditorState.create({
+      doc: code,
+      extensions: [
+        EditorView.editable.of(true),
+        hpeTheme,
+        syntaxHighlighting(hpeSyntaxHighlighting),
+        keymap.of([...defaultKeymap, indentWithTab]),
+        javascript({ jsx: true }),
+        EditorView.updateListener.of(update => {
+          if (update.docChanged && onChangeRef.current) {
+            onChangeRef.current(update.state.doc.toString());
+          }
+        }),
+      ],
+    });
+
+    // Create editor view
+    const view = new EditorView({
+      state,
+      parent: editorRef.current,
+    });
+
+    viewRef.current = view;
+
+    return () => {
+      if (viewRef.current) {
+        viewRef.current.destroy();
+        viewRef.current = null;
+      }
+    };
+  }, [isDark]); // Only recreate when theme mode changes
+
+  // Handle external code changes
+  useEffect(() => {
+    if (viewRef.current && viewRef.current.state.doc.toString() !== code) {
+      viewRef.current.dispatch({
+        changes: {
+          from: 0,
+          to: viewRef.current.state.doc.length,
+          insert: code,
+        },
+      });
+    }
+  }, [code]);
+
+  return <Box ref={editorRef} style={{ height: '100%' }} />;
+};
+
+CodeEditor.propTypes = {
+  code: PropTypes.string.isRequired,
+  onChange: PropTypes.func.isRequired,
+};
diff --git a/apps/docs/src/components/content/ComponentPlayground.js b/apps/docs/src/components/content/ComponentPlayground.js
new file mode 100644
index 0000000000..87aa778dde
--- /dev/null
+++ b/apps/docs/src/components/content/ComponentPlayground.js
@@ -0,0 +1,460 @@
+import React, { useState, useEffect } from 'react';
+import PropTypes from 'prop-types';
+import {
+  Box,
+  Button,
+  CheckBox,
+  Select,
+  Text,
+  TextInput,
+  Heading,
+  ResponsiveContext,
+  Grommet,
+  Grid,
+} from 'grommet';
+import { Copy, Moon } from '@hpe-design/icons-grommet';
+import { hpe } from 'grommet-theme-hpe';
+import { CodeEditor } from './CodeEditor';
+
+const ICON_OPTIONS = [
+  { label: 'None', value: null },
+  { label: 'NewWindow', value: 'NewWindow' },
+  { label: 'LinkNext', value: 'LinkNext' },
+  { label: 'LinkPrevious', value: 'LinkPrevious' },
+];
+
+export const ComponentPlayground = ({
+  component: Component,
+  defaultProps = {},
+  controls = [],
+  codeTemplate,
+}) => {
+  const [componentProps, setComponentProps] = useState(defaultProps);
+  const [copied, setCopied] = useState(false);
+  const [code, setCode] = useState('');
+  const [isCodeManuallyEdited, setIsCodeManuallyEdited] = useState(false);
+  const [codeError, setCodeError] = useState(null);
+  // eslint-disable-next-line max-len
+  const [previewTheme, setPreviewTheme] = useState('light'); // 'light' or 'dark'
+
+  const togglePreviewTheme = () => {
+    setPreviewTheme(prev => (prev === 'light' ? 'dark' : 'light'));
+  };
+
+  const handlePropChange = (propName, value) => {
+    setComponentProps(prev => {
+      const newProps = { ...prev, [propName]: value };
+      return newProps;
+    });
+  };
+
+  const generateCode = () => {
+    // Use custom code template if provided
+    if (codeTemplate) {
+      return codeTemplate(componentProps);
+    }
+
+    const propsString = Object.entries(componentProps)
+      .filter(
+        ([, value]) => value !== null && value !== undefined && value !== '',
+      )
+      .map(([key, value]) => {
+        if (key === 'icon' && value) {
+          return `icon={<${value} />}`;
+        }
+        if (typeof value === 'boolean') {
+          return value ? key : null;
+        }
+        if (typeof value === 'string') {
+          return `${key}="${value}"`;
+        }
+        return null;
+      })
+      .filter(Boolean)
+      .join(' ');
+
+    const iconImport = componentProps.icon
+      ? `import { ${componentProps.icon} } from '@hpe-design/icons-grommet';\n`
+      : '';
+
+    const componentName = Component.displayName || 'Component';
+    const propsCode = propsString ? ` ${propsString}` : '';
+
+    return `${iconImport}import { ${componentName} } from 'grommet';
+
+<${componentName}${propsCode} />`;
+  };
+
+  // Update code when componentProps change, unless user manually edited it
+  useEffect(() => {
+    if (!isCodeManuallyEdited) {
+      const newCode = generateCode();
+      setCode(newCode);
+    }
+    // eslint-disable-next-line react-hooks/exhaustive-deps
+  }, [componentProps, isCodeManuallyEdited]);
+
+  const handleCodeChange = newCode => {
+    setCode(newCode);
+    setIsCodeManuallyEdited(true);
+
+    // Validate code syntax
+    const componentName = Component.displayName || 'Component';
+    const componentRegex = new RegExp(
+      `<${componentName}([^/>]*)(/>|>.*?</${componentName}>)`,
+      's',
+    );
+
+    // Check for basic JSX syntax errors
+    if (
+      newCode.includes(`<${componentName}`) &&
+      !componentRegex.test(newCode)
+    ) {
+      setCodeError('Syntax Error: Incomplete or malformed JSX tag');
+      return;
+    }
+
+    // Check for unclosed quotes
+    const quoteMatches = newCode.match(/"/g);
+    if (quoteMatches && quoteMatches.length % 2 !== 0) {
+      setCodeError('Syntax Error: Unclosed quote');
+      return;
+    }
+
+    // Check for unclosed braces in JSX
+    const braceMatches = newCode.match(/\{/g);
+    const closeBraceMatches = newCode.match(/\}/g);
+    if ((braceMatches?.length || 0) !== (closeBraceMatches?.length || 0)) {
+      setCodeError('Syntax Error: Unclosed brace');
+      return;
+    }
+
+    // Clear error if validation passes
+    setCodeError(null);
+
+    // Parse the code to extract props
+    try {
+      const match = newCode.match(componentRegex);
+
+      if (match) {
+        const propsString = match[1];
+        const newProps = { ...defaultProps }; // Start with default props
+
+        // Parse all string props: propName="value"
+        const stringPropRegex = /(\w+)="([^"]*)"/g;
+        let stringMatch;
+        // eslint-disable-next-line no-cond-assign
+        while ((stringMatch = stringPropRegex.exec(propsString)) !== null) {
+          const [, propName, propValue] = stringMatch;
+          newProps[propName] = propValue;
+        }
+
+        // Parse icon={<IconName />}
+        const iconMatch = propsString.match(/icon=\{<(\w+)\s*\/>\}/);
+        if (iconMatch) {
+          // eslint-disable-next-line prefer-destructuring
+          newProps.icon = iconMatch[1];
+        } else if (!propsString.includes('icon=')) {
+          // If icon prop is not in the code, ensure it's not in newProps
+          delete newProps.icon;
+        }
+
+        // Parse boolean props (just the prop name without =)
+        // Get all possible boolean props from controls
+        const boolProps = controls
+          .filter(c => c.type === 'checkbox')
+          .map(c => c.name);
+
+        boolProps.forEach(prop => {
+          const hasProp = new RegExp(`\\b${prop}\\b(?!=)`).test(propsString);
+          if (hasProp) {
+            newProps[prop] = true;
+          } else if (defaultProps[prop] === undefined) {
+            newProps[prop] = false;
+          }
+        });
+
+        console.log('Parsed props from code:', newProps);
+        // Replace props entirely when code is manually edited
+        setComponentProps(newProps);
+      }
+    } catch (error) {
+      // If parsing fails, just keep the code change
+      setCodeError(`Error: ${error.message}`);
+    }
+  };
+
+  const handleCopy = () => {
+    navigator.clipboard.writeText(code || generateCode());
+    setCopied(true);
+    setTimeout(() => setCopied(false), 2000);
+  };
+
+  const renderControl = (control, isLast = false) => {
+    const { name, type, options, displayLabel } = control;
+
+    let controlElement;
+
+    switch (type) {
+      case 'text':
+        controlElement = (
+          <TextInput
+            id={`playground-${name}`}
+            name={name}
+            value={
+              componentProps[name] !== undefined &&
+              componentProps[name] !== null
+                ? String(componentProps[name])
+                : ''
+            }
+            onChange={event => handlePropChange(name, event.target.value)}
+            placeholder={`Enter ${displayLabel || name}`}
+            size="small"
+            focusIndicator
+          />
+        );
+        break;
+
+      case 'select':
+        controlElement = (
+          <Select
+            options={options || []}
+            value={componentProps[name] || ''}
+            onChange={({ option }) => handlePropChange(name, option)}
+            placeholder={`Select ${displayLabel || name}`}
+            size="small"
+          />
+        );
+        break;
+
+      case 'checkbox':
+        controlElement = (
+          <CheckBox
+            checked={componentProps[name] || false}
+            onChange={event => handlePropChange(name, event.target.checked)}
+            toggle
+          />
+        );
+        break;
+
+      case 'icon':
+        controlElement = (
+          <Select
+            options={options || ICON_OPTIONS}
+            labelKey="label"
+            valueKey="value"
+            value={
+              (options || ICON_OPTIONS).find(
+                opt => opt.value === componentProps[name],
+              ) || { label: 'None', value: null }
+            }
+            onChange={({ option }) => handlePropChange(name, option.value)}
+            size="small"
+          />
+        );
+        break;
+
+      default:
+        return null;
+    }
+
+    return (
+      <Box
+        key={name}
+        direction="row"
+        align="center"
+        justify="between"
+        pad={{ vertical: 'xxsmall', horizontal: 'xxsmall' }}
+        border={!isLast ? { side: 'bottom', color: 'border-weak' } : undefined}
+      >
+        <Text size="small" weight={500}>
+          {displayLabel || name}
+        </Text>
+        <Box width="medium">{controlElement}</Box>
+      </Box>
+    );
+  };
+
+  // Dynamically import icon if needed
+  const ComponentWithIcon = () => {
+    const propsToRender = { ...componentProps };
+
+    // Add onClick handler to prevent default behavior for interactive
+    // components
+    if (!propsToRender.onClick) {
+      propsToRender.onClick = e => {
+        e.preventDefault();
+        e.stopPropagation();
+      };
+    }
+
+    if (componentProps.icon) {
+      const icons = require('@hpe-design/icons-grommet');
+      const IconComponent = icons[componentProps.icon];
+      if (IconComponent) {
+        propsToRender.icon = <IconComponent />;
+      }
+    }
+
+    return <Component {...propsToRender} />;
+  };
+
+  return (
+    <ResponsiveContext.Consumer>
+      {size => {
+        return (
+          <Box
+            pad="medium"
+            round="small"
+            gap="medium"
+            border={{ color: 'border', size: 'xsmall' }}
+          >
+            <Box direction="row" justify="end" alignSelf="end">
+              <Button
+                icon={<Moon />}
+                a11yTitle={
+                  previewTheme === 'dark'
+                    ? 'Switch preview to light mode'
+                    : 'Switch preview to dark mode'
+                }
+                tip={{
+                  content:
+                    previewTheme === 'dark'
+                      ? 'Switch preview to light mode'
+                      : 'Switch preview to dark mode',
+                }}
+                onClick={togglePreviewTheme}
+                secondary
+              />
+            </Box>
+
+            <Grid
+              columns={{ count: 'fit', size: ['flex', 'medium'] }}
+              rows={['flex', 'medium']}
+              areas={[
+                ['main', 'side'],
+                ['code', 'code'],
+              ]}
+              gap="medium"
+              fill
+            >
+              {/* Main area: Component preview */}
+              <Box gridArea="main" pad="medium">
+                <Text size="medium" weight="bold" margin={{ bottom: 'small' }}>
+                  Preview
+                </Text>
+                <Grommet
+                  theme={hpe}
+                  themeMode={previewTheme}
+                  style={{ width: '100%', height: '100%' }}
+                >
+                  <Box
+                    background="background-back"
+                    fill
+                    align="center"
+                    justify="center"
+                    round="xsmall"
+                    height={{ min: 'medium' }}
+                  >
+                    <ComponentWithIcon />
+                  </Box>
+                </Grommet>
+              </Box>
+
+              {/* Side area: Props controls */}
+              <Box gridArea="side" pad="medium" background="background-front">
+                <Box
+                  round="xsmall"
+                  overflow={{ vertical: 'auto' }}
+                  fill
+                  pad={{ vertical: 'xsmall' }}
+                >
+                  <Text
+                    size="medium"
+                    weight="bold"
+                    margin={{ horizontal: 'small', bottom: 'xsmall' }}
+                  >
+                    Props
+                  </Text>
+                  {(() => {
+                    const visibleControls = controls.filter(
+                      control =>
+                        !control.showWhen || control.showWhen(componentProps),
+                    );
+                    return visibleControls.map((control, index) =>
+                      renderControl(
+                        control,
+                        index === visibleControls.length - 1,
+                      ),
+                    );
+                  })()}
+                </Box>
+              </Box>
+
+              {/* Code area: Full width code editor */}
+              <Box gridArea="code" pad="medium">
+                <Text size="medium" weight="bold" margin={{ bottom: 'small' }}>
+                  Code
+                </Text>
+                {codeError && (
+                  <Box
+                    background="status-critical"
+                    pad="small"
+                    round="xsmall"
+                    margin={{ bottom: 'small' }}
+                  >
+                    <Text size="small" color="text-strong">
+                      {codeError}
+                    </Text>
+                  </Box>
+                )}
+                <Box
+                  background="background-front"
+                  round="xsmall"
+                  fill
+                  overflow="auto"
+                  style={{ position: 'relative', minHeight: '200px' }}
+                >
+                  <Box
+                    style={{
+                      position: 'absolute',
+                      top: '12px',
+                      right: '12px',
+                      zIndex: 2,
+                    }}
+                  >
+                    <Button
+                      icon={<Copy />}
+                      a11yTitle={copied ? 'Copied!' : 'Copy code'}
+                      tip={copied ? 'Copied!' : 'Copy code'}
+                      onClick={handleCopy}
+                      size="small"
+                      secondary
+                    />
+                  </Box>
+                  <CodeEditor code={code} onChange={handleCodeChange} />
+                </Box>
+              </Box>
+            </Grid>
+          </Box>
+        );
+      }}
+    </ResponsiveContext.Consumer>
+  );
+};
+
+ComponentPlayground.propTypes = {
+  component: PropTypes.elementType.isRequired,
+  defaultProps: PropTypes.object,
+  // Function that takes props and returns code string
+  codeTemplate: PropTypes.func,
+  controls: PropTypes.arrayOf(
+    PropTypes.shape({
+      name: PropTypes.string.isRequired,
+      type: PropTypes.oneOf(['text', 'select', 'checkbox', 'icon']).isRequired,
+      displayLabel: PropTypes.string,
+      options: PropTypes.array,
+      showWhen: PropTypes.func,
+    }),
+  ).isRequired,
+};
diff --git a/apps/docs/src/components/content/index.js b/apps/docs/src/components/content/index.js
index 23b2980980..3cffe1be54 100644
--- a/apps/docs/src/components/content/index.js
+++ b/apps/docs/src/components/content/index.js
@@ -1,7 +1,9 @@
 export * from './AppIdentity';
+export * from './CodeEditor';
 export * from './CollapsibleSection';
 export * from './ColorCompliance';
 export * from './ColorSwatch';
+export * from './ComponentPlayground';
 export * from './DecisionTree';
 export * from './DesignTokensTable';
 export * from './DesignTokenContext';
diff --git a/apps/docs/src/data/search/contentForSearch.js b/apps/docs/src/data/search/contentForSearch.js
new file mode 100644
index 0000000000..903551d7eb
--- /dev/null
+++ b/apps/docs/src/data/search/contentForSearch.js
@@ -0,0 +1 @@
+export const siteContents = [{"name":"404","parent":"pages","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/404.js","content":"         return (                    ); };           return (                                {first}           {second}                        ); }; export default Custom404; "},{"name":"_app","parent":"pages","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/_app.js","content":"         /* _app.js allows for customizing Next.js's default  component  * Details: https://nextjs.org/docs/advanced-features/custom-app  *  * The `Component` prop is the active `page`, so whenever you  * navigate between routes, `Component` will change to the new `page`.  */ export  // thirtyDaysAgo calculated in milliseconds   ~~ function App({ Component, pageProps, router }) {      // state that holds the update information within the last 30 days      // state that holds boolean for whether or not   // update info is ready to be rendered      // this effect is only for the first time _app mounts   useEffect(() => {          let name = routePartsrouteParts.length - 1.split('#')0;     name = name.charAt(0).toUpperCase() + name.slice(1);     fetch(       'https://api.github.com/repos/grommet/hpe-design-system/pulls?state=closed',     )       .then(response => response.json())       .then(data => {                  let localStorageKey;         for (let i = 0; i  thirtyDaysAgo &&             prDescription &&             prDescription.includes(notificationHeading)           ) {                          // the position of the first bracket containing             // either new/updates is 22 characters away             // this includes the notification header             // and the \\r\\n\\r\\n that follow                                       // += 3 so it can jump between component descriptions             for (               let j = 0;               j  console.error(error));   }, router);   useEffect(() => {            skipLinks.focus();       if (typeof window !== 'undefined') {                  let name = routePartsrouteParts.length - 1.split('-').join(' ');                  name = name.charAt(0).toUpperCase() + name.slice(1);                           // every time it re-routes, see if the given page has a         // reported update in the last 30 days (what's reported in         // updateHistory) then check if it should be shown (T/F), and         // set that in the state variable         if (contentHistory && pageName in contentHistory) {           contentHistorypageName.update = pageVisitTracker(             pageName,             contentHistory,           );           window.localStorage.setItem(localStorageKey, now);           setContentHistory(contentHistory);           setPageUpdateReady(true);         }       }     };     router.events.on('routeChangeComplete', handleRouteChange);     // If the component is unmounted, unsubscribe     // from the event with the `off` method:     return () => {       router.events.off('routeChangeComplete', handleRouteChange);     };   }, router.events, contentHistory, router.route);   // final array item from the route is the title of page we are on      // second to last array item (if present) is the topic         }, contentHistory, pageUpdateReady);   return (                                                                                ); } App.propTypes = {   Component: PropTypes.func,   pageProps: PropTypes.shape({}),   router: PropTypes.shape({     route: PropTypes.string.isRequired,     events: PropTypes.shape({       on: PropTypes.func,       off: PropTypes.func,     }),   }).isRequired, }; export default App; "},{"name":"_document","parent":"pages","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/_document.js","content":"  // This custom set-up is necessary to inject the server side // rendered styles into the  // More info here: https://github.com/zeit/next.js/tree/master/examples/with-styled-components export default class MyDocument extends Document {   static async getInitialProps(ctx) {               try {       ctx.renderPage = () =>         originalRenderPage({           enhanceApp: App => props => sheet.collectStyles(),         });              return {         ...initialProps,         styles: (                    ),       };     } finally {       sheet.seal();     }   }   render() {     return (                                                                                                                                    );   } } "},{"name":"Accordion","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/accordion.mdx","content":"       ## Guidance ~~ When seeking to provide maximum content in limited, vertical space, an accordion is a good choice. An accordion is a group of vertically stacked collapsible buttons with title headers. The titles give the user a high-level idea of what content will be disclosed when an accordion panel opens. Accordions help organize information, which helps the user consume the information they need at a faster pace. ### About accordion ~~ Accordion has two states: - Collapsed - Expanded **The chevron icon** is used to identify the expand or collapse action while the entire header can be clicked to expand or collapse content. **The default behavior** is for all of the panels to be closed, with the user only having visual to the heading. **The accordion labels** should be kept short and to the point of the information following in each panel. Lengthy panel content will want to be avoided. ## Accessibility ~~ Buttons are used for the accordion panels which makes them accessible by screen readers and keyboard. Having a very descriptive heading label helps so the user gets to the content section they are interested in faster. Users are able to click anywhere within the panel heading for the state to change to expanded. To help with readability, accordions should only have one panel open at a time. ### WCAG compliance ~~ "},{"name":"All Components","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/all-components.mdx","content":"     {/* TODO replace with DS icon package when available */}  The HPE Design System provides guidance and theming for a large subset of Grommet components, but is not exhaustive. Some, like DataChart(#datachart) and Video(#video) have not yet been customized by the HPE Design System. Others, like Image(#image), Keyboard(#keyboard), and ResponsiveContext(#responsivecontext) provide tremendous utility, but may not require specific HPE styling or guidance. Below you will find a comprehensive list of all Grommet components, examples for each, and either a link to Design System usage guidance or Grommet documentation in cases where guidance is not yet available. Jump to a specific component type: - Layout(#layout) - Type(#type) - Controls(#controls) - Input(#input) - Visualizations(#visualizations) - Media(#media) - Utilities(#utilities) ## Layout ~~ ### Box ~~      ### Card ~~      ### Footer ~~      ### Grid ~~      ### Header ~~      ### Layer ~~      ### Main ~~      ### Sidebar ~~       ## Type ~~ ### Heading ~~      ### Markdown ~~       ### Paragraph ~~      ### Text ~~      ## Controls ~~ ### Accordion ~~      ### Anchor ~~      ### Button ~~      ### Drop ~~       ### DropButton ~~       ### Menu ~~      ### Nav ~~      ### Pagination ~~      ### Tabs ~~      ### Tip ~~      ### ToggleGroup ~~      ## Input ~~ ### CheckBox ~~      ### CheckBoxGroup ~~      ### DateInput ~~      ### FileInput ~~      ### Form ~~      ### FormField ~~      ### MaskedInput ~~      ### RadioButtonGroup ~~      ### RangeInput ~~      ### RangeSelector ~~       ### Select ~~      ### SelectMultiple ~~      ### TextArea ~~      ### TextInput ~~      ## Visualizations ~~ ### Avatar ~~      ### Calendar ~~       ### Clock ~~       ### DataChart ~~       ### Diagram ~~       ### List ~~      ### Meter ~~       ### Spinner ~~      ### DataTable ~~      ### WorldMap ~~       ## Media ~~ ### Carousel ~~       ### Image ~~       ### Video ~~       ## Utilities ~~ ### AnnounceContext ~~       ### Collapsible ~~       ### Grommet ~~       ### InfiniteScroll ~~       ### Keyboard ~~       ### ResponsiveContext ~~                    ### SkipLinks ~~       ### ThemeContext ~~       "},{"name":"Anchor","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/anchor.mdx","content":"        ## Guidance ~~ Anchors should be used when an element with a link is intended to appear visually like a traditional browser link, text with a simple underline. ### Usage of Anchor vs. Button ~~ When deciding whether to use Anchor or Button, consider the visual appearance of the element. If the element will look like a traditional browser link, use Anchor. If there will be background or border styling, use Button(/components/button). Semantically, if you apply an href to either an Anchor or a Button, both will appear as an anchor tag in the DOM. This is why it is important to consider the visual appearance of the element when deciding whether to use Anchor or Button. Here are some contexts in which Anchor should be used: - as inline text links - to add links to resources within contexts such as a form If a clickable element is intended to appear with a background color, border, of hover style, implement this using Button(/components/button). Use buttons when you are performing an action, such as: \"submit,\" \"merge,\" \"create new,\" \"upload,\" or if you are using a combination of icon and label. ### Anchor Labeling ~~ It is important that your anchor clearly states to what content the anchor leads. For example, labels such as \"Account Information\" or \"How to change account credentials\" are both effective labels that allow the user to have confidence in where the anchor will lead them.                         ## Variants ~~ Anchors are used primarily in text heavy contexts. Here are some ways to use them. ### Inline anchor ~~ Anchors are most commonly used as inline elements to bring users to other pages within an application or to external links.      ### Anchor to external site ~~ Using the 'target' and 'rel' props allow you to create smooth user experiences while maintaining security of your application.      ### Anchor in a form ~~ Using an Anchor within a Form(/templates/forms) can link users to additional information that may be secondary to form content.      ### Anchor with icon ~~ In some instances, it can be beneficial to pair an anchor with an icon. For example, it can be helpful to give the user a visual cue when linking to an external page that the anchor will open in a new tab. The position of the icon can be controlled with the `reverse` prop on Anchor.      ### Disabled anchor ~~ Used to indicate that an anchor cannot be interacted with.      ## Accessibility ~~ ### A11y guidance ~~ The following guidance should be considered for each instance of the component and is the responsibility of the implementer. WCAG criteria provided directly by the Grommet component are summarized under WCAG compliance(#wcag-compliance). **Use 'target' and 'rel' props when linking externally:** If clicking an Anchor leads to an external URL, apply these props to the anchor: - target=\"\\_blank\" - rel=\"noopener\" The distinction is important to screen reader users to know what's going to happen next. Will I navigate somewhere or will something happen on the page? The \"\\_blank\" target causes the link to open in a new tab, so the user doesn't lose their place on the application. Adding the \"noopener\" property prevents the newly opened page from gaining access to the original page which helps maintain the security of your application. **Use clear Anchor labels:** It is important to make sure the label of the anchor will allow screen reader users to know where the anchor will lead. Unhelpful Anchor label: - Read more  The word \"here\" is vague. A screen reader user may not know the context of \"here\". Helpful Anchor label: - Read more  This clearly states the type of content to which the Anchor relates. ### WCAG compliance ~~    "},{"name":"Avatar","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/avatar.mdx","content":"   ## When to use ~~ Avatars are used to enable users to quickly identify an object, whether that be a specific user, account, or other entity. Avatars are always paired with additional information, such as a user's name, for better clarity. If possible, use an image or logo over initials. The consistent dimensions of an avatar ensure that readability and scanability of content surrounding the avatar is not compromised. For example, when scanning a data table column that contains an avatar of a company’s logo(/components/avatar#datatable) and the company name, the company name stays aligned from one row to the next. ## When not to use ~~ Avatars are not the only components that provide visual representation. When applicable, use these over Avatars: - Use Icons(/foundation/icons) when representing objects, actions, programs, or other communicative symbols. - Use an image(/components/avatar#avatar-vs-image) when the context of the visual does not need to have equal height and width to maintain alignment of its surrounding content. ## Anatomy ~~ Avatars can be displayed as an image, initials, or a logo. They come in three different sizes: | T-shirt size | Dimensions (in pixels) | | ------------ | ---------------------- | | **small**    | 24x24px                | | **medium**   | 48x48px                | | **large**    | 96x96px                | The container of an avatar can be circular or a rounded square based on the use case. - Use a circular avatar when representing a person by an image or their initials. - Use a rounded square avatar when representing a company’s or entity’s logo. This can be achieved by applying `round='medium'` to the Avatar. - Always round the edges of a square container when using an avatar.      ## Handling logos in dark mode ~~ When possible, provide both a light and dark mode version of a company logo. If a dark mode version of the logo is not available, apply `background={{ color: ‘background’, dark: false }}` to the avatar.      ## Avatar vs. Image ~~ Avatars are not always necessary when presenting a company logo, and in some cases an image is an appropriate choice. For example, when presenting a company’s logo within a grid of cards, an image can be used so that only the height is fixed and the width can grow to fit the logo’s proportions. In this case, the variable width of the logo does not affect the alignment of text from one card to the next.      ## Examples ~~ ### DataTable ~~ Avatars are always used over images within DataTables to maintain visual alignment with paired content. Use `size=small` avatars in DataTables.                         When using avatars in a DataTable, always accompany the avatar with another piece of identifying information such as the user or company's name or email. If an image is not available provide an avatar with initials instead. Use avatar with `size=small` in DataTables.                         ### PageHeader ~~ When applicable, an avatar is aligned to the left of the title within a PageHeader. Use large-sized avatars within PageHeaders.      ## Accessibility ~~  Inform users of assistive technologies what the avatar represents by including an `a11yTitle`. This text will be read out by a screen reader when the user reaches the avatar. If the avatar acts as a button, the `a11yTitle` should also inform the user of what action will occur if clicked.      ### WCAG compliance ~~  "},{"name":"Box","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/box.mdx","content":"       ## Accessibility ~~ ### WCAG compliance ~~  "},{"name":"Button","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/button.mdx","content":"       ## Guidance ~~ The when, how, and why to use buttons. ### About Button ~~ Buttons should be used in situations where users might need to: - Submit a form - Begin a new task - Trigger a new UI element to appear on the page - Specify a new or next step in a process ### Button labeling ~~ Using the design system Button Component will ensure your button looks like a button and is in line with HPE designs. Ensure to apply an appropriate label so the user has a clear understanding of what action to expect. - Use clear and concise wording. - Avoid contractions or colloquialisms. Keep the language approachable but not personal, for examples, see point of view(https://design-system.hpe.design/foundation/voice-and-tone?q=tone#point-of-view). - Ensure your button label matches the route destination. #### When to use \"Add\", \"Create\" and \"New\" ~~ | Label      | Purpose                                                                                                                                                                                                   | Example                                                                                                                             | | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | **Add**    | \"Add\" is used when an object already exists. It builds an association between that object and another object or set of objects.                                                                           | When editing a device group, use \"Add device\" to add an existing device to the group.                                               | | **New**    | \"New\" opens a template, or blank canvas, of a given object type to allow for user input. The object will not be added as a record in a database until a \"Create\" or submission action has been completed. | When starting the configuration process for a new device, use \"New device\" to initiate the process.                                 | | **Create** | \"Create\" is typically used for form submission, to submit user input and create an instance of an object.                                                                                                 | After completing inputs related to configuring a new device, use \"Create device\" to submit the data and create the object instance. | ### Button alignment ~~ Buttons are unique components since their alignment depends on where they appear (drawers, modals, etc.). Buttons should always be where the user most expects it. In general, follow this guide on how to align buttons in most use cases.  ### Button ordering ~~ Button types may be applied in various combinations, however they should always be ordered by order of importance and in relation to their alignment: Primary first, followed by Secondary, then by Default.           ### Buttons vs. anchors ~~ The HTML elements for buttons and links (a.k.a. anchors) describe a very specific type of action that is going to be taken when they are used. It is important you know when to use which, as the distinction matters: - Use a link when you’re navigating to another place, such as: a \"view all\" page, \"Jane Chen\" profile, a page \"skip link\" etc. - Use buttons when you are performing an action, such as: \"submit,\" \"merge,\" \"create new,\" \"upload,\" etc. - An action almost always occurs on the same page ### Cancel buttons ~~ Cancel buttons enable users to exit out of or dismiss the current screen in order to go back to the previous one. Having an explicit way to cancel provides a fallback to safety as it helps discard any unwanted changes. #### Styling ~~ Cancel buttons should be presented in the default button styling. The neutral appearance signifies the non-committal action. Visually emphasizing the cancel button should be avoided to minimize user confusion.                         ### Toggle buttons ~~ Toggle buttons are used either to switch between two states, such as checked and unchecked, or to trigger two actions like on or off. #### Toggle buttons with icons ~~ Icon buttons have an `a11yTitle`, `aria-label` or button `label` that describes the action that the user will be performing when using screen readers. **Best Practices:** - Limit to 2-3 descriptive words. - Use verbs first to describe the action such as \"Hide/View,\" \"Switch/Unswitch,\" \"Favorite/Unfavorite,\" \"Light/Dark,\" or \"Like/Dislike.\" - Use sentence case capitalization. - Words such as \"the\" and \"a\" should be avoided. For buttons with icons ONLY, it is important that you show the two following elements: 1. Show the current state of the button through the use of an icon. 2. Inform the user of what will happen when the button is clicked by including `a11yTitle` or `aria-label`. ## Primary buttons ~~ Primary buttons highlight actions on a page delivering the most benefit to users. They are helpful in enabling users’ goals, unlocking new value by enabling a new experience, capability, or creation of something which hadn’t previously existed. Primary buttons have increased visual weight through placement and contrast, drawing users’ attention by distinguishing the button from surrounding content. ### When to use a primary action button ~~ Primary action buttons are used within enterprise applications. They are meant to assist and are designed to maximize a user’s experience by highlighting the most common or important action on a page and allowing the user to accomplish a goal or task. Actions supported by primary action buttons are numerous and may be constructive or destructive in nature. Example actions include: create, schedule, deploy, add, save, and depending on context could even be cancel or delete. ## Variants ~~ There are a couple \"flavors\" of button depending on use case. ### Primary button ~~ Used for the key action on the page, and should only appear once. All other supporting actions should use Default button(#default-button). Consider that the 80% use case for some pages is visualization and not action. In cases like these, a secondary button can be used.      ### Secondary button ~~ Secondary buttons are used to represent calls to action that are either in support of the primary call to action or stand-alone. There can be multiple secondary buttons per page. However, a default button(#default-button) should be used for any navigation-type actions.      ### Toolbar button ~~ Toolbar buttons are used when buttons are placed in a row with other toolbar controls. A common use case would be when creating a filtering experience(/templates/filtering). In this situation, a search input, filter button, and action menu are presented as a unified set of controls. The intent is to present each control with equal prominence. To implement, apply `kind=\"toolbar\"` to Button(/components/button) or Button-based components like Menu(/components/menu).      ### Default button ~~ This is the default appreance and behavior of button. The majority of buttons on your page should use this form of button. If you are designating a primary call to action, use a primary button(#primary-button). If you are designating a secondary call to action, use a secondary button(#secondary-button).      ### Button with icon ~~ Icons may be incorporated into buttons, either inline with text or as an icon only. When using icon only buttons, the dimension of the clickable area should be kept in mind for its use on mobile devices. Areas too small lead to errant clicks, and as result, poor experience.      ### Button with badge ~~ The `badge` prop adds a small indicator to a Button to convey extra information, such as a notification or count. It can be used in different ways depending on what needs to be communicated: - To indicate that something is new or needs attention, the badge can be set to true to display a simple dot. - To show how many items there are — such as 3 new messages — a number can be passed, and the badge will display that value.   - If the value exceeds the max, the badge will display a \"+\" next to the max (e.g., 9+) to keep the visual presentation clean and readable. By default the max is 9, but this can be adjusted based on what max value best suits the use case.      ### Button states ~~ A button's visual state may be specified as appropriate in the application's context. For example, using \"active\" for the current item or \"disabled\" until a set of criteria are met. However, use of disabled controls is discouraged because it tends to elicit a \"why?\" response from users. It is better to leave buttons active and use messaging upon click to indicate that criteria have not been met. Buttons that do not apply (for reasons of context or permissions) should not be shown at all, rather than being shown as disabled.      #### Busy button ~~ The busy and success states of button can be used when an action may take a couple of seconds to complete or validate. A common example is when a form requires server side validation. If the action will likely take longer than a few seconds to complete, allow the user to leave the form and do not use the busy button state. Instead, consider notifying them with another kind of notification when the task completes.           ### Button sizes ~~ Button label text size may be specified. Padding and rounding scale proportionately to the label size. The default size is medium.      ## Responsiveness ~~ Ensure you are always being mindful of our responsive page layouts when designing user experiences. Even if you don’t anticipate your users leveraging mobile or tablet devices, they may be reducing/expanding browser widths, zooming in on content, or manipulating the browser in unanticipated ways. As a best practice, always design for a usable UI on all browser widths and resolutions. ### Best practices ~~ - Ensure the button label does not wrap, truncate, or alter the text content in any way when presented on smaller browser widths. - Button label text should not scale down to fit on smaller browser widths. - The minimum button width for any button should be 42px. ### Single buttons ~~ On screen widths of less than or equal to 576px (Grommet \"small\"), it is best to have buttons fill the full width of the container. Because press target size and an unclear visual hierarchy are key concerns at smaller resolutions, this utilizes available space to ensure users can easily identify and interact with the buttons.                         ### Button groups ~~ For button groups on screen widths less than or equal to 576px (Grommet \"small\"), ensure each button within the group follows the established guidance for single buttons. If a button group is presented inline horizontally, rearrange the buttons vertically on smaller browser widths to ensure the proper full button widths can be achieved.                         ## Accessibility ~~ ### A11y guidance ~~ The following guidance should be considered for each instance of the component and is the responsibility of the implementer. WCAG criteria provided directly by the Grommet component are summarized under WCAG compliance(#wcag-compliance). If pressing a Button results in a new URL, or the resultant UI makes sense as \"a new browser tab,\" that is a link ``. Everything else is a ``. The distinction is important to screen reader users to know what's going to happen next. Will I navigate somewhere or will something happen on the page? So it's important to choose the right HTML element for the job. If using an `` tag, see the WCAG rules for the Anchor component(/components/anchor#wcag-compliance). ### WCAG compliance ~~  "},{"name":"Call To Action Card","parent":"card","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/card/call-to-action-card.mdx","content":"   This type of card is more commonly used within marketing contexts and should be used sparingly within HPE products and services. Secondary purposes might include an action to navigate to a screen with greater detail on the offering.      ## Example use cases ~~ - Request a trial - Register for an event - Launch a demo for an upcoming feature release - Upgrade software version   - This encourages users to stay on the latest version to avoid bugs, legacy software. ## Anatomy ~~      1. **Card identifier**: This region is intended to provide the user with context on what the card is about.    - a. **Title** (required): For Call to action cards, this should be a unique, enticing headline to capture the user's attention.    - b. **Pretitle** (optional): Additional context for what this call to action is about (e.g., \"Virtual event\").    - c. **Subtitle** (optional): Any concise, additional supportive text to help establish the card's identity and context. 1. **Actions** (required): Card-level actions.    - A primary or solid-filled button labelled with the main call to action is required. At times, additional supporting actions/links may be appropriate. 1. **Description** (optional): A short paragraph that elaborates on the card's purpose. 1. **Image/Media** (optional): An eye-catching, brand-approved image(https://brandcentral.hpe.com/brand-central/content/distinctive-brand-assets/flexible-ingredients#p1-photography-style-1) that grabs the user's attention. Use of this area should be reserved for highly promotional cards like events and feature announcements. 1. **Background** (optional): A background color or brand-approved texture/gradient(https://brandcentral.hpe.com/brand-central/content/distinctive-brand-assets/flexible-ingredients#c3-color-and-texture-style-3).    - When using a texture or gradient, be mindful to maintain appropriate color contrast between the card's text and the background. ## Presentation ~~ - Call to action cards may be presented in a group with other call to action cards but also may be presented on their own. - When presented in a group, their layout/treatment can be independent from the layout/treatment of the surrounding call to action cards. - Highly promotional call to action cards, such as event promotions, incorporate stronger visual elements. Less promotional cards, such as software updates, are more subtle.   - Use cases (ordered from highest visual emphasis to lowest) include event promotion, new feature release, trial promotion, and software upgrades. ## Examples ~~ These are example layouts for various use cases. ### Event promotion ~~ Event announcements are highly promotional, so they should leverage attention-grabbing card elements such as images, that accentuate the dynamic and vibrant experience that an HPE event provides.      ### Event promotion (row-orientation) ~~ Depending on where a card is presented in a layout, it may be more appropriate for its content to be displayed in a row.      ### Feature update ~~ Announcements about new offerings and features should excite current and potential customers about HPE's services. The use of this brand-approved gradient allows this card to stand out from its surrounding content.      ### Trial promotion (background image) ~~ The use of this brand-approved texture subtley differentiates this card from surrounding content.      ### Trial promotion (row-orientation) ~~ Depending on where a card is presented in a layout, it may be more appropriate for its content to be displayed in a row.      ### Trial promotion (background color) ~~ A colored background can be used to differentiate a card from its surroundings.      ### Feature release ~~ An attention-grabbing title attracts user attention and encourages them to upgrade to the latest version.      "},{"name":"Index","parent":"card","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/card/index.mdx","content":"        ## Principles ~~ Cards are containers that display content and actions on a single topic. They should be easy to scan for relevant and actionable information. **Contained** - A card is identifiable as a single, contained unit. **Independent** - A card can stand alone, without relying on surrounding elements for context. **Individual** - A card cannot merge with another card, or divide into multiple cards. **Summarized** - A card by nature has limited real estate, so it should present summarized information. Cards should be used when: - Presenting high-level, summarized pieces of information. - Presenting an item, or collection of items, which can best be consumed visually. In all cases the presentation allows users to quickly scan the content and navigate to underlying detail if desired. ## Types of cards ~~ A card is a rich, flexible UI component; its anatomy, visual/interactive treatments, and relationship to its peers help to establish and reinforce its purpose. The following are distinct types of cards that have unique purposes and best practices.  ## Formatting ~~ ### Alignment ~~ Use left-alignment whenever possible in order to optimize readability.                         ### Spacing ~~ Follow the proximity principle(https://www.nngroup.com/articles/gestalt-proximity/)  when applying spacing between a group of cards and between other content sections. Apply  a uniform gap between cards so that they are perceived as belonging to the same group. This  spacing should be less than the gap between other content sections.        ## Interactions ~~ ### Mouse ~~ - If a card does not contain an action behavior, do not provide hover feedback. - If a card has a singular action behavior, the entire card may be clickable.  Apply a `pointer` cursor and `large` elevation for the hover state. - If a card contains multiple interactive elements, provide hover feedback on the interactive elements, not the card itself. ### Keyboard ~~ | Key         | Interaction                                                                                                           | | ----------- | --------------------------------------------------------------------------------------------------------------------- | | Tab         | Move forward through the cards (if entire card is clickable) or through logical order of the interactive elements.    | | Shift + Tab | Move backward through the cards (if entire card is clickable) or through logical order of the interactive elements.   | | Enter       | Perform the card action (if entire card is clickable) or the corresponding action of the focused interactive element. | ## Accessibility ~~ ### Card titles ~~ Card titles should use a Heading of the correct semantic heading level(/foundation/typography#semantic-usage-of-heading-levels)  based on where the card is in the document. For example, a card nested under a  Heading level 2 should use a Heading level 3 for its title (Note: If desired,  a heading's size may be adjusted to achieve the desired aethetic, but always use  the proper level). Text should not be used for the card titles. Assistive technologies rely on HTML  heading or aria-labels for understanding a card's title. ### Card sections ~~ When cards are presenting as a group, they should function as a list. - Apply `as=\"ul\"` or `as=\"ol\"` (depending on if the list is orderded or not) to the cards' layout container (whether that be a Grid(/components/grid), List(/templates/lists), or other layout component).   - Some default browser padding may need to be overridden. This can be done by applying `pad=\"none\"`, or the desired padding, to the container. - Apply `as=\"li\"` to the individual cards. ### WCAG compliance ~~  "},{"name":"Navigational Card","parent":"card","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/card/navigational-card.mdx","content":"   Navigational cards enable the user to identify, compare, and choose their desired next step.      ## Anatomy ~~      1. **Card identifier**: This region is intended to provide the user with context on what the card is about.    - a. **Title** (required): For navigational cards, this should be the name of the page the user will be navigated to.    - b. **Icon/Avatar** (optional): A unique icon/avatar that assists the user in identifying their desired navigational path. 1. **Action** (required): If there is a single action on the card, the entire card should be clickable. If the entire card is clickable, a visual of a button in not required in the card. 1. **Description** (optional): A short paragraph that elaborates on the destination of the card. ## Presentation ~~ - Present navigational cards in a group with other navigational cards of the same category.   - For example, a group of navigational cards may be used to provide a user with a means of navigating from a hub called “Manage” to various spoke pages such as “Roles and Permissions”, “Account Settings”, etc. - Use the same anatomy and layout as other navigational cards in the same group.   - This visual consistency further establishes the relationship that these cards are part of the same category. ## Examples ~~ These are example layouts for various use cases. ### Single action ~~      ### Single action, no button ~~      ### Primary and secondary actions ~~      ### Row-orientation ~~      "},{"name":"Checkbox","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/checkbox.mdx","content":"       ## Guidance ~~ CheckBox can be used to present an individual option or group of options to the user. When presented in a group, the user can select a single or multiple options. Refer to CheckBoxGroup for examples. ### Usage ~~ CheckBox should not be used if a user should only be allowed to select one option from a list of options. In the case that a user should only be able to select one option, refer to RadioButtonGroup(/components/radiobuttongroup). There are three states which CheckBox provides: - Unchecked - Value has not been selected. - Checked - Value has been selected. - Indeterminate - Used in situations where the CheckBox is a parent to a list of child options. Use the indeterminate state to indicate that only a subset of the child options have been checked. Checked and unchecked states refer to when an individual CheckBox is checked or when all options from a group are checked. ### CheckBox outside of FormField ~~ A checkbox might be used outside of a form field when: 1. Serving as a UI control showing or hiding page content, such as revealing additional content or inputs which are only relevant when a particular feature is enabled. 2. Scenarios in which having a form field label in addition to the checkbox label would be redundant for the user. 3. Allowing a user to opt-in or acknowledge a disclaimer, such as a privacy policy or terms and conditions. 4. Allowing an item to be selected within a list, table row, or drop down. ### Toggle ~~ - Toggle is a single option which prompts users to choose between two mutually exclusive options. - Toggle is preferred to quickly switch between two possible states. Toggles usually provide immediate results (i.e. no form submission is required) in which gives users the ability to control their preference. - When using toggles the order of text and toggle can be controlled using the reverse prop(https://v2.grommet.io/checkbox?theme=hpe#reverse). If the toggles   are used in a group that contains only toggles then it is preferred to have the text on the left and the toggle on the right. ## Variants ~~ CheckBox can be used individually, within a group, or as a toggle. A standalone or toggle checkbox indicates that a user is opting-in to the context of the checkbox. Within a group, one or multiple checkboxes can be selected. ### CheckBox with description ~~ Adding a description provides the user additional information about the context or purpose of the checkbox.      ### Toggle ~~ Toggle is a great choice to use when the user is given a single option that they can turn on or off.      ### Validation ~~ Validation is used to show that the checkbox does not meet the validation requirements of its bounding FormField.      ### Disabled ~~ Used to indicate that CheckBox cannot be interacted with.      ## Accessibility ~~ CheckBox should be used inside of a FormField to ensure that a label is properly associated with the input. The labels on individual checkboxes should clearly describe the purpose of the checkbox. If a CheckBox is used outside of the context of a FormField, it is important to meet accessibility requirements in an alternate way. There should always be clear visual indication, either by text or icon, that describes the purpose of the checkbox. ### WCAG compliance ~~   "},{"name":"Checkboxgroup","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/checkboxgroup.mdx","content":"       ## Guidance ~~ CheckBoxGroup should be used to present a group of options to the user. The user can select a single or multiple options. ### Best practices ~~ - CheckBoxGroup should be used to select zero or more options from a list. - In a CheckBoxGroup, options are independent from one another. - Settings changed by checkboxes should not take effect until the user clicks to proceed. - It is recommended to have only 4 or fewer options in a CheckBoxGroup. - Use SelectMultiple(/components/selectmultiple#best-practices) when multiple selections can be made in a list containing 5-9 items; use SelectMultiple(/components/selectmultiple#best-practices) with search when containing 10 or more items. ### Usage ~~ **The dos for CheckBoxGroup:** - Always label CheckBoxGroups with short and concise labels. - Give every CheckBox in the group a short, but descriptive value. - Clearly separate Checkbox Groups from other groups on the same page. - Organize Checkboxes in a logical order by grouping related options. - Consider placing most common options first in the group. **The don'ts for CheckBoxGroup:** - Don’t align checkboxes horizontally in a group. - When only one item can be selected from a list, use the Select(/components/select) component instead. - When multiple selections can be made in a list that contains 5 or more items, use SelectMultiple(/components/SelectMultiple). ## Variants ~~ CheckBoxGroup contains multiple checkboxes and has various states. When enabled, CheckBoxGroup should always allow one or more options to be selected. ### With description ~~ Adding a description provides the user additional information about the context or purpose of the CheckBoxGroup.      ### Validation ~~ Validation is used to show that the CheckBoxGroup does not meet the validation requirements of its bounding FormField.      ### With options as array of objects ~~ CheckBoxGroup options are typically an array of strings, but they can also be an array of objects.      ### Disabled ~~ Used to indicate that CheckBoxGroup cannot be interacted with.      ### Scroll ~~ When many options are available and vertical space is limited, a scrollable checkbox group may be considered.      ## Accessibility ~~ When using multiple checkboxes in a single FormField, use a CheckBoxGroup. If you're using a single checkbox, use CheckBox(/components/checkbox). ### WCAG compliance ~~   "},{"name":"Data","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/data.mdx","content":"  Data is the orchestrator for a set of subcomponents. These components work together to create the entirety of the experience, we like to refer to them as \"Data and friends\".      For additional guidance on filtering patterns, see the filtering documentation(/templates/filtering). ## How to use ~~ There are two main ways to build with Data and friends: | Approach          | Definition                                                                                                                                                     | Notes                                                                                                             | | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | **Configurable**  | This approach relies solely on the properties available on the Data component itself.                                                                          | --                                                                                                                | | **Compositional** | This approach allows you to import the subcomponents directly to compose your layout, while still leveraging some of the properties on Data for configuration. | This approach is most useful when you want to add additional controls to the toolbar beyond search and filtering. | To learn more about how to build with Data and friends in Grommet, check out the how-to guides on the Learn page(/learn). "},{"name":"Datafilter","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/datafilter.mdx","content":"       ## Guidance ~~ Based on the type of data for that property, DataFilter determines a suitable \"smart default\" for what kind of input to present. The \"smart default\" is determined based on the following criteria: | Type       | Number of options    | Default filter type        | | ---------- | -------------------- | -------------------------- | | **string** | Less than 5 options  | CheckBoxGroup              | | **string** | 5-9 options          | SelectMultiple             | | **string** | More than 10 options | SelectMultiple with search | | **number** | --                   | RangeSelector              | ## Accessibility ~~ ### WCAG compliance ~~   "},{"name":"Datafilters","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/datafilters.mdx","content":"  When presented in a layer or drop, DataFilters will manage adding a badge on the filter button based on how many filters are applied and rendering a \"Clear filters\" button.      ## Accessibility ~~ ### WCAG compliance ~~   "},{"name":"Datasearch","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/datasearch.mdx","content":"       Use alongside other Data components(/components#data). ## Accessibility ~~ ### WCAG compliance ~~  "},{"name":"Datasort","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/datasort.mdx","content":"       ## Accessibility ~~ ### WCAG compliance ~~  "},{"name":"Datasummary","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/datasummary.mdx","content":"  This includes a summary of how many results out of the total are showing based on search or filter criteria. Additionally if individual records have been selected, such as onSelect with DataTable, it includes a summary of how many items are selected.      ## Accessibility ~~ ### WCAG compliance ~~    "},{"name":"Datatable","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/datatable.mdx","content":"         ## What makes up a DataTable? ~~ DataTables enable users to accomplish a task by finding records of interest, then take action against them. They present structured data in a grid, with columns and rows to aid readability, scanability, and show the meaning of the data.  **Controls** DataTable controls should live above the table and facilitate a user's ability to locate and take actions against records of interest. A controls section may contain search and filter controls(#searching-and-filtering-datatables), as well as action controls(#selecting-multiple-records-and-batch-actions) such as batch applying settings or data export. **DataTable header** Contain table header cells concisely labeling the column's contents. Column headers may be enhanced by enabling sorting(#sorting). **DataTable body** Consists of rows allowing users to scan, read and take action on the data. Rows may be enhanced by enabling actions such as record selection(#selecting-multiple-records-and-batch-actions) and navigation to a record's detailed view. **DataTable footer** Optional. Used for presenting summary counts, sums, averages, and other aggregations(#column-summaries-and-aggregation). ## When to use ~~ Users interacting with a DataTable are trying to accomplish one of the following types of tasks. They are not, however, trying to do all of these tasks at once. Keeping \"what is the user setting out to accompish?\" at the center of our mindset helps guide which table features to include and, more importantly, exclude when we add a Table to our interfaces. ### Finding a specific record ~~ Often, a user's task is to find and take action against a specific record. Whether it be finding a customer's record to review their chat history, tracking a particular order's status, etc., the user experience objective is to enable a user to locate that record as quickly as possible. - Use Search(/components/datasearch). This is often the quickest, most efficient method for users to find a record of interest. - As backup, use sortable columns coupled with paginated results. This combination   provides users with the knowledge of alpha-numeric range, enabling an   educated guess as to the record's location in the sort. ### Narrowing a result set ~~ When users want to focus on a subset of records that share similar characteristics, filter controls(/components/datafilters) enable progressive narrowing of the DataTable’s results. - Provide filter controls to allow users to scope the visible result set. - Choose filter controls that align with the data type and value range,   keeping filtering predictable and efficient. Learn more about providing a great filter experience(/templates/filtering). ### Browsing a result set ~~ Sometimes users are in a browsing or exploratory mode and do not have specific records in mind. In these cases, they are assessing the overall state of their data. The primary experience goal is to support quick scanning, enabling users to easily spot outliers, trends, or records that may require attention or action - especially those they were not previously aware of. #### Options to enhance browsing experience ~~ - Make columns sortable(/components/datasort) to allow users to order records by value,   helping them more easily compare data and identify patterns,   outliers, or priority items. - Use meaningful column data types - such as status indicators(/templates/status-indicator),   badges, or meters - to visually surface records that may   require attention or action. - When a data set is large, pagination(/components/pagination) segments the records into fixed pages,   while infinite scroll enables continuous exploratory scanning. ### Assembling a data set ~~ Distinct from the user objectives above, data tables containing data for analytical purposes deserve distinct treatments as well. While data tables are useful for providing initial \"discovery\" type insights, such as identifying available attributes and ranges of values, purpose built tools are often a better choice for conducting in depth analysis. In this scenario, a data table's design should be optimized for assembling the data set for analysis and easy portability of that data into the user's preferred analytical tool. - Provide filter controls(/templates/filtering#controls). - Filter control input types should be chosen to best fit the data type and breadth of values. - Provide export capability for users to consume the data in their analytical   tool of choice. - Provide aggregate measures in the table footer(#column-summaries-and-aggregation). - Organize table columns to group like elements and to keep most important elements to the left. ## Guidelines ~~ ### Setting the width of a DataTable ~~ - Use the correct set of columns, prioritizing frequently used ones. Don't add more columns just because the data is there, as this will clutter the data table. - To support readability, make tables only as wide as they need to be and no wider. If the content does not need a large width, prevent the table from stretching. - Limit the whitespace on individual columns by using size for data table columns. - When the data table has the potential to be wider than the screen:   - Use 'pin' to anchor the primary column to preserve row context.   - Use horizontal scrolling within the data table, as opposed to scrolling at the level of the entire page - When the data table has the potential to be narrower than its layout context:   - Align it horizontally with the rest of its layout context. Typically, this is aligned to the start of the content as opposed to stretched.   - Align any header above the table, including heading, search, filter, actions, in the same way. This keeps an actions menu or button in the context of the data table and prevents them from being orphaned. However, don't force the header above the data table to align its width to the data table, as that might compress the contents of the header too much. ### Setting the height of a DataTable ~~ - Let the data set the height of the data table. The data table will grow in height as the length of data increases. - If it is expected a user will want to navigate to a specific portion of the data, pagination should be used. Generally, it is recommended that each page of data table results be limited to 20 records. For more information on pagination, read Pagination guidance(/components/pagination#when-to-use-pagination). - Do not restrict the height of a data table if the page has available space. This may introduce unnecessary scrolling. - If the height of a Table needs to be restricted, set `overflow=“auto”` on its parent Box to allow the user to scroll through the data. ### Wrapping and truncating ~~ When text exceeds the amount of space available within a table cell, wrapping(#wrapping) or truncation(#truncation) may be used depending on your use case. Below are some best practices to consider when implementing. - For readability, avoid truncating or wrapping text within the first column. - Keep each cell short and concise, limiting the amount of characters within a cell when possible. - Minimize the number of included columns by only showing those which are used most frequently. ### Truncation ~~ **Truncation should not be used on headings, numeric values, or statuses.** Truncation may be applied at the beginning, middle, or end of a piece of data. When choosing where to apply truncation within a string, consider which section of the text is most likely to differentiate the item from others in the column. Additional questions to keep in mind when using truncation: 1. How much information loss is acceptable? 2. What impact is caused by any amount of information loss? 3. When creating the data, can it be structured so that a table can truncate it in such way that the information loss is kept to a minimum? #### Options for Positioning Truncation ~~ **Front-text** Front-text truncation is when an ellipsis is placed at the beginning of a long string. This is best used when the start of a string is similar to many other cells, such as text containing a common prefix. **Mid-text** For recognizability, it may be better to crop the middle of a string. Define the parts of the content which need to be preserved in order to keep recognition high and should not be truncated. This strategy can be used when both the beginning and ends are uniquely identifiable. **End-text** End-text truncation is when the ellipsis is placed at the end of the string. If truncating numerical values is absolutely necessary, use end-text truncation. Additionally, provide a tooltip(/components/tip) to help users view the complete string. ### Wrapping ~~ Wrapping allows long strings of text or words to break and wrap onto subsequent lines. Wrapping should be used when: - The entirety of the content must be available at all times. - Long numerical values need to be displayed. ### Handling empty cells ~~ If the value of a cell is empty, use `--` in place of where a value would appear. This visual indicator aids the user in identifying fields that do not have values while also maintaining the scanability across rows and columns. Because the HPE theme does not have borders or background color differences to differentiate between rows and columns, a visual indicator in empty cells is necessary to maintain readability and scanability. For empty cells, add an `a11yTitle=\"No value\"` to the Text component that would otherwise render the data to ensure users of assistive technology are informed of the empty state.      ### Status and state ~~ Statuses within a DataTable should always have these accompanying elements: - Shape - Color - Content (**_This is not restricted to just normal, warning, unknown, and critical_**) Greater detail, including accessibility considerations, is included on the status indicator(/templates/status-indicator#what-makes-up-a-status-indicator) page. A state is the current stage of a process. A status is the condition of the state. Status can also be thought of as a pointer to a state’s “health”. Read more about the distinctions between state and status(/components/notification#state-vs-status). Depending on the scenario, status and state may be displayed within a DataTable in one of three ways: 1. Separate columns for status and state(#1-separate-columns-for-status-and-state) 2. Status only column(#2-status-only-column) 3. Combined column(#3-combined-column) #### 1. Separate columns for status and state ~~ When status and state are distinct and independent from each other, display them in separate columns. This is the most common use case. - Used when the status column is not coupled with the displayed state column. (Ex. An equipment can have a “Normal” status but have a “Running” state shown within the DataTable.) - Allows columns to be sorted independently from each other. - Clearly visually separates and labels status and state to avoid false associations.      #### 2. Status only column ~~ - In some use cases, displaying status on a DataTable is more important to users than state. If this is true for your use case, feel free to display only the status in the DataTable. - Used in situations where horizontal screen real-estate is an issue. - If displaying state is required, provide the user the ability to view the record's detail. State may be displayed once the user selects the row for more information.      #### 3. Combined column ~~ When the status and state are coupled, they may be displayed as a single element. - Coupled statuses have a 1:1 relationship with specific states. - A single column presents both status and state. Status represented by a status indicator(/templates/status-indicator) and state as the accompanying label. - Status and State are sorted together rather than individually. - **_Note: A single column is rarely used. Ensure false associations are not created when status and state are not coupled._**      ## DataTable behaviors & actions ~~ ### Sorting ~~ Column headers behave as a button and perform the sort action. A caret icon indicates the directionality and to which column the sort is currently applied.      ### Resizeable columns ~~ Columns can be resized if a DataTable has the `resizeable` prop applied. Column resizing allows the user to change the width of the header columns. Each column can be resized by dragging the right side of its header to the left or to the right to expand the column.      ### Searching and filtering ~~ Complementary elements such as search or filters should be guided by the task the user is setting out to accomplish. - Looking for a specific record? --> Search. - Trying to narrow records down to a set of shared characteristics? --> Filter. - Not quite certain for what I am looking, but I know its general characteristics? --> Filter. See Filtering(/templates/filtering) for greater detail. ### Navigation via DataTable ~~ Clicking on a data table row takes the user to a context where the most prominent heading matches the primary column text. This context could either be a page or a modal. In this example, clicking on a table row navigates to a detail page.      ### Selecting multiple records & batch actions ~~ Checkboxes allow for selection of multiple records, which then may apply batch actions via action control buttons or menus.      ### Paginated ~~ With long sets of data, pagination can help to create a more efficient means of navigating to a specific item or range of items.      ### Server-side paginated table ~~ In this example, data is dynamically fetched using an API call and rendered as a paginated DataTable. This approach is preferred for DataTables that may have large amounts of records because, by loading only a page worth of data at a time, it ensures the DOM doesn't become overloaded.      ### Fixing header row and/or columns ~~ Fixing or pinning header rows, columns, or footers allow users to track and maintain context across long and wide data sets.      ### Column summaries & aggregation ~~      ### Use pagination or infinite scroll ~~ Should be guided by the task the user is setting out to accomplish. - Browsing? --> Infinite Scroll   - Perhaps I am reviewing a customer's account history. I am not looking for     a particular record, rather I am in scanning mode, trying to get a sense of     the volume and types of interaction with a customer over time. Infinite Scroll     creates a nice, frictionless experience for this to occur. - Searching for a specific record? --> It depends.   - Do you have a good search experience? --> Infinite Scroll   - Do you have a performant API?   - Do you require page reloads?   - Is your data structured? - Do rows have many interactive elements? --> Pagination   - Be mindful of keyboard users. ### Vertically align row data ~~ When a column has multi-line data, it may improve readability to align the data to the top of the row. In these cases, apply `verticalAlign={{ body: 'top' }}` to the DataTable.      ## Accessibility ~~ To ensure screen readers are able to associate a page heading with a given DataTable, apply an `id` to the Heading and `aria-describedBy` to the DataTable, where the same string value is applied to both attributes. When a screen reader reaches the data table, it will announce the Heading content which provides the user with better context about the table data and purpose. For example, if on the Heading you apply `id=\"storage-pools-heading\"`, on the DataTable you would apply `aria-describedBy=\"storage-pools-heading\"`. In this example, the screen reader would properly associate \"Storage Pools\" as the description for the DataTable.  ### WCAG compliance ~~  {/* To be added. Placeholders for future content. */} {/* ### Pagination */} ~~ {/* ### Infinite Scroll */} ~~ {/* ## Table Cells */} ~~ "},{"name":"Datatablecolumns","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/datatablecolumns.mdx","content":"       ## Accessibility ~~ ### WCAG compliance ~~   "},{"name":"Datatablegroupby","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/datatablegroupby.mdx","content":"       ## Accessibility ~~ ### WCAG compliance ~~ "},{"name":"Dataview","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/dataview.mdx","content":"       ## Accessibility ~~ ### WCAG compliance ~~ "},{"name":"Dateinput","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/dateinput.mdx","content":"       ## Guidance ~~ - DateInput can be used to display past, present, or future dates and times. - DateInput provides a more guided experience for collecting dates from the user rather than a plain TextInput. - The format provides MaskedInput constraints on what can be typed and auto-fills fixed characters. - The Calendar Drop provides a familiar visual grid interface. ### When using DateInput, you should: ~~ - Use a label to instruct user what to do with the control. - Labels should be clear and descriptive. - Correctly format dates to reduce mistakes, such as having the caller specify   the appropriate date format for the locale the user is in. - For example, in the U.S. dates are formatted as ‘mm/dd/yyyy’ whereas   in other countries, such as Europe it might be ‘dd/mm/yyyy’. ## Variants ~~ DateInput can be configured to support selection of a single date or a range of dates. ### Single date ~~ A single DateInput users can either manually input a date or select a date from the calendar      ### Date range ~~ DateInput can be configured to allow users to select a start and end date. Users will need to use the calendar to select the range of dates.      ### Validation ~~ Error messages should clearly identify when a DateInput was not correctly completed and what the user needs to do to fix the error.      ### Readonly ~~ Used to indicate that a DateInput cannot be edited. When an input is readonly, it will still receive tab focus and be submitted with form data. Apply `readOnlyCopy` to DateInput to display a copy button in the input.      ## Accessibility ~~ ### WCAG compliance ~~    "},{"name":"Fileinput","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/fileinput.mdx","content":"        ## Guidance ~~ FileInput is a specialized input providing users a means to select a file or files for upload. ### Usage ~~ - User must be able to upload a file by clicking the \"Select file\" button, dragging and dropping a file over the drop region, or tabbing to the FileInput and pressing the Spacebar or Enter key. - When FileInput is in a Form, the file should not be uploaded/saved to a server until the user has submitted the form. - Once a file has been added to the input, a button featuring a Trash icon will appear next to the file name allowing removal of that file. - The \"Select file\" button should always be visible, allowing the user to add more files/replace a file after they have already selected one. For additional configurations, such as defining accepted file type, all instrinsic HTML properties are supported. For a comprehensive list of these options, you can read more about HTML input type=\"file\"(https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file). ## Variants ~~ FileInputs may be configured for uploading single or multiple files. ### FileInput with multiple files ~~ To allow multiple files to be uploaded, add the prop `multiple`.      ### FileInput validation ~~ When a file provided to FileInput does not meet its validation criteria, such as file size or type, ensure the user has means to remove the file from the input.      ### FileInput with file removal confirmation ~~ In some cases, it may be appropriate to display a confirmation modal when a user attempts to remove a file. For example, if any time consuming file scanning processes have occurred, a confirmation modal should be used to avoid accidental file removal which results in the user needing to go through the file scanning processes again. To see this behavior, add a file then click the \"Trash\" button to see the confirmation.      ### FileInput within a form ~~  ## Accessibility ~~ When using FileInput within a Form, the FormField wrapping the FileInput should have `htmlFor` and `name` properties that match the `id` and `name` properties placed onto the FileInput. Reference the FileInput within a Form example(/templates/forms#required-and-optional-fields) to see how to implement. **Filename truncation:** If displaying the entire file name is critical to the users understanding of the component and the name is getting truncated, the `renderFile` property should be used to display the full file name. ### WCAG compliance ~~  "},{"name":"Footer","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/footer.mdx","content":"       ## Guidance ~~ Footer is used at the bottom of an application. It provides buttons that link to company information and other important links to secondary pages that may not be part of the Header(/components/header) navigation structure. ### Usage ~~ A footer is a consistent element to be used at the bottom of all of your applications or webpages. Unlike Header, Footer is not as flexible and contains certain required elements. The most common footer is an App footer(#application-footer) which is contains legal and other important resources that pertain to the entirety of an application. The other type of footer is a Page footer(#page-footer) which contains additional actions or resources specific to a single page of an application. ### Application footer ~~ A simple, clean and straightforward app footer displays useful information for the user that couldn’t be displayed on the header. This Footer is typically present on every screen of an application and its contents are universal to the entire application. **Always provide these essential links in your footer:** 1. **Copyright information** - It is vital to make it clear that the content within the    website and applications is protected and copyrighted. 1. **Terms of Use** - These guidelines will help ensure partners and customers the    terms of doing business with us. 1. **Privacy** - As a large corporation, it is essential to display a link to    our privacy policy page to let users know that we follow GDPR laws. 1. **Security** - It is important for users to get an overview that explains    our security processes and tools that are used to protect data and users. Check out this simple Footer example(#) to see how these essential elements are included within a Footer. ### Page footer ~~ A page-level Footer provides additional resources or functions for a single page within an application. **A page-level Footer should:** - always be used in addition to the App Footer - be placed above the App Footer in the layout - contain actions relevant to a single page of an app For more guidance, check out an example of how to use a page-level footer(#footer-for-a-single-page). ## Variants ~~ There are various action elements that may live in a Footer, depending on the application or page context. ### Footer for a single page ~~ A Page Footer should never replace the App Footer. It should be used in addition to the App Footer and placed above the App Footer in the layout. The actions or resources within a Page Footer should pertain only to the content within the current page.      ### App footer with page footer ~~ Here is how to stack a Page Footer with an App Footer in your layout.      ## Accessibility ~~ Wrap buttons at the bottom of a page in a Footer to inform screen readers that the contained content is part of a page footer. This meets accessibility requirements to contain all page content in relevant landmarks. For more information, you can read more on using landmarks to identify page regions(https://www.w3.org/TR/WCAG20-TECHS/ARIA11.html). ### WCAG compliance ~~  "},{"name":"Grid","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/grid.mdx","content":"       ## Getting to know Grid ~~ Grid is a powerful tool. It provides tremendous flexibility and control enabling designers and developers at HPE to create optimal user experiences at any screen size or resolution. With all of Grid's power, there is a bit of a learning curve. The following introduces its key concepts and will accelerate your command of the tool. ### Background ~~ Based on CSS Grid Layout(https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout), Grommet's Grid simplifies and presents the API in a manner consistent with other components in the Grommet library. Grid is composed of columns and rows and its properties allow for: - Fixed(#mixed-width-columns) column widths and row heights, when use cases desire precise dimensions for grid cells. - Flexible(#flexible-columns) column widths and row heights, allowing grid cell contents to gracefully respond   across a variety of browser widths. - Fluid grids(#fluid-grids) allowing columns and rows to grow and adapt to the content provided. - Precise placement of elements within the grid via areas. ## Grid properties and key concepts ~~ Grid's primary properties include: columns(#columns), rows(#rows), and areas. The following examples will demonstrate how these properties may be applied to affect content layouts(/templates/content-layouts). ### Columns ~~ Columns may be specified as uniform widths(#uniform-columns), mixed widths(#mixed-width-columns), or as min-max ranges(#flexible-columns) which allow the contents to flex gracefully. #### Uniform columns ~~ Uniform columns are ideal for presenting a collection of like items such as a grid of images, a catalog of services, or a dashboard of cards(/templates/dashboards#three-column-dashboard). Specifying the column width as single string will repeat multiple columns of that size, as long as there is room for more. For example, `columns=\"medium\"` will fit as many \"medium\" columns into the grid as the overall width allows. Within a wide screen, this might allow 3 or 4 columns; within a narrow screen, maybe only 1 or 2.      #### Mixed-width columns ~~ Mixed-width columns allow for control over layouts desiring columns of various widths. This helps appropriately present different content types and establish content hierarchy with wider columns for primary content and narrower for secondary content such as an activity feed(/templates/dashboards#two-column-dashboard). Mixed-width columns are specified in an array. The number of items in the array dictate the number of columns in the grid. For example, columns specified as `columns={ 'small', 'xsmall', 'xsmall' }` would create a three column grid with corresponding widths:        And, `columns={ '2/3', '1/3' }` would result in two columns with widths proportional to the total width of the grid:      #### Flexible columns ~~ Grid really shines when applying flexible columns. Flexible columns allow content to elegantly scale for dynamic designs. With flexible columns, columns are defined as a min-max range. The column is allowed to flex as large as the max and as small as the min, depending on its content and the space available to the grid as a whole. This allows content to be consistently displayed in an organized and cohesive fashion across a variety of screen widths. The min-max range is specified using a two-item array, instead of a single string. The first item is the min and second max.         Using 'auto' and/or 'flex' as min-max values provides even more flexibility. 'auto' and 'flex' share many characteristics. Both allow the column's width to be defined by its contents; they say, \"make my column as wide as my content needs.\" If there is excess width in the grid, the column will stretch and occupy the excess space. 'auto' and 'flex' differ slightly in behavior when multiple columns are defined using their values: - If multiple columns use 'auto', they share the excess width evenly. - If multiple columns use 'flex', they share the excess width evenly. - If 'auto' and 'flex' are both used, 'flex' will \"win\" the competition for the excess space. Columns   defined with 'auto' will fit the dimensions of their contents; columns defined with 'flex', will fit   the dimensions of their contents **and** occupy the excess width in the grid. See `auto` and `flex` in action in the example below by adjusting your browser width, or applied in a dashboard template(/templates/dashboards#two-column-dashboard).      ### Rows ~~ Rows generally share the same properties as columns(#columns). Accordingly, they won't be repeated here. That said, there a two primary items to call attention to: 1. Just like columns, rows are specified in an array. Each item in the array represent an additional row. 1. The vast majority of time rows will be specified using a fixed height, or as `auto` to let the row's height be defined by its    contents. ### Gap ~~ Use `gap` to define the spacing applied between columns and rows. - As best practice, use t-shirt sizing(/foundation/tshirt-sizing?q=gap#t-shirt-sizing-for-spacing-and-other-styles)   to define gaps. T-shirt sizing keeps layouts consistent and easy to maintain. - Gap may be applied to columns and rows, independently or simultaneously.       ## Implementing Grid ~~ Grid is not limited to the following implementations. Approaches may be mixed and matched as desired, but are presented with the intent to focus on the key concepts for each. ### Fluid grids ~~ Fluid grids allow the grid to grow and adapt to the grid's container width and the content provided. As more content is added, it fills the Grid left to right, top to bottom. Columns are added or removed as the screen's width is adjusted. - Great for presenting dynamic content where the number of items in the grid are unknown. Examples might   be:   - Applying filters to a catalog of services   - Presenting a dashboard where the user may customize the     included widgets   - Presenting image results returned from a search query - Make responsive layouts easy to implement. - Often implemented with uniform columns(#uniform-columns). The following example demonstrates a fluid grid consisting of 'small' columns. Adjust your browser's width and notice how the grid adjusts by adding/removing columns and rows.        The contents within a grid's cells do not have to fill the cell. Grid's `align` and `justify` props may be applied to vertically and horizontally align the content within the cell as desired. Alternatively, an individual cell's content may be vertically aligned using its `alignSelf` prop.      ## Accessibility ~~ ### WCAG compliance ~~  "},{"name":"Header","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/header.mdx","content":"   Header is extremely versatile and can be built by mixing and matching a variety of components to provide users with relevant, interactive elements to navigate through or engage with an application.      ## When to use ~~ Header is used to set the context for an application or a specific page within an application. It is a flexible element that can be composed of a variety of components to aid the user experience in an application. **Common use cases include:** - Global header(#global-header) - App header(#app-header) - Page header(#page-header) ## When not to use ~~ Do not use Header just as a means to display content in a row. The Header component translates to a `` in the DOM, so do not use Header in instances that do not align with the HTML header spec(https://developer.mozilla.org/en-US/docs/Web/HTML/Element/header). ## Anatomy ~~ While Header is flexible in its composition, these anatomical elements are the most common: - Button(/components/button) - Menu(/components/menu) - Search(/components/search) - Heading(/foundation/typography#heading) - Avatar(/components/avatar) ## Content restrictions ~~ Keep Header contents to a limited set of elements in order to: - Provide the user with relevant, helpful actions regarding the application or page. - Layout smoothly and responsively across all browser widths. ## Variants ~~ There are various action elements that may live in a Header, depending on the application or page context. ### Global header ~~ The Global Header, also known as the HPE Common Header and Footer Web Service, provides a tunable, yet consistent header and footer to be used across all HPE applications. For guidance, see documentation for Global Header(/templates/global-header). ### App header ~~ An app header provides additional navigational structure that is app-specific. If the application is not contained within the GreenLake ecosystem, the app header should contain an app identity on the left side of the header that: 1. Contains brand logo and application/service name 2. Links to the landing page of your application On wider screens, the navigational buttons should display in a row. On mobile, these items will be collapsed into a Menu(/components/menu). **Some elements that are appropriate for an app header include:** - Application navigation structure - Profile Avatar button that leads to account information - Search field that searches entirety of the application      ### Page header ~~ A PageHeader is a standardized layout component that sets the context for a single page within an application. For guidance, see documentation for PageHeader(/components/pageheader).      ## Accessibility ~~ When using Header as a navigation structure, use Buttons(/components/button) as your navigational elements and wrap them in a `Nav` component. This allows screen readers to identify this as a navigation region. For guidance, check out this example of an app header(#app-header). ### WCAG compliance ~~  "},{"name":"Index","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/index.js","content":"         export default Components; "},{"name":"Center Layer","parent":"layer","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/layer/center-layer.mdx","content":"    ## Anatomy ~~ See general layer anatomy(/components/layer#anatomy) for specifications applying to all layers. ## Layer closing behavior ~~ The closing behavior and anatomy of a center layer will differ depending on if the layer is informational or actionable.  ### Informational ~~ For informational layers that do not require any user actions, place a close icon(/foundation/icons#ui-actions) button in the layer header.      | Label | Region           | Purpose           |                  Required                   | Notes             | | ----- | ---------------- | ----------------- | :-----------------------------------------: | ----------------- | | **1** | **Close button** | Closes the layer. |  | Use \"Close\" icon. | The user should be able to dismiss the informational layer by clicking outside, `onClickOutside`, or using the Escape key, `onEsc`. ### Actionable ~~ For layers that require user actions, place a \"Cancel\" action alongside the other footer actions. In some cases, a label other than \"Cancel\" may be appropriate.      | Label | Region             | Purpose                                                          |                  Required                   | Notes                                                                                                                                                                                                                                | | ----- | ------------------ | ---------------------------------------------------------------- | :-----------------------------------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **1** | **Footer actions** | Allows the user to confirm, apply, or cancel the layer's action. |  | The actions should be right-aligned with primary action on the right. Right-alignment signals progress and forward momentum. One action should be a \"Cancel\" button that closes the layer, returning the user to the previous state. | To prevent the user from losing progress due to accidental clicks outside of a layer, `onClickOutside` functionality should not be enabled. The user should be able to dismiss the actionable layer by using the Escape key, `onEsc`. ### Double confirmations ~~ When data has been edited or changed and the user tries to close the layer, a double confirmation should be shown. This helps avoid unintentional loss of work. Learn more about the anatomy and implementation of a double confirmation(/components/layer#double-confirmations) on the main layer page since this behavior applies to all layer types. ## Examples ~~ ### Confirming next steps ~~      ### Highly destructive confirmation ~~  Highly destructive actions refer to use cases where large amounts of data will be deleted and cannot be restored. In these instances, have the user type a string that matches the name or path of the object to be deleted. This approach ensures the user is aware of the consequences of the action.      "},{"name":"Fullscreen Layer","parent":"layer","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/layer/fullscreen-layer.mdx","content":"    ## Anatomy ~~ See general layer anatomy(/components/layer#anatomy) for specifications applying to all layers. Fullscreen layers fill the entire page. Therefore, there no rounding or elevation is visible. ### Grommet properties ~~ Apply these layer properties(https://v2.grommet.io/layer?theme=hpe#props) for a fullscreen layer. | Property                                 | Value | | ---------------------------------------- | ----- | | full(https://v2.grommet.io/layer#full) | true  | ## Layer closing behavior ~~ ### Informational ~~ For informational side drawer layers that do not require any user actions, place a close icon(/foundation/icons#ui-actions) button in the layer header.      | Label | Region           | Purpose           |                  Required                   | Notes             | | ----- | ---------------- | ----------------- | :-----------------------------------------: | ----------------- | | **1** | **Close button** | Closes the layer. |  | Use \"Close\" icon. | The user should be able to close the informational layer by clicking on the close button, clicking outside, the layer, or using the Escape key. ### Actionable ~~ For actionable layers, include the close icon(/foundation/icons#ui-actions) button in the header and a \"Cancel\" button alongside footer actions so the user can efficiently leave the layer if desired.      | Label | Region            | Purpose           |                  Required                   | Notes                                                                                                                                                                                                                                  | | ----- | ----------------- | ----------------- | :-----------------------------------------: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1** | **Close button**  | Closes the layer. |  | Including the close button in the header in addition to the footer \"Cancel\" button ensures the user can efficiently exit the layer if desired.                                                                                         | | **2** | **Cancel button** | Closes the layer. |  | The footer actions should be left aligned with primary action on the left and \"Cancel\" button following. The \"Cancel\" button should always be present as a complement to the primary action, providing an easy way to leave the layer. | ### Double confirmations ~~ When data has been edited or changed and the user tries to close the layer, a double confirmation should be shown. This helps avoid unintentional loss of work. Learn more about the anatomy and implementation of a double confirmation(/components/layer#double-confirmations) on the main layer page since this behavior applies to all layer types. ## Scroll behavior ~~ The default behavior of the layer is to allow all of the content to scroll, but this behavior can be modified depending on the layer's contents. | Layer contents | Sticky region                                                                                         | Scroll region                   | Notes                                                                                                                                                                                                       | | -------------- | ----------------------------------------------------------------------------------------------------- | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Wizard**     | Header and footer                                                                                     | Body                            | A sticky footer ensures the user always has access to advance in the wizard. A sticky header maintains the wizard's context and provides persistent access to move a step back in the wizard or cancel out. | | **Form**       | None or header can be sticky/appear on scroll up if this added context is valueable for the use case. | All content, or body and footer | The footer actions should be at the bottom of the form to encourage the user to see the entire form before submission.                                                                                      | ## Examples ~~ ### Wizard ~~ A wizard is a specialized fullscreen layer where a task flow is divided into multiple steps. See wizard guidance(/templates/wizard) for examples and details. "},{"name":"Index","parent":"layer","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/layer/index.mdx","content":"         ## When to use ~~ A layer should be used to present information or task flows to the user without navigating them away from their current context. ## Anatomy ~~ Basic anatomy and spacing that apply to all layer types(#types-of-layers).      | Label  | Region       | Purpose                                                |                  Required                   | Notes                                                                      | | ------ | ------------ | ------------------------------------------------------ | :-----------------------------------------: | -------------------------------------------------------------------------- | | **1**  | **Header**   | Identifies the layer.                                  |  | --                                                                         | | **1a** | **Title**    | A short, descriptive title identifying the layer.      |  | Implemented as a Heading level 2.                                          | | **1b** | **Subtitle** | Any additional context or information about the layer. |                  Optional                   | --                                                                         | | **2**  | **Body**     | Any additional content.                                |                  Optional                   | --                                                                         | | **3**  | **Footer**   | Contains layer actions.                                |                  Optional                   | The ordering and alignment of footer actions depends on the type of layer. |  ## Types of layers ~~ Different use cases and content warrant different layer types. Learn more about each type below.  ## Layer closing behavior ~~ Depending on whether a layer is informational(#informational) or actionable(#actionable), the elements and interactions that close a layer differ. ### Informational ~~ Informational layers do not require any actions from the user, and therefore do not contain any actions. The following should cause an informational layer to close: 1. Clicking the close icon(/foundation/icons#ui-actions) button the layer's header. 1. Clicking outside of the layer, `onClickOutside`. 1. Pressing the Escape key, `onEsc`. Learn more about the specifics of informational center layers(/components/layer/center-layer#informational), informational side drawer layers(/components/layer/side-drawer-layer#informational), and informational fullscreen layers(/components/layer/fullscreen-layer#informational). ### Actionable ~~ Actionable layers require the user to either accept or apply the action prompt in the layer or cancel the action. The following should cause an actionable layer to close: 1. Clicking the close icon(/foundation/icons#ui-actions) button in the layer's header.    - Note: Actionable center layers should not include a close button in the layer's header. Center layers generally present confirmations, therefor the user should intentionally choose between accepting or cancelling the layer's action prompt. 1. Clicking the cancel button in the layer's footer. 1. Pressing the Escape key, `onEsc`. 1. Clicking an affirmative action such as \"save\" or \"apply.\" Clicks outside of an actionable layer, `onClickOutside`, should not close the layer. Actionable layers present an 'apply' or 'do not apply' choice for which a user should make an intentional choice. Clicks outside of layer do not indicate intent and therefore should not close the layer. Use of a double confirmation may be desirable as part of the layer's closing behavior in some instances. See more detail about when to use double confirmation(#double-confirmations). Learn more about the specifics of actionable center layers(/components/layer/center-layer#actionable), actionable side drawer layers(/components/layer/side-drawer-layer#actionable), and actionable fullscreen layers(/components/layer/fullscreen-layer#actionable). ### Double confirmations ~~ When closing out of an actionable layer containing editable or configurable information, the behavior should err on preventing a user's unintentional loss of work by presenting a double confirmation. A double confirmation should be shown when data has been edited or changed and the user closes the layer by using the close icon(/foundation/icons#ui-actions) button, cancel button, or Escape key; a double confirmation is not needed upon affirmative actions like 'save' or 'apply'. | Layer state                             | Confirmation type   | Notes                                                                                                                                                                                         | | --------------------------------------- | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | User has not input or changed any data. | No confirmation     | The user will not lose anything if the layer closes immediately.                                                                                                                              | | User has input or changed data.         | Double confirmation | The double confirmation should show when the user clicks the \"X\" or Cancel button, or presses the Escape key. This short confirmation ensures that user's work won't unintentionally be lost. | #### Double confirmation anatomy ~~ A double confirmation appears as a center modal(#modal-vs-non-modal). This placement puts the confirmation at the center of the user's attention, reinforcing the importance of the dialog's prompt and minimizing distractions from other page content.      | Label  | Region       | Purpose                                                              |                  Required                   | Notes                                                                                                      | | ------ | ------------ | -------------------------------------------------------------------- | :-----------------------------------------: | ---------------------------------------------------------------------------------------------------------- | | **1a** | **Title**    | Explains that data will be discarded when the user closes the layer. |  | --                                                                                                         | | **1b** | **Subtitle** | To clarify that changes will not be saved.                           |  | --                                                                                                         | | **2**  | **Footer **  | Contains two actions: \"Cancel\" and \"Discard\"                         |  | The actions should be right-aligned with primary action on the right, to align with center layer guidance. |                                                 #### Double confirmation example ~~ The example below demonstrates how a double confirmation is only used if the layer's content has been changed or edited. A double confirmation is not used if no changes have been made. This behavior errs on preventing unintentional loss of work that a user has done. First, click \"Add application\" then click the close button in the layer header. Notice how the layer immediately closes. Next, click \"Add application\" again and this time type something into the \"Title\" input. Now, click the close button. Notice how a double confirmation appears.      ## Modal vs. non-modal ~~ While layer is the component that drives the layout, elevation, positioning on the screen, modal vs. non-modal effects the behavior to dismiss the layer and interactivity of outside content. Modal is a specific HTML behavior that excludes interaction with outside elements until it is dismissed. Non-modal means that the outside content can still be interacted with while the layer is open. ### Modal ~~ When a layer is modal, a translucent overlay appears behind the layer and covers the rest of the page content to block the user from interacting with the page until the layer is closed. Actionable layers should always be modal to ensure user focus is on the layer content and required actions. Modal is the default behavior of a layer. ### Non-modal ~~ When a layer is non-modal, there is no translucent overlay that covers the page content, and the page can still be interacted with. Informational layers can be non-modal. To implement, apply `modal={false}` to the layer. ## Action label conventions ~~ If a layer contains footer actions, the primary action should be labeled using verb + noun format (e.g., \"Apply filters\"). The noun may be omitted from actions labels beyond the primary action if the action is clear and unambiguous (e.g. \"Reset\" instead of \"Reset filters\"). When in doubt, follow the verb + noun convention to ensure clarity. See button labeling guidance(/components/button#button-labeling) for more details.                         ### Aligning to layer title ~~ The primary action verb should match the verb in the layer's title.                         ## Accessibility ~~ ### Layer titles ~~ - Layer headings should be semantically correct. - Treat a Layer as if it were a stand alone page, with the exception that the first heading within a Layer should be an `h2` or ``. - All subsequent headings should follow typical semantic heading structure(/foundation/typography#semantic-usage-of-heading-levels). ### Announcing layer open and close ~~ It is critical that users of assisstive technologies are informed when a layer opens and closes. The approach to implementation differs. depending on if a layer is modal(#modal-layers) or non-modal(#non-modal-layers). #### Modal layers ~~ For modal layers, use AnnounceContext(https://v2.grommet.io/announcecontext) to ensure it is clear that the layer has opened or closed. There should be an announcement: 1. When the layer opens. 1. When the layer closes, specifying if the prompt has been accepted or cancelled.   #### Non-modal layers ~~ When using a Layer with `modal={false}`, it is critical that the focus is moved to the \"Close\" button inside the Layer. Give the close button an `a11yTitle` that provides the user with context that they are in a Layer. For example, implementation of this \"Close\" button for a Layer would be:  ### WCAG compliance ~~  "},{"name":"Side Drawer Layer","parent":"layer","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/layer/side-drawer-layer.mdx","content":"   ## Anatomy ~~ See general layer anatomy(/components/layer#anatomy) for specifications applying to all layers. ### Grommet properties ~~ Apply these layer properties(https://v2.grommet.io/layer?theme=hpe#props) for a side drawer layer. | Property                                         | Value    | | ------------------------------------------------ | -------- | | position(https://v2.grommet.io/layer#position) | right    | | full(https://v2.grommet.io/layer#full)         | vertical | ## Layer closing behavior ~~ ### Informational ~~ For informational side drawer layers that do not require any user actions, place a close icon(/foundation/icons#ui-actions) button in the layer header.      | Label | Region           | Purpose           |                  Required                   | Notes             | | ----- | ---------------- | ----------------- | :-----------------------------------------: | ----------------- | | **1** | **Close button** | Closes the layer. |  | Use \"Close\" icon. | The user should be able to dismiss the informational layer by clicking outside, onClickOutside, or using the Escape key, onEsc. ### Actionable ~~ For actionable layers, include the close icon(/foundation/icons#ui-actions) button in the header and a \"Cancel\" button alongside footer actions so the user can efficiently leave the layer if desired.      | Label | Region            | Purpose           |                  Required                   | Notes                                                                                                                                                                                                                                  | | ----- | ----------------- | ----------------- | :-----------------------------------------: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1** | **Close button**  | Closes the layer. |  | Including the close button in the header in addition to the footer \"Cancel\" button ensures the user can efficiently exit the layer if desired.                                                                                         | | **2** | **Cancel button** | Closes the layer. |  | The footer actions should be left aligned with primary action on the left and \"Cancel\" button following. The \"Cancel\" button should always be present as a complement to the primary action, providing an easy way to leave the layer. | To prevent the user from losing progress due to accidental clicks outside of a layer, `onClickOutside` functionality should not be enabled. The user should be able to dismiss the actionable layer by using the Escape key, `onEsc`. ### Double confirmations ~~ When data has been edited or changed and the user tries to close the layer, a double confirmation should be shown. This helps avoid unintentional loss of work. Learn more about the anatomy and implementation of a double confirmation(/components/layer#double-confirmations) on the main layer page since this behavior applies to all layer types. ### Filters ~~ A filter layer is an exception to the above rules. Even though filtering requires action from the user, it is not essential that the user fills out the filtering form. Because of this, a filter layer can be closed by the following interactions: 1. Clicking the \"Apply filters\" button, which will apply the current filter selections and close the layer. 1. Clicking the close button in the layer header. 1. Clicking outside of the layer, `onClickOutside`. 1. Pressing the Escape key, `onEsc`.      ## Scroll behavior ~~ The default behavior of the layer is to allow all of the content to scroll, but this behavior can be modified depending on the layer's contents. | Layer contents | Sticky region                                                                                         | Scroll region   | Notes                                                                                                                            | | -------------- | ----------------------------------------------------------------------------------------------------- | --------------- | -------------------------------------------------------------------------------------------------------------------------------- | | **Filters**    | Footer                                                                                                | Header and body | A sticky footer ensures the user always has access to apply, reset, or cancel out of the filter view and return to the data set. | | **Form**       | None or header can be sticky/appear on scroll up if this added context is valueable for the use case. | Body and footer | The footer actions should be at the bottom of the form to encourage the user to see the entire form before submission.           | ### Sticky header ~~ If it would be valuable for the user to maintain the context of the layer's topic, the header can be made persistent or reappear when the user scrolls up. #### Persistent ~~ If it's necessary for the user to always be able to see the layer heading, make the heading persistent and sticky.      #### Scroll up ~~ In order to maximize screen real-estate when content is scrollable, the header may scroll away as the user scrolls down but reappear as the user scrolls up. This can be accomplished by applying `sticky=\"scrollup\"` on Heading.      ## Examples ~~ ### Configuration form ~~      ### Filtering ~~ Click the filter icon to see the layer. Notice the sticky footer on this layer. Refer to scroll behavior(#scroll-behavior) for added guidance.      "},{"name":"Main","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/main.mdx","content":"       ## Accessibility ~~ ### WCAG compliance ~~  "},{"name":"Maskedinput","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/maskedinput.mdx","content":"       ## Guidance ~~ MaskedInput places syntax restrictions text entered in an input field which allows for efficient, error-free entries. It is similar to TextInput(/components/textinput), in that it allows the user to input shorter forms of data and content. However, it is used to provide extra guidance and enforcement of input formats. ### Usage ~~ MaskedInput should be used anytime there is formalized syntax and should always be used within a Form(/templates/forms). **When using MaskedInput, you should:** - Provide suggestions whenever possible to provide hints of possible values - Use the input mask to restrict input syntax to the desired format - Ensure any syntax separators are automatically inserted if needed, but also allow users to type them MaskedInput reduces the number of input fields needed by allowing multiple criteria to be consolidated into a single input. For example, you can use MaskedInput to collect storage size amounts and units in a single input(#size-with-units). ## Variants ~~ A MaskedInput's visual state informs the user of its ability to be interacted with or if any validation errors have occured. It automatically formats input values to the desired syntax. ### IP address ~~ Used to collect a single IP address.      ### IP range ~~ Used to collect a range of IP addresses. As the user types, the syntax is filled in automatically.      ### Size with units ~~ Used to collect information on size, with suggestions that match common size intervals.      ### Email ~~ Used to email address and formats according to email syntax.      ### Time ~~ Allows time information to be input with options of 15 minute intervals by suggestion or any custom time by typing.      ### Date ~~ Used to collect full date where day value suggestions match the number of days in the selected month.      ### Validation ~~ Used to confirm that an input has been completed properly and to its entirety, even when syntax restrictions are in place. See the difference upon submission when inputting \"123.123.123.123\" vs. \"43.21\".      ### Disabled ~~ Used to indicate that a MaskedInput cannot be interacted with.      ## Accessibility ~~ In every case possible, MaskedInput should be used inside of a FormField to ensure that a label is appropriately paired with the input. This behavior is important to screen reader users who need to know to which context the MaskedInput is referring. Placeholder text does not serve as a sufficient means of restricting syntax. As the user types, the input should auto-format to the intended format. ### WCAG compliance ~~  "},{"name":"Menu","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/menu.mdx","content":"        ## Guidance ~~ A Menu is a set of actions that may be used to engage with content on a page or to navigate to other pages. When a menu item is clicked, the action will be executed. Menu should not be confused with Select(/components/select). Though visually similar, Select is often used in the context of a Form and used to choose from a set of values rather than actions. ### Usage ~~ To create a predictable experience for users, the following are guidelines for using Menu. **It is recommended that you do not have more than 5 items in a menu.** In order to create the most effective user experience, keep the number of items to a minimum. This allows the user to easily understand the scope of the actions they can perform. **Give the menu a clear title.** Instead of labeling the menu as \"Menu\", provide a name that conveys its purpose. For example, a label of \"Account Information\" would be appropriate if the menu items associated were actions such as \"Change username\" or \"Reset password\". **Keep labels short.** Using a simple, concise label for menu items, such as \"Settings\" or \"Logout\", helps the user easily understand the action that will be performed when they click. Longer labels may clutter the layout and create a more effortful experience for the user. **Avoid creating cascading menus.** Menus with multiple layers creates a confusing experience for the user because relevant actions may become nested and difficult to find. Refining menu items to necessary actions creates a more manageable user experience. ## Organizing menu items ~~ Allow a user to quickly locate the menu item they desire by organizing menu items through thoughtful ordering and grouping. ### Guiding principles ~~ - Make it easy for the user to scan by grouping related items and placing more   frequently used actions at the top of the menu. - Ensure intentionality, by placing destructive actions in a distinct, consistent   location at the end of the menu. ### Grouping ~~ Group related menu items. Use separator lines to create visually distinct groups of related menu items. Create separate groups for menu items initiating actions and items setting attributes. Menu items become unpredictable when the behavior of grouped items varies. Menu items should only be grouped if there are two or more related items.         {/* Box allows menu to be presented with drop open, overriding Example align/justify center */}                            {/* Box allows menu to be presented with drop open, overriding Example align/justify center */}                      ### Ordering ~~ Frequency of use should guide the order in which menu items are presented. When menu items are grouped, order items within that group by frequency. Additionally, place the most frequently used group at the top of the menu. This anticipates what the user is looking for and allows them to locate the item as their eye scans the items top to bottom. Exception: Dangerous actions(#dangerous-actions) should be placed as the last item in the menu. ### Dangerous actions ~~ Dangerous or destructive actions altering a state which cannot be recovered, such as delete, should be placed as the last item in the menu with a visual separator for the dangerous actions grouping so that they are distinct from all other actions. Selecting a dangerous action should lead to double confirmation.         {/* Box allows menu to be presented with drop open, overriding Example align/justify center */}                            {/* Box allows menu to be presented with drop open, overriding Example align/justify center */}                      ### Common groupings in HPE applications ~~ Many HPE applications provide the ability for customers to configure, modify, and act upon resources in their environment. For applications in this context, groups of menu items can be thought of as configuring(#configuring), executing(#executing), or transferring(#transferring). #### Configuring ~~ Actions allowing a user to set and modify attributes of a resource. - View resource details - Edit resource - Add item to resource - Remove item from resource - Assign resource to another resource - Add resource to group #### Executing ~~ Actions providing the ability for a user to act upon a resource. - Launch resource - Power on/off resource - Reset resource - Update/upgrade software/firmware version for resource #### Transferring ~~ Actions enabling a user to share or consume data related to a resource. - Download resource data - Share resource with user - Send resource to user - Notify user about resource #### Batch actions menu related to a selection of servers ~~ The table menu's batch actions are grouped by executing and configuration actions. The executing actions group is ordered first because the actions in it are the most frequently used.      #### Actions menu related to an individual record ~~ Each server group has a menu whose actions have been grouped by configuration, executing, and dangerous actions. The configuration actions group is ordered first because adjusting and viewing the group are the most frequently used. The delete group action is ordered last since deleting the group is a destructive action and cannot be recovered.      ## Variants ~~ There are various places a Menu may be useful within an application. If the user is going to be selecting from a list of options to execute an action, Menu is a good component to use. The usage of labels and icons allow a menu to be versatile for different layout contexts. ### Within a header ~~ A menu can be used in a Header(/components/header) to group related actions. The default Menu should be used in all instances unless the Menu is contained within a toolbar, in which case see Menu within a toolbar(#within-a-toolbar) guidance.      ### Within a toolbar ~~ Use `kind=\"toolbar\"` when the Menu is placed in row with other toolbar controls like search or filter. In this situation, a search input, filter button, and action menu are presented as a unified set of controls. The intent is to present each control with equal prominence.      ### With custom icon ~~ Adding an icon prop changes the icon that appears on the menu. In some contexts, it may be appropriate to use a more specific or alternate icon. Here is an example Menu being used in a List(/templates/lists) to indicate actions that can be performed on list items.      ### Disabled ~~ Used to indicate that a Menu cannot be interacted with.      ## Accessibility ~~ Accessibility features such as screen reader messages are automatically built into Menu. By default, these messages are \"Open Menu\" and \"Close Menu\". However, if a more specific message is necessary, a custom a11yTitle(https://v2.grommet.io/menu?theme=hpe#a11yTitle) or messages(https://v2.grommet.io/menu?theme=hpe#messages) may be applied. An icon may be used on a menu item to provide additional context about the action. It is recommended that an icon is used in conjunction with text to ensure the context of the menu item is clear. However, there may be cases where an icon alone is sufficient. For example, highly familiar action indicators, such as this example of Menu with custom icon(#with-custom-icon) demonstrate when an icon only may be sufficient. ### WCAG compliance ~~ {' '}  "},{"name":"Namevaluelist","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/namevaluelist.mdx","content":"         ## When to use ~~ Consider using a NameValueList for the following use cases: - Displaying a list of name and value pairs. - Presenting metadata in a clear, scannable and consistent way. - Decreasing the time taken to review data. ## Anatomy of a NameValuePair ~~      A NameValuePair is a set of two related elements: a name, which identifies a data item, and a value, which is the description of that data. 1. **Name**      A name is a unique indentifier or term referring to a data item. This is typically a constant. In general, name labels are displayed in sentence case (the first letter is a capital and the following words are in lowercase). 2. **Value**      Value is the description of data or a pointer to the location of that data. The format of the value can vary, depending on the data set. Content can include: single line description, multi line description, anchors, array or list of items.      3. **Supporting icons/visuals (optional)**      Icons may be included to visually support the name or value. It is recommended not to use icons for both name and value at the same time. This can cause unnecessary visual noise and distract from vital information.           ## Variants ~~ ### Horizontal (default) ~~      ### Vertical ~~ The pairProps direction determines how the name and value are aligned. If you want the name to be on top of the value, apply `pairProps={{direction: 'column'}}`.      ### Grid ~~ {/* width to be removed once we audit example layouts */}      ### Multiple NameValueLists on a single page ~~      ### Name-Value pair as a read-only display for text inputs ~~ In some cases, NameValuePairs may be used as read-only display for text inputs that are editable inline. Here, the name and value text styling should match the Text Input component (sans border).      ### Name-Value Pair as a read-only display in horizontal ~~      ## Content truncation ~~ When presenting a value as a list of items, the list may be truncated and accompanied by a Button to expand it, displaying all items. When delimited, content exceeding 192 characters should be truncated. For vertical lists: - 7+ items should be truncated, displaying the first 3 items with a \"Show all\" button. - For 6 or fewer items, show all items and do not truncate.      ## Name-Value pair with empty value ~~ If the value of a name-value pair is empty, use `--` in place of where a value would appear. This visual indicator aids the user in identifying fields that do not have values, without increasing cognitive load. To inform assistive-technology users of an empty state, add an `a11yTitle=\"No value\"` to the Text component that would otherwise render the data. Depending on the use case, it may or may not be necessary to render a name-value pair with an empty value to the user. ### When to display “empty value” name-value pairs ~~ In certain scenarios, it is important to display to a user that a certain name-value pair does not have a value. These scenarios include: **Review/Edit pages** - when a user has made configuration selections (such as in a Wizard(/templates/wizard)) or is editing configurations (such as settings), all name-value pairs should be visible so the user knows which options they have and have not configured.      **Detail pages** - these kinds of pages provide the most granular level of information about a device, server, etc. and should display all name-value pairs.      ### When to omit “Empty value” name-value pairs ~~ In certain scenarios, it is not necessary to display name-value pairs that don’t have a value. These scenarios include: **Public-facing profiles** - For instances where a profile is outwardly facing, only name-value pairs with values should be displayed. The complete list of possible entries should only be viewable when a user goes to edit their profile.      **Summaries (such as dashboard cards)** - Summaries are intended to display information-salient content, often in areas with restricted screen real estate. Given this, name-value pairs without a value should be omitted.      ## Hierarchy ~~ A successful NameValueList is scannable and easy to grasp. Consider the following methods to imply hierarchy: order(#order), headings(#headings), scale(#scale), font weight(#font-weight), color(#color). ### Order ~~ - Having a logical order of a name-value list ensures a more scannable display of data. - Depending on content displayed, consider ordering by name (alphabetical order) or by importance of information (most relevant to less relevant). - Always establish the structure of your data upfront. ### Headings ~~ - Use headings to define a name-value List and/or for grouping multiple name-value lists within a single screen. - For accessibility reasons, always ensure semantically correct heading levels are applied. See best practices for applying headings(/foundation/typography#semantic-usage-of-heading-levels).      ### Scale ~~ - Default font size for a NameValueList is “medium” (18px). - Font-size options for displaying name and value include small, medium and large. - Additional sizes xl and xxl can be opted for displaying value content, depending on styling needs (such as for displaying on a dashboard page layout). - The size of name can differ from value. - Name should never be scaled bigger than its value. | Text size        | Name                            | Value                           | | ---------------- | ------------------------------- | ------------------------------- | | xsmall           |  |  | | small            |  |  | | medium (default) |  |  | | large            |  |  | | xlarge           | n/a                             |  | | xxlarge          | n/a                             |  |                         ### Font weight ~~ Making the font bolder or thinner is another way to create hierarchy that’s easily identifiable. - Typically, use a bold weight on names to increase scanability within the list - In some cases, a value may be displayed in a bold weight to draw the reader’s attention. An example of this application might be a dashboard page. - Don’t use bold text for both name and value at the same time. - Don’t use a bold font-weight for any long format content as this can be very hard to read and overwhelm the user.                                                           ### Color ~~ Options for text color include the default `text`  (default for Name-Value pairs) and `text-strong`  . ### Responsiveness ~~ All types of NameValueLists will change to a single column NameValueList on smaller viewports. View this behavior by reducing your window screen until the layout of an example shifts to single column. ### Name-value alignment ~~ By default, both the name and the value are left aligned. This can be changed through `nameProps` and `valueProps` by setting align(https://v2.grommet.io/namevaluelist?theme=hpe#nameProps) to the desired value, such as `end`. No matter what alignment is chosen, always opt for a consistent presentation across a single NameValueList or NameValueLists on a single page.      ### Controlling the width of the name and value ~~ The width of name is set to \"small\" by default to accommodate a reasonable width for common data names. However, if all names are short, it may be appropriate to adjust the name width to something smaller. This can be easily changed through `nameProps`. For example `nameProps={{width: 'xsmall'}}`. The width of value is set to medium by default to aid readability of content. However, if necessary, the width of value can also be adjusted with `valueProps`. For example, `valueProps={{width: 'large'}}` ## Accessibility ~~ ### WCAG compliance ~~  "},{"name":"Notification","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/notification.mdx","content":"   ## What are they for? ~~ Notifications build trust by providing users confidence and assurance that they are informed with timely, relevant status about their systems and tasks. ## Taxonomy ~~ To standardize language for notifications across HPE projects, be sure to familiarize yourself with this taxonomy: - **Type** - In the broadest terms, what the notification is about - **State** - The current stage within a process - **Status** - The condition of a process - **Attention level** - The priority and importance of a notification - **Actions** - Interactactions within a notification - **Persistence** - How the notification is dismissed - **Placement** - Where the notification can be found - **Insight** - The content of the notification  ### State vs. status vs. health ~~ A state is the current stage of a process. A status is the condition of the state. Status can also be thought of as a pointer to a state’s “health.” At HPE we tend to use the two terms interchangeably, but the end users don't know that. To avoid confusion for the end user, do not use the word \"health\" in your user interfaces. Always use \"status\" instead. Here is an example of a toast notification that illustrates their differences:   Keep in mind that a status **derives** from a state. The state of this task is successful, therefore the status of the Toast notification is normal. ## Notification systems ~~ The following types of notifications are used to provide users with full transparent clarity on tasks and system statuses: - Status Indicators(/templates/status-indicator) are used within all types of notifications. They capture a user’s attention based on the notification’s level of severity. - For low priority and non-action-oriented notifications, Toast Notifications(/templates/toast-notifications) are a great way to inform users unobtrusively. ## Variants ~~ There are a couple types of the notification component depending on use case. ### Inline notification ~~ Inline notifications are messages that appear near the content to which they are related. For more thorough guidance, read inline notifications documentation(/templates/inline-notifications).      ### Toast notification ~~ Toast notifications are used for low attention status messages or updates that do not require user action. For more thorough guidance on how and when to properly make use of a toast, access the full page on Toast Notifications(/templates/toast-notifications).      ### Global notifications ~~ Global notifications are system-generated alerts that attract the user's attention to system conditions and updates. For more thorough guidance on how and when to properly make use of a global notification, access the full page on Global Notifications(/templates/global-notifications).      ### Roadmap ~~ The Design System team is currently exploring and researching best practices and considerations for notification patterns. Here are some we plan on addressing: - Page banner - Notification center - Badging & bell ### Have more questions? ~~ Please be sure to send them over to the `#hpe-design-system` channel on Slack(https://slack-invite.grommet.io/)! ## Accessibility ~~ ### WCAG compliance ~~ {' '}  "},{"name":"Page","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/page.mdx","content":"  Page makes it easy to implement page layouts(/templates/page-layouts) uniformly across HPE applications. Two components, Page and PageContent, work together to ensure HPE theme-defined padding, horizontal alignment, max-width, and responsive behaviors are applied in a consistent, turnkey manner. {/* height, width, and screenContainer.scale value chosen to best visually represent the example */}      ## Page and PageContent working together ~~ Page is the outer layout component and provides the desired layout context. Page’s `kind` determines which theme-defined alignment, padding, and min/max-widths are applied to its PageContent children. As a child of Page, PageContent consumes and adheres to the layout styling provided by its parent Page.   In most cases, all content on a page can be wrapped in a single PageContent component(#example-content-within-a-single-pagecontent). However, designs using differing background colors(#example-page-with-full-width-background) to delineate page sections may accomplish this by applying a PageContent per desired section. ## Example: content within a single PageContent ~~ All content is placed within a single PageContent component. {/* height, width, and screenContainer.scale value chosen to best visually represent the example */}      ## Example: Page with full-width background ~~ Use cases where an application needs a background to span the entire width of a page section is achieved by setting `background={{ fill: \"horizontal\", ...additional properties }}` on PageContent. This treatment is often seen on marketing sites where backgrounds help visually block content sections. This might also be seen in a context such as an app-store catalog where the hero section might have an image spanning.      ## Variants ~~ ### Wide ~~ \"Wide\" is Page's default `kind`. The vast majority of pages in HPE applications will likely use Page's \"wide\" variant. See page layouts(/templates/page-layouts#page-kinds) for specifications and content layouts(/templates/content-layouts) for templates and guidance on responsive designs. {/* height, width value chosen to best visually represent the example */}      ### Narrow ~~ Narrow is for use cases where the desire is to provide a user with singular, focused content or objective, such as editing field values of an object or stepping through a wizard-based task flow(/templates/wizard). A \"narrow\" page layout limits the page content's width to `large` and positions the content at the center of the page. See page layouts(/templates/page-layouts#page-kinds) for specifications and use-case guidance. {/* height, width value chosen to best visually represent the example */}      ### Full ~~ \"Full\" is helpful in situations like presenting a monitoring dashboard filled with a collection of key performance indicators or an interface allowing a user to browse resources displayed on a geographic map. This option allows the page's content to occupy the entire width of the browser window. If the window's width exceeds the available content, the content is left aligned. See page layouts(/templates/page-layouts#page-kinds) for specifications and use-case guidance. {/* height, width value chosen to best visually represent the example */}      ## Accessibility ~~ ### WCAG compliance ~~ {' '}  "},{"name":"Pageheader","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/pageheader.mdx","content":"   The PageHeader's title communicates the context of the page. The subtitle elaborates secondary information about the page. The user is also able to access navigation to the parent page and any relevant page-level actions.      ## Anatomy ~~      1. **Page Identifier:** This region is intended to provide the user with context on what the page is about.    - **a.** Title(#title) (required): A short and descriptive title that uniquely identifies the page.    - **b.** Subtitle(#subtitle) (optional): Concise, contextual information elaborating the purpose of the page. 2. Contextual Navigation(#reverse-anchor): A Reverse Anchor is required on all child pages as a means of navigating up the information hierarchy. 3. Page-Level Actions(#page-level-actions) (optional): This region is reserved for actions that affect the entire page or kick-off a task flow. ## Responsive behavior and content prioritization ~~ The main purpose of a page header is to identify a page and its context within an application. Therefore, the title and subtitle regions should receive screen priority when they come into contact with page-level actions. The region containing the title and subtitle should: - Flex to fill the available horizontal space on the page. - Have a minimum width of \"medium\" on `medium-xlarge` breakpoints and \"small\" on `xsmall-small` breakpoints to avoid excessive wrapping. Page-level actions should: - Have a width of \"auto\" by default. - Progressively collapse into an overflow menu as screen width becomes limited. This should follow guidance on responsive behavior of actions(#responsive-behavior-of-actions).       ## Title ~~ A title is a required element of the page and should: - Always be an h1. - Uniquely and concisely identify the page. No two pages under the same parent should have the same name. - Follow sentence case capitalization (i.e., List of clusters, My account). - Wrap if too long for the available space. See Responsive Behavior and Content Prioritization(#responsive-behavior-and-content-prioritization) for more guidance. - Be left-aligned with page content. ## Subtitle ~~ A subtitle is an optional element providing additional information about the contents of the page. A subtitle should: - Concisely elaborates what the page is about, setting expectations as to what a user can find and do. This could be additional information such as ownership of an application, timestamps, or a name to represent by whom a piece of information was created. - Be located below the title and left-aligned with page content. - Wrap at the max-width for the paragraph's font-size in order to optimize the readability.                         ## Reverse anchor ~~ A reverse anchor is required on all child pages and should: - Be located above the title and left-aligned with page content. - Be labelled with the name of the parent page and accompanied by the \"FormPrevious\" icon. - Navigate the user from the child page to its parent. - Not be used on top-level pages(#example-of-top-level-page) because they do not have a parent. ### Example of child page ~~ Child pages include a reverse anchor which allows the user to navigate from the child page to its parent.      ### Example of top-level page ~~ Top-level pages do not display a reverse anchor because they do not have a parent.      ## Page-level actions ~~ Page-level actions affect the entire page or launch a task flow. **All actions should:** - Have clear and concise button labels. - Use verb+noun format to provide sufficient context on action expectations (i.e., Edit profile). See button labeling(/components/button#button-labeling) for more guidance. - Be right-aligned with the page content. - Follow button ordering guidance(/components/button#button-ordering) for right-aligned buttons. **Additional notes:** - A primary action should only be used if the primary purpose of the page is to faciliate performing that action. Most pages will not have a primary action. - Do not include actions related to table or list data (such as create, update, and delete) in the page-level actions. These should be placed in the toolbar above the data. - Page-level actions may be in the form of a button or in a menu.                         ### Responsive behavior of actions ~~ Page-level actions is a flexible region in which a wide variety of actions may live. Actions in this region should be thought of in terms of their importance to a user and progressively collapse based on their priority. **A primary action should:** - Only be used if the primary purpose of the page is the perform that action. Most pages won't have a primary button. - Always remain visible, if present. **Secondary and default actions:** - Should remain visible if there is space but collapse into an action menu if there is not enough space. - Default buttons should collapse first because they are lower priority than secondary buttons. **If the screen breakpoint is `small` or `xsmall`:** - If there is a primary action, then all actions should appear beneath the title and subtitle and be left-aligned with page content. To implement, apply `responsive={true}` to PageHeader. - If there is no primary action, then the overflow menu should remain to the right of the title.                                     ## Accessibility ~~ ### WCAG compliance ~~ {' '}  "},{"name":"Pagination","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/pagination.mdx","content":"        ## Use cases ~~ ### Managing datasets ~~ Common ways to display datasets include, DataTable, List & Cards. Pagination can be attached to any of these options, allowing the user to browse the returned data in smaller segmented views.      ## Anatomy ~~      | Label | Region          | Purpose                                                                            | Required | Notes                                                                                                                                      | | :---: | --------------- | ---------------------------------------------------------------------------------- | :------: | ------------------------------------------------------------------------------------------------------------------------------------------ | | **1** | **Container**   | Organizes its children, where they appear, how they adapt responsively.            | Required | --                                                                                                                                         | | **2** | **Summary**     | Provide clarity on what range of items are in view.                                | Optional | --                                                                                                   | | **3** | **StepOptions** | Displays the current number of items within a page and allows the user to modify.  | Optional | Step defaults to 10. Dropdown options default to 10, 25, 50, 100. The default step and step options can be customized to fit the use case. | | **4** | **Navigation**  | Allow user to jump to a specific page.                                             | Required | --                                                                               | ## Types ~~ ### Default navigation ~~ The standard navigation in the Pagination component displays up to 7 buttons, including Edge Pages (first and last), Middle Pages (maximum of 3 pages) and Arrow Buttons (previous and next). ### Custom navigation ~~ The navigation in the Pagination component can be customized to better fit different use cases. The following settings can be adjusted:   - Middle pages(https://v2.grommet.io/pagination?theme=hpe#numberMiddlePages): adjusts the number of visible pages between the edge pages.   - Edge pages(https://v2.grommet.io/pagination?theme=hpe#numberEdgePages): adjusts the number of visible edge pages.   ## Accessibility ~~ Below are some accessibility requirements that ensure pagination is accessible for screen readers and keyboard navigation. If your team is developing with Grommet, these considerations are already handled, so no further action is required from your team. 1. Wrap pagination links in a `` element. 2. Provide an `aria-label=\"pagination navigaton\"` and `role=\"navigation\"`. 3. Individual page buttons should have an `aria-label` that reads \"Go to page X\", where X is the page that will be navigated to upon selection. 4. The active page button should have `aria-current=\"true\"`. 5. The next/previous arrow buttons should have `aria-label` that reads \"Go to next page\" and \"Go to previous page\", respectively. For more detailed documentation on these requirements, you can read more about accessible pagination(https://www.a11ymatters.com/pattern/pagination/). ### WCAG compliance ~~  "},{"name":"Radiobuttongroup","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/radiobuttongroup.mdx","content":"       ## Guidance ~~ ### Best practices ~~ - Keep labels concise and simple. Avoid lengthy descriptions, however err on clarity over brevity. - If there are more than five options, or if the default value is expected most of the time, consider using Select(/components/select) instead to avoid cluttering the experience. - Use when the user needs to see all related options. - Radio buttons should always be listed vertically with one choice per line. - Never add sub-categories to a RadioButtonGroup. ### When to use ~~ RadioButtonGroup is used to lay out a discreet list of mutually related options that are easily visible. RadioButtonGroup requires an input choice, so it is important to be clear with what is being asked of the user on the label. When users should be able to select more than one option, use CheckBoxGroup(/components/checkboxgroup) instead. ## Variants ~~ RadioButtonGroup is primarily used to select a single item from a list of two or more options. ### Validation ~~ Validation styling indicates that a selection was not made. In many cases, a clear label for the group and an error message of 'required' may be sufficient. Bonus points go to messages explaining why a required selection is beneficial to the user.      ### Disabled ~~ Indicates that the RadioButtonGroup input exists but cannot be interacted with until a precondition is met.      ## Accessibility ~~ ### WCAG compliance ~~ "},{"name":"Rangeinput","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/rangeinput.mdx","content":"       ## Accessibility ~~ ### WCAG compliance ~~   "},{"name":"Search","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/search.mdx","content":"       ## Guidance ~~ Search inputs provide a powerful means for users to access content quickly and efficiently. Many search best practices extend \"behind the scenes,\" such as how query strings are matched to relevant content and to the efficiency in which that information is retrieved. ### Placeholder ~~ Placeholder text should be brief and to the point.                         ### Auto-suggestions ~~ - Provide effective auto-suggestions(#search-with-auto-suggestions) whenever possible. - Auto suggestions accelerate search and allow users to focus on task completion. ### Returning search results ~~ - Use \"live filtering.\" When results are visible and quick to filter, results should be filtered as the user types. - Sort results by highest relevance. Relevance can be determined by keyword matching, however, to really elevate user experience, consider implementing probability based approaches. - Persist users' original query. This eliminates the need to re-type and assists query reformation if needed. - Persist users' recently used search queries. Remembering the user's previous efforts respects their time and serves as \"short cuts\" for returning to previously visited content. ## Search icon ~~ ### Placement ~~ The search icon may be placed either to the right or left of the input field. Icon position is controlled via the reverse(#icon-position) property. Place the icon in the position that most helps people to scan the page and identify the search field. Working as a visual aid, the intention should be for the search icon to be seen first and the placeholder text second. When deciding where to place the icon, consider where the search bar is located and how the user might be scanning the page (for example, in an F shape pattern from left to right). ### Interactivity ~~ The search icon is not interactive. The search may be submitted either \"onChange\" as the user types, \"onEnter\", or in some cases by clicking on an accompanying button. ## Clear search control ~~ When an input has `type=\"search\"`, many browsers will insert a native \"clear\" control inside the input that allows the user to clear the entire search string. The styling of this \"clear\" control is controlled by each browser, so it may differ visually from HPE brand colors and icons. Click into the search input to see the \"clear\" control.      ## Variants ~~ Visual and functional extensions for Search. ### Search with auto suggestions ~~ Suggestions provide users instantaneous feedback as they type, and aid by prompting with common search intents most closely matching the query in progress. Helpful matching functions include root word recognition and predictive text. Suggested queries should be sorted from highest probability match to lowest. Limit the number of suggested queries displayed to five or less.      ### Simple search ~~ Use simple search when its input field is desired to blend with its surrounding content, such as when used in a Header(/components/header).      ### Icon position ~~ Icon position is controlled via the reverse(https://v2.grommet.io/textinput?theme=hpe#reverse) property.      ## Accessibility ~~ Search inputs should be accessible. Ensure users have the ability to return results using their keyboard or by clicking a button. All search inputs should specify `type=\"search\"`. Use an `aria-label` in addition to a placeholder unless a visual label is provided. For additional detail, see ARIA form hints(https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/forms/Basic_form_hints). ### WCAG compliance ~~ {/* Search is just a TextInput with an icon provided. */}  "},{"name":"Select","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/select.mdx","content":"       ## Guidance ~~ Select is a flexible input element able to serve a wide variety of use cases. Though flexible, asking \"is Select the best tool in this circumstance?\" is a healthy exercise. Variants of Select, such as Select with Search(#select-with-search), or alternatives like RadioButtonGroup(/components/radiobuttongroup), MaskedInput(/components/maskedinput), or TextInput with suggestions(/components/textinput#textinput-with-suggestions) may be more appropriate for crafting an elegant user experience. ### When to use Select ~~ Because Select is flexible and familiar, the following questions are helpful to consider alternatives and/or confirm that Select is the most appropriate element: - Is there a need to conserve screen space? Select may be appropriate. - Ensuring collection of standardized values? Select may be appropriate. - Are there less than five options? Consider a CheckBoxGroup(/components/checkboxgroup) or RadioButtonGroup(/components/radiobuttongroup) as they may be more efficient for users. Select can hide information and requires extra clicks/taps for users to access that information. - Are there a large number of options? Lengthy scrolling can be problematic for users. Consider Select with Search(#select-with-search) or TextInput with suggestions(/components/textinput#textinput-with-suggestions). - Is the select for a State/Province in the context of collecting an address? Consider only asking for ZIP/Postal Code and automatically determining City, State, Country, etc. without user input. - Are the values in list well known and understood, such as Year? Consider TextInput with suggestions(/components/textinput#textinput-with-suggestions) or MaskedInput(/components/maskedinput). ### Selecting multiple options ~~ If multiple selections are permitted and there are more than 5 options, use SelectMultiple(/components/selectmultiple). Otherwise, consider using CheckBoxGroup(/components/checkboxgroup). ## Variants ~~ The Select input is flexible and may be extended to allow for multi-select, search, and create options. ### Select with search ~~ Allow users to quickly find their desired option by incorporating Search within the Select component. Select with search is especially useful when presenting lengthy options lists such as when selecting from countries or regions. TextInput with suggestions(/components/textinput#textinput-with-suggestions) and MaskedInput(/components/maskedinput) are also worth considering in circumstances where values are well known.      ### Validation ~~ Validation styling calls visual attention to the Select input with an error and should be accompanied by text instructing the user how to resolve. A \"required\" input error is the most common with Select since the available options are typically pre-defined.      ### Disabled ~~ Indicates that the Select input exists but cannot be interacted with until a precondition is met.      ## Accessibility ~~ Using Select as a form field is preferred for user experience. When Select is used in conjunction with FormField, users receive clear indication for the contents and purpose of the input. Additionally, this use promotes best practices in accessibility by ensuring user inputs are accompanied by labels used by assistive technologies. To properly associate FormField `label` with Grommet's Select component, ensure the Select has an `id` and the FormField has an `htmlFor` with the format of `${id}__input`.  ### WCAG compliance ~~  "},{"name":"Selectmultiple","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/selectmultiple.mdx","content":"  The SelectMultiple component is typically used as a form element but can also be leveraged for user experiences that include searching or narrowing down data. It contains an optional search field. When within a form, the SelectMultiple will support labels, error and disabled states.      ## When to use ~~ When multiple selections can be made in a list that contains 5 or more items. ## When not to use ~~ - For lists that offer less than 5 options, consider using a CheckBoxGroup(/components/checkboxgroup) instead. - When only a single selection is permitted, use the Select(/components/select) component instead. ## Anatomy ~~      1. **Select**: Displays current input value and control to open/close options drop. 1. **Selection Summary**: Succinct presentation of what a user can do, has done, and/or reset to default state. 1. **Search (optional)**: Helps narrow down or quickly find options corresponding to the entered keyword. 1. **Help Text (optional)** 1. **List**: Available options from which the user can choose 1. **List Item**: Clearly displays available option and its selected state. ## Sizing and scrolling ~~ - Depending on the length of the dropdown list, the height of the SelectMultiple can be increased or decreased as needed with the `dropHeight` prop. - For lists with more than 10 items, consider setting a max height to ensure optimum readability and scannability of list items. - It is recommended to show approximately 10-15 items before enabling a scroll. Showing more than that will potentially increase the cognitive load on the user. ## Best practices ~~ - Always use a label unless there is something else (such as preceding body text or headers) that makes that SelectMultiple’s purpose perfectly clear. - Ordering of lists - chronological/recency - Search: Consider including a search if your list is 10 items or longer to make it easier to browse options. ## Accessibility ~~ To properly associate FormField `label` with Grommet's SelectMultiple component, ensure the SelectMultiple has an `id` and the FormField has an `htmlFor` with the format of `${id}__input`.  ### WCAG compliance ~~  "},{"name":"Skeleton","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/skeleton.mdx","content":"        ### Use When ~~ - Waiting for content to be returned and displayed to a user, to provide a sense of page structure and minimize layout shifts. #### Don't Use When ~~ - Indicating the status for an ongoing activity where the result will be success or failure. Use Busy Button(/components/button?q=button#busy-buttonn), Spinner(/components/spinner) or Progress Bar (coming soon) instead. ### Anatomy ~~      Skeletons come in three different shapes - circular, rounded, and rectangular. The shape, size, and elevation of a Skeleton are all dependent on the UI elements that are loading.  Grommet has added `skeleton` property in order to make it easy to switch between a skeleton state and data-rich state for a variety of components. The components that currently support skeleton are: - Text, Paragraph, Heading - Button - Box, Card, Pageheader, Footer, Header ## Accessibility ~~ ### WCAG compliance ~~   "},{"name":"Spinner","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/spinner.mdx","content":"       ## Guidance ~~ Loading Spinners are used to notify the user that an action is being processed. This reassures the user of the system status. Loading spinners can be presented in various sizes depending on the context in which the spinner is being used. For fast processes (less than 300ms), a spinner may not be required. However, for a process that may take time, a spinner should be used. Avoid showing multiple Loading Spinners on a single page. ### When to use ~~ - When fetching data or content, where the expected response time is greater than ~300ms. - When loading more information into a Table or List. ## Variants ~~ A Spinner can be used in various ways to indicate to the user that a task is in process. ### Spinner within a list ~~      ### Spinner with announcement on screen reader ~~      ### Spinner loading content ~~ A Spinner allows users to know when something is being loaded without explicitly telling them. When using a spinner in a larger area you can increase the size of the spinner.      ## Accessibility ~~ For additional clarity for screen reader users, provide a message(https://v2.grommet.io/spinner#message) to the spinner that would explain to the user that the content is being loaded. Message(https://v2.grommet.io/spinner#message) can be provided as a string or as an object in the format of `{ start: ... , end: ... }`, where the \"start\" message is announced when the Spinner appears and the \"end\" message is announced when the Spinner closes. ### WCAG compliance ~~    "},{"name":"Tabs","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/tabs.mdx","content":"        ## Guidance ~~ Tabs can be used to rapidly navigate between different content while maintaining the existing context. The Tabs component serves as the outer wrapper and contains individual Tab components as children. ### Usage ~~ To create a set of Tabs, use the Tabs component as the outer wrapper with Tab components as its children. Providing a title prop to a Tab will populate the text on the actual tab. The children of each Tab will be the content that displays when the given tab is active. **It is recommended that you do not use more than 5 tabs in a group.** In order to create the most effective user experience, keep the number of tabs to a minimum. This allows the user to easily understand the scope of the information presented to them. With more tabs, the information can become overwhelming. **Keep labels short.** Using a simple, concise label such as \"Settings\" or \"Notifications\" helps the user easily decide which tab contains the content they need. Longer labels may clutter the layout and create a more effortful experience for the user. **If using Tabs as a navigation structure, be sure to connect them to the browser location.** This will allow proper active styling and routing to function. **If using Tabs as a navigation structure, don't use them in conjunction with other navigation structures.** Combining multiple navigation structures creates a confusing experience for the user. It can lead to difficulties in navigating through an application and in ability to remember where desired content lives. ### Alignment ~~ To maintain a clean, consistent presentation, all content should be aligned to the left edge of the Tabs component. - Apply `justify=\"start\"` to left-align the tabs and have their bottom border extend the full-width of the parent container. - Content within the Tab should be flush with the left edge of the Tabs component and have a vertical padding of `medium` to provide spacing and room for the content to breathe. ### Responsive Tabs ~~ When horizontal space is limited, only the Tabs that fit will be displayed. The remaining Tabs can be accessed by using the previous and next arrows or with the keyboard. #### Responsive behavior ~~ - Previous and next arrows will be present if the horizontal Tabs are fully outside the viewport. - Previous and next arrows are disabled if the horizontal Tab has no more Tabs to view towards the left or right. - Clicking on the previous and next arrows will show additional Tabs. At `xsmall` and `small` breakpoints(/templates/content-layouts?q=responsive#breakpoints) the arrows will show 1 additional Tab. At `medium`, `large`, or `xlarge` breakpoints(/templates/content-layouts?q=responsive#breakpoints), clicking the arrows will show 3 additional Tabs.       ### Avoid vertical tabs ~~ Considering the UX principles of consistency, simplicity, hierarchy, and responsiveness, the HPE Design System does not support or recommend the use of vertical tabs because they: - Break general layout conventions which aim to give the main content priority of horizontal screen real estate over navigational regions. - Create unneccessary complexity in a page layout by nesting navigation alongside content, introducing a more complex information hierarchy than needed. - Respond poorly at smaller resolutions, requiring them to reflow horizontally or collapse into a menu. Instead, it is recommended to use horizontal tabs already implemented in the Design System as they allow for a more simple page layout and information architecture and respond better on smaller resolutions. ## Variants ~~ Tabs can be used to control what information is presented to a user at a given time. They are effective for grouping information and allowing users to move between those groups without leaving their existing context. ### Tabs with icons ~~ An icon can be used on a Tab to provide additional context about the information contained within the tab. It is recommended that an icon is used in conjunction with a title to ensure the context of the tab is clear.      ### Tab states ~~ An individual Tab can take on various states: enabled, hover, and active. The styling of a tab differs between each of these states as an indicator to the user.      ## Accessibility ~~ Accessibility features such as role and aria-selected are built into Tabs. When a tab is selected, aria-selected is switched to true and toggled to false for all other tabs within the group. If you would like to provide a custom aria-label for screen reader users, you can do so by providing a string to the a11yTitle prop. ### WCAG compliance ~~  "},{"name":"Tag","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/tag.mdx","content":"        ## Use cases ~~ ### Displaying metadata ~~ Static tags(/components/tag#static) can be used to display non-critical, concise information with the purpose to annotate or label items. Tags can contain value only, or a name value pair to assist with classification.      ### Managing metadata ~~ Tags can be created, assigned and removed(/components/tag#removable) from resources or items by a user.      ### Filtering ~~ Interactive tags(/components/tag#interactive) can be activated by mouse or keyboard input to enable quick filtering. Interacting with the tag will display items that share the same assigned value.      ### Drawing attention ~~ Highlight tags(/components/tag#highlight) can be used to draw attention to an element on the page. They are a decorative variant of the static tag(/components/tag#static). Highlights should only contain descriptions that are temporary, such as “New”, “Updated”. As such they should not be used a permanent design feature.      ## Anatomy ~~      | Label | Region                | Purpose                                                                                                                             | Required | Notes                                                 | | :---: | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | :------: | ----------------------------------------------------- | | **1** | **Container**         | Controls padding, border & background color.                                                                                        | Required | Behavior and style will change depending on tag type. | | **2** | **Name**              | Descriptive label or category that identifies what kind of data is stored in the associated value.For example “Country” or “Color”. | Optional | Up to 128 characters max.                             | | **3** | **Value**             | The specific descriptive data associated with an item. For example “USA” or “Green”.                                                | Required | Up to 256 characters max.                             | | **4** | **Close Icon Button** | Used to indicate that tag is removable.                                                                                             | Optional | Required for only removable tags.                     | ## Types ~~ ### Static ~~ - Contains simple, concise information used to annotate, categorize, group or otherwise label items. - Used to display secondary or supplementary information related to an object or item. - Can be used to communicate the state or condition of something (e.g. published, deployed, new, updated, etc.). State is defined in notification taxonomy(/components/notification#taxonomy). - A tag should not be used to convey system status, that is considered primary information. - Static tags are not interactive in any way.      ### Interactive ~~ - Interactive tags enable users to discover, filter, or navigate to identically tagged items. - An interactive tag can be actioned by mouse or keyboard.     {}} value=\"Interactive\" />  ### Removable ~~ - A removable tag is interactive via the \"Close\" icon button. - Can be used to dismiss a category/value set from a filtered view. - Can be used to remove a value that has been assigned to an item or resource.     {}} />  ### Highlight ~~ - Used to indicate a temporary or transient state associated with an item - eg new, updated, promotional. - Draws attention but is no louder than a secondary/primary button. - A highlight tag is not interactive in any way. - A tags size should be limited to x-small or small. - Use “primary/blue” border for highlight tags. This treatment should be used sparingly.      ## Accessibility ~~ | Key             | Interaction                                                                                                                                                                                                           | | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Tab**         | Used to navigate between interactive tags. Focuses on tag if it is selectable. When there is a close icon present, icon receives focus. For read-only, screen reader will read alongside content from where it lives. | | **Space/Enter** | For interactive tags, selects the tag. For removable tags, remove the tag.                                                                                                                                            | ### WCAG compliance ~~  "},{"name":"Textarea","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/textarea.mdx","content":"       ## Guidance ~~ Use TextArea for multi-line input such as notes or comments. TextArea is used frequently within the context of a form, but there may be cases where it would exist independently. Placeholder text can be used to guide the user towards how to start their entry. ### Usage ~~ In order to give the user a hint about how long their response should be, set the initial size of the TextArea to the length of the response expected. In the context of a FormField, apply resize=\"vertical\" on the TextArea to ensure the TextArea doesn't expand beyond the width of the FormField it is contained in. In other contexts, the TextArea should be allowed to resize both vertically and horizontally. ## Variants ~~ A TextArea's visual state informs the user of its ability to be interacted with or if any validation errors have occured. ### Validation ~~ Used to indicate that a TextArea does not meet the validation requirements of its bounding FormField. Click the Validate button while the TextArea is empty to see the validation state.      ### Disabled ~~ Used to indicate that a TextArea cannot be interacted with.      ## Accessibility ~~ In every case possible, TextArea should be used inside of a FormField to ensure that a label is appropriately paired with the input. This behavior is important to screen reader users who need to know what context the TextArea is referring to. If you need to use TextArea outside of the context of a FormField, it is important to make sure the TextArea is labeled in an alternate way to meet accessibility requirements. Placeholder text does not serve as a sufficient means of meeting accessibility requirements for labels. To meet accessbility requirements, placeholder text should be used in conjunction with a label or aria-labelledby attribute. ### WCAG compliance ~~ "},{"name":"Textinput","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/textinput.mdx","content":"       ## Guidance ~~ The TextInput component allows the user to input shorter forms of data and content. Passwords and tags can also be used with the TextInput component. Style can be variable, based upon the use case and customer need that will elicit user confidence in success. ## About TextInput ~~ Text input fields perform text validation. Some use cases for TextInput include username fields, password fields, and search fields. In some cases, it may be beneficial to use an icon to reinforce the context. One example when an icon would be useful would be a search input. There are many ways to give the user hints about how to properly fill out a text input. In addition to the label, placeholder text can help guide the user. When you want to place syntax restrictions on the input, such as an email address or phone number, consider using MaskedInput(/components/maskedinput). A TextInput display the following states: enabled, focused, focused with value, validation, and disabled. ## Variants ~~ A TextInput's visual state informs the user of its ability to be interacted with or if any validation errors have occured. ### Password ~~ Used to maintain the privacy of the password, PIN, or any credentials allowing access to an account a user has entered. This is achieved by applying type=\"password\" to the TextInput.      ### With suggestions ~~ Used to prompt users with available options or suggestions. Suggestions may persist regardless of what the user has entered or may be filtered based on what the user has typed. One common use case for suggestions would be to display prior values for the same field.      ### Labeled by icon ~~ Some situations may need TextInput without a visual label, such as when implementing a search field. To meet accessibility requirements, the TextInput may be labeled by another visual context such as an icon with an id.      ### Validation ~~ Used to indicate that a TextInput does not meet the validation requirements of its bounding FormField. Click the Validate button while the TextInput is empty to see the validation state.      ### Disabled ~~ Used to indicate that a TextInput cannot be interacted with. When an input is disabled, it will not receive tab focus and will not be submitted with form data.      ### Readonly ~~ Used to indicate that a TextInput cannot be edited. When an input is readonly, it will still receive tab focus and be submitted with form data. Apply `readOnlyCopy` to TextInput to display a copy button in the input.      ## Accessibility ~~ In every case possible, TextInput should be used inside of a FormField to ensure that a label is appropriately paired with the input. This behavior is important to screen reader users who need to know to which context the TextInput is referring. If you need to use TextInput outside of the context of a FormField, it is important to make sure the TextInput is labeled in an alternate way to meet accessibility requirements. One approach is to use another visual indicator, such as the TextInput's icon, to serve as the label. See how this is done in the Labeled by icon(#labeled-by-icon) example. Placeholder text does not serve as a sufficient means of meeting accessibility requirements for labels. To meet accessbility requirements, placeholder text should be used in conjunction with a label or aria-labelledby attribute. While Grommet's TextInput supports a `defaultSuggestion` prop, it is not recommended for use because it can lead to potential \"context changes\" on screen readers such as VoiceOver. This would fail WCAG 3.2.1(https://www.w3.org/TR/WCAG22/#on-focus). Instead, order the suggestions such that the most relevant or likely are at the top. ### WCAG compliance ~~  "},{"name":"Tip","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/tip.mdx","content":"        ## Guidance ~~ Tips can be added to Button by Grommet tip props(https://v2.grommet.io/button#tip). Tips will display information upon hover and focus. Tips provide messages that give the user more information about an element. ### Usage ~~ 1. Don't use Tips for information that is vital to task completion. 2. Provide a brief and helpful content inside the Tip. 3. Support both mouse and keyboard hover. 4. Use Tip consistently throughout your site. 5. Tip should never contain interactive components. Make sure to test the Tip positioning to ensure that the content does not block other information pertinent to the user's goal. ### Truncation with Tip ~~ To display the full text when truncation occurs, hover over the truncated text and a Tip will be shown with the full text. Upon hovering, Tip presents additional information about a specific element in a small container. The Tip will remain visible as long as the user is hovering over the element. ## Variants ~~ There are a few different ways that you can use a Tip. ### Truncated table cell content ~~ Tips are useful to supplement truncated content within a table. In the example below, many of the service names are lengthy. Truncation may be applied cell content is constrained by column widths and supplemented with a tip upon hover to reveal the entirety of the cell's content.  ### Tip with icons ~~ An icon without a label should be provided a Tip to remove any ambiguity around an icon's meaning.      ### Tip with exit ~~ A Tip can be used to reiterate traditional symbols.      ### Tip content length ~~ Tip may be used for content varying in length. The size of the Tip will scale according to the content provided.      ## Accessibility ~~ Tips should support both mouse hover and keyboard focus. Do not use Tips for information that is vital for the user to complete the task. ### WCAG compliance ~~  "},{"name":"Togglegroup","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/togglegroup.mdx","content":"       ## Use cases ~~ ### Toggling views ~~ Typically used in a data collection toolbar to allow the user to switch between different data presentations such as map, list, chart, and table.      ## Anatomy ~~      | Label | Region        | Purpose                                                      | Required | Notes                                                       | | :---: | ------------- | ------------------------------------------------------------ | :------: | ----------------------------------------------------------- | | **1** | **Container** | Organizes children, how they appear and spaced.              | Required | --                                                          | | **2** | **Label**     | Describes what the button will do when selected.             | Optional | If no label is shown, icon is required.                     | | **3** | **Icon**      | Used to visually represent text label with or without label. | Optional | a11yTitle required. If no icon is shown, label is required. | ## Types ~~ ### Single select ~~ With single selection, where only one button can be toggled on at a time. This is the default behavior. ### Multiple select ~~ With multiple selection, multiple buttons can be toggled on at the same time. ## Accessibility ~~ In icon-only cases, ensure each icon has a clear `aria-label`. | Key                   | Interaction                                                                                                                    | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | **Tab**               | If nothing is toggled on, focuses on the first button in the group. Otherwise, focuses on the first button that is toggled on. | | **Left/Right Arrows** | Moves to other available buttons.                                                                                              | | **Space/Enter**       | Selects button with focus.                                                                                                     | ### WCAG compliance ~~  "},{"name":"Toolbar","parent":"components","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/components/toolbar.mdx","content":"       ## Accessibility ~~ ### WCAG compliance ~~  "},{"name":"All Design Tokens","parent":"design-tokens","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/design-tokens/all-design-tokens.js","content":"/* eslint-disable react/prop-types */            return (            }         a11yTitle={`${collection} token directory`}         justify=\"start\"         align=\"start\"         label={collection}         onClick={() => {           if (open) setOpen('');           else setOpen(collection);         }}       />                           {Object.keys(tokensObjcollection)             .sort()             .map(category => (                setActive(`${collection}.${category}`)}               />             ))}                        ); };  };  };  };             useEffect(() => {     if (openLayer && 'large', 'xlarge'.includes(breakpoint))       setOpenLayer(false);   }, breakpoint, openLayer);           if (openLayer) setOpenLayer(false);   };         return (                                {'large', 'xlarge'.includes(breakpoint) ? (                            {navContent}                        ) : undefined}                                                        {!'large', 'xlarge'.includes(breakpoint) ? (                   }                     a11yTitle=\"Open design tokens menu\"                     margin={{ top: '3xsmall' }}                     onClick={() => setOpenLayer(true)}                   />                 ) : undefined}                                    {activeCollection}                                               {/* eslint-disable-next-line no-nested-ternary */}               {active.includes('base') ? (                                ) : active.includes('static') ? (                                ) : undefined}                                                  {openLayer && (              setOpenLayer(false)}>               {navContent}                        )}                        ); }; export default AllTokens; "},{"name":"Color Usage","parent":"design-tokens","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/design-tokens/color-usage.mdx","content":"    ## Color names ~~ By combining terms from our color categories, as described in How to read design tokens(/design-tokens/how-to-read-design-tokens), we form semantic color names. | Example                                                         | Token                             | | --------------------------------------------------------------- | --------------------------------- | |              | color.background.back             | |  | color.background.selected.primary | |                 | color.text.primary                | |                  | color.icon.strong                 | ## Color categories ~~ Commonly used categories in color naming are property(#property), variant(#variant), state(#state) and scale(#scale). ### Property ~~ The anatomical part of an element to be styled. | Example                                                                       | Property   | Usage                                        | | ----------------------------------------------------------------------------- | ---------- | -------------------------------------------- | |                            | background | Backgrounds, pages, fills and surfaces.      | |  | border     | Borders around elements, dividers and rules. | | Aa                                                 | text       | Typography, such as paragraphs or labels.    | |                                                      | icon       | Iconography.                                 | |       | foreground | Foreground graphics.                         | ### Variant ~~ Stylistic variant of a token. | Example                                                        | Variant  | Usage                                                                         | | -------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------- | |   | primary  | Primary emphasis color for high visual prominence.                            | |  | neutral  | Generic color that does not need any particular emphasis with regards to hue. | |         | critical | Error or danger.                                                              | |          | warning  | Warning or caution.                                                           | |             | info     | Informational content.                                                        | |               | ok       | Success or everything is operating as expected.                               | |               | onStrong | For content (text and icons) that sit on strong backgrounds.                  | ### State ~~ Color for specific states. | Example                                                                      | State    | Usage                                      | Token example                           | | ---------------------------------------------------------------------------- | -------- | ------------------------------------------ | --------------------------------------- | |                  | hover    | For hover states of a particular color.    | color.background.hover          | |  | selected | For selected states of a particular color. | color.background.selected.primary.strong | ### Scale ~~ Colors can come in a variety of levels of emphasis or tone, named accordingly with a weak or strong modifier. #### Background color scale ~~ Background color variants may have a range of shades.  | Example                                                        | Emphasis | | -------------------------------------------------------------- | -------- | |  | xstrong  | |   | strong   | #### Text emphasis ~~ | Example                                            | Emphasis | | -------------------------------------------------- | -------- | | Aa  | strong   | | Aa | default  | | Aa    | weak     | "},{"name":"Component States","parent":"design-tokens","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/design-tokens/component-states.mdx","content":"         State gives confidence that an interaction has been registered, that a component can or cannot be interacted with, or that the system is in a particular state. Design tokens represent these states in a systematic, scalable way to ensure: - Predictable mapping of design tokens to components - Clarity for how the system should expand if new states are added ## Interaction vs application state ~~ A component should be styled based on combination of application state and interaction state. | State type      | Description                                                                    | | --------------- | ------------------------------------------------------------------------------ | | **Interaction** | Direct result of user interaction (e.g., the user hovered over a button).      | | **Application** | Result of the system (e.g., a input has been validated and there is an error). |  See validation state combinations(#supported-states) in the table below. ### Interaction state naming ~~ Interaction states use the CSS pseudo-class terminology (hover, focus, active). For the “resting state” of the component, the term “rest” is used. ### Application state naming ~~ Some application states correspond directly to CSS pseudo-classes (e.g., disabled), while others are named more generically to apply across components (e.g., “selected” can refer to a selected dropdown option or checked checkbox). Application states that have use cases within the design system are represented in the table below. ## Supported states ~~ In this table, “interaction” states are represented as column headings and “application” states are the rows. Checked cells represent valid combinations. If two application states exist at once, the component should be styled based on the top-most row in the table. For example, if a component is both “readonly” and \"selected\", it should be styled as \"readonly\".  |               |                           rest                           |                          hover                           |                          focus                           |                          active                          | Notes                     | | ------------- | :------------------------------------------------------: | :------------------------------------------------------: | :------------------------------------------------------: | :------------------------------------------------------: | ------------------------- | | none          |  |  |  |  | --                        | | error         |  |  |  |  | --                        | | disabled      |  |                            --                            |                            --                            |                            --                            | --                        | | readonly      |  |                            --                            |  |                            --                            | --                        | | selected      |  |  |  |  | --                        | | indeterminate |  |  |  |  | Only applies to checkbox. | | pinned        |  |  |  |  | --                        | ## Component-specific tokens ~~ For each component with component-specific tokens(/design-tokens/how-to-read-design-tokens#component), the applicable state combinations are provided as design tokens. "},{"name":"Element","parent":"design-tokens","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/design-tokens/element.mdx","content":"   In the HPE Design System, an \"element\" refers to a core UI building block. Elements can contain foundational items like text or icons, but \"can't be broken down any further without ceasing to be functional.\" (source: Atomic Design(https://atomicdesign.bradfrost.com/chapter-2/#atoms)) To understand what element tokens apply to, consider various UI components as levels from most fundamental to most composed: | Level                       | Example components                                  | | --------------------------- | --------------------------------------------------- | | **1. Typography, controls** | text, anchor, checkbox, radio button, toggle switch | | **2. Elements**             | button, input, select, menu, table cells            | | **3. Layout/compositional** | card, modal, toolbars                               | Many common \"elements\" (corresponding directly to native HTML tags or roles like button, input, select, etc.) have component-specific design tokens(/design-tokens/how-to-read-design-tokens#component) published. These design tokens reference element tokens. ## When to use ~~ Use element tokens when there is not a component-specific token available for an element. For example, a team may be designing a new component that is not offered by the design system. They can use element tokens to ensure that the new component aligns and adapts with the rest of the sizing system. Do not use element tokens for compositional components like cards, lists, or toolbars. Instead, use semantic layout tokens(/design-tokens/layout-and-spacing). ## Element sizes ~~ Element sizes are used to ensure consistent sizing and alignment across layouts. Sizes \"xsmall\"-\"xlarge\" are available. ## Supported design tokens ~~ The following design tokens exist for each element size. Replace `size` with the desired size (e.g., `xsmall`, `small`, `medium`, `large`, `xlarge`). | Property                            | Notes                                                                                                                                      | Example                                   | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------- | | **element.size.minHeight**        | Ensures elements achieve the desired minimum height even if internal content varies.                                                       |      | | **element.size.width**            | Use for fixed size components like avatar, spinner, etc.                                                                                   |             | | **element.size.height**           | Use for fixed size components like avatar, spinner, etc.                                                                                   |            | | **element.size.paddingX.narrow**  | Use for components that should have equal horizontal and vertical padding. Often this applies to square components like icon-only buttons. |   | | **element.size.paddingX.default** | Use for standard horizontal padding.                                                                                                       |  | | **element.size.paddingX.wide**    | Use for components that are fully rounded or need more horizontal affordance.                                                              |     | | **element.size.paddingY**         | --                                                                                                                                         |          | | **element.size.textToIconX**      | Use for spacing between text and icon.                                                                                                     |       | | **element.size.textToElementX**   | Use for spacing between text and an internal control like a checkbox.                                                                      |    | | **element.size.borderWidth**      | --                                                                                                                                         |       | | **element.size.lineHeight**       | --                                                                                                                                         |        | | **element.size.fontSize**         | --                                                                                                                                         |          | | **element.size.fontWeight**       | --                                                                                                                                         |        | | **element.size.icon.size**        | Applies to width and height of icon.                                                                                                       |         | "},{"name":"Global","parent":"design-tokens","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/design-tokens/global.mdx","content":"  ## fontStack ~~ Font stack design tokens are a list of fonts that are used in the design system. The first font in the list is the primary font, and the rest are fallback fonts. To learn more about options for how fonts can be loaded, read font delivery documentation(/foundation/typography#font-delivery).      ## breakpoint ~~ Breakpoint design tokens can be used for logic pertaining to layout adjustments as screen width changes. For example, a grid of cards may switch from a 3-column layout to a 2-column layout at the `medium` breakpoint.      ### Built-in breakpoint changes ~~ The values of semantic spacing and heading design tokens step down in size at the `small` breakpoint. These value shifts are built in to the system. When utilizing the CSS files, a media query is included in the \"dimension.small.css\" file to adjust the token values at the `small` breakpoint. ## fontWeight ~~ Font weight design tokens are used to define the weight of text elements. Each text size(/design-tokens/typography-system#text) has a default font weight, but this can be overridden by the `fontWeight` design tokens to add or remove emphasis based on the use case. The system uses `bold` sparingly because it can hurt readability at smaller text sizes and instead relies on the `medium` font weight to create visual emphasis.      ## focusIndicator ~~ This design token is used to define a standardized focus indicator for interactive elements. The focus indicator is a visual cue that helps users understand where they are in the interface and what element is currently in focus. This indicator should be used with the `:focus-visible` pseudo-class in CSS.      "},{"name":"How To Read Design Tokens","parent":"design-tokens","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/design-tokens/how-to-read-design-tokens.mdx","content":"      hpe.button.primary.rest.background  A token is read in a left-to-right order, moving from general to specific. The structure of the token naming schema intends to: 1. Establish the subject of the token (a color, a dimension such as spacing, a component such as button). 2. Specify the variant and state of the subject. 3. In the case of component tokens, identify the CSS property to be affected. ## Naming convention ~~ A consistent convention makes it easier to understand what tokens do, how they should be used, and how new tokens could be added in the future. These are all of the possible parts of a token name, but each type of design token(#types-of-design-tokens) uses a subset of these.      | Category      | Definition                                                                                                                                                                                                         | Examples                                       | Notes                                                                                                                                                        | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **prefix**    | Provides top-level encapsulation of a particular flavor of HPE theme. The prefix helps to avoid collisions and improve developer experience when scanning styles to identify those belonging to HPE Design Tokens. | hpe                                            | --                                                                                                                                                           | | **level**     | Identifies if a token is from the “base” (primitive) level of the tokens hierarchy.                                                                                                                                | base                                           | Primitive tokens point directly to raw values and should not be used directly by developers/designers.                                                       | | **type**      | The category of a token.                                                                                                                                                                                           | color, dimension, spacing, radius              | --                                                                                                                                                           | | **component** | A specific component (such as button) or a family of related components (such as input).                                                                                                                           | anchor, button, formField, menu                | For multi-word names, use camelCase.                                                                                                                         | | **variant**   | A stylistic variant of a token.                                                                                                                                                                                    | secondary, primary, critical, warning          | --                                                                                                                                                           | | **size**      | The t-shirt size of the component family or individual component.                                                                                                                                                  | small, medium, large                           | --                                                                                                                                                           | | **element**   | When a component has distinct pieces of anatomy, this refers to the specific sub-element.                                                                                                                          | item (in a menu), input (in a form field)      | --                                                                                                                                                           | | **scale**     | A size/emphasis modifier for primitive and semantic tokens.                                                                                                                                                        | strong, weak, 100, 200                         | --                                                                                                                                                           | | **state**     | Interactive or programmatically unique state.                                                                                                                                                                      | rest, hover, readOnly, selected, indeterminate | --                                                                                                                                                           | | **property**  | An item’s style. This is required for component tokens.                                                                                                                                                            | background, borderRadius, lineHeight, fontSize | It usually matches a CSS property, but it can also store other conceptual definitions such as size, paddingX, etc. For multi-word properties, use camelCase. | ## Types of design tokens ~~ Each type of token uses a subset of the overall convention. To learn about types of tokens, read the documentation of types of design tokens(/design-tokens/overview#types-of-design-tokens). ### Primitive ~~      | prefix | level | type       | variant | scale | Token                    | | ------ | ----- | ---------- | ------- | ----- | ------------------------ | | hpe    | base  | color      | green   | 100   | hpe.base.color.green.100 | | hpe    | base  | dimension  | --      | 400   | hpe.base.dimension.400   | | hpe    | base  | fontSize   | --      | 100   | hpe.base.fontSize.100    | | hpe    | base  | lineHeight | --      | 100   | hpe.base.lineHeight.100  | ### Semantic ~~ Semantic tokens represent global patterns.      | prefix | type      | subtype    | variant | scale  | state | Token                                     | | ------ | --------- | ---------- | ------- | ------ | ----- | ----------------------------------------- | | hpe    | color     | --         | primary | strong | --    | hpe.color.primary.strong                  | | hpe    | spacing   | --         | --      | large  | --    | hpe.spacing.large                         | | hpe    | color     | background | primary | strong | hover | hpe.color.background.primary.strong.hover | | hpe    | radius    | --         | --      | large  | --    | hpe.radius.large                          | | hpe    | text      | --         | --      | xlarge | --    | hpe.text.xlarge                           | | hpe    | fontStack | --         | primary | --     | --    | hpe.fontStack.primary                     | ### Component ~~ Component tokens represent tokens for specific components and should not be used to style a different component.      | prefix | component | variant   | size   | element | state    | property    | Token                                     | | ------ | --------- | --------- | ------ | ------- | -------- | ----------- | ----------------------------------------- | | hpe    | button    | secondary | medium | --      | --       | borderWidth | hpe.button.secondary.medium.borderWidth   | | hpe    | button    | primary   | --     | --      | disabled | background  | hpe.button.primary.disabled.background    | | hpe    | menu      | default   | medium | item    | --       | paddingX    | hpe.menu.default.medium.item.paddingX     | | hpe    | menu      | default   | item   | --      | rest     | background  | hpe.menu.default.item.rest.background     | | hpe    | select    | default   | medium | option  | --       | paddingY    | hpe.select.default.medium.option.paddingY | | hpe    | select    | default   |        | option  | rest     | textColor   | hpe.select.option.rest.textColor          | ## Token delimiters ~~ While this documentation uses `.` dot as a delimiter, token parts should be separated by the appropriate character for a given framework. For example, CSS variables use the `-` character. "},{"name":"Index","parent":"design-tokens","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/design-tokens/index.js","content":"                                               return (                                {results.map((type, index) =>                   type.data?.length ? (                                                                     {type.data.map(item => (                                                    ))}                                                               ) : null,                 )}                            );           }}                         ); export default Tokens; "},{"name":"Layout And Spacing","parent":"design-tokens","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/design-tokens/layout-and-spacing.mdx","content":"      ## Spacing ~~ Spacing tokens specify `pad`, `gap`, and `margin`.      ## Containers ~~ Container design tokens specify the minimum, maximum, or fixed height and width of  content containers(/foundation/content-container-sizes).      ## Radius ~~ Radius design tokens define corner rounding for elements.      ## Border width ~~ Border width design tokens specify border thickness.      "},{"name":"Overview","parent":"design-tokens","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/design-tokens/overview.mdx","content":"    ## Overview ~~ Design tokens allow HPE digital experiences to be presented as a unified, one-HPE. Tokens establish consistency by serving as a single source of truth encoding HPE's visual language. They are delivered in an easy-to-consume manner allowing the visual style to fluidly evolve along with HPE and customer needs. ## Encoding HPE's visual language ~~ Design tokens codify all decisions making up a design system's visual style. Tokens represent colors, typography, spacing, motion, and more through clear names specifying how and where the token should be applied. Consuming token names, as opposed to the values to which they resolve, builds inherit agility and flexibility into the system. Underlying values can be updated at the source of truth — and then seamlessly consumed by teams with little-to-no effort on their part. Simply point to the latest version and the updated styles are available in designs, sites, and applications. This means HPE digital experiences can be elevated more rapidly as a unified one-HPE. ## What is a design token? ~~ Design tokens represent color, typography, spacing, motion, and other style values by a clear name conveying its intended usage. An HPE design token consists of: | Property        | Description                                              | Example                   | Required                                    | | --------------- | -------------------------------------------------------- | ------------------------- | ------------------------------------------- | | **Name**        | A self-documenting name that represents the coded value. | hpe.color.background.back |  | | **Value**       | The value of the token.                                  | #f7f7f7                   |  | | **Type**        | A category for the token's value.                        | color, dimension, shadow  | Optional                                    | | **Description** | Concise text to describe how the token should be used.   | --                        | Optional                                    | To know more about token naming, visit How to read design tokens(/design-tokens/how-to-read-design-tokens). ## Why are design tokens important? ~~ Design tokens establish a source of truth for HPE's visual style in a tech-agnostic format, enabling a truly consistent, unified experience across applications. Token names are purpose-driven, rather than hard-coded values, which provides the flexibility for token values to evolve over time with our visual style. When tokens are implemented across design and development, style updates will propagate consistently across applications simply by pulling in the latest version of the tokens. Design tokens allow us to: - Codify design decisions - Enable teams across various tech stacks to build efficiently and consistenly with the HPE Design System - Replace manual maintenance methods with faster automated processes that keep design and development synchronized - Build a shared language across design and development ## Types of design tokens ~~ Tokens are grouped into 3 levels: primitive(#primitive-tokens), semantic(#semantic-tokens), and component(#component-tokens). Each level exists to convey specificity, intended usage, and enhance token consumption and delivery. The name and intended use of a token becomes more specific as you move from primitive to semantic to component levels.  ### Primitive tokens ~~ Primitive tokens define the most foundational level of the token system, establishing fundamental attributes like color and dimension. The value of a primitive token will always be a CSS value such as a hex code, pixel, or rem value. Typically, primitive token names describe the token value and not where it should be applied. Primitive design tokens should not be used directly. They exist to provide the foundational options and be referenced in semantic and component design tokens.              hpe.base.color.green.600     ### Semantic tokens ~~ Semantic tokens provide meaning to a primitive token. It's name specifies how and when the token should be applied and its value references another lower-level token. The value of a semantic token can either be a reference to a primitive token or another semantic token. Building with semantic tokens, creates flexibility for a single token to have multiple values dependent on context. For example, the value for the token `hpe.color.background.back` might differ for light versus dark mode. Similarly, the value for the token `hpe.spacing.large` might differ for wide versus narrow viewports.              hpe.background.primary.strong     ### Component tokens ~~ Component tokens capture specific design decisions for an individual component (e.g. button) or family of related components (e.g. inputs). The value of a component token can either be a reference to a primitive token, semantic token, or another component token.              hpe.button.primary.rest.background        }     primary     reverse     size=\"large\"   />  "},{"name":"Typography System","parent":"design-tokens","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/design-tokens/typography-system.mdx","content":"     There are two categories of typography design tokens: heading and text. Each are offered in a range of t-shirt sizes. At each t-shirt size, there is a defined font-size, font-weight, and line-height. The values of each typography value were chosen to ensure readability as well as alignment with the broader spacing system(/design-tokens/layout-and-spacing#foundational-scale). Always use all parts of a typography t-shirt size together; do not mix and match tokens of different t-shirt sizes on a single text element. ## Heading ~~ Heading design tokens should be used on HTML heading elements (h1-h6). Heading tokens are offered in 6 sizes: \"xlarge\"-\"xxsmall\". Generally, an h1 should be styled with the \"xlarge\" token, an h2 with \"large\", and so on.      ## Text ~~ Text design tokens should be used for body text. Text tokens are offered in 10 sizes: \"xsmall\"-\"6xl\".      "},{"name":"Using Design Tokens In Code","parent":"design-tokens","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/design-tokens/using-design-tokens-in-code.mdx","content":"## Using tokens with Grommet ~~ There is no need to install \"hpe-design-tokens\" or change how you build with Grommet. The HPE Design System team has mapped \"hpe-design-tokens\" into \"grommet-theme-hpe\", so there should be no change to your workflow. ## Using tokens in non-Grommet projects ~~ ### Install hpe-design-tokens ~~ Run the following command to add HPE design tokens to your project.    ### Apply tokens ~~ HPE Design Tokens are exported in a variety of formats to support teams across tech stacks. The currently supported formats are: - CSS variables - ESM - CommonJS If the exports from `hpe-design-tokens` do not meet the needs of your team, please reach out to our team in `#hpe-design-system` in Slack. #### CSS variables ~~ To use hpe-design-tokens as CSS variables, first import the CSS files into your project. How these files are imported will depend on your tech stack.  Then, apply the token directly to a CSS property, or create your own CSS variable that can be modified across states. To programmatically build up CSS classes, see Generate CSS class names(#generate-css-class-names).  #### ESM ~~ To use hpe-design-tokens as ESM, import the modules into your project. This format is intended to be used in conjunction with the CSS files. The values returned are the CSS variable for each design token.  #### CommonJS ~~ To use hpe-design-tokens with CommonJS, import the modules into your project. This format is intended to be used in conjunction with the CSS files. The values returned are the CSS variable for each design token.  ### Theme modes ~~ Building with semantic design tokens(/design-tokens/overview#semantic-tokens) allows theme modes, such as light and dark, to be easily applied to an application or, when appropriate, a subsection of a page. The supported theme modes are: - light - dark - auto (responsive to user's operating system preference) Light mode is the default theme mode. To apply light mode, no additional steps are needed. To apply dark mode: 1. Import the dark mode CSS file(#css-variables). 2. Apply `data-mode=\"dark\"` to the `html` tag of the application or to a subsection.  or, to apply to a subsection of the page:  To apply auto mode: 1. Import the CSS color files(#css-variables). 2. Apply `data-mode=\"auto\"` to the `html` or root tag of the application.  ### Generate CSS class names ~~ This code snippet provides a starting point for how to programmatically generate CSS class names for components using either the ESM(#esm) or CommonJS(#commonjs) outputs.  "},{"name":"Using Design Tokens In Figma","parent":"design-tokens","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/design-tokens/using-design-tokens-in-figma.mdx","content":"  In Figma, design tokens are stored as variables and styles. They are used by applying these to properties in a file. Use these Figma guides to learn more about Figma variables(https://help.figma.com/hc/en-us/articles/15339657135383-Guide-to-variables-in-Figma) and how to apply variables to designs(https://help.figma.com/hc/en-us/articles/15343107263511-Apply-variables-to-designs). ## Add design tokens to Figma designs ~~ To use HPE design tokens in Figma as a product designer, you’ll need to enable (\"Add to file\") the Design tokens - Semantic(https://www.figma.com/design/vH5MOEoXU5Kv7qWvBqiUC2/Design-Tokens---Semantic?node-id=0-1&t=geiVllvWWwqLWpfD-1) library in your design files. See the Figma guide on using libraries(https://help.figma.com/hc/en-us/articles/360041051154-Guide-to-libraries-in-Figma) if needed. These tokens are intended to be used generically across use cases and cover the following categories: As variables: - Color - Spacing - Size - Radius - Border width As styles: - Typography - Elevation  ## Semantic token types in Figma ~~  ## Variable scoping ~~ We have scoped variables only to the properties they apply to. For example, in Figma, border color tokens (e.g. color.border.default) can only be applied to strokes and borderRadius tokens (e.g. radius.small) can only be applied to corner radius in Figma. This should make it easier to find and apply tokens in Figma. "},{"name":"Versioning","parent":"design-tokens","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/design-tokens/versioning.mdx","content":"                                            ## Production-ready versions ~~ ### ^2.0.0 ~~ This release, referred to as \"v2-Landmark,\" provides production-ready support for HPE's refreshed visual identity (October 2025 - present). It introduces the new Landmark color palette and the HPE Graphik font face to align with the updated brand expression. For Grommet applications, v2-Landmark is available by grommet-theme-hpe v8.x(https://github.com/grommet/grommet-theme-hpe/releases/tag/v8.0.0) In the HPE Design System Figma Component Library(https://www.figma.com/design/HDckqS2MWhINfC8EIQPMV1/HPE-Design-System-Components-V2?m=auto&t=NjHwxPFWYTvhZTP5-6), this is the default theme. ### ^1.0.0 ~~   This HPE theme was introduced in February 2025. For Grommet applications, v1 is made available in grommet-theme-hpe versions 6.x(https://github.com/grommet/grommet-theme-hpe/releases/tag/v6.0.0) - 7.x(https://github.com/grommet/grommet-theme-hpe/releases/tag/v7.0.0). In the HPE Design System Figma Component Library(https://www.figma.com/design/HDckqS2MWhINfC8EIQPMV1/HPE-Design-System-Components-V2?m=auto&t=NjHwxPFWYTvhZTP5-6), this can be opted into by changing variables to use the \"v1\" modes. View the Themes and modes(https://www.figma.com/design/2CGX8BHVhxV3VKhlymv36y/Guide---Themes-and-Modes?node-id=32-267&t=t0OeJSFRbRMEuDXv-0) file in Figma to learn more about opting into different theme versions. ### ^0.9.0 ~~ This version served as the HPE theme from May 2023 through January 2025. This version is available in grommet-theme-hpe v5.x(https://github.com/grommet/grommet-theme-hpe/releases/tag/v5.8.0). In the HPE Design System Figma Component Library(https://www.figma.com/design/HDckqS2MWhINfC8EIQPMV1/HPE-Design-System-Components-V2?m=auto&t=NjHwxPFWYTvhZTP5-6), this can be opted into by changing variables to use the \"v0\" modes. View the Themes and modes(https://www.figma.com/design/2CGX8BHVhxV3VKhlymv36y/Guide---Themes-and-Modes?m=auto&t=S46XDDtRKeksmQ1c-6) file in Figma to learn more about opting into different theme versions.  ## Migration ~~ ### Migrating from v1 to v2 ~~ v2-Landmark introduces significant updates to align with HPE's refreshed visual identity. This is a major version change reflecting a new brand expression and includes breaking changes. A full list of changes and detailed instructions can be found in the Migrating from hpe-design-tokens v1 to v2-Landmark guide(https://github.com/grommet/hpe-design-system/wiki/Migrating-from-hpe%E2%80%90design%E2%80%90tokens-v1-to-v2%E2%80%90Landmark) and the grommet-theme-hpe v7 to v8 Migration Guide(https://github.com/grommet/grommet-theme-hpe/wiki/Migrating-from-HPE-Theme-7.x-to-8.x). ### Migrating from v0.9.0 to v1.0.0 ~~ v1 reflects styling of the updated HPE theme. For `hpe-design-tokens`, there are no breaking API changes from v0.9.0 to v1.0.0, so teams   may upgrade directly to v1.0.0 without code modifications. However, it is recommended to  review the changelog(https://github.com/grommet/hpe-design-system/releases/tag/hpe-design-tokens%401.0.0)  to understand the token value changes. For `grommet-theme-hpe`, there are breaking changes. To make the upgrade process smoother, the complete migration has been divided into to two steps. The first focusses on visual style  treatments applied to components; the second introduces expanded t-shirt sizing options. Teams  have the option to complete both steps at once or one at a time for greater flexibility. 1. Upgrade from v5.x to v6.x (grommet-theme-hpe v5 to v6 Migration Guide(https://github.com/grommet/grommet-theme-hpe/wiki/Migrating-from-HPE-Theme-5.x-to-6.x)) 2. Upgrade from v6.x to v7.x (grommet-theme-hpe v6 to v7 Migration Guide(https://github.com/grommet/grommet-theme-hpe/wiki/Migrating-from-HPE-Theme-6.x-to-7.x)) ## Semantic versioning ~~ HPE Design tokens follows the standards defined by semantic versioning with slight adaptations at the major version level to align with hpe-design-tokens as a style delivery mechanism. Given a version number MAJOR.MINOR.PATCH, increments will occur when: **1. MAJOR version** when there is a significant change to HPE’s brand expression and/or there are incompatible changes to the API. Significant changes to the look and feel of HPE’s brand &mdash; even if no breaking changes to the namespace are made &mdash; will be signaled via a major change (i.e. the look and feel of the new major version is not compatible with the look and feel of the previous). This signals that if service A is on v1.y.z and service B is on v2.y.z, there will be a mismatch in overall experience. **2. MINOR version** when there is functionality added in a backward compatible manner. Examples include: - Introducing a new token. - Updating a token value in an expected, minor way. For example, slightly darkening or lightening a text color based on user testing/feedback. **3. PATCH version** when backward compatible bug fixes are made. Examples include: - Fixing a typo in a token value. - Fixing a color value to meet accessibility requirements. "},{"name":"Feedback","parent":"pages","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/feedback.js","content":"        export default Feedback; "},{"name":"Accessibility Transcript File","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/accessibility-transcript-file.mdx","content":"Link to video(https://d3hq6blov2iije.cloudfront.net/media/BILL-ACCESS-VID.mp4). The video shows Bill, a white man with blondish brown hair and a mustache, in his office wearing a long-sleeved lavender-blue dress shirt with the HPE rectangular-shaped, multi-color logo against a black background as the background. Bill speaking Hello, my name is Bill Tipton and I work for Hewlett Packard Enterprise as a Product Accessibility Champion. As part of my responsibilities, I educate and advise our product designers, developers, and decision-makers on accessible user experiences. Unfortunately in May of 1999, I suddenly went completely blind. Since then, I have used a screen reader daily to access the internet and other digital technologies. I often experience what it is like to attempt to use software with many accessibility and usability issues. It is not a pleasant feeling or experience when you are excluded from accessing a product due to technical issues that could have easily been avoided if somebody took the time to incorporate accessibility early in the design or development process. Although I am a member of the disabled community, I cannot speak for all people with disabilities. However, I personally would like the chance to be able to use all digital technologies including software effectively, so I am able to participate equally in all of life's digital opportunities. Through direct engagements, live demonstrations, and usability evaluations, I highlight the requirements, design standards, and value to our business success by supporting a diverse set of user personas, including our valued customers with disabilities. I encourage all researchers, product designers, developers, product managers, and others to incorporate accessibility and usability to create more accessible products and experiences. In life and in our work, it is important to continuously advocate for inclusive environments for all, including becoming an ally for our disabled community. Thank you, and now let's go out and create some positive change. "},{"name":"Accessibility","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/accessibility.mdx","content":"   At HPE, we believe in being a force for good. We solve for humanity with humanity. We use technology to make the world better. We are unconditionally inclusive. **We believe that being accessible is a requirement, not an option**. In the video below, Bill Tipton, an HPE Product Accessibility Champion, discusses his role and the importance of inclusive design and development.  Everyone has the right to fully access and take advantage of the web. Web accessibility is focused on making content usable for the widest set of people, including those with disabilities. Aligned with the Web Content Accessibility Guidelines (WCAG) 2.2(https://www.w3.org/TR/WCAG22/), HPE adheres to the following four core principles to provide users with the most accessible experience:  Creating accessible applications means providing experiences that are easily usable by those who rely on keyboard navigation, speech input software, screen readers, alternative input devices (like head pointers), screen magnification software, who are colorblind, or who are experiencing some other permanent, temporary, or situational disability. Accessibility covers a spectrum of disabilities, including but not restricted to blindness, low vision, hearing and cognitive impairments and situational disabilities. From using glasses to aid with sight to a temporary broken bone to carpal tunnel, about 25% of the United States population(https://www.cdc.gov/ncbddd/disabilityandhealth/infographic-disability-impacts-all.html) lives with some type of disability, permanent or not. ## Built into all Design System tools ~~ Considerations for sight, mobility, hearing, and cognition are incorporated into all HPE Design System components, patterns, and guidance, providing design and development tools for all teams to build accessible applications. Get started with these resources and tools(#automated-testing-tools) to perform a baseline audit of the accessibility of your application. ## Designer and software developer guides ~~ The following collection of guides from the HPE Product Accessibility Program Office(https://hpe.sharepoint.com/sites/F5/CTO/Office/Accessibility/Pages/index.aspx) help designers and developers create accessible products which meet the needs of HPE’s clients.  ## Accessible product design videos ~~ A collection of short educational videos from HPE explaining basic accessible design principles in software and web technologies. Each video is less than 10 minutes and is accompanied by a “Pocket Guide” with key takeaways that can be found under HPE Accessible Design Training(https://hpe.sharepoint.com/sites/f5/cto/office/Accessibility/Pages/accessible-design-training.aspx).  ## Designing for accessibility ~~ All components and assets in the HPE Design System Figma library are built using Design Tokens(https://design-system.hpe.design/design-tokens) that align with accessibility standards. By using these prebuilt components or applying the design tokens (a.k.a Figma variables) in your own designs, you gain access to styles that meet WCAG guidelines. Not part of the Design System Figma? See our Designer Guidance(https://design-system.hpe.design/foundation/designer-guidance#setting-up-your-figma-account) to sign up. ## Developing for accessibility ~~ We recommend you develop your apps using Grommet(https://v2.grommet.io/) because it seamlessly integrates with grommet-theme-hpe(https://github.com/grommet/grommet-theme-hpe)and is built to support keyboard navigation, HTML landmarks, and many ARIA attributes out of the box. While supplemental attributes may need to be implemented and accessibility testing should still be performed, Grommet handles many of the general DOM requirements for you. For guidance on setting up your development environment, see Developer Guidance(/foundation/developer-guidance). ## Accessibility support at different levels ~~ Accessibility is a shared responsibility across the product development process. The HPE Design System provides foundational support, while designers and developers must ensure that accessibility is met in real-world implementations. It is important to understand what is offered in terms of accessibility by the Design System and what is expected from the consumers of the Design System. | Accessibility consideration | Description                                                                             | Grommet + HPE Theme                                                                                                       | Design tokens only (separate lib)                                                                                                                                 | | --------------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Core assets**             |                                                                                         |                                                                                                                           |                                                                                                                                                                   | | Color                       | Contrast ratios                                                                         |                                                                      | Review and apply: Color palette(/foundation/color) Color usage(/design-tokens/color-usage) Color pairing(/foundation/color-pairing)                         | | Typography                  | Font legibility, stroke widths, size, text scaling, line height, spacing, styling       |                                                                      | Typography(https://design-system.hpe.design/foundation/typography?q=typo) Typography system(https://design-system.hpe.design/design-tokens/typography-system) | | **Components**              |                                                                                         |                                                                                                                           |                                                                                                                                                                   | | Component behavior          | Keyboard navigation, ARIA support, focus handling                                       |                                                                      | Must implement accessible behaviors manually                                                                                                                      | | Focus style & states        | -                                                                                       |                                                                      | Component states(https://design-system.hpe.design/design-tokens/component-states)                                                                               | | ARIA roles & attributes     | Must provide context-specific ARIA values                                               |                                                                      | Fully responsible for correct use of ARIA roles, relationships, and properties                                                                                    | | Responsiveness              | Sizing at different breakpoints                                                         |                                                                      | Layout and spacing(https://design-system.hpe.design/design-tokens/layout-and-spacing)                                                                           | | Semantic HTML & Structure   | Use semantic elements (e.g., `` `` ``) |                                                                      | Must ensure correct semantic structure is applied                                                                                                                 | | **Content**                 |                                                                                         |                                                                                                                           |                                                                                                                                                                   | | Alt text & descriptions     | -                                                                                       | Must provide descriptive alt text for images and media                                                                    | Must provide descriptive alt text for images and media                                                                                                            | | Labeling                    | Forms, buttons, error messages, etc.                                                    | Must supply meaningful and descriptive labels                                                                             | Must supply meaningful and descriptive labels                                                                                                                     | | Readability                 | Provide examples, placeholder text, and documentation using plain, clear language.      | Review Design System guidance around Voice and Tone(https://design-system.hpe.design/foundation/voice-and-tone?q=voice) | Review Design System guidance around Voice and Tone(https://design-system.hpe.design/foundation/voice-and-tone?q=voice)                                         | ## Testing for accessibility ~~ The following are actions you can incorporate into your workflow to better test and ensure accessibility across the board: - **Accessibility first.** If accessibility is incorporated into the design process and development lifecycle as early as possible, many violations could be avoided in the future. More research, dialogue, testing and empathy will increase the accessibility of HPE products. - **Conduct research.** It is important to understand the limitations and pain points of the audience you are trying to engage with and build for. Read about the current best practices and standards for the interface you are building. Understand how users with disabilities will interact with your product. - **Try it yourself.** When testing your products manually by yourself, it is important to simulate the experience of a person with a disability to the best of your capabilities in order to build empathy. Make sure to test with multiple assistive technologies and operating systems. For example:   - Turn your monitor off when using a screen reader.   - Avoid any reliance on your mouse.   - Use technologies to aid in simulating disabilities(#disability-simulator-tools) such as color blindness, dyslexia and tunnel vision. - **Observe real people.** The best way to understand the problems that users with disabilities face is to see how they navigate in their daily lives. Break down assumptions by learning about disabilities outside of the context of the web, too. - **Test with real users.** Automated testing tools only catch approximately 30-50% of accessibility violations. Manual testing is essential to thoroughly conducting an accessibility test on a product. Test with a variety of users with disabilities to ensure full coverage. Bill Tipton(https://hpe.sharepoint.com/sites/f5/cto/office/Accessibility/Pages/bill-tipton-biography.aspx), from the Product Accessibility Office, is an excellent internal resource for usability testing. Bill has used a screen reader in his daily life since 1999 when he lost his eyesight. Please email him with any of your product testing questions and he will respond at the earliest convenience. - **Be an advocate.** Testing does not end at the final report of accessibility violations of a product. To further advance accessibility, after testing, you should remain an active ally and advocate for the disabled community. Amplifying all voices will lend a hand to making the internet more inclusive. ## Automated testing tools ~~ The following testing tools can be used to help check code, designs, and applications for accessibility. Automated testing tools will not catch 100% of your product's accessibility violations, but offer a good initial report of issues to track and fix. ### Continuous integration and delivery tools ~~ - Lighthouse Github Action(https://github.com/jakejarvis/lighthouse-action): Built into the Design System repo(https://github.com/grommet/hpe-design-system/blob/master/.github/workflows/main.yml), this Github action performs a Lighthouse audit on open pull requests to ensure no accessibility violations, among other checks. - axe-core(https://github.com/dequelabs/axe-core-npm/tree/develop/packages/react): An accessibility testing engine built to integrate with existing functional testing to help automate accessibility checks. - axe-testcafe(https://www.npmjs.com/package/axe-testcafe): A TestCafe module that allows you to use the aXe accessibility engine in TestCafe tests. Some use of these tests has been incorporated into the Design System testing(https://github.com/grommet/hpe-design-system/blob/master/apps/docs/src/tests/accessibility/axe.js). ### Browser extension tools ~~ - AxeDev Tools(https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US): Identifies violations and pinpoints them so you are able to easily see and fix them. - Access Assistant(https://chrome.google.com/webstore/detail/access-assistant/ojiighldhdmahfdnhfdebnpmlbiemdfm/related): Offered by Level Access(https://www.levelaccess.com/), this tool identifies the most common, highest risk accessibility violations on a product. Reports can be saved to monitor compliance over time. - WAVE (Web Accessibility Evaluation Tool) Browser Plugin(https://wave.webaim.org/extension/): Scans webpages to recognize missing HTML requirements and color contrast standards. - Lighthouse(https://developers.google.com/web/tools/lighthouse): Integrated into Chrome, this tools is available as a tab after clicking 'Inspect' on a webpage and will generate an accessibility report for the page. - ANDI Browser Tool(https://www.ssa.gov/accessibility/andi/help/install.html): Activate on a page to check the accessibility of images, headings, color contrast, data tables, links, and more. ### Disability simulator tools ~~ - Silktide(https://silktide.com/resources/toolbar/): An extension tool that helps simulate disabilities on the web including color blindness, dyslexia, tunnel vision, cataracts and blindness. - WebAIM Color Contrast Checker(https://webaim.org/resources/contrastchecker/): Check color contrast ratios of specific color values to identify if they meet WCAG AA and/or AAA standards. - Colorblind Web Page Filter(https://www.toptal.com/designers/colorfilter/): See what your application looks like to users with various types of colorblindness. ## Government standards and regulations ~~ To help enforce the World Wide Web's accessibility, policies and laws have been put in place which require certain standards to be met for all web, software and non-web documents. As a designer or developer, we are morally responsible for creating accessible products, and it is necessary that we are aware of the mandated standards established across the world. The following links provide insight into how governments and policy makers have come to include accessibility into laws, emphasizing the importance of making the web inclusive for all. In general, it is helpful to understand some of these policies and how they may affect your work product. - Web Content Accessibility Guidelines (WCAG) 2.1(https://www.w3.org/TR/WCAG21/): A robust set of international accessibility design guidelines. 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. - U.S. Section 508(https://www.section508.gov/): This site provides guidance for IT accessibility, covering program management, procurement, tools, training, and policy compliance. - Americans with Disabilities Act (ADA)(https://www.ada.gov/ada_intro.htm): An equal opportunity law that prohibits discrimination against people with disabilities where public services are offered — now including the public web domain. - European Accessibility Act (EAA)(https://ec.europa.eu/social/main.jsp?catId=1202): A directive that aims to improve the market for accessible products and services that have been identified as most important for individuals with disabilities. ## External resources ~~ - WebAIM Introduction to Web Accessibility(https://webaim.org/intro/): An introduction on how accessibility improves the Web for all users. - The A11y Project Checklist(https://www.a11yproject.com/checklist/): A checklist using WCAG 2.1 as a reference for developers and designers to ensure their product's accessibility. - U.S. Web Design System Principles(https://designsystem.digital.gov/design-principles/#embrace-accessibility): These principles and key guidelines outline how you should approach accessibility from a design system perspective. "},{"name":"Background Colors Guidance","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/background-colors-guidance.mdx","content":"      The overall design philosophy is to distinguish content sections with the strategic use of color and avoid the use of excessive borders. This helps reduce visual clutter which a reader's eye and brain must sift through. The application of background colors creates a visual hierarchy supporting the information hierarchy for the page. When applying background colors to content or layout, it is helpful to think about the content's role and relation to the page's information hierarchy. ## Basic or layered approach? ~~ There are two approaches to how background colors should be used: Basic(#basic) or Layered(#layered). For consistency across an application, a single approach should be used app-wide. The decision to use the Basic or Layered approach comes down to how much visual differentiation is desired between background and foreground elements. - If a more subtle distinction is desired, use the Basic(#basic) layout. - If a more defined contrast is desired, such as what is used for this Design System website, use the Layered(#layered) layout. A single approach should be used app-wide. You should not use the layered approach on some pages of an application and the basic approach on others. Explore detailed guidance for applying each approach below. ## Basic ~~ In this approach, background color is oriented to keep the overall user interface focused and clutter-free. The background color is held consistent throughout the page and content section separation is accomplished primarily through the use of typography and spacing (via margins and padding). - **background**  - The default background color when no other background color is specified. - **background-contrast**  - Used to indicate secondary content. Refer to the background palette(/foundation/color#background-palette) for definition of each background color namespace and value. ### Basic layout with cards ~~ `background`  should be used for the application background as well as foreground elements, like Cards. The header, main content, and cards all use `background`  for the background color.      ### Basic layout with supporting content ~~ In this example, the header and main content use `background`  and the help text uses `background-contrast` . Usage of `background-contrast` and supplemental regions like this should be kept to a minimum.      ## Layered ~~ The layered approach to background color is oriented towards more complex content situations. In addition to typography and spacing, background colors are used to create separate content sections and promote focus on primary content. In this approach, the overall background color should be `background-back` and specific content sections which should be the primary focus of attention should use `background-front`. From an information architecture, as well as from a component layout perspective, `background-back` should not be used within a context which already has `background-front`. For instance, a primary navigation header should not use `background-front` above a main content section that uses `background-back`. - **background-back**  - The overall background color. - **background-front**  - The background color for content which should be the primary focus. - **background-contrast**  - Could be used to indicate a secondary content area within a large content section. Refer to the background palette(/foundation/color#background-palette) for definition of each background color namespace and value. ## Examples of layered layout ~~ For example, a page with a header(/components/header), summary content, and a grid of cards(/components/card) would use `background-front` for each card and `background-back` for everything else. For a multi-column page layout, `background-front` could be used to distinguish the column which should be the primary focus. ### With fixed header ~~ When the header is fixed, use `background-front`  for the header since it is layered in front of the main content.      ### Header scrolls with content ~~ When the header scrolls with the main content, use `background-back`  for the header since it is flush with the main content. An example of this design would be the Design System website.      "},{"name":"Color Pairing","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/color-pairing.mdx","content":"       ## Color pairing explained ~~ Pair colors correctly to ensure your design has sufficient contrast ratios and will remain so with color updates. - Standard background colors can be paired with any standard icon/text colors. - Any `strong` variant of a standard background should be paired with the `onStrong` variant of text/icon. - Specific-role background colors should be paired with their associated \"onRole\" icon/text color. For example, `background-critical` should be paired with `text-onCritical`. - Any \"strong\" variant of a specific-role background should be paired with the \"onRoleStrong\" variant of text/icon. The general rule is to use the most specific color for the use-case. If a particular background color has a particular text/icon pair, use it. ## Accessible standard color pairings ~~ Combine background and text and icon colors with confidence as all contrast ratios have been tested.  **Work with**   ## Strong background and onStrong colors ~~ Strong backgrounds have higher emphasis and are always paired with onStrong colors. This ensures that content sitting on strong backgrounds, for example, text and icons, will always be visible and accessible, even if colors are updated at a future date.       ## Specialty color pairings ~~ Some colors have pairings with added granular definition. For example, `color.background.primary.strong` is paired with `color.text.onPrimaryStrong`. Background colors that are not part of the standard set documented above will have a specific pairing with text and/or icon colors, to allow more fine-grained control of values at the token level. This means that if colors are updated at a future date, the design system will ensure that supported color pairings meet accessibility requirements.      Refer to this table below for examples of background colors paired with \"on\" colors.  | Example                                                                                                                                                                                              | Background color                         | Pairs with                                                             | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | ---------------------------------------------------------------------- | | Aa                             | color.background.critical                | color.text.onCritical, color.text.onCritical.strong                    | | Aa                               | color.background.warning                 | color.text.onWarning, color.text.onWarning.strong                      | | Aa                                         | color.background.ok                      | color.text.onWarning, color.text.onWarning.strong                      | | Aa                                     | color.background.info                    | color.text.onInfo, color.text.onInfo.strong                            | | Aa                               | color.background.unknown                 | color.text.onUnknown, color.text.onUnknown.strong                      | | Aa             | color.background.primary.strong          | color.text.onPrimaryStrong, color.icon.onPrimaryStrong                 | | Aa            | color.background.primary.xstrong         | color.text.onPrimaryStrong, color.icon.onPrimaryStrong                 |         | Aa              | color.background.selected.primary        | color.text.onSelectedPrimary, color.icon.onSelectedPrimary             | | Aa   | color.background.selected.primary.strong | color.text.onSelectedPrimaryStrong, color.icon.onSelectedPrimaryStrong | export       return (        ); };"},{"name":"Color","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/color.mdx","content":"   ## Applying color ~~ HPE colors are stored in the form of design tokens. Rather than applying RGB or hex values, use semantic colors (otherwise called semantic tokens(/design-tokens/overview#semantic-tokens)). Semantic color names describe when and where to apply them. Applying semantic colors as intended ensures your design: - Is aligned with the current theme and visual direction. - Is accessible. - Enables theme mode switching (light and dark). - Improves maintenance (when themes are updated, designs are synchronised with token updates. See design tokens overview(/design-tokens/overview).) The HPE Design System color palette and guidance differ from Brand Central(https://brandcentral.hpe.com/brand-central/content/color). In partnership with HPE Brand, the HPE Design System extends brand colors to serve digital product use cases. Prioritize the HPE Design System palette when selecting colors for app or web experiences. ## Color palettes ~~ Color expresses brand, guides interaction, and supports accessibility. It shapes interface elements, typographic emphasis, data visualization clarity, and adaptation between light and dark modes. Applied intentionally, it reinforces inclusive design across HPE applications and web experiences. ### Backgrounds ~~ Background colors establish depth, hierarchy, and cognitive grouping. Products typically begin with `color.background.back` as the base, then layer surfaces using `color.background.front` and `color.background.floating` to convey elevation. Use contrast background tokens to separate dense regions, preferring contrast backgrounds over borders in tight layouts to reduce visual noise. For more direction on how to use background colors, see background colors guidance(/foundation/background-colors-guidance).  #### Overlay ~~ The overlay color dims inactive content to direct attention to an active layer. Apply it behind center layer, side drawer layer, or dialog surfaces to reduce cognitive load using `color.background.screenOverlay`. ### Borders ~~ Border colors delineate areas only when spacing or background contrast are insufficient. Use `color.border.default` for neutral boundaries and dividers, and omit borders where existing spacing or contrast already provides clear separation.  ### Text ~~ Text colors help create hierarchy and ensure readability. Use `color.text.default` for body copy and `color.text.heading` for headings. `color.text.strong` can be used to emphasize key figures or other important text. To de-emphasize content and create a clear visual hierarchy, apply `color.text.weak` to secondary information.  ### Icon ~~ Icon colors follow text hierarchy and must remain legible at small sizes. Match an icon's color emphasis with its accompanying text.  ### Decorative ~~ Decorative colors provide brand and accent without conveying status. Limit secondary decorative hues to illustration and non‑interactive ornamentation. Avoid substituting decorative colors for status; use semantic text or foreground status design tokens instead.  ### Data visualization ~~ Data visualization colors differentiate categories without overwhelming perception. This palette has been crafted to ensure each series is visually distinct and color blind friendly. Apply data visualization colors according to the following guidelines: - Begin categorical series with the first design token and proceed sequentially. - Consider consolidating series with limited data into an \"other\" category represented by a single data visualization color; provide the ability to drill-down to view detail. - When using HPE Design System DataChart, series colors are applied automatically in sequence to support consistent interpretation.  ### Foreground ~~ Foreground colors fill graphic and quantitative regions (meters, progress, indicators) with semantic meaning.  ### Status colors ~~ Status colors reinforce state and feedback (critical, warning, ok, informational, unknown) across surfaces, text and icons. - Use status color only when conveying semantic meaning; avoid decorative substitution. - Pair status color with an icon or concise label for rapid scanning and to meet accessibility.  ### Focus ~~ Focus provides clear visual cues for keyboard and assistive technology navigation by highlighting the currently active element, reinforcing accessible interaction. ## Accessibility ~~ Color accessibility ensures all users can perceive and understand content regardless of visual ability. The HPE Design System prioritizes accessibility compliance through semantic color tokens. ### Color pairing ~~ Pair text and icon colors appropriately with background colors to maintain accessibility. Strong background colors require `onStrong` text and icon tokens. For detailed color pairing guidance, see color pairing(/foundation/color-pairing). ### Color as information ~~ Never rely solely on color to convey information. Always provide additional visual cues such as: - Text labels - Icons - Patterns or textures - Underlines for links "},{"name":"Component Sizes","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/component-sizes.mdx","content":"T-shirt sizes (design tokens) define component dimensions through the `size` property. Common options include `small`, `medium`, and `large`, with extended  ranges like `xxsmall` or `3xlarge` available for certain components. All  components share a common dimension lineage based on  element design tokens(/design-tokens/element), ensuring standardized sizing  for core UI building blocks and consistent alignment across layouts. Examples supporting t-shirt sizes include: - Typography - Heading(/foundation/typography#heading), Paragraph(/foundation/typography#paragraph), Text(/foundation/typography#text) - Controls - Anchor(/components/anchor), Button(/components/button), Pagination(/components/pagination) - Visualizations - Avatar(/components/avatar), Spinner(/components/spinner), Tag(/components/tag) ## Default sizes ~~ Components exposing a `size` property default to `medium` when unspecified. In the button example below, “Default” and size=”medium” produce the equivalent rendering:  Omit the `size` property when `medium` is appropriate. Omission reduces verbosity  without altering appearance. "},{"name":"Content Container Sizes","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/content-container-sizes.mdx","content":"  Content container sizes are a subset of the scale system(/foundation/scale-system) used to define content regions, containers, and establish page layout structure. Container design tokens(/design-tokens/layout-and-spacing#containers) specify the minimum, maximum, or fixed height and width of content areas. They are commonly used to define the heights and widths of Boxes(/components/box), columns and rows for Grid(/components/grid) layouts, widths for layers(/components/layer), modals(/components/layer/center-layer), cards(/components/card), and many more use cases. Additionally, design tokens specify border widths(#border-widths) and radii(#radius-sizes) for content areas. ## Container sizes ~~ Content containers may be implemented as invisible bounding boxes defining layout regions or visible surfaces on which content may be displayed. In either scenario, t-shirt sizes specify container dimensions used when defining container-driven layouts(/templates/content-layouts#container-driven-layouts). For more flexibility, t-shirt sizes can define minimum and maximum ranges so  containers adjust to available screen space(/components/grid#flexible-columns).  To avoid restricting content unnecessarily, consider using  content-driven layouts(/templates/content-layouts#content-driven-layouts) instead.       ## Border widths ~~       ## Radius sizes ~~       "},{"name":"Date And Time","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/date-and-time.mdx","content":"   export  Date and time can appear in a wide variety of contexts: - Data tables - Inline with paragraph text - Name value lists - Notifications - Log files Depending on the context, date and time may be presented as: | Format                          | Purpose                                                                         | Examples                                                                                                                                                               | Notes                                                                                                             | | ------------------------------- | ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | Absolute time(#absolute-time) | To provide the precise date and/or time of an event.                            | {Intl.DateTimeFormat('en-US', { dateStyle: 'long' }).format(date)}; {Intl.DateTimeFormat('en-US', { month: '2-digit', day: '2-digit', year: 'numeric' }).format(date)} | The granularity and formatting depends on the context. See absolute time guidance(#absolute-time). | | Relative time(#relative-time) | To display how long ago something occurred or in how long something will occur. | in 5 days, 3 days ago                                                                                                                                                  | --                                                                                                                | Timestamps should always be stored in UTC, the universal standard. These UTC timestamps will then get converted to local time, if necessary, by the UI for display. ## Absolute time ~~ Absolute time stamps display the precise date and time an action has occurred or will occur. May be presented as: - Date - Date and time   - Including seconds (and fractional seconds)   - Including timezone In most cases, absolute time should be presented according to the user's locale(#locale-formatting) and timezone(#timezones), indicating the timezone in the output. Absolute time can be presented in a variety of formats:  | Formats                        | Example                                                                                              | When to use                                                                                              | Code snippet (where date is a Javascript Date object)                                                             | | ------------------------------ | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | Full written format            | {Intl.DateTimeFormat(undefined, { dateStyle: 'full' }).format(date)}                                 | When space is available and displaying the day of week is beneficial to the user.                        | `Intl.DateTimeFormat(undefined, { dateStyle: 'full' }).format(date)`                                 | | Long written format            | {Intl.DateTimeFormat(undefined, { dateStyle: 'long' }).format(date)}                                 | When space is available.                                                                                 | `Intl.DateTimeFormat(undefined, { dateStyle: 'long' }).format(date)`                                 | | Medium written format          | {Intl.DateTimeFormat(undefined, { dateStyle: 'medium' }).format(date)}                               | When space is limited.                                                                                   | `Intl.DateTimeFormat(undefined, { dateStyle: 'medium' }).format(date)`                               | | Numeric locale-specific format | {Intl.DateTimeFormat(undefined, { month: '2-digit', day: '2-digit', year: 'numeric' }).format(date)} | When the user needs to compare across dates, such as in a column or list. Otherwise, use written format. | `Intl.DateTimeFormat(undefined, { month: '2-digit', day: '2-digit', year: 'numeric' }).format(date)` | | ISO 8601 format                | {date.toISOString()}                                     | Log files; trigger times.                                                                                | `date.toISOString()`                                                                                 | Other than log files, date and time should be presented according to the user's locale(#locale-formatting) and timezone(#timezones). ### Locale formatting ~~ Applying the user experience principles of \"personalization\" and \"don't make me think,\" in most cases dates and times should be presented based on the user's locale as specified in their browser and system preferences. Date and time are formatted differently depending on the language and region. Some aspects that are locale-dependent include date and time ordering, separators, and 12-hour vs 24-hour clocks. There are various Javascript Date methods(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat) that can be leveraged to convert from UTC to the user's locale. Whenever possible, present date and time according to the user's locale. export  export  export  | Locale | Date                                                            | Time                                                          | | ------ | --------------------------------------------------------------- | ------------------------------------------------------------- | | en-US  | {Intl.DateTimeFormat('en-US', localeFormat).format(localeDate)} | {Intl.DateTimeFormat('en-US', timeFormat).format(localeDate)} | | en-AU  | {Intl.DateTimeFormat('en-AU', localeFormat).format(localeDate)} | {Intl.DateTimeFormat('en-AU', timeFormat).format(localeDate)} | | de     | {Intl.DateTimeFormat('de', localeFormat).format(localeDate)}    | {Intl.DateTimeFormat('de', timeFormat).format(localeDate)}    | ### Timezones ~~ In addition to formatting a date according to the user's locale, present time in the user's timezone and display the timezone alongside the time stamp for clarity. In instances when a user's timezone cannot be determined, output the date and time in UTC+0.                          ### ISO 8601 Formatting ~~ ISO 8601 is an internationally recognized standard for presenting date and time. It is presented as `YYYY-MM-DDTHH:mm:ss.sssZ`. For example, `2023-02-07T06:57:00.000Z`. In this format, `T` indiciates the start of the time stamp, and `Z` indiciates the time is in UTC. Some use cases include: - Log files - Trigger times Even though ISO 8601 is an internationalized standard, it is not the most friendly format for users. In most other cases, date and time formatting should be based on the user's locale(#locale-formatting) and timezone(#timezones). ## Relative time ~~ Relative time stamps display: 1. How recently an event has occurred. 1. How far in the future an event will occur. Relative time stamps remove the need for the user to perform mental calculations by presenting timestamps in written form like \"2 days ago\". When displaying relative time: - Adapt and show the appropriate unit of time. For example, after 60 minutes, display hours. - Unless required, displaying the time for anything less than a second and more than a week is generally not needed. - Zero values should not be included as this will cause issues with alignment. For example, do not show when something is at \"0 minutes\". - For older events, such as anything that happened more than a week ago, consider using absolute time(#absolute-time) instead. - Consider whether or not it's important for users to be able to see the absolute time as well. This could be placed within a tooltip or displayed on a detail page. | Description            | Display                          | Display when space is limited   | | ---------------------- | -------------------------------- | ------------------------------- | | Within the last minute | Just now; a minute ago           | now; a min ago                  | | 1 day ago              | yesterday                        | yesterday                       | | = 1 week ago          | Absolute time(#absolute-time)  | Absolute time(#absolute-time) | | In 1 day               | tomorrow                         | tomorrow                        | | = 1 week           | Absolute time(#absolute-time)  | Absolute time(#absolute-time) |                         ## Abbreviating date and time ~~ When space in the UI is limited, units of time, days of the week, and months can be abbreviated. Some contexts in which abbreviations may be needed are: - Within cells of a data table - At smaller breakpoints | Units of time  | Abbreviation | | -------------- | ------------ | | millisecond(s) | ms           | | second(s)      | sec          | | minute(s)      | min          | | hour(s)        | hr           | | day(s)         | day, days    | | week(s)        | wk           | | month(s)       | mo           | | year(s)        | yr           | To abbreviate days of the week or months, use the Javascript Intl.DateTimeFormat method(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat). The general convention for English is to use the first 3 letters of the day or month name.      ## Alignment ~~ By default, left-align dates and times. When presenting dates in a column, right-align relative times(#relative-time) to bring units of the same magnitude into alignment.      ## Zero-padding ~~ When a user needs to compare time stamps such as in a list or column, zero-padding ensures units are uniform and aligned for easy readability and comparison. When applicable, a leading zero should be included within both the date and time. Zero-padding is not needed when context contains only one time stamp, see notification example(#notification).                         ## Examples ~~ ### Notification ~~ When displaying future events such as upcoming updates, expiration dates, and ongoing processes: - Use the friendlier, more conversational relative time() phrasing, such as “in x days”. - Provide the date, exact time, and timezone alongside the relative time to remove any ambiguity.                         "},{"name":"Designer Guidance","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/designer-guidance.mdx","content":"## Getting started ~~ We're excited you're using the HPE Design System! Below are a set of resources that will help you get started using the HPE Design System components in your designs. If you don't find what you're looking for, please reach out in the #hpe-design-system channel on Slack(https://grommet.slack.com). ### Setting up your Figma account ~~ If you are new to Figma, the Figma Getting Started(https://help.figma.com/hc/en-us/categories/360002051613-Getting-Started) page is a good place to start. Create a Figma account(https://help.figma.com/hc/en-us/articles/360039811114-Create-a-Figma-account) with your HPE email address. Using your HPE email provides immediate access to all HPE Design System files. If you would prefer to access the HPE Design System library in a desktop app, you can download the Figma Desktop App(https://help.figma.com/hc/en-us/articles/360039823654-Download-the-Figma-Desktop-App#Download_the_Desktop_App) for MacOS or Windows. ### Joining the HPE Design System Figma team ~~ Once you have made a Figma account with your HPE email, you can request to join the HPE Design System team. You can do so by following these steps: 1. Log into Figma and look for an HPE icon in your left control bar. 2. Click on HPE. Here, you will see all HPE Figma teams. 3. Look for \"HPE Design System\" and click \"Request to join\". Once you have been added to this team, you will have access to all of the HPE Design System files. ### Before your start designing ~~ Familiarize yourself with the concepts and components the HPE Design System offers. Understanding use cases and guidelines for individual components will ensure your designs align with the HPE Design System. Need somewhere to start? Check out the guidelines for Color(/foundation/color), Typography(/foundation/typography), Components(/components), or Templates(/templates). ### HPE Design System Figma Library ~~ The HPE Design System Figma Library(https://www.figma.com/files/815326206297160627/project/334891093/Library-v2?fuid=1333807079138466234) is a library of assets for designing HPE applications. If you are having trouble accessing the files, you may need to join the HPE Design System Figma team(#joining-the-hpe-design-system-figma-team) first. "},{"name":"Developer Guidance","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/developer-guidance.mdx","content":"## Getting started ~~ We're excited you're using the HPE Design System! Below are a set of resources that will help you get your application set-up with Grommet and the HPE theme. If you don't find what you're looking for, please reach out in the #hpe-design-system channel on Slack(https://grommet.slack.com). ### Preferred environment ~~ The HPE Design System is primarily focused on user interfaces developed with ReactJS and Grommet. We encourage teams to use ReactJS and Grommet if possible because there are more resources, examples, and community help for this environment. Questions and feedback should be routed through the #hpe-design-system channel on Slack(https://grommet.slack.com). ### ReactJS and Grommet starter resources ~~ If you are new to ReactJS, the React Tutorial(https://reactjs.org/tutorial/tutorial.html) is a good place to start. If you are already familiar with ReactJS but are unfamiliar with Grommet, check out the Getting Started with Grommet(https://v2.grommet.io/starter) guide. ### Applying the HPE theme ~~ Once your project is set up with ReactJS and Grommet, make sure you have the latest grommet-theme-hpe(https://github.com/grommet/grommet-theme-hpe) theme via `npm`, `pnpm` or `yarn`. This will help ensure that your application is aligned with the HPE Design System colors, fonts, and default component styles. ### What if our team doesn't use ReactJS? ~~ For non-React projects, the design system may be consumed via HPE Design Tokens(/design-tokens). Design tokens encode design decisions such as color, typography, spacing, and motion in a consistent, reusable, and tech-agnostic format. To get started, see using design tokens in code(/design-tokens/using-design-tokens-in-code). Alongside design tokens, use the examples and patterns throughout this site as reference. If you have questions or would like some guidance on migrating to ReactJS, please reach out to the HPE Design System team on Slack in #hpe-design-system.(https://hpe.enterprise.slack.com/archives/C04LMJWQT) "},{"name":"Distinctive Brand Assets","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/distinctive-brand-assets.mdx","content":"    Refer to HPE Brand Central(https://brandcentral.hpe.com/brand-central/content/distinctive-brand-assets) for rules and guidance for when, where, and how to apply HPE's distinctive brand assets. Use this page to learn how you can implement brand assets with ease. ## HPE GreenLake badge ~~ HPE GreenLake will launch a new brand later this year, featuring a new logo, visual identity, messaging, and naming updates. Until the launch of the new brand, please do not make any changes to existing HPE GreenLake materials. The existing HPE GreenLake badge is retired and should not be added to any new material. Image files and usage rules can be found on Brand Central(https://brandcentral.hpe.com/brand-central/content/hpe-greenlake#hpe-greenlake). ## HPE green ~~ HPE Green, referred to as the `decorative-brand`  token in Design System resources, and all other colors are provided by the HPE theme and Figma. Visit Color(/foundation/color) to learn about color palettes and their use within HPE applications. ## HPE Graphik font ~~ HPE fonts are provided by the HPE theme and Figma. Visit typography(/foundation/typography) for more detail. {/*  ## Flexible ingredients ~~ ### Color and texture styles ~~ Gradient, datawave, and light/shadow assets can be consumed directly from the HPE theme. These assets may be seen commonly throughout marketing contexts and should be used more sparingly within platform. However, there are appropriate use cases such as or a page header for a service catalog or call to action cards(/components/card/call-to-action-card), where the incorporation of bolder, vibrant elements communicate \"unlocking value\" and can inspire and entice the user. See HPE theme backgrounds(https://github.com/grommet/grommet-theme-hpe/blob/master/src/js/themes/backgrounds.js) for a full list of background values.      ### Typography styles ~~ Texture or gradient in type can easily be implemented using Box(/components/box)'s `background` plus Heading(/foundation/typography#heading) or Text(/foundation/typography#text). For rules such as \"only place texture or gradient filled text on white backgrounds\" and other advice, please refer to HPE Brand Central(https://brandcentral.hpe.com/brand-central/content/distinctive-brand-assets).      ### Photography, film, and more ~~ Many more distinctive brand assets such as photography collections, film animations, and idents are all available on HPE Brand Central(https://brandcentral.hpe.com/brand-central/content/distinctive-brand-assets). The HPE Design System includes assets most commonly used in websites and web applications. Have an asset you would like to see added? Post your request to the #hpe-design-system channel on Grommet Slack(https://grommet.slack.com). */} "},{"name":"Human Centered","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/human-centered.mdx","content":"Human sensitivity to technology, as understood through research and a relentless pursuit of community engagement, allow the Design System to be inclusive, conversational, and adaptable. ## Inclusive ~~ Meeting WCAG accessibility standards, creating responsive experiences, and adhering to readability guidelines are just the beginning of understanding what it means to be inclusive. Community discussions that allow the Design System to thrive invites new ideas, innovation, and ongoing learning. The Design System seeks to embrace an ethic that honors human engagement in the digital experience, keeping in mind emotional and social implications of the experience. ## Attentive ~~ Being human-centered requires attention to the needs of others. We first listen to our customers, with curiosity while seeking understanding. Listening attentively is an act of humility and it is a part of our ethos that buildst the community. Being attentive is followed by action through thoughtful presentation of data, utilizing a task-based approach to craft experiences, and ensuring services and application core competencies. ## Conversational ~~ The HPE Design System elicits a conversation in two ways. It first enables people to craft experiences that engage in an interactive dialogue. The Design System allows for the design to express tone and give voice to an interaction. Each interaction elicits a positive or negative response that compiles into an entire experience for the user. Second, the Design System elicits conversation to continue its evolution, growth, maturity, and adaptability. It will not meet every need and solve every solution. However, it can bring about a conversation to safely allow people to be bold and accelerate what's next. "},{"name":"Icons","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/icons.mdx","content":"   {/* TODO replace with DS icon package when available */}  Icons can appear as stand-alone decorative elements or be embedded within components such as Button or Tabs to enhance usability and recognition. They provide quick visual cues that help users interpret actions and content at a glance. Icons should support recognition, not create ambiguity. Familiar, universal symbols (e.g., search, delete, close) can stand alone, while less common icons should be paired with a label to ensure clarity. Thoughtful, consistent use prevents overuse or misuse, avoiding the confusion caused by unclear or inconsistent symbolism. Icons in the HPE icon library are semantically named to indicate each icon’s intended usage. Every icon includes metadata to improve discovery and provide additional context about its purpose. - Use icons only when their meaning is clear and supports the context. - Pair abstract icons with text labels to aid comprehension. - If an icon always requires a label to be understood, use text alone. - Avoid using the same symbol to represent different meanings across products. - Keep icons visually consistent with the library’s size, and color standards. - Use decorative icons sparingly — they should support, not compete with, content. }   label=\"Open icon set in Figma\"   target=\"_blank\"   secondary   href=\"https://www.figma.com/design/Hio1n5z95fdxSxuS86dLqJ/HPE-Icons-V2-%E2%80%93-Production?node-id=0-1\"   rel=\"noreferrer noopener\"   alignSelf=\"start\" /> ## Developing with @hpe-design/icons-grommet ~~ Explore the HPE Icons Storybook(https://hpe-design-icons-grommet.netlify.app/) for interactive examples and implementation details. For guidance on installing and migrating to use the @hpe-design/icons-grommet icons in your application, refer to the migration documentation.  ## Icon sizes ~~ The default icon size is medium. Icons can be scaled using predefined size options to align with the typography scale(/foundation/typography), ensuring consistent vertical rhythm and proper inline alignment with text.      ## Icon color ~~ Standalone icon components use the default color token `icon-default`.\\ Decorative icons may also use `icon-strong` `icon-weak` `icon-disabled` or `icon-primary` to convey emphasis or state. Non-semantic icons, such as brand or third-party SVGs, should display their native colors. To preserve their original styling, apply the prop `color=\"plain\"`.      ## Status icons ~~ Status icons are reserved for drawing attention to information about system health.      ## Aligning with text ~~ When icons appear inline with text, set the `height` to match the text's size prop to ensure visual alignment.      ## Icons within components ~~ Icons are available for use inside other components such as Search fields(/components/search), Menus(https://design-system.hpe.design/components/menu?#with-custom-icon) and Buttons(https://design-system.hpe.design/components/button?#button-with-icon). When placed within a component, an icon will inherit styling, color, and scale properties from its parent component to maintain theme alignment.      ## Core icons ~~ The following common icons should be used as described in order to provide a consistent and clear experience for the user. ### Resource actions ~~ These icons represent actions that create, update, or delete saved resources.  ### UI actions ~~ These icons represent actions that move the user to a new view or context within the interface.  ### UI controls ~~ These icons represent actions that adjust or toggle the state of an individual component.  ### Info and help ~~ These icons support users by offering extra context, guidance, or help content.  ## Accessibility ~~ ### Screen reader ~~ Each icon includes an `aria-label` to support screen readers.\\ Use the `a11yTitle` prop to override or customize the default label when needed.\\ Icons used for decorative purposes only should have `aria-hidden` to prevent labels with no meaning from being read by screen readers. ### Color contrast ~~ Ensure icon colors maintain sufficient contrast against their background in accordance with WCAG guidelines(https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html). "},{"name":"Index","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/index.js","content":"         export default Foundation; "},{"name":"Our Brand","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/our-brand.mdx","content":"   Our logos are a powerful expression of our brand and who we are. The distinctive symbol, we call the \"Element,\" speaks to our focus on customers and their success, with a color which signals growth and opportunity, and an approachable word-mark which says we are welcoming to our partners. All usage of the Hewlett Packard Enterprise brand elements is subject to the requirements and restrictions outlined in the Terms of Use(https://www.hpe.com/us/en/about/legal/terms-of-use.html). For additional guidance and logo usage refer to Brand Central(https://brandcentral.hpe.com/home). ## Hewlett Packard Enterprise ~~ Hewlett Packard Enterprise, also known as HPE has a couple logo variations to help build your experience. Each variation should be used in the appropriate context. Being aware of different uses helps make your experience more compliant. ### HPE logo ~~ Use the HPE Logo when establishing the brand and building layouts with less dense content. Place the logo on the top left or bottom left depending on the layout; neither placement is necessarily preferred.                           ### HPE Element ~~ 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.           ## HPE Aruba Networks ~~ For additional information and guidance on HPE Aruba Networking view Brand Central(https://brandcentral.hpe.com/brand-central/content/hpe-logo-and-hpe-greenlake-badge#hpe-aruba-networking-wordmark). "},{"name":"Philosophy And Principles","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/philosophy-and-principles.mdx","content":"## Philosophy ~~ The HPE Design System contains an open-source library of elements consisting of working code, best practices, design resources, human-centered guidelines, and a vibrant community of contributors. It enables experiences to be crafted with uncompromising integrity. The Design System is built on 3 Pillars: - Human-centered design - A common design language - Collaboration and community ### Human-centered design ~~ We provide for the needs of people and their work. The HPE Design System is crafted upon user research and listening to customers first. We strive to create consistent and usable design patterns that will make HPE products and services a joy to use by customers, partners and internal HPE users. ### Common design language ~~ The HPE Design System provides a common language for designers, developers and stakeholders. This allows everyone to speak the same design language without having to translate from one language to another. This also allows for more precise specification of UX requirements. A common set of UX/UI components for designers and developers helps to make implementation easier and more efficient. These pre-built components provide UX consistency, localizability and accessibility. ### Collaboration and community ~~ Collaborating with you and participating in ongoing conversation is how we can build and evolve the design system. Your voice is critical to cultivating a relationship that identifies issues and contributes to the growth and vitality of the community. ## Principles ~~ Our principles provide clear criteria for the concepts, craftsmanship and creativity our brand demands and which our clients deserve. They are for designers and non-designers alike, anyone authoring or authorizing any form of design on behalf of HPE. Designs created using these principles will be innovative and adventurous, purposeful and useful, and composable yet integrated. ### Focus on the experience ~~ Understanding customer needs is critical to creating great user experiences (UX). - Consider the use cases - Simplify the end-to-end experience, making it elegant, intuitive and easy - Express creativity by empathizing with the user ### Simplify ~~ Be as simple as possible. Focus on the tasks that users need to do with intentionality and mindfulness. - Reduce visual and cognitive overload - Understand “why” things are needed in your design - Design for the mainstream use cases, yet provide ways to accomplish less frequent tasks ### Be intuitive ~~ Create designs that are easy to understand and use. - Make use of affordance and common user interface paradigms - Use consistent patterns and terminology within your design and across designs - Create self-documenting designs to minimize the need to refer to online help and other user documents ### Lead people to success ~~ Present paths that guide people to accomplish the task or goal they need to achieve. It is the right thing to do and it results in happy customers. - Show only choices and fields that apply to the current context - Organize choices and fields with most common/reasonable first - Reveal additional fields only when they apply - Provide appropriate safeguards to protect the customer and HPE from mistakes or unintentional actions "},{"name":"Scale System","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/scale-system.mdx","content":" The scale establishes how UI elements proportionally relate to one another, ensuring  composability and harmony within the layout. It defines a base unit and scale ratio from  which all steps of the scale are derived. Subsets of the scale are used to define spacing  sizes and content container sizes. Additionally, the scale system provides ready-to-use functionality that automatically  adapts UIs based on viewport width, device type, and user preferences. ## Principles ~~ The scale system has been built from the following principles: - **Proportional:** Each step in the scale follows a consistent ratio, ensuring all   steps are proportional to one another. - **Composable:** Each step in the scale is divisible into halves, thirds, quarters, and so on.   Conversely, each step may be assembled from smaller increments. - **Flexible:** Subsets of the scale accommodate a wide range of use cases, from small spacing needs   to large containers and layouts. - **Harmonious:** The scale promotes visual harmony and balance across UI elements by ensuring   consistent sizing relationships. ## Foundational scale ~~ The scale system is built upon two interconnected scales: - **Primary scale**: Based on a 24px base unit, where each step is achieved by doubling or halving the previous value. - **Supplementary scale**: Based on a 16px base unit, following the same doubling and halving principle. The resulting scale steps:  1, 2, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64, 96, 128, 192, 256, 384, 512, 768, 1024, 1536. Design tokens for spacing(/design-tokens/layout-and-spacing#spacing), containers(/design-tokens/layout-and-spacing#containers),  border radius(/design-tokens/layout-and-spacing#radius), and border width(/design-tokens/layout-and-spacing#border-width) are defined as subsets of  this foundational scale. ## Composability ~~ Each step in the scale is divisible into halves, thirds, or quarters. Conversely, each step can be  composed by combining smaller steps. This ensures that when you add or subtract spacing or  container t-shirt sizes(/foundation/tshirt-sizing), the result is always another valid size on  the scale.    {/* TODO: Determine appropriate colors and/or how to represent proper text. Or, do we treat this as an illustration only? */}      Figure 1: Composable scale steps visualization  "},{"name":"Spacing","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/spacing.mdx","content":"    Spacing sizes are a subset of the scale system(/foundation/scale-system), supporting proximity principles to shape relationships between content and establish hierarchy on a page. These principles are applied through spacing design tokens(/design-tokens/layout-and-spacing#spacing), which define the padding within, margin around, and gap between content. Effective spacing guides a user's eye through the interface, making it easier to understand how elements relate to one another. The HPE Design System minimizes use of borders to separate content. Instead spacing, typography, and background color are combined to create visual hierarchy. ## Spacing scale ~~ Use spacing to: - Create separation between content containers(/foundation/content-container-sizes) (gaps). - Set space between a container's boundary and its content (padding). - Define spacing within subsections of content (gap).       ## Spacing best practices ~~                            "},{"name":"Tshirt Sizing","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/tshirt-sizing.mdx","content":"   ## What is t-shirt sizing? ~~ T-shirt sizing uses semantic names (a.k.a. design tokens) which map familiar clothing sizes (`small`, `medium`, `large`, etc.) to specific pixel values for sizing and spacing. T-shirt sizes apply to: - Spacing(/foundation/spacing) (padding, margin, gap) - Content containers(/foundation/content-container-sizes) (width, height, border, radius) - Components(/foundation/component-sizes) (size property) Use t-shirt sizes rather than hard pixel values. If a new value is needed, report it  so that it may be evaluated and added as a design token if appropriate. ## Benefits ~~ T-shirt sizes promote consistency, systematic UI delivery, and ensure harmony among  layout elements. Hardcoded and arbitrary pixel values should be avoided, as they are  inflexible and fail to realize the benefits provided by t-shirt sizes, including: - Establish shared vocabulary across designers, developers, and delivery teams. - Accelerate layout specification through reuse of predefined values. - Ensure UIs are composable using common, shared size definitions. - Facilitate responsive design. - Enable density modes and expanded user preferences. - Promote consistency, maintainability, and scalability through systematic reuse. ## Responsiveness ~~ Layouts should be designed with responsiveness in mind to meet a user wherever they are &mdash; whether on a desktop, tablet, or mobile device. The values of semantic spacing and radius design tokens step down in size at the `small` breakpoint(/design-tokens/global#breakpoint). This retains appropriate proportions between shape, spacing, and content as the screen size decreases. When utilizing the CSS files, a media query is included in the `dimension.small.css` file to adjust the token values at the `small` breakpoint. To further refine layouts for different screen sizes, various breakpoints(/design-tokens/global#breakpoint) can be used to instruct logic for layout adjustments."},{"name":"Typography","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/typography.mdx","content":"      {/* TODO replace with DS icon package when available */}  export    return (            {children}        ); }; Typography is about more than words. It is an integral part of brand personality and design. When making a statement, the visual language should be clear, recognizable, and easy to understand. For specific design token values and implementation details, see the Typography system(/design-tokens/typography-system). ## HPE Graphik styles ~~ The weights and styles shown are part of the HPE Design System theme. HPE Graphik comes in a variety of weights. For digital experiences we use Light, Regular, Medium, Semibold and Bold weights at a variety of scales to compliment the content in a given design. ## Heading ~~      ### Best practices for headings ~~ For accessibility, ensure each page follows proper HTML structure by applying semantically correct heading levels(https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Heading_Elements#Usage_notes) and using the appropriate heading element for every section. Heading levels create a scaffold of a web page's content structure by defining the main page title, page sections, and subsections of those sections. Correctly implementing heading levels: - establishes a more scannable visual hierarchy - creates a clear HTML structure which is critical for use by assistive technologies If heading levels are not implemented in the correct hierarchy, users of screen readers and other assistive technologies will have a more effortful and difficult experience using the application. Headings beyond level 3 are rarely needed and often signal overly dense content. Before introducing levels 4–6, review whether the information can be simplified or reorganized into clearer sections.                {`Page title Card title Section title Another card title`}                       {`Page title Card title Section title Another card title`}          ### Styling exceptions ~~ Some components may require visual consistency regardless of heading level. For example, card titles in dashboard layouts often need to share the same text size even if their semantic levels differ. In these cases, keep the correct semantic heading level, but apply the appropriate design token to style the text(/design-tokens/typography-system#text). - For Card specific guidance, see card titles(/components/card#card-titles) documentation. - For Layer specific guidance, see layer titles(/components/layer#layer-titles) documentation. ### Heading levels ~~ {/* Future enhancement: Add syntax examples for non-Grommet implementations */} Use `level={1}` for the single `` on the page. Follow with `level={2}` for main sections and `level={3}` for subsections. See the example below for a recommended structure. Below is an example showing proper heading levels for a page with three topics, each with two subtopics.  ## Paragraph ~~ Paragraphs represent blocks of flowing text and are styled using Text design tokens(/design-tokens/typography-system#text) for font size, weight, and line height. Paragraphs differ from standard text by providing a maximum width limiting line length for optimal readability(https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-visual-presentation.html). Implementations should reference the `maxWidth` associated with each corresponding Text t-shirt size.      ## Text ~~      ### Text best practices ~~ Use the t-shirt size `maxWidth` design token on paragraphs to limit the width of text to ensure readability. While each text t-shirt sizes comes with a default font weight, the emphasis of text can be adjusted to suit the context by using the fontWeight(/design-tokens/global#fontweight) design tokens. ## Accessibility ~~ Typography desgin tokens(/design-tokens/typography-system) use `rem` units to scale fonts according to a user's browser settings. ## Font delivery ~~ In most cases, teams should point to the web-hosted version of the HPE Graphik fonts to ensure users always have the latest version. For Grommet-based teams, these CDN URLs are already included in grommet-theme-hpe. For non-Grommet teams, the appropriate CDN URLs and font-face definitions can be found in grommet-theme-hpe(https://github.com/grommet/grommet-theme-hpe/blob/master/src/js/themes/hpe.js) by searching for `@font-face`. ### Fonts for offline usage ~~ In rare cases where a product needs to reference the HPE Graphik fonts but users don't have internet access from their browser or maybe a designer needs the fonts locally, you can download the fonts for local use. HPE Graphik fonts can be downloaded from Brand Central in OTF/Vector and Web(https://brandcentral.hpe.com/brand-central/content/typography) formats. "},{"name":"Voice And Tone","parent":"foundation","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/foundation/voice-and-tone.mdx","content":"  The HPE Design System crafts words into content that cultivates an exceptional user experience. {/* The above sentence will be the leading line and moved to the Voice and Tone card in Foundations once approved */} The user experience is built upon our content. Every word we write is a carefully-considered concept that voices our values: - **Open**: We foster inclusive experiences that are personal, accessible, and transparent. - **Courageous**: We empower users with decisive and experienced guidance. - **Inspired**: We share our drive of 'yes we can' with users. We exercise empathy in our voice through situational tones that speak to each context, audience, and subject matter. We can _be a force for good_ by creating content that is: - Active - Positive - Objective - Fact-based - Plain English Refer to the guidance for HPE's Voice(https://brandcentral.hpe.com/brand-central/content/voice) for more information. ## Best practices ~~ The following are some high-level guidelines for  how a task is accomplished. Content supplements design. It communicates the goal of the user experience; why a task should be accomplished. We can create meaningful user experiences by writing clarity into our content; what we say and how we say it. Clarity simplifies complex ideas and connects one idea to the next to bridge the gap between user and application, task and goal. We can write clear content with a few simple qualities: ### Approachable ~~ Write with clear language to communicate clear ideas. Write to users in plain language, grounded in positive ability and action. Plain language requires less cognitive effort from users, improving time to action. Write at a United States grade 7 reading level to create straightforward, succinct, and consistent content. Use the Hemingway App(https://hemingwayapp.com/) to check the readability of content. Identify and communicate key points by separating and refining ideas to their essence. Words can often be reordered and refined to create simple and neat sentences. Read your message aloud to hear if it sounds like natural conversation. Content that sounds natural is easier to read and understand. ### Objective ~~ Anchor content in fact and objectivity, free of bias and judgement. Content based in fact fosters clarity and reliability. Content based in opinion introduces ambiguity. Consider the connotations of content. Words like **_Error_** can unintentionally suggest that the user is at fault or that their actions are being judged. However, an exception to this guidance applies when communicating with screen reader users—using **_Error_** in this context helps clearly signal that an issue must be resolved before continuing.  These messages begin with \"Error,\" to ensure screen readers announce the severity upfront, helping screen reader users quickly understand that corrective action is needed. Consider content from the user's perspective and goals, not what the UI can do. ### Format ~~ Write content that complements its element in the user interface. Elements like headers and interactive objects require concise language that communicates a single point. Body content provides room to elaborate but should still be succinct. ### Position ~~ Establish context with language that positions the user in the application: where they are and where they are going. Conversational language in macro settings, such as a dashboard that provides a broad set of interactions, can communicate big-picture goals. Definitive, action-oriented language in micro settings, such as a step in a workflow, can communicate the immediate task. ### Flow ~~ Write clear paths to goals and resolutions. Organize content so that one idea flows into the next and builds upon itself, enabling users to quickly make informed decisions. ## Conversational American English ~~ Variations of English are used throughout the world. However, to maintain consistency in HPE's voice, the messaging standard is to use conversational American English. Below are common usage and spelling differences between American, Indian, and British English and suggested resolutions for where differences arise. ### British English ~~ When there is a difference between American and British spelling, use the American spelling. Many British words are spelled ending in \"our\" such as \"colour\". Use the American \"or\" variant instead: color. Many British words are spelled ending in \"yse\" (analyse) or \"ise\" (realise). Use the American \"yze\"/\"ize\" variants instead: analyze/realize. Additional common differences: | British   | American  | | --------- | --------- | | Licence   | License   | | Cancelled | Canceled  | | Centre    | Center    | | Catalogue | Catalog   | | Behaviour | Behavior  | | Favourite | Favorite  | | Grey      | Gray      | | Chips     | Fries 😊  | | Biscuit   | Cookie 😊 | When using a spelling/grammar checker, set your locale to provide American English suggestions. ### Indian English ~~ This is a collection of common words or phrases used in India, that are not used in American English: | If you find yourself using this… | Example                                                                                | Use this instead                                                                                                                                                      | Why?                                                           | | -------------------------------- | -------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | Sorted                           | _The feature is not sorted._                                                           | Use either \"elaborated\", \"thought through\", \"analyzed\", \"planned\".                                                                                                    | Confusing. \"Sorted\" implies sorting in the computer sense.     | | Thus / Hence                     | _…, thus you must factory reset._                                                      | Use \"therefore\".                                                                                                                                                      | Uncommon or too formal.                                        | | Do the needful                   | _The server is down. Do the needful._                                                  | This is similar to \"do what is necessary\" or \"do whatever it takes\", but neither should be used in our messaging. Instead, be specific about what the user should do. | Never used. We should always be specific.                      | | We will revert back              | I send an email saying \"do it like this\" and you reply, _Thanks, we will revert back._ | _We will get back to you._                                                                                                                                            | \"Revert back\" implies going back to a previous revision.       | | Strong all the more              | _makes the case strong all the more._                                                  | _makes the case stronger._                                                                                                                                            | Never used.                                                    | | I have a doubt                   | _I have a doubt about that._                                                           | _I have a question_                                                                                                                                                   | \"I have a doubt about that\" implies you think it is incorrect. | ## Point of view ~~ Point of view is the perspective from which the message is written. First person perspective uses words like: I, me, us, we, our, etc. Second person uses any form of the word \"you\" which has the effect of addressing the reader. Third person directs the reader to things that are neither the writer or the reader. Examples: - _We noticed the server is malfunctioning._ (1st person-ish) - _Your server is malfunctioning._ (2nd person-ish) - _The server is malfunctioning._ (3rd person - no focus on the writer or the reader) ## Referring to support ~~ - Do not tell the user to contact their administrator. The user is likely the administrator. - Do not tell the user to contact HPE. A 3rd party may be providing support to the user. - Use something like: _Contact your authorized support representative._ - Do not overuse this phrase. If the resolution to a problem is clear, just give the resolution and do not add that the user should contact support. - Contacting support costs everyone time and money, so do not turn every issue into a potential support issue. It makes our product seem unnecessarily fragile and can result in unnecessary support calls. - Do use this phrase for internal errors where there's nothing else the user can do (i.e. when it is the only resolution). ## Scale ~~ Consider singular and plural use cases and craft messages for each. If a sentence contains a list, do not allow the length of the list to be unbounded. Instead, consider an approach where three items are shown and the remaining items are grouped: _The following policies have not been implemented: Policy A, Policy B, Policy C, and 5 others._ ## Quoting ~~ In messaging that contains user-specified content, use double-quotes around this content if it is not rendered as a hyperlink. If user-content is rendered as a hyperlink, the hyperlink styling is sufficient to offset the content from other text in the message. Why is this important? User-entered names can contain spaces, and if they are not quoted or rendered as hyperlinks, they can hinder comprehension of a message. Here is a correct example: _the uplink set \"{0}\" has a problem_. Compare this to an incorrect example: _the uplink set {0} has a problem_. If the uplink set is named \"deleted\", this will read as _the uplink set deleted has a problem_. ## Guidelines ~~ These concrete rules structure our communications. ## Capitalization ~~ There are five types of capitalization. 1. Sentence case, where the first letter is capitalized and subsequent words begin with lowercase letters, with some exceptions, such as proper nouns.    (example: Storage volume) 2. Title case, where most words are capitalized except for \"connector\" words such as \"the,\" \"an,\" \"or,\" etc.    (example: \"The Benefits of Cloud Storage Explained\") 3. PascalCase, where there are capital letters inside the word, almost always for branding purposes.    (example: GreenLake) 4. All lowercase, where every single word is lowercase    (example: \"lowercase exudes an approachable and casual vibe\") 5. All caps, where every letter is capitalized    (example: ALL LETTERS ARE CAPITALIZED) At HPE, almost all text should be written in sentence case. Never begin a sentence or phrase with a lowercase letter because it is too casual for our brand. Do not write in all caps because it is equated with yelling and increases stress. Sentence case should be applied on: - Attribute labels - Column headings - Legends - Tabs - Menus - Paragraphs of text - Tips - Notifications - Help - Page titles - Dialog titles - Section and subsections/subheadings - Buttons, except for those ending in the following short prepositions: at, by, for, in, of, off, on, out, to, up   - Correct: Sign Up   - Incorrect: Sign up Title case should only be applied on: - The title of an event, program, or website and for all proper nouns. HPE brand and product names are proper nouns. Fight the urge to elevate normal nouns to proper noun status. For example, if you are in a \"data sources\" page and need to say something about data sources, do not capitalize it. Unless it is a true proper noun, leave it uncapitalized when following sentence capitalization rules. When writing instructions, you can choose to refer generally to the action that should be taken or to the button or page. When you refer generally to an action, use lowercase. When you refer to a specific button, page or other element, follow the case of the element. Example of when you can refer to action in a general manner: To create a data fabric you must first anchorcreate a new clusteranchor. vs. Example when you refer to a page or button: First, go to the \"anchorCreate a New Clusteranchor\" page to create a data fabric. ## Acronyms and initialisms ~~ Acronyms and initialisms can be problematic and should be used with care. Because they are shortcuts communicating a concept in a visually shortened form, they tend to become distinct languages for a limited set of \"insiders.\" However, for those who are less fluent or use the language infrequently, acronyms and initialisms are actually detrimental. Acronyms increase the cognitive load on the user, forcing them to \"decode\" the message before comprehension, and tend to be exclusionary rather than inclusive. If an acronym or initialism is needed, define it the first time it is used. Additionally, only use the acronym if it is used multiple times in the message. - 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._ ## Branding ~~ To aid in comprehension, do not use full brand/product names in messaging. Refer to these with shortened names. For example, \"_HPE GreenLake Lighthouse_\" is a mouthful and if needed several times in a sentence, set context and consider using a simpler \"_Lighthouse_\" the second, third, Nth time. ## Language dos and don'ts ~~ **Do this:** - Use words like \"a\", \"an\", \"the\" so we don't sound like a robot. - Add punctuation to the end of each sentence. - Use correct punctuation within a sentence. - Use contractions to emphasize a conversational tone.   - For example, 'you are' can be shortened to 'you're', 'we will' can be shortened to 'we'll', and 'is not' can be shortened to 'isn't'. - Adjectives typically come before nouns.   - Incorrect: _the operation specified is…_   - Correct: _the specified operation is…_ - Adjectives in English appear in a specific order. If this order is violated, the sentence will seem odd.   - From the book *The Elements of Eloquence*: ...adjectives in English absolutely have to be in this order: opinion-size-age-shape-color-origin-material-purpose Noun. So you can have a lovely little old rectangular green French silver whittling knife. But if you mess with that word order in the slightest you’ll sound like a maniac. It’s an odd thing that every English speaker uses that list, but almost none of us could write it out.   - There's a slightly different order listed in the Cambridge Dictionary.   - Therefore: _two failing SATA SSD drives_ and not _SSD SATA failing two drives_ **Don't do this:** - Avoid possessives (e.g. _the server hardware's power is off_). - Eliminate run-on sentences. - Don't overuse the word \"please\".  While \"please\" is allowed, starting every action phrase with the word \"please\" is not appropriate.  In general, we should be limiting the use of \"please\". - When the subject of a sentence is a specific resource, do not use that resource’s name as an adjective describing a resource type.  Instead, use the type as an adjective describing the resource:   - Incorrect: _the ABC uplink set has…_   - Correct: _the uplink set \"ABC\" has…_ - It is not necessary to tell the user to _retry the operation_ in most cases.  For example, if the user has entered incorrect or illegal values, we only need to tell them to specify correct values and do not also need to tell them to retry the operation.  The retry is intuitive and obvious in these cases. - Never tell the user to retry after _some time_.  Be more specific.   - E.g. \"_after 3 minutes_\" or \"_after the refresh has completed.\"_ - Don't tell the user to _try_ or _attempt_ things. It does not convey confidence. Instead, tell them to do things.   - Incorrect: _Try resetting the interconnect._   - Correct: _Reset the interconnect._ - Don't say _bad request_. This is blaming the user.  Just explain what is wrong. - Do not use internal terminology in external messaging. - Do not refer to \"the\" or \"your\" administrator in messaging.  More often than not, the user reading the message is the administrator. Be more specific. - When making parenthetical comments…   - Don’t add spaces inside the parentheses: _this is bad ( yes it is )._   - Do add spaces outside the parentheses: _this is bad(yes it is)._ The exception would be things like “server(s)”. - Avoid incorrect use of the word \"input\".   - Incorrect: _Specify a valid certificate as input._   - Correct: _Specify a valid certificate._   - Incorrect: _One of the input parameters is null._   - Correct: _One of the parameters is null._ or _One of the specified parameters is null._ or _The \"name\" parameter is null._ ## Other common problems and how to address them ~~ The following are commonly misspelled/mis-capitalized terms: - The following must be spelled/capitalized as shown:   - 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) (either that, or be explicit and say X-API-Version) - \"Log in\" is a verb (e.g. \"Log in to the server\"). - \"Login\" is a noun or adjective (e.g. \"The login token has expired\"). - Use the word \"and\" instead of an ampersand \"&\". - Filesystem is one word. - Use \"host name\" when referring to the name of a host. - Use \"hostname\" when referring to the Unix command. The following table contains a set of common mistakes found in messaging, along with suggested corrections: | Don't                                                                  | Do                                                                      | Notes                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          | | ---------------------------------------------------------------------- | ----------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | app                                                                    | application                                                             |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | | internal error                                                         | unexpected problem                                                      |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | | coding error                                                           | unexpected problem                                                      |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | | issue/error                                                            | problem                                                                 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | | Failed to                                                              | Unable to                                                               |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | | X failed                                                               | Unable to X                                                             |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | | since                                                                  | because                                                                 | Unless referring to time                                                                                                                                                                                                                                                                                                                                                                                                                                                                       | | there's                                                                | there is                                                                |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | | non something                                                          | non-something                                                           |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | | can not                                                                | cannot                                                                  |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | | associated to                                                          | associated with                                                         |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | | as the                                                                 | because the                                                             | Only when it can be substituted with \"because the\".  There are valid uses of \"as the\", e.g. X must be the same as the Y. In general, don't use \"as\" where you can use \"because\".                                                                                                                                                                                                                                                                                                               | | as it has                                                              | because it has                                                          | In general, do not use \"as\" where you can use \"because\"                                                                                                                                                                                                                                                                                                                                                                                                                                        | | make sure                                                              | ensure                                                                  |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | | check if                                                               | ensure that                                                             | Note: \"check if\" or \"verify that\" are never valid resolutions because they don't tell you what to do or how to do it. A resolution must be actionable. For example: \"Check if the required CA certificates have been added and are valid\" is not a good resolution. It does not tell you what to do if the certs have not been added or if the certs have been added but are not valid. Our messaging must lead the user to success &mdash; not leave them guessing.                           | | provide / provided, supply / supplied, give / given                    | specify / specified                                                     | Be careful with blind replacements here. In many cases, it is possible, but our \"contact support\" message includes the word \"provide\" and must not be changed to say \"...specify a support dump.\"                                                                                                                                                                                                                                                                                              | | try again / retry operation (when used as the sole recommended action) | Tell the user what they need to change and then tell them to try again. | At minimum, each instance needs to be evaluated more deeply to see what our code could do to prevent the user from doing something we could do ourselves.  If a retry is due to a timeout (proxy, etc), then first see if the code can be changed to use an exponential backoff algorithm to do its own retries.  Any time that retry will be used in messaging, the message itself needs more explanation for what actually went wrong.                                                       | | try again / retry operation (without understanding the larger context) | Understand the context and give the correct recommendation.             | E.g. in a sub-task of \"add enclosure\", a try again resolution of any kind is inappropriate because the add enclosure will always result in an enclosure resource being created. The user cannot try the enclosure add a second time.                                                                                                                                                                                                                                                           | | should                                                                 | must                                                                    | \"Should\" does not mean \"must\". If you say that a value should be 0, that is only a suggestion. If it is a requirement, use the word \"must\".                                                                                                                                                                                                                                                                                                                                                    | | has to be                                                              | must be                                                                 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | | were / was / had                                                       | are / is / has                                                          | Use \"were\"/\"was\"/\"had\" to refer to the past and \"are\"/\"is\"/\"has\" to refer to the present.  Notifications must typically refer to the present. Wrong: \"there were no licenses\".  Right: \"there are no licenses\". Acceptable: \"Multiple occurrences of the same network were found…\"                                                                                                                                                                                                             | | mark                                                                   | set / specify                                                           | Wrong: \"There is more than one setting marked as Required\". Better: \"More than one setting is specified as required.\"\"                                                                                                                                                                                                                                                                                                                                                                         | | you / your                                                             | TBD                                                                     | We strive to not use personal pronouns in error messaging. It is too easy to blame the user by using personal pronouns. In general, if the sentence can easily be changed to eliminate the use of these pronouns, do so.                                                                                                                                                                                                                                                                       | | as per the                                                             | per the                                                                 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | | hit / hitting                                                          | press / pressing                                                        | Users do not hit the keyboard. They press keys.                                                                                                                                                                                                                                                                                                                                                                                                                                                | | power down / turn off                                                  | power off                                                               | Also consider whether a shutdown is required.                                                                                                                                                                                                                                                                                                                                                                                                                                                  | | ongoing                                                                | in progress                                                             | When referring to tasks, \"ongoing\" has the wrong connotation: long running perpetual tasks. This is OK: \"ongoing server management\". Otherwise, use statements like: \"the software upgrade is in progress\"                                                                                                                                                                                                                                                                                     | | recreate                                                               | re-create                                                               | \"Recreate\" means to enjoy a leisurely activity. Re-create means to create again. Try to avoid using recreate/re-create, in general, and see if there is a way to rephrase the message without this term.                                                                                                                                                                                                                                                                                       | | getting                                                                | retrieving                                                              |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | | updation                                                               | update                                                                  | \"updation\" is not a word.                                                                                                                                                                                                                                                                                                                                                                                                                                                                      | | is belonging                                                           | belongs                                                                 | Bad example: \"Server profile assigned to the hypervisor profile is belonging to enclosure group…\"                                                                                                                                                                                                                                                                                                                                                                                              | | is having                                                              | has                                                                     | Bad example: \"Server profile assigned to the host is having a different server hardware type…\"                                                                                                                                                                                                                                                                                                                                                                                                 | | is not having                                                          | does not have                                                           | Bad example: \"Hypervisor host XYZ is not having a server profile attached to it and so it is unsupported.\"                                                                                                                                                                                                                                                                                                                                                                                     | | is matching                                                            | matches                                                                 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | | is not matching with                                                   | does not match                                                          |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                | | there are not enough                                                   | there are insufficient                                                  | In general, try to avoid this entirely. It is odd to start with \"there are\" only to end with the fact that this isn't true. For example, instead of telling the user that there are insufficient licenses to perform an action, you might tell them that all licenses are in use and the action cannot be performed.                                                                                                                                                                           | | simply                                                                 |                                                                         | Don't use this word. Never presume something is simple for the user.                                                                                                                                                                                                                                                                                                                                                                                                                           | | drop down                                                              | menu / selection list                                                   | Refer to either a menu (e.g. action menu) or a selection list.                                                                                                                                                                                                                                                                                                                                                                                                                                 | | screen                                                                 | page / dialog                                                           | A page is commonly a linkable, top-level visualization page shown in a browser. A dialog is a pop-up (sidebar, central, full-page) that overlays a page and typically results from the user performing an action.                                                                                                                                                                                                                                                                              | | verify if / check if                                                   |                                                                         | Don't do it. Example: \"Please verify if the input is bad.\" Are we asking them to ensure it is bad or are we asking them to ensure it is good?                                                                                                                                                                                                                                                                                                                                                  | | invalid                                                                | not valid                                                               | Machine translation can incorrectly translate \"invalid\", so it is better to use \"not valid\". However, it is even better to use neither and instead be specific about what the problem is. For example, if an input is not valid because it is too long, then tell the user the input is too long instead of telling them it is not valid. See: https://docs.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/i/invalid-not-valid                                                 | | and if                                                                 | Split into two sentences                                                | Bad example: \"Retry the operation and if the problem persists, contact your authorized support representative and provide a support dump\". Good example: \"Retry the operation. If the problem persists, contact your authorized support representative and provide a support dump\". In general, each separate option in an error resolution should be either, its own sentence, or in a comma separated list. The last-resort action of contacting support must always be in its own sentence. | | re-order                                                               | reorder                                                                 | Use this to describe the action of reorganizing items in a list, rather than re-order (placing another order).                                                                                                                                                                                                                                                                                                                                                                                 | ## Implementation ~~ Implement effective communications with these conventions. ## Documenting messages ~~ A best practice for developers is to add comments to messages in the properties files or message catalogs. Reviewers and translators (and ultimately, users) will thank you. - Document all parameter substitution values. When the value is a resource, be specific. Is it a name? Is it a URI? Is it raw JSON that needs to be encapsulated in curly braces? Or is it pre-formatted JSON that includes curly braces? - For errors and alerts, document the severity associated with the message. - Document the type of message (alert, task, etc). - If a message to users doesn't state how its associated problem occurrs or what to do about it, document those details. - Add context for the task being performed or the resource category involved. - Document if and when API-only messages don't display in the UI. To localize content for international audiences, reference our internationalization(/templates/internationalization) resources. ## User input ~~ Unless there is a compelling reason, do not limit the character set that a user can use to name things. Names commonly contain non-alphanumeric characters and we must handle them correctly on input and in re-display via messaging. For example: - _Joe’s system_ (apostrophe for a possessive) - _O’Reilly Auto Parts_ (apostrophe in name) - _Yahoo! Client_ (company name includes a symbol) - _Frank James-Martin_ (Hyphen in name) - _DC-NY-East_ (Dashes in internal company identifiers) - _Björk Guðmundsdóttir_ (Unicode characters) - _联想_ (Unicode characters) - _John Q. Public_ (punctuation for abbreviation) - _“”>_ (An actual company name in the UK that the UK Companies House had to ban because it broke their systems. See article(https://idle.slashdot.org/story/20/11/08/2334254/uk-agency-demands-company-stop-using-name-which-includes-an-html-closing-tag).) Proper encoding/decoding of user-entered input must be performed to prevent SQL/XSS attacks. Input such as the following user input must not cause problems when the user-generated input is later incorporated in application messaging: - _Robert’); DROP TABLE Students;--_ (see: https://xkcd.com/327/(https://xkcd.com/327/)) User-generated input can be arbitrarily long. When confronted with displaying user-generated input, plan for the 80% case, but define which of truncation (with hover) or wrapping will be used. ## Maintainability ~~ A best practice for developers is to use parameter substitution in messaging where branded names occur. A product's branding is likely to evolve over time. For example, GreenLake Central recently rebranded as Cloud Services. Imagine the multitude of instances to which the product name was referred. Use of parameter substitution limits the number changes to be made while ensuring brand names are spelled and capitalized consistently in all messages. Implementing messages with a parameterized `${prodname}` instead of hardcoded messages allows for a product's branding to be changed easily, confidently, and comprehensively. Lastly, consider formal and informal substitution values which can be used in various contexts. For example: - formal = HPE Ezmeral Container Platform - normal = Ezmeral Container Platform - short = Container Platform ## Case study ~~ Consider a case with messaging related to a condition where a Kubernetes cluster is running low on available memory. Versions 1-7 highlight bad practices and identify the respective problems within each version. Lastly, a best practice(#best-practice) example is provided. ### Version 1 ~~  Problems: - No punctuation - No verb - No context (what cluster?) - Robotic (robots don't use words like \"a\", \"the\", \"is\") - Incorrect capitalization of memory (it is not a proper noun) ### Version 2 ~~  Problems: - It is better to have the resource type (cluster) precede the resource name (ABC). - Names are user-specified and can cause readability issues if not quoted or hyperlinks. See what happens if \"ABC\" is replaced with names like \"the\", \"storage\", \"Joe's\", \"obsolete\", or any random string containing spaces. - What does \"out of memory\" actually mean? We should be more specific. ### Version 3 ~~  Problems: - Strongly consider hyperlinking any named resource so that a user can directly navigate to it from a notification. - 95% of 10TB means that 500GB are still free. But, 95% of 16GB means only 800MB remain. Showing only percentages doesn't offer the user enough context to make a decision. ### Version 4 ~~        The cluster  is using over 95% of its memory       (42GB of free memory out of 1TB total).        } /> Problems: - What is the user supposed to do about this? Never raise an issue without offering a solution. ### Version 5 ~~                 The cluster  is using over 95% of its memory         (42GB of free memory out of 1TB total).              Do the needful.        } /> Problems: - What is the needful? This is a saying not used in conversational American English and does not give the user specific guidance. ### Version 6 ~~                 The cluster  is using over 95% of its memory         (42GB of free memory out of 1TB total).                       Remove containers, reduce quotas, or increase the cluster capacity.               } /> Problems: - The user purchased the cluster to use it. Telling them to stop using it is not going to go over well. - Is this really a critical issue? Unused resources are often considered wasted resources. It is actually a good thing to be fully utilizing your hardware. - In an aaS world, additional capacity should be a simple add-on to an existing service. As such, this may not be a critical issue, but could be transformed to a lower priority marketing message. ### Version 7 ~~                 The cluster  is using over 95% of its memory (42GB         of free memory out of 1TB total).                       If you have plans to increase utilization in the near future, additional         capacity can be added by selecting the \"Order Capacity\" action from the         action menu.               } /> Problems: - If possible, give the user a way to directly perform a mentioned action. ### Best practice ~~                 The cluster  is using over 95% of its memory         (42GB of free memory out of 1TB total).                       If you have plans to increase utilization in the near future,         additional capacity can be added by selecting the{' '}          action from the action menu.               } /> - Correct capitalization and punctuation is used. - The named resource is hyperlinked so that a user can directly navigation to it from a notification. - A solution to the issue is provided to the user. - Context on how much available memory is provided. - The user is given a way to directly perform a mentioned action. "},{"name":"Index","parent":"pages","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/index.js","content":"    // Main homepage for HPE Design System   /* Including header here to share the same background image */     // These make a box width limited to xxlarge but centered // Used to center sections with max width  // Intro section wrapper for hero content  Intro.propTypes = {   children: PropTypes.node, }; // Hero section container with background image  Hero.propTypes = {   children: PropTypes.node,   bgImage: PropTypes.string, }; // Homepage component with dark mode background switching       // Use different background image for dark mode      return (                                                                     Design, develop and deliver                                         Empower designers and developers to quickly create accessible               enterprise app experiences.                                                                                                           ); }; export default Index; "},{"name":"Grid Fundamentals Part One","parent":"learn","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/learn/grid-fundamentals-part-one.mdx","content":"   In this tutorial you will use Grid to display a collection of products, similar to that of an e-commerce website, and use its properties(https://v2.grommet.io/grid?theme=hpe#props) to: - Present a collection of items in a grid. - Allow the number of grid columns to adapt to a variety of screen widths. - Allow the items to adapt and flex within the available space. At the end of this tutorial, you will have built a grid of product cards(#final-layout). ## Prerequisites ~~ This tutorial can be completed in its entirety by following the steps below. However, because Grommet is a ReactJS-based UI library, introductory knowledge of React(https://reactjs.org/docs/getting-started.html) may be helpful in understanding the syntax. ## Getting started ~~ Let’s get started. Use this CodeSandbox template(https://codesandbox.io/s/grid-fundamentals-part-one-starter-ljmks2?file=/src/App.js) as a starter. First, in `App.js` add the Grid to your project by importing it from Grommet and placing it around the “hello world” text.   Let's also add a heading to the page.  ## Add placeholder content ~~ Now that you have the Grid in place, let's add some placeholder content. Replace the \"hello world\" text with the following:  We now have a Grid with seven boxes, each containing a product name. The Grid is displaying the boxes in a single column, which is the default behavior. ## Add columns ~~ To display the boxes in a grid, we need to add columns. The Grid component has a `columns` property that allows you to specify the number and/or width of the columns you want to display. Let's add the `columns` property to the Grid and set it to `{ count: 3, size: 'auto' }`.  Now the boxes are displayed in a grid with three columns.      ## Add product content ~~ Now that we have a grid with three columns, let's add some product content to the boxes. Start by adding `ProductCard` and `productList` to App.js. `ProductCard` is a template set up for ease of use and will be used to display the product image, name, and price. `productList` is a JSON file containing the product data.        To learn more about the components used in ProductCard, check out the API       docs for{' '}              , , , , , , and .        }   width=\"xlarge\"   margin={{ bottom: 'medium' }}   status=\"learn\" />   Then, replace the placeholder content with the following:  Now the products are displayed in the grid with three columns.      ## Responsive columns ~~ Take a moment to resize the browser window. Adjust the width, both wider and narrower. Notice that the products appear squished when the browser window is narrow and stretched when the browser window is wide. This is because the Grid is not responsive. Let's fix that. To make the Grid responsive, we will adjust the `columns` property. Set the `columns` property to `\"medium\"`.  Now the Grid will fit as many columns as will fit in the available space, with each column being a minimum width of the t-shirt size 'medium'.        Did you know that Grommet uses \"t-shirt sizes\" to make implementing       consistent layouts easy? Learn more about{' '}       .        }   width=\"xlarge\"   margin={{ bottom: 'medium' }}   status=\"learn\" /> Notice how the number of columns changes as the browser window is resized. The Grid is now responsive.      ## Polishing the layout ~~ Now that we have a responsive Grid, let's polish the layout. Let's add some space between the products by adding `gap=\"xsmall\"` to the Grid.        Finally, let's refine the column width to be a bit more efficient with our screen's real-estate. A minimum column width of `\"medium\"` feels too wide. Let's try setting the `columns` property to `\"xsmall\"`.  Now we are able to display more products in each row, but they become too narrow. Let's make our final modifications by importing the function `midSize` from a utilities file, add two additional lines of code which calculate a column width between 'small' and 'medium', and then use that value in the `columns` property.  ## Final layout ~~ Congratulations! You have completed the tutorial and have a great start on a very respectable product catalog.      ## Summary ~~ In this tutorial, you learned how to: - Use the Grid component to present a collection of items in a grid. - Use the `columns` property to specify the number and/or width of the columns. - Use the `columns.count` property to specify the number of columns. - Use the `colums.size` property to specify the width of the columns. - Use the `columns` property to respond to the space available. - Use the `gap` property to add space between the items. If you'd like to reference a completed implementation, check out this CodeSandbox with completed code(https://codesandbox.io/s/grid-fundamentals-part-one-complete-h9zc75?file=/src/App.js). "},{"name":"How To Add Additional Controls To A Toolbar","parent":"learn","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/learn/how-to-add-additional-controls-to-a-toolbar.mdx","content":"  ## Prerequisites ~~ This guide builds off the \"How to add search and filter to DataTable\" how-to guide(/learn/how-to-add-search-and-filter-to-datatable-with-data). While it's not necessary to complete that guide first, it may be helpful for additional context. Let’s get started! Use this CodeSandbox template(https://codesandbox.io/p/devbox/how-to-add-additional-controls-to-a-toolbar-gn9q9j?file=%2Fsrc%2FApp.js%3A46%2C20) to start. The template is populated with a paginated DataTable configured to display SpaceX data with search and filter controls. ## Importing the components ~~ In `App.js`, start by importing the Toolbar component and the Data controls you'll include in your toolbar.  ## Compose the toolbar ~~ ### Render the controls in the toolbar ~~ Remove the `toolbar` property from Data. Insert the Toolbar and Data controls (DataSearch(https://v2.grommet.io/datasearch), DataSort(https://v2.grommet.io/datasort), DataFilters(https://v2.grommet.io/datafilters)) above the DataTable. Apply `drop` to DataSort to render the sort controls in a drop and `layer` to DataFilters to render the filters in a side drawer layer.  ### Allow user to define column visibility and order ~~ Create a variable, `options`, which defines which properties should be part of the DataTableColumns(https://v2.grommet.io/datatablecolumns) experience. In this case, we'll dynamically generate these options based on the `columns` of the DataTable.  Next, add DataTableColumns to the toolbar, passing the `options` variable you created to the `options` property. Similar to the other controls, specify `drop` to render the control in a drop.  ### Group controls into sections ~~ Next, create subsections of the toolbar controls in alignment with data collection toolbar guidance. First, group all of the \"find\" controls (DataSearch, DataSort, and DataFilters) together by wrapping them in their own Toolbar. Then, add `gap=\"medium\"` to the outermost Toolbar to create more distinction between toolbar sections.  ### Add the data summary ~~ Lastly, add the DataSummary below the outermost Toolbar.  Your project should look like this:      Congratulations! You’ve used Data subcomponents to compose a toolbar with a variety of controls. To reference a completed implementation, check out this CodeSandbox with completed code(https://codesandbox.io/p/devbox/how-to-add-additional-controls-to-a-toolbar-completed-l5nr54?file=%2Fsrc%2FApp.js%3A14%2C15). "},{"name":"How To Add Search And Filter To Datatable With Data","parent":"learn","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/learn/how-to-add-search-and-filter-to-datatable-with-data.mdx","content":" ## Prerequisites ~~ Let’s get started! Use this CodeSandbox template(https://codesandbox.io/p/devbox/how-to-add-search-and-filter-to-datatable-j7n3dz) to start. The template is populated with a paginated DataTable configured to display SpaceX data.  ## Set up Data provider ~~ In `index.js`, start by importing `Data` from grommet. Then, remove the `data` property from DataTable and place it as a property on Data. The Data component is now the data provider, controlling which data should be rendered in the DataTable.  ## Add default search and filter capabilities ~~ ### Toolbar ~~ Setting `toolbar` to 'true' will include a Toolbar containing DataSearch, a results summary above the DataTable, and DataFilters with layer prop. Grommet offers a Toolbar component(https://v2.grommet.io/toolbar) for users who may want to configure their own toolbar.  At this point, your project should look like this:      ### Total ~~ We are only fetching one page of data at a time. Add `total={numberItems}` to inform Data of the total number of records. `numberItems` is defined in the starter template using a key from the API response providing the total number of records in the table.  ### View and onView ~~ The `view` property specifies the subset of data to be displayed, whether that be applied filters, current page, and/or other customizations. To ensure the table displays the proper results from any applied filters, use `view` and `onView`. First, create a state variable called `view`.  Next, add `view` and `onView` as properties on Data. When the filter change, `onView` will provide the new values. Use this to update the `view` state variable and reset the page to 1.  To fetch the data again when the value of `view` changes, pass `view` as a parameter in `fetchData` and include `view` as an item in the dependency array of the useEffect.  At this point, your project should look like this:        ## Customize filtered attributes ~~ To customize which attributes are filterable, use `properties` property on Data. In this case, let's only filter by \"type\" and \"mass_lbs\". For the ease of this guide, we've hardcoded the options for \"type\" and \"mass_lbs\", but handling this dynamically is recommended for applications in production. Add the following to Data:  Now, when the filters layer is opened, the filters will look like this:      Congratulations! You’ve used Data to add search and filter controls to manage what data should be rendered in a DataTable. To reference a completed implementation, check out this CodeSandbox with completed code(https://codesandbox.io/p/devbox/how-to-add-search-and-filter-to-datatable-completed-dgs243). "},{"name":"Index","parent":"learn","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/learn/index.js","content":"                                                                         return (                                {results.map((type, index) =>                   type.data?.length ? (                                                                     {type.data.map(item => (                                                    ))}                                                               ) : null,                 )}                            );           }}                         ); export default Learn; "},{"name":"The Box Model Part One","parent":"learn","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/learn/the-box-model-part-one.mdx","content":"  In this tutorial you will use Box to build a hero section for a page and understand how to use some of its properties(https://v2.grommet.io/box?theme=hpe#props) to: - Orient the direction of your layout. - Control the width of its content. - Add a background color. - Affect the amount of spacing between each of its child elements. At the end of this tutorial, you will have built this:      ## Prerequisites ~~ This tutorial can be completed in its entirety by following the steps below. However, because Grommet is a ReactJS-based UI library, introductory knowledge of React(https://reactjs.org/docs/getting-started.html) may be helpful in understanding the syntax. ## Getting started ~~ Let’s get started. Use this CodeSandbox template(https://codesandbox.io/s/hpe-design-system-tutorial-starter-be7kse?file=/src/App.js) as a starter. First, in `App.js` add the Box to your project by importing it from Grommet and placing it around the “hello world” text.  ## Add hero section content ~~ Now, you'll add the content within the Box. Start by importing Button, Heading, Image, and Text.  Replace “Hello world” with the following content as children of the Box.        To learn more about the properties applied to these components, check out       the API docs for{' '}              , , and .        }   width=\"xlarge\"   margin={{ bottom: 'medium' }}   status=\"learn\" />  At this point, your project should look like this:      ## Use direction to affect content layout ~~ Now, we’d like to adjust the layout direction of the content so that the text appears on the left and the image on the right. Box has a direction(https://v2.grommet.io/box?theme=hpe#direction) which specifies whether the Box's children are displayed vertically or horizontally. By default, the layout direction of Box is “column” which renders its children vertically. To adjust the direction, add `direction=\"row\"` to the Box.  Notice how the content is displayed in a row from left to right. That is because each element was a direct child of the Box to which we added the `direction` property. However, we would like the heading, paragraph, and button to be grouped and displayed in a column. To do so, wrap these elements in a Box of their own.  Now, the image and the Box containing the heading, paragraph, and button are the only direct children of the container Box, so only those two elements are displayed in a row. For any content we wanted displayed in a column, we had to group it in its own Box. At this point, your project should look like this:      ## Use Box to manage an image's width ~~ Right now, the dimensions of the image file are determining how wide it is. In order to have more control of the image’s width, wrap the image in its own Box.  ## Adjust width to manage content dimensions ~~ In order to ensure the text content remains a more readable width across wide screens, apply `width=\"large\"` on the Box containing the heading, paragraph, and button. To keep the button from stretching the full width of the box, apply `alignSelf=\"start\"` on the Button. Notice how the button is no longer spanning the entire width of the Box.         Throughout this tutorial, we’ll be using t-shirt sizes. Make sure to read       the{' '}                       {' '}       for more information on what they are and their value in Grommet.        }   width=\"xlarge\"   margin={{ bottom: 'medium' }}   status=\"learn\" /> At this point, your project should look like this:      ## Add a background color and pad ~~ Now, let’s add a background color to the hero section by adding `background=\"background-contrast\"` to the outer Box. We also want some space added between the edge of the outer Box and the content. To do so, add `pad=\"large\"` to the outer Box. Remember that `pad` (equivalent to CSS padding) applies space inside of a given container while `margin` applies space outside of a given container.  At this point, your project should look like this. We’re getting closer, but we’re missing spacing between the various content elements, such as the space between heading and paragraph, paragraph and primary button, and text and image.      ## Use gap to add space between elements ~~ Now, let’s add the spacing between elements. Whenever space is needed between elements, use `gap` on the parent Box of those elements. To add space between the image and the grouped content, add `gap=\"large\"` to the outer Box.  Notice how the gap only applies between the image and the heading/paragraph/button group but not between the heading, paragraph, and button. That’s because `gap` will only apply space between the direct children of a Box. In this case, the direct children were: 1. The Box containing the Heading, Paragraph, and Button. 2. The Box containing the Image. Now, add space between the heading, paragraph, and button by applying `gap=\"medium\"` to the Box that wraps those elements.  Great job! You have built a hero section of a page using Box and its various properties. Your project should look like this:      If you'd like to reference a completed implementation, check out this CodeSandbox with completed code(https://codesandbox.io/s/the-box-model-part-one-completed-xbwg9u?file=/src/App.js). export  "},{"name":"Ascending Navigation","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/ascending-navigation.mdx","content":"   When an application’s hierarchy is well designed, the ascending button will typically take the user back to the previous page they came from.      ## Guidance ~~ - Follows the default button styling(https://design-system.hpe.design/components/button#default-button) with a \"FormPrevious\" icon. - Displayed below the Header and aligned to the left with the pages content. ## When to use ~~ - To allow users to return to the parent (hub) screen when on a details (child/spoke) page. - To visually communicate the parent page for the user’s current page. ## Example ~~ Ascending Navigation provides an easy way for a user to move from a child page up to a parent page.  "},{"name":"Code Blocks","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/code-blocks.mdx","content":"       ## Guidance ~~ Code blocks can be created using the react-syntax-highlighter(https://github.com/react-syntax-highlighter/react-syntax-highlighter) tool. Prism or Highlighter.js can be used with react-syntax-highlighter. Highlighter.js is the default, however it can have trouble highlighting JSX, so it is recommended to use Prism instead. Prism with react-syntax-highlighter supports syntax highlighting for hundreds of languages(https://github.com/react-syntax-highlighter/react-syntax-highlighter/blob/master/AVAILABLE_LANGUAGES_PRISM.MD). react-syntax-highlighter can be installed with the following command: For yarn users: `yarn add react-syntax-highlighter` For npm users: `npm install react-syntax-highlighter --save` For pnpm users: `pnpm install react-syntax-highlighter` Import the react-syntax-highlighter specifying Prism as the highlighter with the following: `` ### Theming ~~ The theme exported from grommet-hpe-theme(https://raw.githubusercontent.com/grommet/grommet-theme-hpe/master/src/js/themes/prism.js) should be used to style code blocks. ### Scrolling ~~ Horizontal scrolling should be avoided where possible. Vertical scrolling within the code block container is encouraged when a code block is long. ### Line wrapping ~~ Long lines should wrap to avoid horizontal scrolling. This option can be specified with `wrapLongLines`. ### Tab index ~~ To ensure the code block is accessible to keyboard users the `tabIndex` should be set to 0. "},{"name":"Content Layouts","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/content-layouts.mdx","content":"      Content layouts may be applied across different levels of information hierarchy. At a page template level, it can help with the layout of page sections. At an page section level, it can coordinate how a title, piece of content, and related actions should be laid out in relation to each other. Understanding Grid(/components/grid) is the key to creating successful content layouts. Looking for a quick start? Jump to layout templates(#templates). ## Responsive design ~~ Layouts should be adaptable to different screen sizes. Our goal as designers and developers at HPE should be to create optimal and accessible user experiences regardless of screen size or resolution. ### Breakpoints ~~ A breakpoint is a point at which some change in the page design is likely to occur. For designers, breakpoints can help stress test and validate UX decisions around page layouts. See the table below for breakpoints defined by the HPE Design System. Keep in mind that these breakpoints are not meant to target every single existing device &mdash; we understand that technology is ever evolving. Instead, the ranges defined here help build a strong foundation to account for diverse use cases when creating responsive designs. | Breakpoint | Range (width in pixels) | | ---------- | ----------------------- | | **xsmall** | 576 and below           | | **small**  | 577 - 768               | | **medium** | 769 - 1080              | | **large**  | 1081 - 1439             | | **xlarge** | 1440 and above          | ### Prioritizing content needs ~~ Focusing on content needs allows for optimal user experiences to be created. Thinking about which pieces of content a user will likely need and want to interact with first informs how the items on the page should be ordered. Specifying layout content in this way will also ensure that it is interepreted appropriately by screen readers for visually impaired users. The example below has content labeled by its priority. Resize your browser window and notice the content layout adjust, ensuring content is ordered as desired across window widths. {/* height, width value chosen to best visually represent the example */}      ## Implementing content layouts ~~ The following discusses three approaches for building responsive content layouts. All approaches may be mixed and matched as desired. - Container-driven(#container-driven-layouts) - Content-driven(#content-driven-layouts) - Nested grids(#nested-grids) These approaches take full advantage of Grid's flexibility which provides designers and developers great control and ability to execute layouts regardless of the user's screen size. For greater detail about Grid's properties and key concepts visit getting to know Grid(/components/grid#getting-to-know-grid). Additionally, a can't miss tool for designers is Layout Templates in Figma(https://www.figma.com/design/fupkQ4sOefx3qUVoV6WfJi/Template-Library?m=auto&node-id=4040-6121&t=r7Bf1k6QfmCKSMhJ-1) which provides Grid-based layout templates for each responsive breakpoint(#breakpoints) and page layout kind(/templates/page-layouts#page-kinds). ### Container-driven layouts ~~ Container-driven layouts drive the layout from the outside-in. They begin by defining regions in which the content will live, whether those regions are fixed, flexible, or fluid(/components/grid#background), and how those regions are prioritized(#prioritizing-content-needs) at each responsive breakpoint. Container-driven layouts are useful for defining larger layouts, such as at the page level, but can be useful for defining smaller sub-regions as well. The best use of available screen real-estate can be achieved by combining a container-driven page layout with components such as Cards which have been built to have adaptive layouts themselves. The following example takes a container-driven approach, implementing an app-catalog consisting of a filters region and a results region. Key aspects to the approach are: - At larger breakpoints, the content layout will be a two-column layout; a single column   at smaller breakpoints. - The filters region will be fixed-width when in a two-column layout and flex-width(/components/grid#flexible-columns)   when in a single column. The results region always uses a fluid grid(/components/grid#fluid-grids). - The filters region are prioritized over the results region because the filters are needed to control   the results. {/* height, width value chosen to best visually represent the example */}      ### Content-driven layouts ~~ Content-driven layouts are driven from the inside-out, allowing the container to respond and adapt to things like user entered content, like names. The layout is custom fit to the content it holds. The content-driven approach is useful for layouts such as modal dialogs or side drawer content within a layer, where the content should occupy the space it needs and not be awkwardly constrained by its layout container. The following example takes a content-driven approach, implementing a modal dialog displaying content returned from a server with an unknown length.      ### Nested grids ~~ When dealing with complex layouts, it is helpful to simplify them by thinking of them as nested grids. Any column or grid area may be a grid itself.      ## Templates ~~ Responsive, customizable layout templates to help you jumpstart your application design and development. This work is in progress. More templates coming soon.  "},{"name":"Dashboards","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/dashboards.mdx","content":"       ## Guidance ~~ Dashboards provide users peace-of-mind knowing critical measures, applications, and services are healthy; plus, easy access to areas needing attention for the moments when they are not. Well designed dashboards begin by defining the specific purpose and user needs it is serving. Operational dashboards focus on delivering information such as data deviations, current resources, and resource statuses so that users can proactively execute time-sensitive tasks. Analytical dashboards present comparison, relationship, and distribution data supporting analysis and decision making. Regardless of need, each of these templates deliver at-a-glance critical information and quick navigation to underlying detail. Consider: - abbreviated numbers (ex: $1.2M vs $1,234,567.89) - less detail - fewer colors (ex: show 4 pie chart sections and a 5th for other) - larger items and fewer items ## Dashboard templates ~~ The following templates are based on page layout guidelines(/templates/page-layouts) and serve as a starting point for design and development. They are customizable depending on your content and UX needs. Templates for 3 column and 4 column dashboards are coming soon. ### Two column dashboard ~~      ### Three column dashboard ~~      "},{"name":"Datatable Customization","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/datatable-customization.mdx","content":"       ## Guidelines ~~ For complex data tables with many columns, the user will need the ability to configure which columns they want to see and the order in which these columns appear. This functionality is handled by a dropdown that contains two tabs: one for selecting which columns should appear in the DataTable and another for ordering the columns. ## Anatomy of a customizable DataTable ~~ ### An action to manage column visibility and order controls ~~ Since we want to customize the data table itself, we have separate controls for changing which columns are shown in the data table and their order. Place a button with a `Manage columns` icon to the right of the search and filter controls. These view controls change what items are shown in the data table or how they are presented rather than changing the items themselves. The right aligned `Actions` menu is mainly for actions which modify items in the data table. ### Column visibility ~~ Clicking on the `Manage columns` button opens a dropdown which has two tabs. The first tab should be active and labeled \"Select columns.\" The tab content should consist of a Search input and a CheckBoxGroup that lists all possible table columns. When a column in the list is checked, it is visible in the data table. When it is unchecked, it is removed from the data table. When a column from the data table is required, display it as checked and disabled. Adjustments to the table data should occur immediately as the user checks or unchecks a column, as opposed to waiting until the dropdown closes. The user can also search for a specific column by typing in the Search input.    ### Column order ~~ The second tab of the dropdown should be labeled \"Order columns.\" It contains a list of the selected columns from the \"Select columns\" tab. A user can reorder the columns either by dragging and dropping the column names in the list or by using the move up/move down buttons that are present next to each column name. Similar to column selection, the reordering of the data table columns should take place immediately, as opposed to waiting until the dropdown closes. "},{"name":"Drill Down Navigation","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/drill-down-navigation.mdx","content":"  Drill Down Navigation allows for a consistent and focused experience that helps eliminate cognitive overload. ## When to use ~~ - When users need to focus on one task at a time. - To provide summary information with the ability to drill down into specifics. - When screen real estate is limited. - When designing for many levels of functionality. - To divide content into meaningful, focussed sections. - When the user is moving forward step-by-step to access further information. - When going from your Account > Services > Service. - To allow users to dive deeper into related content. ## Guidelines ~~ - Can be used as an individual element or in groups of related content. - Each element should have its own single content. ## Examples ~~ ### Card ~~ A visual representation of interactive and organized content.           ### List ~~ Lists provide access points that present a collection of organized and related content.           ### DataTable ~~ Datatables present data in a column and row format. A user can be taken to a spoke when an entire table row is clickable or if an individual cell is clickable to drill down into more information.           "},{"name":"Empty State","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/empty-state.mdx","content":"        ## When to use ~~ Common empty state use cases include: - “Day 0” use cases when a user first starts using an application - When the user completes an action that returns no results - When an error prevents the system from returning any data   - For errors generated by a user's action, an inline notification may be used to compliment the empty state. This provides feedback to the user associating that the empty state was caused by, and resolved by, the user's action. It is our responsibility as designers to provide our users with clear, concise guidance on why the data isn’t present and how to move forward in their journey. A well-designed empty state can improve the user experience and reduce confusion by setting clear expectations for what the user should do next. Here are a few characteristics that make a well-designed empty state: 1.  **Clear messaging:** The empty state should have simple and clear messaging that tells the user what information is missing, why it is missing, and what they can do next to access the information. Follow the voice and tone guidance(/foundation/voice-and-tone) within the design system to remain clear and empathetic to the user. 1.  **Visual cues:** The empty state should use iconography to help convey the message and create a more engaging user experience. The icon should be relevant to the context of the interface and help the user understand why it's empty. 1.  **Guidance:** The empty state should provide guidance and a direct pathway out of the empty state when applicable. Avoid leading the user to a dead end. 1.  **Calls-to-action:** The empty state should include calls-to-action that encourage the user to take action, such as creating their first resource or adding their first item. 1.  **Help or documentation links:** The empty state may include links to help or documentation resources that can assist the user in populating the view with data or finding relevant information. ## Anatomy ~~      Although there are many diverse use cases for empty states within our solutions, we use a single component structure to ensure they are consistently applied across the complete user experience. Below describes the structure of an empty state component: | Label | Region          | Purpose                                                             |                  Required                   | Notes                                                                                                                                              | | ----- | --------------- | ------------------------------------------------------------------- | :-----------------------------------------: | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **1** | **Icon**        | Imagery to help the user process the message.                       |                                             | Use size=\"xlarge\" on icon.                                                                                                                         | | **2** | **Heading**     | Communicates the system status.                                     |  | Use the semantic heading level(/foundation/typography#semantic-usage-of-heading-levels) that fits the placement of the empty state. | | **3** | **Description** | Guides the user out of the empty state                              |  | Use default text size of \"medium\".                                                                                                                 | | **4** | **Action**      | A direct pathway out of the empty state.                            |                                             | Generally there is a single action button, but a supporting action button can be added if the use case warrants. Limit to two or fewer.            | | **5** | **Link**        | An additional learning cue to help the user out of the empty state. |                                             | If present, there is generally a single link, but an additional link may be added if the use case warrants. Limit to two or fewer.                 | ## Placement ~~ The placement of an empty state in a UI depends on the context and the type of content the interface is displaying. However, some common placements for empty states are: 1. In the center of the interface 1. In the top left of the interface 1. Within the content area Ultimately, the goal of the empty state is to guide the user and help them understand what they can do to populate the interface. So, it's important to place it in a location that is visible, intuitive, and contextually appropriate. ### In the center of the interface ~~ Center the empty state horizontally within the UI to ensure the empty state is the focal point of the UI. The exact positioning of the empty state can depend on the specific UI design and layout. For example, if there are other elements in the content area, the empty state may need to be adjusted slightly to ensure it is still centered within the available space.      ### In the top left of the interface ~~ With left-aligned UIs, positioning an empty state on the top left could help draw the user's attention to the fact that there is no content available in that section. This is the most common placement within our cloud services.      ### Within the content area ~~ Sometimes, it makes sense to place the empty state within the content area itself. For example, if the interface is displaying a list of items, the empty state can be a message that appears when there are no items in the list.           ## Types of empty states ~~ ### No data empty state ~~ No data empty states are displayed when an application has no data to show for a particular view or section. The messaging and visual cues should convey that there is no data to display, while also providing guidance or calls-to-action that can help the user add data or find the information they need. The best position for this type of empty state is typically the location where the data is presented, but always ensure they are in a prominent and clear location where users can easily find and understand them.      ### Action empty state ~~ Action empty states provide feedback to the user that an action has been successfully completed or that no data has been returned as a result of that user action. These states can be used in various situations, such as: 1. **After completing a task:** When a user completes a task such as sending a message, submitting a form, or deleting an item, the user interface can display an action empty state to indicate that the task has been completed successfully and there are no further actions required at that moment. 2. **After clearing notifications:** When a user clears all notifications from their notification panel, an action empty state can be used to indicate that all notifications have been cleared and there are no further notifications to view or take action on. 3. **When no results returned from a search:** This can provide the user with clear feedback that the search has been completed and there are no matching results available, while also offering suggestions for alternative actions that they can take.      ### Error management empty state ~~ Error management empty states are displayed when there has been an error that prevents the content from loading or displaying correctly. These are designed to provide feedback to the user when an error occurs. This can include error messages or prompts that guide the user through the error and provide possible solutions or next steps. The goal of an error management empty state is to help the user understand what went wrong and how to resolve the issue. Some considerations for writing error management empty states: 1. **Consistent visual cues:** these empty states typically use the “alert” status icon and “status warning” color. Only deviate from this standard if it is necessary for your context. 1. **Appropriate tone:** receiving errors can be frustrating to the user. Be sure to remain empathetic to the seriousness of the error, don’t pass blame to the user, and be clear about how they can resolve the issue. 1. **Direct messaging:** be clear about what impact the error may have on a user's work in a readable format. Only provide the information that is necessary to help the user fix the issue, and avoid unnecessary technical jargon.      "},{"name":"Filtering","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/filtering.mdx","content":"   export  For details on the components that make up the filtering experience, see Data documentation(/components/data), DataFilters documentation(/components/datafilters), DataSummary documentation(/components/datasummary), and DataSearch documentation(/components/datasearch).      ## When to use ~~ Filtering allows data to be narrowed down around a set of specified parameters. When users may not have a specific record in mind but are seeking to group data around a certain set of attributes, filtering allows the user to narrow the data and take action on relevant records. If a user will likely be looking for a specific record as opposed to groups of data, consider implementing search. ## Placement ~~ Filter controls should live above the data content and facilitate a user's ability to locate and take actions against records of interest. ## Presentation ~~ The way filters are displayed is dependent on the number of filters, data types of the content, and the use case. - In most cases, filters should be presented in a side-drawer layer(#filters-in-a-layer) that can be opened by a button with Filter icon. - At times, it may be helpful to expose a frequently used filter in the toolbar(#exposed-filter-in-toolbar) directly. Filter types should suit both the type of data and number of options available. For example, rendering numeric data as a RangeSelector is more beneficial than rendering it as a CheckBoxGroup because it allows the user to more efficiently define a desired range. When building with Data and friends(/components/data), a smart default input for a given property will be determined based on the type of data and the number of options. For details on which/how the default input type is chosen, see DataFilter documentation(/components/datafilter). While the default input types are intended as smart defaults for the 80% case, other input types can be used if it better suits the use case. ## Results ~~ Results should live below the controls and display any records that meet the filter criteria. Depending on the data types and use case, results may be represented by a List(/templates/lists), Cards(/components/card), or DataTable(/components/datatable). ## Data summary ~~ The summary displayed beneath the filter controls should always reflect the user's actions. When filtering is combined with selection(#selectable-results), the summary text should adjust for the following scenarios. | State                                | Summary                        | Notes                                                                                                  | | ------------------------------------ | ------------------------------ | ------------------------------------------------------------------------------------------------------ | | **No filters, no selections**        | Y items                        | Y is the total number of items in the dataset.                                                         | | **Filters applied, no selections**   | X results of Y items           | X is the number of items that meet the filter criteria. Y is the total number of items in the dataset. | | **No filters, selections made**      |          | Z is the total number of items selected.                                                               | | **Filters applied, selections made** |  | Z is the total number of items selected.                                                               | When building with Grommet, DataSummary(/components/datasummary) manages these messages automatically. ## Pagination ~~ For large data sets, it can be helpful to paginate the data and display pagination controls underneath the results. For details on pagination behavior, see Pagination documentation(/components/pagination). ## Examples ~~ ### Filters in a layer ~~ When applying many filters at once, it is helpful to present them in a consolidated layer.      ### Exposed filter in toolbar ~~ If it's expected that a specific filter or filters will be most frequently used, the filter can be exposed in the toolbar. Use your understanding of the use case to determine if this will aid the user's goal.      ### Selectable results ~~      "},{"name":"Index","parent":"forms","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/forms/index.mdx","content":"          ## When to use ~~ To efficiently capture information necessary for completing a task. ## When not to use ~~ Complicated processes where the user might need guidance at various stages, or when the form would be intimidatingly long. In these cases use a Wizard(https://design-system.hpe.design/templates/wizard?q=error#guidance). ## Do's ~~ **Required fields** - Ask only for the required information. Keep the fields to a minimum to allow the user to finish their task as quickly as possible. - List only the most common field requirements below the relevant field. - Use asterisks for required fields when the form has more than two required fields and/or has optional fields. - Asterisks for required fields should be the same color as label field. **Format and fields** - User-entered input must be encoded to prevent SQL injection(https://www.w3schools.com/sql/sql_injection.asp) and XSS attacks(https://en.wikipedia.org/wiki/Cross-site_scripting). - Wrap all input elements within a FormField `` - Reveal fields progressively so the user is not overwhelmed. - Write in sentence case (capitalize the first letter and all following letters should be lowercase). - Fill in default values for as many fields as possible. - Use clear, concise labels for each field. - Write helpful placeholder text inside the fields. - If the user will likely have doubts about how to complete an input, include helpful text below the field, such as password requirements(#sign-up) or additional resources(#customize) on a field's context. - Place the submit, reset, and cancel buttons at the bottom left of the form. See responsive button behavior(https://design-system.hpe.design/components/button#responsiveness). - Use specific labels on buttons that tell the user what action to expect. **Actions after the user submits information** - Provide feedback when the form is submitted successfully (e.g. notification, success page, green check mark, etc.). - In the case of an error(#required-vs-optional-fields), red highlight the field where the error occurred. - List all errors and the corrective action the user must take. Place inline when possible. Otherwise, list above the submit button. - Allow the user to continue navigating through the application immediately. ## Don'ts ~~ **Required fields** - Use asterisks for sign up and sign in forms. This can be implemented using `required={{ indicator: false }}`. - Use red asterisks, because has shown to actually decrease success in filling out the form. - List rejection criteria that the user is unlikely to input (ex. double hyphens, starting with a space, etc.). Only alert them when they type the error. **Format and fields** - Have more than two optional fields. - Repeat the field label as placeholder text. - Use generic labels on buttons, such as “Yes,\" or \"No.\" Instead use labels such as \"Save,\" \"Publish,\" \"Create Project,\" etc. - Restrict resource naming. Allow spaces, punctuation and unicode characters (ex. Björk Guðmundsdóttir, 联想, John Q. Public, etc.). ## Accessibility ~~ Form inputs must be accompanied by a label that identifies itself to screen readers. Placing all inputs within a Grommet FormField and applying the guidance below play a big role in ensuring the inputs are accessible. **FormFields must include:** - A \"for\" property that matches the `id` of its child input. If using Grommet, this is applied with the `htmlFor` property.  - A `name` property applied on both the FormField and its child input element. - A clear, concise label. - Ensure that users can tab through fields and buttons in a logical order and not have to use arrow keys. View the accessibility guidance page if you'd like to use simulators, testing tools, and other resources(https://design-system.hpe.design/foundation/accessibility?q=acce). ## Terms and conditions ~~ Users must actively check a box next to a statement that shows they have agreed to the Terms and Conditions when signing up for an account. For easy access and quick reference, the legal agreement is a simple link in the text. ## Single field forms ~~ - For single form fields(#single-required-formfield) (ex: delete confirmation request), use an asterisk to denote that it is a \"required\" field. This can avoid user confusion and reduce the chance of \"required\" input error. ## Use cases ~~ ### Sign up ~~      ### Sign in ~~      ### Filter ~~ To learn about filtering, read the filtering documentation(/templates/filtering). ### Sort ~~      ### Change password ~~      ### Settings ~~      ### Pay ~~      ### Shipping ~~      ### Customize ~~      ## Required vs optional fields ~~ For standard forms, use an asterisk(\\*) to indicate required field/controls. **Please note that at this time we do not have use cases that require labeling a form field as optional. If you feel you have a use case that would need to be labeled as optional, please contact us to discuss further.**      ### Single required FormField ~~      ### Fields with character limits ~~ **When to use** In cases where the user is given an opportunity to express themselves or would likely exceed a field's character limit. Examples include some description fields, feedback, feature requests, reporting issues, etc. In general, exceeding the character limit should be an infrequent experience for users. If users are  with only the minimum required fields so that the user can focus on completing their task. Separately, in a preferences or settings dashboard, for example, provide a form that allows the user to add helpful, optional information at another time. An example of a helpful but not required field could be asking for someone's official title or role. If it is not necessary to capture this information right away on a sign-in form, offer this \"role\" or \"title\" field in profile settings.  ## Where to present a form ~~ There are several placement options when presenting a form, but when should a particular placement be chosen and why? On a dedicated page? Within a layer? If within a layer, which type?  ## Full-page forms ~~ A full-page form is used to display information free from interuption. They may be presented on a dedicated page or within a fullscreen layer. **Best practices for full-page forms:** - When using a full-page form use a single-column form layout to create a clear focused path   to complete for the user. - When using a full-page form avoid using multi-column layouts, which can cause users to skip   important fields, input data in the wrong field, or simply hinder efficiency which leads to   frustration or even abandonment. - When using a single form page, use no more than 10 form fields in the same viewport so that   users are not intimidated by seeing a long page filled with form fields and sections. Instead,   consider breaking the form up into logical sections and present them one at a time. ### Avoid using multiple column layouts ~~ Using single-column layouts creates clear paths for users. Multi-column layouts can inadvertently cause users to skip important fields, input data in the wrong field, or simply prevent efficient progress; all of which can lead users to abandon forms.                         ## Managing child objects within a form ~~ Applications often have scenarios where an object has multiple child objects, such as: - Creating an account with multiple contacts, each with their own contact detail. - Creating a cluster to perform a workload, dependent on setting and specifying   parameters for each resource composing the cluster. - Configuring permissions for a role, for which each permission has its own set of parameters. See managing child objects(/templates/forms/managing-child-objects) to see how a user can easily show and hide a child object's detail as needed. "},{"name":"Managing Child Objects","parent":"forms","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/forms/managing-child-objects.mdx","content":"   This pattern improves productivity by focusing a user's attention solely on the current object of interest, and uses collapsible objects to show or hide detail as needed. The intent is that collapsible objects reduce noise, clutter, and cognitive overload by hiding extraneous detail &mdash; and an easy means to view detail when needed. ## When to use ~~ Use when a user's primary task is to create or configure a parent resource, but creating, updating, or removing child objects is a sub-task. This pattern provides users easy control over displaying detail as needed. ## Anatomy ~~ The following illustrates the elements composing a child object in its collapsed and expanded states. View the examples(#examples) to see how child objects behave and are presented in a form context. ### Collapsed state ~~      |                 Label                  | Region             | Purpose                                                    |                  Required                   | Notes                                                                                                                                                                | | :------------------------------------: | ------------------ | ---------------------------------------------------------- | :-----------------------------------------: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |                 **1**                  | **Container**      | Identfies the child and controls the show detail behavior. |  | The entirety of the container is focusable and expands to show detail with a mouse click, Enter key, or Spacebar. The aria-label should read \"Show and edit detail.\" | |                 **2**                  | **Label**          | Uniquely identifies each child object.                     |  | Should be implemented as a semantically correct heading to allow screen reader users to traverse between children.                                                   | |                 **3**                  | **Expand icon**    | Visual treatment indicating show detail behavior.          |  | Icon name is \"FormDown\".                                                                                                                                             | |                 **4**                  | **Values summary** | A preview summarizing the object's detail.                 |                  Optional                   | Use \"truncate\" on Text to allow the summary to truncate if there is not sufficient width.                                                                            | |  | **Border**         |                                                            |  | Border is on top and bottom of child object. color=\"border-weak\"                                                                                                     | ### Expanded state ~~      | Label | Region            | Purpose                                                     |                  Required                   | Notes                                                                                                                                                                 | | :---: | ----------------- | ----------------------------------------------------------- | :-----------------------------------------: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1** | **Header**        | Identifies the child and controls the hide detail behavior. |  | The entirety of the container is focusable and hides detail with a mouse click, Enter key, or Spacebar. The aria-label should read \"Hide detail.\"                     | | **2** | **Label**         | Uniquely identifies each child object.                      |  | Should be implemented as a semantically correct heading to allow screen reader users to traverse between children.                                                    | | **3** | **Collapse icon** | Visual treatment indicating hide detail behavior.           |  | Icon name is \"FormUp\".                                                                                                                                                | | **4** | **Body**          | Flexible region for presenting an object's detail.          |  | Detail presentation may vary by the use case.                                                                                                                         | | **5** | **Remove button** | Removes/deletes the child from its parent.                  |               Case depending                | Always provide unless at least one child object is required by the parent. See Required children(#required-children) for detail. Icon name is \"Trash\". | ## Examples ~~ ### Optional children ~~ Use cases where child objects are not required by the parent may use a semantically correct heading, optional description, and a secondary button labelled with an add action to the form.      ### Required children ~~ For convenience, use cases where a parent can not be created without associating at least one child (e.g. creating a cluster) may present the first child object in its expanded state.      ### Remove all action ~~ When multiple children are associated with the parent, consider including a \"Remove all\" button to allow a user the ability to easily remove all associations with a single action.      "},{"name":"Global Header","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/global-header.mdx","content":"    {/* TODO replace with DS icon package when available */}       ## When to use ~~ For all products that exist within the HPE GreenLake ecosystem, Global Header with the HPE GreenLake badge should be used. If a product does not exist within the HPE GreenLake ecosystem, use the HPE Common Header and Footer Web Service(#hpe-common-header-and-footer-web-service). ## Implementing the Global Header ~~ ### For designers ~~ The Global Header is published as a Figma component in the HPE Design System Component Library. }   href=\"https://www.figma.com/design/HDckqS2MWhINfC8EIQPMV1/HPE-Design-System-Components-V2?m=auto&node-id=2860-270&t=9Kvc9d8gzK405Y1J-1\"   secondary /> ### For developers ~~ The HPE GreenLake Global Header is an innersource project that is currently in development by an HPE GreenLake engineering team. The header is delivered as a Web Component, which can be easily consumed by any UI framework. Documentation can be found on the HPE GreenLake Developer Portal(https://developer.greenlake.hpe.com/docs/greenlake/guides/internal/front-end/greenlake_header/). For additional questions, feel free to reach out on Slack in the #greenlake-header-support channel. ## HPE Common Header and Footer Web Service ~~ For HPE applications that exist outside of the HPE GreenLake ecosystem, the HPE Common Header and Footer Web Service provides a tunable, yet consistent header and footer. It is provided as a service and injected into your application at run-time.              ### Guidelines ~~ The HPE Common Header is a standardized header to be used across applications. HPE provides an implementation(https://h50007.www5.hpe.com/hfws-test-pages/common-hfws-test-page.php) to be referenced from your application. Both the header and footer are customizable, allowing consumers to choose various features to enable such as country selector, shopping cart, HPE passport login, privacy statement links, theme mode, and more. Each site or application will have different needs. Some header options may not make sense for some sites. The following sections will help you decide which options to include. ### What makes up the HPE Common Header? ~~ The full common header with all options enabled looks like this:      To configure what parts are shown in the common header for your site, go to the HPE Common HFWS test page(https://h50007.www5.hpe.com/hfws-test-pages/common-hfws-test-page.php?version=latest.r&cc_ll=us%2Fen&header_logo=&slim_footer=true&hide_search=true&hide_cart=true&hide_country_selector=true&hide_sign_in=true). There you can choose various options and hit `Submit`. The common header at the top of that page will change to include those options, and the code sample on that page will change to declare the chosen options as parameters in `` element that configures the header. You can then copy the URL from that `` and use it in the code sample at the top of this page to configure the common header and footer for your site. Let's take a closer look at each part of the common header and footer. #### App identity ~~ Most sites should choose the default which will be the HPE logo for regular mode or the HPE GreenLake logo for `console` mode. You can force it to use one or the other by specifically choosing HPE versus HPE GreenLake if needed. !HPE logo(/templateImages/globalheader-hpe.png) !HPE GreenLake logo(/templateImages/globalheader-greenlake.png) #### Header main navigation ~~ The main navigation in the center of the header provide marketing content. The links allow users to find HPE products, contact support and get more information about HPE. These should also typically be enabled for most sites. !Global Header Main Navigation example(/templateImages/globalheader-nav.png) #### Search ~~  The *Search* icon allows the user to search hpe.com.{' '} #### Shopping cart ~~  The *Shopping Cart* icon goes to the HPE shopping cart for buy.hpe.com. This should only be enabled for sites which have products or solutions for sale. #### Country selector ~~  The country selector allows the user to go to a language-specific version of hpe.com. This should be disabled for most sites since the link really only takes you back to hpe.com instead of staying on your site. #### Sign in ~~ !Sign In button(/templateImages/globalheader-sign-in.png) Sign in allows the user to sign in to their HPE Passport account for hpe.com. Enable this option if your site uses features that require a Passport login. #### Cube menu ~~  The *Cube Menu* allows access to HPE services available to the user such as HPE GreenLake and other Cloud console applications as well as general HPE links for HPE content like developer.hpe.com, education.hpe.com, etc. This menu should be enabled to allow access to other HPE sites and applications. #### Color scheme ~~ **Color Scheme** allows implementors to choose either a light or dark variant of the header/footer. The color scheme you choose should be harmonious with the primary background of your application's header and avoid stark contrast which interrupts a user's visual flow. If your application supports light and dark modes, consider setting the `color_scheme` parameter with a value of either `light` or `dark` in alignment with the user's preference. ### What makes up the HPE Common Footer? ~~ The common footer contains links for privacy information and various opt-out and choices required by European GDPR standards as well US and other privacy requirements. In general these links should be enabled for customer-facing sites. #### Privacy link ~~ The _Privacy_ link goes to HPE's Privacy Statement which explains how HPE manages and protects a users information and respects the relevant privacy standards like GDPR, APEC, etc. #### Terms of Use link ~~ The _Terms of Use_ link goes to the legal statement that governs the user's activity on HPE's websites. #### Ad Choices and Cookies link ~~ The _Ad Choices and Cookies_ link goes to the section of the _Privacy Statement_ that explains how cookies are used as well as how you can opt-out of targetted advertisements and analytics data such as Google Analytics and Adobe Analytics. #### Do Not Sell My Personal Information link ~~ The _Do Not Sell My Personal Information_ link goes to information on how to opt-out of any sale of personal collected by automatic data collection tools.         "},{"name":"Global Notifications","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/global-notifications.mdx","content":"    {/* height, width value chosen to best visually represent the example */}      ## When to use ~~ Global notifications are high-attention notifications used primarily for status updates on background processes and upcoming system changes and releases. Global notifications are used to showcase warning and critical statuses or informational alerts. Depending on the severity of the information, they may remain persistent across multiple sessions or be dismissible by the user. ## When not to use ~~ - Completion of tasks, such as long running or batch actions. - Success or failure confirmations. - Low-attention and low-severity information. For low-severity notifications that do not require user action or user attention such as confirmation receipts, instead use Toast Notifications(/templates/toast-notifications). ## Anatomy ~~      | Label | Region                       | Purpose                                                      |                  Required                   | Notes                                                                                                          | | ----- | ---------------------------- | ------------------------------------------------------------ | :-----------------------------------------: | -------------------------------------------------------------------------------------------------------------- | | **1** | **Icon or status indicator** | Indicates the status of notification                         |  | Warning, Critical, and Unknown status indicators(/templates/status-indicator) can be displayed. | | **2** | **Message**                  | Briefly describes the action, status, or additional context  |  | --                                                                                                             | | **3** | **Anchors (optional)**       | Used to direct users to additional detail or related content |                  Optional                   | --                                                                                                             | | **4** | **Close button**             | Dismisses the notification                                   |                  Optional                   | Critical notifications should not be dismissible.                                                              | ## Best practices ~~ - Since Global notifications take over the top of an interface and can be intrusive, they should be reserved only for important system generated updates. - Also when applicable, Global notifications should always have a relevant anchor(s) to direct users to further actions or to view more about the issue in full detail. - Do not use `onClose` when information is important and needs to remain persistent. Also, global notifications may remain persistent across multiple sessions until they are dismissed. ### Placement ~~ - Always located directly below the Global Header without a gap and should be implemented inline with content so no content or actions are obscured. - Can persist across multiple sessions until dismissed if necessary. ### Format ~~ - Only show one global notification at a time. - Global notifications should stay within the 192 character limit. - Long text is not truncated but instead will wrap on smaller screen sizes. - Anchors are left-aligned and will wrap alongisde the text. - Use only two or fewer anchors. - Utilize writing guide to stay within character count as well as the writing effective content guidance for appropriate language. ### Behavior ~~ - Never sticky and should scroll when there is other content. - The background spans the full width of the screen, but the content resizes alongside the Global Header. ### Things to avoid ~~ - Global notifications are not clickable. Instead use anchors to direct users to take further action or to view the issue in full detail. - Do not allow messages to exceed 192 characters. ## Variants ~~ ### Dismissible info notification ~~ Some possible use cases are when **new features are available** or a **new release is coming**. Informational notifications should be dismissible.      ### Dismissible critical notification ~~ One possible use case is **scheduled maintenance**. A critical status should be used and the notification should be dismissible.      ### Persistent critical notification ~~ One possible use case is when **platform access is unavailable due to the system**. A critical status should be used and should not be dismissible.      ### Dismissible warning notification ~~ One possible use case is when **subscriptions about to expire**. A warning status should be used and the notification should be dismissible.      ### Persistent warning notification ~~ One possible use case is a **session timeout**. A warning status should be used and should not be dismissible. The notification should also contain a relevant anchor to refresh.      ## Do’s and don’ts ~~                         "},{"name":"Index","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/index.js","content":"         export default Templates; "},{"name":"Inline Notifications","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/inline-notifications.mdx","content":"    Inline notifications are messages that appear near the content to which they are related. They may be task or system generated, communicating information such as significant status updates, alerts to success or failure of an action, or call attention to a new feature in which a user may be interested.      ## When to use ~~ Consider using an inline notification when presenting: - **Feedback** &ndash; Providing feedback to users about their actions. For   example, if a user submits a form requiring server-side validation, an   inline notification should be used to display and summarize form-level errors. - **Significant status updates** &ndash; Delivering significant status updates   about a task. For example, if a user initiated an asynchronous process such   as a device update, a notification might provide the status update upon.   \"Success - all devices have updated to the latest version.\" - **Promotions** &ndash; Calling a user's attention to such as new features, tips,   best practices, or other announcements. Use these sparingly. ## When to consider something else ~~ Inline notifications are quite flexible, however consider using the alternatives for the following scenarios: - **Low severity information** &ndash; If communicating low severity information   which does not need to persist or require the user's attention, consider using   a toast notification(/templates/toast-notifications). - **High attention information** &ndash; Consider using global notifications(/templates/global-notifications)   when communicating information which might result in loss of functionality or   requires the user's attention and/or action. Examples might include a system   outage, critical error, or expiring subscription or license. Global notifications(/templates/global-notifications)   are persistent and require user action to acknowledge or dismiss. - **Immediate feedback** &ndash; When providing immediate feedback to a user's   action, a variety of tools are likely more appropriate.   - When a user is awaiting a response after clicking an action button, use the     busy button(/components/button#busy-button) which provides in-progress and success animations. If the     response time exceeds expectations or the API call fails, then an inline     notification is appropriate for providing status updates.   - When validating form input client-side, use field-level form validation(https://design-system.hpe.design/components/textinput#validation)     when possible. If validation results in a form-level error(#form-validation), using an inline     notification is appropriate. ## Anatomy ~~      An inline notification consists of: | Label | Region                       | Purpose                                                      |                  Required                   | Notes                                                                                                                  | | ----- | ---------------------------- | ------------------------------------------------------------ | :-----------------------------------------: | ---------------------------------------------------------------------------------------------------------------------- | | **1** | **Icon or status indicator** | Indicates the status of notification                         |  | Normal, Warning, Critical, and Unknown status indicators(/templates/status-indicator) can be displayed. | | **2** | **Title**                    | Short, descriptive label identifying the notification        |                  Optional                   | Titles should only be used for inline notifications presenting page level summaries.                                   | | **3** | **Message**                  | Briefly describes the action, status, or additional context  |  | --                                                                                                                     | | **4** | **Link**                     | Used to direct users to additional detail or related content |                  Optional                   | --                                                                                                                     | | **5** | **Close button**             | Dismisses the notification                                   |                  Optional                   | Critical notifications should not be dismissible.                                                                      | ## Placement ~~ Inline notifications should be placed near the content to which they are related. - If the notification is related to the entire page, it should be placed underneath the page header. - If the notification is related to a specific element, section of content, or action, it should be placed above that element, section of content, or action. Examples of inline notifications relating to a specific section of content: - A notification indicating a new option or configuration is available would be appropriate to place at the top of the form. Examples of inline notifications relating to an action element: - A notification providing form-level validation should be placed above the submit button, between the last input and the submit button. See form validation example(#form-validation). - An notification indicating a service has an available upgrade should be placed above the launch action for that service. See promotion example(#promotion). ## Format ~~ - Titles and messages should be brief and clear. - Longer messages should wrap on narrower screens; they should not be truncated. - Anchor links may be used to provide additional information about the   notification. The links should immediately follow the message and should be   limited to no more than two links. ## Content guidelines ~~ Notifications reassure users that they are moving towards their goal. They should be relevant, timely, and informative providing assurance that their intended actions have been completed successfully. Or, if there is an issue, they should provide clear direction on how to resolve the issue. - **Relevant** &ndash; Notifications should be relevant to the user's current   task. - **Timely** &ndash; Deliver notifications in a timely manner and ensure they   are kept up to date with current status. - **Informative** &ndash; Messages shoud provide clear context and direction on   how to resolve any issues. Follow the voice and tone guidelines(/foundation/voice-and-tone) for writing   crisp and effective content. ## Behavior ~~ - Never sticky and should scroll when there is other content. - The width and resizing behavior of an inline notification should scale alongside   related content. For example, when placed below the PageHeader(/components/pageheader),   the inline notification should have the same width and responsive behavior as the   PageHeader. - Inline Notifications are not clickable. Instead use anchors to direct users to   take further action or to view the issue in full detail. - Do not place buttons within an inline notification. ## Use cases ~~ ### Status updates ~~ Inline notifications may be used to display normal, warning, and critical information. For example, a normal status might communicate a process is progressing without interruption, a warning status might communicate a resource is approaching a limit or threshold, and a critical status might communicate an action has failed.      ### Additional detail ~~ An inline notification may be used to provide additional detail or context, offering a helpful hint or tip, or providing a link to additional information. In this example, the page-level banner informs the user that an action is required on a set of resources and provides a way for the user to navigate to the affected section for more details. Click \"View details\" to see the section-level notification with additional information.      ### Promotion ~~ It is desirable for users to stay up-to-date on the latest version. Place the notification above the card action. In this case, placing the upgrade notification above the launch action informs the user of an action they might want to take prior to launching the application.      ### Form validation ~~ An inline form validation appears above the form's footer, providing a summary of any errors and steps to resolve them.      "},{"name":"Internationalization","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/internationalization.mdx","content":" ## Overview ~~ Internationalizion (I18N) and Localization (L10N) are important for web content and applications which are intended to be used by global users. It's even important for users in a single location who simply speak different languages. Internationalization is the process of tailoring application content to different languages or even locations. Localization is the process of translating content and behavior for a particular language or location. Even if you don't localize the messages and content of your application or site in a different language, users can benefit from your site being internationalized. Part of internationalizating is making your site recognize the locale set in the browser and format things like dates and times, currency and numbers specifically for that locale. Browsers have great built-in support for formatting that content appropriately for the locale. For example, a user in Australia or the United Kingdom may be perfectly happy with your content being in English but would much prefer any dates or times be presented with the day of the month before the month (28/06/2021 versus 6/28/2021). This is easy to do with `Date.toLocalDateString()`. ## Guidelines ~~ Depending on how your site or application is implemented, you'll need to pick an appropriate mechanism for choosing a language and locale and then provide content for the language and locale the user chose. You can provide a control in the application that allows the user to pick a language or simply try to use the preference set by the browser. Browsers include the user's locale preferences (if set) in header in the page request. Your application or site can choose localized content that best matches a locale from this list. Even if you don't have content for one of the preferred languages or allowed the user to set the language another way, it's best to still format dates, numbers and such given their preferred locale whenever possible. Once the site has chosen a locale from the user's preferences your site needs to provide the appropriate content given the selected locale. If you have implemented your application with Grommet, there are some default messages for components like Menu and FormField that will require localization. For example, the required message that accompanies a required FormField. ## Localizing Grommet ~~ Messages needed for Grommet components can be provided in a single place by using the `messages` property on the `Grommet` component itself.  If you're using other packages for internationalization like react-intl(https://www.npmjs.com/package/react-intl) or react-i18next(https://www.npmjs.com/package/react-i18next), it's even easier to provide a function which accesses the messages on demand by id. For `react-intl`:  For `react-i18next`:  Then just provide the Grommet messages along with your other localized messages. See the Grommet component documentation(https://v2.grommet.io/grommet) for details on what messages are needed. If needed you can also provide customized messages to the Grommet components which need them. The components which have localizable messages also support a `messages` property which accepts their specific messages. In most cases it easiest to provide the messages as above to the `Grommet` component instead. However, if you want to specify customized messages for a component in a few specific use cases you can certainly do that via the `messages` property for those components. ## Examples ~~ To see some example code and localization of a Grommet application take a look at the Grommet I18N example(https://github.com/grommet/grommet-i18n). It shows how you can use either `react-intl` or `react-i18next` with Grommet and includes a few localized language examples. "},{"name":"Lists","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/lists.mdx","content":"       ## Guidance ~~ The when, how, and why to use lists. ### About Lists ~~ HPE Design System list view templates are go-to patterns for displaying homogeneous data such as services, devices, users, and more. List views are optimized for scanability and reading comprehension. Each list item provides users focused information and identity labels to aid selection, decision making, and action. ### Usage ~~ A list is primarily used for: - Looking for specific data or information. When coupled with search or filters, it provides a quick means of scanning to find something. - Aggregating. When coupled with search or filters, it provides a summary of what items match the search/filter criteria and verification of the matching items. - Selecting multiple items to perform an action with them. ### Best practices ~~ - Be consistent with layout and visual treatments for all list items. - Keep list item descriptions brief and concise. - Use icons or images in list items to help draw attention and support scanning. - Maintain sufficient space between list items or consider using dividers between rows. - Sort lists in a logical order such as alphabetically, numerically, chronologically, or by user preference. ### Selection ~~ Use either selection of a whole list item or clickable areas on a list item (such as the action menu button). Do not combine these. Use hover states to indicate which kind of selection is being used. If the entire list item is clickable, the background of the list item receives the active background color and the cursor changes to a pointer hand. Otherwise, there is no hover state for a list item that is not interactive. If a list item contains an action button (or other clickable area), then that button respects its natural hover behavior. **Selection use cases include:** - A list with selectable items and a single action menu on the same page, allows for multi-selection of items - A list with selectable items and no action menu on the same page, allows an item to be selected. When an item is selected, a detail view can be shown with a single action menu for performing other things, such as powering on or off a device. Multi-select is not supported. - A list without selectable items, but an action menu on each item, allows an action to be performed inline on a single item. Multi-select is not supported. ### Action menu in list item ~~ - If space is limited, then don’t use an Action Menu in a List item (repetition of the Action Menu icon uses a lot of space) - If more context is needed to perform an action, the entire list row should be clickable and should route the user to a detail page for the List item. On this detail page, an Action Menu can be provided to allow the user to engage with the data. - If an action is simple and the results can be seen in the List contents (e.g. enable/disable), then use an Action Menu in a List item - If multi-select is required, then don’t use the Action Menu in the List item. ### Long lists ~~ - Add a sticky header for the list - Avoid using multiple vertical scrollbars - For really long lists (i.e. hundreds or thousands), consider limiting the number of items that can be shown at a time and provide some mechanism for accessing the rest of the items, such as infinite scrolling with lazy retrieval and rendering - Provide search and filtering capabilities to allow customers to quickly find specific list items - Avoid pagination. It tends to cause a more complicated user experience, especially when selection and/or automatic updating are involved. ### Responsiveness ~~ Examples are included for different screen sizes – Desktop, Laptop and Mobile. Lists should span the width of the container they are laid out in. ### Wrapping vs. truncation ~~ - Long data in lists should be wrapped, rather than truncated. - It’s about respecting the user’s content; that is, the words they type in. - We have customers who use long names (>100 chars) and they really need to distinguish one from the other. Truncating often ends up with multiple list entries that look the same, but really aren't. - It can also apply to automatically generated data, such as product names and descriptions. - If for some reason the “Do not truncate” rule must be broken, then a way must be provided to see the entire content. ### Accessibility ~~ Lists are usually easier to navigate than tables. When creating a design that uses a table, especially a simple table, consider whether a list could be used instead. **Keyboard navigation:** When list items are interactive, the Tab key can be used to focus on the List. The focus is always on the list itself and up/down arrow keys are used to move an indicator demonstrating which item will be clicked when the Enter key is pressed. **Screen readers:** Each list should also have a clear aria-label indicating what the list contains and a summary of the contents, such as how many items are in the list. ### List vs. table ~~ A List or a Table can be used to represent a set of related items, such as servers or devices or users. The one that is chosen will depend on the specific use cases that need to be supported. - If space is limited, a List uses less room than a Table - Use a List, If scanability is desired. It’s easier to read than a Table - If items can be selected using only the List contents, then use a List ## Variants ~~ Examples of common lists. ### Icon + name + option ~~ Single-line list with an icon, primary title, and a short status tag. In this example, the list items are clickable.      ### Name + description + option ~~ Two-line list with primary title, description, and a short status tag.      ### Name + option + action ~~ Single-line list with a primary title, short status tag and an action button.      ### Image + name + description ~~ Two-line list with an image, primary title, and a description.      ### Paginated ~~ With long sets of data, pagination can help to create a more efficient means of navigating to a specific item or range of items.      ### Item order ~~ List supports `onOrder` property which allows the user to reorder the items in a list by dragging items or pressing up and down controls. Choose `Actions -> Re-Order Items` to enable drag and drop of list items and move up/down controls. While in reordering mode, take note of how the row content is top-aligned. For **multi-line** list items like this use case, list items should be top-aligned for easy scanning across a row. To implement top-alignment for multi-line lists, use the prop `defaultItemsProp` on List:       "},{"name":"Matrix Navigation","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/matrix-navigation.mdx","content":" Matrix navigation lets the user determine their own path by jumping into particular areas of the screen, in no specific order. This allows them to directly access content of their choosing, without having to go up and back down to get there. ## When to use ~~ - Pages where the hierarchy isn't crucial to the user experience and where browsing is encouraged. For example, HPE.com(https://www.hpe.com/us/en/home.html) presents a wide variety of content and allows a visitor to choose their own journey, relevant to their needs. - User flows where a global navigation bar is visible at all times. This allows a user quick access to any of the site's primary hubs. ## Examples ~~ ### Within a music app ~~ The way a music application allows a user to choose their own journey is a great example where matrix navigation is employed. Songs, albums, artists, and playlists all interrelate, but are relevant to different users at different times. Applying matrix navigation provides a user easy access to all related content at any given time. On a song screen, they may access the album the song appears on, the artist who performed it, and/or the playlists to which the song has been added. No matter the user's current need, matrix navigation provides easy access and choice.      ### Within HPE app ~~ An HPE application example of a user Matrix Navigating to different access points which allows them to determine their own path.      "},{"name":"Navigation","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/navigation.mdx","content":"    export  export  Navigation is the overall structure providing users screen direction to complete a task logically and easily through a website or an application. Part of creating a seamless application or interface is creating an obvious flow from one view or interaction to the next. Think of navigation as a story map where you help guide your user through each process. ## Types of navigation ~~ Pages and content of a site or service are typically organized in an information hierarchy. Navigation provides various means for traversing this hierarchy depending on the user's task. There are 5 navigational directions in which a user can maneuver: **Drill Down** - Used when the user wants to view greater detail on the current topic than the current page displays. **Side-to-Side** - Used to visit to the next or previous sibling of the current page, typically when the user is scanning across similar items. **Reverse Navigation** - Used to return to the previous visited page using the browser's built-in back button. **Matrix** - Used to \"jump\" to a different place in the information hierarchy which isn't a direct parent or child of the current page. **Ascending Navigation** - Used to allow the user to move up the information hierarchy from a child page to its parent.  ## What makes navigation successful ~~ Users should always be able to tell where they are on a page, application or product and should be predictable as to how they can get to the next step or destination. A task has a start and an end point so it is important to keep the functionality or task(s) in mind when creating products with common user experiences and expectations. "},{"name":"Page Layouts","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/page-layouts.mdx","content":"     ## Elements of an app UI ~~ The User Interface (UI) for an HPE application consists of four building blocks: App Container, Global Header and Footer, Page, and PageContent.      1. **App container** - The container serves as the outer shell of a page UI. - This is the parent component containing all HTML elements within a grid. - Its responsibility is to organize each of the page components, how they   relate to eachother, the spacing between each, and how they respond at   various screen widths. 2. **Global header and footer** - The Global Header, also known as the HPE Common Header and Footer   Web Service(/templates/global-header), provides a tunable, yet consistent   header and footer to be used across all HPE applications. - No matter the screen size, the Global Header & Footer will always be full   width, occupying as much space as available. 3. **Page** - The Page component dictates the max width, padding, and alignment of its child PageContent(s). - It is responsible for the layout for the main content of a page. - Page `kind` can be Wide(#wide-default), Narrow(#narrow), of Full(#full). 4. **PageContent** - The PageContent contains the Page Header and any other content. - Its max width, padding, and alignment is determined by what Page `kind` it is in.            Coming soon:     - Page Content Layout Templates for Dashboards, Wizards, Lists and Tables. - Updated guidance on Page Headers(/components/header#page-header). ## Page and PageContent ~~ Page is the parent component that wraps around all content for a page. Page dictates what max width, padding, and alignment its child PageContent components should receive. PageContent contains the Page Header and any other content. To make the following functionality easy to implement, Grommet provides Page and PageContent components(/components/page).      ### Page kinds ~~ There are 3 Page kinds from which to choose, depending on the layout use case: Wide(#wide-default), Narrow(#narrow) and Full(#full). The Page `kind` determines the max width that PageContent can reach. In all cases, the minimum width of content is `336px`, after which horizontal scrolling is enabled. #### Wide (default) ~~ - This is the default width for the PageContent. - Using the \"wide\" Page scales the PageContent until a maximum width of `1536px`. - If the screen is larger than `1536px`, the PageContent will be center aligned and white space   will be displayed around the perimeter of the content.      **Use cases include:** - Dashboards - Tables - Lists - Charts #### Narrow ~~ - The \"narrow\" Page scales the PageContent until a maximum width of `768px`. - If the screen is wider than 768px, the PageContent will be center aligned   and white space will be displayed around the perimeter of the content.      **Use cases include:** - Wizards - Articles - Single task flows, such as forms - Admin and user settings #### Full ~~ - The \"full\" Page will automatically resize the PageContent to fill the   screen displaying it. - With the \"full\" option, if the screen grows wider than the available content, the   PageContent will be left aligned to the edge of the screen.      **Use cases may include:** - Charts - Maps - Tables #### Page padding ~~ Page padding is the left and right space between the page content and the screen edge. Wider padding is better for larger screens, as it creates more whitespace either side of the content. For smaller screens, less whitespace is appropriate in order to maximize the available screen real estate.      Responsive breakpoints(/templates/content-layouts#breakpoints) determine the amount of horizontal padding to be used at various screen widths. | Breakpoint | Pad (pixels) | | ---------- | -----------: | | **xsmall** |           12 | | **small**  |           24 | | **medium** |           24 | | **large**  |           48 | | **xlarge** |           48 | ### PageContent widths demonstration ~~ Open the following example in \"fullscreen mode\" and resize your browser window to see how each page content width's(#page-kinds) maximum width, contents padding, and alignment gracefully adjust across screens ranging from very narrow to very wide. {/* height value chosen to best visually represent the page layout diagram concept */}      ## Layouts for page content ~~ For specific guidelines and templates regarding page content, see Content Layouts(/templates/content-layouts).    }     alignSelf=\"start\"     reverse     size=\"large\"   />  "},{"name":"Popover","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/popover.mdx","content":"         ## Use cases ~~ ### Providing inline contextual help ~~ Contextual help, such as a term's definition or feature explanation, may be provided in a popover. In this case, an icon-only button(/components/button#button-with-icon) is used to indicated that additional help or information is available and serves as the trigger opening the popup.      ## Anatomy ~~      | Label | Region        | Purpose                              | Required | Notes                                      | | :---: | ------------- | ------------------------------------ | :------: | ------------------------------------------ | | **1** | **Title**     | Identifies the popover.               | Optional |                                            | | **2** | **Close button** | Closes the popover.                |    |  Closed by mouse-click and/or keyboard. A popover also closes by any clicks outside of the popover. | | **3** | **Body**      | Provides contextual information.      |    | May include non-text elements.             | | **4** | **Footer**    | Contains additional actions.          | Optional | May include anchors.                       |  ## Content guidelines ~~ Popovers should be: - Relevant: Content should relate to its trigger. - Non-crucial: Contents should not include crucial information or actions required to complete a task. - Short: Content should be concise to avoid overwhelming the user and occupying excessive screen space. Follow voice and tone(https://design-system.hpe.design/foundation/voice-and-tone) guidelines for writing effective content. Recommended practices: - Use `Paragraph/Small` and `Anchor/Small` to save space. - Avoid using titles if they do not provide additional context. - Use `Text` for the title instead of a heading. ## Accessibility ~~ Ensure accessibility by including an `a11yTitle` on: - Triggers without labels, such as icon-only buttons. - The Close button. Add `aria-haspopup` as well as `aria-controls` on: - The trigger in which opens the popover.    - `aria-haspopup` tells users that there is a pop-up associated with the element.    - `aria-controls` gives users more detailed information about which specific element will be affected when they interact with the element that has `aria-haspopup`. Popover should be operable by both mouse and keyboard events. Keyboard focus should be contained or \"trapped\" within the popover while it is open.  | Key   | Interaction                                                                                                      | | ----- | ---------------------------------------------------------------------------------------------------------------- | | **Tab** | Highlights interactive elements. Focus remains within the popover until it is closed. Once exited, focus returns to the trigger. | | **Esc** | Exits the popover at any time.                                                                                   | "},{"name":"Scrolling And Pagination","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/scrolling-and-pagination.mdx","content":"   export const ScrollingAndPaginationEmptyState = () => (   }   /> )"},{"name":"Selector","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/selector.mdx","content":"        ## Use cases ~~ ### Quick filtering ~~ Enables users to efficiently filter data using intuitive visual options, ensuring the presented view is both relevant and beneficial to the workflow.      ### Quick option selection ~~ Helps users quickly navigate through choices, ensuring they find the relevant options with ease, is commonly observed in support and onboarding processes.      ## Anatomy ~~      | Label  | Region                  | Purpose                                                                                      | Required | Notes                                                                                                                                                                    | | :----: | ----------------------- | -------------------------------------------------------------------------------------------- | :------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **1**  | **Container**           | Provides distinct boundary representing the option as a distinct choice.                     | Required | --                                                                                                                                                                       | | **2**  | **Selection Indicator** | Provides additional visual prominence and distinction between selected and unselected state. | Optional | For single it will be rounded for multiple squared off                                                                                                                   | | **3**  | **Identifier**          | Clearly labels what is being selected.                                                       |    --    | --                                                                                                                                                                       | | **3a** | **Icon**                | A unique icon that assists the user in identifying their desired selection.                  | Optional | Consider only using if the icon is well-known, recognizable, and understood, with correct a11yTitle.                                                                     | | **3b** | **Title**               | Clear succinct label.                                                                        | Required | --                                                                                                                                                                       | | **3c** | **Description**         | Provides additional detail if the title is insufficient on its own.                          | Optional | --                                                                                                                                                                       | | **4**  | **Body**                | Flexible content section which can be tailored to the use case.                              | Optional | May be used in addition to or in place of the Identifier. If used in place of the Identifier, it should satisfy the criteria of clearly labeling what is being selected. | ## Types ~~ ### Single select ~~ With single selection, only one option can be selected at a time. This is the default behavior. ### Multiple select ~~ With multiple selection, multiple options can be selected on at the same time. ## Accessibility ~~ Avoid placing interactive elements inside a Selector. This interferes with selection, breaks expected keyboard and screen reader behavior, and creates accessibility issues due to nested interactive elements. | Key             | Interaction                                                                |     | | --------------- | -------------------------------------------------------------------------- | --- | | **Tab**         | Used to navigate to the Selector group, and elements within the container. |     | | **Space/Enter** | Selects button with focus.                                                 |     | "},{"name":"Side To Side Navigation","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/side-to-side-navigation.mdx","content":"  ## When to use ~~ - Tabs to maneuver between relevant information within the same view. - Hamburger menus, sidebars, nav bars, wizards. - Switching from one service to another service. - Sidebar to navigate between pages. - Accordions to open a single panel to navigating between content within the same page. ## HPE local header example ~~ The HPE product’s local header which contains grouped, frequently used and top-level information. ## HPE Global Header example ~~ The Global Header, also known as the HPE Common Header and Footer Web Service, provides a tunable, yet consistent header to be used across all HPE applications. For more information, reference the Global Header page(/templates/global-header). ### Global Header guidelines ~~ - Global Header should be on all applications and websites - Allows users to move between top-level important destinations - Located at the top of all application and websites      ## Tabs example ~~ Tabs are a persistent horizontal bar that is used to navigate between related content without leaving the current page. See the Tabs page(/components/tabs) for more guidance and examples. ### Tab guidelines ~~ - Use only nouns or verbs for labels. - Use concise 1-2 word labels. - Use Title Case. - Avoid nested Tabs. - Organize information by priority and reading direction (e.g., right to left) of the user. - Ensure first tab is active when arriving at the page. - Keep users on same page when navigating between Tabs. - Use 5-7 Tabs max.       export  export  "},{"name":"Status Indicator","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/status-indicator.mdx","content":"  ## What makes up a status indicator? ~~ To effectively capture the user’s attention, status indicators are compromised of four different elements: - Colors - Icons - Shapes - Content To meet WCAG 2.1 compliance(https://www.w3.org/WAI/WCAG21/quickref/#status-messages), at least three out of four elements must always be present. ### Colors ~~ The colors used for Status are found within the HPE Design System Color guidance(https://design-system.hpe.design/foundation/color#status-colors). Additionally, always pair color with other elements as it is not widely accessible by everyone. These are some typical situations in which each color could be used: - A critical status used to alert a device failure - A warning status used to notify the user of an expiring license - A normal status used to communicate that an update has successfully completed - An unknown status used to indicate that a page cannot be found ### Icons and shapes ~~ Icons and shapes are used to represent the notification’s level of severity to users. Here is a set of icons and shapes created for Statuses found within the HPE Design System Icons(https://design-system.hpe.design/foundation/icons) page:  \\*\\*\\* Remember that WCAG 2.1 guidelines states that at least three out of four elements must be present, therefore, this set will not pass accessibility requirements if it is not paired with another element such as well-written and relevant content. ### Content ~~ **Do this:** - When constructing content be sure to use words, phrases, and concepts familiar to the user, rather than internal jargon. - Content should be natural and logical as if it were being used within a real-world setting. **Don't do this:** - Do not include overbearing or irrelevant information, especially important to note for low attention notifications. Try and keep status messages short and terse as to not overload the user with information. - Do not include run-on sentences. - Don't overuse the word \"please\". While \"please\" is allowed, starting every action phrase with the word \"please\" is not appropriate. In general, we should be limiting the use of \"please.\" For more detailed guidelines and examples, be sure to check out the HPE Design System Voice and Tone(https://design-system.hpe.design/foundation/voice-and-tone#case-study) page. ### Have more questions? ~~ Please be sure to send them over to the `#hpe-design-system` channel on Slack(https://slack-invite.grommet.io/)! "},{"name":"Toast Notifications","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/toast-notifications.mdx","content":"         ## Guidance ~~ Toasts are a low-attention notification mechanism primarily for use in confirming task receipt and completion. Toasts are intended to be non-intrusive and brief. A user must be able to read and comprehend a toast message in ~8 seconds before the toast automatically closes itself. Toasts are not a guaranteed delivery mechanism. They can easily be missed and are never shown while the user is focused on performing a task. Because there is no guarantee that a user will see a toast and because of the auto-close nature of toasts, they must never be used as a primary means of notification. A separate means (E.g., a notification center) to view active and historical task and alert information is needed. ### When should you use a toast notification? ~~ **Toasts should be considered when displaying these types of information to the user:** - Low attention messages that do not require user action - Singular status updates - Confirmations - Information that does not need to be followed up **Do not use toasts if the information contains the following:** - High attention and crtitical information - Time-sensitive information - Requires user action or input - Batch updates The main use case for toasts is messaging related to actions or tasks that the user has initiated. For example, confirmation that an action is being performed or notification that an action has completed. Outside of this limited use case, toasts should be used sparingly or replaced entirely by a different type of notification. In no way are toasts mandatory elements for a platform’s notification system. **Do not use toasts when the user is performing an action.** Toasts are only appropriate when the user is in a visualization page in the UI, but not when the user is interacting with a form or modal dialog to perform an action. Toasts that arrive while the UI is displaying a modal are not shown; they are dropped. **Do not use Toasts to indicate a process is \"In progress\". Toasts should indicate initiation/completion of a process.** Toast notifications are brief reassurances to a user that an action has begun or ended. They should indicate a process has successfully been initiated (status-good), or a process has ended with the appropriate status icon (good, warning, critical). Toasts should not be used to communicate that a process is \"in progress,\" rather it should assure the user the process has been initiated successfully, failed to initiate successfully, or has ended. ### Handling multiple toast notifications ~~ When there are multiple toast notifications (E.g., when two tasks finish at the same time), you should handle them by having only one toast present at a time. Once the first toast is dismissed or timed out, the next one should appear. Because toasts are never intended to be a primary notification mechanism, if a large number of toasts are queued (E.g., 100 tasks finish within a short timeframe), it is not necessary to show all of the toasts. One method to handle this might be to allow toasts to time out even if not being shown: show the first toast, but start timing all toasts. Once the first toast times out, show the next toast that has not timed out. ### Persistence ~~ Toasts are automatically dismissed after 8 seconds. Because they contain low-attention level information, they must not require user action other than the close button. Keep in mind the three line (8 second) limit for toasts because longer messages may not be read completely before automatically dismissing. ## Anatomy ~~  Diagram illustrating the four parts of a Toast notification. | Label | Region                       | Purpose                                                      |                  Required                   | Notes                                                                                                                  | | ----- | ---------------------------- | ------------------------------------------------------------ | :-----------------------------------------: | ---------------------------------------------------------------------------------------------------------------------- | | **1** | **Icon or status indicator** | Indicates the status of notification                         |  | Normal, Warning, Critical, and Unknown status indicators(/templates/status-indicator) can be displayed. | | **2** | **Title**                    | Short, descriptive label identifying the notification        | Optional                                            |   --                                                                                                                     | | **3** | **Message**                  | Briefly describes the action, status, or additional context  |  |    --                                                                                                                    | | **4** | **Close button**             | Dismisses the notification                                   | Optional                                            |    --                                                                                                                    | All toasts have a fixed width size at \"medium\" (384px) but the height is driven by the amount of content. ### Status indicator ~~ Avoid using toasts for very critical information or alerts. Users may accidentally dismiss or entirely miss a toast, so it is best to avoid using toasts for important information. Additionally, avoid using toasts, critical or not, if it requires a user action. The status indicators used for toasts are restricted to Normal, Warning, Critical and Unknown statuses. The crtical status should only be used to indicate a task completion that ended in an error and not for conveying critical or time-sensitive information to the user since a toast can be missed.  You can read more guidance about status indicators(/templates/status-indicator). ### Content (title + message) ~~ All toasts have content comprised of a message and an optional title. The title and message must be distinguishable from each other by the weight of the text. **1. Amount of information** Toast notifications should not have too much information inside of them. Additionally, each notification should only revolve around one idea or subject. Because a toast notification is only present on the screen for a short amount of time, a user using assistive technology needs to have an understanding of what information is in the notification. Therefore, the content should be minimal and direct. Because toasts are primarily used to convey information about tasks, the content must include enough context to be clearly understood. For example, what task is being performed, what resource is it being performed against, and what is the state of the task (E.g., starting, completed, failed, etc.). For best practice, keep the amount of information to three lines or under. This three line limit either can be a combination of both the message and the title or a three-line message. If the information is heavy and long, consider using a different type of notification other than toast. Never truncate text within a toast. The main point is to keep the information concise and clear. Do not add a title that is redundant with the message. If you can explain everything in a message, there is no need for a title. It is recommended to avoid using a title when possible to minimize the amount of bold text, which can hinder readability. Examples of message-only toasts: - Deleted cluster \"Joe's cluster\". - Update of \"Rule set 5\" completed. - Created Kubernetes cluster \"New York State Tax Authority\". **2. Interactive content** To remain compliant with WCAG 2.1 guidelines, avoid interactive elements, like links and buttons, inside of a toast. These elements may be difficult to access with a screen reader and other assistive technology. ### Close button ~~ The close button within a toast should be the only interactive element and is used if the user chooses to dismiss the toast before it automatically dismisses itself. To clarify, the toast itself is not dismissable on any click; rather it is dismissed when the close button is activated. This is to avoid any confusion over what is interactive within a toast. ## Accessibility ~~ Toast notifications should be read aloud when they appear on a user's screen. To accomplish this, toasts are given the role of \"log\" with default aria-live set to \"polite\". The \"log\" role is used for live regions where new information is presented to a user in a meaningful order, and the \"polite\" attribute allows for a non-obtrusive way to notify screen readers of a new toast in a timely manner. ## Placement ~~ Follow these placement guidelines for Toast Notifications: - Place them either top-center or top-right of the screen. If badging is being used, toasts should be placed underneath it. Note that top-right placements may negatively affect those using screen magnifiers. - Quickly fade in on arrival and fade out when dismissed. - Do not obscure critical information or any primary action elements. - Toasts are not focused on and do not appear when a user is within a Modal or Wizard since they do not carry high attention information. - Reminder that toasts should not be used to convey a batch of information as this would quickly hinder their visibility and cause notification fatigue. - Consider incorporating a Notification Center where a user can access full information about tasks and asynchronous events/alerts. ### Top-right aligned toast ~~      ### Have more questions? ~~ Please be sure to send them over to the `#hpe-design-system` channel on Slack(https://slack-invite.grommet.io/)! "},{"name":"User Feedback Collection","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/user-feedback-collection.mdx","content":"    export  Feedback collected from users provides qualitative insights into users' perception of ease-of-use and value delivered. Qualitative measures compliment quantitative usage and interaction data to form a well-rounded analytic picture of the customer experience.      ## When to use ~~ When and where to collect feedback from users should be a collaborative effort working with the HPE GreenLake Experience Management COE. This team will work with you to           // The properties within the surveyValues object will be specific to your   // product and instance within the product. These will be specified   // when working with the HPE GreenLake Experience Management COE team.    ``` **Notes**: - The structure of the `surveyValues` object needs to exactly match the fields associated with a given survey. These fields (QID-type fields) are NOT free-form entry fields and will be ignored if they do not match the survey in question. They cannot be shared between surveys and may differ even for two identical surveys. - Review the response structure within the XM tool and validate they survey field structure using a tool (like Postman) and verfiy that all responses are collected correctly. ## Examples ~~ ### Solicited feedback ~~ Solicited feedback is an active method of asking users for their opinions and perspectives. A feedback questionnaire is presented after a user has completed a task or consumed a piece of content. Solicited feedback should not interrupt or impede a user from completing their intended objective. #### Task flow in center layer ~~ Click on \"Power on 1 device\" to see the feedback questions presented at the completion of the power on task flow.      ### Unsolicited feedback ~~ Unsolicited feedback provides users the opportunity to ask questions, provide ideas, or make recommendations. Acting similar to a “suggestions box,” this mechanism is placed in a persistent location, such as within an app-level menu or embedded with the application's page layout. "},{"name":"Wizard","parent":"templates","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/templates/wizard.mdx","content":"       ## When to use ~~ Use a wizard when your form involves multiple steps. This makes the experience more manageable for the user and helps to eliminate error by validating inputs as the user progresses. ## Anatomy ~~      1. **Wizard header**: This region identifies the task flow and provides the wizard's controls. The wizard header spands the full width of the viewport.    - **a. Wizard title** (required): A short, descriptive title identifying the wizard.    - **b. Previous step button** (required): A button allowing the user to return to the previous wizard step. This button is positioned similarly to a browser's back button and is aligned to the left side of the wizard's header. It should appear on all steps except the first.    - **c. Cancel button** (required): A button allowing the user to leave the wizard. When clicked, a confirmation modal will appear. This button is aligned to the right side of the header. 1. **Step identifier:** This region provides the user with information regarding the current step.    - **a. Step title** (required): A short, descriptive title uniquely identifying the step.    - **b. Step summary** (optional): A summary of where the user is within the wizard, formatted as \"Step X of Y\".    - **c. Step description** (optional): Any additional context or information about the current step. 1. **Step inputs**: Form inputs for the current step. 1. **Step footer**: The footer contains a primary action button to advance to the next step or finish the wizard. The footer should remain a consistent width across all steps of a wizard so that the next button is placed consistently for the user. Its width should match the width of the widest step.    - **a. Next/finish button** (required): A primary action button that allows the user to advance to the next step or finish the wizard. This button should be aligned to the far-right side of the footer. 1. **Cancel wizard modal** (required), displayed when \"Cancel\" button is clicked: A center modal that provides double confirmation before the wizard is exited and cancelled. ## Guidance ~~ A wizard should always appear as a fullscreen modal. ### Header and footer behavior ~~ The Wizard header should always be sticky so that user has persistent access to previous step and cancel actions. The footer, when there is sufficient height on desktop, should be placed directly below the inputs. On mobile, or when there is not sufficient height to show all inputs, the footer should be sticky on the bottom of the window. ### Providing guidance for a form step ~~ It is helpful to provide concise and clear descriptions for each step of the form. Keep each step simple and in chunks easy enough to fit on a single page. This helps the user have confidence in how to fill out the form correctly. ### Indicating progress ~~ It is important to give the user an indication of where they are within the form. This should be done by indicating the total number of steps and the user's current position (i.e. \"Step 1 of 3\"). ### Validation ~~ Validation should occur within each step of the wizard. If there are any errors with the inputs in the current step, the user should not be able to advance and errors should be displayed. Error display should follow conventions established by Form(/templates/forms). ### Summarizing what was accomplished or configured ~~ The final step of a wizard should summarize what has been accomplished or configured. This summary is displayed to the user prior to form submisson. In order to complete the wizard, the user will click a submit button provided on this screen. Examples of submit button labels include \"Finish Setup\", \"Finish Configuration\", etc. ### Cancellation ~~ It is important to provide the user with an option to \"Cancel\" or exit the wizard. Place this button on the upper right hand corner of the wizard. When clicked, the \"Cancel\" button should: - Open a layer that allows the user to confirm they want to cancel. - Provide two buttons with a clear binary choice (Example: yes or no) and a secondary term that reaffirms the action (Example: stay or exit) - The Primary Button should be used to confirm cancellation (Example: \"Yes, exit\") and a Secondary Button should give the option to return back to completing the wizard (Example: \"No, stay\"). ### Single column vs. two column wizards ~~ If guidance can be provided in a short description, use a single column wizard. When additional guidance is required for the form or content of the wizard, you might consider a two-column format. **If using a single column format:** - Center the \"Next\" or submit button directly under the form inputs. **If using a two column format:** - Wrap guidance in a containing box with different background color than the page, so that it is visually separate from form inputs. - Center the \"Next\" or submit button underneath both the form inputs and the guidance. - On desktop, place the guidance to the right of form inputs. - On mobile, place the guidance above form inputs. ## Variants ~~ Common wizard variants. ### Two-column wizard ~~ When additional guidance is necessary, use a two-column wizard. Click \"See Fullscreen\" for a more realistic experience.      "},{"name":"Whats New","parent":"pages","path":"/Users/archibeq/Documents/hpe-design-system/apps/docs/src/pages/whats-new.mdx","content":"  {/* NOTES for content editors modifying this file */} {/* - See editing markdown instructions(https://github.com/grommet/hpe-design-system/blob/master/apps/docs/README.md#editing-whats-new-page). */} {/* - Helpful markdown syntax reminders with this markdown cheatsheet(https://www.markdownguide.org/basic-syntax/). */} {/* - Reference the \"New Entry Template\" provided below for the markdown used to create new \"What's New\" entries. */} # What's New ~~ Track Design System announcements, new template patterns, guidance, and released components. ## Opportunities to engage ~~ **Slack** &mdash; Have questions? Want feedback? Can't find something? The hpe-design-system channel(https://hpe.slack.com/archives/C04LMJWQT) allows you to get prompt responses from HPE Design System team members as well as designers and developers consuming the design system throughout HPE. **Office hours** &mdash; Held weekly on Thursdays, 8:00 AM PDT / 8:30 PM IST. Office hours are a flexible, easy-going forum to bring questions, discuss, provide point of view, or simply observe. It's a great opportunity for us all to learn, grow, and contribute to the HPE Design System. Open to all. Contact HPE Design System team(mailto:designsystem-staff@hpe.com?subject=HPE%20Design%20System%20office%20hours&body=I%20would%20like%20to%20be%20invited%20to%20the%20HPE%20Design%20System%20office%20hours.) for a calendar invite. {/* BEGIN: New Entry Template -- Markdown syntax and layout for creating new entries */} {/* ## Week of entry in Month Days, Year format */} ~~ {/* ### Feature 1 */} ~~ {/* - Item 1 */} {/* - Item 2 */} {/* - ... */} {/* - Item n */} {/* ### Feature 2 */} ~~ {/* - Item 1 */} {/* - ... */} {/* - Item n */} {/* ... */} {/* ### Feature n */} ~~ {/* - Item 1 */} {/* - ... */} {/* - Item n */} {/* END: New Entry Template */} {/* BEGIN: What's New Entries */} ## April 2023 ~~ ### Grommet April release ~~ Grommet v2.32.0 is here! This release includes new Button busy and success props(https://storybook.grommet.io/?path=/story/controls-button-busy--busy&globals=theme:hpe) to support an animation while Button is in a busy or success state. Also included are accessibility enhancements, improvements for using grommet in a shadow root, bug fixes for DataTable and SelectMultiple and lots more! Checkout the full release notes(https://github.com/grommet/grommet/releases/tag/v2.32.0). ### Brand refresh ~~ - All \"brand refresh\" stylings have been applied to all components and are now available within Figma(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=0%3A1&t=ViKCtdnRM2CUkNZI-1). - To view details on how to migrate to the new theme or troubleshoot common Figma problems, check out the Figma migration guide(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=2%3A4&t=ViKCtdnRM2CUkNZI-1). - For devlopers, here's the grommet-theme-hpe migration guide(https://github.com/grommet/grommet-theme-hpe/wiki/Migrating-from-HPE-Theme-4.x-to-5.x). ### Data ~~ \"Data\" is a new category of Grommet components which make is easy to display, manage, and interact with data collections. These components are currently in beta. Check them out and let us know what you think! - Added DataTableGroupBy(https://v2.grommet.io/datatablegroupby). ### Templates, patterns, and guidance ~~ - A new pattern for displaying empty states(/templates/empty-state) is now available. ### Figma component enhancements ~~ - Figma Tag component(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=9685-105828&t=bKVTr3ZekzMiijnL-4) now supports t-shirt sizes. - Colors for placeholder and disabled text have been corrected for the following Figma components. Previously, the placeholder text was xweak. It has been updated to use the correct color, text-weak to meet proper color contrast ratios.   - Checkbox(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=2940%3A62424&t=ViKCtdnRM2CUkNZI-1)   - CheckboxGroup(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=5732%3A78041&t=ViKCtdnRM2CUkNZI-1)   - RadioButton(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=3520%3A83485&t=ViKCtdnRM2CUkNZI-1)   - RadioButtonGroup(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=5733%3A92878&t=ViKCtdnRM2CUkNZI-1)   - TextInput(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=2%3A8&t=ViKCtdnRM2CUkNZI-1)   - Layer(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=5735%3A85900&t=ViKCtdnRM2CUkNZI-1) ### Learn ~~ - Added Grid Fundamentals: Part One(/learn/grid-fundamentals-part-one). ## March 2023 ~~ ### Brand refresh ~~ `grommet-theme-hpe` v5 was published. **New** - **Brand-refresh styles for HPE product experiences** - From updated buttons to refined typography, v5 supports HPE's   brand strategy by delivering the latest brand expression for HPE products. - **Enhanced support for marketing experiences** - In addition to updated styles for product experiences,   v5 of the theme also introduces a special extension of the HPE theme tailored for HPE marketing sites.   This release features scaled-up typography aiding discovery and story-telling showcasing how HPE helps   customers in their edge-to-cloud journey. For example, the HPE Design System site now uses the “web type scale,”   but uses the “product type scale” in all inline product examples. **What you can do right now** - **What, why, and how** - Read the HPE theme guide for Migrating from v4 to v5(https://github.com/grommet/grommet-theme-hpe/wiki/Migrating-from-HPE-Theme-4.x-to-5.x) to understand what styles were updated and how they align to the latest brand direction. - **Get the new theme** - Upgrade to the latest versions of `grommet-theme-hpe`, `grommet`, and `grommet-icons` to start building with all the capabilities of the new theme. **Coming soon** - **Updated Figma components** - The HPE Design System Figma library is in the process of being updated to reflect all of the latest changes. These updates will be published in the coming weeks. - **Share-out invites** - Be on the lookout for an invitation to learn more about the motivations driving the brand-refresh, how the updated HPE theme supports it, a tour of the changes you will see, and tips for how to get up to date with the latest styles. Please share any comments and reach out with any questions! ### grommet v2.31.0 ~~ This release includes the addition of pad property on Button, improved responsive typography behavior of PageHeader, as well as fixes to CheckBox, FormField, and SelectMultiple. **Features in beta** Grommet community, Data and related components(https://v2.grommet.io/data) are features currently in beta and provide ways to conveniently present, manage, and manipulate a variety of data collections. Please check them out and share your thoughts and feedback. For full details, check out the release notes(https://github.com/grommet/grommet/releases/tag/v2.31.0). ### Data ~~ - Implemented Filtering examples(/templates/filtering) using new Data components. - Implemented DataTable Customization example(/templates/datatable-customization) using new Data components. ### Templates, patterns, and guidance ~~ - Added list & table templates(https://www.figma.com/file/4rdBkUlHd5MCVq3hvUOXHd/Page-Layouts?node-id=5639%3A166208&t=IC28JVzDR8NsAZ30-1) to Figma. - Added detail/object view templates(https://www.figma.com/file/4rdBkUlHd5MCVq3hvUOXHd/Page-Layouts?node-id=5768%3A218145&t=IC28JVzDR8NsAZ30-1) to Figma. - Updated tabs styling(/components/tabs) based on new brand refresh changes. - Layers now have overflow property(/templates/filtering) to ensure that the content does not exceed the container, making it easier for user to view all filter content. - For accessibility, card titles(/templates/filtering) now semantically correct heading levels instead of text. - For accessibility, changed DateInput(/components/dateinput)'s month and year to use Text instead of Heading. ## February 2023 ~~ ### Grommet v2.30.0 ~~ This release includes enhancements to Button, Layer, Skeleton, and TextInput as well as fixes to Data, DataTable, DataFilters, DataSearch, DataSort, Drop, DropButton, Layer and WorldMap. For more details, see the release notes(https://github.com/grommet/grommet/releases/tag/v2.30.0). ### Figma component enhancements ~~ - **Icon swapping** - Now, when you do an icon instance swap, the icon's color will automatically apply the correct color when changing between states. - DateInput component(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=444%3A9254&t=VBDzNSHpjrMyywm1-1) now supports days of the week. - **Page templates** - Home page Figma template has been completed. ### Learn ~~ The HPE Design System now features learn(/learn) which is a new home to tutorials and how-to guides. This section of the site will be populated with resources to help designers and developers learn implementation approaches, best practices, and level-up their skills. - Published The Box Model: Part One(/learn/the-box-model-part-one) ## January 2023 ~~ ### Grommet v2.29.0 ~~ NEW StarRating(https://v2.grommet.io/starrating) & NEW ThumbsRating(https://v2.grommet.io/thumbsrating) input components. NEW BETA components (the API of components in beta are subject to change): - Data(https://v2.grommet.io/data) - acts as a provider to manage search and filter capabilities on data collections. - DataFilter, DataFilters, DataSearch, DataSort, DataSummary, Toolbar - components that allow you to further customize how search and filter render in your layout - Cards(https://v2.grommet.io/cards) - allows you to render a set of cards within Data to leverage Data’s turnkey search and filter capabilities   Feel free to check them out and send us your feedback. Stories can be found under Data folder in storybook This release includes enhancements to Box, Form, FormField, as well as fixes to Collapsible, DataTable and Select. For more details, see the full release notes(https://github.com/grommet/grommet/releases/tag/v2.29.0). ### Templates, patterns, and guidance ~~ - Collecting feedback from users(/templates/user-feedback-collection) pattern was added to support collection of customer analytics and insights from within product experiences. - Skeleton(/components/skeleton) component supporting data loading states is now available. ### Figma component enhancements ~~ - HPE Global Header(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?t=rcDz07wh34Xxtsft-0) component is now available. - **Refactored components:**   - CheckBox(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=2940%3A62424&t=da2J4GDdKdAi7PIN-1)   - CheckBoxGroup(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=5732%3A78041&t=da2J4GDdKdAi7PIN-1)   - RadioButton(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=3520%3A83485&t=da2J4GDdKdAi7PIN-1)   - RadioButtonGroup(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=5733%3A92878&t=da2J4GDdKdAi7PIN-1)   - Tip(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=5248%3A73430&t=da2J4GDdKdAi7PIN-1)   - Feedback(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=5554%3A77765&t=da2J4GDdKdAi7PIN-1) ### Learn ~~ - Added a How to add search and filter to DataTable with Data(/learn/how-to-add-search-and-filter-to-datatable-with-data?q=data) how-to guide. ## December 2022 ~~ - **Layer**   - New refactored Layer components are available in Figma(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=5735%3A85900&t=da2J4GDdKdAi7PIN-1) including center layers, side drawers and fullscreen layers. - **Feedback Component**   - Completed two variants of Feedback(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=5554%3A77765&t=da2J4GDdKdAi7PIN-1) which can be found in Figma. For flexibility, we’ve also implemented a variant using slots. - **Managing Child Objects**   - Added an example and guidance(/templates/forms/managing-child-objects?q=mana) on how to manage child objects within a form. - **Card**   - We’ve added new Card examples and guidance(/components/card?q=ard) on our site. - **Menu**   - New refactored Menu component(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=6062%3A109930&t=da2J4GDdKdAi7PIN-1) available in Figma. ## November 2022 ~~ - **Avatar**   - We've added Avatar guidance and examples(/components/avatar) and Figma component(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=3027%3A61406&t=CpM6ERbKsy0lCo2p-1). - **Wizard**   - We've added Wizard anatomy(/templates/wizard#anatomy) guidance. - **Global Header**   - Refactored Figma component(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=3028%3A58404&t=wuQ19EerOmEErTIk-1). - **SelectMultiple**   - Refactored Figma component(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=4464%3A103743&t=wuQ19EerOmEErTIk-1). ## October 2022 ~~ - **HPE Brand Refresh**   - We've published a new grommet-theme-hpe(https://github.com/grommet/grommet-theme-hpe/releases/tag/v4.0.0) with the latest HPE brand styling.   - We've added distinctive brand assets(/foundation/distinctive-brand-assets) guidance and examples.   - We've added new Button kinds for call-to-action buttons(/components/button#cta-button), 'cta-primary' and 'cta-alternate', plus guidance for when and how to use them(/components/button#when-to-use-a-cta-button).   - Aligned with Brand guidance, we've updated the capitalization guidance(/foundation/voice-and-tone#capitalization) towards using mostly sentence case. - **Header**   - We've added guidance on various types of Headers(/components/header#when-to-use). - **CheckBox**   - We've enhanced guidance for using a CheckBox outside of a FormField(/components/checkbox#checkbox-outside-of-formfield).   - Refactored Figma component(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=2940%3A64707&t=wuQ19EerOmEErTIk-1). - **Menu**   - We've updated the styling for grouped Menu items(https://www.figma.com/file/DyFWlzLBUtK5KH5jJhwoCB/HPE-Menu-Component?node-id=606%3A1489&t=5s9S2IY0lW34lv9J-0). - **Feedback**   - We've added an enhanced Feedback mechanism on the HPE Design System site. Hint, there's a button in the bottom right corner on every page. Check it out! This is integrated with Qualtrics. - **Button**   - Refactored Figma component(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=4510%3A82658&t=wuQ19EerOmEErTIk-1). - **DataTable**   - Enhanced customization in Figma(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=2915%3A60783&t=wuQ19EerOmEErTIk-1). ## September 2022 ~~ - **Card**   - We've enhanced Card(/components/card) guidance and examples.   - We've added call to action card(/components/card/call-to-action-card) and navigational card(/components/card/navigational-card) examples and guidance. - **SelectMultiple**   - We've added a SelectMultiple component(/components/selectmultiple) which improves the display and interaction behaviors for selecting multiple options from a select list. ## August 2022 ~~ - **Form**   - We've added guidance on where to present a form(/templates/forms#where-to-present-a-form).   - We've added examples and guidance for full-page forms(/templates/forms#full-page-forms). - **DataTable**   - We've created a Figma component(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=2915%3A56106&t=ZMldJMLzCjzI8VxQ-0) for DataTable customization. - **Analytics**   - We've made it easier to collect web analytics data (e.g navigation, layer and form interactions, and more) via `onAnalytics` and the Grommet component. ## July 2022 ~~ - **Form**   - We've added guidance on accepting Terms and Conditions(/templates/forms#terms-and-conditions). - **TextInput**   - Refactored Figma component(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=1249%3A23170&t=wuQ19EerOmEErTIk-1). - **DateInput**   - Refactored Figma component(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=1340%3A29596&t=wuQ19EerOmEErTIk-1). - **FileInput**   - Refactored Figma component(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=387%3A1967&t=wuQ19EerOmEErTIk-1). - **Search**   - Refactored Figma component(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=1419%3A27237&t=wuQ19EerOmEErTIk-1). - **List**   - Refactored Figma component(https://www.figma.com/file/5uOrsL2qk8XwwH8C1ZpDb6/HPE-Design-System-Components?node-id=1317%3A23894&t=wuQ19EerOmEErTIk-1). ## June 4, 2022 - July 8, 2022 ~~ ### Stay Current with the Latest Changes ~~ - **Tabs**   - We've enhanced responsive behavior and updated the guidance(/components/tabs#responsive-behavior). - **Menu**   - We've added item grouping and added guidance(/components/menu#organizing-menu-items) for when to use it. ### Roadmap Updates ~~ - **Figma Component Refactoring**   - We're just about ready to announce the first version new input components. Thanks for all of the help we received. - **Multi-Select**   - We've built several UI prototypes to gather detailed feedback and flesh out accessibility aspects. Thanks for all of the feedback we've received so far. - **User Feedback and Analytics**   - We're working on components for collecting feedback from users. - **Adoption Scorecard**   - We've begun testing out the details and refining the process via evaluating the latest HPE GreenLake COM UI. ## April 11, 2022 - June 3, 2022 ~~ ### Stay Current with the Latest Changes ~~ - **Page Header**   - Figma(https://www.figma.com/file/BHp0KrOcPvbnzNyshfHkd8/HPE-Page-Header?node-id=734%3A40546) and Grommet(https://v2.grommet.io/pageheader) components are now available along with design guidance and code examples(/components/pageheader). ### Roadmap Updates ~~ - **Figma Component Refactoring**   - We are currently working on input components. Thanks for all of the help we've received from folks across HPE in this effort. - **Multi-Select**   - Wrapping up basic anatomy and focusing on how to represent the current selection. - **Adoption Scorecard**   - Working on initial draft version of a spreadsheet to evaluate how well products and services are aligned to the HPE Design System. Look for more to come in this area soon. ### Latest Releases ~~ - **grommet v2.24.0** + **grommet-theme-hpe v3.1.0**   - Added a NEW **PageHeader** component.   - List now supports `disabled` items and will indicate which item is currently active via `onActive`.   - For more details, see the release notes(https://github.com/grommet/grommet/releases/tag/v2.24.0) - **grommet v2.23.0** + **grommet-theme-hpe v3.0.1**   - Support for ReactJS v18   - `sticky` Header   - Accessibility improvements including List and Menu `a11yTitle`, Video scrubbing via the keyboard.   - DataTable now supports `disabled` rows and allows combining `onClickRow` with `onSelect`.   - For more details, see the Grommet release notes(https://github.com/grommet/grommet/releases/tag/v2.23.0) and Theme release notes(https://github.com/grommet/grommet-theme-hpe/releases/tag/v3.1.0). ## April 4, 2022 - April 8, 2022 ~~ ### Latest Releases ~~ - **grommet-theme-hpe v3.0.0** - This release provides additional responsive breakpoints helping deliver the optimal user experience for HPE customers.   - Gain precise control over how page layouts respond and adapt.   - Implement grid layouts, such as a dashboard of cards(/templates/dashboards#two-column-dashboard), which gracefully adapt and flow.   - Is your application currently consuming Grommet's ResponsiveContext? If so, the additional breakpoints are breaking changes from v2 and may require minor code changes to ensure backwards compatibility. A migration guide(https://github.com/grommet/grommet-theme-hpe/wiki/Migrating-from-HPE-Theme-2.x-to-3.x) is available to make this a smooth process. ## March 9, 2022 - April 1, 2022 ~~ ### Communications ~~ - To help scale and accelerate Design System feature delivery, we are actively working on a process for receiving design contributions from members outside of the Design System core team. Initially, designers will be able to leverage Figma's Branching feature(https://www.figma.com/best-practices/branching-in-figma/) to contribute small fixes and medium enhancements while the process is tested and refined. Stay tuned! ### Roadmap Updates ~~ - **Page Layouts**   - Updated the Page Layouts Figma file(https://www.figma.com/file/4rdBkUlHd5MCVq3hvUOXHd/Page-Layouts?node-id=2891%3A21273) to reflect new Page component in Grommet. Page component guidance and examples coming soon to the Design System site. - **Global notifications**   - Guidance and examples for Global notifications(/templates/global-notifications) are now available.   - Styling is supplied by the HPE Theme and available on `grommet-theme-hpe v2.4.0`. - **Page Header**   - Began work to standardize Page Headers(https://www.figma.com/file/BHp0KrOcPvbnzNyshfHkd8/HPE-Page-Header?node-id=84%3A2940) across HPE applications. The scope of this work is to define how page titles, page level actions, and contextual information should be displayed. - **Tabs**   - Began working with stakeholders to understand uses cases and standardize scenarios with more than 5 Tabs across HPE applications. The scope of this work is to define how to visually display tabs across different resolutions. ### Stay Current with the Latest Changes ~~ - Want to know how to create dynamic, responsive layouts? Gain a better understanding Grid's capabilities and how to master this component(/components/grid#grid-properties-and-key-concepts) to create dynamic layouts. - Added an example of a Form with a single required FormField(/templates/forms#single-required-formfield) on the site. - FileInput - The remove file action(/components/fileinput) is now represented by the Close icon instead of the Trash icon. This aligns the icon more closely with the action it is representing (the Trash icon was associated with destroy/delete/unrecoverable, which is not the case in removing a file from a FileInput). This change has been made in the Figma component and is available in the grommet-hpe-theme v2.4.0. - **Figma changes**   - Improved auto layout behaviors in Select(https://www.figma.com/file/fZJdRcNrvZ1JjdPRYHpFFU/HPE-Select-Component?node-id=0%3A1), TextInput(https://www.figma.com/file/E40Oo2MpdRNMyVaJqfJ0Wd/HPE-Text-Input-Component?node-id=0%3A1), and TextArea(https://www.figma.com/file/evH1LQewFPc8Y2fteywMxM/HPE-Text-Area-Component?node-id=0%3A1) which resolves resizing and wrapping issues in Figma.   - Tabs(https://www.figma.com/file/Kp4dWyhUTnKIJ1Cg5CoL9o/HPE-Tabs-Component?node-id=208%3A0) - Previously in Figma you were not able to swap between variants, you can now swap to the selected instance without any issues. ### Latest Releases ~~ - **Grommet v2.22.0** - Release includes NEW Page and PageContent components which allow for consistent page layout implementation across HPE applications, as well as accessibility improvements to RangeInput, Menu, and Select components. Full details about this release are available in the Release Notes(https://github.com/grommet/grommet/releases/tag/v2.22.0). - **grommet-theme-hpe v2.4.0** - Some features of the release include:   - NEW Banner Notifications styling.   - NEW Page component styling.   - Changed value of text-weak to pass color contrast requirements and can be used for text when a more subtle treatment is desired. text-xweak is recommended for disabled text.   - For a more detailed look at these enhancements, check out the release notes(https://github.com/grommet/grommet-theme-hpe/releases/tag/v2.4.0). ## February 14 - March 4, 2022 ~~ ### Communications ~~ - **Office Hours** - We have combined our two office hours into one which will be held every Wednesday, 10:00 PM IST / 8:00 AM PST. This office hours is open to all. Contact Kamlesh Thakur(mailto:kamlesh.thakur@hpe.com), if you would like a calendar invite. ### Roadmap Updates ~~ - **Page Layouts**   - Added Page component in Grommet which makes implementing page layout guidance and page widths(/templates/page-layouts#page-container-widths) super easy. The Page component(https://github.com/grommet/grommet/pull/5960) is available on Grommet's Stable branch for beta use and community feedback. HPE Theme and Design System documentation for the Page component is coming soon.   - Added layout templates to Figma(https://www.figma.com/file/4rdBkUlHd5MCVq3hvUOXHd/Page-Layouts?node-id=2906%3A21283) for each breakpoint with ability to add columns and customize widths as needed. Super neat! Be sure to check them out.   - Completed dashboard template for a 3 column dashboard layout(/templates/dashboards#three-column-dashboard). - **Page Header** - Completed research and gathered use cases for Page Header and began design ideation. - **Banner Notification**   - Completed ideation on Global notifications.   - Added support for Global Banners and actions(https://github.com/grommet/grommet/pull/5958) to Grommet's Notification component.   - Guidance, theme updates, and implementation examples for Global notifications are coming soon. ### Stay current with the latest changes ~~ - **Menu** - Added an example of Menu in a toolbar(/components/menu#within-a-toolbar). This pattern displays a search input, filter button, and action menu presented as a unified set of controls. The intent is to present each control with equal prominence. ### Latest Releases ~~ - **Grommet v2.20.1** - Release includes enhancements including (but not limited to): Notification toast position, DataChart type additions, Tag size prop, DateInput icon customization.   Full details about this release are available in the Release Notes(https://github.com/grommet/grommet/releases/tag/v2.21.0). ## January 24 - February 11, 2022 ~~ ### HPE theme breaking change ~~ **Text-Weak** - To meet accessibility requirements, the color value for `text-weak` is changing from `#BBBBBB` to `#757575` for light mode and from `#606B7D` to `#8C98AA` for dark mode. A new namespace `text-xweak` is being added with the value `#BBBBBB` for light mode and `#606B7D` for dark mode. The new `text-weak` value passed WCAG AA contrast values. `#BBBBBB` and `#606B7D` will remain the value for disabled fonts. We would like to hear any feedback on this change ahead of the the next release of the HPE Theme. To test out this new change, apply the theme's stable branch to your project by following these directions(https://github.com/grommet/grommet-theme-hpe#stable). This is a breaking change that will be in the next HPE theme release which will be published in March. ### Communications ~~ - **Office Hours** - India office hours will be held every other Thursday, 9:00 PM IST / 7:30 AM PST. This office hours is open to all. Contact Kamlesh Thakur, if you would like a calendar invite. ### Roadmap Updates ~~ - **Page Layouts**   - Published Content Layouts page with provides guidance for designing for responsiveness(/templates/content-layouts#designing-for-responsiveness), responsive breakpoints(/templates/content-layouts#breakpoints) and page margins(/templates/content-layouts#page-margin).   - Began publishing a collection of page layout templates(/templates/content-layouts#templates) and dashboard templates(/templates/dashboards#dashboard-templates) which provide customizable templates for design and development.   - Collaborating with UCEP to align the Global Header/Footer Service with page layouts guidelines. Provided proof-of-concept project to deliver the HPE Global Header as a Web Component(https://github.hpe.com/grommet/hpe-global-header). - **No Data** - Added guidance and example displaying empty/missing values(/components/namevaluelist#name-value-pair-with-empty-value) in a NameValueList. - **Navigation** - Published five types of navigation patterns(/templates/navigation#types-of-navigation), the strengths for each, and when to use. ### Stay current with the latest changes ~~ - **Toast Notifications** - Enhanced ability to allow greater control over placement of Toast Notifications. Make sure you are aware of the trade-offs associated with placement design decisions(/templates/toast-notifications#placement). - **Accessibility** - Do you know the 4 core principles of accessibility(/foundation/accessibility)? Read up on what it means to be perceivable, operable, understandable, and robust. - **Buttons** - Have \"grouped buttons?\" What types of buttons can be appear together? How should they be ordered? How should they be aligned? See button ordering(/components/button#button-ordering) for more detail. ### Latest Releases ~~ - Grommet v2.20.1(https://github.com/grommet/grommet/releases/tag/v2.20.1) was released which includes an enhancement allowing form validation to occur \"onMount\" for controlled input forms, and bug fixes for \"double focus on Select with search,\" DateInput formatting, Button icon alignment, and styling for TextInput with suggestions. ## January 4 - January 21, 2022 ~~ ### Roadmap Updates ~~ - **Tag** - Completed guidance for Tag(/components/tag). - **Navigation** - Completed research(https://www.figma.com/file/b6hiokanRCwNnc93PpHdgQ/HPE-Design-System-Navigation?node-id=2382%3A13827) and ideations(https://www.figma.com/file/b6hiokanRCwNnc93PpHdgQ/HPE-Design-System-Navigation?node-id=2725%3A18556) for Ascending Navigation. - **Button** - Updated font color on Default Button active state(https://www.figma.com/file/Oi5UEEQ33VCAyOKQcZ8Nr8/HPE-Button-Component) from `text` to `text-strong`. - **Page Layouts**   - Completed Dashboard template for a 2 column layout(https://www.figma.com/file/4rdBkUlHd5MCVq3hvUOXHd/Page-Layouts?node-id=2231%3A17992).   - Shared status update with the Design System Council on January 20, 2022.   - Completed the definition, scope, and anatomy(https://www.figma.com/file/4rdBkUlHd5MCVq3hvUOXHd/Page-Layouts?node-id=2256%3A18479) of Page Layouts.   - Created guidelines for the Page Container, including defining 3 types of content widths: Wide, Narrow and Full(https://www.figma.com/file/4rdBkUlHd5MCVq3hvUOXHd/Page-Layouts?node-id=2256%3A18578).   - Defined new breakpoints and page margins for each breakpoint.   - Work in progress for Page Layout templates, starting with 2 column, 3 column and multi-column Dashboards. ### Stay current with the latest changes ~~ - **Persistent Sidebar to be deprecated by end of year** - In preparation for the deprecation of the Persistent Sidebar in Design System, we have removed any examples and documentation surrounding its use. ### Latest Releases ~~ - **Grommet v2.20.0** - Release includes the NEW Tag component along with enhancements to Calendar, Carousel, DateInput, Form, Video; fixes applied to Anchor, Button, Calendar, Clock, Select, Text, and TextInput. Full details about this release are available in the Release Notes(https://github.com/grommet/grommet/releases/tag/v2.20.0). ## December 24 - January 3, 2022 ~~ Happy Holidays 🎉 ## December 20 - 23, 2021 ~~ ### Roadmap Updates ~~ - **NameValueList** - Created variant demonstrating how editable horizontal form fields(/components/namevaluelist#name-value-pair-as-a-read-only-display-in-horizontal) may be displayed within Name-Value Lists. ### Stay current with the latest changes ~~ - **Toast Notifications** - Updated the following guidance for toast notifications:   - When a toast notification should be used(/templates/toast-notifications#when-should-you-use-a-toast-notification).   - Aria attributes which should be present for toast notification accessibility(/templates/toast-notifications#accessibility). ## December 6 - December 17, 2021 ~~ ### Roadmap Updates ~~ - **Button**   - Completed guidance on placement of the Cancel Button in a Form and Modal(/components/button#styling).   - Updated Figma with the new hover states for Primary and Color Buttons and published within the HPE theme(https://github.com/grommet/grommet-theme-hpe/pull/230).   - Updated Button Figma file on Cancel Buttons(/components/button#cancel-buttons) to use `default` styling in Forms and Modals instead of `secondary`. - **Tag**   - Started explorations(https://www.figma.com/file/8zrInotU4JK9LWP4WyZy25/HPE-Design-System-Tags?node-id=2%3A3) and ideations(https://www.figma.com/file/8zrInotU4JK9LWP4WyZy25/HPE-Design-System-Tags?node-id=286%3A2375) for Tags component. - **Navigation**   - Began ideation for Matrix Navigation(https://www.figma.com/file/b6hiokanRCwNnc93PpHdgQ/HPE-Design-System-Navigation?node-id=1647%3A9780).   - Started ideation for Reverse Navigation(https://www.figma.com/file/b6hiokanRCwNnc93PpHdgQ/HPE-Design-System-Navigation?node-id=2486%3A14490).   - Provided guidance and examples on Sidebar for Side-to-Side Navigation(/templates/side-to-side-navigation?q=side).   - Finalized ideating and creating documentation for Matrix Navigation(/templates/matrix-navigation).   - Finalized ideation for Global Header within Side-to-Side Navigation(https://www.figma.com/file/b6hiokanRCwNnc93PpHdgQ/HPE-Design-System-Navigation?node-id=1647%3A9562). - **Page Layouts**   - Started an overview of Page Layouts that provides definitions and an anatomy(https://www.figma.com/file/4rdBkUlHd5MCVq3hvUOXHd/Page-Layouts?node-id=1876%3A16251).   - Commenced ideation and documentation such as responsive design, breakpoints, and padding on containers within Page Layouts(https://www.figma.com/file/4rdBkUlHd5MCVq3hvUOXHd/Page-Layouts?node-id=1876%3A16251). ## November 22 - December 3, 2021 ~~ ### Roadmap Updates ~~ - **Button**   - Added guidance on the ordering of buttons on a form, layer. Updates are available on Design System site(/components/button?q=button#single-buttons).   - Started exploration around if Cancel Buttons should be primary or secondary.   - Completed guidance for button positioning on wizards and modals.(/components/layer#actionable).   - Guidance on left vs right aligned buttons(/components/button#button-alignment) published to Design System site.   - Re-visited hover state for primary button and updated color(https://github.com/grommet/hpe-design-system/issues/1271). - **Navigation**   - Began explorations for Reverse Navigation(https://www.figma.com/file/b6hiokanRCwNnc93PpHdgQ/HPE-Design-System-Navigation?node-id=1%3A18).   - Started exploration of Matrix Navigation(https://www.figma.com/file/b6hiokanRCwNnc93PpHdgQ/HPE-Design-System-Navigation?node-id=1%3A18). ### Stay current with the latest changes ~~ - Added trash icon to FileInput validation example on Design System site(/components/fileinput#fileinput-validation). - Changed the cog icon on ordering of items to column icon based on outcomes of a user study(/templates/datatable-customization). ## November 8 - November 19, 2021 ~~ ### Communications ~~ - **Office Hours** - A second office hours will be held on Thursdays, 9:00 PM IST / 7:30 AM PST. This office hours is open to all. Contact us if you would like an invite. - **Figma Guide** - A new guide(https://www.figma.com/proto/ehx1youYYwuaGasfwTbkNK/Figma-Guide?page-id=425%3A284&node-id=846%3A1435&viewport=241%2C48%2C0.03&scaling=min-zoom&starting-point-node-id=644%3A590) to level-up your Figma skills. Whether you are onboarding or a Figma power user, there's content for you from fundamentals, to auto-layout, to interactive prototyping &mdash; plus fun tips and tricks too! ### Roadmap Updates ~~ - **NameValueList**. The NEW NameValueList component and guidance have been published and is available in Figma(https://www.figma.com/file/Ny7rYK5gI5VO4PtZsq6vGC/HPE-Name-Value-List?node-id=2%3A93) and on the Design System site(/components/namevaluelist?q=name). - **Navigation**. Added guidance and examples for Drill Down Navigation(https://www.figma.com/file/b6hiokanRCwNnc93PpHdgQ/HPE-Design-System-Navigation?node-id=1647%3A9622) using cards, lists, and tables. - **Button Guidance**.   Left aligned? Right aligned? Read the latest guidance for how buttons should be aligned(https://www.figma.com/file/Oi5UEEQ33VCAyOKQcZ8Nr8/HPE-Button-Component?node-id=4071%3A8993) in various contexts. ### Stay current with the latest changes ~~ - **Tables** - Presenting state and statuses in table data can occupy valuable real-estate. View these recommendations for displaying states and statuses within a table(https://www.figma.com/file/XEoIWIlLfcARRIFhkpFCch/HPE-DataTable?node-id=7210%3A147386). - **Checkbox** - Checkboxes may now be vertically aligned(https://github.com/grommet/grommet-theme-hpe/pull/222) when accompanied by a multi-line label such as your favorite \"I accept the Terms of Use and Privacy Policy\". - **FileInput** - Following up on an Office Hours request, examples for how file input validation should appear have been added to the Design System site(/components/fileinput?q=file#fileinput-validation) and Figma(https://www.figma.com/file/8HwAiiSDloOTjUxqvCTypq/HPE-FileInput-Component?node-id=1164%3A43348). ### Latest Releases ~~ - **Grommet v2.19.0** - Release includes the NEW NameValueList component along with enhancements to DataTable, FileInput, FormField and RangeInput. For a comprehensive list of enhancements and fixes, see the Release Notes(https://github.com/grommet/grommet/releases/tag/v2.19.0). - **Grommet-theme-hpe v2.3.0** - Release includes alignments of input dimensions and RangeInput to Figma, fixes to DataTable pinned background to work in both light and dark modes, and more. For more details, see the Release Notes(https://github.com/grommet/grommet-theme-hpe/releases/tag/v2.3.0). - **Grommet-Icons v4.7.0** - Release includes the NEW HomeRounded icon. See the Release Notes(https://github.com/grommet/grommet-icons/releases/tag/v4.7.0) for details. ## October 25 - November 5, 2021 ~~ ### Hacktoberfest ~~ - Grommet completed the month-long Hacktoberfest event(https://grommet.slack.com/archives/C3UGPN06S/p1636133843018400)   which encourages support and contributions to open source projects. This year 79 pull   requests were merged addressing TypeScript support and type testing, support for Storybook   theming, and a smattering of bug fixes and other enhancements. ### \"Big Things\" progress updates ~~ Here are the latest developments regarding roadmap items: - **NameValueList**. Styling for NameValueList and NameValuePairs are now available in the   HPE Theme. - **Page Layouts**. Shared milestones and timelines with the Design System Council on November 3, 2021. - **Tags**. Grommet pull request for a new Tag component(https://github.com/grommet/grommet/pull/5778) has been submitted and is under review. - **Refresh Navigation**. Shared card-based navigation patterns, solicited and incorporated feedback. See Figma for reference(https://www.figma.com/file/b6hiokanRCwNnc93PpHdgQ/HPE-Design-System-Navigation?node-id=1647%3A9622). - **Site Search**. Enhanced the search experience on the Design System site providing   expanded search result set, content previews, and more. - **Button Guidance**.   Fixed Figma library button icon variants(https://www.figma.com/file/Oi5UEEQ33VCAyOKQcZ8Nr8/HPE-Button-Component?node-id=3644%3A8574) for small and large buttons. - **Accessibility Resources**.   - Added collection of designer and software developer guides(/foundation/accessibility#designer-and-software-developer-guides) covering accessibility     topics such as \"complex images in software,\" \"treatment of links and hyperlinks,\"     \"evaluation tools,\" and more.   - Published a collection of short accessible product design videos(/foundation/accessibility#accessible-product-design-videos)     covering topics such as \"tab order and on-screen focus,\" \"layout and page structure,\" and more. ## October 18-22, 2021 ~~ ### NEW NameValueList ~~ - Looking to display key-value pairs cleanly, consistently, and semantically correct? NEW   NameValueList component(https://v2.grommet.io/namevaluelist) is now available on Grommet.   HPE theming and guidance(https://github.com/grommet/hpe-design-system/issues/1986) will follow soon. ### Stay current with the latest guidance ~~ - How should card elevation be handled? What should I do if my card has multiple interactive elements?   Can cards have multiple interactive elements? View the new Card interactions guidance(/components/card#interactions)   and updated card example implementations. - Guidance for required and optional fields has been refined. Read the   updated guidance(/templates/forms#required-vs-optional-fields) and   research(https://www.figma.com/file/3fkwBelW5UsCbfwdDCJkT8/HPE-Form-Templates?node-id=5236%3A11011). ### \"Big Things\" progress updates ~~ Here are the latest developments regarding roadmap items: - **NameValueList**. See above(/whats-new#namevaluelist). - **Page Layouts**. Page layout executions and use cases have been collected across teams and synthesized to   identify common templates(https://github.com/grommet/hpe-design-system/issues/1912). Creation of dashboard   templates will be prioritized, followed by wizards, lists, and tables. - **Tags**. Or, are they labels? Custom attributes? Chips? Jury says... tags! A special thanks to Greg Furuiye   for his contributions to tag research, explorations, ideations, and initial guidance &mdash; contributions   help a ton! Next steps are to assemble guidance and examples for the Design System site. Plus, development   on the supporting Grommet Tag component has begun. - **Refresh Navigation**. Completed research and exploration for card-based navigation(https://github.com/grommet/hpe-design-system/issues/1655#issuecomment-949064370). ### Communications ~~ - **Office Hours** - A second, timezone-friendly option for office hours will soon be offered to ensure   questions across all teams are addressed. Scheduling is in the works. ## October 4-15, 2021 ~~ ### Stay current with the latest guidance ~~ - HPE theming and guidance have been added for displaying Code Blocks(/templates/code-blocks)   within applications. ### \"Big Things\" progress updates ~~ Here are the latest developments regarding roadmap items: - **NameValueList**.   - Grommet component API and development is ready for review(https://github.com/grommet/grommet/pull/5626).   - Completed designs for NameValueList(https://www.figma.com/file/Ny7rYK5gI5VO4PtZsq6vGC/HPE-Name-Value-Pair?node-id=305%3A471)     and handed off for development. - **Page Layouts**. Defined maximum and minimum page widths(https://github.com/grommet/hpe-design-system/issues/1830) and associated breakpoints. - **Refresh Navigation**. Shared tab-based navigation patterns, solicited and incorporated feedback. See Figma for reference(https://www.figma.com/file/b6hiokanRCwNnc93PpHdgQ/HPE-Design-System-Navigation?node-id=1647%3A9562). - **Button Guidance**. How should buttons be used within and to control layers? Answer, it depends on the   layer's function. Guidance for layer types and their interactivity(/components/layer#types)   has been added, accompanied by updated example implementations. - **Accessibility Page Improvements**. Added Government Standards and Regulations(http://localhost:3000/foundation/accessibility#government-standards-and-regulations)   resources, calling attention to the policies and how they may affect your work product. ### Communications ~~ - Completed workshops related to consumers of the Design System, identifying areas for improve the process for communicating   new components and component requests. - Began drafting a \"Figma getting started guide\" to help onboard designers and provide best practices   when consuming component libraries. ## September 20 - October 1, 2021 ~~ - Kicked off the HPE Design System Council, a steering committee for defining key initiatives and priorities. - Began holding Design System \"office hours\" each Wednesday morning. Bring your questions and topics for discussion. Contact the #hpe-design-system channel on Slack to request a calendar invite. - New resources and a checklist has been added to the Accessibility page(/foundation/accessibility#external-resources). - Fixed height on DataTable(/components/datatable) examples when in full screen. - Completed Button size designs(https://www.figma.com/file/Oi5UEEQ33VCAyOKQcZ8Nr8/HPE-Button-Component?node-id=0%3A1). - Completed ideation and collected feedback for NameValueList designs(https://www.figma.com/file/Ny7rYK5gI5VO4PtZsq6vGC/HPE-Name-Value-Pair?node-id=148%3A1936). - Provides \"request for comments\" pull requests for Grommet NameValueList component. Approach 1(https://github.com/grommet/grommet/pull/5623). Approach 2(https://github.com/grommet/grommet/pull/5626). - Improved DateInput and Calendar keyboard accessibility behavior. - Provided additional accessibility resources(/foundation/accessibility#internal-resources) from the Product Accessibility Office on the Accessibility page. - Implemented improved site search capabilities on the HPE Design System site. - Completed categorization and naming for Navigation patterns. - Released Grommet v2.18.0(https://github.com/grommet/grommet/releases/tag/v2.18.0). ## September 6 - September 17, 2021 ~~ - Completed research on task focused navigation(https://www.figma.com/file/b6hiokanRCwNnc93PpHdgQ/HPE-Design-System-Navigation?node-id=1265%3A1187). - Completed usability testing on toggle buttons and sortable columns within a table with an expert screen reader user. - Ideation on Navigation(https://www.figma.com/file/b6hiokanRCwNnc93PpHdgQ/HPE-Design-System-Navigation?node-id=1279%3A1206) coming to a finish. - Added guidance for toggle icon buttons(/components/button#toggle-buttons-with-icons). - Added t-shirt sizing for buttons. Figma publishing coming soon! - Enhanced List to support top-alignment and added guidance for multi-line lists(/templates/lists). - Enhanced a11yText on our light/dark mode button within the HPE Design System header navigation(/). - Aligned Toolbar Button hover(/components/button#toolbar-button) implementation with Figma(https://www.figma.com/file/Oi5UEEQ33VCAyOKQcZ8Nr8/HPE-Button-Component?node-id=681%3A5164). - Aligned RangeInput component to Grommet. Figma file coming soon! - Advanced Design System site search capabilities. Work in progress. ## August 30 - September 3, 2021 ~~ - Published Notifications page(/components/notification). - Published Toast Notifications(/templates/toast-notifications). - Published Status Indicators(/templates/status-indicator) template page. - Updated all examples referencing \"status\" to apply the new Status Indicators guidance(/templates/status-indicator#what-makes-up-a-status-indicator). ## August 23 - August 27, 2021 ~~ - Published the Notification(/components/notification) and Toast Notifications(/templates/toast-notifications) & Status Indicator(/templates/status-indicator) content with examples. - Updated Toolbar Button(https://www.figma.com/file/Oi5UEEQ33VCAyOKQcZ8Nr8/HPE-Button-Component?node-id=3156%3A5073) to include an icon-only variant and changed stroke from 2px to 1px. - Updated Default Button(https://www.figma.com/file/Oi5UEEQ33VCAyOKQcZ8Nr8/HPE-Button-Component?node-id=690%3A823) in Figma to align with the Design System site by removing the background color. - Updated name for \"Tooltip\" component in Figma library to \"Tip\"(https://www.figma.com/file/Jd34cI5yyZIPb5BIwkIPU2/HPE-Tip?node-id=538%3A803) to align with the Design System site. - Added numerical values(https://www.figma.com/file/BqCjvjc0rECQ4Ln2QhyjNi/HPE-Range-Input-Component?node-id=9%3A73) labeling each end of RangeInput. - The actions menu(https://www.figma.com/file/TonE8uQ33e5QJRPknZx36q/Ordering-Of-Items?node-id=868%3A16581) is now styled to match the new Toolbar Button. ## July 19-23, 2021 ~~ - Iterated on Notifications taxonomy based on research results. - Continued ideating on written guidance for Navigation(https://www.figma.com/file/b6hiokanRCwNnc93PpHdgQ/HPE-Design-System-Navigation?node-id=1%3A20). - Audited all of Figma files to ensure correct use of MetricHPEXS font. ## July 12-16, 2021 ~~ - Began Notifications Taxonomy Survey. - Updated Header colors on DateInput component in Figma(https://www.figma.com/file/Mf9if6zyGETTWW5b9PsYNQ/HPE-Date-Input-Component?node-id=0%3A1). - Removed Selected state from Menu on Figma file(https://www.figma.com/file/DyFWlzLBUtK5KH5jJhwoCB/HPE-Menu-Component?node-id=0%3A1) to align with Design System site. - Updated DataTable with Search value(https://www.figma.com/file/XEoIWIlLfcARRIFhkpFCch/HPE-Table?node-id=2390%3A242) to match Filtering examples on Figma and Design System site. - Updated Select dropdown items on Figma file to use regular text weight rather than form value weight(https://www.figma.com/file/fZJdRcNrvZ1JjdPRYHpFFU/HPE-Select-Component?node-id=0%3A1). - Updated TextInput dropdown items on Figma file to use regular text weight rather than form value weight(https://www.figma.com/file/E40Oo2MpdRNMyVaJqfJ0Wd/HPE-Text-Input-Component?node-id=0%3A1). - Enhanced the way Menu is built on Figma by making it one component rather than a button with a list drop.(https://www.figma.com/file/DyFWlzLBUtK5KH5jJhwoCB/HPE-Menu-Component?node-id=0%3A1). - Updated Wizard Figma file to match the Design System site. Changes include: wizard header background color, spacing and text styling(https://www.figma.com/file/GEhgYzx3b8MejBjg9gAxyA/Wizarding?node-id=0%3A1) ## July 5-9, 2021 ~~ - Began ideation for Navigation guidance and examples. - Added guidance on how to determine the width of columns on a Table(/components/datatable#setting-the-width-of-the-table). ## June 28 - July 2, 2021 ~~ - Added new Toolbar Button to Figma and its variants ( https://www.figma.com/file/Oi5UEEQ33VCAyOKQcZ8Nr8/HPE-Button-Component?node-id=0%3A1). - Updated Form Figma file to include correct text styling.(https://www.figma.com/file/3fkwBelW5UsCbfwdDCJkT8/HPE-Form-Templates?node-id=2668%3A3582) TextInput values were changed from text-strong to default text color. - Completed research for Navigation(https://www.figma.com/file/b6hiokanRCwNnc93PpHdgQ/HPE-Design-System-Navigation?node-id=1%3A18). ## June 21-25, 2021 ~~ - Began research explorations for Navigation. ## July 26-30, 2021 ~~ - Updated Form examples on Design System site to use semantically correct headings and font color(/templates/forms). ## August 23-27, 2021 ~~ - Added examples to Tip to display the different sizes and how it can be used within a Table. ## June 14-18, 2021 ~~ - Released grommet-icons v4.6.0! Check out the Release Notes(https://github.com/grommet/grommet-icons/releases/tag/v4.6.0). - Added download links for MetricHPEXS(/foundation/typography#fonts-for-offline-usage) for offline usage. - Enhanced filtering examples to demonstrate Filtering with a table containing selectable rows(/templates/filtering#filtering-with-selectable-results). - Added guidance for setting the width of a DataTable(/components/datatable#setting-the-width-of-a-DataTable). - Added a CheckBox variant of \"checked\" to Figma for Table headers(https://www.figma.com/file/XEoIWIlLfcARRIFhkpFCch/HPE-Table?node-id=2390%3A13994). - Aligned the CheckBox component in Figma(https://www.figma.com/file/7Mm1xDBTOtPHqggEVpaD2N/HPE-Checkbox-Component?node-id=1315%3A1) with the Design System site to include a border on hover. ## June 7-11, 2021 ~~ - Released Grommet v2.17.3! Read the Release Notes(https://github.com/grommet/grommet/releases/tag/v2.17.3). - Updated Wizard \"Next\" button mobile layout(/templates/wizard) to match desktop layout - Added examples for how the **order of items** may be customized in a Table(/templates/table-customization) and List(/templates/lists#item-order). - Provided instructions and guidance for implementing the latest HPE Global Header(/templates/global-header). ## May 31 - June 4, 2021 ~~ - Added guidance and examples for FileInput(/components/fileinput) - Added `kind=\"toolbar\"` to button in grommet-theme-hpe for use in Filter contexts. See how this button is used in Filtering examples(/templates/filtering). - Updated filtering pattern to use default Button instead of Anchor for \"Clear Filters\" control. View the Filtering examples on Design System site(/templates/filtering) and Figma(https://www.figma.com/file/EA0OZFdocKVcQ55c7Jainb/HPE-Filter-Templates?node-id=1%3A3738). ## May 24-28, 2021 ~~ - Began a \"Getting Started with HPE Design System\" starter application providing a step-by-step introduction to Grommet, grommet-theme-hpe, and developing with the Design System. Check out the repository: https://github.com/grommet/hpe-design-system-starter. ## May 17-21, 2021 ~~ - Added guidance for Spinner(/components/spinner) - Improved accessibility for Select by allowing callers to specify an `a11yTitle`(https://github.com/grommet/grommet/pull/5234). - Improved the Design System site experience for keyboard navigators and screen reader users by adding SkipLinks(https://github.com/grommet/hpe-design-system/pull/1606). - Completed gathering research and screen shots of the different types of Page Layouts(https://www.figma.com/file/4rdBkUlHd5MCVq3hvUOXHd/App-Page-Layouts?node-id=881%3A3952). - Completed Page Layout(https://www.figma.com/file/4rdBkUlHd5MCVq3hvUOXHd/App-Page-Layouts?node-id=0%3A1) designs in Figma. ## May 10-14, 2021 ~~ - Released grommet-theme-hpe v2.1.0! Read the Release Notes(https://github.com/grommet/grommet-theme-hpe/releases/tag/v2.1.0). - Created slides on why Principles(https://www.figma.com/file/8jLGXR0nBgFeuy9cdQUxWH/Principles-and-Values?node-id=146%3A1) are important for a Design System. ## May 3-7, 2021 ~~ - Improved accessibility of grouped form inputs in Grommet: https://github.com/grommet/grommet/pull/5209 ## April 26-30, 2021 ~~ - Released Grommet v2.17.2! Read the Release Notes(https://github.com/grommet/grommet/releases/tag/v2.17.2). - Provided example of CheckBox validation when not contained in a FormField(https://github.com/grommet/hpe-design-system/issues/1592). - Enhanced grommet-theme-hpe z-index for Layer and Drop to work with HPE Global Header: https://github.com/grommet/grommet-theme-hpe/pull/185 ## April 19-23, 2021 ~~ - Added examples of text sizes 3xl, 4xl, 5xl, 6xl(/foundation/typography#text) - Added text sizes of 3xl, 4xl, 5xl, and 6xl to Figma(https://www.figma.com/file/oJhw3JqMemtbwWjlLPWW5O/HPE-Typography-Styles?node-id=149%3A2). - Updated Form examples(/templates/forms#shipping): when referring to ZIP codes, the acronym should always be written as ZIP instead of Zip - Added guidance for CheckBox as a toggle(/components/checkbox#toggle). - Updated Figma to provide an example for a RadioButtonGroup without a FormField description(https://www.figma.com/file/aZyY606ENQedz4FXugdzgS/HPE-Radio-Button-Group-Component?node-id=105%3A643). - Completed design ideations for Ordering of Items(https://www.figma.com/file/TonE8uQ33e5QJRPknZx36q/Ordering-Of-Items?node-id=343%3A6850) ## April 12-16, 2021 ~~ - Added guidance and examples for Tip(/components/tip) ## April 5-9, 2021 ~~ - Updated Wizard guidance(/templates/wizard) and patterns to demonstrate recommended behavior for width of the inputs and footer - Demonstrated how to use `plain: true` in DataTable columns(/components/datatable#selecting-multiple-records-and-batch-actions) to create clickable cells ## March 29 - April 2, 2021 ~~ - Updated guidance for user-entered input in Forms(/templates/forms#user-entered-input). - Updated guidance for considerations to make dashboards easier to consume(/templates/dashboards#guidance). - Added guidance and an example for navigation from within a Table(/components/datatable#navigation-via-table). ## March 22-26, 2021 ~~ - Added theming for Pagination(https://github.com/grommet/grommet-theme-hpe/pull/174) and Spinner(https://github.com/grommet/grommet-theme-hpe/pull/176) to grommet-theme-hpe - Completed ideation on FileInput(https://www.figma.com/file/8HwAiiSDloOTjUxqvCTypq/HPE-FileInput-Component?node-id=0%3A1). ## March 15-19, 2021 ~~ - Added a RadioButton Group with no description variant to Figma(https://www.figma.com/file/aZyY606ENQedz4FXugdzgS/HPE-Radio-Button-Group-Component?node-id=78%3A0). ### Published Pagination page and Figma designs ~~ - Added guidance and usage examples for when to use pagination(/components/pagination). - Published Figma designs for Pagination(https://www.figma.com/file/slRqNvhJub0QlgN46zSXoY/HPE-Pagination-Component?node-id=1%3A2) ### Published Spinner page ~~ - Spinner Page was added onto the site. Read more about spinner guidance(/components/spinner) ## March 8-9, 2021 ~~ ### Conducted a design-sprint to discuss Page-Layouts ~~ ## March 1-5, 2021 ~~ ### Ran OWASP security scan on the design-system site ~~ - The OWASP Security Scan was run to identify any security vulnerabilities in the Design System site. This is required to ensure full compliance with HPE standards. ## Febuary 22-26, 2021 ~~ ### New Spinner Component on Grommet. ~~ The new Spinner component has been released on grommet stable branch(https://github.com/grommet/grommet/pull/4981). ### Add new validation colors ~~ - Add validation-ok and validation-warning to theme. ### Added Tooltip to theme and site examples ~~ - Default Tip styling available on grommet-theme-hpe stable branch(https://github.com/grommet/grommet-theme-hpe/pull/167) - Guidance and code examples available on the Tooltip page(/components/tooltip) ## Febuary 15-19, 2021 ~~ ### New FileInput Component ~~ - Check out the new FileInput(https://v2.grommet.io/fileinput) Component on the grommet stable branch. ### New Pagination Component ~~ - Check out the new Pagination Component(https://v2.grommet.io/pagination) on the grommet stable branch. ### Layer ~~ - Aligned layer component(https://github.com/grommet/hpe-design-system/pull/1434) to match the figma files. ## Febuary 8-12, 2021 ~~ - Ordering of Items research(https://www.figma.com/file/TonE8uQ33e5QJRPknZx36q/Ordering-Of-Items?node-id=33%3A12) was completed. ### Homepage ~~ - Completed a fresh new look for our new HPE Design System home page(https://github.com/grommet/hpe-design-system/pull/1408). - Figma(https://www.figma.com/file/CWB0xMmfVx6cT0ugzluySl/home-page?node-id=87%3A379) is updated as well ### Updated Wizard template ~~ - Adds Wizard Title to WizardContext. Allows for step header description to be custom element ## Febuary 1-5, 2021 ~~ - Updated Search Figma file to include drop suggestion examples(https://www.figma.com/file/KKHWJN4GAI0Mq5yh0snDT6/HPE-Search-Component?node-id=43%3A26) to align with Design System site. - Updated TextInput Figma file to include drop suggestion examples(https://www.figma.com/file/E40Oo2MpdRNMyVaJqfJ0Wd/HPE-Text-Input-Component?node-id=2231%3A145) to align with Design System site. ### Provided some content on our accessibility page. ~~ - Find out how to incorporate accessibility into design and development. Check out the page(/foundation/accessibility) ### Updated multiiselect example ~~ - Previously multiiselect was immediately closing after a user made a single selection this changed to add a close prop. Find details about this change here(https://github.com/grommet/hpe-design-system/pull/1400) ### Grommet 2.16.3 release ~~ ### Update theme to handle formfield labels with required ~~ - Updated the HPE theme to provide required label. ## January 24-30, 2021 ~~ ### Background colors ~~ - Audited Design System site examples and updated background color usage(https://github.com/grommet/hpe-design-system/pull/1384)   aligning with background colors guidance(/foundation/background-colors-guidance). ### Button ~~ - Enhanced ability to support button sizes(https://github.com/grommet/grommet/pull/4886)   in the HPE theme. - Next steps are to incorporate button sizes into the HPE theme. ### Cards ~~ - Modified default elevation(https://github.com/grommet/grommet-theme-hpe/pull/157) applied to Cards. ### DateInput ~~ - Added example(https://www.figma.com/file/Mf9if6zyGETTWW5b9PsYNQ/HPE-Date-Input-Component?node-id=287%3A910)   of a DateInput without a label to Figma. ### Headings ~~ - Headings now use `text-strong` by default in the HPE Theme. Completes work(/whats-new#headings-1162021)   begun week ending January 16. ### Form ~~ - Resolved issue related to updating form input values(https://github.com/grommet/grommet/issues/4882)   when name prop not present. Contribution from the Grommet community! - Fixed issue regarding onBlur form validation(https://github.com/grommet/grommet/issues/4863). ### Layer ~~ - Implement Layer border-radii in HPE Theme(https://github.com/grommet/hpe-design-system/issues/1341)   to match Figma designs. Completes Layer theming work(#miscellaneous-12192020) begun in December. ### Table ~~ - Resolved column alignment bug(https://github.com/grommet/grommet/issues/4887).   Contribution from the Grommet community! - Resolved lag in hover styling https://github.com/grommet/grommet/issues/4881. ### Tabs ~~ - Resolved spacing issue between icons within Tabs in Figma(https://www.figma.com/file/Kp4dWyhUTnKIJ1Cg5CoL9o/HPE-Tabs-Component?node-id=0%3A1). ### Wizard ~~ - Incorporated updated Wizard designs(/templates/wizard) based on feedback. Notable changes include: - Wizard header now has a background of `background-contrast`. - Step titles are now using h1, size=\"small\". - Tightened up spacing between step number, step title, and step description. ### Miscellaneous ~~ - Cleaned up Figma component thumbnails(https://github.com/grommet/hpe-design-system/issues/1356). - Provided proof of concept for custom Select(https://github.com/grommet/grommet/issues/4855) implementation meeting requirement use case. ## January 17-23, 2021 ~~ ### Background colors ~~ - Incorporated feedback and addressed clarifying questions:   - Provided additional guidance on what to consider when selecting a basic or layered approach(/foundation/background-colors-guidance#basic-or-layered-approach).   - Added an example and guidance for using the basic layout with cards(/foundation/background-colors-guidance#basic-layout-with-cards).   - Added examples clarifying how an application header should appear and behave when it is a fixed header(/foundation/background-colors-guidance#with-fixed-header) and another for when the header scrolls with the content(/foundation/background-colors-guidance#header-scrolls-with-content). ### DateInput ~~ - Added a DateInput with no label to Figma(https://www.figma.com/file/Mf9if6zyGETTWW5b9PsYNQ/HPE-Date-Input-Component?node-id=1%3A567) to align with Design System site. ### InfiniteScroll ~~ - Completed InfiniteScroll design direction(https://www.figma.com/file/XOEwUOqtfLAowprV2psWHM/HPE-Infinite-Scroll?node-id=1%3A35). ### Pagination ~~ - Advanced the work-in-progress by incorporating review feedback and t-shirt sizing. Play with Pagination behavior(https://deploy-preview-4646--sad-tereshkova-173d07.netlify.app/?path=/story/controls-pagination--custom)   and/or follow the pull request progress(https://github.com/grommet/grommet/pull/4646). ### ToolTip ~~ - Completed ideation phase and finalized design direction for ToolTip(https://www.figma.com/file/Jd34cI5yyZIPb5BIwkIPU2/HPE-Tooltip?node-id=119%3A375).   A special thanks to **@Maggie Silva** for her contributions to ToolTip. ### Miscellaneous ~~ - Completed ideation for a refreshed home page(https://www.figma.com/file/CWB0xMmfVx6cT0ugzluySl/home-page?node-id=0%3A1) experience. The live version is coming soon. - Published the What's New page(/whats-new). ## January 10-16, 2021 ~~ ### Headings - 1.16.2021 ~~ - Headings in the Figma library have been updated to use `text-strong`. - TODO: Apply `text-strong` as default in HPE Theme. ### Background colors ~~ - Published a new page providing guidance for   how to apply background colors(/foundation/background-colors-guidance)   in your application layout. We've already received great feedback and identified areas which need   to be addressed. ### Anchor ~~ - Added an example for an Anchor with weight(/components/anchor#anchor-with-weight) to the Anchor page. ### Pagination ~~ - Added custom theming capabilities for the proposed Pagination Grommet component. Play with Pagination behavior(https://deploy-preview-4646--sad-tereshkova-173d07.netlify.app/?path=/story/controls-pagination--custom)   and/or follow the pull request progress(https://github.com/grommet/grommet/pull/4646). ### Miscellaneous ~~ - Began implementation of the \"What's New\" page. - Fixed error preventing Grommet Docs site to deploy properly. ## January 3-9, 2021 ~~ ### Headings ~~ - Decision has been made to make `text-strong`  the   default font color for Headings. Previously, Headings defaulted to color `text`   . ### Pagination ~~ - Made pagination controls respect a uniform width for the proposed Pagination Grommet component. - Added abillity to control the sizing of pagination controls via \"t-shirt sizing.\" - Explored approaches for allowing custom theming capabilities. - Play with Pagination behavior(https://deploy-preview-4646--sad-tereshkova-173d07.netlify.app/?path=/story/controls-pagination--custom)   and/or follow the pull request progress(https://github.com/grommet/grommet/pull/4646). ### Searching & Filtering ~~ - Additional guidance was requested for how the text should read in a situation after   a user has filtered a set of table results and selected rows from the filtered table.   That work is represented in this issue(https://github.com/grommet/hpe-design-system/issues/1343). ### Miscellaneous ~~ - Fixed order of plot points(https://github.com/grommet/grommet/issues/4854) in Chart. - Enhanced Layer to allow elevation to be controlled via theme(https://github.com/grommet/grommet/pull/4851),   and set default elevation(https://github.com/grommet/grommet-theme-hpe/pull/150) of 'large' in HPE Theme. - Made casing of form validation errors consistent across Form examples(/templates/forms). ## December 20, 2020 - January 2, 2021 ~~ Happy holidays to all. See you in 2021! ## December 13-19, 2020 ~~ ### Colors ~~ - Added background context and criteria for how the \"green\" colors in the HPE Theme(/foundation/color#green-color-accessibility) were determined. ### Miscellaneous - 12.19.2020 ~~ - Fixed issue formatting disabled Calendar dates(https://github.com/grommet/hpe-design-system/issues/1328). - Fixed issue with Select with search(https://github.com/grommet/grommet/issues/4829) - Enhance Layer theming to allow styling border radii(https://github.com/grommet/grommet/issues/4805). - Completed Ideation phase for What's New page(https://github.com/grommet/hpe-design-system/issues/822) with recommended design for implementation. - Completed research on Principles and Values(https://www.figma.com/file/8jLGXR0nBgFeuy9cdQUxWH/Principles-and-Values?node-id=0%3A1) to enhancements to our own. ## December 6-12, 2020 ~~ ### Tables ~~ - Hover effect on tables has been fixed. Check it out!() - Table now has guidance on using unique identifiers(https://www.figma.com/file/XEoIWIlLfcARRIFhkpFCch/HPE-Table?node-id=2390%3A13974) in your table. - Table also has guidance for how interactive table cells(https://www.figma.com/file/XEoIWIlLfcARRIFhkpFCch/HPE-Table?node-id=2390%3A13974) look and behave. ### Select ~~ - Validation icon added to Select component within Figma. Check it out!() ### Icons ~~ - Work to provide guidance for how and when to use icons in your designs has   begun. We are in the **Exploration** phase of this work where we gather research,   assemble use cases, etc. Check back soon. ### Miscellaneous ~~ - Aligned of Wizard examples in Figma and Design System site. {/* END: What's New Entries */} "}];
\ No newline at end of file
diff --git a/apps/docs/src/examples/components/Playground.js b/apps/docs/src/examples/components/Playground.js
new file mode 100644
index 0000000000..6d4da6fcc7
--- /dev/null
+++ b/apps/docs/src/examples/components/Playground.js
@@ -0,0 +1,125 @@
+import React from 'react';
+import PropTypes from 'prop-types';
+import { Anchor, Box, Text } from 'grommet';
+import { anchorArgTypes } from
+  '@shared/aries-core/src/stories/components/Anchor.stories';
+import { boxArgTypes } from
+  '@shared/aries-core/src/stories/components/Box.stories.tsx';
+import {
+  ComponentPlayground,
+} from '../../components/content/ComponentPlayground';
+
+// Component configurations
+const COMPONENT_CONFIGS = {
+  anchor: {
+    component: Anchor,
+    argTypes: anchorArgTypes,
+    defaultProps: {
+      label: 'Link',
+      href: '#',
+      a11yTitle: 'Navigate to link',
+      icon: null,
+      size: 'medium',
+      reverse: false,
+      disabled: false,
+    },
+  },
+  box: {
+    component: Box,
+    argTypes: boxArgTypes,
+    defaultProps: {
+      direction: 'column',
+      pad: 'medium',
+    },
+    // Custom renderer for Box to include children
+    customRender: props => (
+      <Box {...props}>
+        <Text>First item</Text>
+        <Text>Second item</Text>
+        <Text>Third item</Text>
+      </Box>
+    ),
+  },
+};
+
+// Transform Storybook argTypes to ComponentPlayground controls format
+const transformArgTypesToControls = (argTypes, componentName) => {
+  const controls = [];
+
+  Object.entries(argTypes).forEach(([name, argType]) => {
+    const control = {
+      name,
+      displayLabel:
+        name.charAt(0).toUpperCase() + name.slice(1).replace(/([A-Z])/g, ' $1'),
+    };
+
+    // Determine control type based on Storybook control type
+    const controlType = argType.control?.type;
+
+    if (controlType === 'text') {
+      control.type = 'text';
+    } else if (controlType === 'boolean') {
+      control.type = 'checkbox';
+    } else if (controlType === 'select') {
+      control.type = 'select';
+      control.options = argType.options || [];
+
+      // Special handling for icon type
+      if (argType.mapping) {
+        control.type = 'icon';
+        control.options = argType.options
+          .filter(opt => opt !== 'none')
+          .map(opt => ({ label: opt, value: opt }));
+        // Add None option at the beginning
+        control.options.unshift({ label: 'None', value: null });
+      }
+    }
+
+    // Add conditional visibility for reverse (anchor-specific)
+    if (name === 'reverse' && componentName === 'anchor') {
+      control.showWhen = props => props.icon && props.label;
+    }
+
+    controls.push(control);
+  });
+
+  return controls;
+};
+
+export const Playground = ({ component: componentName }) => {
+
+  const config = COMPONENT_CONFIGS[componentName.toLowerCase()];
+
+  if (!config) {
+    return (
+      <div>Component "{componentName}" not found in playground config</div>
+    );
+  }
+
+  const controls = transformArgTypesToControls(
+    config.argTypes,
+    componentName.toLowerCase(),
+  );
+
+  // Set display name for code generation
+  const displayName =
+    componentName.charAt(0).toUpperCase() + componentName.slice(1);
+  config.component.displayName = displayName;
+
+  // If using customRender, set its displayName too
+  if (config.customRender) {
+    config.customRender.displayName = displayName;
+  }
+
+  return (
+    <ComponentPlayground
+      component={config.customRender || config.component}
+      defaultProps={config.defaultProps}
+      controls={controls}
+    />
+  );
+};
+
+Playground.propTypes = {
+  component: PropTypes.string.isRequired,
+};
diff --git a/apps/docs/src/examples/components/anchor/AnchorPlayground.js b/apps/docs/src/examples/components/anchor/AnchorPlayground.js
new file mode 100644
index 0000000000..a38aa22982
--- /dev/null
+++ b/apps/docs/src/examples/components/anchor/AnchorPlayground.js
@@ -0,0 +1,147 @@
+/* eslint-disable react/prop-types */
+import React from 'react';
+import { Anchor, Box } from 'grommet';
+import {
+  anchorArgTypes,
+  Default as AnchorDefault,
+} from '@shared/aries-core/src/stories/components/Anchor.stories';
+import {
+  boxArgTypes,
+  Default as BoxDefault,
+} from '@shared/aries-core/src/stories/components/Box.stories.tsx';
+import {
+  ComponentPlayground,
+} from '../../../components/content/ComponentPlayground';
+
+// Extract code from story render function
+const getCodeFromStoryRender = (storyRender, props) => {
+  // Get the function source code as string
+  const renderSource = storyRender.toString();
+
+  // Extract the JSX part - look for the return statement
+  const jsxMatch = renderSource.match(/return\s+([^;]+);?\s*}/);
+  if (!jsxMatch) return null;
+
+  let jsxCode = jsxMatch[1].trim();
+
+  // Clean up the JSX code - remove parentheses if wrapped
+  jsxCode = jsxCode.replace(/^\(/, '').replace(/\)$/, '');
+
+  // Replace {...args} with actual props
+  const propsString = Object.entries(props)
+    .filter(
+      ([, value]) => value !== null && value !== undefined && value !== '',
+    )
+    .map(([key, value]) => {
+      if (typeof value === 'boolean') {
+        return value ? `${key}` : null;
+      }
+      if (typeof value === 'string') {
+        return `${key}="${value}"`;
+      }
+      return null;
+    })
+    .filter(Boolean)
+    .join('\n  ');
+
+  // Replace {...args} with formatted props
+  jsxCode = jsxCode.replace(
+    /\{\.\.\.\w+\}/,
+    propsString ? `\n  ${propsString}\n` : '',
+  );
+
+  // Extract component imports from JSX
+  const componentMatches = jsxCode.match(/<(\w+)/g);
+  const components = [
+    ...new Set(componentMatches?.map(match => match.replace('<', '')) || []),
+  ];
+
+  const importStatement = `import { ${components.join(', ')} } from 'grommet';`;
+
+  return `${importStatement}
+
+${jsxCode}`;
+};
+
+// Component configurations
+const COMPONENT_CONFIGS = {
+  anchor: {
+    component: Anchor,
+    argTypes: anchorArgTypes,
+    defaultProps: AnchorDefault.args,
+  },
+  box: {
+    component: Box,
+    argTypes: boxArgTypes,
+    defaultProps: BoxDefault.args,
+    customRender: BoxDefault.render,
+    // Use story's render function for code generation
+    codeTemplate: props => getCodeFromStoryRender(BoxDefault.render, props),
+  },
+};
+
+// Transform Storybook argTypes to ComponentPlayground controls format
+const transformArgTypesToControls = (argTypes, componentName) => {
+  const controls = [];
+
+  Object.entries(argTypes).forEach(([name, argType]) => {
+    const control = {
+      name,
+      displayLabel:
+        name.charAt(0).toUpperCase() + name.slice(1).replace(/([A-Z])/g, ' $1'),
+    };
+
+    // Determine control type based on Storybook control type
+    const controlType = argType.control?.type;
+
+    if (controlType === 'text') {
+      control.type = 'text';
+    } else if (controlType === 'boolean') {
+      control.type = 'checkbox';
+    } else if (controlType === 'select') {
+      control.type = 'select';
+      control.options = argType.options || [];
+
+      // Special handling for icon type
+      if (argType.mapping) {
+        control.type = 'icon';
+        control.options = argType.options
+          .filter(opt => opt !== 'none')
+          .map(opt => ({ label: opt, value: opt }));
+        // Add None option at the beginning
+        control.options.unshift({ label: 'None', value: null });
+      }
+    }
+
+    // Add conditional visibility for reverse (anchor-specific)
+    if (name === 'reverse' && componentName === 'anchor') {
+      control.showWhen = props => props.icon && props.label;
+    }
+
+    controls.push(control);
+  });
+
+  return controls;
+};
+
+export const Playground = ({ component: componentName }) => {
+  const config = COMPONENT_CONFIGS[componentName.toLowerCase()];
+
+  const controls = transformArgTypesToControls(
+    config.argTypes,
+    componentName.toLowerCase(),
+  );
+
+  // Set display name for code generation
+  config.component.displayName =
+    componentName.charAt(0).toUpperCase() + componentName.slice(1);
+
+  return (
+    <ComponentPlayground
+      component={config.customRender || config.component}
+      defaultProps={config.defaultProps}
+      controls={controls}
+      codeTemplate={config.codeTemplate}
+    />
+  );
+};
diff --git a/apps/docs/src/examples/components/button/ButtonBusyExample.js b/apps/docs/src/examples/components/button/ButtonBusyExample.js
index 350cd0d3d4..402ba559b9 100644
--- a/apps/docs/src/examples/components/button/ButtonBusyExample.js
+++ b/apps/docs/src/examples/components/button/ButtonBusyExample.js
@@ -14,7 +14,7 @@ import { ButtonGroup, ModalDialog } from '@shared/aries-core';
 export const ButtonBusyExample = ({ containerRef }) => {
   const [busy, setBusy] = useState(false);
   const [success, setSuccess] = useState(false);
-  const [showLayer, setShowLayer] = useState(true);
+  const [showLayer, setShowLayer] = useState(false);
 
   const onClose = () => {
     setShowLayer(false);
diff --git a/apps/docs/src/examples/components/button/ButtonPlayground.js b/apps/docs/src/examples/components/button/ButtonPlayground.js
new file mode 100644
index 0000000000..a2d592cce4
--- /dev/null
+++ b/apps/docs/src/examples/components/button/ButtonPlayground.js
@@ -0,0 +1,123 @@
+/* eslint-disable react/prop-types */
+import React from 'react';
+import { Button } from 'grommet';
+import {
+  ComponentPlayground,
+} from '../../../components/content/ComponentPlayground';
+
+// Set display name for code generation
+Button.displayName = 'Button';
+
+export const ButtonPlayground = () => {
+  const buttonControls = [
+    {
+      name: 'label',
+      type: 'text',
+      displayLabel: 'Button Label',
+    },
+    {
+      name: 'icon',
+      type: 'icon',
+      displayLabel: 'Icon',
+      options: [
+        { label: 'None', value: null },
+        { label: 'Add', value: 'Add' },
+        { label: 'Edit', value: 'Edit' },
+        { label: 'Trash', value: 'Trash' },
+        { label: 'Download', value: 'Download' },
+        { label: 'Upload', value: 'Upload' },
+        { label: 'Save', value: 'Save' },
+      ],
+    },
+    {
+      name: 'primary',
+      type: 'checkbox',
+      displayLabel: 'Primary',
+    },
+    {
+      name: 'secondary',
+      type: 'checkbox',
+      displayLabel: 'Secondary',
+    },
+    {
+      name: 'disabled',
+      type: 'checkbox',
+      displayLabel: 'Disabled',
+    },
+    {
+      name: 'active',
+      type: 'checkbox',
+      displayLabel: 'Active',
+    },
+    {
+      name: 'busy',
+      type: 'checkbox',
+      displayLabel: 'Busy',
+    },
+    {
+      name: 'reverse',
+      type: 'checkbox',
+      displayLabel: 'Reverse',
+    },
+    {
+      name: 'size',
+      type: 'select',
+      displayLabel: 'Size',
+      options: ['small', 'medium', 'large'],
+    },
+    {
+      name: 'alignSelf',
+      type: 'select',
+      displayLabel: 'Align Self',
+      options: ['start', 'center', 'end', 'stretch'],
+    },
+    {
+      name: 'justify',
+      type: 'select',
+      displayLabel: 'Justify',
+      options: ['start', 'center', 'end', 'between', 'around'],
+    },
+    {
+      name: 'gap',
+      type: 'select',
+      displayLabel: 'Gap',
+      options: ['xxsmall', 'xsmall', 'small', 'medium', 'large'],
+      showWhen: props => props.icon && props.label,
+    },
+    {
+      name: 'badge',
+      type: 'checkbox',
+      displayLabel: 'Badge',
+    },
+    {
+      name: 'tip',
+      type: 'text',
+      displayLabel: 'Tooltip',
+    },
+  ];
+
+  const defaultProps = {
+    label: 'Button',
+    primary: false,
+    secondary: false,
+    disabled: false,
+    active: false,
+    busy: false,
+    reverse: false,
+    size: 'medium',
+    alignSelf: undefined,
+    justify: undefined,
+    gap: undefined,
+    badge: false,
+    tip: undefined,
+    icon: null,
+  };
+
+  return (
+    <ComponentPlayground
+      component={Button}
+      defaultProps={defaultProps}
+      controls={buttonControls}
+    />
+  );
+};
diff --git a/apps/docs/src/examples/components/button/index.js b/apps/docs/src/examples/components/button/index.js
index 29386f22a3..756ed57f2e 100644
--- a/apps/docs/src/examples/components/button/index.js
+++ b/apps/docs/src/examples/components/button/index.js
@@ -5,6 +5,7 @@ export * from './ButtonBusyExample';
 export * from './ButtonBusySimpleExample';
 export * from './ButtonIconExample';
 export * from './ButtonLeftAlignExample';
+export * from './ButtonPlayground';
 export * from './ButtonRightAlignExample';
 export * from './ButtonSizingExample';
 export * from './ButtonStatesExample';
diff --git a/apps/docs/src/examples/components/index.js b/apps/docs/src/examples/components/index.js
index d48b7b7114..936515ec80 100644
--- a/apps/docs/src/examples/components/index.js
+++ b/apps/docs/src/examples/components/index.js
@@ -2,6 +2,7 @@ export * from './anchor';
 export * from './avatar';
 export * from './button';
 export * from './accordion';
+export * from './Playground';
 export * from './calendar';
 export * from './card';
 export * from './carousel';
diff --git a/apps/docs/src/pages/components/anchor.mdx b/apps/docs/src/pages/components/anchor.mdx
index 990dd34c1d..b7bc69d341 100644
--- a/apps/docs/src/pages/components/anchor.mdx
+++ b/apps/docs/src/pages/components/anchor.mdx
@@ -8,18 +8,12 @@ import {
   AnchorIconExample,
   AnchorGoodExample,
   AnchorInlineExample,
+  Playground,
   SignUpExample,
 } from '../../examples';
 
-<Example
-  componentName="Anchor"
-  designer="https://designer.grommet.io/anchor?id=HPE-design-system-hpedesignsystem-hpe-com&mode=edit"
-  docs="https://v2.grommet.io/anchor?theme=hpe#props"
-  code="https://raw.githubusercontent.com/grommet/hpe-design-system/master/apps/docs/src/examples/components/anchor/AnchorExample.js"
-  grommetSource="https://github.com/grommet/grommet/blob/master/src/js/components/Anchor/Anchor.js"
->
-  <AnchorExample />
-</Example>
+<Playground component="anchor" />
+
 
 ## Guidance
 
diff --git a/apps/docs/src/pages/components/box.mdx b/apps/docs/src/pages/components/box.mdx
index 71c5a46eee..d8f335d514 100644
--- a/apps/docs/src/pages/components/box.mdx
+++ b/apps/docs/src/pages/components/box.mdx
@@ -1,14 +1,8 @@
 import { AccessibilitySection, Example } from '../../layouts';
-import { BoxExample } from '../../examples';
+import { BoxExample, Playground } from '../../examples';
+
+<Playground component="box" />
 
-<Example
-  componentName="Box"
-  docs="https://v2.grommet.io/box?theme=hpe#props"
-  code="https://raw.githubusercontent.com/grommet/hpe-design-system/master/apps/docs/src/examples/components/layouts/BoxExample.js"
-  grommetSource="https://github.com/grommet/grommet/blob/master/src/js/components/Box/Box.js"
->
-  <BoxExample />
-</Example>
 
 ## Accessibility
 
diff --git a/apps/docs/src/pages/components/button.mdx b/apps/docs/src/pages/components/button.mdx
index 04805b4f69..5d06885b81 100644
--- a/apps/docs/src/pages/components/button.mdx
+++ b/apps/docs/src/pages/components/button.mdx
@@ -17,6 +17,7 @@ import {
   ButtonGoodSignUpPreview,
   ButtonIconExample,
   ButtonLeftAlignExample,
+  ButtonPlayground,
   ButtonRightAlignExample,
   ButtonStatesExample,
   ButtonSizingExample,
@@ -26,6 +27,8 @@ import {
   ToolbarButtonExample,
 } from '../../examples';
 
+<ButtonPlayground />
+
 <Example
   componentName="Button"
   code="https://raw.githubusercontent.com/grommet/hpe-design-system/master/apps/docs/src/examples/components/button/DefaultButtonExample.js"
diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml
index acb36479fe..e790ff7548 100644
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@@ -23,7 +23,7 @@ catalogs:
       version: 8.57.1
     grommet:
       specifier: ^2.52.0
-      version: 2.51.0
+      version: 2.53.0
     grommet-icons:
       specifier: ^4.14.0
       version: 4.14.0
@@ -66,10 +66,10 @@ importers:
         version: 1.1.0(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet:
         specifier: 'catalog:'
-        version: 2.52.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+        version: 2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet-theme-hpe:
         specifier: 'catalog:'
-        version: 8.0.0(@hpe-design/icons-grommet@1.1.0(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.52.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+        version: 8.0.0(@hpe-design/icons-grommet@1.1.0(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       styled-components:
         specifier: 'catalog:'
         version: 6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)
@@ -133,13 +133,13 @@ importers:
         version: 1.1.0(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet:
         specifier: 'catalog:'
-        version: 2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+        version: 2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet-icons:
         specifier: 'catalog:'
         version: 4.14.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet-theme-hpe:
         specifier: ^6.0.0
-        version: 6.5.1(grommet-icons@4.14.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+        version: 6.5.1(grommet-icons@4.14.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       hpe-design-tokens:
         specifier: workspace:*
         version: link:../../packages/hpe-design-tokens
@@ -192,9 +192,30 @@ importers:
 
   apps/docs:
     dependencies:
+      '@codemirror/commands':
+        specifier: ^6.10.1
+        version: 6.10.1
+      '@codemirror/lang-javascript':
+        specifier: ^6.2.4
+        version: 6.2.4
+      '@codemirror/language':
+        specifier: ^6.12.1
+        version: 6.12.1
+      '@codemirror/state':
+        specifier: ^6.5.4
+        version: 6.5.4
+      '@codemirror/theme-one-dark':
+        specifier: ^6.1.3
+        version: 6.1.3
+      '@codemirror/view':
+        specifier: ^6.39.12
+        version: 6.39.12
       '@hpe-design/icons-grommet':
         specifier: 'catalog:'
         version: 1.1.0(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+      '@lezer/highlight':
+        specifier: ^1.2.3
+        version: 1.2.3
       '@mdx-js/loader':
         specifier: ^3.0.1
         version: 3.1.1(webpack@5.102.1)
@@ -207,9 +228,12 @@ importers:
       '@shared/aries-core':
         specifier: workspace:*
         version: link:../../shared/aries-core
+      '@uiw/codemirror-theme-github':
+        specifier: ^4.25.4
+        version: 4.25.4(@codemirror/language@6.12.1)(@codemirror/state@6.5.4)(@codemirror/view@6.39.12)
       grommet:
         specifier: 'catalog:'
-        version: 2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+        version: 2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet-icons:
         specifier: catalog:grommet-stable
         version: https://github.com/grommet/grommet-icons/tarball/stable(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
@@ -258,7 +282,7 @@ importers:
         version: 2.1.4(@babel/core@7.28.5)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet-theme-hpe:
         specifier: 'catalog:'
-        version: 8.0.0(@hpe-design/icons-grommet@1.1.0(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+        version: 8.0.0(@hpe-design/icons-grommet@1.1.0(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       next-transpile-modules:
         specifier: ^10.0.1
         version: 10.0.1
@@ -370,7 +394,7 @@ importers:
         version: 16.5.0
       grommet-theme-hpe:
         specifier: catalog:grommet-theme-hpe-v7
-        version: 7.0.2(grommet-icons@4.14.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.52.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+        version: 7.0.2(grommet-icons@4.14.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       minimatch:
         specifier: ^10.0.3
         version: 10.1.1
@@ -415,16 +439,16 @@ importers:
         version: 1.1.0(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet:
         specifier: 'catalog:'
-        version: 2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+        version: 2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet-icons:
         specifier: catalog:grommet-stable
         version: https://github.com/grommet/grommet-icons/tarball/stable(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet-theme-hpe-v5:
         specifier: npm:grommet-theme-hpe@5.8.0
-        version: grommet-theme-hpe@5.8.0(grommet-icons@https://github.com/grommet/grommet-icons/tarball/stable(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+        version: grommet-theme-hpe@5.8.0(grommet-icons@https://github.com/grommet/grommet-icons/tarball/stable(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet-theme-hpe-v6:
         specifier: npm:grommet-theme-hpe@6
-        version: grommet-theme-hpe@6.5.1(grommet-icons@https://github.com/grommet/grommet-icons/tarball/stable(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+        version: grommet-theme-hpe@6.5.1(grommet-icons@https://github.com/grommet/grommet-icons/tarball/stable(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       gsap:
         specifier: ^3.12.5
         version: 3.13.0
@@ -553,13 +577,13 @@ importers:
         version: link:../hooks
       grommet:
         specifier: 'catalog:'
-        version: 2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+        version: 2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet-icons:
         specifier: 'catalog:'
         version: 4.14.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet-theme-hpe:
         specifier: 'catalog:'
-        version: 8.0.0(@hpe-design/icons-grommet@1.1.0(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+        version: 8.0.0(@hpe-design/icons-grommet@1.1.0(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       prop-types:
         specifier: 'catalog:'
         version: 15.8.1
@@ -1610,6 +1634,30 @@ packages:
   '@changesets/write@0.4.0':
     resolution: {integrity: sha512-CdTLvIOPiCNuH71pyDu3rA+Q0n65cmAbXnwWH84rKGiFumFzkmHNT8KHTMEchcxN+Kl8I54xGUhJ7l3E7X396Q==}
 
+  '@codemirror/autocomplete@6.20.0':
+    resolution: {integrity: sha512-bOwvTOIJcG5FVo5gUUupiwYh8MioPLQ4UcqbcRf7UQ98X90tCa9E1kZ3Z7tqwpZxYyOvh1YTYbmZE9RTfTp5hg==}
+
+  '@codemirror/commands@6.10.1':
+    resolution: {integrity: sha512-uWDWFypNdQmz2y1LaNJzK7fL7TYKLeUAU0npEC685OKTF3KcQ2Vu3klIM78D7I6wGhktme0lh3CuQLv0ZCrD9Q==}
+
+  '@codemirror/lang-javascript@6.2.4':
+    resolution: {integrity: sha512-0WVmhp1QOqZ4Rt6GlVGwKJN3KW7Xh4H2q8ZZNGZaP6lRdxXJzmjm4FqvmOojVj6khWJHIb9sp7U/72W7xQgqAA==}
+
+  '@codemirror/language@6.12.1':
+    resolution: {integrity: sha512-Fa6xkSiuGKc8XC8Cn96T+TQHYj4ZZ7RdFmXA3i9xe/3hLHfwPZdM+dqfX0Cp0zQklBKhVD8Yzc8LS45rkqcwpQ==}
+
+  '@codemirror/lint@6.9.3':
+    resolution: {integrity: sha512-y3YkYhdnhjDBAe0VIA0c4wVoFOvnp8CnAvfLqi0TqotIv92wIlAAP7HELOpLBsKwjAX6W92rSflA6an/2zBvXw==}
+
+  '@codemirror/state@6.5.4':
+    resolution: {integrity: sha512-8y7xqG/hpB53l25CIoit9/ngxdfoG+fx+V3SHBrinnhOtLvKHRyAJJuHzkWrR4YXXLX8eXBsejgAAxHUOdW1yw==}
+
+  '@codemirror/theme-one-dark@6.1.3':
+    resolution: {integrity: sha512-NzBdIvEJmx6fjeremiGp3t/okrLPYT0d9orIc7AFun8oZcRk58aejkqhv6spnz4MLAevrKNPMQYXEWMg4s+sKA==}
+
+  '@codemirror/view@6.39.12':
+    resolution: {integrity: sha512-f+/VsHVn/kOA9lltk/GFzuYwVVAKmOnNjxbrhkk3tPHntFqjWeI2TbIXx006YkBkqC10wZ4NsnWXCQiFPeAISQ==}
+
   '@csstools/color-helpers@5.1.0':
     resolution: {integrity: sha512-S11EXWJyy0Mz5SYvRmY8nJYTFFd1LCNV+7cXyAgQtOOuzb4EsgfqDufL+9esx72/eLhsRdGZwaldu/h+E4t4BA==}
     engines: {node: '>=18'}
@@ -2107,105 +2155,89 @@ packages:
     resolution: {integrity: sha512-excjX8DfsIcJ10x1Kzr4RcWe1edC9PquDRRPx3YVCvQv+U5p7Yin2s32ftzikXojb1PIFc/9Mt28/y+iRklkrw==}
     cpu: [arm64]
     os: [linux]
-    libc: [glibc]
 
   '@img/sharp-libvips-linux-arm@1.2.4':
     resolution: {integrity: sha512-bFI7xcKFELdiNCVov8e44Ia4u2byA+l3XtsAj+Q8tfCwO6BQ8iDojYdvoPMqsKDkuoOo+X6HZA0s0q11ANMQ8A==}
     cpu: [arm]
     os: [linux]
-    libc: [glibc]
 
   '@img/sharp-libvips-linux-ppc64@1.2.4':
     resolution: {integrity: sha512-FMuvGijLDYG6lW+b/UvyilUWu5Ayu+3r2d1S8notiGCIyYU/76eig1UfMmkZ7vwgOrzKzlQbFSuQfgm7GYUPpA==}
     cpu: [ppc64]
     os: [linux]
-    libc: [glibc]
 
   '@img/sharp-libvips-linux-riscv64@1.2.4':
     resolution: {integrity: sha512-oVDbcR4zUC0ce82teubSm+x6ETixtKZBh/qbREIOcI3cULzDyb18Sr/Wcyx7NRQeQzOiHTNbZFF1UwPS2scyGA==}
     cpu: [riscv64]
     os: [linux]
-    libc: [glibc]
 
   '@img/sharp-libvips-linux-s390x@1.2.4':
     resolution: {integrity: sha512-qmp9VrzgPgMoGZyPvrQHqk02uyjA0/QrTO26Tqk6l4ZV0MPWIW6LTkqOIov+J1yEu7MbFQaDpwdwJKhbJvuRxQ==}
     cpu: [s390x]
     os: [linux]
-    libc: [glibc]
 
   '@img/sharp-libvips-linux-x64@1.2.4':
     resolution: {integrity: sha512-tJxiiLsmHc9Ax1bz3oaOYBURTXGIRDODBqhveVHonrHJ9/+k89qbLl0bcJns+e4t4rvaNBxaEZsFtSfAdquPrw==}
     cpu: [x64]
     os: [linux]
-    libc: [glibc]
 
   '@img/sharp-libvips-linuxmusl-arm64@1.2.4':
     resolution: {integrity: sha512-FVQHuwx1IIuNow9QAbYUzJ+En8KcVm9Lk5+uGUQJHaZmMECZmOlix9HnH7n1TRkXMS0pGxIJokIVB9SuqZGGXw==}
     cpu: [arm64]
     os: [linux]
-    libc: [musl]
 
   '@img/sharp-libvips-linuxmusl-x64@1.2.4':
     resolution: {integrity: sha512-+LpyBk7L44ZIXwz/VYfglaX/okxezESc6UxDSoyo2Ks6Jxc4Y7sGjpgU9s4PMgqgjj1gZCylTieNamqA1MF7Dg==}
     cpu: [x64]
     os: [linux]
-    libc: [musl]
 
   '@img/sharp-linux-arm64@0.34.5':
     resolution: {integrity: sha512-bKQzaJRY/bkPOXyKx5EVup7qkaojECG6NLYswgktOZjaXecSAeCWiZwwiFf3/Y+O1HrauiE3FVsGxFg8c24rZg==}
     engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [arm64]
     os: [linux]
-    libc: [glibc]
 
   '@img/sharp-linux-arm@0.34.5':
     resolution: {integrity: sha512-9dLqsvwtg1uuXBGZKsxem9595+ujv0sJ6Vi8wcTANSFpwV/GONat5eCkzQo/1O6zRIkh0m/8+5BjrRr7jDUSZw==}
     engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [arm]
     os: [linux]
-    libc: [glibc]
 
   '@img/sharp-linux-ppc64@0.34.5':
     resolution: {integrity: sha512-7zznwNaqW6YtsfrGGDA6BRkISKAAE1Jo0QdpNYXNMHu2+0dTrPflTLNkpc8l7MUP5M16ZJcUvysVWWrMefZquA==}
     engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [ppc64]
     os: [linux]
-    libc: [glibc]
 
   '@img/sharp-linux-riscv64@0.34.5':
     resolution: {integrity: sha512-51gJuLPTKa7piYPaVs8GmByo7/U7/7TZOq+cnXJIHZKavIRHAP77e3N2HEl3dgiqdD/w0yUfiJnII77PuDDFdw==}
     engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [riscv64]
     os: [linux]
-    libc: [glibc]
 
   '@img/sharp-linux-s390x@0.34.5':
     resolution: {integrity: sha512-nQtCk0PdKfho3eC5MrbQoigJ2gd1CgddUMkabUj+rBevs8tZ2cULOx46E7oyX+04WGfABgIwmMC0VqieTiR4jg==}
     engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [s390x]
     os: [linux]
-    libc: [glibc]
 
   '@img/sharp-linux-x64@0.34.5':
     resolution: {integrity: sha512-MEzd8HPKxVxVenwAa+JRPwEC7QFjoPWuS5NZnBt6B3pu7EG2Ge0id1oLHZpPJdn3OQK+BQDiw9zStiHBTJQQQQ==}
     engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [x64]
     os: [linux]
-    libc: [glibc]
 
   '@img/sharp-linuxmusl-arm64@0.34.5':
     resolution: {integrity: sha512-fprJR6GtRsMt6Kyfq44IsChVZeGN97gTD331weR1ex1c1rypDEABN6Tm2xa1wE6lYb5DdEnk03NZPqA7Id21yg==}
     engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [arm64]
     os: [linux]
-    libc: [musl]
 
   '@img/sharp-linuxmusl-x64@0.34.5':
     resolution: {integrity: sha512-Jg8wNT1MUzIvhBFxViqrEhWDGzqymo3sV7z7ZsaWbZNDLXRJZoRGrjulp60YYtV4wfY8VIKcWidjojlLcWrd8Q==}
     engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [x64]
     os: [linux]
-    libc: [musl]
 
   '@img/sharp-wasm32@0.34.5':
     resolution: {integrity: sha512-OdWTEiVkY2PHwqkbBI8frFxQQFekHaSSkUIJkwzclWZe64O1X4UlUjqqqLaPbUpMOQk6FBu/HtlGXNblIs0huw==}
@@ -2410,12 +2442,27 @@ packages:
   '@leichtgewicht/ip-codec@2.0.5':
     resolution: {integrity: sha512-Vo+PSpZG2/fmgmiNzYK9qWRh8h/CHrwD0mo1h1DzL4yzHNSfWYujGTYsWGreD000gcgmZ7K4Ys6Tx9TxtsKdDw==}
 
+  '@lezer/common@1.5.1':
+    resolution: {integrity: sha512-6YRVG9vBkaY7p1IVxL4s44n5nUnaNnGM2/AckNgYOnxTG2kWh1vR8BMxPseWPjRNpb5VtXnMpeYAEAADoRV1Iw==}
+
+  '@lezer/highlight@1.2.3':
+    resolution: {integrity: sha512-qXdH7UqTvGfdVBINrgKhDsVTJTxactNNxLk7+UMwZhU13lMHaOBlJe9Vqp907ya56Y3+ed2tlqzys7jDkTmW0g==}
+
+  '@lezer/javascript@1.5.4':
+    resolution: {integrity: sha512-vvYx3MhWqeZtGPwDStM2dwgljd5smolYD2lR2UyFcHfxbBQebqx8yjmFmxtJ/E6nN6u1D9srOiVWm3Rb4tmcUA==}
+
+  '@lezer/lr@1.4.8':
+    resolution: {integrity: sha512-bPWa0Pgx69ylNlMlPvBPryqeLYQjyJjqPx+Aupm5zydLIF3NE+6MMLT8Yi23Bd9cif9VS00aUebn+6fDIGBcDA==}
+
   '@manypkg/find-root@1.1.0':
     resolution: {integrity: sha512-mki5uBvhHzO8kYYix/WRy2WX8S3B5wdVSc9D6KcU5lQNglP2yt58/VfLuAK49glRXChosY8ap2oJ1qgma3GUVA==}
 
   '@manypkg/get-packages@1.1.3':
     resolution: {integrity: sha512-fo+QhuU3qE/2TQMQmbVMqaQ6EWbMhi4ABWP+O4AM1NqPBuy0OrApV5LO6BrrgnhtAHS2NH6RrVk9OL181tTi8A==}
 
+  '@marijn/find-cluster-break@1.0.2':
+    resolution: {integrity: sha512-l0h88YhZFyKdXIFNfSWpyjStDjGHwZ/U7iobcK1cQQD8sejsONdQtTVU+1wVN1PBw40PiiHB1vA5S7VTfQiP9g==}
+
   '@mdx-js/loader@3.1.1':
     resolution: {integrity: sha512-0TTacJyZ9mDmY+VefuthVshaNIyCGZHJG2fMnGaDttCt8HmjUF7SizlHJpaCDoGnN635nK1wpzfpx/Xx5S4WnQ==}
     peerDependencies:
@@ -2477,28 +2524,24 @@ packages:
     engines: {node: '>= 10'}
     cpu: [arm64]
     os: [linux]
-    libc: [glibc]
 
   '@next/swc-linux-arm64-musl@15.5.7':
     resolution: {integrity: sha512-nfymt+SE5cvtTrG9u1wdoxBr9bVB7mtKTcj0ltRn6gkP/2Nu1zM5ei8rwP9qKQP0Y//umK+TtkKgNtfboBxRrw==}
     engines: {node: '>= 10'}
     cpu: [arm64]
     os: [linux]
-    libc: [musl]
 
   '@next/swc-linux-x64-gnu@15.5.7':
     resolution: {integrity: sha512-hvXcZvCaaEbCZcVzcY7E1uXN9xWZfFvkNHwbe/n4OkRhFWrs1J1QV+4U1BN06tXLdaS4DazEGXwgqnu/VMcmqw==}
     engines: {node: '>= 10'}
     cpu: [x64]
     os: [linux]
-    libc: [glibc]
 
   '@next/swc-linux-x64-musl@15.5.7':
     resolution: {integrity: sha512-4IUO539b8FmF0odY6/SqANJdgwn1xs1GkPO5doZugwZ3ETF6JUdckk7RGmsfSf7ws8Qb2YB5It33mvNL/0acqA==}
     engines: {node: '>= 10'}
     cpu: [x64]
     os: [linux]
-    libc: [musl]
 
   '@next/swc-win32-arm64-msvc@15.5.7':
     resolution: {integrity: sha512-CpJVTkYI3ZajQkC5vajM7/ApKJUOlm6uP4BknM3XKvJ7VXAvCqSjSLmM0LKdYzn6nBJVSjdclx8nYJSa3xlTgQ==}
@@ -2857,67 +2900,56 @@ packages:
     resolution: {integrity: sha512-EPlb95nUsz6Dd9Qy13fI5kUPXNSljaG9FiJ4YUGU1O/Q77i5DYFW5KR8g1OzTcdZUqQQ1KdDqsTohdFVwCwjqg==}
     cpu: [arm]
     os: [linux]
-    libc: [glibc]
 
   '@rollup/rollup-linux-arm-musleabihf@4.53.2':
     resolution: {integrity: sha512-BOmnVW+khAUX+YZvNfa0tGTEMVVEerOxN0pDk2E6N6DsEIa2Ctj48FOMfNDdrwinocKaC7YXUZ1pHlKpnkja/Q==}
     cpu: [arm]
     os: [linux]
-    libc: [musl]
 
   '@rollup/rollup-linux-arm64-gnu@4.53.2':
     resolution: {integrity: sha512-Xt2byDZ+6OVNuREgBXr4+CZDJtrVso5woFtpKdGPhpTPHcNG7D8YXeQzpNbFRxzTVqJf7kvPMCub/pcGUWgBjA==}
     cpu: [arm64]
     os: [linux]
-    libc: [glibc]
 
   '@rollup/rollup-linux-arm64-musl@4.53.2':
     resolution: {integrity: sha512-+LdZSldy/I9N8+klim/Y1HsKbJ3BbInHav5qE9Iy77dtHC/pibw1SR/fXlWyAk0ThnpRKoODwnAuSjqxFRDHUQ==}
     cpu: [arm64]
     os: [linux]
-    libc: [musl]
 
   '@rollup/rollup-linux-loong64-gnu@4.53.2':
     resolution: {integrity: sha512-8ms8sjmyc1jWJS6WdNSA23rEfdjWB30LH8Wqj0Cqvv7qSHnvw6kgMMXRdop6hkmGPlyYBdRPkjJnj3KCUHV/uQ==}
     cpu: [loong64]
     os: [linux]
-    libc: [glibc]
 
   '@rollup/rollup-linux-ppc64-gnu@4.53.2':
     resolution: {integrity: sha512-3HRQLUQbpBDMmzoxPJYd3W6vrVHOo2cVW8RUo87Xz0JPJcBLBr5kZ1pGcQAhdZgX9VV7NbGNipah1omKKe23/g==}
     cpu: [ppc64]
     os: [linux]
-    libc: [glibc]
 
   '@rollup/rollup-linux-riscv64-gnu@4.53.2':
     resolution: {integrity: sha512-fMjKi+ojnmIvhk34gZP94vjogXNNUKMEYs+EDaB/5TG/wUkoeua7p7VCHnE6T2Tx+iaghAqQX8teQzcvrYpaQA==}
     cpu: [riscv64]
     os: [linux]
-    libc: [glibc]
 
   '@rollup/rollup-linux-riscv64-musl@4.53.2':
     resolution: {integrity: sha512-XuGFGU+VwUUV5kLvoAdi0Wz5Xbh2SrjIxCtZj6Wq8MDp4bflb/+ThZsVxokM7n0pcbkEr2h5/pzqzDYI7cCgLQ==}
     cpu: [riscv64]
     os: [linux]
-    libc: [musl]
 
   '@rollup/rollup-linux-s390x-gnu@4.53.2':
     resolution: {integrity: sha512-w6yjZF0P+NGzWR3AXWX9zc0DNEGdtvykB03uhonSHMRa+oWA6novflo2WaJr6JZakG2ucsyb+rvhrKac6NIy+w==}
     cpu: [s390x]
     os: [linux]
-    libc: [glibc]
 
   '@rollup/rollup-linux-x64-gnu@4.53.2':
     resolution: {integrity: sha512-yo8d6tdfdeBArzC7T/PnHd7OypfI9cbuZzPnzLJIyKYFhAQ8SvlkKtKBMbXDxe1h03Rcr7u++nFS7tqXz87Gtw==}
     cpu: [x64]
     os: [linux]
-    libc: [glibc]
 
   '@rollup/rollup-linux-x64-musl@4.53.2':
     resolution: {integrity: sha512-ah59c1YkCxKExPP8O9PwOvs+XRLKwh/mV+3YdKqQ5AMQ0r4M4ZDuOrpWkUaqO7fzAHdINzV9tEVu8vNw48z0lA==}
     cpu: [x64]
     os: [linux]
-    libc: [musl]
 
   '@rollup/rollup-openharmony-arm64@4.53.2':
     resolution: {integrity: sha512-4VEd19Wmhr+Zy7hbUsFZ6YXEiP48hE//KPLCSVNY5RMGX2/7HZ+QkN55a3atM1C/BZCGIgqN+xrVgtdak2S9+A==}
@@ -3287,28 +3319,24 @@ packages:
     engines: {node: '>=10'}
     cpu: [arm64]
     os: [linux]
-    libc: [glibc]
 
   '@swc/core-linux-arm64-musl@1.15.2':
     resolution: {integrity: sha512-5av6VYZZeneiYIodwzGMlnyVakpuYZryGzFIbgu1XP8wVylZxduEzup4eP8atiMDFmIm+s4wn8GySJmYqeJC0A==}
     engines: {node: '>=10'}
     cpu: [arm64]
     os: [linux]
-    libc: [musl]
 
   '@swc/core-linux-x64-gnu@1.15.2':
     resolution: {integrity: sha512-1nO/UfdCLuT/uE/7oB3EZgTeZDCIa6nL72cFEpdegnqpJVNDI6Qb8U4g/4lfVPkmHq2lvxQ0L+n+JdgaZLhrRA==}
     engines: {node: '>=10'}
     cpu: [x64]
     os: [linux]
-    libc: [glibc]
 
   '@swc/core-linux-x64-musl@1.15.2':
     resolution: {integrity: sha512-Ksfrb0Tx310kr+TLiUOvB/I80lyZ3lSOp6cM18zmNRT/92NB4mW8oX2Jo7K4eVEI2JWyaQUAFubDSha2Q+439A==}
     engines: {node: '>=10'}
     cpu: [x64]
     os: [linux]
-    libc: [musl]
 
   '@swc/core-win32-arm64-msvc@1.15.2':
     resolution: {integrity: sha512-IzUb5RlMUY0r1A9IuJrQ7Tbts1wWb73/zXVXT8VhewbHGoNlBKE0qUhKMED6Tv4wDF+pmbtUJmKXDthytAvLmg==}
@@ -3728,6 +3756,16 @@ packages:
     resolution: {integrity: sha512-SIV3/6eftCy1bNzCQoPmbWsRLujS8t5iDIZ4spZOBHqrM+yfX2ogg8Tt3PDTAVKw3sSCiUgg30uOAvK2r9zGjQ==}
     engines: {node: ^18.18.0 || ^20.9.0 || >=21.1.0}
 
+  '@uiw/codemirror-theme-github@4.25.4':
+    resolution: {integrity: sha512-M5zRT2vIpNsuKN0Lz+DwLnmhHW8Eddp1M9zC0hm3V+bvffmaSn/pUDey1eqGIv5xNNmjhqvDAz0a90xLYCzvSw==}
+
+  '@uiw/codemirror-themes@4.25.4':
+    resolution: {integrity: sha512-2SLktItgcZC4p0+PfFusEbAHwbuAWe3bOOntCevVgHtrWGtGZX3IPv2k8IKZMgOXtAHyGKpJvT9/nspPn/uCQg==}
+    peerDependencies:
+      '@codemirror/language': '>=6.0.0'
+      '@codemirror/state': '>=6.0.0'
+      '@codemirror/view': '>=6.0.0'
+
   '@ungap/structured-clone@1.3.0':
     resolution: {integrity: sha512-WmoN8qaIAo7WTYWbAZuG8PYEhn5fkz7dZrqTBZ7dtt//lL2Gwms1IcnQ5yHqjDfX8Ft5j4YzDM23f87zBfDe9g==}
 
@@ -4700,6 +4738,9 @@ packages:
       typescript:
         optional: true
 
+  crelt@1.0.6:
+    resolution: {integrity: sha512-VQ2MBenTq1fWZUH9DJNGti7kKv6EeAuYr3cLwxUWhIu1baTaXh4Ib5W2CqHVqib4/MqbYGJqiL3Zb8GJZr3l4g==}
+
   cross-spawn@7.0.6:
     resolution: {integrity: sha512-uV2QOWP2nWzsy2aMp8aRibhi9dlzF5Hgh5SHaB9OiTGEyDTiJJyx0uy51QXdyWbtAHNua4XJzUKca3OzKUd3vA==}
     engines: {node: '>= 8'}
@@ -5775,7 +5816,7 @@ packages:
   glob@8.1.0:
     resolution: {integrity: sha512-r8hpEjiQEYlF2QU0df3dS+nxxSIreXQS1qRhMJM0Q5NDdR386C7jb7Hwwod8Fgiuex+k0GFjgft18yvxm5XoCQ==}
     engines: {node: '>=12'}
-    deprecated: Glob versions prior to v9 are no longer supported
+    deprecated: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me
 
   globals@13.24.0:
     resolution: {integrity: sha512-AhO5QUcj8llrbG09iWhPU2B204J1xnPeL8kQmVorSsy+Sjj1sk8gIyh6cUocGmH4L0UuhAJy+hJMRA4mgA4mFQ==}
@@ -5866,16 +5907,8 @@ packages:
       react: ^16.13.1 || ^17.0.1 || ^18.0.0 || ^19.0.0
       styled-components: ^6.0.0
 
-  grommet@2.51.0:
-    resolution: {integrity: sha512-PN7GRCX6TxDoEpzbQBQuooMFYOLEkZpooqw1QlsC3X4LvMxBjQOKWl1x26CUI9lbktQFHGnZEgpX8MdK8Nrl3w==}
-    engines: {node: '>= 16'}
-    peerDependencies:
-      react: ^16.6.1 || ^17.0.0 || ^18.0.0 || ^19.0.0
-      react-dom: ^16.6.1 || ^17.0.0 || ^18.0.0 || ^19.0.0
-      styled-components: ^5.1.0 || ^6.0.0
-
-  grommet@2.52.0:
-    resolution: {integrity: sha512-q5Dh0O4QpkKz9fWrOboe+A8G086jNFUz80mPt2mMDhm3wW+YLBrHmwPEzGF8Tu4h1eSfrY7YzdZylVWEr+Zovg==}
+  grommet@2.53.0:
+    resolution: {integrity: sha512-80UwAKI75pBr96UPEye66+5ZffmDfAe647XrkKBKTTMn7b37hWVQ4ros0S1ztxHcrNrfSm/2SfLwuA7y89rvcQ==}
     engines: {node: '>= 16'}
     peerDependencies:
       react: ^16.6.1 || ^17.0.0 || ^18.0.0 || ^19.0.0
@@ -8599,6 +8632,9 @@ packages:
     peerDependencies:
       webpack: ^5.27.0
 
+  style-mod@4.1.3:
+    resolution: {integrity: sha512-i/n8VsZydrugj3Iuzll8+x/00GH2vnYsk1eomD8QiRrSAeW6ItbCQDtfXCeJHd0iwiNagqjQkvpvREEPtW3IoQ==}
+
   style-to-js@1.1.21:
     resolution: {integrity: sha512-RjQetxJrrUJLQPHbLku6U/ocGtzyjbJMP9lCNK7Ag0CNh690nSH8woqWH9u16nMjYBAok+i7JO1NP2pOy8IsPQ==}
 
@@ -9301,6 +9337,9 @@ packages:
     resolution: {integrity: sha512-z8P5DvDNjKDoFIHK7q8r8lackT6l+jo/Ye3HOle7l9nICP9lf1Ci25fy9vHd0JOWewkIFzXIEig3TdKT7JQ5fQ==}
     deprecated: Use your platform's native performance.now() and performance.timeOrigin.
 
+  w3c-keyname@2.2.8:
+    resolution: {integrity: sha512-dpojBhNsCNN7T82Tm7k26A6G9ML3NkhDsnw9n/eoxSRlVBB4CEtIQ/KTCLI2Fwf3ataSXRhYFkQi3SlnFwPvPQ==}
+
   w3c-xmlserializer@2.0.0:
     resolution: {integrity: sha512-4tzD0mF8iSiMiNs30BiLO3EpfGLZUT2MSX/G+o7ZywDzliWQ3OPtTZ0PTC3B3ca1UAf4cJMHB+2Bf56EriJuRA==}
     engines: {node: '>=10'}
@@ -10911,6 +10950,63 @@ snapshots:
       human-id: 4.1.2
       prettier: 2.8.8
 
+  '@codemirror/autocomplete@6.20.0':
+    dependencies:
+      '@codemirror/language': 6.12.1
+      '@codemirror/state': 6.5.4
+      '@codemirror/view': 6.39.12
+      '@lezer/common': 1.5.1
+
+  '@codemirror/commands@6.10.1':
+    dependencies:
+      '@codemirror/language': 6.12.1
+      '@codemirror/state': 6.5.4
+      '@codemirror/view': 6.39.12
+      '@lezer/common': 1.5.1
+
+  '@codemirror/lang-javascript@6.2.4':
+    dependencies:
+      '@codemirror/autocomplete': 6.20.0
+      '@codemirror/language': 6.12.1
+      '@codemirror/lint': 6.9.3
+      '@codemirror/state': 6.5.4
+      '@codemirror/view': 6.39.12
+      '@lezer/common': 1.5.1
+      '@lezer/javascript': 1.5.4
+
+  '@codemirror/language@6.12.1':
+    dependencies:
+      '@codemirror/state': 6.5.4
+      '@codemirror/view': 6.39.12
+      '@lezer/common': 1.5.1
+      '@lezer/highlight': 1.2.3
+      '@lezer/lr': 1.4.8
+      style-mod: 4.1.3
+
+  '@codemirror/lint@6.9.3':
+    dependencies:
+      '@codemirror/state': 6.5.4
+      '@codemirror/view': 6.39.12
+      crelt: 1.0.6
+
+  '@codemirror/state@6.5.4':
+    dependencies:
+      '@marijn/find-cluster-break': 1.0.2
+
+  '@codemirror/theme-one-dark@6.1.3':
+    dependencies:
+      '@codemirror/language': 6.12.1
+      '@codemirror/state': 6.5.4
+      '@codemirror/view': 6.39.12
+      '@lezer/highlight': 1.2.3
+
+  '@codemirror/view@6.39.12':
+    dependencies:
+      '@codemirror/state': 6.5.4
+      crelt: 1.0.6
+      style-mod: 4.1.3
+      w3c-keyname: 2.2.8
+
   '@csstools/color-helpers@5.1.0': {}
 
   '@csstools/css-calc@2.1.4(@csstools/css-parser-algorithms@3.0.5(@csstools/css-tokenizer@3.0.4))(@csstools/css-tokenizer@3.0.4)':
@@ -11626,6 +11722,22 @@ snapshots:
 
   '@leichtgewicht/ip-codec@2.0.5': {}
 
+  '@lezer/common@1.5.1': {}
+
+  '@lezer/highlight@1.2.3':
+    dependencies:
+      '@lezer/common': 1.5.1
+
+  '@lezer/javascript@1.5.4':
+    dependencies:
+      '@lezer/common': 1.5.1
+      '@lezer/highlight': 1.2.3
+      '@lezer/lr': 1.4.8
+
+  '@lezer/lr@1.4.8':
+    dependencies:
+      '@lezer/common': 1.5.1
+
   '@manypkg/find-root@1.1.0':
     dependencies:
       '@babel/runtime': 7.28.4
@@ -11642,6 +11754,8 @@ snapshots:
       globby: 11.1.0
       read-yaml-file: 1.1.0
 
+  '@marijn/find-cluster-break@1.0.2': {}
+
   '@mdx-js/loader@3.1.1(webpack@5.102.1)':
     dependencies:
       '@mdx-js/mdx': 3.1.1
@@ -13127,6 +13241,20 @@ snapshots:
       '@typescript-eslint/types': 8.47.0
       eslint-visitor-keys: 4.2.1
 
+  '@uiw/codemirror-theme-github@4.25.4(@codemirror/language@6.12.1)(@codemirror/state@6.5.4)(@codemirror/view@6.39.12)':
+    dependencies:
+      '@uiw/codemirror-themes': 4.25.4(@codemirror/language@6.12.1)(@codemirror/state@6.5.4)(@codemirror/view@6.39.12)
+    transitivePeerDependencies:
+      - '@codemirror/language'
+      - '@codemirror/state'
+      - '@codemirror/view'
+
+  '@uiw/codemirror-themes@4.25.4(@codemirror/language@6.12.1)(@codemirror/state@6.5.4)(@codemirror/view@6.39.12)':
+    dependencies:
+      '@codemirror/language': 6.12.1
+      '@codemirror/state': 6.5.4
+      '@codemirror/view': 6.39.12
+
   '@ungap/structured-clone@1.3.0': {}
 
   '@vitejs/plugin-react@4.7.0(vite@5.4.21(@types/node@20.19.25)(terser@5.44.1))':
@@ -14200,6 +14328,8 @@ snapshots:
     optionalDependencies:
       typescript: 5.9.3
 
+  crelt@1.0.6: {}
+
   cross-spawn@7.0.6:
     dependencies:
       path-key: 3.1.1
@@ -15650,64 +15780,46 @@ snapshots:
       react-dom: 19.2.3(react@19.2.3)
       styled-components: 6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)
 
-  grommet-theme-hpe@5.8.0(grommet-icons@https://github.com/grommet/grommet-icons/tarball/stable(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)):
+  grommet-theme-hpe@5.8.0(grommet-icons@https://github.com/grommet/grommet-icons/tarball/stable(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)):
     dependencies:
-      grommet: 2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+      grommet: 2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet-icons: https://github.com/grommet/grommet-icons/tarball/stable(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       react: 19.2.3
       styled-components: 6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)
 
-  grommet-theme-hpe@6.5.1(grommet-icons@4.14.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)):
+  grommet-theme-hpe@6.5.1(grommet-icons@4.14.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)):
     dependencies:
-      grommet: 2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+      grommet: 2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet-icons: 4.14.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       hpe-design-tokens: 1.4.1
       react: 19.2.3
       styled-components: 6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)
 
-  grommet-theme-hpe@6.5.1(grommet-icons@https://github.com/grommet/grommet-icons/tarball/stable(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)):
+  grommet-theme-hpe@6.5.1(grommet-icons@https://github.com/grommet/grommet-icons/tarball/stable(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)):
     dependencies:
-      grommet: 2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+      grommet: 2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet-icons: https://github.com/grommet/grommet-icons/tarball/stable(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       hpe-design-tokens: 1.4.1
       react: 19.2.3
       styled-components: 6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)
 
-  grommet-theme-hpe@7.0.2(grommet-icons@4.14.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.52.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)):
+  grommet-theme-hpe@7.0.2(grommet-icons@4.14.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)):
     dependencies:
-      grommet: 2.52.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+      grommet: 2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       grommet-icons: 4.14.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       hpe-design-tokens: 1.4.1
       react: 19.2.3
       styled-components: 6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)
 
-  grommet-theme-hpe@8.0.0(@hpe-design/icons-grommet@1.1.0(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)):
+  grommet-theme-hpe@8.0.0(@hpe-design/icons-grommet@1.1.0(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)):
     dependencies:
       '@hpe-design/icons-grommet': 1.1.0(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
-      grommet: 2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
+      grommet: 2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
       hpe-design-tokens: 2.1.0
       react: 19.2.3
       styled-components: 6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)
 
-  grommet-theme-hpe@8.0.0(@hpe-design/icons-grommet@1.1.0(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(grommet@2.52.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)):
-    dependencies:
-      '@hpe-design/icons-grommet': 1.1.0(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
-      grommet: 2.52.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
-      hpe-design-tokens: 2.1.0
-      react: 19.2.3
-      styled-components: 6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)
-
-  grommet@2.51.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)):
-    dependencies:
-      '@emotion/is-prop-valid': 1.4.0
-      grommet-icons: 4.14.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
-      markdown-to-jsx: 7.4.4(react@19.2.3)
-      prop-types: 15.8.1
-      react: 19.2.3
-      react-dom: 19.2.3(react@19.2.3)
-      styled-components: 6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)
-
-  grommet@2.52.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)):
+  grommet@2.53.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3)):
     dependencies:
       '@emotion/is-prop-valid': 1.4.0
       grommet-icons: 4.14.0(react-dom@19.2.3(react@19.2.3))(react@19.2.3)(styled-components@6.1.19(react-dom@19.2.3(react@19.2.3))(react@19.2.3))
@@ -19203,6 +19315,8 @@ snapshots:
     dependencies:
       webpack: 5.102.1(@swc/core@1.15.2)(esbuild@0.25.12)(webpack-cli@5.1.4)
 
+  style-mod@4.1.3: {}
+
   style-to-js@1.1.21:
     dependencies:
       style-to-object: 1.0.14
@@ -20075,6 +20189,8 @@ snapshots:
     dependencies:
       browser-process-hrtime: 1.0.0
 
+  w3c-keyname@2.2.8: {}
+
   w3c-xmlserializer@2.0.0:
     dependencies:
       xml-name-validator: 3.0.0
diff --git a/shared/aries-core/src/stories/components/Anchor.stories.js b/shared/aries-core/src/stories/components/Anchor.stories.js
new file mode 100644
index 0000000000..b5e0f4d7a2
--- /dev/null
+++ b/shared/aries-core/src/stories/components/Anchor.stories.js
@@ -0,0 +1,42 @@
+import React from 'react';
+import { Anchor } from 'grommet';
+import {
+  disabledArg,
+  labelArg,
+  textSizesArg,
+  reverseArg,
+  iconArg,
+  a11yTitleArg,
+} from '../utils/commonArgs';
+
+export const anchorArgTypes = {
+  a11yTitle: a11yTitleArg,
+  disabled: disabledArg,
+  icon: iconArg,
+  label: labelArg,
+  href: {
+    control: { type: 'text' },
+  },
+  size: textSizesArg,
+  reverse: reverseArg,
+};
+
+const meta = {
+  title: 'Components/Anchor',
+  component: Anchor,
+  argTypes: anchorArgTypes,
+};
+
+export default meta;
+
+export const Default = {
+  render: args => {
+    return <Anchor {...args} />;
+  },
+  args: {
+    label: 'Link',
+    href: '#',
+    a11yTitle: 'Navigate to link',
+  },
+  name: 'Anchor',
+};
diff --git a/shared/aries-core/src/stories/components/Box.stories.tsx b/shared/aries-core/src/stories/components/Box.stories.tsx
index a6ce3f97cc..6cbe0b96b3 100644
--- a/shared/aries-core/src/stories/components/Box.stories.tsx
+++ b/shared/aries-core/src/stories/components/Box.stories.tsx
@@ -3,10 +3,12 @@ import type { StoryObj } from '@storybook/react';
 import { Box, Text, BoxTypes } from 'grommet';
 import { boxArgs } from '../utils/commonArgs';
 
+export const boxArgTypes = boxArgs;
+
 const meta = {
   title: 'Components/Box',
   component: Box,
-  argTypes: boxArgs,
+  argTypes: boxArgTypes,
 };
 
 export default meta;
diff --git a/shared/aries-core/src/stories/utils/commonArgs.js b/shared/aries-core/src/stories/utils/commonArgs.js
new file mode 100644
index 0000000000..a4e93e1a3e
--- /dev/null
+++ b/shared/aries-core/src/stories/utils/commonArgs.js
@@ -0,0 +1,133 @@
+import React from 'react';
+import { colors, hpe } from 'grommet-theme-hpe';
+import * as Icons from '@hpe-design/icons-grommet';
+
+export const backgroundColors = Object.keys(colors)
+  .filter(key => key.split('-')[0] === 'background')
+  .sort();
+
+export const borderSizes = Object.keys(hpe.global.borderSize);
+
+export const spacingSizes = Object.keys(hpe.global.edgeSize);
+
+export const tShirtSizes = Object.keys(hpe.button.size);
+
+export const textSizes = Object.keys(hpe.text).filter(
+  key => !['extend', 'skeleton'].includes(key),
+);
+
+export const radiusSizes = Object.keys(hpe.global.radius);
+
+export const containerSizes = Object.keys(hpe.global.size);
+
+export const disabledArg = {
+  control: { type: 'boolean' },
+  options: [true, false],
+};
+
+export const fillArg = {
+  control: { type: 'select' },
+  options: [true, false, 'horizontal', 'vertical'],
+};
+
+export const gapArg = {
+  control: { type: 'select' },
+  options: spacingSizes,
+};
+
+export const backgroundArg = {
+  control: { type: 'select' },
+  options: backgroundColors,
+};
+
+export const heightArg = {
+  control: { type: 'select' },
+  options: containerSizes,
+};
+
+export const padArg = {
+  control: { type: 'select' },
+  options: spacingSizes,
+};
+
+export const labelArg = {
+  control: { type: 'text' },
+};
+
+export const a11yTitleArg = {
+  control: { type: 'text' },
+};
+
+export const roundArg = {
+  control: { type: 'select' },
+  options: radiusSizes,
+};
+
+export const textSizesArg = {
+  control: { type: 'select' },
+  options: textSizes,
+};
+
+export const reverseArg = {
+  control: { type: 'boolean' },
+  options: [true, false],
+};
+
+export const widthArg = {
+  control: { type: 'select' },
+  options: containerSizes,
+};
+
+export const alignArg = {
+  control: { type: 'select' },
+  options: ['start', 'center', 'end', 'stretch', 'baseline'],
+};
+
+export const alignContentArg = {
+  control: { type: 'select' },
+  options: ['start', 'center', 'end', 'between', 'around', 'evenly', 'stretch'],
+};
+
+export const borderArg = {
+  control: { type: 'boolean' },
+};
+
+export const elevationArg = {
+  control: { type: 'select' },
+  options: tShirtSizes,
+};
+
+export const skeletonArg = {
+  control: { type: 'boolean' },
+};
+
+export const iconArg = {
+  control: { type: 'select' },
+  options: ['none', ...Object.keys(Icons)],
+  mapping: {
+    none: undefined,
+    ...Object.keys(Icons).reduce((acc, iconName) => {
+      const IconComponent = Icons[iconName];
+      acc[iconName] = React.createElement(IconComponent);
+      return acc;
+    }, {}),
+  },
+};
+
+export const boxArgs = {
+  align: alignArg,
+  alignContent: alignContentArg,
+  background: backgroundArg,
+  border: borderArg,
+  direction: {
+    control: { type: 'select' },
+    options: ['row', 'column', 'row-responsive'],
+  },
+  elevation: elevationArg,
+  fill: fillArg,
+  gap: gapArg,
+  height: heightArg,
+  round: roundArg,
+  skeleton: skeletonArg,
+  width: widthArg,
+};