|
|
As part of our effort to build a system of reusable components, we have defined certain design principles to aid collaboration and guide our work. The goal is to encourage contributions from other stakeholders in order to produce a series of assets that individual journals may then incorporate into their own workflows.
|
|
|
|
|
|
## Our principles
|
|
|
|
|
|
### Crafting components for reusability
|
|
|
* When creating new components consider how they might fit back into the xPub ecosystem.
|
|
|
* Avoid hardcoding arbitrary spacing/padding values
|
|
|
* Consider how your new component would fit within the specified grid requirements
|
|
|
* Consider how vertical rhythm is set. The starter kit uses multiples and divisions of specified grid units
|
|
|
* Before creating new components ask the following questions
|
|
|
* Does a component for this purpose already exist?
|
|
|
* Is there something similar that could be adjusted to fulfil my requirement?
|
|
|
* How much refactoring would my component need to be used by others?
|
|
|
* Test components to ensure they meet requirements for the xPub Starter Kit before adding them into the guide
|
|
|
* When building components use dynamic units for size and spacing instead of pixels, picas, points
|
|
|
|
|
|
### Mobile friendly
|
|
|
* Make components and layouts fluid to respond to a number of viewport sizes
|
|
|
* Only use breakpoints when needed. Too many breakpoints can be hard to manage on a system level and can quickly grow out of control
|
|
|
* Size matters. Ensure that User Interface interaction areas are optimised for touch
|
|
|
* Only scale text to suit varying screen sizes when needed (this tends affect h1’s mainly). The basefont size for the xPub starter kit has been carefully selected to perform well across varying viewport sizes without the need for adjustment
|
|
|
|
|
|
### Conform to standards
|
|
|
* Components must use correct, semantic HTML 5 markup
|
|
|
* Components must conform to [WCAG](https://www.w3.org/TR/WCAG20/) 2 level AA
|
|
|
* [Aria](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA) should be used appropriately and carefully to ensure meaningful user feedback
|
|
|
|
|
|
### Clear documentation
|
|
|
* Components should be documented in the following way
|
|
|
* Clearly, with no jargon so that they are easily understood
|
|
|
* By use. What is the intent of the component and how should it be used
|
|
|
* Referenced to the contributing organisation for instances when further clarification is required
|
|
|
* Each component should be placed in a relevant Atomic section of the style guide (Atoms, Molecules, Organisms)
|
|
|
|
|
|
### Visual language
|
|
|
* The xPub starter kit has intentionally been designed with a neutral visual style. The intention is that kit is used in two ways
|
|
|
* As-is, so that basic design needs are covered without need for extensive customisation
|
|
|
* As a starting point for organisations and their design teams to project their visual style onto
|
|
|
* Text hierarchy should be set using a 1.125 modular scale
|
|
|
* Font families should be assigned in the following way
|
|
|
* Noto sans - User interface elements and headings
|
|
|
* Noto serif - Reading text, like paragraphs
|
|
|
* Ubuntu - Writing text input by the user
|
|
|
|
|
|
### User experience
|
|
|
* UI feedback should have a clear relationship with the component that it is associated with
|
|
|
* Apply colour in a consistent meaningful way to indicate
|
|
|
* Validation (Error or success)
|
|
|
* Interactive (Primary or link colour)
|
|
|
* Interaction (Hover or focus)
|
|
|
* Do not misuse element attributes (e.g. use input placeholder instead of a label) |