data-govt-nz / rua

Pattern library for data.govt.nz

Rua Pattern Library

Table of Contents

1. Installation
2. Development
3. Usage

Installation

yarn install

@todo Register to npm.js so we can run

yarn install rua-pattern-library

Development

yarn run watch

or

gulp watch

Your default browser should open to localhost:3000 or increment to the next available port.

Note: on first run you may get an error cannot GET /. Try running yarn run build then watch again.

Build

yarn run build

or

gulp

Contributing

To update this repo, create a PR with just the src changes (not dist/ or docs/). Once the changes have been merged, create a commit "Dist and docs" on master and tag with latest version number.

Usage

@import '~rua-pattern-library/src/rua';

// Optionally set window.dataTargetNamespace to a custom value (e.g. 'rua-' would mean you'd use `data-rua-toggle="..."`)

import {
    toggler,
    matchHeight,
    clipboard,
    tooltip,
    backToTop
} from 'rua-pattern-library/src/9-plugins'

$(document).ready(function(){
    matchHeight()
    toggler()
    clipboard()
    tooltip()
    backToTop()
})

rua's Issues

Drop references to 'rua' in source code

Something to tidy up later, while the pattern library is called "rua" we shouldn't make references to that name in the src code itself as we are aiming for generic reusability into other pattern libs later on.

New layout suggestion: Header with admin section

CKAN needs a ribbon across the top of the header to hold some admin only menu items, the same could be applied to CWP header when a user is logged in (displays a link to the CMS etc).

TODO list

• Look into template options See https://github.com/kss-node/kss-node/wiki/Using-custom-templates
• - Determine sass/src structure of the repo
• - Work out how to add a generic layer of styles on top of bootstrap, then flavour for products

Code examples start in closed accordion

As a browser of the pattern library
I want code examples to be hidden and able to be opened by clicking
So that browsing the components is easier and I only see the code I need.

Colours and highlights

Add a burnt orange option to the available highlight colours.

Ensure the applying a highlight override to a section of the site doesn't lock us in to using named class styles. This avoids the need to find/replace classes should we decide to alter the highlight colour. Treat the highlights like "slots" which can hold any colour and should only need to update 1 hex value and rebuild the CSS.

Also suggest in the library to split the colour section into core/supporting and highlight colour sections so it's clear which colours should be used for higlights.

https://data-govt-nz.github.io/rua/section-core.html

checkbox and radio labels

Form label at present displays about the checkbox and radio items rather than to the right of it which is common practice and ok'd in the design.

box shadow transtion.

subtle/quick transition on the box-shadow that appears on the option, button, input and select hover on hover so it's not quite so jarring. Ideally this should be a global variable to share among all elements.

As mentioned in #18

Write some readme for the pattern library

This is just a note for me to make sure we provide some text at https://github.com/data-govt-nz/rua/blob/master/src/0-docs/homepage.md

Headings and breadcrumb: Size considerations with real world content

Not that the headings in the hero banner when we have longer real world text in place end up pushing off screen. Breadcrumb also get cut off.

@gorriecoe you might need to revisit the sizes of the heading elements or find some way to make them more relative to their context.

Example:

Card: A11y considerations

The card semantic markup is something we've spent time sorting on the current site to best meet accessibility and usability guidelines (and practicalities). Suggest reviewing the card like markup on the home page of the current theme.

Key things are:

• The image is clickable
• It includes categories if needed (we can use our existing tags component as a variation).
• The "alt" attributes should be included for images and these should describe whats on the next page rather that what the image is.
• To get this to play nice with screen readers you need to wrap both the img and heading tags in the a tag (it might make you cringe semantically but this is workable good practice for this scenario put forward by an a11y expert and previous w3c rep we work with 👍).