Giter VIP home page Giter VIP logo

uswds-team's Introduction

United States Web Design System

CircleCI Build Status Snyk vulnerabilities npm Version npm Downloads GitHub issues code style: prettier

The United States Web Design System includes a library of open source UI components and a visual style guide for U.S. federal government websites.

This repository is for the design system code itself. We maintain another repository for the documentation and website. To see the design system and its documentation on the web, visit https://designsystem.digital.gov.

Contents

Recent updates

Information about the most recent release of the design system can always be found in the release history. We include details about significant updates and any backward-incompatible changes along with a list of all changes.

USWDS 3.0 is our most recent major release.

Getting started

We’re glad you’d like to use the design system — here’s how you can get started:

What's included in USWDS

The USWDS package includes compiled assets in a dist directory and component source files in a packages directory.

As of USWDS 3.0.0, our codebase is centered around functional packages, typically components. For more about how we organize packages, see our Packages documentation. In each of the following examples, we use [package] to represent a specific package. For example, component Sass is located in packages/[package]/src/styles for an accordion, this would be packages/usa-accordion/src/styles.

  • Fonts are located in both dist/fonts and packages/uswds-core/src/assets/fonts. The fonts in dist are simply a copy of the files in uswds-core.
  • Images and icons are located in: dist/img. The source for component-specific images can be found in a package's src/img directory.
  • JavaScript for components is located in packages/[package]/src/index.js. General JavaScript utilities and polyfills are located in the uswds-core package: packages/uswds-core/src/js
  • Sass component-specific stylesheets are located in: packages/[package]/src/styles. Many components also have a component entry point at packages/[package]/_index.scss that includes references to all a component's dependencies as well. Compiled CSS is located in dist/css.
  • Template markup for the components is located in: packages/[package]/src/[package.twig] in the site root. These, however, are written in the templating language Twig. It's best to get HTML source markup directly from designsystem.digital.gov/components

Directory structure

Here's what you can expect to find inside the USWDS package:

[uswds package]
├── .storybook/
├── dist/
│   ├── css/
│   │   ├── uswds.css
│   │   ├── uswds.min.css
│   │   └── uswds.min.css.map
│   ├── fonts/
│   │   ├── merriweather/
│   │   ├── public-sans/
│   │   ├── roboto-mono/
│   │   └── source-sans-pro/
│   ├── img/
│   │   ├── usa-icons/
│   │   ├── material-icons/
│   │   ├── uswds-icons/
│   │   ├── usa-icons-bg/
│   │   ├── sprite.svg
│   │   ├── [individual images]
│   │   ...
│   ├── js/
│   │   ├── uswds-init.js
│   │   ├── uswds-init.min.js
│   │   ├── uswds-init.min.js.map
│   │   ├── uswds.js
│   │   ├── uswds.min.js
│   │   └── uswds.min.js.map
│   ├── scss/
│   │   └── stylesheets/
│   │       └── uswds.scss
│   └── theme/
│       ├── _uswds-theme.scss
│       ├── _uswds-theme-custom-styles.scss
│       └── styles.scss
├── packages/
│   ├── usa-component/
│   │   ├── src/
│   │   │   ├── content/
│   │   │   ├── styles/
│   │   │   │   ├── _index.scss
│   │   │   │   └── component.scss
│   │   │   ├── test/
│   │   │   │   ├── component.spec.js
│   │   │   │   └── template.html
│   │   │   ├── index.js
│   │   │   ├── usa-component.stories.js
│   │   │   └── usa-component.twig
│   │   └── _index.scss_/
│   ├── usa-component/
│   ├── usa-component/
│   ├── uswds-bundle/
│   ├── uswds-bundle/
│   ...
├── src/
│   ├── img/
│   ├── stylesheets/
│   └── test/
└── tasks/

Package contents

Here's what you can expect to find in each of the directories and files in the USWDS package:

  • /.storybook: Storybook configuration files (not used in USWDS projects)

  • /dist: Compiled or collected files

  • /dist/css: Precompiled CSS files with USWDS defaults

  • /dist/fonts: Default fonts available to the design system

  • /dist/img: All USWDS images collected into a single directory

  • /dist/img/usa-icons: All icons collected into the USWDS icon sprite (sprite.svg)

  • /dist/img/material-icons: All Material Icons

  • /dist/img/uswds-icons: All icons created by USWDS

  • /dist/img/sprite.svg: Precompiled icon sprite with default icon set

  • /dist/js: Precompiled JavaScript files

  • /dist/scss/stylesheets/uswds.scss: Backwards compatible USWDS Sass entry point

  • /dist/scss/theme: Example theme files

  • /dist/scss/theme/_uswds-theme.scss: Example theme settings file

  • /dist/scss/theme/_uswds-theme-custom-styles.scss: Example custom settings file

  • /dist/scss/theme/styles.scss: Example project Sass entry point

  • /packages: Source files for USWDS components and other functionality.

  • /packages/usa-[component]: Each package has a name like usa-[component] that matches its class name in the design system, like usa-accordion.

  • /packages/usa-[component]/_index.scss: Sass entry point for the package.

  • /packages/usa-[component]/src: Package source files

  • /packages/usa-[component]/src/index.js: Package javascript

  • /packages/usa-[component]/src/usa-component.stories.js: Storybook setup

  • /packages/usa-[component]/src/usa-component.twig: Component template

  • /packages/usa-[component]/src/index.js: Package javascript

  • /packages/usa-[component]/src/content: Package template content

  • /packages/usa-[component]/src/test: Package unit tests

  • /packages/usa-[component]/src/styles: Package source Sass

  • /packages/uswds: The package most projects include by default. This bundle includes all USWDS components and functionality.

  • /packages/uswds-[bundle]: Other non-component functionality is included in uswds--prefixed packages. These bundles might collect common component packages (uswds-form-controls) or important internal functionality (uswds-core).

  • /src: Placeholders included for backwards compatibility. Most projects should avoid using the contents of this directory.

  • /tasks: Internal build process files (not used in USWDS projects)

