Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Style Guide #2

Open
freemvmt opened this issue Jan 8, 2020 · 0 comments
Open

Style Guide #2

freemvmt opened this issue Jan 8, 2020 · 0 comments
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@freemvmt
Copy link
Collaborator

freemvmt commented Jan 8, 2020

Humble Style Guide

Heuristics

There are some key aesthetic principles that our approach to design will abide by:

Simplicity - Inkeeping with our 'humble' brand, we prefer to keep interfaces clean and ascetic
Transparency - As per our mission, we are keen to be recognised as community-oriented (rather than profit-oriented), and will demonstrate this to users by making the app's functionality transparent
Consistency - It is important that users consider us to have integrity, and part of fostering that is coming across consistently, in terms of design and language, throughout the user interface
Inclusivity - Everyone should be equally able to use humble

In practice, these translate as the following rules:

  • write headings in lowercase (see typography)
  • use familiar, minimalist iconography
  • when writing copy, use plain language and be as explicit as possible
  • be verbose where necessary and avoid superficial sloganeering
  • when referring to a feature, use the same language across the board
  • reveal processes to the user where possible
  • keep accessibility in mind at all times
  • avoid making assumptions about users' experience of, and familiarity with, other apps
  • do not assume the latest technology or best browser
  • any part of the app already seen can be revisited (for example, the onboarding process)
  • design for mobile first, but other versions should look and operate similarly

Colours

To be flush with the above heuristics, we opted for a natural, down to earth colour scheme.

Usage Name of colour Hex code Contrast w/ background Contrast w/ primary
Background off white #f7fff7 n/a 9.68 (AAA)
Primary colour (text) otter brown #583e23 9.68 (AAA) n/a
Secondary colour sand yellow #ecd444 1.46 (fail) 6.61 (AA)
Detail and accenting leaf green #bed558 1.6 (fail) 6.04 (AA)

NB. Brackets after contrast ratios denote WCAG rating for given contrast.

This means we can be confident that text in primary colour can be laid against our background, our secondary colour, or even our detail colour, and always be legible. Appropriately though, it's contrast is highest (i.e. it is most visible, achieveing a AAA WCAG rating) against the background.

f7fff7-ecd444-583e23-343434-bed558 coolors

Typography

Tag Typeface Styling
h1 (landing logo) Comfortaa Medium 56px, lowercase
h1 (normal logo) Comfortaa Regular 42px, lowercase
h2 Dosis Semi-Bold 24px, lowercase, 2% spacing
h3 Dosis Medium 22px, lowercase, 2% spacing
h4 Dosis Regular 20px, lowercase
p Dosis Regular 18px, normal capitalisation
p (emph) Dosis Light 18px, italic, normal capitalisation
a Dosis Medium 18px, underlined, normal capitalisation

See these on Google Fonts.

We've done a similar thing with fonts as for spacing, defining a --font-unit variable from which all the font sizes are given.

Spacing

We are using a CSS variable system in Fibonnaci to define spacing throughout the app.

This includes sizes xxxxs, xxxs, xxs, xs, sm, md, lg, xl, xxl, xxxl, xxxxl, ranging from 0.125em through to 13.75em, all calculated from a base unit, called --space-unit, initialised as 1em.

Crucially, where media queries might be used to make different devices responsive, we can just adjust the base unit and this will cascade through all the sizes. For example, if we want to increase spacing across components when using a tablet, we could write:

@media (min-width: 800px) {
  --space-unit: 1.25em;
}

For easy styling during development, we've also included the following self-explanatory variables which can be used across the site to ensure consistency:

  • --component-padding
  • --border-width

Styled Components

Yes that's right folks, we are using styled-components to level up our CSS. This should enable us to produce a library of basic components with consistent styling that any member of the team can drop directly into a component proper.

We will keep these in a styled folder within our components directory, and import them in as needed.

For further reading, see the Basics section of the styled-components docs and read up on the stylis CSS preprocessor, which is built into styled-components so can be leveraged wherever it's used (although standard CSS will work just fine too).

Inspiration

@freemvmt freemvmt added the documentation Improvements or additions to documentation label Jan 8, 2020
@freemvmt freemvmt self-assigned this Jan 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

1 participant