Can’t someone else do it?

How to assign responsibilities on project updates — Build just like Lego!

In collaboration with Sara Lerma

A totally normal developer’s brain

Do you feel you are overwriting (and recurrently deploying) your almost-same-code with every content update? Do you have a minute to talk about CMS’s?

A CMS (Content Management System) is just a place to store content. It works kind of like a database: you call for some information, you receive data to render on your page.

Your project

Imagine your business webpage: You display some “welcome” info, some static details… and your biggest business product: the offer of the week. Some (meta) code like this:

<>Welcome to our page!</>
   <>…blablabla…</>
   <>Offer of the week:</>
   <>Now sushi for 42$!! Get an amazing 60% less for 4 friends!!</>

Marketing team, as a business strategy, ask you to change the offer of the week unsurprisingly on a weekly basis, looking for incoming clients.

• In dev-terms, this change means going on complete dev-path: coding, testing, deploying… every week.
• In marketing terms, this (good) dev practice path requires some time to be launched each time.

Let’s think about a CMS to update this offer of the week:

{
  “item”: “sushi”,
  “price”: “42$”,
  “pax”: “4”,
  “discount”: “60%”
}

In your more-generic-and-reusable code you make a CMS call, and handle received data:

<>Offer of the week:</>
   <>Now #{item} for #{price}!! Get an amazing #{discount} less for #{pax} friends!!</>

But… Why only manage content?

Imagine now you’re redirecting your customers to specific content according to your partner’s business agreements. Next month, your partner could be a different company! You’ll need to frequently update those values.

CMS to the rescue!

{
  “recommendation1”: “Sushi house”,
  “recommendation2”: “Ramen house”,
  “partner1”: “www.our-new-partner-for-sushi.com”,
  “partner2”: “www.our-new-partner-for-ramen.com”
}

And…

<a href={partner1}>Our recommendation for #{recommendation1}<a/>
<a href={partner2}>Our recommendation for #{recommendation2}<a/>

Won’t somebody please think of the… bugs?

Every new piece of code has its own risk of bugs. Does it make sense to go through the complete development process when your final intention is to update content not related to the code?

A content update:

• Without CMS:

• With CMS:

…So: No new coding, testing nor deployment needed, neither are story points in the developer’s sprint.

By avoiding writing business logic and content data in our code layer we’re making it transparent to Marketing and Business Intelligence decisions.

For every information or logic update, the Marketing team can go to CMS, modify information, click on publish… and ta-da!!! It will be live! Change happens at that very moment!

The goal

At Coverwallet we’re trying to create more and more autonomous and customisable projects and components. Our idea is that the responsibility of updating content should rely on those who create it. Simply!

We want our code to be agnostic of Business decisions.

Why not a database?

But hey, you said “kind of like a database”, then, why not use a database?

Let us talk here about some of our projects.

We manage not only components, but complete pages with our CMS, so, for a certain product, marketing can index images, pricing plans, slider items… and all elements they need.

This is far easier working with a specific and friendly UI rather than making DB queries.

How do we do it?

In Coverwallet we use Contentful as CMS. On it, you can structure and organize the content of a page through a Content Model.

Then, you can relate a Content Model (let’s call it “parent page”) to some small content structures, which can be for example an item with a title, an image and a text.

These small content structures can be generic components and can be reused in different parent pages. So you can imagine the parent pages as a container for small structures:

Yeah, we love sushi.

You can build just like Lego! Just fit some customisable-parts on top of others according to your needs… so for us in Coverwallet, our Lego would be something like this:

- Main page (i.e. Resources page, Resources index)
   - Section page
      - Category page
        - Entry page
          - Text
            - Link
              - Rich content (i.e. embedding images, videos, etc)

In this way, the marketing team can change the content of a page easily:

• On one hand, updating the content of a parent page, adding or removing children components.
• On the other hand, modifying the content of the children components.

Consequences

Using a CMS allows you to produce, manage and publish content on a website in a more fluid and easier way.

Splitting responsibilities among containers (= surface to provide support to Lego bricks) vs. content (= Lego bricks) management allows flexibility within our development flows, not only avoiding accessing containers when only content will be updated (hence saving developers time & avoiding possible bugs), but also shortening the time taken to publish content.

Some useful links

• Advantages & Disadvantages of Using a CMS: https://webhostingmedia.net/advantages-disadvantages-using-cms/
• Usage of statistics of content management systems: https://w3techs.com/technologies/overview/content_management