The Origami team maintains this site and specification, components and component tools. It is currently led by Andrew Betts.
Everything Origami does is in line with our vision which is twofold: create a unified style for FT websites, and make building websites faster.
Users find it easier to use our websites if they share a consistent brand identity. This doesn’t mean they all have to stick rigidly to a template or even that there is even on single element that they all have to share. It’s more about establishing a strong consistency of design ethos across sites, so that it’s easier to make things match, and when there’s no good reason for things to differ, they do match.
More consistent presentation of our brand also helps to support the values and principles that the brand stands for, such as quality and accuracy.
It’s often tempting when building websites to start from a blank canvas, but doing that often leads to solving problems that have already been solved. And if you have more problems to solve you can’t spend as much time on each one. We should be working with reusable, always-improving solutions that can be shared by everyone, whether that be tools, conventions, components or anything else.
In pursuit of the vision above, we aim to ensure that:
In Origami specification documents, the words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY have the meaning given to them in RFC 2119.
On issues affecting the Origami spec, the team will also consult the Origami advisory group, and take their views into account when making spec changes.
If a spec change is proposed by the spec editor, they will normally create a pull request. If no objections are received (via pull request comments) within three business days, the change will be merged. Once an important change is merged, the advisory group will be notified again so that they can keep their programmes up to date with the latest state of the standard, and promote its adoption and use. All non-trivial changes will be recorded in a chagelog that is part of the specification.
Changes to the spec may also be proposed by anyone via a pull request. These will be reviewed by the spec editor and if approved, submitted to the advisory group.
The spec editor may choose to skip advisory group approval at their discretion, but should do so only for things that are highly likely to be uncontested.
The Origami advisory group comprises senior front end developers from across FT technology. Advisory group members are responsible for: