Reading Time: 5 minutes

So, you’re a front-end developer. You’re trying to learn about Tridion and how it affects your life. Maybe you’ve met some Tridion architects you want to impress. Maybe you’ve aggravated them, but you’ve run out of whisky. Even after my last post on schemas, you still feel like there’s more to learn. Well, you’re right. There is more to learn about schemas in Tridion.

1. There aren’t that many types of fields for schemas

An entire website can be built with 7 types of fields.

• Text
• Number
• Date
• Embedded Schema
• External Link
• Multimedia Link
• Component Link

Seven types of field. Three are for linking, and one is for adding more fields. So really, websites are built with four types of fields. Tridion’s flexibility comes not by offering many different field types, but many options for few field types. All of these can be required, have multiple values, and default values, but some have additional options

• text field: 1 line or many, rich text (which has its own set of configurations), or plain text, list
• number field: list
• Date field: list
• Embedded Schema
• Component Link: Allow multimedia links

Why it matters to front-enders

1. A field is either required, or it isn’t; you have no complex field validations or messaging. The burden is on your code and your communication to set the parameters for how to use a field
2. Text fields are text fields; the difference between plain and rich text is setting it to be more than 3 lines and checking a box to make it rich. It’s deceptively easy to change a field to something that can have huge ramifications for how you write your code
3. The Date field also captures time; this can be used if you need to capture time in a specific formatting
4. There’s more to that lists option than you think

Knowing your field types and properties ahead of time helps you write code that’s in sync with content authoring expectations. In my experience, 2/3rds of “content authoring mistakes” aren’t; they’re the result of code that doesn’t fully acknowledge the configuration of the schema, or failures to communicate with the client. “They aren’t supposed to do that,” is not an excuse for poor planning ⁶.

2. There’s many ways to list-ify a field

I mentioned that you can make Text, Number, and Date fields a list. List is way too vague of a term, in this case.

You have the option to make a list, but you additionally have the option to choose what kind of list you want:

• Drop Down
• Select Box
• Radio Button
• Check boxes

Why list types matter to front-enders

Listifying a schema field can help regulate the kinds of content that a user outputs — but that’s not why this is my bonus #2 for developers. Listification is hugely beneficial when we need to give the user a tiny little bit of control over the presentation of content. Sometimes, we ask for a component template when really all we need is to give the user a few choices in the component:

• Should an image be on the left, right, or centered?
• Does the video need to autoplay?
• Does the user want to be able to add differently-colored borders around an image?
• Should a Call to Action use icons?

we can create component templates for each of these things — and we should create CTs if this presentation should be different. But if an image should always be on the left, and a video should always autoplay, this isn’t time for a new CT.

Dropdown lists may not always give you values

Suppose an image can be positioned left, right, or center. You might think, “great, this is a way to make sure it’s always positioned; I’ll use a dropdown list.”

Drop down lists only ever allow one value to be selected, but they don’t always guarantee a value! If the dropdown list doesn’t have a default value set for it, then on the other side, you may not get any position at all for that image — in which case, your CSS needs to account for a default positioning of that image. Unless you’re confident that the drop down has a default value, you may not want to use it for positioning an image.

Dropdown lists are more helpful for adding an optional feature to content. Suppose you’re using an image, and suppose it could have a multi-colored border, or none at all. A dropdown list with border colors is your friend.

Radios are automatically required

Going back to managing the position of that image, the radio list is perfect for this. In part, it’s because a radio list is automatically required; the user has to select “left”, “right” or “center”.

You can, of course, set a default value. But, especially with something like an image position where it’s visually appealing to keep images in different positions, you can leave out the default value and force the user to decide. So, you’ll always get some value out with the radio list.

Select Boxes can be confusing

I don’t often recommend select boxes and here’s why:

You can make select boxes multivalue, but it’s not obvious to the user that they’re multivalue. As you can see in the screen shot above, there’s no visual indicator that the first one allows multiple values, while the second one doesn’t.

And if it’s not obvious to a user that it could be none, one, or many, then it’s going to be hard to account for this in your code.

Check boxes beat select boxes

The fourth option for listification of a field is the checkbox. This sucker is perfect for the scenario where a piece of content can be none, one, or many things. This is what you can use when a user wants to have a lot of optional visual features on an element that don’t influence each other:

• Background Colors
• Border styles
• Text Colors
• Shadows

Each value of a checkbox can equate to a single class name in your CSS. As a result, you can offer “skinnable” options to the end user for managing the presentation of a piece of content.

In Summary

My first four facts about schemas in Tridion took 1000 words. The last two took up another thousand. Tridion can do a lot with very few types of schema fields. The front-end developer owes it to himself and his team to ask questions about the fields that are being used to put content on a page.

Not only that,the many different ways we can “listify” a schema field can have many positive effects on how we give content authors control over various aspects of their content. In fact, the listification of a field might deserve its own blog post, in the future.