Skip to content

Commit

Permalink
feat: docs update (#133)
Browse files Browse the repository at this point in the history
* add code of conduct

* update default port and install instructions

* link and copy updates

* update preview image

* update ds link in overview

* update versioning docs

* update process docs

* add cms integration docs

Co-authored-by: Nathan Rogan <nathanroagn@centro.org.uk>
  • Loading branch information
rolorogan and Nathan Rogan committed Apr 29, 2021
1 parent e7eaf0f commit 9c85db5
Show file tree
Hide file tree
Showing 23 changed files with 492 additions and 463 deletions.
8 changes: 4 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,9 +26,9 @@

## 1.2. Overview

Welcome to the [West Midlands Combined Authority Design System](https://wmcadigital.github.io/wmca-design-system).
Welcome to the [West Midlands Combined Authority Design System](https://wmcads.netlify.app/).

The WMCA Design System is ran at the designated url on startup (usually [http://localhost:3000](http://localhost:3000)) and is the primary means of viewing your work - it will live update as you make changes.
The WMCA Design System is ran at the designated url on startup (usually [http://localhost:8080](http://localhost:8080)) and is the primary means of viewing your work - it will live update as you make changes.

- Tailored for building West Midlands Combined Authority apps and websites: Using the WMCA Design System markup and CSS framework results in UIs that reflect the West Midlands Combined Authority look and feel.
- Continuously updated: As long as you're using the latest version of the WMCA Design System, your pages are always up to date with West Midlands Combined Authority UI changes.
Expand All @@ -41,9 +41,9 @@ The WMCA Design System is ran at the designated url on startup (usually [http://
You'll need [Git](https://help.github.com/articles/set-up-git/) and [Node.js](https://nodejs.org/en/) installed to get this project running.

1. Clone the project with `git clone https://github.com/wmcadigital/wmca-design-system.git`
2. Run `npm install` in the root folder.
2. Run `npm i` in the root folder.
3. Run `npm start` to launch the dev environment with hot reloading.
4. Visit [http://localhost:3000](http://localhost:3000)
4. Visit [http://localhost:8080](http://localhost:8080)

Having trouble getting these steps to work on your machine? Follow the [troubleshooting guide](doc/troubleshooting.md).

Expand Down
73 changes: 73 additions & 0 deletions doc/CODE_OF_CONDUCT.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
# Contributor Covenant Code of Conduct

## Our Pledge

In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, gender identity and expression, level of experience,
education, socio-economic status, nationality, personal appearance, race,
religion, or sexual identity and orientation.

## Our Standards

Examples of behavior that contributes to creating a positive environment
include:

* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

* The use of sexualized language or imagery and unwelcome sexual attention or
advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting

## Our Responsibilities

Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.

Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.

## Scope

This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.

## Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at {{ email }}. All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.

Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.

## Attribution

This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html

[homepage]: https://www.contributor-covenant.org
16 changes: 8 additions & 8 deletions doc/contributing.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ These docs are to help you understand our contribution guidelines and standards.
- [CSS](#css)
- [JavaScript](#javascript)
- [Components and Nunjucks API](#components-and-nunjucks-api)
- [Testing and linting](#testing-and-linting)
- [Linting](#testing-and-linting)
- [Supported browsers](#supported-browsers)
- [Commit hygiene](#commit-hygiene)
- [Updating Changelog](#updating-changelog)
Expand Down Expand Up @@ -47,23 +47,23 @@ See [running locally](/doc/contributing/running-locally.md).

### CSS

See our [coding standards for CSS](/doc/contributing/coding-standards/css.md) and [testing and linting](/doc/contributing/testing-and-linting.md).
See our [coding standards for CSS](/doc/contributing/css.md) and [Linting](/doc/contributing/testing-and-linting.md).

### JavaScript

See our [coding standards for JavaScript](/doc/contributing/coding-standards/js.md) and [testing and linting](/doc/contributing/testing-and-linting.md).
See our [coding standards for JavaScript](/doc/contributing/js.md) and [Linting](/doc/contributing/testing-and-linting.md).

### Components and Nunjucks API

See our [coding standards for components](/doc/contributing/coding-standards/components.md), [coding standards for Nunjucks macros](/doc/contributing/coding-standards/nunjucks-api.md) and [testing and linting](/doc/contributing/testing-and-linting.md).
See our [coding standards for components](/doc/contributing/coding-standards.md), [coding standards for Nunjucks macros](/doc/contributing/coding-standards.md) and [Linting](/doc/contributing/testing-and-linting.md).

## Testing and linting
## linting

See [testing and linting](/doc/contributing/testing-and-linting.md).
See [Linting](/doc/contributing/testing-and-linting.md).

## Supported browsers

Your contribution needs to work with certain browsers as set out in [README](README.md#browser-support). See also [supporting Internet Explorer 8](/doc/installation/supporting-internet-explorer-8.md).
Your contribution needs to work with certain browsers as set out in [README](README.md#browser-support).

## Supported assistive technology

Expand Down Expand Up @@ -92,4 +92,4 @@ See [deploying](/doc/contributing/deploying.md).

## Releasing a new version

See [publishing](/doc/contributing/publishing.md).
See [versioning](/doc/contributing/versioning.md).
12 changes: 6 additions & 6 deletions doc/contributing/application-architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@

Source files. See [README.md](../../src/README.md) in the src directory for details.

- `wmre/`
- `wmcads/`

This is where the core library of all components/patterns are built using nunjucks for the WMCA Design System. These are then referenced by the Design System Website to show examples to other collaborators.

Expand All @@ -18,19 +18,19 @@

- `sass/`

Any core SASS/SCSS that is used for styling components/patterns etc. should be placed in here and then referenced in `src/wmre/assets/sass/wmre.scss`. Note: Anything referenced will appear in the live build.
Any core SASS/SCSS that is used for styling components/patterns etc. should be placed in here and then referenced in `src/wmre/assets/sass/wmcads.scss`. Note: Anything referenced will appear in the live build.

- `components/`

Examples of components usage in various contexts. See [README.md](../../src/components/README.md) in the components directory for more details. You can access these examples from [WMCA Design System components](http://localhost:3000/components/).
Examples of components usage in various contexts. See [README.md](../../src/wmcads/components/README.md) in the components directory for more details. You can access these examples from [WMCA Design System components](https://wmcads.netlify.app/components/).

- `patterns/`

Examples of pattern usage in various contexts. See [README.md](../../src/components/README.md) in the components directory for more details. You can access these examples from [WMCA Design System patterns](http://localhost:3000/patterns/).
Examples of pattern usage in various contexts. See [README.md](../../src/wmcads/patterns/README.md) in the components directory for more details. You can access these examples from [WMCA Design System patterns](https://wmcads.netlify.app/patterns/).

- `www/`

Anything that is specific for the [WMCA Design System website](http://localhost:3000) goes in this folder. It also contains generic layout templates used to render preview and content pages.
Anything that is specific for the [WMCA Design System website](https://wmcads.netlify.app) goes in this folder. It also contains generic layout templates used to render preview, content pages and template mockups.

- `assets/`

Expand All @@ -44,7 +44,7 @@

Any javascript files located in here will be concatenated and compiled into `docs/js/wmcads-vendor.min.js` via the [javascript build task](tasks.md#markdown-header-141-scripts-javascript).

- `docs/` **contains auto-generated files**
- `build/` **contains auto-generated files**

Standalone builds of WMCA Design System. Provides a way to consume WMCA Design System without using npm.

Expand Down
5 changes: 5 additions & 0 deletions doc/contributing/cms/cms-integration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
# CMS Integration

Every new template should be created on a new branch based on `release` following the guidelines in [Versioning](../versioning.md#123-new-branches).

Where feasible any new components should be added as a partial view and imported into the template.
7 changes: 3 additions & 4 deletions doc/contributing/coding-standards.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Components

Find components in `src/wmre/components`.
Find components in `src/wmcads/components`.

Components must use the `.wmcads-` namespace.

Expand All @@ -24,10 +24,9 @@ Component folder and files should be singular, except in cases where they are mo
The folder structure should be:

component-name
- `component-name.njk`
- `_component-name.scss`
- `component-name.html`
- `component-name.js`
- `README.md`
- `component-name.js` (optional)

## Nunjucks template API

Expand Down
18 changes: 5 additions & 13 deletions doc/contributing/css.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

## Class naming convention

## `wmre` namespacing
## `wmca` namespacing

All class names start with a `.wmcads-` namespace to reduce the likelihood of
conflicting with existing classes in your application. It also helps to identify
Expand Down Expand Up @@ -112,12 +112,12 @@ This makes it easier to keep track of different contexts.
# Linting

To ensure code quality and consistency in our Sass files we check that certain
style rules are followed using a project [YAML file](../../../config/.sass-lint.yml)
style rules are followed using a project [YAML file](../../../master/.sass-lint.yml)

As we're using node-sass parser to parse our scss files, the package of choice
is [sass-lint](https://github.com/sasstools/sass-lint).

See [testing and linting](../testing-and-linting.md) for more information.
See [linting](../contributing/testing-and-linting.md) for more information.

## Running the lint task

Expand All @@ -126,7 +126,7 @@ or check linting directly in [Sublime Text](https://github.com/skovhus/SublimeLi
[Atom](https://atom.io/packages/linter-sass-lint)
or other [IDE's](https://github.com/sasstools/sass-lint#ide-integration)

See also [testing and linting](../testing-and-linting.md).
See also [Linting](../testing-and-linting.md).

## Linting rules

Expand Down Expand Up @@ -492,12 +492,4 @@ Good:

### Remove trailing whitespace

More write up on [supported rules](https://github.com/sasstools/sass-lint/tree/master/doc/rules).

## SassDoC

We document SCSS using [SassDoc](http://sassdoc.com/file-level-annotations/). This includes most of the settings, helpers and tools layers, with variables, functions and mixins being marked as private or public.

The syntax is used to generate a [SassDoc application](http://wmcads-frontend-review.herokuapp.com/doc/) that documents SCSS in a readable format.

See [colour.scss](../../../src/wmre/helpers/_colour.scss) for an example of SassDoc syntax.
More write up on [supported rules](https://github.com/sasstools/sass-lint/tree/master/docs/rules).
5 changes: 5 additions & 0 deletions doc/contributing/ds/creating-pages.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
# Creating pages

When the Design System is built it automatically generates files from `src/www` to the `build` folder. These are the files used to generate the [Design System front-end](https://wmcads.netlify.app/).

These pages are created from the files within `src/www/pages`. This is where you can import [components](../../../src/wmcads/components/README.md) or [patterns](../../../src/wmcads/patterns/README.md) found in `src/wmcads`.
29 changes: 29 additions & 0 deletions doc/contributing/ds/nunjucks-params.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
# Nunjucks parameters

Change the behavior of components by sending custom parameters.

This enables us to re-use components without having to duplicate them just to change copy or UI features.

## Change copy

As an example lets change the title of a component:

1 - In the compoent `.njk` file add a custom parameter like this:

{% set title = params.title or 'Default Title' %}

This is looking for a parameter called `title`, if the parameter is not found the default value is used after `or`.

2 - Display the value in the front end.

Add the parameter name within `{{ }}` where you want the value to appear:

<h1>{{title}}</h1>

3 - Send the title value to the component

{{
wmcadsComponentName({
title: "New title"
})
}}
10 changes: 5 additions & 5 deletions doc/contributing/git.md
Original file line number Diff line number Diff line change
Expand Up @@ -103,11 +103,11 @@ will make sense to your fellow developers. In particular, you may find
commits and use git rebase master instead. However, you should not rewrite commits
that have been pushed unless you:

- are **very sure** that no-one else will be affected by you rewriting the
branch history
- have an Extremely Good Reason. For example: someone has committed
sensitive information (personally identifiable data, passwords and suchlike)
and it needs purging from history
- are **very sure** that no-one else will be affected by you rewriting the
branch history
- have an Extremely Good Reason. For example: someone has committed
sensitive information (personally identifiable data, passwords and suchlike)
and it needs purging from history

When in doubt you should err towards smaller commits, which can be rebased
together later. It's harder to break large commits out into smaller chunks.
Expand Down
55 changes: 55 additions & 0 deletions doc/contributing/internal-process.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
# Internal process for developing the new WMCA website

These docs outline the process all designers and developers should be following when updating the WMCA Design System and for testing templates for the new WMCA website.

## Development

Make sure you are familiar with how the design system is setup and how to contribute to it by reviewing the [Contributing guide](../contributing.md).

Main points to follow:

- Each new feature or bugfix should be created on a new branch based on `release` following the guidelines in [Versioning](versioning.md#123-new-branches).
- This makes it easier for multiple developers to work on the same feature or bugfix without disturbing the main codebase.
- This also makes it easier to carry out staggered releases to the main codebase.
- All new components or patterns need to follow the [Coding standards](coding-standards.md).
- Any new CMS templates should be added to the design system to ensure:
- That the latest components and patterns are in use
- To show the template to designers for sign off
- Any custom styles and javascript are checked and generated in the build process
- Once you are ready to propose new changes, you must **open a pull request to the** `release` **branch**.
- This will trigger the Github actions which will:
- Check the pull request title to ensure the semantic-release works correctly
- Checks the codebase for any linting or accessibility issues
- A preview will be created in Netlify
- The pull request will then be reviewed by the head developer and any issues identified.
- Once the lead developer is happy with the pull request an ICT change request will be created and merged into the `master` branch.

### Points for template creation

- All templates should be added into `src/www/pages/templates`. These will appear on the main Design System site [here](https://wmcads.netlify.app/templates/).
- Ensure you use the appropriate style [utilities classes](https://wmcads.netlify.app/styles/utility-classes/) for the template layout.
- Check that the page passes accessibility checks using automated tools such as [AXE](https://www.deque.com/axe/), [Wave](https://wave.webaim.org/) or [Lighthouse](https://developers.google.com/web/tools/lighthouse) (or a combination of the tools).
- Once the pull request passes all checks and the lead developer confirms it's ok the template preview will be sent to the designers for final sign off.

## Design / UX / UI

- When a template has been signed off by the lead developer a Netlify preview link will be sent to the designers
- Designers should review the template on desktop, tablet and mobile to ensure the design works as expected.
- Any issues to be added to the GitHub repository [issues](https://github.com/wmcadigital/wmca-design-system/issues) page. Where possible add the sprint card reference found in the [West Midlands Combined Authority - Backlog](https://github.com/orgs/wmcadigital/projects/18). E.g. `DS2.1 - Font issue with body copy`.

### Template Sign Off

Only when the template has been signed off by the lead developer and design can it be integrated into the Content Management System.

#### Sign off checklist

- Templates use the design System utility classes, components & patterns
- If the template requires extra styles or scripts these should be added into the `src/www/pages/templates/template-name` folder so they can go through [Linting](../contributing/testing-and-linting.md) and the build process.
- If the code is concidered useful for other pages it should be added to the base Design System.
- Templates pass accessibility checks
- Approved by lead developer
- Approved by Design

## CMS Integration

When the template has been signed off it can be integrated into our [CMS](../contributing/cms/cms-integration.md).
2 changes: 1 addition & 1 deletion doc/contributing/js.md
Original file line number Diff line number Diff line change
Expand Up @@ -122,4 +122,4 @@ The standard docs have a [complete list of rules and some reasoning behind them]

Read more about [running standard manually or in your editor](https://github.com/alphagov/styleguides/blob/master/js.md#linting).

See also [testing and linting](../testing-and-linting.md).
See also [Linting](../testing-and-linting.md).
Loading

0 comments on commit 9c85db5

Please sign in to comment.