12 April 2024

Spina CMS Design Principles

These are the design principles of Spina CMS, a flexible CMS built with Ruby on Rails. The team behind Spina has strong opinions about what a good CMS should be like and has applied them to their product. This set of design principles represents the ideas that the team behind Spina CMS has boiled down.

Source: Spina Design Principles


The principles

  1. Keep it simple

    This one should be obvious, but it's worth repeating. Keep in mind who the end user is and build accordingly. Cut away the cruft. Not everything has to be editable.

  2. Dare to be different

    Web design is often criticized for being too boring and similar. Traditional CMSs make it difficult to create complex editable layouts, discouraging exciting design. Spina provides flexible content fields for everything you need – nothing more – and then goes out of your way.

  3. No HTML

    HTML belongs in source code, not in a CMS. The end user shouldn't need to know what HTML is to edit their website.

  4. No WYSIWYG

    What you see is what you get is a promise that fails to deliver. Instead, Spina includes easy to use page editing forms with clear labeling. It uses Trix for rich text fields. Page forms in Spina have zero optional fields so users don't have to guess.

  5. Configuration happens in code

    Everything a developer has to configure should be done in Ruby, not in Spina. Configuration rarely changes, storing it in version control is better than storing it in a database.

  6. Be fast, without caching

    Slow websites kill the user experience. Spina uses Postgres' JSONB-type to store all content as JSON. This makes pages screaming fast without having to worry about cache expiration. It's better to embed content directly on a page than to reference a different table.

  7. Fewer dependencies is better

    More dependencies equals harder maintenance. Spina tries to stick with the vanilla Rails stack as much as possible. That way there's little risk of getting trapped in dependency hell when upgrading down the line.

1. Keep it simple

This one should be obvious, but it's worth repeating. Keep in mind who the end user is and build accordingly. Cut away the cruft. Not everything has to be editable.

2. Dare to be different

Web design is often criticized for being too boring and similar. Traditional CMSs make it difficult to create complex editable layouts, discouraging exciting design. Spina provides flexible content fields for everything you need – nothing more – and then goes out of your way.

3. No HTML

HTML belongs in source code, not in a CMS. The end user shouldn't need to know what HTML is to edit their website.

4. No WYSIWYG

What you see is what you get is a promise that fails to deliver. Instead, Spina includes easy to use page editing forms with clear labeling. It uses Trix for rich text fields. Page forms in Spina have zero optional fields so users don't have to guess.

5. Configuration happens in code

Everything a developer has to configure should be done in Ruby, not in Spina. Configuration rarely changes, storing it in version control is better than storing it in a database.

6. Be fast, without caching

Slow websites kill the user experience. Spina uses Postgres' JSONB-type to store all content as JSON. This makes pages screaming fast without having to worry about cache expiration. It's better to embed content directly on a page than to reference a different table.

7. Fewer dependencies is better

More dependencies equals harder maintenance. Spina tries to stick with the vanilla Rails stack as much as possible. That way there's little risk of getting trapped in dependency hell when upgrading down the line.

Tags

  • Product

Related collections

Facebook's Four B2B Design Principles

4 principles


Margaret Stewart