Global Moxie

Photo by SeenyaRita

“Good fences make good neighbors,” Robert Frost tells us, perhaps explaining why one of Big Medium’s most-requested features is the ability to limit editors to specific sections of a site. Let Jane tend to Jane’s area and Harry to his, but don’t let them stray from their respective domains.

Today’s “Picket Fences” beta update for Big Medium 2 adds exactly that feature, allowing webmasters and administrators to fence off content areas and restrict editors to specific site sections.

These new section-specific privileges will no doubt find application in a variety of sites, particularly in large or distributed organizations. Teachers can have their own mini-sites within a school site. Youth-group kids can publish content to their own area of a church site. Bloggers in a blog-network site can have ownership of their own site sections. Meanwhile, site administrators can choose to allow other accounts into these areas or wave them off.

This is one of the relatively rare cases where I think it’s good and sensible to impose editing restrictions on Big Medium accounts. More thoughts about that in a second; first, let’s have a look at the feature itself.

The interface

Listing of an account's site privileges. Click to enlarge.

I’m pleased with how the visual design turned out for this feature. It could have easily gotten unwieldy for Big Medium systems with a large number of sites, each with lots of content categories and subcategories. I fretted over how to make it simple and elegant.

In the end, I chose to add the new privilege controls to Big Medium’s account edit screen. There, webmasters and administrators can add, review or cancel the site privileges for an individual account. Clicking “customize” for a site pops up a form where you can choose the sections to allow the account to edit.

Customizing section-specific privileges. Click to enlarge.

All in all, I think it’s an easy little interface for a complex set of tasks on the server. I hope you like it, too.

Constructing all these fences, though, got me thinking about whether fences do indeed make good neighbors and when other means might be more productive.

Don’t fence me in

When you step back from it, it’s kinda remarkable how many Big Medium feature requests are aimed at preventing people from doing this or that. Limit the number of images they can add to a page. Don’t let them change the link sort order. Keep their links off the homepage. Don’t let them edit this or that section of the site. (Based on the volume of this type of request, I could probably keep myself busy for several weeks by just adding new locks, fences and restrictions without ever adding features that let you actually do something.)

These are, I’m sure, entirely reasonable editorial policies, but I’m not convinced that they always require technical solutions within the software itself. As a developer, I’m much more inclined to focus my efforts on allowing people to make contributions than to prevent them from doing so.

Locked doors have their uses, no doubt about it. You can’t have just anybody posting anything just anywhere. Adding technical fences to mark broad property lines within a website’s content collection is a sensible thing to do, for example. Today’s new feature makes the cut.

But throwing up technical barriers isn’t always the answer. In particular, I think that fine-grained policy details are often better handled by non-technical solutions. Don’t want editors to add more than two images per page? Don’t want them to change the priority field on pages? Here’s a gentle suggestion: Just ask them not to.

Words work, too

Communication, after all, is how we collaborate offline. It’s how flesh-and-blood projects are managed. And simple words tends to be warmer and kinder than technological handcuffs.

Our poet friend Robert Frost appears to agree. In the very same “good fences make good neighbors” poem, he writes:

Before I built a wall I’d ask to know
What I was walling in or walling out,
And to whom I was like to give offence.
Something there is that doesn’t love a wall,
That wants it down.

Add too many walls, and you foster an atmosphere of distrust. After all, Big Medium is designed to be a collaborative tool for building sites with trusted colleagues. Accounts are available only to those whom you actually want to contribute. Big Medium provides a basic set of permissions — a minimum set of locks and fences — but it’s intended to be used in an atmosphere of trust.

In that atmosphere, plainspoken communication and old-fashioned management is at least as effective as a lock-and-key approach, probably much more. I’m reminded of what technologist Tim Bray recently told ComputerWorld:

If you think you need filtering technologies to be sure your employees aren’t damaging your reputation, that’s a management problem, not a technology one. If employees can’t be trusted, technology is the least of your problems.

In fact, trying to enforce too much policy via software solutions can actually make technology a problem. Adding lots of permission options would inevitably make Big Medium more complicated to use and, to be sure, more complicated to develop and maintain for your humble developer.

Just to be clear here, I’m not uniformly against adding new permission options. Today’s addition of section-specific privileges is an example of that. But I think software-based permissions are often a crutch, and my general inclination is to leave them out of Big Medium except in numbingly obvious circumstances.

Like the man said: “Before I built a wall, I’d ask to know what I was walling in or walling out.”

Tags: bigmedium, business, cms, collaboration, customerservice, programming, simplicity, workflow