LogoLogo
  • Technical Direction
  • Technical overview
    • Technical Implementation
    • API Design Guide
      • Data Definitions and Standards
      • Data Transfer Objects
      • Documentation
      • Environments
      • Error Handling
      • Example API Service
      • GraphQL Naming Conventions
      • Methods
      • Naming Conventions
      • Once Only Principle
      • Pagination
      • Resource Oriented Design
      • REST Request
      • REST Response
      • Security
      • Versioning
    • Ísland.is Public Web Data Flow
    • Code Reviews
    • Code Standards
    • Monorepo
    • Project Management
    • Teamwork
    • Architectural Decision Records
      • Use Markdown Architectural Decision Records
      • Use NX
      • Continuous Integration
      • CSS
      • Branching and Release Strategy
      • Error Tracking and Monitoring
      • What API Management Tool to Consider
      • Viskuausan Static Site Generator
      • Use OAuth 2.0 and OpenID Connect As Protocols for Authentication and Authorization
      • Unified Naming Strategy for Files and Directories
      • CMS
      • Open Source License
      • What Chart Library Should We Use Across Island.is?
      • What Feature Flag Service/application Should We Use at Island.is?
      • Logging, Monitoring and APM Platform
      • ADR Template
    • Log Management Policy
  • Products
    • Island.is Authentication Service
      • Terminology
      • Integration Options
      • Authentication Flows
      • Authorising API Endpoints
      • Session Lifecycle
      • Scopes and Tokens
      • Delegations
      • Configuration
      • Tools and Examples
      • Environments
      • Test IAS with Postman
      • Using the IAS admin portal
    • Notifications / Hnipp
      • New Notification Setup Guide
      • Notifications service workflow overview
      • Email notifications
    • Pósthólfið
      • Security Checklist
      • Introduction
      • Skjalatilkynning API
      • Skjalaveita API
      • Sequence Diagram
      • Interfaces
    • Straumurinn (X-Road)
      • Architecture Guidelines for Service Providers and Consumers
      • Setting up an X-Road Security Server
        • Network Configuration
      • X-Road - Uppfærsla á öryggisþjónum
      • Straumurinn - Notkun og umsýsla
      • X-Road Central - current version
  • Development
    • Getting Started
    • Generating a New Project
    • Definition of done
    • Devops
      • Continuous Delivery
      • Database
      • Dockerizing
      • Environment Setup
      • Logging
      • Metrics
      • NextJS Custom Server
      • Observability
      • Operations Base Principles
      • Security
      • Service Configuration
      • Support
    • AWS Secrets
    • Feature Flags
    • Documentation Contributions
    • Defining Monorepo Boundaries With Tags
    • OpenAPI
    • Code Generation
    • Workspace Settings (Deprecated)
    • External Contributions
  • REFERENCE
    • Problems
      • 400 Validation Failed
      • 400 Attempt Failed
      • 403 Bad Subject
      • 400 500 Template API Error
    • Glossary
  • Misc
    • Guide: Adding a Payment Step to an Application
    • Guide: Enable Organisations to Make Requests to an Application
    • README Template
Powered by GitBook
On this page
  • Context and Problem Statement
  • Decision Drivers
  • Considered Options
  • Decision Outcome
  • Pros and Cons of the Options
  • Gather content
  • Prismic
  • Contentful
  • Contentstack
  • Drupal, WordPress and other hosted solutions
  • Strapi
  • Whitehall
  • Links

Was this helpful?

  1. Technical overview
  2. Architectural Decision Records

CMS

  • Status: accepted

  • Deciders: devs, management

  • Date: 2020-05-25

Context and Problem Statement

island.is will be maintaining and publishing content from many different government agencies and institutions. Their technical skill may vary a great deal, the content skill may also be lacking, therefore it is paramount for the system to be user friendly and intuitive.

Agencies and institutions should have enough autonomy with regards to editing content they are responsible for, to minimise the manual labour required by the island.is editors.

Which CMS system would best suit the needs of island.is?

Decision Drivers

  • Content needs to be editable by non technical users

  • Content needs to be accessible across multiple domains and platforms

  • Setup should be simple for developers new to the project

  • The system should manage flexible content structures to limit systems impact on design

  • The system should be user friendly and easy to use for a non technical person

  • The system needs to offer a suitable workflow option to ease content management once multiple agencies start to contribute