Installing the design system

There are two ways to install the design system on a project:

  • Installing it as a project dependency using Node and npm
  • Installing the package directly from GitHub

We recommend using npm to make it as straightforward as possible to install the design system and update it as we release new versions.

Install using Node and npm

npm is a package manager for Node-based projects. USWDS maintains the @uswds/uswds package that includes both the pre-compiled and compiled files. npm packages make it easy to update and install the design system from the command line.

  1. Install Node/npm. Below is a link to find the install method that coincides with your operating system:

    Note for Windows users: If you are using Windows and are unfamiliar with Node or npm, we recommend following Team Treehouse's tutorial for more information.

  2. Make sure you have installed it correctly:

    npm -v
    6.13.0 # This line may vary depending on what version of Node you've installed.
  3. Create a package.json file. You can do this manually, but an easier method is to use the npm init command. This command will prompt you with a few questions to create your package.json file.

  4. Add @uswds/uswds to your project’s package.json:

    npm install --save @uswds/uswds@latest

The @uswds/uswds module is now installed as a dependency. You can use the compiled files found in the node_modules/@uswds/uswds/dist/ directory or the source files in the node_modules/@uswds/uswds/packages/ directory.

Note: We do not recommend directly editing the design system files in node_modules. One of the benefits of using a package manager is its ease of upgrade and installation. If you make customizations to the files in the package, any upgrade or re-installation will wipe them out.

Install the package directly from GitHub

If you’re using a framework or package manager that doesn’t support npm, you can find the source files in this repository and use them in your project. Otherwise, we recommend that you follow the steps outlined in this section.

  1. Download the USWDS package directly from the latest USWDS release and uncompress that file.

  2. Copy these files and folders into a relevant place in your project's code base. Here is an example structure for how this might look:

    example-project/
    ├── assets/
    │   ├── uswds/
    │   │   ├── dist/
    │   │   ├── packages/
    │   │   └── src/
    │   ├── stylesheets/
    │   ├── images/
    │   └── javascript/
    └── index.html
    

    You'll notice in our example above that we also outline a stylesheets, images and javascript folder in your assets folder. These folders are to help organize any assets that are unique to your project and separate from the design system assets.

Using USWDS CSS and JavaScript in your project

The three files critical to any USWDS project are the stylesheet, the JavaScript, and the initializer. Most projects require all of these to function properly.

  • Stylesheet: This is the compiled CSS stylesheet that describes how design system components look. To start, reference either uswds.css or uswds.min.css in the <head> of your document. Find this file in /dist/css. Most projects will want to compile their own CSS from USWDS source Sass instead of using the precompiled version. For more about this, see Compiling USWDS Sass into CSS, below.
  • Library: This is the compiled JavaScript that controls component interactivity. Reference either uswds.js or uswds.min.js at the end of the <body> of your document. Find this file in /dist/js.
  • Initializer: This small JavaScript file (less than 1 KB minified) helps the browser know if the USWDS JavaScript library is loading properly. This prevents component content from "flashing" or "shifting" while the page loads. Reference uswds-init.min.js in the <head> of your page, or inline its contents directly into the <script> tag. Find this file in /dist/js.

Reference the stylesheet, library, and initializer in each HTML page or dynamic template in your project.

Here is an example of how to reference these assets in your index.html file:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My Example Project</title>
    <script src="assets/uswds/dist/js/uswds-init.min.js"></script>
    <link rel="stylesheet" href="assets/uswds/dist/css/uswds.min.css" />
  </head>
  <body>
    <script src="assets/uswds/dist/js/uswds.min.js"></script>
  </body>
</html>

And that’s it — you should now be able to copy our code samples into your index.html and start using the design system.

Compiling USWDS Sass into CSS

If you want to take full advantage of USWDS custom settings and add build new styles and components with the USWDS toolset, you'll need a way to access the assets in the USWDS package and compile custom CSS from the USWDS source files.

USWDS uses the task manager Gulp as a way to add USWDS assets to a project and compile our CSS from the package source. Gulp is a useful and powerful tool, but it can be difficult to set up if you are new to it.

The USWDS Compile package is made for developers new to Gulp or those who just want a simple setup to compile USWDS Sass. The repo contains files and instructions for setting up the compiler, initializing USWDS, and compiling CSS from the source files.

Sass compilation requirements

USWDS Sass needs three things to compile properly:

  • Sass Module syntax: USWDS requires a modern Sass compiler that can parse Sass Module syntax.
  • Autoprefixing: USWDS requires Autoprefixing your CSS with a specific .browserslistrc.
  • Sass Load Paths: USWDS requires Sass compilers use Load Paths that reference the /packages directory in the USWDS package

Note: Using a compiler package like USWDS Compile is a good way to fulfill these requirements automatically.

