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.
July 28th, 2008 at 11:55 pm
You wants me to call up some software developer heads and tell them how quickly they can be sent packing? To Germany perhaps?
It won’t be my first time…
July 29th, 2008 at 11:02 am
I’m part of the same ‘secret’ group. It’s quite apparent to me that the features that customers need and want was decided long ago in a conference room meeting that did not include anybody that actually uses the product for a living.
All they want now is bug testing, not comments on the usability, neccesity, or ‘would be nice to have’ features.
The bathrooms there (ivory tower) don’t need ventlators because obviously their s**t doesn’t stink.
July 29th, 2008 at 5:49 pm
This should be two posts. I fully agree on part of this post (the part about important annoyances – like 30 seconds+ for login). I fully disagree on the second part (feature change -> whining -> changing back).
In my opinion people are damn lazy. Sometimes they are just too lazy to re-learn something even if it’s for the better in the long run.
As an example i would like to present Windows Vista. People complain they can’t find this or that function. This is due to the error of searching in the old, familiar place. The old and familiar place may not have been the best place to put the function (or maybe the label on that function might have been hard to understand) so it gets changed. People complain it’s more complicated while it is in fact easier – they’re just not yet used to it.
If you only listen to the people wanting their old functions back, there will be no noteworthy development in software.
I am just saying that sometimes you have to do something against everybody else’s opinion to make a change for the better.
October 27th, 2008 at 3:41 am
Ohhh. Dont get me started.
Change for the sake of change. Claudius; there is nothing lazy about not wanting to change the way things were/are done. If the new is always easier, why was it not put that way in the first place? The fact of the matter is that changing things (in the most case) is so that on-going training, books and other money-generating angles can be exercised. Don’t be sucked onto “the greater good ” b.s. No company would invest in changing things that work really well just to “refine”, if that change will cause the majority of their customer base to dislike it, unless there was some other reason… Money perhaps??