The Problem with Custom Fields

When it comes to content management, custom fields are good – it’s nice to have a place to put things that the developer didn’t anticipate. You’d think it would bridge the gap between a “closed” CMS and an “open” CMS (see this post and this post), but it doesn’t really.

Having custom fields is better than not having them, but there’s still a problem: the custom fields are usually always global, meaning every object has to have the same fields. So I haven’t really increased the variety of objects I can store, I’m just able to store the same object with more detail.

So if I’m making a Web site for my church, I have a problem. If I use some of the fields for Sermon Length and Biblical Reference, these same fields are going to appear when I want to store a Person.

Here’s a solution that I thought up while I was shoveling snow today (there’s a lot of snow, so I had a lot of time). This isn’t a replacement for a truly open, object-oriented solution (a la eZ publish), but it’s not bad. (The idea also creeps too far, as you’ll see.)

Here goes –

Instead of just providing some custom fields, allow users to define custom fields and group them into “Custom Field Sets.” So, I could create a Custom Field Set called Sermon. This would have fields for Sermon Length, Biblical Reference, Sermon Series, Guest Speaker, etc.

Then when I create a new post in TextPattern or a new document in Etimote or a new entry in Movable Type, I would “Add a Custom Field Set” to it. If this item is supposed to be a Sermon, I add that set. For a Person, I add that set, etc.

Problem solved. Sort of. There’s actually a slippery slope here. Slide with me for a bit.

Different items with different Custom Field Sets applied to them will expose different information. If I’m displaying a Sermon, then I have a piece of data for Sermon Length, whereas if I’m displaying a Person, I don’t. How do I expose that when I want to, and not expose it when I don’t?

The solution is to be able to select a template too. Etimote and TextPattern and lots of other systems allow you to do this on a per-item basis, so you can can pick a one-off template for a specific item if you like.

So now we have different templates for Sermon and for Person that handle information in different ways. When I create an item and apply the Custom Field Set for Sermon, I should also pick the template for Sermon. And now we’re happy again. Right?

Well, let’s slip down the slope a little more –

The application of a Custom Field Set and the use of a template are pretty much locked together, right? If you apply the Custom Field Set of Sermon, then you pretty much always want the template of Sermon, right?

So let’s lock the two. You don’t just apply a Custom Field Set and pick a template, let’s apply an “Object Type,” which applies the Custom Field Set and the template together. Awesome.

But…why wait until you’re actually in the posting interface for this? Let’s do it before you get in there. We’ll have a drop-down from the menu that says something like “Add a Sermon [Person, whatever].” Rock on.

And, with that, we’ve just slid down the feature creep slide and complicated the crap out of everything.

I still think the idea has merit. I just don’t know when to stop.