Scalable Schema Fields

Content Management Systems often let you define authored fields as well as how they present to content authors.

For example, SDL Tridion allows number, date, and text fields as schema (content definition) field options. Text fields can present as:

• drop down list
• select box
• radio button
• check boxes
• tree (may not be as familiar as the others--use it to offer keyword selection organized into subcategories)

After four SDL Tridion functional projects in as many quarters, I wanted to make a tl;dr multi-post on schema and template design. In the meantime, here's three practical schema design tips "from the field."

Consider Keywords instead of Separate Schema Fields

Though you can definitely use "True/False" or "Yes/No" keyword options via a "Boolean Category," consider check boxes driven by a Category for future flexibility.

Instead of:

External Search:
[ ] True
[ ] False

Internal Search:
[ ] True
[ ] False

See if a single field of options make sense:

Search options:
[ ] External
[ ] Internal

This allows you to:

• simplify entry and consolidate template code with fewer fields
• add new functionality with a keyword change rather than a new schema field

Some catches:

• you can't have more than one default option (without an extension), though you could change the wording to make the unchecked option the default update: content types let you create whatever default selections you need
• you still need template logic to handle the various options

Mimic Placement by Increasing Per-Line Settings

If you do have two options, consider increasing the boxes/radio buttons per line setting to place these accordingly. Typically you wouldn't have positional requirements in a schema field, but if you did, these per-line options come in handy.

Placement:
( ) left  ( ) right

Position:
( ) 1 top left  ( ) 2 top right
( ) 3 btm left  ( ) 4 btm right

Rating Scale:
( ) 1 ( ) 2 ( ) 3 ( ) 4 ( ) 5

Tic-tac-toe (not practical, but you get the point):
[ ] 1 [ ] 2 [ ] 3
[ ] 4 [ ] 5 [ ] 6
[ ] 7 [ ] 8 [ ] 9

For longer-named keywords, list them in order with an item per row and if you need a selection that changes based on what an author selects, consider the tree view.

Map Business-to-Developer Terms with Keyword Key Values

It's tempting to use text fields for authors for ultimate freedom. When possible, template out all but the relevant info. For example, if your rendered output needs "https://graph.facebook.com/19292868552" (the social graph URL for the Facebook Platform), you could add the URL part with template code.

An author would only enter the id (i.e. 19292868552). If appropriate, place this ID in a component or use it as the key value of a keyword, so the author sees "Facebook Platform" as a component or from a select-able keyword list.

By separating the URL, you could then update it in a single location or possibly re-use these IDs with third-party services or for analytics.

See StackOverflow for sample code to get these keys into your templates. Alternatively you could use configuration components, an extension, AppData or possibly keyword metadata--it depends on how you want to manage this mapping.

Keywords let you better manage evolving schemas that have binary T/F options, the per line setting improves how your component form works in certain scenarios, and a keyword's key value helps you map business terms to developer keys.