GithubHelp home page GithubHelp logo

uswds / uswds Goto Github PK

View Code? Open in Web Editor NEW
6.6K 6.6K 919.0 162.79 MB

The U.S. Web Design System helps the federal government build fast, accessible, mobile-friendly websites.

Home Page: https://designsystem.digital.gov

License: Other

JavaScript 33.39% HTML 3.54% SCSS 47.89% Shell 0.05% Twig 15.13%
design design-systems government uswds

uswds'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's People

Contributors

aduth avatar ahelkit avatar alexose avatar amyleadem avatar brunerae avatar carodew avatar colinpmacarthur avatar donjo avatar el-mapache avatar gscottqueen avatar hursey013 avatar jaredcunha avatar jonathanbobel avatar mahoneycm avatar maya avatar mejiaj avatar mherchel avatar mitchmoccia avatar mollieru avatar rogeruiz avatar saracope avatar scottqueen-bixal avatar shawnbot avatar sknep avatar swimburger avatar thisisdano avatar toolness avatar vgvg avatar wbyoko avatar yozlet avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

uswds's Issues

Component [Labels/Tags]

v1 of components: unbranded basic styling focused on layout, sizing, padding + UX/interaction

Leaving this here for feedback:
labels_ui_v1

Change files in /pages from .md to .html

After running into the following issue, @maya and I discussed switching our files over to .html. While Jekyll typically uses .md files for things like blog posts and other pages that may not use html, this is not the case for these files. This will also help avoid these kinds of issues in the future.

Feature request: Forms

In the case of openFOIA, we've got medium to large forms:

  • For potential future implementation: FOIA request submission. Audience: FOIA requesters.
  • Currently being implemented: Contact update form. Audience: Government agencies.

Because the second one is the only one that has been fully fleshed out, I will go into more detail.

Features+Description

  • Many fields, many of which are pre-populated but may need to be edited/updated (label and input field layout become very important here)
  • About a 40/60 split required vs optional elements (do we mark optional? do we mark required?)
  • Validation of phone numbers, zip codes, email, URLs (how and when do we display errors?)
  • For some (yes unfortunate) instances, many dozens of fields to navigate. DOJ for instance has 38-sub agencies, each with 16-17 fields. How do users navigate this? (See one solution in the openFOIA contact updater mockup)
  • Contextual information. If a field needs further explanation, how do we show that info?
  • Nudges. If a field is optional but we want to nudge users to submit information, how do we do that?

A relatively recent mockup can be seen on the openFOIA repo. Error messages have been moved to below the fields, as the right side of the fields are used for contextual information.

Pattern [Footer]

v1 of components: unbranded basic styling focused on layout, sizing, padding + UX/interaction

These are in-progress -- still need to refine padding and spacing, but @angel would love general feedback on font size + layout. (cc @colinpmacarthur )

(Doing desktop first, then will add in mobile)
footer_desktop_ui_v1

Make this repo public

After discussing with the team in Issue #6, we've decided to move forward in our original plan to make this repo public during the Sprint 3 milestone.

What should our url be?

Opening this issue to brainstorm ideas on what the url for the pattern library should be. Please feel free to add any ideas you have in the comments:

  • uspatternlibrary.*.gov
  • govtwidepatternlibrary.*.gov
  • usgovtpatternlibary.*.gov

[Typography] What kind of type treatments/H styles, etc. should we offer?

v1 of components: unbranded basic styling focused on layout, sizing, padding + UX/interaction

This is not the typography we are suggesting as part of a style guide. This is the typography we are using for v1 of the library, and it will very likely change. We'd like feedback on the way we've presented the type styles and applications, and not on the typeface itself (I guess unless you really like it, which is helpful too).

typography_ui_v1

feature request: list of dates/calendars

