Not Thinking Out of the Box

This is kind of a continuation of the content management stuff I’ve been writing about. It pertains to software in general though. In our case the problems were with the content management software, but anytime you’re developing something based on a commercially-available platform, this issue comes into play.

It’s silly, but in our rush to bend our content management system to do what we wanted, we neglected to really explore what it already did. That is, we didn’t familiarize ourselves with the “out of the box functionality*” that we were getting.

My main excuse is, of course, the familiar and painfully true: WE DON’T KNOW HOW TO DO THIS. Once again, it would have been nice if our vendor had helped us out a bit more.

One of our team members raised the warning during a UI review-type thing where the vendor showed us an interminable presentation depicting in stunning wireframes the UI representation of each use case. So basically, “if you want to do XYZ, click this button and choose this menu item.” Oh, yes, it’s just as exciting as you’re imagining right now. And did I mention it was in PowerPoint, and we were projecting the slides in a dark room? Probably right after lunch?

Our team member, who wasn’t dazzled by the 2-d renderings, asked a simple question along the lines of “what do all those grayed-out menu items do?” You’d think she’d hurled a molotov cocktail at the presenter’s head based on the reaction. The presenter, the other reps from the vendor, and our own corporate project manager all basically told her “don’t worry about it” but used more and louder words with wavy hand and arm gestures.

Undaunted, she pressed on, asking something like “but don’t we need to know everything this does before we can tell you what we don’t want?” Again, the arm waving and near-apoplexy with the general message of “we’ve already figured that out for you based on your requirements.”

Oh, my. It pains me to recount this ugly incident. And, like cowards throughout history, I went along with the loud majority, in this case our vendor. Because of course they have our best interests in mind, and they’re the experts, and they’ve assured us that this really is the way we want to go. And the second payment is due next Friday.

My colleague let it go, but with a “you guys are wrong and this is going to come back to hurt you” look that haunts me to this day.

Obviously, she was right. Months, and even years, later, we’d come across something that didn’t quite do what we wanted, or we’d have a new requirement pop up. We’d ask our (completely different) experts how to make it happen. And imagine our anguish when they told us “this is already supposed to be in there.” And the absolutely devastating “in fact, somebody had to do a really complex workaround to shut off this core functionality.” And the humiliating “why did you want them to do that?”

The lesson should be obvious: if you’re using commercially-available software as part of your publishing solution, you’d better have a REALLY good reason to disable features and functions that are already available. I mean, come on. What were we thinking?

(* And may I just say how much I detest the word “functionality**”. But even more, the fact that after being bombardized by it for so long I end up engaging in its utilization because it provides optimal expressionality for my core meaningness? This instantiates my angrificity, which renders me beyond uncomfortabilitated.)

(** I did, though, enjoy titling a user guide “Utilizing the Functionality!” The exclamation point means fun!)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: