cagov / design-system Goto Github PK

View Code? Open in Web Editor NEW

79.0 12.0 25.0 14.18 MB

State of California Design System

License: MIT License

SCSS 56.93% HTML 17.15% JavaScript 25.89% Shell 0.02%

design-system's Introduction

California Design System README

About the California Design System

Status

This project is currently in early beta status. It’s used in production on a few sites while we learn and continuously improve.

Part of our early beta includes learning and collaborating with teams. As the project matures we’ll share more details on how we might meld the design system components into the State template.

Why a design system

We built this to address common needs identified by California's Office of Digital Innovation (ODI) and the California Department of Technology (CDT) during development of alpha.ca.gov, covid19.ca.gov and cannabis.ca.gov.

How we work

We start by understanding the needs of residents of California through user research. We use an iterative design and development process to provide services that meet these needs. As we work, we continue to test our principles, designs, and components. We prioritize equity to some degree by ensuring that our code is accessible and performant for all devices and bandwidths. Components pass through stages of alpha, beta and production as they become available to the Design System.

We work in the open: all our code and issue tracking is public. We’re happy to review pull requests from the public and state employees. Anyone can file an issue with bug reports and feature requests by selecting the New issue button from our issues page. You can see the prioritized list of issues we’re addressing on our project board.

Development instructions

This project is a collection of components. This means the individual widgets are easy to iterate on in isolation, upgrade individually, or exclude from a project.

To run this project locally, checkout this repo and run these commands:

npm install
npm run dev

This will start up a local server running the site you see at designsystem.webstandards.ca.gov.

You can find the components in the /components directory. The README for each component is used to create the pages in the Components section. Interactive versions of each component are included in these pages.

Each component is published to npm. The following steps are run in a pre-publish hook in the package.json script. New versions will not publish unless these steps complete:

The sample markup in the README is matched to the sample markup used in the automated test
Any build steps like JavaScript concatenation or Sass compilation are run and resulting files are stored in the /dist folder
Automated tests are run including an axe accessibility checker
The latest version of the component is written to our CDN so it can be included with a script tag

We welcome your component modification requests or suggestions. Create a pull request or open an issue in this repository.

End to end testing

Playwright is used to run end to end and accessibility tests against local site urls using axe.

This set of tests is configured to be run against any open PR in our git actions: validate.yml.

They can be run locally with:

npm run test:site

If you run into test failures due to an axe detected accessibility violation the offending node will be part of the test failure output. You can get more information on this type of failure by using the axe chrome plugin and letting it evaluate the page locally during development.

