Goodbye, Different Chairs

It’s been an interesting eight years.

I started Different Chairs after finishing grad school in the Potemkin village of Ann Arbor, Michigan. I didn’t know what I was doing; I made mistakes continuously. Wherever it was possible to do something wrong, I did, and maybe half of the time I managed to learn from it and improve my work.

Here’s one thing about running a small business: it’s never easy, although it’s sometimes good. Here’s the other thing: even a sole proprietor can only be as successful as the people whose support, collaboration, and friendship make it all possible. You know who you are. Yes, you. I don’t say it often enough, but I’ll say it now: thank you.

In the end, I solved problems. I made clients happy. I treasure every moment of it, even those I won’t miss. Today’s the last day of Different Chairs, and tomorrow is the first day of what’s next.







Problems and solutions

A long time ago, my mother-in-law Sue told me that some problems just don’t have solutions. I knew she was wrong. I knew that every problem has a solution — that having solutions are what problems are for. Of course, I was wrong, and she was right.

Some problems have solutions that you can see, but can’t get to. Some solutions are even worse than the problems they’d solve. And some problems are just plain tricky: the swords of mighty kings forged into gordian knots. Other problems are solved merely by waiting for a person to die or for an empire to crumble. And whenever you solve the worst problem you’re facing, the second-worst problem immediately steps up to take its place.

Storytime with Jerry Weinberg

A friend recently tweeted this quote from Jerry Weinberg’s “Secrets of Consulting” (a phenomenal book with a lousy title):

That quote reminded me of my own summary of “Secrets of Consulting”, which, true to his homilist technique, I call the “don’t be a jackass” rule:

The “don’t be a jackass” rule

Problems are everywhere. Acknowledge that you, under your own strength, are not going to solve every problem you see, or every problem you know how to solve — and if you try to, you’re just being a jackass.

(What’s this all about? Well, go read Weinberg’s book, or soak in Todd Clarke’s visual book notes for the same. I recommend both.)

Finding 15% solutions

What I’ll often do, instead, is turn to one of my favorite liberating structures, a little bauble called 15% solutions.

For me, the search for 15% solutions begins with the recognition that the biggest, thorniest problems we face are just another part of our environment. Our problems are located in the same big soup as our colleagues and peers; as people we like and people we don’t; as our organizations, affiliations, and communities; as our responsibilities, creditors, paradoxes, and best-laid plans. Furthermore, most things in this jumble are as hard to change as the built environment, even if they aren’t physical stuff that’s too big to move or profoundly meaningless boxes and arrows on a flowchart or orgchart.

But there’s always a little wiggle room. Small things you can change without getting permission, or by begging forgiveness. Things left uninstrumented or directly within your grasp. That’s the 15%.

A 15% solution is what you arrive at when you stop worrying about the intractable systems of the world as they whirl without cease under encroaching darkness, and instead identify the tiny, immediate, and maybe effective things you can do right now.

If you do this by yourself, that’s great.

If you do it with a few other people who are stuck in the same problem, that’s even better. (In fact, the amplifying effect this can yield is the point of the liberating structure.)

In other words

  1. Don’t leap at problems, or you’ll just find more problems.
  2. Don’t leap at solutions, or you’ll be a jackass.
  3. Remember to try the easiest things first.
  4. It can be pretty hard to find the easiest things.

“Problems and solutions” was originally published in the Different Chairs journal.

Why your CMS is awful, II: what do to about it

In the previous post in this series, I described the circumstances that make most content management systems for the web unwieldy and unpleasant.

It’s possible — maybe even the common case — to put a lot of work and resources into a CMS project, only to wind up with something so hostile that nobody uses it, or it becomes arcana that’s relegated to technical staff.

So let’s assume you’re starting a project incorporating a web CMS, and that you’ve chosen technology based on the capabilities of the system: it’ll do all of the things you and your constituents want it to do. Awesome! Now we’ll try to make a meaningful experience for the people you dearly hope will get into the CMS and create and share stuff that will affect the world in some way.

It’s a two-step process:

  1. have the right stuff, and
  2. work on the CMS throughout the project.

Having the right stuff

Here’s the checklist I use at Different Chairs. These items almost always come up during requirements analysis, and if they don’t, users will ask for them (typically after the money is spent). Nothing here has to do with the basic capabilities of the CMS. We’re assuming you’ve got something capable — and want to improve the odds that anyone will actually bother with it. I’ve also given implementation notes for the Django CMS, since that’s what I work with most often.

Requirement Why it matters Django CMS notes
Support for phones and tablets.

Working in a CMS seems like a “desktop task”, since the administrative user experiences are complicated and sprawling. But people will use the tools in front of them, and that’s increasingly not a laptop or computer screen. Therefore, consider a responsive design for the CMS’s admin experience. Start with making the experience possible, since it almost certainly won’t be with the default admin presentation.

