You Want Collaboration, Not Workflow

By on June 1, 2014

Content management isn’t unique this in regard, but the CMS sales cycle is a process of people asking for things they’re never going to use. You smile and play along because they’ve put a lot of work into that RFP, but, honestly, at least 50% of the functionality they swear they need is nothing that’s ever going to get implemented. Call me a cynic.

This is never more true than with workflow.  I’ll say this: workflow is the most over-purchased feature of content management, hands-down (I’ve said this before, in fact).

Seemingly every project has grand plans around workflow. Editors are going to submit content to an approver, then it’s going to an editorial committee of which 60% need to sign off, then it’s going to a metadata specialist, then the legal department, and then it will be published when the temperature in Moscow hits 60 degrees and the Oakland Raiders win the Superbowl, etc.

None of this ever happens (especially the part about the Raiders and the Superbowl…)

In my experience, 95% of “workflows” are simple serial chain approvals, and 95% of those are one step.  Someone can edit and submit, then someone else comes to review then publish.  It’s barely even “workflow,” but that’s fine because it works and it’s what most clients really need.

I wasn’t a huge fan of Ektron as a CMS, but as noted in the link above, they did workflow well as what they simply called “Approval Chains.” They didn’t even try to pretend that workflow was anything more than a chain of approvers, stacked however many levels deep.

EPiServer has a slightly less powerful model in that you can give Editor A “Edit” rights but not “Publish” rights. This means that Editor A can simply designate content as “Ready to Publish,” and Editor B (who has “Publish” rights) has to come along and publish it. Same thing, really – a simple approval chain, but only one level deep.

Over the years, I’ve come to understand, that when a client says they need “workflow,” what they’re most likely talking about is “collaboration.” They don’t want approvals so much as they want to be able to communicate with other editors about content and make sure content looks good before it goes out the door.

So, the functionality people really want is:

  1. To collaboratively discuss content.
  2. To prevent bad content from being published.
I’ve always thought that a CMS would be well-served by letting you “turn the page over and write on the back.”  You know how Wikipedia has “talk” pages where people can have a meta-discussion about the actual content of the page (example)?  Same thing. The average content editor just wants a space where they can call a time-out and discuss the content that’s being produced.  Additionally, some of these discussions might need to be resolved before the content can be published.

Take a look at this wireframe.

We scoped this for a client on EPiServer, but sadly it never got approved.  However, I still think the idea has merit.  The major functional points are as follows:

  1. Any editor can open a discussion about any piece of content.  They can “turn over the page” and engage other editors and users in conversation about that content in the form of a simple discussion forum.
  2. The discussion can be “scoped” to a specific piece of content (e.g. — the privacy policy, for example), or to an entire section of content (e.g. — the About Us).
  3. Topics are tied to specific versions – so every thread is version-stamped, so you know what the current version of content was when the thread was opened.
  4. Topics can “block” publication.  When a thread is opened, an editor can check a box that says “this version of content cannot be published until I remove this block.” An administrator could override, but the idea is that a single editor can block the content edit until it’s modified to their satisfaction or someone talks them off a ledge and they voluntarily unblock it.
(Note: there’s something else in the wireframe about requesting approvals, but it’s been 19 months and I can’t really remember what I was doing there.)

I maintain this is really what 95% of people want when they say “workflow.”  I have no doubt that “true” workflow scenarios still exist – there are legal, regulatory, and audit scenarios that require historical trails to be present.  But these situations are further apart then we care to admit because we’re too busy showing off our shiny workflow solutions in a demo. Many prospects ask for these just because they’ve seen them in examples.

Give editors a competent solution for collaboration, and I’m quite sure that many requirements for workflow will simply evaporate.


Never Fall for a Custom CMS. Ever.

By on May 20, 2014

Because I keep seeing the same problems happen over and over and over, I’m going to make this claim:

There is NO benefit to you in being talked into using a custom CMS which is hosted and controlled by a web development shop. DO NOT AGREE TO THIS. EVER.
We’re seeing this again and again: an earnest client is talked into letting a web development shop build their site on an in-house CMS, which the dev shop hosts.  It’s an “end-to-end” solution, they’re told.

It’s all a myth.

I’m going to go one step further:

