March 21, 2007
I've seen a lot of painfully bad IT web comics in my day, but I'm happy to say that Bug Bash, by Hans Bjordahl, is not one of them.
This particular strip is one of my favorites because it hits so close to home. Software developers truly believe, in their heart of hearts, that they are typical users. Be sure to check out the sequel strip, How Good Software Goes Bad, Part II, and while you're at it, the rest of the bug bash archives.
Posted by Jeff Atwood
The thinking you're a typical user is part of a general situation that everyone has where they think their experience and ideas about the world.
Robert: Actually, I assume I'm a non-standard user in all things I do. I think that what there are are various degrees of "novice" "intermediate" and "advanced" that range from "never touched a computer" to "sleeps with one or more computers". None of them could really be considered a "standard" user, but trying to aim for the middle of that pack misses out on the two extremes. Frankly, I firmly believe that all software that aims for a "large" audience should have Lite, Standard and Expert versions. Some people just don't need all that functionality... and some simply cannot get by without it...
Warning: "on the other hand" rant ahead.
It's true that we developers are not typical users, but we *are*
users, and we have our needs. Frankly, I don't know what's worse:
to give a casual user software designed for experts, or to give
an expert software designed for casual users? At least the former
kind forces the newbie to learn a little more about his/her own
problem domain. The latter, on the other hand, is invariably
condescending and second-guessing, which always works out badly.
Just a point of view.
xkcd: A webcomic of romance,
sarcasm, math, and language.
Best comic I've /ever/ seen.
"It's true that we developers are not typical users, but we *are*
users, and we have our needs."
I think the point of this comic is not to say that developers are not users, but to say design to your actual user community. This problem is not just a developer issue but goes for PMM (Project Micro-Management) team that feels that they some how know what the grunts need and do to make the rocketship go.
In most cases even users do not know what they want, but they will tell you what they don't. So as a developer, Project manager, systems analyst, etc. it is best play the part of slow and stupid.
Thanks Jeff, I had a lot of fun of that Bug Bash :-)
I was going to do a techie comic called ".duh", but then I decided that I was going to find limited appeal simply because the jokes were either too deep or too simple. Oh well. Funny stuff, Jeff. I'll recheck this tonight when I'm home and can bookmark.
I would disagree with the "we are users" statement. Meaning no disrespect but how often do you use the actual software that you develop for a customer? I can't remember ever sitting down to a day to day job where I use the software I wrote. For the most part, I only know enough about a "typical user" and how they do there work to get a module or class written.
Software design and quality is held in the eyes of the typical, day-to-day user that has to stare at the software we write. Whether we think it is of high quality is irrelevant; if the day-to-day user thinks it sucks it sucks. We should not design software that implies a level of knowledge outside of that users scope, nor should we try to educate the user. We should try to design software that meets their needs, no more and no less.
My two cents anyway. Love the posts Jeff.
Meaning no disrespect but how often do you use the actual software that you develop for a customer?
Well... i'd say that's a pretty big problem problem. One of my ongoing rants has been about the clammy feeling i get from using certain apps that don't seem to have had anyone working on them who actually used them.
Example: a certain web browser that for *years* would refuse to open a certain "special" folder, even though it'd just saved your downloads to that location. No user in their right mind would spend the extra time coding up an annoyance like that - or put up with it once someone else had. But a developer blindly following spec might, and that's a shame.
I was *really* hoping that "painfully bad IT web comics" would link to user friendly. Thanks for not letting me down.
I'll second the recommendation for xkcd. It's absolutely brilliant.
(Don't forget to check out the ALT text... it's like two comics in one!)
Frankly, I don't know what's worse: to give a casual user software designed for experts, or to give an expert software designed for casual users?
If an expert uses "casual user" software, he may be frustrated by the level of control he doesn't have but he'll get the job done. If a casual user has to face "expert" software, he'll grow to hate computers and the people who design software for them. Not everyone wants to be an expert: Some users just want to push the damn button and go to the second floor.
On the other hand, I get paid to teach casual users where the "damn button" is, so it may not be in my financial interest for developers to learn this lesson.
forces the newbie to learn a little more about his/her own
The user's "problem domain" might be something like budget analysis or creating mailing labels. Or maybe just checking email or browsing the Web. IOW, most users have a "Job 1" that they're using software in order to accomplish. Learning software in that case is Job 2, or for most people, Job Last. *Forcing* people to learn how software works in order for them to do something useful is, as Jeff occasionally likes to call it, insane.
Loved the comics. Nice diversion.
I'm sure there are a lot of angles to look at the "design by developers" story from though. I just lived through one myself:
"Just dump the data in a grid with minimal intepretation. It will fit nicely on one screen, we're all familiar with the meaning behind the raw status codes. We'll have you come back and pretty it up in Version 2."
"Nobody knows what any of this means. We just never check the status of the mesh network anymore. The Help Desk kids can handle it, we fired all of the Operations people. We just have a guy who reports alarms to the vendor."
"Whew! Glad somebody can read these 'tea leaves.' Been down for three days and we had no idea what was wrong."
"Vendor TLA re-engineered the system. The global status is displayed as a nice cube we can rotate, slice through, and everything is reported in nice shades of green through red. Finally we have something useful! Oh, we've been down three days, and don't know where the problem is."
"Nobody knows how any of it works, that legacy network is a mystery but our core business depends on it. We've learned to wait out any outages, they usually correct themselves within a week or two. What? We're back up?"
"Hey, where'd you get that node status report thing? Yeah, it does say port three of the Ohio West router is unresponsive. Is that what that brownish streak running through Slices 13 and 14 of the MeshCube means? We'll get the vendor on it. Nobody here knows that exotic network stuff, we outsourced it all. I'm off to a Project Management meeting right now though, we can take care of it tomorrow. Crummy software anyway. Hey! What'd you do? The brown streak disappeared."
Sadly, too many see it as an xor proposition. Software done well allows huge amounts of customization and easy access to that customization, but provides sensible defaults so that you don't have to configure or specify things that you don't want to.
I once had a discussion with a coworker about how primitive and ill-conceived integrated development environments and programming languages are. When I started to offer up ideas for what might be improved, he backed away furiously, and asked "so what if I want to write code through *this*", pointing to his blackberry.
Sadly, this is the kind of riposte that will be met with cheers from many programmers. Perhaps even people like Eric Schmidt and Bill Gates would agree with him.
Referencing the first comment up there, I must say that using the Enter key for something other than marking a new paragraph is *lame*. :)
I like the comics very much though. :)
haha, I clicked on Jeff's link to part two, read it, and then clicked on the archive link from that page.
And look what I got:
"Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, firstname.lastname@example.org and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request."
I especially love the part about "anything you might have done" to cause the error. Sure, blame me, pal!
Guess I should:
- take the blame
- email the admin, and
- check the server log
Sure, I'll get right on that!
Wow. I've been away for the week-end and a lot of people responded to my comments. Rest assured that I do use the software I write, and if I don't, one of my coworkers does. Or even my boss. So I'm very close to some of my users :-)
As for what lies within one's problem domain, I think a doctor shouldn't have to learn, say, SQL to get reports out of his patient database. But someone who wants to surf the Web would better learn what a URL is, where to type it (address bar, anyone?) and the meaning of the simple words "Page Not Found". I mean, how much more can we dumb down computers? There's a limit to everything.
Maybe Jae is on to something here, though...
@bhamdeveloper said how often do you use the actual software that you develop for a customer?
How very sad for you. Do try it some day: the experience of writing for yourself is amazing. Suddenly there is no friction between the forces of I wanna write cool code and I want working software. The best and the good may be enemies, but now they are on a level playing field. Balance is quickly found.
My experience was writing a debugger. I used it to debug itself, every day. I got immediate feedback on whether my changes made sense.
RE: typical users vs. developers and UI design
I have learned that you can't design user interaction correctly up front, just like you can't design your object model correctly up front. Until you see it in action, you won't know what's broken. That means that programmers have a critical roll to play in user interface design.
It took me long time, but I now realize that I want *simple* software. I am a geek and I like control, but that's no excuse for making me work hard to use your software. Microsft Office is a great example: old Office had hugely deep menus that I would get lost in (bad for everyone); new Office has a ribbon bar that works well for any level of sophistication or geek interest. Chrome is a great browser interface. Vista's complexity is much worse than Windows XP. These things aren't dependent on whether your a futuristic superman or a first-time computer user.