Autoprefixing

The design system requires autoprefixing to work properly. Don't add vendor prefixes to your custom styles manually — it is more reliable to use autoprefixing. Autoprefixing services like gulp-autoprefixer automatically add vendor prefixes to CSS rules. We use the following autoprefixer settings via .browserslistrc config:

> 2%
last 2 versions
IE 11
not dead

Sass Load Paths

USWDS 3.0 and newer require the use of Sass Load Paths to compile properly.

USWDS 3.0 load paths must include a path to the /packages directory in the USWDS package, typically by updating an IncludePaths setting to include node_modules/@uswds/uswds/packages.

Here's how this might look in Gulp and in Webpack:

Gulp
.pipe(
  sass({
    includePaths: [
      "./node_modules/@uswds/uswds/packages",
    ],
  })
Webpack
loader: "sass-loader",
options: {
  sassOptions: {
    includePaths: [
      "./node_modules/@uswds/uswds/packages"
    ],
  },
},

Other useful compiler postprocessing

  • Minification: We recommend using a minifier like csso to compress your final compiled CSS.
  • Sourcemaps: We recommend using a sourcemap tool like gulp-sourcemaps to assist debugging by keeping track of source Sass locations.

Sass and theme settings

The design system is customizable using the power of Sass (Syntactically Awesome Style Sheets). The critical files you'll need in your project are those in dist/scss/theme:

  • _uswds-theme.scss: custom theme settings
  • _uswds-theme-custom-styles.scss: additional project CSS for customizing or adding to what USWDS provides
  • styles.scss: The Sass entry point. This is the primary Sass file that you'll compile. It collects theme settings, USWDS source files, and custom CSS

styles.scss looks something like the following code. It adds all the project theme settings, then adds USWDS source, and finally adds your project's custom styles:

@forward "uswds-theme";
@forward "uswds";
@forward "uswds-theme-custom-styles";

Technical note: The @forward 'uswds' statement above references the uswds package in node_modules/@uswds/uswds/packages. The compile functions included in uswds-compile automatically look for USWDS packages in the proper directory using includePaths.

JS customization

Unfortunately, customizing the JavaScript for the USWDS currently requires NodeJS and a module bundler like Browserify or Webpack. We apologize for this inconvenience, and are working to resolve it in a future release of the design system.

USWDS JavaScript is separated into components (just as with the CSS and HTML) and initialized with event handlers when the DOM is ready. These components are accessible as CommonJS modules that can be required in other JavaScript files, then built for the browser. The components are not accessible in the global browser scope, but can be extended to be included by requiring components and setting it to a global scope:

window.uswds = require("./components");

Each component has a standardized interface that can be used to extend it further. The components store a HTML class (like .usa-accordion__button[aria-controls]) used to link HTML elements with the JavaScript component. When a component is initialized, it searches through the current HTML DOM to find all elements that match the class and initializes the component JavaScript for those elements. The primary methods for each component include:

  • on: Initialize a component's JavaScript behavior by passing the root element, such as window.document.
  • off: The opposite of on, de-initializes a component, removing any JavaScript event handlers on the component.
  • hide: Hide the whole component.
  • show: Shows a whole, hidden component.
  • toggle: Toggles the visibility of a component on and off based on the previous state.

Some components have additional methods based on that component's functionality. Any additional methods are found in that component's JavaScript file.

If you’re using a modern framework like React or Angular you can import components and initialize them in your library's DOM ready lifecycle event.

Importing a modular component.

import USWDS from "@uswds/uswds/js";
const { characterCount, accordion } = USWDS; // deconstruct your components here

// Alternatively
import accordion from "@uswds/uswds/js/usa-accordion";

⚠️Requires webpack 5+

React hooks example:

function App() {
  const ref = document.body;

  useEffect(() => {
    // initialize
    characterCount.on(ref);
    // default ref is document.body, if you want to use
    // default you do not have to pass arguments
    accordion.on();

    // remove event listeners when the component un-mounts.
    return () => {
      characterCount.off();
      accordion.off();
    };
  });
}

Angular example:

export class App implements OnInit {
  constructor() {
    this.ref = document.body;
    // default ref is document.body, if you want to use
    // default you do not have to pass arguments
  }

  ngOnInit() {
    // initialize
    characterCount.on(this.ref);
    accordion.on();
  }

  // remove event listeners when the component un-mounts.
  ngOnDestroy() {
    characterCount.off();
    accordion.off();
  }
}

Style theming and tokens

USWDS 3.0 provides extensive support for theming via its theme settings files introduced in Sass and theme settings, above.

Set theme settings with USWDS design tokens, not with values directly. They tend to be quoted strings like 'desktop' or 'md' or unitless numbers like 2 or -1.5. Tokens are the values passed into the USWDS functions and mixins that parse them. They are the keys that, through the mechanism of a function or mixin, unlock a value — they are not the values themselves.

Visit the Design tokens section of USWDS 3.0 documentation for more on the available tokens for color, spacing units, font size, and more.

Using tokens in theme settings

The following is an example of theme settings from _uswds-theme.scss:

@use "uswds-core" with (
  $theme-grid-container-max-width: "desktop",
  $theme-site-margins-breakpoint: "desktop",
  $theme-site-margins-width: 4,
  $theme-site-margins-mobile-width: 2,
)

The USWDS uses those tokens to build component styles:

.usa-example {
  @include u-padding-x($theme-site-margins-mobile-width);
  max-width: units($theme-grid-container-max-width);

  @include at-media($theme-site-margins-breakpoint) {
    @include u-padding-x($theme-site-margins-width);
  }
}

This is the functional equivalent of:

.usa-example {
  @include u-padding-x(2);
  max-width: units("desktop");

  @include at-media("desktop") {
    @include u-padding-x(4);
  }
}

Which, if $theme-respect-user-font-size is set to true would output something like:

.usa-example {
  padding-left: 1rem;
  padding-right: 1rem;
  max-width: 64rem;
}

@media screen and (min-width: 64em) {
  .usa-example {
    padding-left: 2rem;
    padding-right: 2rem;
  }
}

In general, USWDS sets variables with tokens, and passes those variables into functions and mixins in the source Sass.

Set the base asset paths (fonts and images)

The values of $theme-font-path and $theme-image-path will be appended to USWDS font paths and image paths, respectively:

@use "uswds-core" with (
  $theme-font-path: "../fonts",
  $theme-image-path: "../img",
);

CSS architecture

  • The CSS foundation of this site is built with the Sass preprocessor language.
  • The CSS organization and naming conventions follow 18F’s Engineering Guide.
  • We format our code with Prettier, per the formatting section of the 18F Engineering Guide.
  • CSS selectors are prefixed with usa (For example: .usa-button). This identifier helps the design system avoid conflicts with other styles on a site which are not part of USWDS.
  • Uses a BEM approach for naming CSS selectors. Blocks are separated from elements with two underscores (__). Multi-word blocks use single hyphens instead of spaces. Modifier classes are additive — proper markup requires the base class and the modifier class or classes. Modifier classes consist of the base class plus a modifier suffix, separated by two hyphens (--) as in .usa-button.usa-button--secondary or usa-accordion.usa-accordion--bordered.
  • Uses modular CSS for scalable, modular, and flexible code.
  • Uses nesting when appropriate. Nest minimally with up to two levels of nesting.
  • Hard-coded magic numbers are avoided.
  • Media queries are built mobile first.
  • Spacing units are set with the units() function as described in the USWDS 3.0 documentation. In general, we use spacing in multiples of 8px — expressed as a multiple in units([multiple]). For instance units(2) is the equivalent of 2 * 8px or 16px. In the final, compiled CSS, this value will be expressed in rem, as a multiple of the base font size set with $theme-base-font-size.

For more information, visit: 18F’s CSS Guide

Browser support

We’ve designed the design system to support older and newer browsers through progressive enhancement. The current major version of the design system (3.0.0) follows the 2% rule: we officially support any browser above 2% usage as observed by analytics.usa.gov. Currently, this means that the design system version 3.0.0 supports the newest versions of Chrome, Firefox, and Safari.

As of USWDS 3.0.0 we no longer officially support Internet Explorer 11 (IE11). We will continue to include IE11 polyfills and prefixing for the first few releases in USWDS 3.x — when we finally drop IE11, we'll make a note in the release notes and in this documentation.

Accessibility

The design system also meets the WCAG 2.0 AA accessibility guidelines and conforms to the standards of Section 508 of the Rehabilitation Act. Additionally, we try to meet the requirements of WCAG 2.1.

We use the following tools to ensure USWDS is accessible:

If you find any issues with our accessibility conformance, please create an issue in our GitHub repo or send us an email at [email protected]. We prioritize accessibility issues. See the Accessibility page of our website for more information.

Long-term support of v1.x

Version 1.x is no longer maintained.

Long-term support of v2.x

Version 2.x is in maintenance mode and will continue to get important bugfixes and security patches until May 2023.

Need installation help?

Do you have questions or need help with setup? Did you run into any weird errors while following these instructions? Feel free to open an issue here:

https://github.com/uswds/uswds/issues.

You can also email us directly at [email protected].

Contributing to the code base

For complete instructions on how to contribute code, please read CONTRIBUTING.md. These instructions also include guidance on how to set up your own copy of the design system style guide website for development.

If you would like to learn more about our workflow process, check out the Workflow and Issue label Glossary pages on the wiki.

If you have questions or concerns about our contributing workflow, please contact us by filing a GitHub issue or emailing our team.

Reuse of open-source style guides

Much of the guidance in USWDS leans on open source designs, code, and patterns from other civic and government organizations, including:

Licenses and attribution

A few parts of this project are not in the public domain. Attribution and licensing information for those parts are described in detail in LICENSE.md.

The rest of this project is in the worldwide public domain, released under the CC0 1.0 Universal public domain dedication.

Contributing

All contributions to this project will be released under the CC0 dedication alongside the public domain portions of this project. For more information, see CONTRIBUTING.md.

uswds-team's People

Contributors

amyleadem avatar thisisdano avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Forkers

isabella232

uswds-team's Issues

August Monthly Call (8.20) // Follow up items

August Monthly Call (8.20) fairly light due to outside presenter
Topics:
• 2.8.1 release review
• Any new site launches
Tasks:
• Pre activities: script submission and review
• Prep // run through meeting
• post activities (blogs, etc)

Tasks:

  • Meeting to determine what to share. Scheduled 8.26.
  • Schedule a reoccurring 30-min post call recap from 3:40-4 pm ET (Dan, Ammie, Jaimee, Katie, Allie goal: collect links and high level recap in post)
  • @katieekline to develop post call gDoc for review
  • Approval of message by client
  • Share a recap of the call with links to a key resource or two in #uswds-public.

Update and validate personas

User story:
As a UX specialist, I want to evaluate current personas so that I can either develop new personas and /or revise, validate existing personas.

This story is about the need to have accurate and updated persona information so that the team can better tailor content and customer experience to specific users of our product. Personas help define common user needs and bring them to the forefront of planning. They provide the team a shared understanding of users in terms of goals and capabilities and help keep our product user focused.

Updated personas will lay the foundation to fulfill product roadmap items such as, but NLT “getting started” content directed at specific users. This information will also inform a larger needs assessment surrounding site IA, content audit, and overall usability.

Existing Personas and Roadmap

Acceptance criteria:

  • Documentation of key findings to include recommendations and next steps. What we know, what we need to know.
  • Persona creation/development, revisions, and/or validations.

Tasks to complete:

  • Synthesize and analyze user research tests, and any other existing information to
    develop key findings and recommendations
  • Persona creation/development/updates
  • Possible next steps with Katie

Definition of Done:
• Meets acceptance criteria
• Cared Framework: Clear, Accessible, Resilient, Evidence-based, Documented

Prepare presentation for IAAF (due: September 10)

We are presenting at the 2020 Interagency Accessibility Forum (IAAF) on October 6 from 2-2:25. The format is a ~20 minute presentation followed by Q&A.

By September 10, we must send our presentation to Avis Ryan in OGP.

Topic
Embrace Accessibility and Build It Into Every Decision - 21st Century IDEA requirements are critical and necessary, but only the beginning. Accessibility is about real people who use our services. Everyone has a role to play in making federal websites and digital services accessible and inclusive. The U.S. Web Design System's Embrace Accessibility principle encourages teams to design generously and celebrate requirements as a set of constraints that help us create better products for all users. Accessibility affects everybody. Build it into every decision.

Panel Members
Ammie Farraj Feijoo, General Services Administration
Dan Williams, General Services Administration

Submit speaker form to present at IAAF

The Federal Chief Information Officer (CIO) Council Accessibility Community of Practice (ACOP) asked for recommendations for the upcoming Interagency Accessibility Forum (IAAF). Responses are due by 5/22/2020.

Each session will be a 45-minute discussion on the speaker’s area of expertise within accessibility and Section 508.

Event Details
WHEN: September 30 - October 1, 2020, 9:00 a.m. to 4:00 p.m.
WHERE: U.S. Census Bureau Headquarters: located at 4600 Silver Hill Road, Suitland, MD 20746
WHO: Federal government employees and contractors; industry technology and accessibility service providers
QUESTIONS: Contact us at [email protected]

Generate a VPAT for USWDS

Background

As an agency customer
I would like to see a Voluntary Product Accessibility Template (VPAT) for USWDS
So I know can evaluate the design system for accessibility

Section508.gov recommends generating a VPAT™ for any technology that’s intended to be marketed to the Federal government.

**Acceptance criteria **

  • USWDS uses the VPAT™ to make specific statements in simple recommended language to demonstrate how its features and functional characteristics of meet the Revised 508 Standards.

Tasks to complete this issue

  • Generate a VPAT for USWDS
  • Publish information on the VPAT

Definition of done

  • Acceptance criteria met

September monthly call activities(9.17)

September monthly call (9.17)

USWDS 2.9.0
Improvements:
Added align-self utilities
Added accent-warm buttons
Added SHA-256 hash to zip release

Bug fixes
Disabled radio button styling
Secondary button active state
List alignment inside alerts
Proper styling of legends

Three new components
Identifier
Step indicator
Time Picker

Website updates:
USWDS fundamentals and getting started guide
Sample contract language for 21st century IDEA

Tasks:

  • Pre activities: [script submission and review](Monthly call Script)
  • [NA] possible re-record test
  • Prep // run through meeting
  • Post call sync
    Post call activities
  • Release announcement
  • develop post call recap announcement in gDoc template for review
  • Share out call recap #uswds-public.

Deprecate components.designsystem.digital.gov

Tasks to deprecate https://components.designsystem.digital.gov:

Submit a pitch for UXPA Magazine by Aug 15

The upcoming 20.3 issue of UXPA Magazine will cover UX governance:

When designing experiences for our users, different disciplines merge into the equation. IT infrastructure, APIs, Data structures, Design Systems, Open and Dynamic repositories for continuous improvement, to name a few, come into our mind. We need to synchronize all of them building a governance framework that puts users in the center of the system. All of those who want to write about the topic are welcome to submit. We are looking for articles that cover the topic from different perspectives and disciplines.

Article proposals are due August 15, 2020. Visit http://uxpamagazine.org/information-for-authors/ for information on how to submit submittal.

IT scan and depenabot alerts Nov

Dependabot alerts for the week of Oct 27 - Nov 3

  • All returns entered in POAM, ID# 010-028, new entries highlighted in yellow for review. Green highlight indicates returns that can be fixed. Four out of 19 returns can be resolved.
  • Final Reviewer: Cross reference check with POAM, 2020-015, 2020-017, 2020-019, 2020-023
  • PR for merge: uswds/luminance-tool#18

Add a Breadcrumb component

Why we're doing this

Designers and developers need to provide contextual awareness of where a user is in a websites and provides users a simple way to navigate back to page higher in the site hierarchy.

The Breadcrumb component is available in pretty much every design system🔒 and is a baseline expectation for a design system like USWDS.

Related issues and documentation

TK

How we'll know this new component is done

Clear

  • Include a well-formed user story, preferably one that connects to research findings
  • Use existing code as much as possible
  • Include only the code necessary for the component
  • Affect as few other components as possible
  • Use USWDS code style
  • Use only USWDS design tokens, mixins, and functions
  • Use the same design patterns to solve the same problems

Accessible

  • Add component-based tests to automated testing
  • Pass automated CI accessibility review (aXe)
  • Pass semi-automated accessibility review like Accessibility Insights
  • Pass WCAG 2.1 review
  • Use screen reader and keyboard accessible markup
  • Make scrollable elements focusable for keyboard users
  • Assure markup describes a logical structure/outline

Resilient

  • Use a mobile-first design methodology
  • Stress-test with edge cases (and document these variants in the library)
  • Outline contexts where this component might appear (and add these templates to the library)
  • Perform critical tasks with low bandwidth and unreliable CSS load
  • Perform critical tasks when JavaScript does not load
  • Document and addresses any new package vulnerability
  • Pass Snyk scan
  • npm audit: Contain no Critical vulnerabilities
  • npm audit: Contain no High vulnerability standard dependencies
  • Justify any High vulnerability dev dependencies
  • Provide a print stylesheet
  • Autoprefix with: "> 2%", "Last 2 versions", "IE 11"
  • Test back to IE11 with a cross-platform testing tool
  • Include functional unit tests

Evidence-based

  • Document internal or external developer usability test findings (and link to the documentation)
  • Document internal or external end-user usability test findings (and link to the documentation)
  • Collect links and references to any sources used to create this component in the documentation
  • Perform landscape analysis of existing government examples of the component
  • Compare component features with landscape to assure we're meeting expectations

Documented

  • Include a guidance page on the uswds-site linked to the new uswds work branch via package.json
  • Include the following sections in site documentation:
    • Name
    • Description
    • Example
    • Component code
    • When to use
    • When to consider something else
    • Usability guidance
    • Accessibility guidance
    • Implementation guidance
    • When to consider something else
    • Resources
    • Package information
  • Document any additions to USWDS settings on the settings page
  • Create a component package that allows Sass to import only that component and its dependencies. See an example.
  • Use plain language and explain any technical terms
  • Document source code with comments
  • Include a blog post that contextualizes the component work and explains what, why, and how of the component
  • Content proofread with no typos or broken links

Sample contract language: comms plan and approval

Create a communication plan for Sample contract language. Review and approval of plan.
Draft Comms messaging
Plan should include:

  • Create short post to cross promote on Digital.gov and in the Digital.gov newsletter
  • Draft email and share with web managers listserv
  • Draft Slack message and share on #uswds-public Slack
  • Draft social promos and tweet from USWDS and Digital.gov

DoD

  • USWDS review and approval
  • Comms review and approval 2/3
  • follow up w execution of comms plan #60

Anchor Component: Discovery

User story: As a UX specialist, I want to discover user needs surrounding the anchor component so that acceptance criteria for best default is accurate, and so the final component is as valuable as possible.

This story is linked to the Anchor component epic. This component is a complement to the footer. Its purpose is to provide a consistent way of presenting information and links that are required by federal policy. The Anchor Component is distinctly different from the footer and has a simple, neutral default. Embedded within the component are best practice suggestions as to what links or information should be included.

References:
USWDS Anchor Issue: uswds/uswds#3525

Previous landscape analysis examples:
https://github.com/uswds/uswds/wiki/Card-Landscape-Analysis
https://bixal.invisionapp.com/freehand/document/tSS644yrC
Previous heuristic analysis (sample: Preliminary analysis: https://github.com/uswds/uswds/wiki/Breadcrumbs-Landscape-Analysis

Acceptance criteria:

  • Research based minimal acceptance criteria for best default and most added value.
  • Landscape Analysis (used to create guidance)
  • Heuristic Analysis (used to create guidance)
  • Naming convention: suggest best practice terminology
  • Identify users/roles to account for impacts.

Tasks to complete:

  • Determine past research techniques. What has been used, what was most useful.
  • Determine other (or new) platforms for feedback: Slack, 10x forms, Qualtrics on website.
  • Determine if interviewing users is a useful option? PRA issues (ask Ammie)? Perhaps interview Bixal staff (ask Philip)?
  • Landscape Analysis (used to create guidance)
  • Heuristic Analysis (used to create guidance)
  • Naming convention: suggest best practice terminology
  • Identify users/roles to account for impacts. Who are key users and what is their specific information needs?
  • Determine what is the best default. Define user needs surrounding the default.
  • Develop minimal acceptance criteria for best default and most added value.

Definition of Done:
• Meets acceptance criteria
• Cared Framework: Clear, Accessible, Resilient, Evidence-based, Documented

Document the process to get feedback on new components

Background

As a USWDS customer
I would like to anticipate communication with USWDS on new component releases
So that I can understand the process and contribute feedback throughout

As a USWDS team member
I would like to follow a standard process to receive feedback from customers on new components throughout the lifecycle
So I ensure we're listening and taking customer needs and public user needs into account

This story is about documenting the process to get feedback on new components. We want to understand needs through the lifecycle from discovery to post-release:

  • What agency teams need and for what public users
  • What they would use the component for
  • Existing research or work done by other teams
  • Considerations for accessibility and usability
  • Any applicable policies, standards, or guidelines that apply,
  • Bugs in using the component
  • Share successful implementations
  • Further needs for improvements and customization options.

Acceptance criteria

  • We have documented the process to get feedback on new components
  • We have created some boilerplate language to collect feedback at each stage
  • We have defined KPIs to measure effectiveness of our efforts to collect feedback
  • A folder is created in Google Drive to collect the feedback and research
  • The process is documented and findable in the wiki

Tasks to complete this issue

  • Define the stages
  • Review existing efforts to collect feedback, including from the 10x team
  • Draft the high-level process
  • Identify various touchpoints and channels, write boilerplate language, and define KPIs
  • Schedule interviews with a few federal customers
  • Analyze feedback and review the process
  • Walk through topline with USWDS lead and validate to-be process
  • Create gDrive folder
  • Post to wiki

Definition of done

  • Acceptance criteria met

Analyze data from USWDS monthly calls

As a member of the USWDS product team,
I would like to see insights from the call data
So I can see trends over time and ensure the calls are valuable

Goal: better develop metrics and document process
• metrics: analyze rather than collect
• define goals
• set KPIs
• develop experiments to discover satisfaction--i.e. diversity across agencies
• Develop clear CTA
• Tighten up and document process

Anchor Component (Milestone)

Description: Anchor component is a complement to the footer. Its purpose is to provide a consistent way of presenting information and links that are required by federal policy. The Anchor Component is distinctly different from the footer. It has a simple, neutral default. Embedded within the component are best practice suggestions as to what links or information should be included.

Value: will add some nice consistency to how agencies link back to USA.gov.
Making the requirement that states that all gov sites need to link to USA.gov "official" in the USWSDS (with consistent language in both, English and Spanish) is fantastic. Other gov agencies won't have to worry about where exactly to put it, the verbiage and the style.

Issue info: This component has previously been developed by digital.gov. The Bixal team should complete discovery process to validate digital.gov or further develop a new prototype or new features.
Example: https://digital.gov/
Digital.gov Issue: GSA/digitalgov.gov#2351
USWDS Issue: uswds/uswds#3525

Acceptance Criteria

  • All associated tasks and issues are complete:

  • Discovery - #28

  • Wireframe/Prototype - uswds/uswds#3565

  • Content

  • Build

  • Test

  • Release

Definition of Done:
• Meets acceptance criteria
• Cared Framework: Clear, Accessible, Resilient, Evidence-based, Documented

Coordinate meeting with HHS/ASPA

scheduling internal meeting with Bixal and Dan and Ammie to discuss approach for meeting with ASPA product owner to discuss USWDS adoption

Add a card component

Why we're doing this

Designers need a card component to organize summarized materials, and present these summaries in a scannable, browsable format. A card pattern serves to:

  • collect together related materials
  • distinguish related collected materials from their context
  • connect related collections as a "collection-of-collections"
  • provide a simple followup action related to the collected content

The card component is available in pretty much every design system🔒 and is a baseline expectation for a design system like USWDS.

Related issues and documentation

Card prototype
Problem Statement
Initial Assumptions and Hypothesis
Landscape Analysis
Landscape Analysis of Existing Gov Solutions
Draft Card Principles
Initial build of card component
Site documentation for the card component
flex-fill not working in IE11

How we'll know this new component is done

Clear

  • Include a well-formed user story, preferably one that connects to research findings
  • Use existing code as much as possible
  • Include only the code necessary for the component
  • Affect as few other components as possible
  • Use USWDS code style
  • Use only USWDS design tokens, mixins, and functions
  • Use the same design patterns to solve the same problems

Accessible

  • Add component-based tests to automated testing
  • Pass automated CI accessibility review (aXe)
  • Pass semi-automated accessibility review like Accessibility Insights
  • Pass WCAG 2.1 review
  • Use screen reader and keyboard accessible markup
  • Make scrollable elements focusable for keyboard users
  • Assure markup describes a logical structure/outline

Resilient

  • Use a mobile-first design methodology
  • Stress-test with edge cases (and document these variants in the library)
  • Outline contexts where this component might appear (and add these templates to the library)
  • Perform critical tasks with low bandwidth and unreliable CSS load
  • Perform critical tasks when JavaScript does not load
  • Document and addresses any new package vulnerability
  • Pass Snyk scan
  • npm audit: Contain no Critical vulnerabilities
  • npm audit: Contain no High vulnerability standard dependencies
  • Justify any High vulnerability dev dependencies
  • Provide a print stylesheet
  • Autoprefix with: "> 2%", "Last 2 versions", "IE 11"
  • Test back to IE11 with a cross-platform testing tool
  • Include functional unit tests

Evidence-based

  • Document internal or external developer usability test findings (and link to the documentation)
  • Document internal or external end-user usability test findings (and link to the documentation)
  • Collect links and references to any sources used to create this component in the documentation
  • Perform landscape analysis of existing government examples of the component
  • Compare component features with landscape to assure we're meeting expectations

Documented

  • Include a guidance page on the uswds-site linked to the new uswds work branch via package.json
  • Include the following sections in site documentation:
    • Name
    • Description
    • Example
    • Component code
    • When to use
    • When to consider something else
    • Usability guidance
    • Accessibility guidance
    • Implementation guidance
    • When to consider something else
    • Resources
    • Package information
  • Document any additions to USWDS settings on the settings page
  • Create a component package that allows Sass to import only that component and its dependencies. See an example.
  • Use plain language and explain any technical terms
  • Document source code with comments
  • Include a blog post that contextualizes the component work and explains what, why, and how of the component
  • Content proofread with no typos or broken links

Move from `master` branch to `main` across USWDS repos

For each of our repos, we should move from using a master branch to a main branch. This in line with what GitHub is doing and it's a small but meaningful step toward promoting inclusive language in our project and codebase.

We'll need to update not only our branches, but our documentation and codebase hooks — particularly with CI.

We can start with the instructions here in one of our smaller repos, and apply what we learned to the larger ones.

Are there any other downstream implications to this change?

  • uswds
  • uswds-gulp
  • uswds-sandbox
  • uswds-site
  • uswds-team
  • uswds-for-designers
  • luminance-tool
  • public-sans

Modernize USWDS Websites (epic)

Why we're doing this

All GSA websites must follow the Guidelines for GSA’s Digital Presence🔒 linked within GSA Order 2140.2🔒. GSA also developed compliance criteria🔒 to help web managers follow these guidelines and meet the goals of 21st Century IDEA.

All GSA sites were required to have a modernization plan in place by May 2020. Below are the action items from the website modernization plans for USWDS websites.

designsystem.digital.gov

In FY 2020, based on the Modernization Plan for designsystem.digital.gov🔒, we will make the following improvements on https://designsystem.digital.gov:

components.designsystem.digital.gov

In FY 2020, based on the Modernization Plan for components.designsystem.digital.gov🔒, we will make the following improvements on https://components.designsystem.digital.gov:

- [ ] Incorporate a11y testing (est. 40 hours)
- [ ] Use USWDS, follow GSA branding guidelines, and add anchor (est. 40 hours)
- [ ] Add DAP
- [ ] Add USWDS GA

public-sans.digital.gov

In FY 2020, based on the Modernization Plan for public-sans.digital.gov🔒, we will make the following improvements on https://public-sans.digital.gov:

v1.designsystem.digital.gov ✅

In FY 2020, based on the Modernization Plan for v1.designsystem.digital.gov🔒, we will make the following improvement on https://v1.designsystem.digital.gov:

v2alt.designsystem.digital.gov ✅

Redirects

We will continue to maintain redirects for four legacy subdomains:

  1. https://components.standards.usa.gov
  2. https://design-principles-guide.18f.gov
  3. https://standards.usa.gov
  4. https://v2.designsystem.digital.gov

Standardize Issue Criteria

User story: As a PM, I want to standardize issue criteria, so that issues are detailed, clear and understandable to the entire team.

This story will create consistency across issues.

Acceptance criteria:

  • Approved documentation of issue criteria guidance
  • Archived to appropriate location for ease of reference

Tasks to complete:

  • Research past issues for good examples
  • Develop issue criteria
  • Is there an existing template for guidance and SOP documentation?
  • Submit for feedback and revisions and Approval

Definition of Done:
• Meets acceptance criteria
• Cared Framework: Clear, Accessible, Resilient, Evidence-based, Documented

Conduct User Interviews

Task checklist
Link to interview research plan
Link to interview script

  • Identify interview subjects
  • Do not add interview subject names to GitHub issues or Gdocs. Protect identity by using anonymous pseudonyms.
  • Send intro email to interview subjects, copy Ammie and Dan
  • Identify interviewer & other attendees
  • Schedule in Google Calendar, 45 minutes
  • Ask for permission to record
  • Create, share, and synthesize notes
  • Capture findings
  • Archive notes, archive recording

Publish How to Test Websites for Accessibility resource

Here is a link to the main document.
https://docs.google.com/document/d/1Y1Sozh0AaFt-umWR2Sz_sjXrNZEAbmorBt-GmllivSk/edit#

Please review the items below:

  • Link to recording on YouTube (not live yet)
  • Link to captioning (which has been edited and custom timed with the YouTube video)
  • Link to presentation
  • Primary Resource Page
  • Updates to Accessibility Pages

Robert Jolly's interview and notes are included as references, but we do not plan to post them. Sara just asked us to interview him for more background on the Trusted Tester program.

Due 10/8: Report out on website modernization progress

Add updated information for USWDS in the FAS spreadsheet🔒 by COB October 8.

The instructions to use the sheet are in the Instructions tab. The data that was submitted for plans earlier this year is also pre-populated (as reference) in the sheet (Columns E and F).

See #7 for what's been done and what's left to do for the 4 USWDS websites.

Improve Issue Management

User story: As a PM, I want to guide and streamline the issue management process so that our team is working smoothly in an agile framework.

This story will help to create consistency with the agile methodology and provide guidance as to where, when, and how work is tracked.

Acceptance criteria:

  • Approved documentation of issue management guidance
  • Archived to appropriate location for ease of reference
  • Plan for a revisit and revision for continued improvement

Tasks to Complete:

  • Research current agile process and determine issues and improvements
  • Research current issue content process
  • Research best way to treat epics, stories, tasks, subtasks with in Github.
  • Determine best options on how to measure LOE
  • Submit documentation for feedback and revisions

Definition of Done:
• Meets acceptance criteria
• Cared Framework: Clear, Accessible, Resilient, Evidence-based, Documented

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.