Any web development shop that tries to talk you into this is being reckless or naive at best. At worst, they’re being unethical.
At some point in the maturation of that dev shop, they faced a choice: do we (1) build our own CMS, or (2) learn to competently use one of the hundreds of available open-source or commercial options available.  In this day and age, I’m completely mystified why people keep trying the first option.

Actually, I think this is dying out. I hope it is, anyway. I’m hoping that the organizations we see getting screwed over today are just unfortunate vestiges of some archaic past practices.  Back in the day, this might have been a viable option. Back before the open-source world matured enough to provide so many great options.

But, in the darkest corners of my mind, some dev shop somewhere is staring down this choice today and still making the wrong one.

Think about this: if their CMS was really any good, other people would want to use it.  If it was that good, they’d sell it, or productize it, or at least open-source it and make the code available for other people to see and use. If they don’t (and they probably don’t), ask yourself why. If they have managed to re-solve the problems of content management so damn well that you should sign onto their pipe dream, why aren’t other people using the software?

If you are a client facing someone trying to sell you this, here are your problems:

If a dev shop tries to talk you into this, do not walk away. Run.  As fast as you possibly can. They do not have your best interests at heart. They are trying to put you in their system not for your benefit, but for theirs. The upside belongs completely to them – they get to be lazy, live in their own little insular world, pretend that they’re state-of-the-art, and lock you in.

Do not fall for it.

Do I sound pissed?  I am.  Too many times – several recently – I’ve seen good organizations get hurt by this. They finally realize that this custom platform is not meeting their needs, they make the hard decision to move on, and they suddenly face tens of thousands of dollars in migration expenses at best, and a obstructionist dev shop at worst.

So, are all hosted CMS options bad?  Well, they’re not ideal, and I would never encourage one of my clients to use a SaaS CMS option (I’ve made this point before), but if you have to, look for two things:

Don’t do anything until you have good answers for the above two questions.

This business practice just has to stop. I’m waiting for the first client in this situation to just man up and sue their shop for professional negligence. When it finally happens, I’ll be standing by, cheering them on.


It’s Fun to Hate Microsoft

By on May 8, 2014

Microsoft killed my Pappy: Scott Hanselman points out the truth: the Microsoft you’ve worked so hard to hate for so long is not the same company it used to be:

We’re putting source on GitHub, many groups are using Git with TFS internally for projects, we’ve open sourced (not just source-opened) huge parts of .NET and are still pushing. We’ve open sourced Azure hardware specs, opening SDKs, and we’re making systems more pluggable than ever. Frankly, we’re bending over backwards to NOT be dicks about stuff, at the very least in my corner of the company. Could we do better? ALWAYS. Are we pure evil? Nah.

But, of course, none of this matters because people are still going to hate Microsoft because they need someone to hate.  Yes, Windows 8 has some stupidity to it.  So does iTunes. So does Draconian control of iPod connectivity. So does a ton of stuff Apple does.

But, whatever. Keep hating if that’s what you need to be happy.


How to Give a Good Conference Talk

By on April 17, 2014

I talk at a fair amount of conferences. Over the years, I’ve taken notes on how to do it well (this pre-supposes that I do it well, which is very much up for debate).  I figured I’d share these notes.

Now, understand that I give a very specific type of conference presentation, which is 30-50 minutes and always based around a presentation deck (a Power Point).  This might not fit for everyone.  Some of you might be doing a short speech unsupported by any visuals. If so, pick and choose from the sections below.

Also, I don’t offer this list as hard-and-fast rules, nor do I think it’s the only way to do it. This is simply what works for me. I concede that other people may have entirely different ways of doing it.

Here are my notes, edited slightly to make for a better blog post. If you’re staring down a conference presentation, I hope they help you.  (And, in the true spirit of PowerPoint, these are in the form of bullet points, because that’s how I wrote them down originally.)

Questions to Ask the Organizers

The answers to these questions will help you, either explicitly or implicitly. The idea here is that it’s good to get as much background info as you can, because whether you’re aware of it or not, it will influence your talk as you put it together.

Planning Your Talk

Preparing Your Deck

Rehearsing Your Talk

Giving The Actual Talk

If you want some more good tips, take a look at this: 11 Top Tips for a Successful Technical Presentation. In particular, read the comments there – lots of great stuff submitted in the comments. It’s also worth noting that Scott Hanselman is the presenting style that I really try to emulate: he’s so wonderfully relaxed when he talks that you feel like you’re in it with him, rather than being lectured to.