Considered Options

Decision Outcome

Devs narrowed the choice down to two options Contentful and Contentstack.

Both systems meet the required featureset.

A decision from management was made to use Contentful. Contentful is deemed to have a larger presence in the Icelandic dev community. Contentful is also believed to have a stronger funding base. Contentful is already implemented in some of our projects.

Pros and Cons of the Options

  • Good, because it allows for a great deal of workflow and collaboration features

  • Good, because it can function as a project management tool for the content

  • Good, because it can serve as a communication portal between island.is and the various parties involved

  • Good, because it has comprehensive access control [7],[8]

  • Bad, because it has a very basic API

  • Bad, because it has a limited set of CMS features

  • Bad, because it is not designed to be a publishing platform

  • Good, because it is kind of a simpler version of Contentful

  • Good, because it is simple to use for non technical users

  • Good, because image editing & placement is simple but effective

  • Good, because it has a built-in CDN for images

  • Bad, because it doesn't have a write API

  • Bad, because the only way to import content is through the web interface

  • Bad, because it doesn't have 'required fields'

  • Bad, because API is somewhat limited

  • Good, because it has a best in class API and SDKs

  • Good, because it has a large ecosystem of users

  • Good, because it has a hybrid WYSIWYG editor, where you mix content types together with regular rich text content

  • Good, because it is generic enough to be used for many different things

  • Good, because it has a write-API, so you can create content programmatically

  • Good, because it can be extended with UI extensions and various 3rd party tools

  • Good, because it has rich access controls

  • Good, because it a lot of developers have experience with it

  • Good, because it has a built-in CDN for images and content

  • Good, because it can define workflows and apply user permissions across those

  • Bad, because it has a very generic structure and can be confusing for new users

  • Bad, because depending on how content is set up, you may often have to do deep drill-downs on content entries

  • Bad, because it has a complex billing structure making it harder to project costs

  • Good, because it is somewhat structured compared to some of the other choices

  • Good, because it has an SDK for many languages

  • Good, because it is generic enough to be used for many different things

  • Good, because it has a write-API, so you can create content programmatically

  • Good, because it can be extended with widgets and various 3rd party tools

  • Good, because it has a built-in CDN for images and content

  • Good, because it has rich access controls

  • Good, because it can define workflows and apply user permissions across those

  • Good, because it has a easy to understand billing structure

  • Bad, because fewer developers have experience with it

  • Bad, because it has a steep initial price

  • Good, because you have endless control over these types of systems

  • Good, because there's a huge ecosystem of pre-built stuff

  • Bad, because the huge ecosystem has a huge quality control problem

  • Bad, because you will need specialised knowledge of these systems to maintain them and get out of them what you want.

  • Bad, because you will have to host them yourself, take care of backups and maintenance and there are regular serious security breaches with these systems.

  • Bad, because even though they can be run in headless mode, their UIs and APIs are not really geared towards headless usage.

  • Good, because you have endless control over these types of systems

  • Good, because there's a huge ecosystem of pre-built stuff

  • Good, because it has a write-API, so you can create content programmatically

  • Bad, because you will need specialised knowledge of these systems to maintain them and get out of them what you want.

  • Bad, because you will have to host them yourself, take care of backups and maintenance and there are regular serious security breaches with these systems.

  • Bad, because the system is missing features deemed critical such as content internationalization and granular access control

  • Good, because it manages workflows

  • Bad, because it's built around Gov UK and we would have to fork the project to use it safely

  • Bad, a lot of upfront work would be required to adapt the system to our stack

  • Bad, because it does not fulfill the project's requirements

Links

PreviousUnified Naming Strategy for Files and DirectoriesNextOpen Source License

Last updated 2 years ago

Was this helpful?

, , , other hosted solutions

, and other hosted solutions

Gather content
Prismic
Contentful
Content stack
Whitehall
Drupal
WordPress
Strapi
Gather content
Prismic
Contentful
Contentstack
Drupal
WordPress
Strapi
Whitehall
gather content ACL tab 1
gather content ACL tab 2