One of our biggest priorities coming up will be some kind of calendar or list of upcoming dates. If you can include this, I think it would have broad use. A lot of agencies need to share this info with the public for upcoming public hearings, events, closings, and deadlines for submitting applications or required info (ex: taxes or in the FEC's case, filing campaign finance info).

We have started working on this and could possibly collaborate.

Feature request: content section/style guide

Hi folks!

I submitted some pull requests today because we've got a variety of ongoing projects that would love to be working from the same working style guide.

The strategy is to use the amazing content style guide that data.gov was already using, which was informed by lot so amazing research by the GDS team, and is simple, brief, and already in the public.

Hosting this here will help all of the existing efforts which are currently fractured re-use some of the great work public servants have already done by strengthening this third version of a style guide rather than creating a new one.

Thank you for your awesome work, team style guide!

Component [Grids]

v1 of components: unbranded basic styling focused on layout, sizing, padding + UX/interaction

Leaving this here for feedback:
grid_ui_v1
grid_examples_ui_v1

Set up new Cloud Foundry space/org

  • Have a new instance/org setup
  • Add users to that instance/org
  • Add manifest.yml and travis.yml*
  • This last task will be determined on which build out we decide to go with.

CSS class naming

It would be great to get a consensus on class naming in the markup. I'm struggling with this a bit myself. Even though it's ugly, I am growing fond of the BEM style, because it:

  • avoids unnecessary cascading that can bleed into other components in a big system
  • makes it easy to know the dependencies of a particular element
  • makes it easy to find the style in the file structure if you use the component name for the file name
  • encourages good practices of building in a modular way
/* Block component */
.btn {}

/* Element that depends upon the block */ 
.btn__price {}

/* Modifier that changes the style of the block */
.btn--orange {} 
.btn--big {}

Exceptions

  • How deep should this go? I feel like it should only go one element deep. If it needs to go deeper, you might need another 'block' or component.
  • General helper classes like .left should still be used when possible.

Would love to get opinions on this.

[Charts/Graphs] How should we think about designing these?

Looking from teams to give us a bit more insight on what components of charts and graphs people are looking for. Like styled out bar charts, line graphs, etc?

Would be helpful to get guidance on whether this is about visual guidance and/or also building customizeable interfaces, which will require muchmore front end lift.

Making this repo public instead of private

As a team we have previously discussed making this repo private or public. I'd like to start a thread for us to open that up again for discussion as we head into Sprint One. Here were some initial questions:

  1. Should we keep the repo private until we launch in August?
  2. If so, what other internal contributors could we add for feedback and help?

Component [Search Bar]

v1 of components: unbranded basic styling focused on layout, sizing, padding + UX/interaction

Leaving this here for feedback:

search_bar_ui_v1

Library structure and packaging

Hi friends! I'm pumped to see this thing start to take shape. Y'all are killing it.

Have you given any thought to how the library will be structured? i.e. Will it be monolithic, similar to how Bootstrap and Foundation work, with all components in a single repo and a script that concats all source files? Or will each component have its own repo a la Basscss, Semantic UI, Topcoat?

In the same vein, how will components be packaged for consumption? I assume you'll generate a name-of-library.css file for users to download but do you also plan on publishing it to package registries like npm and Bower? It'd be ideal if each individual component was published separately, so that if I just want your button styles, I'm not forced to install your entire framework. Semantic UI does a really good job in this regard.

I apologize if these topics are premature/overwhelming/have already been discussed. I'm just really excited to see this library happen.

Feedback: [Alerts/Notifications]

v1 of components: unbranded basic styling focused on layout, sizing, padding + UX/interaction

Leaving this here for feedback:
alerts_ui_v1

Add 'under construction' bar to top of the site

Suggest adding an 'in progress' note w 'us govt website' bar.

Suggest repurposing the FOIA team's approach, with the following text:

screen shot 2015-06-24 at 12 36 08 pm

BAR
[US flag] An official website of the U.S. Government. This website is in development. Learn more

DROPDOWN
This site is in development. Tell us what you think!

You are visiting the first release of site designed to create web patterns and element styles for use across federal government digital materials. This release includes wireframe mockups of UI elements. Your feedback is important to us as we build this site and we encourage you to contribute your input at https://github.com/18F/govt-wide-patternlibrary/issues

This project is a partnership of the US Digital Service and 18F. If you'd like to learn more, please email [email protected].

Add smooth scrolling to sidebar items

We currently jump directly to the components after clicking its link. It may be nice to use a smooth scrolling effect so users have context of where they're navigating to within the page.

Update sidenav links to reflect split out components previously called 'Forms'

We broke out the individual bits of 'Form Elements' and 'Form Patterns' into their own sections. The sidebar links currently don't reflect this (though the page content does). Update sidebar nav links as follows (new links in italics):

ELEMENTS

Buttons
Text input
Checkboxes
Radio Buttons
Labels
Dropdowns
Tables

COMPONENTS

Accordions
Alerts
Footers
Address Form
Name Input Fields
SSN Input Fields
Sign in Form
Password Reset Form
Contact Form
Date select
Navigation + Header
Search Bar
Search Results

(I know the alphabetizing will re-order this, that's totally fine)

NOTE: I suspect this is all is subject to change based on usability testing later this week. The goal here is just to make sure we have findable links to all of the sections of the site.

Set up Travis CI

This will be a simple build of whatever the current site structure is, just to make sure that we are not breaking anything on build.

Can't navigate to sub-links of different pages

When I’m on one page (like Patterns) and click on the sublinks of another page (like Grids under Layout System), I don’t go anywhere. This only happens when you have clicked one of the top level headers ("Visual Style," "Layout System," "Patterns.") and then try to click on the sublink of another page.

Component [Tables]

v1 of components: unbranded basic styling focused on layout, sizing, padding + UX/interaction

Leaving this here for feedback:

tables_ui_v1

Folders for art assets

@maya @juliaelman for product testing next week, I'd like to share a few versions of art files of each component for our testing teams to take a peak at. Goal: give folks the ability to be able to get into editable design files of the components.

Does it make sense to add an img folder at the top level where we load in files for each component (organized like our Drive setup currently) or is there a way to do this? I don't have strong feelings at all as to how this happens -- what do you guys think makes the most sense?

[Inputs] Looking for feedback on spacing, styling, etc.

v1 of components: unbranded basic styling focused on layout, sizing, padding + UX/interaction

[Note: we are also designing form patterns, aka: address field, DOB, login, etc. which will be made up of the follow elements]

Leaving this here for feedback:
form_elements_ui_v1

Create ability to have a non-compressed CSS when working locally.

@maya brought up the concern of having compressed CSS locally and not easily being able to see the compiled output. There are a few options we can go with here:

  1. Add a check in config.yml if working locally and turn compression off.
  2. Create separate config files for local development vs. staging/production.

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.