CMS Types
Let's explore each type of CMS listed here to help determine the best type for your use case.
CMS
All platforms listed here can be considered CMSs, but those categorized as "CMS" specifically refer to traditional systems where you build models/content types/collections and add fields to them. These platforms use databases to store content and provide a user interface (UI) for editing each record.
Tabular
Tabular provides a spreadsheet-like interface (also known as a visual database) to manage data.
How do I know if I should use tabular data?
- If you don't need images within rich text. Adding images within rich text isn't usually possible in this type of platform (it's not due to a technical limitation, they usually just don't offer it 🤷♂️). Therefore, blogs are usually not a good fit for this category.
- Not managing a lot of large blocks of text. Sometimes, the UX that comes with managing lots of text isn't great, although some platforms offer the ability to expand the cell into a big window.
- Seeing all your data in one grid. Visual databases typically provide a UI for filtering, grouping, and sorting data based on simple to complex conditions. When managing a lot of data, this can be very helpful, if not a requirement.
- Automations. They typically offer built-in methods or integrate with one of the many automation tools like n8n, Zapier, or ActivePieces.
- Adding data vis forms. Allowing visitors/clients the ability to add new data via a form can significantly improve workflows. This very page lets you submit new CMSs or update existing ones!
- Need formulas to create output. Visual databases provide a straightforward way of combining multiple fields and performing other manipulations to create a new field.
Example use cases:
- Programmatic SEO – When you want to output many pages that have similar data, often with formulas to output the variations in each field such as "Visit our {field_location} office".
- Team members – Listing each team member and providing a dedicated page for them is well aligned with the capabilities of visual databases.
- Portfolio – Portfolios often consist of highly structured pages that feature images and small blocks of text.
Blogging engine
Blogging engines typically provide an out-of-the-box solution for managing blogs and usually don't allow you to customize the fields, as the assumption is they provide everything you need.
Blogging engines usually have these qualities:
- Ability to manage blog posts, authors, and categories/tags
- Rich text editors with a lot of formatting and embed options
- Can't add new fields (though the default ones are usually enough)
- Straightforward and simple UI as it's all entirely geared towards blogging
Static (Git/files)
Static CMSs either use a static site generator to output files for each blog post (instead of serving them from a database), or you directly create static files, typically in Markdown.
They are typically used in tandem with frontend frameworks like React or Gatsby, as most platforms in this type don't provide an API; rather, the files are generated and served with the app itself.
Why use a static CMS?
- Version control – Tracking the history of every edit you make on your blog is useful, especially for teams. While many content management systems create this functionality (and typically charge a lot for it), there's already a solution on the market: Git. Git is a version control system that is commonly used for code, letting engineers track every change they make, especially useful for reviewing changes and reverting any problematic code. However, Git is useful for tracking changes in any file, including blog posts. Beyond tracking changes, Git is advantageous because there are many storage solutions that have free tiers for storing files, like your blog posts, such as GitHub. GitHub is where Webstudio stores its code powering the open source website builder.
- Markdown – Because your blog posts are stored in files, instead of a database, the language your blog posts are written in is almost always going to be Markdown. Markdown is a simple syntax for formatting rich text, unlike HTML, which takes many more keystrokes to write and is harder to read (for humans). It's also highly portable to other systems if you decide to move your blog.
- Hosting options – Static sites are easier to host, typically cheaper, and don't rely on a CMS API that may charge you based on bandwidth/requests.
Rich text considerations
Content that requires rich text field(s), like blogs, requires a CMS with a robust rich text editor.
Let's explore what to look for.
Components and formatting
Components can range from simple, like headers and images, to more complex, like callouts and CTAs.
By incorporating complex components, content quality improves, leading to enhanced user experience, higher retention, increased conversions, and better search engine optimization.
Each platform varies in what they offer out of the box (default) and if they let you create custom components.
Default
By definition, all rich text editors provide some level of formatting, such as bold, but not all provide the ability to add images or callouts.
Nearly every platform with rich text provides at least:
- Headings 1 - 3
- Bold
- Italic
- Lists (ordered and unordered)
Most platforms will also provide these:
- Images
- Heading 1 - 6
Few platforms provide these:
- Callouts
- CTAs
- Social embeds (YouTube, Vimeo, X, etc.)
Custom
Advanced platforms enable you to create custom components such as callouts, CTAs, products, etc.
Creating a new component adds an option to the toolbar/add menu, and selecting it pulls up the custom fields you created. For example, a callout can have type, icon, and message fields.
Then, it's up to you to format the HTML structure of the component and design it on the frontend.
For styling classes in Content Embed in Webstudio, refer to this issue.