If I could replicate one talk (in vibe and style, not so much content), it would be this one: It’s not what you read, it’s what you ignore. That’s Scott at WebStock 2012 in New Zealand. It’s fantastic.

It helps that Scott has spoken at my company, sitting at my breakroom table. It’s easy to like someone when they do that for you.


Perspectives On What “Archiving” Means in Content Management

By on April 16, 2014

In content management, “archiving” is a pretty common word. Systems allow for “archiving,” or there are “archive” buttons on the interface, “managing content archiving” is a bullet in a job description, etc.

But there’s no accepted definition for it.  What does it mean, exactly?

I appears to mean any one of the following:

Different systems have different ways of defining it.

I posted this question to the Content Management Professionals group on LinkedIn (it’s private, so no link – unless you’re a member, you can’t view it anyway).  Here are a smattering of answers.

  • Archiving keeps the information available to content managers in case of any legal/ compliance issues that may arise. […] when you delete records you lose that “institutional memory” which is a lot more valuable than most people realize. Once the “archived” content satisfies your firm’s record retention policy, you can then delete it.
  • […] we first began “archiving” in the late 1990s-early 2000s on websites where we had little control over how the CMS displayed content. We “archived” something by removing it from regular view [but it would still be available to search], and then, a few years later, we got a REALLY advanced CMS and we could “archive” by removing it from the production site but leaving it in the system for managers in case it was needed for audit purposes, etc.
  • As a former archivist, I can tell you that the profession as a whole winces when they see the word ‘archiving’ […] In my present role, I move files out of general circulation into an ‘archive’ area within my CMS – they are no longer visible to most users, and we do worry about traditional archival things like records retention once we move them there. That said, in previous roles the ‘archive’ has referred to things like moving previous feature stories off the main page (back when that involved hand-coding a flat HTML file to point to all the older files), and elsewhere it has had that more ‘locked away’ meaning.
  • From an operational point of view one could argue: Everything that is currently not in use in day-to-day business, but may be needed later for whatever reason is to be archived.
  • In our system we do try to make a distinction between archives that are still publicly available and archives that are not. The former is “Archive” while the latter adds the modifier “Archive and Expire.” This latter option signifies that the content is “expired” from the site. From the perspective of the visitor, it’s as good as deleted, yet the authoring / managing team still retains the data for record keeping.
  • To me the ‘standard’ definition for archiving content is allowing it to be accessible via search, while no longer remaining prominent (if navigable at all) on a user’s website.
  • […] taking it out of the CMS in order to keep it for audit reasons and the like […]
  • Archiving is purely and simply the act of preservation. Access, purpose and use are details that affect consumption of the archive.
  • I always considered archiving a method to reduce the impact content has on the system(s) usability; for instance with regards to searchability, performance, but not in the least user-friendliness (for lack of a better word)
  • On a number of projects I’ve seen “Soft Delete” used to describe the state in which content has been effectively removed from the system, but can be restored in an emergency. Archiving, in my mind, implies recognized long-term value, rather than a CYA ability to restore.

In seems that “archiving” is a very fluid term, and one that means whatever the organization defines it to mean.


Why I Love to Manage Content

By on April 7, 2014

I love content.  I love modeling it, storing it, managing it, organizing it, searching it, and delivering it.

Why do I love this?  I’ve spent a lot of time trying to figure that out. This is my best attempt, and I apologize in advance if it’s overly personal or dramatic.

Content is beautiful. It has a purity to it.  It has a soul — done correctly, content is information in a perfectly accessible wrapper, waiting to be consumed and used for some purpose. It’s potential energy, perpetually standing by, ready to be unleashed.

There’s incredible beauty in that, full stop.

But, even more importantly, content is the genesis of action, education, and change. Content informs.  People come away from good content with more understanding and perspective about issues that affect them.  Content enables them to consider a situation, question, or decision based on clear information and then act with purpose and clarity.

So, content is core to teaching. And there is joy in helping someone understand.  There is an amazing feeling when someone finds something they were looking for and finds a clarity they were missing. That’s a gift to that person.  More than that – it’s a gift to the world. We are better as a human race because of this moment. Moments like this move us all forward.

Our society depends on continual progress.  The information in content represents that progress.  The accumulation of information is how we get better as a species.  It’s why we have advances in medicine and science and history.  It’s why movements start and governments fall.  A population with accurate information is in a better position than a population without it.