No magic bullet here. Until recently, django-admin-bootstrapped supported the Django CMS and provided a decent responsive design for the admin (it doesn’t support Django 1.5 or Django CMS 2.4). A better solution is to use django-bootstrapped, which takes a similar approach but yields better markup and responsive layouts that scale more appropriately to small screens. You’ll have to override some of the CMS’s templates to get this to work, but it’s well worth the effort.

Easy ways to work on and share draft content.

Any capable CMS will have ways to view, compare, and revert to versioned content, as well as deliver an editorial workflow that satisfies bureaucracy. It’s fine for this to remain a fail-safe that not everybody cares about. But there should be a simple means for someone to create a new draft, look at it, and share it internally. It’s important to be able to work in private, at one’s own speed, and be confident in how the end product will appear and function.

  1. Create a top-level page for draft content, configured such that it’s never published.
  2. Add an item to the CMS toolbar allowing someone to create a new, draft page that’s a child of the page from the first step.
  3. Show this to everyone who will use the CMS.
Live editing.

How easy is it to fix a typo? If you have to go into the CMS, drill down to the content you were just looking at, and enter some editor, you’ve lost. Ensure that logged-in CMS contributors can make quick edits in place and you’ll be surprised by how often they do.

The CMS toolbar is a nearly perfect solution. Set up actions that satisfy common needs, even if they’re just deep links into the CMS admin. Test dynamic or interactive templates, making sure that all states are available to the CMS toolbar.

Structured content everywhere…

For lots of things (lists, addresses, event information), it’s easier to work with a well-designed, considerate form than a text area. Add as many kinds of structured data to the CMS as you can. Their data models and forms-based presentation need good validation and descriptive help and error messages.

Find or create many plugins. In addition to useful third-party plugins like djangocms-table, keep an ear out during development for opportunities to create CMS plugins to capture little bits of data, or to make it easier to syndicate or republish things from other applications.

…but always in the right context.

What kind of page are you creating or changing? What part of the page? The answers to these questions should control what kinds of content are available to work with. Make this easy to change, but come up with sensible defaults that simplify the author’s work. Available options may differ based on where someone is and what they’re doing — but they’ll always make sense.

You wouldn’t believe how often I see Django CMS projects in deployment without a CMS_PLACEHOLDER_CONF setting, which maps available plugins to placeholders and therefore to templates. Producing templates with these relationships in mind is a powerful way to help people feel comfortable and confident when using the CMS.

An appropriate rich text editor.

Two concerns: (a) Nobody likes these stupid things. (b) The most common content management tasks involve fiddling with some copy in a rich text editor. Therefore, configure the rich text editor to generate markup that you won’t regret down the road, and use one that helps authors create and style copy that integrates into the rest of your site’s presentation. A good starting point would be WYMeditor.

Use the CMS’s default of WYMEditor and configure the daylights out of it so that the available classes and elements match the site’s layout, both in the editor and in the content previews it generates. Make the exact same editor configuration available to other web applications used by the same people.

Opt-in notifications for people who want them.

People want to know what’s happening to content they’re responsible for, sometimes without inserting themselves into an editorial workflow. Provide ways to generate feed, get automated e-mails, or other notifications for changes to sections of a site they’re interested in. If it’s a migration to new CMS from some other system, wire page-not-found errors and other errors to the same notifications.

One simple approach is to write some Django signal receivers to listen in on page changes and dispatch e-mails or user-level notifications. You might also choose to create create reporting views in the CMS admin — or just show people how to satisfy their curiosity by looking at the reversion “recent changes” listings.

Don’t let tools wait until the end

When designing a content-driven site, keep the CMS in mind from the beginning of the project. As you do:

  • Research will drive basic decisions about access to, workflow for, and the purpose of content. (The people that will use the CMS are users too — so don’t forget to do user research with them.)
  • Content strategy can inform the structured content you set up in the CMS.
  • Information architecture will hint at the hierarchy and inheritance of templates.
  • During development, the people who will ultimately use the system might like the chance to see and experiment with it.
  • Analytics and instrumentation can be hooked into the CMS, so when you encounter errors you can easily move from a problem to its resolution.

If you work on the management tools while working through the purpose, intent, and content of the product itself, you’ll get more useful, coherent tools.

When you’re asking people across your team or organization to write, communicate, and inspire, you’re asking them to do something that’s never easy. Don’t let the content management system keep these folks from doing that hard work, and doing it well.

“Why your CMS is awful, II: what do to about it” was originally published in the Different Chairs journal.

Why your CMS is awful, I: capability & experience

