This is a response to a comment on a previous article: “Yeah, why can’t the software do what I want it to do, rather than what I tell it to do….”

<sigh>

This is one of those cases where I get mad that computer communication doesn’t carry vocal inflection. If you’re being serious, then you truly understand what my gripe is. If you’re being sarcastic, it’s exactly that attitude that is the problem.

The user should not have to adapt to the software. The software should adapt to the user. The user pays to use software in order to gain productivity. The software designer is not paying the user. If your software is not easy to use, the customer can always go get someone else’s software. If the user experiences any pain while using your software, whether through your poor design or their own ignorance or incompetance, someone else will be more than happy to write software that helps that user and take their money away from you.

I recommend that anyone who writes software that interacts with humans try using Perl for a few months. The whole language has “does what you mean, not what you say” as an explicit design goal. As a result, it is one of the most pleasurable languages to work in that I have ever used. The language itself vitually never gets in your way. It is such an incredible world of difference. .Net languages, Java, and other langauges I have worked with (recently) have only been able to keep up with Perl in terms of the ability to rapidly develop software because they have such gigantic libraries. As languages in and of themselves, they are lightyears behind.

Why am I mentioning all of this here?

Because of the concept of “gee, well you’re the one who clicked on the wrong thing.” Wrong. Unless the user makes an accident, such as a typo or a mis-click, the user has always done precisely what they thought would accomplish their goal. ALWAYS. To beleive otherwise is designer hubris, an attitude that needs to be eradicated from your thinking if you ever want to be a great (or even good, let alone employed) programmer, engineer, or any other designer.

Here’s an example: propositions on ballots. If you have ever lived in a state that does these, you know exactly what I am talking about. You are presented with one to five paragraphs of dense legal text, and end the end, asked to vote “yes” or “no”. Here in South Carolina, a proposition barely passed that was heavily demanded. Exit polls indicated that it had won overwhelmingly. What happened? A significant number of portion of voters simply did not understand which of the two choices they were presented with would actually vote for the proposition. I know that I re-read it three or four times, and still was not sure if “Yes” would vote for the end result that I knew I wanted. Post election polls that asked what choice people made, and compared it to what result they wanted showed this. The ballot was poorly designed.

Software is all too often designed by people who have this designer’s hubris. If your software reacted badly to a user’s input, it is because you failed to perform proper error handling. More importantly, you failed to comprehend your user’s needs. Web forms are notorious for this; instead of anticipating that a user may put dashed or spaces (or no delimiters at all) into a credit card or phone number entry field, and stripping out non-numerics, then trying to process the card, they limit the user’s input. The user doesn’t find out that the field is limited to 16 digits, then they need to go back, remove the dashes or spaces, then finish entering the credit card number. Frustrating! Just make the field bigger! More importantly, those dashes/spaces help the user ensure that the numbers were put in correctly. It takes but one line of code to strip the junk characters out and reformat that credit card number (in Perl; other languages need a zillion lines to make and use a regex object…). Either way, five minutes of programming will make your users happier and provide you with more accurate data input.

Instead, we get websites that kick you back with an error message (often hard to find the error message on the screen, to make it worse). That’s designer hubris in action.

Let’s review some of the comments the previous article received to see some of this designer hubris in action:

“I know it’s not much consolation when you have to use specific proprietary applications for work, but you might try using more open source software. For the most part, open source software is developed by people who want to use it, not by people who are just being paid to produce something for others.” – apotheon

Sadly, much (if not most) open source software has even worse user interface design than proprietary/commercial code. All too often, the answer to even a simple item is in the manual, not the interface. A user should never have to read the manual for anything but the most complex tasks. How to accomplish simple, day-to-day tasks should be intuitive and easy. Too often, I have found using open source software to be like using a website where many of the pages aren’t linked to, but need to URL typed in manually.

“You have to figure out how to copy correctly, because like everything in life, if you don’t do it correctly it won’t work, pretty obvious really. This idea that somehow the system should figure out what you’re trying to do and how is ridiculous.” – gbently

Wrong answer. When someone has table data in the clipboard, and is pasting into a table object, it is fairly obvious that the user is trying to populate the table with data, not an individual cell. If the program is in doubt, it should simply ask “what are you trying to accomplish, how can I help that to occur?”

“IMHO Visual Studio is for programming, not database manipulation.” – dancoo

