Origami Frontend Components & Services

Readme: ft-origami


This is the source code for the Origami website. Please visit http://origami.ft.com/ if you're looking for the documentation.

Running locally

Jekyll is used to build this site, and we host it on GitHub pages. Before we can run the site locally, you'll need:

  1. Node.js
  2. Ruby

Now install all the dependencies required to build the site:

make install

After this, you can start running the site using:

make serve

The locally running website will be viewable here: http://localhost:4000/.


This website is tested with Pa11y CI using CircleCI. If there are accessibility errors on the website, the build will fail.

If you'd like to run these tests locally, you'll need:

You should now be able to run the following to test the site:

make test

Documentation style guide

This guide is based on Jacob Kaplan-Moss' documentation series [1] [2] [3]. It exists as guidance to help keep our documentation consistent.

Types of documentation

There are three types of documentation:

  1. Step by step tutorials: These are the on-ramp for our project. Users should be able to follow one of our step-by-steps and achieve success within 30 minutes. These live in this repo (ft-origami).
  2. Topic guides: We don't have these yet. They should cover topics in comprehensive detail. They include information that would be too dense for a step-by-step.
  3. Reference: The Origami Spec is the container for general conventions for Origami components. Each component has it's own reference documentation too, found in its readme, JSdoc and Sassdoc.


We assume good grammar and proper spelling is already a given so it's not in this list. The Origami Spec is a normative specification and follows the conventions of normative specifications. For our other documentation (tutorials, topic guides and readmes) we use a much less formal tone. They should be informative, but breezy and conversational.

  1. Be conversational
    • Use contractions: "we're" over "we are"
    • Starting sentences with conjunctions like 'but' or 'so' is allowed
  2. Prefer "we" to "I"
    • good: "we recommend you do X"
    • bad: "I recommend you do X"
  3. Use the active voice. If you need help with this one, use http://www.hemingwayapp.com/
    • good: "we recommend you do X"
    • bad: "it is recommended you do X"
  4. Omit fluff. Avoid qualifiers like "pretty", "mostly", "probably"
  5. Prefer short sentences to long sentences
  6. Use British English
    • good: organise, favour
    • bad: organize, favor
  7. Avoid metaphors or turns of phrase that non-native English speakers may not be familiar with
    • good: "this site has everything you need to know"
    • bad: "this site is a one stop shop for Origami"
  8. Avoid "simply" and other words that trivialise concepts and ideas that might not be trivial
  9. Structure documentation for skim readers
    • Code variables go in back-ticks
    • Use tables
    • Use asides for extra tidbits
    • Use strong and emphasis where appropriate
    • Use lists
    • Break things up with informative headings
  10. Always capitalise Origami when referring to the product
  11. Never capitalise modules
    • good: o-techdocs, o-component
    • bad: O-techdocs, O-Techdocs
  12. Always capitalise Origami services
    • good: the Polyfill Service, the Build Service
    • bad: the polyfill service, the build service
Switch component view

GitHub Repository