Each week, our Vice President of Product shares an email with the company that’s filled with the background story on why Brightspot’s features are the way they are. It’s not just how Brightspot works but why its features were engineered the way they were. Not one to keep secrets, we’re sharing her insights with you here, in a weekly column called “The Whys.” From creating vanity URLs to knowing the difference between a document and an attachment, these posts answer the questions anyone who publishes digital content has likely pondered.
As I mentioned in my last edition of The Whys, I think of Content Templates as "shortcuts." When it comes to Content Forms, I generally think of them as ... "magic."
Content Forms allow you to control the UI of an asset, including:
- The order of fields on the content type
- The labels of fields on the content type
- Whether a field is editable or read-only on the content type
- Whether a field is displayed or hidden on the content type
Much like with Content Templates, you have choices with Content Forms as far as "where you want them to appear." With Content Forms, you have two choices:
- Global: Meaning the changes you make to a content type in your Content Form become the default for all CMS users. (You probably don't want to do this, except in one case where you do, which I'll go into below, in the section called "The Best Use Case for a Global Content Form".)
- By Role: Meaning the Content Form you create must then be associated with a given Role.
I wanted you to understand the "where" with Content Forms because it impacts the use cases quite a bit. So, let's go back to those four things you can control in the UI using a Content Form, and let me talk about why you might do each of those things.
1. Control the order of fields. Let's take Article as an example. We've made the decision in Brightspot that SEO Title, SEO Description and SEO Keywords are in the SEO tab by default. But you might want the SEO fields to be front and center for a team entirely responsible for SEO metadata. In this case, you can create a role (SEO Editors) and a Content Form for Article that moves those fields out of the SEO tab and into the Main Tab just for the SEO Editors.
In this example, I've hidden lots of widgets and fields from the Article, and I moved the field SEO Title to Tab: Main, below Name; note that I have also changed the Name of the Field: Title to SEO Title
2. Control whether a field is displayed or hidden. This is where the “magic” happens. Let's say your SEO Editors have no need to see any other tabs on Articles, or the URL widget, or the References widget, or the Revisions history. On your Content Form, you can drag and drop those widgets to the "hidden" area.
3. Control the labels of fields. Within the SEO tab, those fields are simply called Title, Description and Keywords, which makes sense because they are in the context of the SEO tab. When you move them into the Main tab, wouldn't it be nicer if you labeled them SEO Title, SEO Description and SEO Keywords? You can do that in your Content Form!
4. 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.
A field set to Access: Read Only. You can also set a field to Read. By default, the Access is set to Inherit, which means all the fields will inherit what is set at the content type level Access.
The Best Use Case for a Global Content FormThere’s another very useful thing you can do with a Content Form: rename a content type completely (this is done in Global). As an example, I once set up a template for a book publisher that included these content types: Book Title, Chapter Number, Chapter Title, Book Author and Release Date. With Content Forms, this didn’t require any help from a developer. All I did was create a Content Form using Article, Section, Package, Author and Tag, and set them to Global—which completely renamed that content type for all users of the CMS.
The example above isn’t always the best solution, though. If you're working with a customer and their newsroom calls an Article a Story, and they call the Sub-headline a Dek, and they are never, ever going to use Slug, and everyone in every role in every part of the company agrees, then you should have a back-end engineer make those changes permanently in code instead of using a Content Form. In the long run, it's much faster to have an engineer make those changes one time in the original object vs. you or another admin needing to create a Content Form for every single role.
Sometimes you might use both of these options. You may know that you need to go the back-end engineering route but leverage a Content Form in the short-term to solve an immediate problem with a simple publishing action. You can always delete the Content Form when the permanent code change is implemented.