I agree 100%. To load the data into MySQL, I used the LOAD DATA statement. If I wanted it to go into SQL Server 2000, I would have (probably) used the Import Wizard. If I wanted it in Oracle, I would have used sqlldr.exe. But I wanted it in SQL Server 2005 Express, which has no management tools that I could find. I followed the directions in the help system. They said to use copy/paste. The database tools in Visual Studio aren’t so hot. But they are still better than nothing, much of the time, and in the case of SQL Server 2005 Express, they seem to be the only thing going.

“LMFAO an even better question is why don’t you use php5 or python or something like that where YOU CAN ACTUALLY PROGRAM YOUR OWN ERROR MESSAGES! OMGZ! and use it fast and learn it easy.” – mindilator

Wow, this one had me laughing. I am not quite sure how me using Visual Studio compares to me using PHP or Python. The last I checked, I was trying to load data into a database; what language I was writing my software in is 100% irrelevant. Even if it was relevant, this poster makes a really stupid assumption: that I had much of a choice in my language. This person is obviously trying to make me look stupid, saying that I am too stupid to use PHP or Python, and that I’m a fool for using Visual Studio. What if I told this user that I was using IronPython for Visual studio, or Perl.Net? Would that make them happy? Probably not. It also shows this person’s ignorance. Visual Studio does a lot more than write web applications. In this case, I am writing a desktop application. This is why I was using SQL Server 2005 Express in the first place. PHP and Python aren’t too much help when writing a Windows desktop application!

“just stop blaming others for not building an IDE that reads your mind.” – mindilator

This is actually one of the things that a good IDE does. A good IDE, for example, when debugging, doesn’t just say that an exception occurred; it shows me the error. That’s a form of mind reading, it knows that I want to see the error that occured. More to the point, I was simply following the instructions. My intial thought was to find either an import wizard or an import utility. The documentation did not mention either of those. Most importantly, a well designed system does exactly what I need it to do. If I need to treat my computer like a newborn puppy, I might as well give up now.

“i could easily moan that his lack of comments wasted two days of figuring out what implements what, but that’s just the breaks.” – mindilator

Not only could you, you should be concerned about his lack of comments. You wasted two days of your time working with his system. If he had spent a few hours writing some basic documentation, you would have saved a lot of time. Furthermore, what if he had chnaged the function of a parameter, but not the name? Without that documentation, you would need to inspect his code line by line to see what each parameter is sued for. Additionally, the process of writing comments serves as a code review. Many times, it is during the comment-writing phase when it becomes obvious how to streamline architechture, add in additional functionality, and so forth. Good and great programmers write comments. Bad and average programmers don’t. I’m not saying that writing comments is enjoyable; it really isn’t. But the lack of comments is disturbing, particularly if he was aware that this was code that other people would be working with.

“you really want a job that’s 75% pen and paper? what’s the other 25%, using an abacus?” – mindilator

I’m actually glad you mentioned the abacus. Many abacus users are significantly faster at performing math than many computer users. What does that tell you? Yes, I want a pen and paper job. When I am programming, I spend about 50% of my time not writing code, if not more. I spend a good portion of time performing planning on paper. I spend time talking to my customer or end user determining their needs. I spend time sketching potential screenshots and showing them to others for critque and input. By the time I’m actually sitting down and writing code, it is a fairly quick and trivial process. It doesn’t take much time to write the code itself, and debugging is typically fairly quick as well, assuiming I have access to a quality debugger. Things like breakpoints and watches (vs. “print ‘Executing line 678, the value of sFileName is ‘ . sFileName;”) cut debugging time by about 75%, and often help you find problems before they even occur, because you get to watch the logic you wrote in action.

The point is, the user does not pucnh themself in the head. A user who “clicked the wrong button” and wiped out their data is the victim of a bad interface design, not an idiot. Users don’t say to themselves, “gee, I want to wipe my hard drive”, they do these things because the design stunk. It is my beleive that user interface stinks, because many programmers simply do not pay close attention to the needs of their users, do not test with real-life users, and have a bad attitude towards users. It’s time the designers started paying better attention. Look at Google. Google went from a nobody to a market giant, by simply helping the user accomplish their goals (searching the Web for data) better than anyone else. They did this by providing a significantly better user interface, and by taking the time to write a better search algorithm. They identified the user’s need, and wrote software that met that need while simultaneously working the way the customer needed it to, instead of making the user work the way the software did.

J.Ja