The playwright test setup uses `http-server' instead of 11ty because axe-playwright flags the browser-sync element that is injected into 11ty's default local serve mode as an accessibility violation for not being included in a landmark element.

Unit tests

Each component contains its own unit tests. The tests for all components are run in sequence when any commit is made in this repo via a husky pre-commit hook. When a package is published its own unit tests are run via an npm prepublish hook configured in the component's package.json

You can run any components tests individually during development with the npm test command inside its directory.

These component unit tests were created following Open Web Components recommendations.

Directory structure

The code for all the components is in /components. Each directory contains the entire package for each component published to npm. The markdown files in each component's directory provide the content used in the component gallery section of the design system site. Any modification to a component's code or documentation should be associated with a new version of the component being published. Publishing a new version of a component to npm will run the scripts that publish its code to the CA CDN. More information on component development in the component readme.

The rest of the site content is in /docs

/docs/pages: markdown for additional pages
/docs/site: templates for site layouts
/docs/src/css/sass/index.scss: site CSS dependencies
/docs/src/js/index.js: site JS dependencies

design-system's People

Contributors

Stargazers

Watchers

Forkers

liznobriga robertmain53 angsv adeguzm1 whyisjake ossd-sp22 saldanaj27 rasmi andy-bond mgifford yasamankamal kaseycusick evilwaredotcom matikin9 seanlanglands tomnk-fork jon-grant-state-ca-gov pan-american-copyright-conventions greg-watanabe

design-system's Issues

Component: Per page Feedback - Backend architecture

The per page feedback component is used in the cannabis site designs as part of the site footer.

In order to be reused in new sites we need to review, upgrade and isolate the backend architecture.

Create new Azure Cosmos DB using production Azure subscription plan
Create new Azure FAAS to receive post data data, this is necessary to secure cosmos connection strings and limit input structure
Test new endpoints with latest frontend component
Design new way to retrieve feedback that allows for multiple site dataset separation.
Currently feedback retrieval is managed via github pages app. Can we use github oauth for cannabis use case?
New feedback review app should be created with existing UI but updated endpoitns and security architecture, separate ticket opened to create and deploy the feedback review application: #22

Component: Branding Block (informs DS)

Create branding component that will include:

brand/logo,
organization/entity/Dept./ project/website name
search input box (search button in mobile)
menu button (in mobile)

This component might include search ID JavaScript code and some expand and collapse functions javaScript code for search and menu buttons in mobile.

Figma link: https://www.figma.com/file/9FTGOPO5HlsLfYuNrtL9IM/cannabis.ca.gov-screens?node-id=381%3A3318

Layout:

Where will this live?
design-system/components/branding/template.html
design-system/components/branding/index.css
design-system/components/branding/index.js

Define new component: Press Release Page Block

We are really excited to share our idea for a design system component.

Our design system team will review this component proposal.

To make sure the component serves all Californians, we have identified some things we need to know about this component.

Please fill in what you can.

Checklist

Name

What should we call this component in conversation?

"Press release page block"

About this component

Please tell us more about the component.

This is a Gutenberg block pattern + child components for creating a press release.

Based on prior WP components (Divi based, from the CA Web theme) the city & post date are separated out, so the plan is to keep the data separated so we can more easily import. Would be nice to keep or update the content tags so editors can find all their press release posts.

Description

Describe how this component will be used.

To publish press releases.

Examples from ca.gov properties

(Can be screenshots, a few examples is great. Please include URLs if the examples are live.) This helps everyone understand what you are referring to.

There are many on cannabis.ca.gov.

Examples from other design systems

If this component is commonly found in other design systems, please link to it. This helps everyone understand real-world examples of this idea.

Don't have any at this time.

Features

Critical features to support initially.

Label: Press release
Post date
City / Location
Body

Requesting agency

Who is requesting this component?

Office of Digital Innovation (ODI) & Department of Cannabis Control (DCC)

code centralizaton: publish base-css component

The base-css component is currently used in both headless cannabis and drought sites. The code required to render it should be published to npm with a readme describing the module and the required package files. The code for the component should be checked into the design-system repository and deleted from the cannabis and drought repositories. The feature should be used in both sites via npm install.

This is a first step towards making this component a member of the design system. We are publishing it in a central location now to prevent code drift.

Component: Site specific footer (informs DS)

California government state sites should have a site specific footer component. This contains sitewide links and logos. The site specific footer should be placed above the universal footer component

Requirements:

Create a site footer component that matches Adam's designs.
This component should be installable independently.
It should inherit the appropriate parent styles but contain enough code to work on its own.
Use only the minimal amount of code to ship this tool. This component probably does not require javascript so it should be created with HTML and CSS only.
Component should work smoothly with screenreaders
Component should be as lightweight as possible not dragging down page performance
Component should be independently responsive without media queries so that this element can be use appropriate layouts inside any size parent container, not just the entire page

Tasks:

Create the HTML, CSS for the component
Get design signoff from Adam on standalone component
Publish the component as part of the component collection in the design system repository
Implement the component on digital.ca.gov

Screenshots from figma

Define new component: Standard Page Block

We are really excited to share our idea for a design system component.

Our design system team will review this component proposal.

To make sure the component serves all Californians, we have identified some things we need to know about this component.

Please fill in what you can.

Checklist

Name

What should we call this component in conversation?

Standard Page Block

About this component

Please tell us more about the component.

This is a Wordpress Gutenberg Pattern + child blocks that will render content navigation and page content.
The content navigation should only appear when the content has header tags.

Description

Describe how this component will be used.

This should be the main pattern used for content pages.

Examples from ca.gov properties

(Can be screenshots, a few examples is great. Please include URLs if the examples are live.) This helps everyone understand what you are referring to.

None

Examples from other design systems

If this component is commonly found in other design systems, please link to it. This helps everyone understand real-world examples of this idea.

Not applicable, this is a page layout.

Features

Critical features to support initially.

Render breadcrumb
Add content navigation (responsively)
Add body content

Requesting agency

Who is requesting this component?
Office of Digital Innovation & Department of Cannabis Control

code centralization: publish page alert component

The page alert component is currently used in both headless cannabis and drought sites. The code required to render it should be published to npm with a readme describing the module and the required package files. The code for the component should be checked into the design-system repository and deleted from the cannabis and drought repositories. The feature should be used in both sites via npm install. All sass variables not defined inside this component should be replaced with css variables. These variables should be defined in the site code that installs this component

This is a first step towards making this component a member of the design system. We are publishing it in a central location now to prevent code drift.

Component: Page Alert (informs DS)

Create alert component that will have:

Alert title
Alert text block
Link or dismiss button

Figma link:
https://www.figma.com/file/9FTGOPO5HlsLfYuNrtL9IM/cannabis.ca.gov-screens?node-id=0%3A3

Layout:

Alert might require JavaScript code for dismiss button.

Where will this live?

design-system/components/alert/template.html
design-system/components/alert/index.css
design-system/components/alert/index.js

code centralization: publish step-list component

The step list component is currently used in both headless cannabis and drought sites. The code required to render it should be published to npm with a readme describing the module and the required package files. The code for the component should be checked into the design-system repository and deleted from the cannabis and drought repositories. The feature should be used in both sites via npm install. All sass variables not defined inside this component should be replaced with css variables. These variables should be defined in the site code that installs this component

This is a first step towards making this component a member of the design system. We are publishing it in a central location now to prevent code drift.

Define new component: Event Page Block

Checklist

Name

What should we call this component in conversation?

"Event page block"

About this component

Please tell us more about the component.

Will display event details.

Description

Describe how this component will be used.

Content editors post upcoming events, sometimes with virtual meeting links and agendas. These need to be listed on the event page.

Examples from ca.gov properties

(Can be screenshots, a few examples is great. Please include URLs if the examples are live.) This helps everyone understand what you are referring to.

There are some on cannabis.ca.gov. Can share more links if needed.

Examples from other design systems

If this component is commonly found in other design systems, please link to it. This helps everyone understand real-world examples of this idea.

Don't have any.

Features

Critical features to support initially.

This should be a Gutenberg block pattern with some child block components.

According to our notes and the Figma design, these are the main content pieces:

Event tag
Event Title
Description
Details block
- Date and time
- Add to Calendar (needs to be hashed out)
- Location (URL, to zoom link or other information, TBD)
- Cost
- Button with register link
No header image. (Needs confirmation)

Requesting agency

Who is requesting this component?
Office of Digital Innovation (ODI) and Department of Cannabis Control (DCC)

Technical Review: Content Navigation component

Technical Review

A component proposal for the design system needs a technical review.

The initial version of the content navigation component is under development for the cannabis.ca.gov website (phase 1).

Using this issue to record more of the technical requirements and technical discoveries.

Development Review Checklist

Features

Critical features to support initially.

Is a web component
Can embed in a Wordpress PHP template
Accept a selector to use to search for header tags
Read through markup and generate functioning anchor links that can be used in a sidebar navigation element.
Fill in any missing ID tags.

Future features

Update url hash so anchor link can be linked to from another page

Notes for UX:

Content editors will need to know to manage their ID elements appropriately for consistency.

Notes:

hgroup exists, but we are not currently using that markup pattern.

Data structure

If this component maps to an existing schema.org microdata format, please include. If it doesnt, that's ok. We will look it up and provide a data structure. We use schema.org for SEO and data management and round-trip data migration to help keep the component upgradable.

Not really applicable here.
The https://schema.org/SiteNavigationElement is meant for main page navigation. We use JavaScript to generate the links (though these could be converted to static markup in "static site generation mode")

Will not do this, but if anyone can think of improvements so that the navigation elements can connect better to screen-readers, let's do what we can to make this optimal.

Format

Include or reference the expected HTML markup and CSS output (if known)*

<cagov-content-navigation data-selector="main" data-type="wordpress" data-label="On this page"> </cagov-content-navigation>

This code current lives in includes/templates/template-page.php.

For translation in Wordpress, we could create a string interface registry & load in the translated label. (If needed, not needed if we move to headless page delivery.)
Content editors will not alter this component.
The data-label should be translatable through an API based translation service.
For headless page templates, replace data-label with a variable from a string interface, scoped (somehow) to the "content-navigation" component. This component is meant to be rendered in a two column layout. Hopefully our WP template <div id="page-container" class="with-sidebar page-container-ds">...</div> element can be used as a source for headless templates with minimal conversions.

Future-proofing:
The data-type is meant to communicate that the source is Wordpress. If needed, this component can be altered with additional types (like data-type="headless") - and altered to support other systems. Not clear on this yet, but it is our plan to keep these components agnostic to CMS. Creating a scope should help in case there are subtle interaction behaviors like adjusting sticky behavior or anchor link behavior that require additional manipulation based on the environment they are rendering in.

Accessibility

In our design system, we are creating fully-accessible components, for delivery and for the editor experience. We have a baseline of general accessibility practices we are following. Are there any additional accessibility considerations with this component?

These are standard anchor links.

Q: What other improvements can we do to assist with page navigation in other devices?

Analytics

How can we measure if this component is succeeding in its intention, or discover new insights about needs that we did not know?

Q: Do we want to measure this?
NOTE: This probably belongs also in the UX review AND in Technical Review, but the technical review is where we would say what we need to measure & how.

Performance

We provide a baseline of tests for basic performance. Will this component present additional performance issues, and if so, how can we address them?

Creates a small amount of JS code (in the web component) and some Javascript load to parse through the page.
Could be statically generated instead, too - using the web component as a basis to compile & not requiring the component to be delivered headlessly for the tiniest possible footprint.

Testing plan

We provide a baseline of tests for basic component features. Are there additional tests that need to happen for this component?

After we go through scoping out how we register this to the CA Design System as a new web component, we would want to build the following tests:
Finds exact header tags, including header tags with attributes
Doesn't include header tags in body content code blocks
If statically compiling, rendering changes to the selector (adding anchor id's when missing) are captured.
Links work
Links scroll without header tag hitting top of page (i.e. has sensible CSS default behavior in the component)
Links can be restyled with any CSS
anchor-links with emojis, RTL characters, other UTF-8 characters work. (NOTE: we may want to be more specific here about character support. Current version replaces spaces with dashes and converts to lower case & that's it. Supports any length of anchor link)
Existing ID tags are not overridden.
Missing ID tags are created.

Prototype code samples (if any)

content-navigation

This is the initial version created for cannabis.ca.gov website, Phase 1.
(The "metadata" issue will talk about where this component belongs.)

Component: breadcrumbs (informs DS)

Breadcrumbs component

Breadcrumbs are used on internal pages to display how the current page fits into the navigation structure

Examples

Here is a breadcrumbs frontend component from another design system that pays attention to accessibility and clean markup: https://democracyclub.github.io/design-system/components/breadcrumbs/

Design

Development

This ticket will result in a PR to the design-system repository containing a web component that attempts to lookup its own url via the designated site nav API and populate the breadcrumbs

A separate ticket will be opened to track the integration of this into WordPress Gutenberg patterns and custom blocks

Component: Per Page Feedback (informs DS)

The per page feedback widget used on covid19.ca.gov is already a web component that accepts the url of the site being used and submits data to a scalable Azure CosmosDB via serverless endpoint.

This component has not yet been used on any other sites although it should work if some style issues are ironed out.

In one of the wireframe review sessions with the cannabis team they mentioned that this component should appear lower in the footer. It is placed at the desired location in the latest version of the wireframes.

This component was integrated into the WordPress site theme by Danny Guzman using a script include hack that added the web component js and then inserted the custom element into the footer. This was done without modifying the theme but allowed it to appear on all pages.

We need to modify the web component as required to make it more easily reusable and then work with the WordPress theme team again in the production site to integrate it into the footer.

speedup: isolate google translate widget

Publish new web component that contains the google translate widget code and can be used in the statewide site header. Keep track of whether the translate widget has been used so an active translate session can be maintained. Delay loading of the translate widget until click if it has not been activated before

axe identified accessibility issues on cannabis

The axe accessibility audit identified many issues on the headless cannabis site that lighthouse did not flag.

Need to evaluate all of these, fix them.

Also run this plugin on cannabis monolith to compare

New component: News page block

Checklist

Name

What should we call this component in conversation?

"News page block"

About this component

Please tell us more about the component.

This component is a general purpose news block with optional image header.

Description

Describe how this component will be used.

This component will be used to render general news post information. (Excluding events, press-releases and other pre-defined templates)

Examples from ca.gov properties

(Can be screenshots, a few examples is great. Please include URLs if the examples are live.) This helps everyone understand what you are referring to.

[HAVE some examples from existing cannabis.ca.gov which uses CA Web State template)

Examples from other design systems

If this component is commonly found in other design systems, please link to it. This helps everyone understand real-world examples of this idea.

Don't have any.

Features

Create a new WP Gutenberg pattern with

Breadcrumbs
Full screen width (no sidebar)
Critical features to support initially.*
Label: News
Header image: Select & upload with from default WP media upload tool
News post Title
Post date (will use default post date unless otherwise noted)
Post body

Requesting agency

Who is requesting this component?
Office of Digital Innovation and Department of Cannabis Control

Content principle writing: Focus on user needs and services

Write full documentation for the content principle Focus on user needs and services.

Work will take place in this Google Doc.

css file naming standard for css only components

Review file naming standard for sass source file and generated css file or just css file when there is no sass source file.

Can we put final generated css in same location in all cases?
Can original sass file when present be in the same place always?

Standardizing this will help with import confusion. Need to review, identify and document standards and implement on all already published components

code centralization: publish footer component

The footer component is currently used in both headless cannabis and drought sites. The code required to render it should be published to npm with a readme describing the module and the required package files. The code for the component should be checked into the design-system repository and deleted from the cannabis and drought repositories. The feature should be used in both sites via npm install. All sass variables not defined inside this component should be replaced with css variables. These variables should be defined in the site code that installs this component

This is a first step towards making this component a member of the design system. We are publishing it in a central location now to prevent code drift.

Metadata Recommendation: Promotional Card

Component Metadata

A component proposal for the design system needs a metadata recommendation.

Our design system uses package control systems, and these systems need names and some basic metadata about the component, and will help with registering the component in the documentation and any libraries.

Component Metadata Checklist

Name of component

What should we call this component in the design system? The name originally proposed might not follow our naming conventions, or may have a conflict.

Our team had a discussion about this already and decided on:

Promotional Card

Short name

What should the computer call this component? (alpha-numeric characters, dash separated, e.g. "highlight-box")

promotional-card

Web component tag
cagov-promotional-card

Version number

Start at v1.0.0, if this is a proposal for a new version, please say so.

v1.0.0

Destination

Where should this component live in the design system?*

Will live in cannabis.ca.gov repo for initial launch and testing, and then migrate into design-system.

https://github.com/cagov/ca-design-system-gutenberg-blocks/tree/main/blocks/promotional-card

Then in design system, current plan is this:
/components/promotional-card

Description

How should we initially describe this in the design system (e.g. in Wordpress, documentation, package.json. This content will be revised in the final publishing step.)

What is it? (quick description for conversation)
Where does it appear?
What does it do? (purpose, intent, why did we build this)
What does it include? (features, data elements, etc) (Tips, if any)

Card that highlights content. Designed for page content. Provides image asset, name, description and hyperlink.

Component: Define a reusable Gutenberg Block: Highlight box (informs DS)

We are really excited to share this idea for a component for the ca.gov design system.

About this component

Please tell us more about the component.

Page authors often need to bring users attention to a temporary message.

Basic information

To make sure the component serves all Californians, we have identified some things we need to know about this component.

Please fill in what you can.

Our design system team will review this component proposal.

Checklist

Name of component

What should we call this component in conversation?

Description

Describe how this component will be used.

Examples from ca.gov properties

(Can be screenshots, a few examples is great. Please include URLs if the examples are live.)

Data discrepancy notification on a dashboard:
Limited time call to action on vaccines page:

Examples from other design systems

If this component is commonly found in other design systems, please link to it

Features

Critical features to support initially.

HTML and CSS for a highlight box
Message & icon
Optional image
Use little to no javascript
Should work on multiple background colors
Should work in any container without media queries
Support translations
Support RTL
May include links, links might be PDFs with external tags
Tab navigation should work for links

Requesting agency

Who is requesting this component?

Reviews

Once a component is initially created, we will use this issue to fill in the additional information. This issue will eventually become part of the documentation.

Checklist

Metadata

Our design system uses package control systems, and these systems need names and some basic metadata about the component.

Name of component

What should we call this component in the design system?

Short name

What should the computer call this component? (alpha-numeric characters, dash separated, e.g. "highlight-box")

Version number

Start at v1.0.0, if this is a proposal for a new version, please say so.

Destination

Where should this component live in the design system?*
design-system/src/components/highlight-box/template.html
design-system/src/components/highlight-box/index.css

Description

How should we describe this in the design system (e.g. in Wordpress, documentation, package.json)

Features

Critical features to support initially.

Status

We plan to manage this mostly with Github labels & Airtable

Has Github labels
Final content in Airtable (to autogenerate documentation & keep track of assets)

Development

Checklist

User research

Has user research been conducted?

Design

Anything needed to know about designing this component

Location of Figma assets

Content design

What content elements or assets does a content editor need to provide?

icon
message (maximum length)

Content strategy

What does a content editor need to know about writing and publishing this content?

Data structure

If this component maps to an existing schema.org microdata format, please include. If it doesnt, that's ok. We will look it up or provide a data structure. We use schema.org for SEO and data management and round-trip data migration to help help the component easy to upgrade.

https://schema.org/SpecialAnnouncement

Format

Include or reference the expected HTML markup and CSS output (if known)*

HTML markup sample
- Desired selectors: (?)
CSS - Will be added to the global css file

Accessibility

Analytics

How can we measure if this component is succeeding in its intention, or discover new insights about needs that we did not know?

Equity

Are there potential impacts of this component or how it is used that may need special consideration?

Performance

We provide a baseline of tests for basic performance. Will this component present additional performance issues, and if so, how can we address them?

Testing plan

We provide a baseline of tests for basic component features. Are there additional tests that need to happen for this component?

Publishing

Once development is completed and the component is in use throughout ca.gov websites, any changes will need well communicated updates that will roll up into bigger updates. Additionally, documentation and support will be required.

Documentation

This document will inform the documentation we create for the finished component.

Screenshots
Sample code
How to use
Video walkthrough (with captions) (editorial experience)

Support plan

We provide a baseline of support. What kinds of additional support are needed for this component?

Component: Create utility (official) header (informs DS)

Create CA official top header component that would include ca.gov logo, and languages links.

Figma link:
https://www.figma.com/file/9FTGOPO5HlsLfYuNrtL9IM/cannabis.ca.gov-screens?node-id=381%3A3318

CA.gov Logo needs to be SVG code.
Next to it needs to be text "Official website of the State of California"

Languages links are: English, Espańol, 中文 and More (drop down button with arrow down icon). They should go on the left side of the component.

Mobile layout:

Where will this live?

design-system/components/utility-header/template.html
design-system/components/utility-header/index.css

Component: pagination

The cannabis site uses pagination to move between the press releases and other content types. We will create a reusable web component that can call external APIs to determine:

How many pages to display

The component will display links to all available page sets, prev and next active when available

The component will emit events on click to notify other components on the page about new click events

Checklist

Name

What should we call this component in conversation?

About this component

Please tell us more about the component.

Description

Describe how this component will be used.

Examples from ca.gov properties

(Can be screenshots, a few examples is great. Please include URLs if the examples are live.) This helps everyone understand what you are referring to.

Examples from other design systems

If this component is commonly found in other design systems, please link to it. This helps everyone understand real-world examples of this idea.

Features

Critical features to support initially.

Requesting agency

Who is requesting this component?

Thank you!

Learn more about our review process.

Define new component: Post list block

We are really excited to share our idea for a design system component.

Our design system team will review this component proposal.

To make sure the component serves all Californians, we have identified some things we need to know about this component.

Please fill in what you can.

Checklist

Name

What should we call this component in conversation?

"Event list block"

About this component

Please tell us more about the component.

A Wordpress Gutenberg Block that lists 3 events by default, ascending order, include title, date, time, zoom link.

Description

Describe how this component will be used.

This is a listing of posts tagged events. Should be similar to the news block but render the events with a different temple.
Want to add it on pages where we want to show a list of events.

Examples from ca.gov properties

(Can be screenshots, a few examples is great. Please include URLs if the examples are live.) This helps everyone understand what you are referring to.

Not aware of any right now.

Examples from other design systems

If this component is commonly found in other design systems, please link to it. This helps everyone understand real-world examples of this idea.

Not applicable

Features

Critical features to support initially.

Title of the block
3 events by default
Event post title
Date (Format: Sat, May 29, 2021)
Time (Format: 5:00 PM - 9:00 PM EDT)
Zoom link

Requesting agency

Who is requesting this component?

Ignore: Just running a test

Ipsum Lorem

Skip to the content

When keyboard-only users interact with your site they use the tab key to jump from link to link. If you have a lot of links at the first of your page in your header or in a menu, they must tab through those every time they come to a new page just to get to the main content. Providing a skip to main content link allows them to easily bypass this.

Checklist

Requesting agency

Who is requesting this component?
CDT, California State Template development unit

Origin Story

What prompted this proposal?
Having skip to the main content link is accessibility requirement (WCAG 2.4.1)

Name

What should we call this component in conversation?
Skip to the main content

About this component

Please tell us more about the component.
The objective of this technique is to provide a mechanism to bypass header links and main navigation links are repeated on multiple Web pages by skipping directly to the main content of the Web page. The first interactive item in the Web page is a link to the beginning of the main content. Activating the link sets focus beyond the other content to the main content.

Description

Describe how this component will be used.
When keyboard-only users interact with your site they use the tab key to jump from link to link. If you have a lot of links at the first of your page in your header or in a menu, they must tab through those every time they come to a new page just to get to the main content. Providing a skip to main content link allows them to easily bypass this.

Examples from ca.gov properties

(Can be screenshots, a few examples is great. Please include URLs if the examples are live.) This helps everyone understand what you are referring to.
https://template.webstandards.ca.gov/

Examples from other design systems

If this component is commonly found in other design systems, please link to it. This helps everyone understand real-world examples of this idea.
https://designsystem.digital.gov/

Features

Critical features to support initially.

Should be first focusable element on the page.
Should be hidden on initial view but visible on focus.
Should be linked to the main content tag

Thank you!

Learn more about our review process.

Promotional Card

We are really excited to share our idea for a design system component.

Our design system team will review this component proposal.

To make sure the component serves all Californians, we have identified some things we need to know about this component.

Please fill in what you can.

Checklist

Name

We're calling this a promotional card as it pertains to the campaign toolkit (for now).

About this component

This component is an initial preview into current or archived departmental campaigns. It is a link to the corresponding campaign page.

Description

Pic
Title
Start/End date
Desc
URL

Examples from ca.gov properties

See Landing Page V2

Figma link)

Examples from other design systems

TBD

Features

Pic
Title
Start/End date
Desc
URL

Requesting agency

Department of Cannabis Control

Thank you!

Learn more about our review process.

code centralization: publish menu component

The menu component is currently used in both headless cannabis and drought sites. The code required to render it should be published to npm with a readme describing the module and the required package files. The code for the component should be checked into the design-system repository and deleted from the cannabis and drought repositories. The feature should be used in both sites via npm install.

This is a first step towards making this component a member of the design system. We are publishing it in a central location now to prevent code drift.

Horizontal Scrollable Grid

We are really excited to share our idea for a design system component.

Our design system team will review this component proposal.

To make sure the component serves all Californians, we have identified some things we need to know about this component.

Please fill in what you can.

Checklist

Origin Story

Original concept was to port the existing campaign page from the old cannabis site to the new site. We suggested turning it into a campaign toolkit page to better facilitate content specific users who may want to upload or download campaign assets. DCC agreed this was a great idea.

Name

Horizontal Scrollable Grid

About this component

Takes a filtered data set and renders it as scrollable cards in a horizontal grid.

Description

This is a repeatable component for organizing campaign assets and displays a set of information of the same type in a digestible way.

Examples from ca.gov properties

Figma link

Examples from other design systems

If this component is commonly found in other design systems, please link to it. This helps everyone understand real-world examples of this idea.

Features

Comprised of two components:

Grid with scrolling interface
Card that renders the data

Requesting agency

Department of Cannabis Control

Thank you!

Learn more about our review process.

Component: Card grid (informs DS)

The card grid component designed by Adam is planned to be used on the cannabis.ca.gov site homepage.

User needs:

The cannabis site should have an grid of cards section that showcases important content below the hero image
This component should be easily edited or swapped out in the WordPress editing environment
This should be based on the reusable design system element
The implementation should be lightweight and fully accessible

Requirements:

Create a card grid component that matches Adam's designs.
This component should be installable independently.
It should inherit the appropriate parent styles but contain enough code to work on its own.
Use only the minimal amount of code to ship this tool. This component probably does not require javascript so it should be created with HTML and CSS only.
Component should work smoothly with screenreaders
Component should be as lightweight as possible not dragging down page performance
Component should be independently responsive without media queries so that this element can be use appropriate layouts inside any size parent container, not just the entire page
Create additional tools to make sure that this component can be used easily inside WordPress and that it will faithfully output the desired styles and markup in that environment.

Tasks:

Create the HTML, CSS for the component
Get design signoff from Adam on standalone component
Publish the component as part of the component collection in the design system repository
Create a custom gutenberg block so that this component can be added to the cannabis.ca.gov WordPress site
Validate all the WP block functionality with Adam, Michael, and the cannabis content maintainers
Review the component code generated in WordPress for accessibility, performance
Review the component custom block authoring experience for accessibility

Screenshots from figma

Content design principle documentation

This ticket is for the content team to define the principles we want to scale across California state agencies to help other departments create content that better serves Californians.

We will do our initial work in this Google Doc. The ultimate goal is to load this information into a website where other state agencies can find and use these principles to improve their content.

code centralization: publish universal header component

The state header component is currently used in both headless cannabis and drought sites. The code required to render it should be published to npm with a readme describing the module and the required package files. The code for the component should be checked into the design-system repository and deleted from the cannabis and drought repositories. The feature should be used in both sites via npm install.

This is a first step towards making this component a member of the design system. We are publishing it in a central location now to prevent code drift.

UX Review: Content Navigation component

UX Review

A component proposal for the design system needs a UX review.

Initial proposal: #24
In progress component: cagov/cannabis.ca.gov#53

We have an initial prototype based on our conversations, Slack threads, Figma design files.

Starting this issue to future address what this component needs to be.

Let's collect any insights and information we already know from working on the covid19 project & the design/content design thoughts that went into the Figma design. If there are notes from Google docs & other conversations, let's summarize them here to the best of our ability so that anyone looking at this component can trace its history better.

Checklist

User research

Has user research been conducted?

Design

Anything needed to know about designing this component

Screenshots of Designs
Notes on responsive design?

Screenshots

You can include a public link to a design asset, but please provide design screenshots at 100% size so that everyone can see the design.

Content design

What content elements or assets does a content editor need to provide?

Content strategy

What does a content editor need to know about writing and publishing this type of content?

Analytics

How can we measure if this component is succeeding in its intention, or discover new insights about needs that we did not know?

Impact

Are there potential impacts of this component or how it is used that may need special consideration? (Impacts could be in equity, accessibility, privacy or other concerns, or opportunities)

code centralization: publish breadcrumb component

The post-list-headless component is currently used in both headless cannabis and drought sites. The code required to render it should be published to npm with a readme describing the module and the required package files. The code for the component should be checked into the design-system repository and deleted from the cannabis and drought repositories. The feature should be used in both sites via npm install. All sass variables not defined inside this component should be replaced with css variables. These variables should be defined in the site code that installs this component

This is a first step towards making this component a member of the design system. We are publishing it in a central location now to prevent code drift.

Define new component: News

We are really excited to tell you about the component that you would like to suggest for the design system.

About this component

Please tell us more about the component.

A news block.

Tell us more about the component

To make sure the component serves all Californians, we have identified some things we need to know about this component.

Please fill in what you can.

Our design system team will review this component proposal.

Checklist

Name of component

What should we call this component in conversation?

News block

Description

Describe how this component will be used.

This block will be used to display recent news content.

Examples from ca.gov properties

(Can be screenshots, a few examples is great. Please include URLs if the examples are live.)

Examples from other design systems

If this component is commonly found in other design systems, please link to it

Notes on Features

Generally describe the features of this component.

List a few news titles with links.
Outlined in more detail below.

Requesting agency

Who is requesting this component?

Department of Cannabis Control & Office of Digital Innovation

Reviews

Once a component is initially created, we will use this issue to fill in the additional information. This issue will eventually become part of the documentation.

Checklist

Metadata

Our design system uses package control systems, and these systems need names and some basic metadata about the component.

Name of component

What should we call this component in the design system?

News block

Short name

What should the computer call this component? (alpha-numeric characters, dash separated, e.g. "highlight-box")

news-block

Version number

Start at v1.0.0, if this is a proposal for a new version, please say so.

v1.0.0

Destination

Where should this component live in the design system?*

Design System plugin

Called news-block
Will live as a web component that has a standard API
The wordpress API wrapper will need to be mapped to this standard API so that the component can be used by any CMS.

Gutenberg block Editor Workflow

Will be designed to be “no-code” and minimally configurable*
Add a new Gutenberg block called “News Block” with a description saying “List of recent news posts.”
Load data automatically
Click to edit title
Click to change link to news page
Eventually, need a way to change the default tag + number - maybe a settings gear?
Q: What kind of other hints do we need to give?

Gutenberg block Display View

Block renders the web-component, taking from the current domain & adding the custom edited tag.
Dynamically renders and loads content and uses options to control the display
markup desired
<cagov-news-block data-url=”{compiled url endpoint}” data-count=”4” data-order=”desc” data-title=”News” data-api-type=”wordpress/v2” data-link=”/news” />

Description

How should we describe this in the design system (e.g. in Wordpress, documentation, package.json)

Features

Critical features to support initially.

Block title (translatable, editable)
WordPress post content, filtered by a tag.
Link to news page

Item listing will default to:
* tag: "news"
* count: 5 items
* order: most recent first
* NOT editable by default.

* Possibility: We can make a configurable version of the same code and call it "Customizable News Block" which will let the user change the tag, count, order to other types of content. We can build the base block so this is possible.

Content of each item
* Title
* Date
* URL
* No image
* No excerpt

Status

We plan to manage this mostly with Github labels & Airtable

Has Github labels
Final content in Airtable (to autogenerate documentation & keep track of assets)

Development

Checklist

User research

Has user research been conducted?

Design

Anything needed to know about designing this component

The news block displays the most recent news articles.

Default title is “News” but this can be configured
For each news article, there is a:
- Title that links to the news article
- Published date [TBD is date can be manually overridden. See note in “Data Structure for more notes on field & data settings.]
The block displays 4 of articles [TBD if this can be configured]
24px of spacing between each article
At the end of the list is a “View all news” link that links to the website’s news page

Figma link

Notes on Responsive Design

The width of the news block will change.

Content design

What content elements or assets does a content editor need to provide?

Title
Url path to news page (unless it’s set to a site default)
The content will be pulled from the page titles automatically.
This design does not include excerpts, but a variant will & content editors will need to provide web-friendly post descriptions.

Content strategy

What does a content editor need to know about writing and publishing this content?

Data structure

If this component maps to an existing schema.org microdata format, please include. If it doesn’t, that's ok. We will look it up or provide a data structure. We use schema.org for SEO and data management and round-trip data migration to help the component easy to upgrade.

The correct schema.org type for news listings is ItemList
The item list will render a CreativeWork for a NewsArticle

We will need to map our fields to the required properties:

Date: datePublished - Date MAY be default WP published date OR a separate posted date that is stored in block settings & needs to be retrieved.
Title: headline
Url: url

There are additional schema fields necessary to work with Google’s SEO capabilities:
Summary page is the best example. Technically it is a “Carousel” but it’s also a list, depending on the content type. Will need to combine the content type with the ListItem.

They can be tested by pasting code in Google Rich Results Test tool

Question: If the block title needs to be included/used.

Format

Include or reference the expected HTML markup and CSS output (if known)*

Accessibility

Analytics

How can we measure if this component is succeeding in its intention, or discover new insights about needs that we did not know?

Equity

Are there potential impacts of this component or how it is used that may need special consideration?

All content and labels should be fully translatable.

Performance

We provide a baseline of tests for basic performance. Will this component present additional performance issues, and if so, how can we address them?

We will use a fetch request to an API, so the content will dynamically load on page render. This will add a small performance hit. It should error out appropriately on network errors.

Testing plan

We provide a baseline of tests for basic component features. Are there additional tests that need to happen for this component?

With API
With bad API data
With failed network request
Translations work
RTL works
Not enough data found doesn’t fail

Publishing

Documentation

This document will inform the documentation we create for the finished component.

Screenshots
Sample code
How to use
Video walkthrough (with captions) (editorial experience)

Support plan

We provide a baseline of support. What kinds of additional support are needed for this component?

Metadata Recommendation: Content Navigation

Component Metadata

A component proposal for the design system needs a metadata recommendation.

Initial Issue: #24

Component Metadata Checklist

Name of component

What should we call this component in the design system? The name originally proposed might not follow our naming conventions, or may have a conflict.

Content Navigation is what we are currently calling it. Everyone seems to understand what we are talking about, but we can use this thread to track if we actually think this is a good name. The name is used in issue reporting too & for training content editors.

Short name

What should the computer call this component? (alpha-numeric characters, dash separated, e.g. "highlight-box")

Is currently content-navigation

Version number

Start at v1.0.0, if this is a proposal for a new version, please say so.

1.0.0

We are missing the package.json for this component, so we can use this issue to collect the information that belongs in the package registry.

Destination

Where should this component live in the design system?*

components/content-navigation

Description

How should we initially describe this in the design system (e.g. in Wordpress, documentation, package.json. This content will be revised in the final publishing step.)

Great question. We had a mini "naming hackathon" for other components, but this, being a utility component is slated to go through a group process to actually discuss the name & generate descriptions that are meaningful to anyone interacting with this component.

Component: State site universal footer (informs DS)

All California government state sites should share a footer component. This provides a bookend of familiar branding at the bottom of pages and contains links to common state sites.

Requirements:

Create a footer component that matches Adam's designs.
This component should be installable independently.
It should inherit the appropriate parent styles but contain enough code to work on its own.
Use only the minimal amount of code to ship this tool. This component probably does not require javascript so it should be created with HTML and CSS only.
Component should work smoothly with screenreaders
Component should be as lightweight as possible not dragging down page performance
Component should be independently responsive without media queries so that this element can be use appropriate layouts inside any size parent container, not just the entire page

Tasks:

Create the HTML, CSS for the component
Get design signoff from Adam on standalone component
Publish the component as part of the component collection in the design system repository
Implement the component on digital.ca.gov

Screenshots from figma

update leaderboards crawl list

The attached spreadsheet was provided by Artem Khomishen so we can cover all the CDT managed sites on the ca.gov leaderboards

CDT-Website-List.xlsx

Modify the leaderboard creation repo to include all these sites

code centralization: update accordion, feature card, card grid components

The accordion, feature card, card grid components are currently used in both headless cannabis and drought sites. The code required to render it should be published to npm with a readme describing the module and the required package files. The code for the component should be checked into the design-system repository and deleted from the cannabis and drought repositories. The feature should be used in both sites via npm install. All sass variables not defined inside this component should be replaced with css variables. These variables should be defined in the site code that installs this component

This is a first step towards making this component a member of the design system. We are publishing it in a central location now to prevent code drift.

Technical Review: Scrollable Grid

Technical Review

A component proposal for the design system needs a technical review.

Development Review Checklist

Features

Critical features to support initially.

The data and variations of assets for the campaign toolkit are our reference point for this component. The volume of assets will grow in Wordpress over time, and also this component needs to be able to pull from a variety of sources.

We plan to build this component in a couple of phases (or "layers".)

A campaign toolkit shares different social media and video assets used to promote a campaign.
For initial launch, supporting manual entry. No special data sources required. HTML links to media assets will be manual and a little cumbersome.
The second version will construct markdown based on a structured spreadsheet. This will help to organize and manage media imports, or just keep track of assets, many of which have similar names.
The third layer involves working with API data. We are prototyping this with structured CSV data, and exploring ways of tagging assets from the default WordPress media library
We will also suggest a plugin for improving the media library interface, specifically supplying folders for media asset management, as the library grows over time and the default wordpress interface is difficult to search. The latest version of WordPress includes updates to the Media Library, we will also review this to see if there are any relevant features.
We will add a scrolling interface. For naming, the scrolling is likely to always be horizontal, so planning to call this scrollable-grid. Looking at something like Glider, but will do a little more research for any other alternatives. https://nickpiscitelli.github.io/Glider.js/
Scroll interface has pagination and swiping. Since we are building web components that are very lightweight, we will also want to find a light but solid interaction library for scroll swiping.

Data structure

This is the data structure from the CSV file we are using in Airtable to build sample data for development:

Toolkit

Title
Campaign - Name of campaign (tag)
Category - For pulling tagged data from Media library. Need to see what kind of taxonomies will make sense for what we are doing here.
Description
Image
Assets (links to asset records) - Need to research what we can do within the limitation of WordPress
Accessibility text
Order

Asset

asset_id
Title
Asset Type (taxonomy)
Asset URL
Asset File
Order

Removed "Asset Embed Code", we will lean on the embed code coming from content hosts and provide screengrabs as needed.

Format

Include or reference the expected HTML markup and CSS output (if known)*

<cagov-scrollable-grid>
    <div class="cagov-horizontal-grid-card">
        <div class="card-image">
            <img="{attributes.mediaURL}" alt="{attributes.mediaAlt}" />
        </div>
        <div class="card-content">
        <h3>{title}</h3>
        <p class="description>{description}</p>
        <ul class="links">
            <li><a href="/">{assetURL}</a></li>
        </ul>
    </div>
    <div class="cagov-horizontal-grid-card">
        <div class="card-image">
            <img="{attributes.mediaURL}" alt="{attributes.mediaAlt}" />
        </div>
        <div class="card-content">
        <h3>{title}</h3>
        <p class="description>{description}</p>
        <ul class="links">
            <li><a href="/">{assetURL}</a></li>
        </ul>
    </div>
</div>
</cagov-scrollable-grid>

Accessibility

We need to research any ARIA tags that are present in scroll interface.
Alt content for image needs to be pulled into the interface
We want to encourage social media accessibility, by encouraging including a description of the asset with the Images, or adding reminders that the video includes captions or transcripts.

Performance

We provide a baseline of tests for basic performance. Will this component present additional performance issues, and if so, how can we address them?

Responsive image sizes. Same as promotional-card, can also be retroactively applied to hero/feature-card.

Testing plan

We provide a baseline of tests for basic component features. Are there additional tests that need to happen for this component?

Translations checklist

With the CSS only layout the markup is easily translated.
For more complex API generated scrollable grids (using compiled markup from an API), either we need to translate the JSON, an attribute called data-content or data-json, or store structured data in a way that it can be translated with an API based pipeline and fed into a content generator.

Decoupled architecture checklist

The content needs to render in our WordPress editors AND in a headless static site generator. Will it?

The "third layer" of building this, using a WordPress API or other API source will need to be described more carefully. Thinking of doing something like a React <Provider>, but with an API url & rendering type that can pregenerate the data for the static site. This gets more complex if filtering is needed & should be a separate project.

Component: Per page feedback - Web app to review feedback

Separate ticket for creation and deployment of review interface for site owners to read, sort, filter all the feedback received.

Explore using Video Recordings in Github Issues

https://www.loom.com/share/94d12485a36e44bfaa04f4f0a6750fb9 <- This was created with the Chrome extension using the Loom button that appears from Github automatically works the same.

create initial css only component

We are packaging reused code between headless cannabis and drought sites. Several of these design system elements are just HTML & CSS. This is cool, we don't need to introduce javascript because that makes progressive enhancement more complicated. In order to reuse the code we are publishing css only modules to npm. This is the first example of one.

Goals:

centralize code currently duplicated in headless cannabis and drought into components in the design-system repo
Publish them and install them in repos that use them
Iterate on the components in isolation so they have the documentation, preview and any required test features they need.

Define new component: Content Navigation

Checklist

Name

What should we call this component in conversation?

Content Navigation

About this component

Please tell us more about the component.

The content-navigation is a stand-alone web component that accepts a target selector, finds any h2-h6 tags, and builds a list of anchor links. If tags to not have ids, ids are created dynamically so that on clicking the link, it will scroll to that section.

Description

Describe how this component will be used.

This component will be used to help page viewers find content on the page.

Examples from ca.gov properties

(Can be screenshots, a few examples is great. Please include URLs if the examples are live.) This helps everyone understand what you are referring to.

The covid19.ca.gov website used jump links at the top of pages to help reads find relevant information.

Examples from other design systems

If this component is commonly found in other design systems, please link to it. This helps everyone understand real-world examples of this idea.

Not aware of any, requires research.

Features

Critical features to support initially.

Read page headers and build links to the headers

Requesting agency

Who is requesting this component?

Office of Digital Innovation & Department of Cannabis Control

Content style guide: when should something be an action button

(bringing over from jira)

Check if we describe how to determine when to use an action button in our handbook. Requested by Angie.

Component: Use Feedback on digital.ca.gov (informs DS)

California government state sites should have a site specific footer component. This contains sitewide links and logos. The site specific footer should be placed above the universal footer component

Requirements:

Create a feedback component that matches Adam's designs.
This component should be installable independently.
It should inherit the appropriate parent styles but contain enough code to work on its own.
Use only the minimal amount of code to ship this tool. This component probably requires javascript so it should be created as a web component and published to npm
Component should work smoothly with screenreaders
Component should be as lightweight as possible not dragging down page performance
Component should be independently responsive without media queries so that this element can be use appropriate layouts inside any size parent container, not just the entire page

Tasks:

Create the HTML, CSS for the component
Get design signoff from Adam on standalone component
Verify data collection
Create site specific viewing location so data can be retrieved independently of covid feedback
Publish the component as part of the component collection in the design system repository
Implement the component on digital.ca.gov

Screenshots from figma

fix redirects on latest leaderboards

Some of the sites added in the last set of urls provided by Art are doing a redirect before they are evaluated so are being unfairly penalized. Need to fix all these urls to show the final one unless they are doing something weird like going to /m for mobile visitors. Then rerun leaderboards

Component: Accordion (informs DS)

We use the accordion component frequently on covid19.ca.gov. We haven't yet made this a standalone, reusable element. It needs more style isolation and review of what it inherits.

Adam has refined the design of the component for the design system so we need to match his latest designs. We also need to create a Gutenberg block for this so that it can be used the same way as the rest of content elements on cannabis.

Examples: https://covid19.ca.gov/industry-guidance/

About this component

This component needs to be progressively enhanced. It the javascript does not execute it should not obscure content. Otherwise it should default to closed, animate open on click and close on click when open. The header should allow anchor links. Its internal content should allow any standard page block type

Examples from other design systems

If this component is commonly found in other design systems, please link to it. This helps everyone understand real-world examples of this idea.

Features

Checklist

Metadata

Our design system uses package control systems, and these systems need names and some basic metadata about the component.

Name of component

What should we call this component in the design system?

Short name

What should the computer call this component? (alpha-numeric characters, dash separated, e.g. "highlight-box")

Version number

Start at v1.0.0, if this is a proposal for a new version, please say so.

Destination

Where should this component live in the design system?*

Description

How should we describe this in the design system (e.g. in Wordpress, documentation, package.json)

Features

Critical features to support initially.

Status

We plan to manage this mostly with Github labels & Airtable

Has Github labels
Final content in Airtable (to autogenerate documentation & keep track of assets)

Development

Checklist

User research

Has user research been conducted?

Design

Anything needed to know about designing this component

Location of Figma assets

Content design

What content elements or assets does a content editor need to provide?

Content strategy

What does a content editor need to know about writing and publishing this content?

Data structure

Format

Include or reference the expected HTML markup and CSS output (if known)*

Accessibility

Analytics

How can we measure if this component is succeeding in its intention, or discover new insights about needs that we did not know?

Equity

Are there potential impacts of this component or how it is used that may need special consideration?

Performance

We provide a baseline of tests for basic performance. Will this component present additional performance issues, and if so, how can we address them?

Testing plan

We provide a baseline of tests for basic component features. Are there additional tests that need to happen for this component?

Publishing

Documentation

This document will inform the documentation we create for the finished component.

Screenshots
Sample code
How to use
Video walkthrough (with captions) (editorial experience)

Support plan

We provide a baseline of support. What kinds of additional support are needed for this component?

Thank you!

Learn more about our review process.

Technical Review: Promotional Card

Technical Review

A component proposal for the design system needs a technical review.

Development Review Checklist

Features

Critical features to support initially.
Based on the design,

This component needs to render an appropriately sized media image.
Needs to stack two at a time
Provide Gutenberg block interface so it's easy to remember which elements to include.
Calculate the date and show "to present" if no end date is set.
Be translatable
Be able to set data from a container (that would pass data from a data set for toolkits, or use pre-generated markup from a small Airtable script that builds web components from spreadsheet data)
Link to the correct toolkit page

Note: We won't build an autogenerated API version of this yet, as we need to solve a couple of levels of other issues first, but we will keep this in mind as we work so that autogeneration and autoupdating based on API data is possible.

Data structure

The closest schema.org type for this is ItemList and CollectionPage
https://schema.org/CollectionPage

Format

Include or reference the expected HTML markup and CSS output (if known)*

This could be a CSS-only component similar to the hero/feature-card component. It would be cleaner if it were a web component wrapper that created template content in the HTML structure below, it might give us some flexibility to continue to find the ideal integration of Gutenberg Blocks, but still keep the code translatable and easy to edit.

<cagov-promotional-card data-content="{attributes}"></cagov-promotional-card>

<div class="cagov-promotional-card">
        <div class="card-image"><img="{attributes.mediaURL}" alt="{attributes.mediaAlt}" /></div>
        <div class="card-content">
        <h3>{title}</h3>
        <p class="date-range">{startDate: Month Year}-{endDate: Month Year (or present)}</p>
        <p class="description>{description}</p>
        <div class="wp-block-button">
            <a 
                class="wp-block-button__link" 
                href="{buttonLink}">
                    {buttonLabel}
            </a>
        </div>
        </div>
    </div>

Attributes

{
    title: "",
    startDate: "",
    endDate: "",
    description: "",
    buttonLabel: "",
    buttonLink: "",
    category: "",
    mediaID: "",
    mediaURL: "",
    mediaAlt: "",
    mediaWidth: "",
    mediaHeight: ""
}

Accessibility

Make sure the web component can access the correct Alt tag information from the Media library.

Performance

The image needs to pull the alt text from the WordPress media API. We need a new convention for using the Media API data, with smaller mobile image and larger desktop sized images. Wordpress automatically scales and provides image files & metadata with the Media API, but our data structure we used for hero image doesn't support this. Will try to come up with a better structure here that can inform any component that needs to support multiple image sizes.

Testing plan

We provide a baseline of tests for basic component features. Are there additional tests that need to happen for this component?

We need to start to articulate all the kinds of tests our components and CSS only components need to preserve their features. Using story formats and setting up test data will be helpful.

Translations Checklist

The component will be translatable.

As we build we are ensuring that all content is translatable with

Human translation of page markup
automatic translations from web services

The following page markup will be translated.

JSON content
Markup
(NEW REQUEST UNDER CONSIDERATION), JSON in data-content markup attributes. Idea is to simplify content passed into web component using JSON. Will get feedback from team.

code centralization: publish content navigation component

The content-navigation component is currently used in both headless cannabis and drought sites. The code required to render it should be published to npm with a readme describing the module and the required package files. The code for the component should be checked into the design-system repository and deleted from the cannabis and drought repositories. The feature should be used in both sites via npm install. All sass variables not defined inside this component should be replaced with css variables. These variables should be defined in the site code that installs this component

This is a first step towards making this component a member of the design system. We are publishing it in a central location now to prevent code drift.