Every so often, our Vice President of Product shares an email with the company that tells the background story on why Brightspot’s features are the way they are. Not one to keep secrets, we’re sharing her insights with you here, in a series called “Inside Brightspot.” From creating users and permissions to knowing the difference between different dashboard widgets, this series will answer the questions anyone who publishes digital content has likely pondered.
As mentioned previously, we recommend that users think of Brightspot's Content Templates as shortcuts. Content Templates allow users to save and reuse versions of assets with certain attributes and layouts pre-filled to save time.
When it comes to Brightspot Content Forms, we recommend thinking of them in terms of the Brightspot UI, which is a lot like filling out a form — and Content Forms allow users to modify the the UI of a form.
For example, the types of modifications you can make to the UI of an asset using Brightspot's Content Forms include:
- The order of fields
- The labels of fields
- The grouping or organization of fields
- Whether a field is editable or read-only
- Whether a field is displayed or hidden
Sounds cool, but when is the right time to use a Content Form?
Content Forms in Action: Use Cases
There are a handful of times when Content Forms can be useful.
First, a Content Form can be set to behave globally, which means the changes within it will be made available anywhere that content type is available in the CMS, to every user of the system.
The best example for using a Global Content Form is when a team simply needs to quickly rename a content type. For example, we often find that customers refer to an Article as a Story. Using a Global content form, that's a simple change.
That said, a Global Content Form is a rare breed — the more likely use case is associating one with a Role. A role-specific content form has a variety of uses, and it ties into permissions. For example, a newsroom may want to make metadata and SEO fields read-only for certain members of their teams — this can be achieved with a content form.
Creating Content Forms: A Primer
As you can see, you have a lot of freedom of choice in how you leverage Brightspot's Content Forms.
Next, let's explain what you can do in the UI, taking an Article content type as our example.
1. Control the order of fields. In the Article content, let's say that the order of fields in the back end data model is Headline, Author, Body, Section and Tag.
If we'd prefer that Author is instead below the Body field, we could do that quick reordering with a Content Form. (Note that this does not change the underlying data model, just the tool UI!)
2. Control whether a field is displayed or hidden.
Take our Article again. Now let's say that we've decided that we don't want Author to display as a field anymore. Again, we can use a Content Form and drag that field into to the "hidden" list.
3. The grouping or organization of fields. In addition to reordering and hiding, Content Forms allow for fields to be grouped together (what we call Clusters) as well as into different Tabs. For example, let's say we wanted to group Author, Section and Tag in one single group or cluster, called Metadata. That's a simple drag and drop in the Article Content Form.
4. Control the labels of fields. Still talking about this Article. Now let's say we want to change the label of Author on Article so that it's instead called Byline. You guessed it — we can do this by changing the field label on the Article Content Form. (Again, this doesn't change the underlying data model.)
5. Control whether a field is editable or read-only. Your SEO editors need to be able to read-write the SEO fields. They also need to be able to see the Body field (so they can read the content, understand it and add rich keywords). However, they shouldn't be able to actually make edits in the body field. Within Content Forms, you have the ability to set a field to Read or Read & Write. In this case, we set the Body field to Read, and, voilà, our SEO Editors can't make changes to the Body field.
When NOT to Use a Content Form
Content Forms sound great, and they certainly have their uses. However, it's important to remember that they do not change the underlying back end data model of Brightspot.
For example, let's take the use case where a newsroom calls an Article a Story, and would much prefer that the Author field was labeled Byline, for all users.
In this case, because this difference is relevant to all users, the ideal path is for a back-end engineer make those changes permanently in code instead of using a Content Form. Because it may take a few days for that code to be written, tested and deployed, the Content Form can be created and published as a short term stopgap solution to limit confusion. Once the back-end engineer makes those global changes, the Content From can be removed.