What’s more valuable: having the capability to do something you’re interested in, or the experience of doing it without an undue amount of frustration and delay?

Seems like an abstract question, but it’s important to ask when you’re creating or selecting a content management system (CMS) for the web.

Remember the last time you used a CMS. Now, let me describe what you saw: A list of slightly different kinds of things, almost identical in appearance. An awkward mechanism for attaching images or other media to your work, involving a weird modal screen with a half-dozen fields you always ignore. An unused scheme for accessing older revisions of content. A way to work with draft content, or publish to a staging service, that’s still a little confusing after all this time. A sidebar or footer telling you that things you don’t care about are out-of-date. Oh, and somewhere, a few taps in, a wee text area, festooned with a rich text editor (itself having a stripe of about 15 icons, of which you use two or three).


The CMS nightmare I’ve described is typical of a system trying to offer the most capabilities. These systems make several claims:

  • that you can do all kinds of useful, amazing stuff;
  • that you should come to the system having already decided exactly what to write, or publish (and you’d love to type it all out into that tiny text area); and
  • that if you don’t know or remember how to use the system, it’s your own fault.

But they fail to acknowledge some important things:

  • that you, like everyone else, are stressed out by writing;
  • you’re worried about getting things to look and behave right, or that you’ll do something that undermines your message;
  • that you might have preferred to do this work from your phone or tablet; and
  • that you’d like the system to be smart enough give you reasonable defaults and let you choose only from options that make sense.

No wonder everybody hates their CMS. No wonder there are so many elaborate CMSes that go unused.


When someone, we’ll call him Joe, is motivated to go create or maintain something that requires him to go into the CMS, he’s already set about a very difficult task. Communicating with others is hard. Delivering a message is hard. Writing is hard. Encouraging readers to take some action is hard. Dealing with deviant and spammy commenters is hard. Writing a support entry about how to fix or replace a faulty hose that keeps falling out of the device is hard.

Therefore, setting about his task, Joe logs into the CMS. What does he see? A list of similar but slightly different things. A confusing sidebar. A wee text area.

Nothing here is providing a welcoming environment for Joe to do his work. There’s too much stuff, some of it never needed, most of it not needed right now. And if he completes the task that brought him into the CMS, he’ll feel that he’s succeeded despite the system, not because of it.

Which brings us back to the original question. What do people value more in a CMS: the capabilities they offer, or the experience they provide? For me, the answer’s simple. People value experience, and take capabilities for granted.

Having it all

Most open source CMSes offer a terrible experience, though they may be quite capable. They’re engineered from a one-fits-many perspective, with user interfaces that inflate or deflate based on which feature sets you’ve enabled. Introduce the dreaded plugin architecture, where little bundles of third-party functionality can be added (each dragging along their own user interfaces) and — well, you know where we end up.

Tremendous capability, hidden inside a poor experience.

For example, my favorite system for new content management projects is the Django CMS. It has a nice set of capabilities, a moderate amount of third-party applications that can extend those capabilities in the usual ways, and is otherwise easy to customize and improve. But, guess what? It’s just awful to use. The good news is that rounding off rough edges and improving a user’s experience is orders of magnitude easier than developing a modern CMS’s capabilities from scratch.

See the next post in this series for specific things a CMS should do to make it a decent environment to work in, as well as tactics for implementing those recommendations for projects that happen to incorporate the Django CMS.

“Why your CMS is awful, I: capability & experience” was originally published in the Different Chairs journal.

I’ll have a definition of “done” when I’m dead

One of the great bugbears of scrum and scrumbut systems is the Definition of Done (DoD, not to be confused with the Pentagon). Managing a product by post-hoc reporting works best when everybody on the “team” can point to a wiki page somewhere and proclaim, “My feature is done!”

Now on that wiki page, behind the cobwebs and broken links, is a bulleted list. It lists things such as: the code is written; the tests pass; the things are prepared; other things have been accepted; — or whatever else the management had everybody decide at last year’s Why The Product Is Late summit, in that classic consensus-building exercise where the manager speaks and everybody else waits, silent yet eager, for the moment of quiet assent to pass.

After a developer has checked in her work and proclaimed “my feature is done!” she is absolved. In a state of grace she drifts towards the weekend.

That’s our first definition of done. We’ll call it DoD (1).

Sometimes one might ask: what does it mean to be done with this product?

The answers come from way over there, outside of the technical group. The product is being sunsetted, repositioned, moved upmarket or downmarket. Retired, put to pasture, abandoned. Maybe frozen: the changeless, icy core around which the salesforce orbits.

If a feature can be done when it’s “done!” on Friday morning, a product can be done in the same way a puppy is done. Either it grows into something else or it just doesn’t make it. That’s DoD (2).