You know that feeling when you type something into Google — no matter how obscure — and you see that someone has searched for it before?  Content provides that connection.  The fact that content for Topic X exists means that someone else had the same problem and also needed Topic X.  You are not alone.  Content unites.

The search for information is a cry for help.  No matter how inconsequential, it is someone looking to improve their circumstances by educating themselves.

The content manager is a matchmaker. The world is looking for content, and content is waiting to be found.  The content manager is the person who brokers that meeting.  The world is better when this happens.

I want to be there for that. I want to be the silent thing lurking in the background that someone thanks when they find what they’re looking for.  I want to be that source of happiness for them, however many layers removed, however faintly understood and acknowledged.

I am driven by the vision of people finding what they’re looking for, experiencing that happiness, educating themselves, and making a better decision sometime in the future because of it.

You don’t create content for yourself, you create it to be consumed.  By the same token, you don’t manage content for yourself, you manage content to make it easier for someone else to consume it.  Content is a service to others.  It is a service to the world.

I believe that the management of content is honorable. Managing content makes the world a better place.

When you manage content, you are a gear in a larger machine.  You are the volunteer passing sandbags down the line.  You are bridging the gap between those who create and those who consume.

In a perfect world, you are unnoticed.  You exist in service of the content, and your performance is measured strictly in how well you allow the soul of the content tor be found, understood, and used by the consumer.  And in some small way, your performance in this role makes the world a better place.

This is the role I gladly accept.

This is why I love to manage content.


IA is Not New

By on March 31, 2014

One of the problems with working in digital is that we tend to think we invented everything. We sit around and imagine we’re breaking amazing new ground, when we’re often just retreading ground that was broken long before.

Consider the much-ballyhooed discipline of “content modeling” (a phrase which I admittedly use freely).  This used to be called “data modeling.” I wrote a sidebar for Sara WB’s book where I essentially said the same:

Many of the challenges you find in content modeling are basic data modeling problems, and the relational database crowd solved those decades ago: Don’t duplicate data. Tend toward atomicity—small particles of content. Compose complex objects by combining simpler objects. […] None of this is new, but it might be a new way of thinking for you.

What’s different now is just that you don’t need a database designer to do this – you can do it in your own, humble CMS, without help.  So, old problem, just a new solution.   But, again, we tend to think we’re changing the world, when we’re really just re-solving problems which have largely been solved, or finding different ways to do things and thinking that this makes it a new thing.

This is never more true than in the information architecture space.  “Information architecture” is a great label, but it’s one that has gone by less glamorous terms for a long time: “library science” and “cataloguing” and “classification.”  I imagine some people think “taxonomy” is a purely digital term (or even the funny made-up name for a Drupal module).

What I don’t see much of in this space is people reading the classics – going back to the basics of how this discipline has been done for centuries.

Yes, these people are long-dead, but there’s some great reading there.  If you’re interested in IA, I defy you not to be fascinated by Ranganathan’s “colon classification” system, or his “original” facets: PMEST (his idea of the “personality” of an object is pretty fantastic).

It’s also interesting to see the historical emphasis on labeling – they didn’t have computers that could slice-and-dice facets back then, so they had to label, and there was a science for coming up with the “category number” for any combination of facets.  (Put another way: you don’t know how good you have these days…)

I’m going to recommend two books here:

For giggles, read the footnotes and indexes in those two books.  It’s humbling.  I quickly came to realize that I didn’t know jack squat, and the Dunning-Kruger Effect slammed into me like a dump truck.

(To make it worse, spend five minutes skimming George Lakoff’s “Women, Fire, and Dangerous Things,” and take a second to appreciate how much research has gone into the science of mental classification, which has been a thing since humans have existed.)

Now, don’t misunderstand me – I’m not saying that we don’t know anything.  Furthermore, I’m not saying that the Internet doesn’t bring about some very unique aspects to information architecture.   We are doing some neat stuff, sure, and we’re expanding this discipline in some important ways based on the current environment in which we exist.

But what I am saying is that 90% of the ground we’re “breaking” has already been broken.  And if we took a second to look, we’d understand that we’re really just standing on the shoulders of giants.

More than that: if you really love information architecture, go learn some history.  For me, reading about guys like Ranganathan isn’t just educational, it’s…fun.  It’s thrilling.  It’s fulfilling.

