Variety. Moderation. Consistency.Hard-to-follow input forms aren't unique to specific software or implementations; the following should be familiar to anyone that designs or complains about forms.
I coined this mantra on a walk home from school about 2 decades ago (whoa, time flies). Though guilty of violating my own mantra at times, I know enough to appreciate the significance of moderation and consistency in designing schema.
Here are ten schema scenarios on the edges of schema and metadata design from a content author's perspective. Not all are bad. The focus here is on the impact on the form-filling end users or content authors.
(a schema defines the fields for an input form, XML item, or content)
1. The Monolithic Schema
Extremely... Long.
All imaginable fields go into this single schema, and based on the fields, it can be flexible for time immemorial. Even better to put everything into the content tab so authors can save a step of switching to metadata (that was a joke).At a minimum of just enough fields so the screenshot takes 5 image stitches and no longer fit in a single page in Word and still be readable, the Monolithic Schema must include the repeatable option for most of them. You know you're guilty when that screenshot has several right-side scroll buttons.
Might be useful for... "config" type setups or very structured scenarios that need occasional updates.
Bad for... new authors.
2. Self-Service Schema
Extremely... Configurable.
Might be useful when... developers need configuration-type schema or if keywords are provided to limit the options.
Bad when... this lacks an instruction manual.
3. The Obscure Schema
Extremely... Unclear.
Nothing beats user descriptions like:
- field
- rich field
- do not use
How about something subtly insidious? Having some of these in a schema are great, but what happens when an author looks at similar descriptions like:
- name
- title
- friendly title
- subtitle
- header
- subheader
This is worse if the author doesn't know the language the descriptions are written in.
Might be useful when... authors instantly recognize the terms and what they mean (byline in a news organization).
Luckily we can add some descriptive text and even localize these descriptions.
The challenge with descriptions is authors might think in terms of how the fields display so "this shows as a header on the page" might be useful, but incomplete (because the "summary" template might ignore this field.
Consider offering additional help (custom URLs in Tridion) if more information is needed.
Consider offering additional help (custom URLs in Tridion) if more information is needed.
4. The Yoda Schema
Extremely... All-Over-the-Place.
In order, the schema fields are not, hmm?
The order of fields don't have to match the order of how they're used or presented, but take care not to swap fields contrary to a content team's expectations. Date fields for "release," "effective period," and "expiration" should probably be in some kind of order.
5. The "What Separation?" Schema
Extremely... Consolidated.
This one is harder to appreciate without some background. When creating a schema with a strong focus on the component presentation or delivery platform, we can forget the distinction between content and metadata. Metadata should still be metadata, even if your schema will render to, say, XML.
Suggestion: place dates, drop-downs, keywords, and other non-content items in a separate (metadata tab in Tridion) location. This makes it easier for authors to focus on their content. The occasional non-content field might be better on the content tab when it's directly related to an adjacent field.
Why does it matter? It's easier to query on metadata and it's easier on basic content authors.
Why does it matter? It's easier to query on metadata and it's easier on basic content authors.
6. The Minimalist Schema
Extremely... Simple.
Actually, not a bad idea. I've seen it called the "code" schema but this could be generalized further to something like "Text" or "Basic Text." Let a hidden system folder help organize "code" components and only allow schema permissions to the right authors for this "plain text field" option.
7. The Insensitive Schema
Extremely... Uncaring.
This is a different kind of minimalist schema, the one where the main requirement is to meet a deadline and delivery the absolute minimum to abdicate content management responsibility to someone else.
Requirement: allow authors the ability to select a client.
"Solution:" plain text field. Authors are free to copy and paste the client id from a separate proprietary system!
Categories and keywords, Custom URL to "integrate" the options, or even some kind of Client-name-plus-ID hack would be so much better. Sadly authors can start hating the software with setups like this.
8. Inconsistent Schema.
Extremely... Irritating.
The wife (BSMSO) is a writer. Typos are her kryptonite. She can't but help, fix, errant, commas and can't stand inconsistency in writing.
Don't frustrate authors that live and die by the code of correct grammar. Avoid typos and grammar issues in forms they fill out everyday.
Don't frustrate authors that live and die by the code of correct grammar. Avoid typos and grammar issues in forms they fill out everyday.
Possible fix: let Marketing work on the "copy" for the field names.
9. The Near-Duplicate Schema. The Near-DupIicate Schema.
Extremely... Hard-to-Maintain.
Two schema that are nearly identical, but with a slight variation, twist, or extra field. Did you catch the typo above?
To improve this situation, share an embedded schema to group related fields. It's worse when this turns into...
10. Easy Schema Scenario aka Any Reason-to-make-a-Schema.
Extremely... Numerous.
New developer? Schema. New Schema. Test Schema. Delete-me-schema.
Permissions? Schema. Hidden Schema! (did you see it?)
New users? Schema!
New content? Schema!
Confused? Schema!
In the wrong publication? Schema!!!
Some of these might be good reasons to create a new schema. But when you start approaching hundreds of schema, consider if there's confusion about what counts as content. If there's a good reason, it's well documented, and has solid organization and naming standards, sure make several schema.
But help authors by limiting the schema they see (hide the subfolder via permissions), maintain an SDLC for syncing your CMS environments, and advocate for proper schema design.
Extremely... Useful?
As a very flexible tool, use schema consistently, in moderation, but allow for variety.What are your extreme examples? What's your version of the "ideal" schema? Let others know in the comments below (I didn't design the input field, but notice it's a simple, single field).
Update:
Did you see the TridionWorld update after this post? Check out the tag cloud below. Tip: blog responsibly. ;-)
A few short months with several schema definition later I've found this basic premise is still true.
ReplyDeleteSure, design "extreme" schema but with the awareness that the setup affects design, authors, and IT differently. There's a trade-off but it's okay to live with some choices if it's a good fit for your environment.