But what about you? Yes, you. What does it mean for you to be done? Are you done when the product is? When you have enough money to retire, or are forced into management? When you give notice? When your contract is up, and you from your labors rest? Let’s call this hairball DoD (3).

The Ann Arbor Chronicle is the newspaper in a town I once lived in. After writing for long enough to gestate an actual living human being, Dave Askins, the Chronicle’s editor, published a fascinating editorial grappling with the job. His readers compared the gig to running a marathon. But, Dave wrote:

“It’s not really clear what counts as the finish line — when I die, perhaps? The idea of attending Ann Arbor city council meetings until the day I die is a fairly sobering prospect. I’m not sure that’s what I signed up for.”

That was four years ago, but I remember it as the most acute condition of DoD (3) I’ve ever seen.

Now, I’ve used the word “done” in each of these senses, and more. It’s as slippery and unhygienic as a river otter. But here at Different Chairs, I call something “done” when it’s ready to start.

Before your product is ready to radiate out into the ether and help real people change the world in real, measurable (if tiny!) ways, it’s in development. It’s in process. But when it’s useful enough to keep somebody’s attention long enough to help them do something — guess what? — it’s done. Instead of wondering what’s the most important thing to do, or worrying about your development schedule and the tenuous ligaments holding it to reality, or the fact that time speeds up as you fall behind schedule, relax: you’re done! It’s time to watch how people use the experience you’ve created for them, and learn from their mistakes and yours, and improve the experience in worthwhile and surprising ways.

That is to say: once you’re done, you can really get started.

“I’ll have a definition of ‘done’ when I’m dead” was originally published in the Different Chairs journal.

Three stories about ants

Here are three stories about ants. The first two are from brilliant people and were both originally published in 01968 (oddly); the third is from me, today.

As behaving systems

Herb Simon’s “The Psychology of Thinking” opens with a little ditty about an ant, picking its way across a wind-swept beach. The ant’s path is weaving, irregular, non-geometric. Where is the ant going?

Old ‘Uncle’ Simon sketches the ant’s path and shows the sketch to a friend, who sees in its jagged course a skier’s slalom, a dodgy sloop, or (abstractly) a student working out a problem.

But it was just an ant crawling the beach, not doing anything complicated. It encountered a problem, it changed course, it moved along. Simon writes:

“An ant, viewed as a behaving system, is quite simple. The apparent complexity of its behavior over time is largely a reflection of the complexity of the environment in which it finds itself.”

For the balance of the essay, he explores that hypothesis, but with the word “human being” replacing “ant”. Human beings have these basic characteristics: We remember a little bit. We forget almost everything. We do one thing at a time, mostly, and slowly. And from this you can explain a lot of behavior.

As creatures doing their best

Near the beginning of Stanislaw Lem’s awesome novel “His Master’s Voice”, our narrator finds himself as part of a team of scientists tasked with making sense of a deep space transmission, a signal (message?) from way out there. (I’ve heard “His Master’s Voice” described as Carl Sagan’s “Contact” for adults.) He describes the task thus:

“We stood at the feet of a gigantic find, as unprepared, but also as sure of ourselves, as we could possibly be. We clambered up on it from every side, quickly, hungrily, and cleverly, with our time-honored skill, like ants. I was one of them. This is the story of an ant.”

Because, of course, “ants that encounter in their path a dead philosopher may make good use of him.”

It’s probably not much of a surprise to know that Lem’s ants eat well, but they don’t really learn anything.

This story ends with a nagging question: for the ant, this is no great loss, is it?

As people grubbing at iPads

You want to make a compelling experience for people. Maybe you want them to do something, or buy something, or learn something. You can see the whole happy path. They’ll come in here, and work their way over there, and everybody gets what they want.

And then you let people into your system and things fall apart immediately. People are using the wrong device. They can’t hear your video on the train, or at all. They signed up but don’t remember where. They don’t get your e-mail. The commercial break ends, a drink spills, or (let’s hope not!) the traffic light turns green. These individuals have fallen off the happy path.

If a task has two steps, some people will fail to make it to the next step. If a task has one step, some people will fail to even begin. Some people will complete the task, forget they’ve done so, and start it again.

But that’s all fine. Because, when you start to design an experience, and as you’re developing it, and as you watch and change it over time, you aren’t just thinking about that happy path — the perfect, meaningful interaction you imagine people having in a comfortable seat and in good lighting.

Certainly you start with that happy path, by defining what should happen in an ideal scenario. But you’ll surround and buttress that path through designs that can recover from failures, mistakes, and interruptions.

To create a great experience, you must put together an environment, not just an interaction. And when somebody crawls off the path, you’ll have put something there to help them wiggle their little feelers and find their way back on.

“Three stories about ants” was originally published in the Different Chairs journal.