Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • D design
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 20
    • Issues 20
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • pubsweet
  • design
  • Wiki
  • design principles for the xpub starter kit

Last edited by Nick Duffield Mar 09, 2018
Page history

design principles for the xpub starter kit

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 2 level AA
  • 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)
Clone repository
  • Design links from Europe PMC plus
  • Design links from eLife
  • Design meetings
  • Theme variables
  • coko theme
  • design principles for the xpub starter kit
  • Home