CMS Admin Interface Customization: An Example

By Deane Barker on May 16, 2010

So, I’m sitting around in Denver International Airport, on my way to speak at Gilbane SF, and I got to thinking about CMS admin interface customizations.  In a lot of cases, this is what separates the men from the boys, in the CMS world.

Good systems let you customize to your heart’s content in a supported, elegant manner.  Bad systems don’t – if you can do it at all, you have to go hack their code, and re-hack with every upgrade.

To give you an example of a system that was planned and built from the ground-up to be extended, I cataloged the ways Episerver will let you customize their admin interface (all the ways I know about, anyway).  I thought about writing them down, but then I realized that would never do it justice, and it’s hard to understand something you never seen.

So, I had a little screencapping party, and I spent about an hour mustering up all the wretched image editing skills I have (there’s not much, believe me).  I now present you with an uber-screencap of some of the ways you can customize Episerver’s admin interface.

Episerver Admin Customizations

I’m sure I missed some, but these are more than enough, believe me.  Even if you don’t use Episerver, this is a great example of what’s possible, and what systems should strive for.

There’s a larger principle at work here: good systems don’t say, “you can do X."  Instead, they say, “how can I give you the options you need to do X,Y, Z, and whatever else you might think up?”

Comments (4)

Brade says:

Interesting to see a viewpoint that is pretty much 180 degrees opposite from 37signals and their ilk, which seek to limit the ways a user can shoot himself in the foot. No wonder you adore Microsoft more than Apple – options, options, options!

You seem to have a deep appreciation for complexity/customization rather than simplicity. Come to think of it, I would be really interested in your review of “Rework”...

Deane says:

Simplicity works great...until your problem is not simple. Then you often find yourself hacking like crazy to find a way around it, and the “solution” you present to your users ends up being more complex because the system wouldn’t adapt to it.

I know that the current mantra is “make content management simple.” And I love that idea. But we need to be prepared to admit that sometimes, content management integrations are not simple. Some of them are breathtakingly complex, in fact, and sitting around pretending like everything just needs to be more simple isn’t going to change that.

I struggle a bit with companies that try to “re-invent” content management by stripping away a bunch of features and pretending that they’re so enlightened. This would be wonderful except no one told the clients. The clients still want enormous amounts of functionality, and the crop of “refreshingly simple” content management systems usually fall absurdly short, no matter how right they’re convinced they are.

Brade says:

Apt points indeed. In my work for clients, they definitely have a lot of specific features they want in their CMS/admin app. So I usually start w/ a framework like CakePHP and am able to build quickly from there.

So the issue becomes one of audience. Developers really do need either A) a lot of freedom, or B) a lot of options. In practical terms, for a PHP dev, this is a choice, e.g., between CakePHP vs. Drupal. It’s been interesting working with both of these fairly equally, because without fail there are many things that are much faster to implement in one or the other – it truly ends up being about 50/50. Want to display a custom calculation in a specific place on the site? With CakePHP it’s simple. Want a paged image gallery with lightbox functionality? Drupal can get you there much more quickly in this case.

For both these platforms, the other audience comes into play as well, namely the client. Obviously the client needs to have their available options presented as concisely as possible – they don’t need (or want) a huge amount of freedom or options. So it falls to us as developers to make an attempt at creating this simple interface. The trick is knowing which stuff to allow them to change and which stuff to hard-code. In both cases, it’s priority #1 to define these as variables ASAP in the code, so we can switch back and forth if need be. Yet clients will always possess an uncanny knack for requesting the tweaks that are most troublesome to implement. (Granular permissions, anyone?)

Oh well, if things were any simpler, we developers wouldn’t have much job security... ;)

Deane says:

There are two sides to the “simple” coin: (1) simple for developers, and (2) simple for users. To make a system more simple for users (the ultimate goal), you need as many options as possible, because you never know what they’re going to come up with and you need a system that will wrap around their requirements, fit them like a glove, and make things...simple.

This usually means things are more complex for us, as developoers, but that’s just how it goes.