This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/03/a-race-of-futuristic-supermen.html
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.
Excuse the follow-up, but I couldn’t miss this opportunity:
xkcd: A webcomic of romance,
sarcasm, math, and language.
Best comic I’ve /ever/ seen.
Perhaps the last frame from the latest comic is more relevant here:
“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.