The bottom line: we are continuing an amazing legacy, and knowing the long, dusty road that has led up to where you are walking right now will make you appreciate your discipline so much more.

Put another way, when you finally scale the peak of your discipline and reach the summit, don’t be surprised if you find a bunch of librarians who have been sitting there for years.


The Gift of Perspective

By on March 26, 2014

Why your previous developer was terrible: When a new developer comes onto a project, they often find a bunch of stuff to change right away and seem to be hyper-productive right out of the gate.  It’s a matter of fresh perspective, and the ability to view the project with the perspective of the current moment in time, without understanding that the application was development in many moments in time, each with their own idiosyncrasies and variables.

It’s what I call the “curse of the present.” When you, as a developer, look at the choices used to build a particular application, you’re blown away at the poor decisions made at every turn. “Why, oh why, is this built with Rails when Node.js would be so much better?” or “how could the previous developer not have forseen that the database would need referential integrity when they chose MongoDB?”

But what you may not realize is that you are seeing the application as it exists today. When the previous developer (or team) had to develop it, they had to deal with a LOT of unknowns. They had to make many decisions under a cloak of opacity. You are cursed with the knowledge of the present, so the system seems like a hackjob of bad decisions.

So much truth here.


The Necessity of Asynchronous Communication

By on March 22, 2014

Synchronous communication is over-rated.  By this, I mean the concept of talking to someone face-to-face, or over-the-phone in real-time.

I’m not saying this communication doesn’t have some unique properties, but in a lot of cases, it’s not what you really need.  Rather, you need asynchronous communication, where one party says something but doesn’t wait around for an answer. When the other party does respond, the conversation continues.

I wrote about this almost 10 years ago when I explained Why Email is Better Than the Telephone.  I said:

A lot of interactions are, by nature, segmented. In a lot of conversions with someone, you need to check with someone else about something, research something, wait for something to happen, etc. A lot of phone calls are ended because someone “offline” has to occur before they continue. This fits in perfectly with email.

And this is still true.

Real-time communication introduces lots of non-communication factors that often confuse the issue at hand.  You’re trying to debate a larger problem, but you keep get distracted by the other conversant’s annoying tie and the Southern accent that drives you nuts.

Additionally, you often don’t think clearly on the spur-of-the moment.  Ever had a debate about something that you “won” an hour later when you were thinking up what you should have said in the car on the way home?

Even if you’re great on-the-spot, perhaps you need some time to research something.  You’re not an encyclopedia, and an off-the-cuff exchange gives you no time to make sure you’re know what you’re talking about.

When my wife and I were dating, we were full of drama, as most young people are.  Thankfully, we learned a constructive way to argue – we would call each other and leave messages on each other’s answering machine.  This gave us time to absorb the other person’s response, think about it, determine an appropriate response, rehearse it a bit, then deliver it.

(I still remember the time I answered the phone to hear Annie say, awkwardly, “Um…I was calling for your answering machine…”).

There’s still a category of people who eschew email and prefer the phone. They see this as folksy, good ‘ol common sense – “Why do that new fangled stuff, when the phone still works fine?”  Or they view it in terms of human relations – “We’re too disconnected these days, so it’s much better just to walk into someone’s office.”  (Most of these people enjoy being contrarian, and a lot of them consider this part of their personal brand.)

These sentiments may be true in many cases, but not in all.  There are certain communications and interactions and patterns when a real-time, face-to-face conversation is exactly the wrong thing and will damage the exchange more than help it.

I always remember a project manager at a company I worked out. I couldn’t stand this woman, and I had a hard time talking to her about anything (in retrospect, however, she was a very talented PM).

Whenever would send her an email, my phone would ring immediately.  I had to resist the urge to yell into the phone “I sent you an email exactly because I didn’t want to talk to you!!”

Maybe I was just a jerk, but even then I was having trouble understanding the desire for some people to always talk in real-time.


Two Versions of the Content Management vs. Marketing Talk

By on March 19, 2014

When writing about the white paper I wrote for Movable Type, I suddenly realized that I failed to post this, which is the video of the talk I did for the Movable Type Idea Exchange in NYC last fall.

This is a recap of the talk I have at Drupalcon in Portland in May 2013.  Here’s the video for that.  You can pick which one you like better – Movable Type has me, and Drupalcon just has the audio, but has a better view of the slides.