We shall simply explain.
Wednesday, July 16th, 2008
From time to time I get asked to beta-test new versions of software, and of course there’s just the common experience of taking a new online service out for a spin. That’s when I’ll discover something, not necessarily something you’d label a “bug,” not really a “feature,” but a way the thing works that just doesn’t work for me, the real-world user.
I figure if I mention it to the developer, and explain what I was trying to do and why this is frustrating to me, I not only help myself to get an application or web service that works better down the road, but I’m making the lives of everyone else who uses the software easier as well. This might not always be the case—I’m not always Joe Everyman when it comes to how I use my computer—but I try to raise my hand and point out what I see as a problem, as opposed to grumbling to myself or to folks who have no influence on how the product actually works.
It’s amazing how many times in the Mac community this really works well…they appreciate the observation, they’re motivated to make stuff that sets new standards in user interface, they get it.
But lately, I’ve come up a bit against an attitude from software developers that calls to mind an experience when I was doing graphic design for a new twenty-four hour news channel in Austin…which was using some custom software for newsroom automation that was so unfinished at the point of purchase that it required a large team of developers from Germany to come out and live onsite for what seemed like weeks, months.
And at one point as we were trying to make this software work, we came up against a huge slowdown at the very start of the process…when a user dashing to a workstation in a newsroom, under deadline pressure, would log in and enter his or her password, the system would seemingly stop and wait upwards of 30 seconds until the login was accepted.
30 seconds is an eternity in newsroom terms. When this fact was presented to the developers (“hey, this might be a concern”), the unconcerned development lead said officiously—a quote I will always remember—”well, we shall simply explain [to everyone] why it must be this way.”
Um, yeah, that will help.
After the head of the local news group simply explained how quickly they could be sent packing, the software guys tackled the bug with extreme priority, and darned if they didn’t get the login time down to one second.
But that “we shall simply explain” attitude, well, I’m butting up against it in a couple of places lately. (And there’s its governmental cousin, popular in the Bush administration: “People just have to understand that…” —but that’s another story, another annoyance.)
There’s an otherwise great FTP/SFTP client—Cyberduck—which came out with a major revision that took away a key piece of functionality—having all the sites available in a drawer off to the side of the window, always there with one click. When I (and a handful of others) pointed out that this effectively hobbled our workflow, requiring multiple clicks to get where we used to take one. The change also eliminated the ability to just glance off to the side—no clicks, just eye movement—and get valuable information.
Well, the developer wanted to simply explain why it must be that way. Since the initial posting on the forum that tracks bugs and development changes, dozens of people have chimed in to say “we like the old version better.”
This is also the case in the latest release of the otherwise amazing and wonderful Google Earth. They’ve changed the way the navigation works “for the better,” according to all their PR online. According to post after post in the Google support groups, it’s not better, it’s more cumbersome for most users. And the Google Earth support folk “simply explained” that much of the old functionality is there if you hold down the shift key when you click. OK, fine, but that means you can’t just fly it with the mouse..you have to grab the keyboard (if, like me, you’re leaning back in your chair) for one keystroke in a sea of mouse-manipulation. Why!? Why??? Well, they simply explained it was “better” this way.
There’s an even more egregious example—actually several of them—on a product I am under an NDA not to discuss, so I won’t, except to say that like the first example, users who upgrade will find fundamental components of their workflow hobbled in the name of progress. And this app has a LOT of users, cross-platform. It’s big. Huge. Uh-oh.
I think there’s one basic precept all developers should hold dear. If they make a change “for the better,” and they immediately get even a dozen complaints saying “the old way was better,” they are obligated to step out of their own reality distortion field (because, of course, if you’re a developer, you can’t help but be excited by the new features you’ve labored to produce) and see what all the grumbling is about. And then, if there’s a glimmer that they might have broken more than they may have “fixed,” have the courage to roll the behavior back, or provide (at the very least) an option for longtime users to customize back to the old behavior.
Hey, I’m simply explaining.
