Content Modelling

❓

A strong content model is crucial for a successful custom publication. It streamlines and simplifies the process by allowing authors to provide custom data to the end application.

All Storipress Pro and higher plan users can create their own content model. This guide covers content modeling principles and setup with Storipress, giving you the confidence to start your Storipress journey.

The basics

😮

A content model structures and organises your publication’s data with individual content types. You can think of each content type as an outline for your content; it tells you what data will be contained within each entry.

Each content type has fields that specify the data type in the entry. For example, title text field, body field, and media file fields. This structures content into modular chunks.

Designing a content model is essential for building a robust, efficient, and sustainable Enterprise publication that meets the needs of your entire team, from content creators to designers to developers. A session with your content team is recommended to determine their needs and structure your content accordingly.

Architecting your content model

❗

Before designing your content model in Storipress, approach it with an open mind and forget traditional restrictions. Content modelling in Storipress is more flexible than traditional systems and goes beyond simple strings of text.

Storipress lets you create a content model that fits your publication, not the other way around. Define your model through our web app or API, focusing on your project's design and functional needs — if your publication needs to display additional metadata about an article, include it as additional fields.

Modelling within Storipress also differs from traditional database architecting. In Storipress, content is modeled from parent to child, unlike traditional spreadsheets where it's modeled from child to parent. This allows for early consideration of appearance requirements:

Start with the big questions:

What does the end application need to do, and

What information needs to be displayed to our users?

These two questions will help structure your content model effectively. As mentioned above, your overall model comprises individual content types. Each content type represents effectively a single ‘unit’ or ‘module’ of content within your end application. Thus, you’ll also need to think about where one type ends and another begins.

When to separate content types depends on the structure and flexibility required. For predictable content, like a brand page, use one type with all necessary information, such as name, location, logo, etc.

However, for content items which frequently requires authors to input different content types, separate content types based on criteria. One story type might have an image hero, but the next might require a video hero. Each media type requires other metadata; in which case, the creation of two separate content types—one for images and one for videos—is required for an author to pick and choose as required.

It's also good to identify reusable content elements. A example is a sponsorship block. Instead of typing out the a sponsor name and biography blurb into each article, you can create a reusable chunk of content containing the sponsor’s info that can be used repeatedly. Content reuse can significantly simplify your content creation workflow.

Assembling your content model

Now that you know what your content model will need to achieve, it's time to start building your content model in Storipress. This guide covers modelling in the web app, but you can also use the Content Management API.

When to use multiple publications

To build your content model in Storipress, log into the web app and create a publication. Each publication is a separate database and includes unique content types, entries, assets, user memberships, and API keys. Usually, it's best to keep all content in one publication, but multiple publications can be used if needed:

When to use multiple publications:

For working with separate projects, e.g. client work or multi-stakeholder projects.

To create a "playground" for testing, e.g. trying out features and settings with mock content when first exploring Storipress.

For creating publications which require internationalisation (i18n).

When NOT to use multiple publications:

For workflow management, e.g. to restrict publishing permissions.

To create numerous staging environments (the Content Preview API should be used for testing draft content).

Field settings & validations

Each field type in Storipress has configurable settings like name and validation options. All settings can be modified later, except the field type and ID.

Validations

The validations tab in your field's settings lets you set specifications and requirements. To ensure a story requiring a review always has a rating, just mark the field as required.

You can set validations for field types, such as required number of characters or predefined values. For reference fields, you can specify the allowed content type of referenced entries. The same applies to media fields — you wouldn't want to accidentally put a video where an image should be!

Validations exist on the right side of the modal

We recommend waiting to add validations until you have all your content types set up.

Duplicating & deleting content types

❗

Your content model will change in the future. Storipress allows you to edit, disable or delete fields as your content model evolves with your project.

To make changes to a content type without affecting the current model, copy it by selecting "duplicate" in the web app's content type settings.

Once you're ready to delete the old version of your content type, first, you must delete all of the entries using the content type to ensure the content in your end application won't be affected.

After removing all entries of that content type (including archived items), you can delete the content type completely.

Field management: disabling & deleting fields

To modify your content model, adding or removing fields is easy. New fields will automatically be added to existing entries. If it's a required field, existing entries will be held to the validation once the entry is update meaning older entries will remain published until updated at which point, you will need to fill out the required field before re-publishing.

Disabling fields in response

Disabling fields in API response will prevent them from being fetched by the Content Delivery API and not available in your end application, but still editable in the entry editor. Use cases include fields only relevant in Storipress web app, like entry status in workflow, where leaving this data out of the API response this data makes it more efficient to fetch.

Deleting fields

Before deleting a field, disable it in the API response and preview the changes. This safeguards against accidental field deletion and potential harm to your end application. Always test API responses before finalising field deletions!

Getting support

Content modelling is a broad and sometimes complicated, so don't worry if you're still struggling with content modeling. This guide just covers the basics. For further assistance, reach out to us via chat or support request if you ever get stuck!