PCMT – The Perfect Content Management Tool, take one

In my last post I cried out about the need to have Content Management as a tool. This does not mean that “solutions” are not good or useful. Of course they are, but they can support (well) only a fraction of our CM needs. For the rest, we need a tool.

Note that I’m not talking about “Content Management” as in “Web(site) Content Management”. I’m talking about the CM as in the management of content, when content is defined as a set of data, usually not just a row in a table. Also, this is not a post about the definition of CM… there’s enough of that already going on…

The journey begins in 2004 when I was discussing with a customer and we were doing the requirements analysis for a contract management solution. On my question about how does he see the best software solution to its needs, he replied:

“I would like to have one big button on the screen. And when I push it, it should do whatever I want it to do. That’s about it, I’ll be satisfied with that.”

Perfect Content Management Tool. (obviously, you can replace CM with anything and will still be valid)


After a few laughs we resumed the more down to earth talk and ended up with a decent set of requirements. But the idea of the “big button” still lingers on. With me and also with my – now old – customer.

Can it be done? Sure!

Now? Dunno. But I will try.

Let’s analyze, split and address the challenge ahead.

There should be “a button”. Ideally “the only button”, but we could probably negotiate on that. A button is something simple to understand by the user, it’s accustomed to its behavior. We should not necessarily stick to an actual GUI button, but instead understand the idea of offering to the user something very much close to the usual things it interacts with each day. For example it can also be a “link”. But it needs to be big, aka “visible enough”. Menus probably don’t work.. as they are a little more complicated.

The button should do “what I want”. I  specifically remember the customer saying “what I want“. Not “need” or “should be done”. I’m not sure right now if it’s easier to to a button which does what’s needed vs. one which does what’s wanted. Anyway, one which does what “should be done” is definitely the easiest of all magic buttons.

How do we make such a button? Well, the button should “hear” the context in which it stands, should know the context in which his user is and must know what resources he can access and which are the processing paths it can follow. Probably also a lot of other things, but these are the ones I feel are important right now.

Hear the context in which it stands

The button is somewhere. Because it exists.

For example, it should know its location on the screen (c’mon, this is easy)… but not for presenting itself to the user. It needs to know this because the position might have a meaning. If it’s on the top right corner then maybe it will do something completely different than if it’s on the bottom. If the button is on a laptop screen it might perform other things than if its on an iPhone. I know it sounds simple, but remember we’re talking about “one” button. Only one, not several ones.

Ok, but you said “hear”. Yes, the button must be able to hear (not receive as in “destination”) the messages sent by neighboring other “things”. This is happening right now at a primitive level with GUI buttons on presentation software. But I’m not talking about that. The “button” is just a metaphor at this moment of the whole tool/software thingie. The messages are in my view, not technical ones.. but more linked to the data the user interacts with and to its meaning.

In order to hear, the button must have the receptors for this. Webservice listeners, message queue monitors, event handlers, psychic serial bus.. you name it.

In order to understand what it hears, the button must speak the language of the message. This is where standards or public formats come into play. Both are good, I’m not advocating one over the other, let the real life decide. The more standards / public formats will the button speak, the better the button.

Know the context in which his user is

Is my user in an airport, is he at his desk, is she in a meeting, is there some public wireless within reach? This sort of data must be available to the button and it should know them. By knowing this, it has more data to process and be more prepared when the user clicks it.

and so on…

What’s this got to do with Content Management?

Where is my ECM?

Nowhere near, I’m afraid.

But I bet we can get it closer. Not in one swoop, for sure. But would if be that hard to make a button called “Get” which will adapt to all of the above and try to surface my accessible content from wherever, and help me get to the one I want in some 2-3 clicks through a faceted navigation?

Since the button is sensitive to it’s context, we can move it around on our digital workspace and activate it when we reach the are we’re focusing on. Or when it “glows” (probably because it just detected that he can tell me something “new” about the context).

Does it sound Science Fiction? Not to me. Just came to mind: “instant search” anyone? Things are moving, get on with it.