With the release of Contensis 9 just around the corner, we've been looking at ways to improve the way we communicate what’s new in Contensis.

It's fair to say that the old method of trawling through a long list of developer change logs isn't the best way to find out if a bug has been fixed, or if a new feature has been included in a release.

When we released R8.3, we created a full set of release notes to outline the changes that had been made. These are far cleaner and easier to read than looking through the change logs, but it is time consuming to produce this kind of documentation at the end of a release.

As a team we wanted to take things a step further. We wanted to get a better understanding of what changes had been made across releases, and have a single place for you to come to find out what’s new with Contensis.

Some of the criteria we considered:

  1. It should be simpler to update and make it possible to document changes as we progress with the development of a release.
  2. It should allow users to filter between the different types of improvement.
  3. It could highlight changes outside of Contensis that relate to the product, e.g. its documentation.
  4. It should be future proofed to allow updates to be displayed outside of a webpage.

I’ll continue this post with an overview of what we've done to take some of that criteria to build a What’s New feed. I'll demonstrate the simplicity of using content types and entries along with a few lines of code in razor using the Delivery API.

For simplicity, we’ll look at some basic fields and their respective content displayed.

Create a What’s New content type

We’ll start out by creating a new content type that will define the different types of update that we want to display. These are outlined in the table.

NameTypeDescriptionValidation
Title Text The title to describe the change Required
Summary Markup A summary of the change providing more detail.  
Type List A list of predefined categories that represent the type of change e.g. New Feature, Bug, Improvement, Documentation Required

blog-content-type

Create some new content

With the content type created and published we can now create a set of entries that we want to be displayed.

  1. Go to the entries listing screen.
  2. Select New Entry and use the What’s New content type.
  3. Populate the fields and press Publish.

I’ve created a few examples for the purposes of this post.

blog-entries

Create a razor view

Now that you have a content type and some entries, we’ll need to use the Delivery API to request a list of entries and display them in a page.

I’m using a simple razor view that:

  • says that we want to use the Delivery API
  • sets up a client connection
  • uses the entries list method to generate a list of entries from the What’s New content type
  • outputs the content of each entry in to an article tag

Using the razor view in a page

This basic razor view can now be dragged into a page placeholder that supports Razor views. When the page is previewed the contents of the What’s New content type will be displayed.

blog-whats-new

Taking it further

As I outlined in the beginning of the post, this simple Razor view doesn’t cover all the criteria, but it can easily be built upon.

It should be simpler to update and possible to document changes as we progress with the development of a release.
Changes can now be added as entries as development occurs.

It should have the ability to filter between the different types of improvement.
We’ve added the different types of category in our list, and we can use this information to create a sort filter.

It could highlight changes outside of Contensis that relate to the product e.g. its documentation. 
New types of category can easily be added to the category list.

Be future proofed to allow updates to be displayed outside of a webpage.
Now we have formatted the content as entries, we can easily use the content in different forms outside of a webpage, e.g. in the Contensis application or on a status board.

Summary

Looking back at our release notes for R8.3, the content was concise and fairly well structured within a page, but it didn’t allow the content to easily be reused. It was stuck in a single page. Rethinking the way you organise your content has huge potential in making it available for reuse in ways you haven’t even considered yet.

This provides a great place to end this post. If you’d like to see a series of posts improving and extending this example. We’d love to hear from you. In the meantime, keep your eyes peeled for the release of Contensis 9.

Subscribe to our stories

Richard Saunders

About the Author

Richard is the product owner for Contensis – our CMS. He sets the direction and roadmap for the product. His background includes both user experience and front-end design.

Follow Richard

More stories from Zengenti