Linked by Eugenia Loli on Thu 27th Dec 2007 05:37 UTC, submitted by Esther Schindler
Graphics, User Interfaces "It's hateful when a developer takes a 'shortcut' that saves that individual a couple of minutes, but thereafter causes extra effort from every single user. Awful as they are, these application design errors - all the fault of lazy developers - are entirely too common."
Order by: Score:
Interesting article
by TLZ_ on Thu 27th Dec 2007 07:38 UTC
TLZ_
Member since:
2007-02-05

Interesting article, good things to keep in mind when designing stuff.

In general I really appriciate OSnews' GUI-articles, I keep finding much good stuff in this field on OSnews.
Thank you. ;)

Reply Score: 3

RE: Interesting article
by Joe User on Thu 27th Dec 2007 12:20 UTC in reply to "Interesting article"
Joe User Member since:
2005-06-29

I like these usability articles too. Usability mistakes are so annoying at times. The worst usability mistake I have found so far is when you take 5 minutes to fill out a registration form, you submit it, get an error message saying that field #17 is mandatory and...You're redirected to a blank form again!!! Yeah!!!

Reply Score: 1

In short
by dwave on Thu 27th Dec 2007 07:44 UTC
dwave
Member since:
2006-09-19

Spare yourself a lot of irrelevant blah-blah. In short:
1.) unsanitized user input
2.) repetitive GUI operations
3.) misleading error messages

Reply Score: 16

RE: In short
by RIchard James13 on Thu 27th Dec 2007 10:14 UTC in reply to "In short"
RIchard James13 Member since:
2007-10-26

1) unsanitized user input

Her example of this is inputting say a telephone number into a form. The user enters a string like +61 (07) 46 999-999 and the program says there is a problem. Realistically it should just remove all the non-numeric stuff and count the number of digits.

+61 (07) 46 999-999 == 610746999999 (12 digits)

Why make the user guess the input format? I remember reading about this back in the 1980's but still programmers don't do it right.

Reply Score: 4

RE: In short
by Fergy on Thu 27th Dec 2007 11:16 UTC in reply to "In short"
Fergy Member since:
2006-04-10

I wish OSnews would write "in short" for every article instead of quoting from the article.

Reply Score: 4

I would add
by renox on Thu 27th Dec 2007 09:26 UTC
renox
Member since:
2005-07-06

HTML lack of units representation as a big 'usability sin'.

As a foreigner, it's quite annoying reading about inch, pound, miles and other weird units that I don't know..

Sure I can convert these manually, but it's a pain: there should be a way to declare those units in HTML and I would view the result in sane metric units..

Reply Score: 10

RE: I would add
by Spellcheck on Thu 27th Dec 2007 09:36 UTC in reply to "I would add"
Spellcheck Member since:
2007-01-20

HTML is expressive enough to do this, but don't blame authors for your quantity monoculture (you don't have the right to not be offended or confused).

For example, you could use the dfn element (just like it's used now for defining terms and abbreviations, often in combination with abbr, etc) and fill one or more attributes (or use the cite element) with links to documentation or unique identifiers for the unit in terms of standards documentation. In fact, this would make a create microformat, if it doesn't already exist.

The problem is that in modern literature, if units are actually an issue, then the author usually provides conversions or clarifying footnotes. It's just not important.

Reply Score: 1

RE[2]: I would add
by Fergy on Thu 27th Dec 2007 11:20 UTC in reply to "RE: I would add"
Fergy Member since:
2006-04-10

What you call a monoculture is what other people call standards. If you are writing for an international audience you should use international measurements. And yes I do mean the metric system.

Reply Score: 11

RE[3]: I would add
by mojojojo on Thu 27th Dec 2007 15:00 UTC in reply to "RE[2]: I would add"
mojojojo Member since:
2007-11-20

No offense, but I find no evidence on the CIO website that they are writing for an international audience. The form for free subscriptions is US-only, etc. Interested foreigners can pay, but it's clear that CIO sees them as a "bonus" audience and not their main audience.

Perhaps you should just take up the habit of immediately leaving any website that uses feet, pounds, and miles - you are not the intended audience for those sites. Or are you saying that anything posted to the internet should use *your* preferred units, even if the author and the intended audience won't understand those units?

I have some news for you - 30 years and counting of international pressure on the US to adopt the metric system isn't going to finally succeed because of your whinging about it on OSNews.

Reply Score: 3

RE[4]: I would add
by renox on Fri 28th Dec 2007 00:11 UTC in reply to "RE[3]: I would add"
renox Member since:
2005-07-06

Instead of making a fool of yourself you should reread what I suggested: a way to keep using non-standard units but having them transparently converted for other users..

Reply Score: 1

RE[5]: I would add
by mojojojo on Sat 29th Dec 2007 17:19 UTC in reply to "RE[3]: I would add"
mojojojo Member since:
2007-11-20

I understood that, but tagging to support this automatic conversion sounds like a hassle. Why bother? Where do you propose to draw the line in the demand for such things? With a demand that it handle local spellings, so I don't have to figure out what "digitised colour" might mean and you can live in ignorance of the orthographic abominations considered standard in communities other than your own? Automatic localization of the word "football"? Conversion of "lorry" and "lift" to and from "truck" and "elevator"?

In my dialect of English, we have a second person plural pronoun. This is an improvement to the language and I insist that everyone tag their use of "you" for number so my browser can represent it properly!

Local variations in vocabulary and usage are here to stay. If you learn to live with them you'll be better prepared to converse with people from other parts of the world and other segments of society.

Reply Score: 1

Yagotta B. Kidding Member since:
2006-04-15

My, look what a cute boy he is:

...international pressure on the US to adopt the metric system isn't going to finally succeed...


Baby mojo, US _has_ adopted the metric system already. You do not work for NASA, or a defense contractor, you might predend you've got no clue. But I do. Indeed, a lot of us do.

And puhleez, don't try to suck here. Go hide and suck yourself.

It's not like inches, yards, miles, gallons and what have you should all vanish in a day - no one will let this happen. There are elderly people and there are bicycle chains. However, doing engineering work of any kind requires thorough understanding and daily use of the metric system. And yes, I do mean qualified US-engineering of today.

So far, I was not able to detect a trace of "international pressure" on us to adopt metric measures. The need is home-made. And very reasonable to boot...

Reply Score: 1

mojojojo Member since:
2007-11-20

What's with the "cute boy" and "suck yourself" and all this crudeness and impoliteness? Is it really necessary? A little snarkiness or sarcasm I can live with, but invitations to implausible masturbatory acts seems a bit over the line to me. Then again, perhaps you are a troll, I suppose, and these lines are part of your troll shtick. For now, I will pretend as though you are not a troll.

I am aware that the metric system is in use in the U.S. for certain things. I use it myself in my work occasionally, although I don't work for NASA or a defense contractor, nor am I even an engineer, I'm ashamed to say. However, everyone must admit is still the common usage in the US to use Imperial units for most things. Truly, if it weren't common for some, mostly US-based, web sites to use Imperial units, we wouldn't be having this lovely exchange, would we?

The GP was complaining about use of Imperial units that the GP found incomprehensible and requesting (applying pressure) that web pages be coded differently to allow automatic conversion of Imperial units to metric units. I think it's safe to assume that the GP finds Imperial units incomprehensible because the GP lives outside the US (international). Are you now able to detect at least something that might be considered international pressure? If not, read the GP again - the reference to metric units as "standard" is certainly at least a gentle suggestion that metric units should be adopted.

Reply Score: 1

Usability problems with the article
by blixel on Thu 27th Dec 2007 09:46 UTC
blixel
Member since:
2005-07-06

Every user that goes to the article has to waste time or energy by either viewing a full page advertisement, or clicking the "Skip Ad" button in the upper right.

The article chops a sentence in half between the first and second page of the article. So you have to pause your thinking, click "Next Page", wait for the page to load, and then finish the sentence.

The article is 3 pages long, although the "Previous" and "Next" buttons at the bottom indicate it's 2 pages long.

(Yes - these 3 points were made in the comments section of that article. But I independently came to the same conclusion before reading the comments.)

Reply Score: 7

dwave Member since:
2006-09-19

Most of IDG's websites are b0rken. This is due to the obscure home-brewed CMS many IDG business units have to use. Also, the common IDG web server is ridden with security issues and some units' sites are hacked on a weekly base. It's really sad.

Reply Score: 1

estherschindler Member since:
2005-07-12

Sounds juicy, but it isn't true.

IDG sites -- CIO.com and Computerworld.com for example -- run on industry standard Interwoven. The Advice & Opinion section, where this blog post is found, run on the open source Drupal. And most of the site UI objections (such as the blog post being chopped off midstream, or showing only the first "page 2" (even if there are more pages) are the default Drupal behavior.

Reply Score: 1

Her solution (a) won't work
by RIchard James13 on Thu 27th Dec 2007 10:07 UTC
RIchard James13
Member since:
2007-10-26

These three unforgivable sins would soon be addressed if every developer were required to (a) spend two weeks as a user of the software she writes and (b) spend two weeks on the help desk supporting her application.


If the developer has to go through and use their software they know all the quirks already after all they wrote it. They will just think it is normal. Only if they watch other people try and use their software will they spot the problems. Every programmer should spend at least 6 months on the help desk or in maintenance just to see what the effect of bad design really is.

Reply Score: 4

RE: Her solution (a) won't work
by henrikmk on Thu 27th Dec 2007 10:49 UTC in reply to "Her solution (a) won't work"
henrikmk Member since:
2005-07-10

If the developer has to go through and use their software they know all the quirks already after all they wrote it. They will just think it is normal. Only if they watch other people try and use their software will they spot the problems. Every programmer should spend at least 6 months on the help desk or in maintenance just to see what the effect of bad design really is.


Exactly.

The thing is: No matter how hard you try as a programmer, your work isn't done until it has been through the user tests, because errors will crop up shockingly quickly. They are not just software errors in general, but the strange ways that users use the program, which can cause a support call.

I made an example of that:

I made a user interface once, iTunes style with a search box and a list. Whenever you entered a single char in that search box, the list auto-filtered the way that iTunes does. When you're done searching, you don't have to press Enter, since it has no effect on the search result. Simple, right?

Well, I observed that some users were utterly confused by this, because they didn't notice the list change from before they started typing. It wasn't because they couldn't see the logic in the search method. It was simply because they were looking at the keyboard instead of the screen, while typing! They didn't look up again until they were done typing, and then pressing Enter had no effect. Therefore, they couldn't see that the search field and the list view worked together. They would have seen it, if they had looked up.

It's one of those things you don't anticipate as a developer until you look over the shoulder of a user.

Reply Score: 6

Quite right
by reflect on Thu 27th Dec 2007 11:05 UTC
reflect
Member since:
2007-07-10

She's spot on, actually. Why should the user be bothered with doing things the computer is best at? Every time you need to spend a few seconds extra doing something, it's a loss. Now imagine there's a few hundred million people also losing similar amounts of seconds. It quickly avalanches to years of lost time. When you look at it from one persons perspective, it's not much, but once you look at the bigger picture..

It's like when you shop online, and some sites wants you to enter your credit card number exactly as written on the card, including spaces. Or worse, the other way around where they gather spaces is erroneous input from you. There's no point in that and you waste a few seconds while doing it.

Edited 2007-12-27 11:07

Reply Score: 2

Comment by moleskine
by moleskine on Thu 27th Dec 2007 11:13 UTC
moleskine
Member since:
2005-11-05

I guess two things that get my goat about a certain OS are that a) whenever I apply a software patch the whole OS shuts down and reboots whether I like it or not; and b) whenever I go near this OS my bank account seems to shrink alarmingly.

Fonts and icons are often underestimated but without them our computers would be next to useless. Using poor quality ones is is very iffy for the unfortunate user. If one of those mega-rich multimedia companies wanted to do something really nice for open source, then they could release or commission some really top quality free fonts and icons under the glp that could form the basis of the interfaces on *nix (or make grants to some of the existing toilers to perfect their game). That, and perhaps a generous grant to xorg to help keep both display technology and anti-aliasing in tiptop shape. Hello, Adobe, Google and co?

Reply Score: 0

I don't want...
by kaiwai on Thu 27th Dec 2007 11:43 UTC
kaiwai
Member since:
2005-07-06

I don't want to sound like a smart ass, but that article was an example of bad usability; the page was laden with so many ads it was distracting, the lay out of the text on the page was enough to make me nauseous, the need for a 'splash screen advertisement' screams of 2000.

I always laugh to myself when I see people give a sermon on the mount over the perils of bad usability and yet, their very website is an example of ADD in HTML form.

And the waffle, geeze, the waffle from the article, dwave put it succinctly in the three lines. The amount of space taken up by the article, I could have covered 10 topics.

Reply Score: 10

ADBLOCK!!!
by robinh on Thu 27th Dec 2007 13:20 UTC
robinh
Member since:
2006-12-19

All you people complaining about intrusive ads on this site, please allow me to state the obvious - install adblock plus in to your Firefox. There's really no point complaining about about ads any more, because it's so easy to get rid of them.

Reply Score: 2

RE: ADBLOCK!!!
by Joe User on Thu 27th Dec 2007 13:26 UTC in reply to "ADBLOCK!!!"
Joe User Member since:
2005-06-29

If you used Opera you wouldn't have to install an ad-blocking extension.

Reply Score: 1

RE[2]: ADBLOCK!!!
by rockwell on Thu 27th Dec 2007 16:03 UTC in reply to "RE: ADBLOCK!!!"
rockwell Member since:
2005-09-13

Yah, because it takes all of 10 seconds to install Adblock.

Reply Score: 0

RE[2]: ADBLOCK!!!
by NxStY on Thu 27th Dec 2007 21:49 UTC in reply to "RE: ADBLOCK!!!"
NxStY Member since:
2005-11-12

But opera's contentblocker has less features than adblock+ (no list subscriptions for example). I prefer firefox and adblock+ even if it takes half a minute longer to set it up.

Reply Score: 2

RE: ADBLOCK!!!
by kaiwai on Thu 27th Dec 2007 14:37 UTC in reply to "ADBLOCK!!!"
kaiwai Member since:
2005-07-06

I have nothing against Ad's. I accept that as part of having 'free access' part of the payment is the displaying of Ads. Thats ok. The problem I have is when they go overboard on the number of ads, or worse, the terrible layout of the page - A thin column of text wedged between two dominating side columns of wiffle-waffle that adds nothing to the usability of the website, unless of course the aim of the site is to confuse.

Reply Score: 4

RE[2]: ADBLOCK!!!
by MacTO on Thu 27th Dec 2007 17:54 UTC in reply to "RE: ADBLOCK!!!"
MacTO Member since:
2006-09-21

To add to what you're saying:

Blocking the ads will rarely fix the formatting issues created by the website being designed for advertising rather than content.

Though I'm not going to go as far as blaming the author for the problems of the website. For all we know, her commentary may be an underhanded discussion of the backend that the publisher forced her to use in order to get her articles published.

Reply Score: 1

User-hostile
by lefty78312 on Thu 27th Dec 2007 13:24 UTC
lefty78312
Member since:
2005-10-18

Virtually every software program I've had to work with in the past 10 years or so was designed to be sold to the company; not to be useable. Sometimes it's something as simple as not putting the focus at the place where it's most logical for the user to input information, or having the tab-stops in a non-sensical order. And some programs won't allow the user to take the most logical next step at all, and/or are very counter-intuitive if they do. And once the program has been disseminated to users, changes to make it more useable are never made.

I would suggest that the people who approve these programs for purchase should have to spend a month or so actually using them, and receive the same pay during that time as the users they approved it for. As long as there are idiots involved in the purchasing process, nothing will change.

Reply Score: 2

One thing that's always bothered me...
by javaman83 on Thu 27th Dec 2007 14:43 UTC
javaman83
Member since:
2005-07-06

are programs that insist on taking the focus. IE and the MS Office apps are notorious for that. If I put a program in the background, I want it to stay there until I'm ready to go back to it.

Reply Score: 2

My least favorite
by fretinator on Thu 27th Dec 2007 14:57 UTC
fretinator
Member since:
2005-07-06

Fixed-size dialogs. Almost every major software vendor has done this at one time or another. A dialog pops up and there is too much text to fit on the dialog, so part of the text is cut off. No big deal, you just grab the corner of the dialog and ... DOH! The dialog is not resizable, so you never get to see the rest of the text. There used to be many of these in Microsoft's system dialog boxes. Some lazy programmer decided that dialog would never need to be resized.

I also don't like windows/dialogs that have important text (even URL's for example) that cannot be selected and copied.

Reply Score: 6

RE: My least favorite
by spikeb on Thu 27th Dec 2007 16:59 UTC in reply to "My least favorite"
spikeb Member since:
2006-01-18

i think every dialogue box should have text that can be copied.

Reply Score: 3

RE[2]: My least favorite
by Bending Unit on Thu 27th Dec 2007 18:11 UTC in reply to "RE: My least favorite"
Bending Unit Member since:
2005-07-06

Windows standard dialogs: press CTRL+C when the msgbox is in focus. Paste in text editor.

Reply Score: 4

What the author forgets...
by IridiumAlly on Thu 27th Dec 2007 15:21 UTC
IridiumAlly
Member since:
2007-06-29

What the author forgets is that most commercial software developers are at the bottom of the development chain. No matter what the developer wants to do he/she is trumped by the project manager who in-turn is trumped by another manager an so on. Developers make the magic, and are also directed to make the crap, because that is exactly what someone else higher up wants. The commercial application that I have been toiling away on for 5 years has so many usability issues in it. But, that's how the PM wants it because he trains the users in how to operate it. It's what he wants not what the users, testers or the developers want. Yet, we hear about the issues almost daily...

Reply Score: 3

RE: What the author forgets...
by Tuishimi on Thu 27th Dec 2007 15:29 UTC in reply to "What the author forgets..."
Tuishimi Member since:
2005-07-06

This is true, too. Often the developer has a steamy load of requirement dung plopped before him, with a predetermined amount of time to accomplish the vagueness.

Reply Score: 3

This is good timing...
by Tuishimi on Thu 27th Dec 2007 15:26 UTC
Tuishimi
Member since:
2005-07-06

...I was asked to make our "page range" field for entering (duh) pages used by our customer in range format that can be 0-9, roman numerals, separated by a comma OR space, can contain a dash for ranges. Then I have to take them all, count them and provide a total back to the user. ;) So far I tried the lazy way out using regular expressions but I am terrible with them, looks like no matter what I do I'll have to do a little coding.

Reply Score: 3

RE: This is good timing...
by Bending Unit on Thu 27th Dec 2007 18:14 UTC in reply to "This is good timing..."
Bending Unit Member since:
2005-07-06

A developer do a little coding? The horror!

Reply Score: 3

Dumb
by Belial6 on Thu 27th Dec 2007 22:17 UTC
Belial6
Member since:
2007-06-07

The writer of this article is simply dumb. When you call someone lazy because they didn't make every little detail the way you wanted it, you are simply to dumb to be taken seriously. The example with the input cleansing. Given that the developer of the example app may have fixed 100 other things before they ran out of time, the authors solution very well may have left 2 options. Release without stripping dashes, or not release at all. Which version is going to work better?

The same could be said about the 'losing context' complaint. She says it is trivial to implement, but clearly has never had to implement an infinite number of undos in a real production application. After all, if your going to have to keep track of the last operation when you start doing something new, we are basically talking about undos. If you code one level, someone is going to complain about not having 2, 3, or more. But, even if you take that out of the equation, you are still faced with very often, not getting any software at all if you try to submit a budget that includes all of these little things.

Finally, while I have seen some bad error messages in my day, (And have written a few to boot) her examples of bad error messages are simple... Dumb. If the user is experienced enough to fix a problem on their own then they are experienced enough to know that they don't need to call the administrator. If they are not experienced enough to know not to call the administrator, then they should be calling. This should be obvious. The other dumb comment was that the applications say the error is in other parts of the system instead on in the program itself. Well, hello?!?!? if the developer knew that the bug existed, they would have fixed it, and really, 99 times out of a hundred, if the application doesn't think that you entered the right information, then you probably didn't. As a user of applications, I can only think of a few times out of 10 of thousands 'wrong data' messages I have seen that were the applications fault.

Reply Score: 2

RE: Dumb
by Chicken Blood on Fri 28th Dec 2007 06:54 UTC in reply to "Dumb"
Chicken Blood Member since:
2005-12-21

The writer of this article is simply dumb. When you call someone lazy because they didn't make every little detail the way you wanted it, you are simply to dumb to be taken seriously. The example with the input cleansing. Given that the developer of the example app may have fixed 100 other things before they ran out of time, the authors solution very well may have left 2 options. Release without stripping dashes, or not release at all. Which version is going to work better?


You create a convenient straw man argument there. The choice is "release without stripping dashes, or don't release at all". Really? Good QA would have made strong input validation a priority 1 feature before release. The other 100 bugs would have similarly been filtered into 'nice to have' features and show stoppers. The author is not dumb at all. The author just wants decent software. Your attitude is typical of developers who resent their users.


The same could be said about the 'losing context' complaint. She says it is trivial to implement, but clearly has never had to implement an infinite number of undos in a real production application. After all, if your going to have to keep track of the last operation when you start doing something new, we are basically talking about undos. If you code one level, someone is going to complain about not having 2, 3, or more. But, even if you take that out of the equation, you are still faced with very often, not getting any software at all if you try to submit a budget that includes all of these little things.


This is not about infinite undo, it is just about remembering the current position in a list, so the user does not have to do unnecessary, repetitive work. Read the article again. This is not a 'little thing' and anyone managing a budget should realize this.


Finally, while I have seen some bad error messages in my day, (And have written a few to boot) her examples of bad error messages are simple... Dumb. If the user is experienced enough to fix a problem on their own then they are experienced enough to know that they don't need to call the administrator. If they are not experienced enough to know not to call the administrator, then they should be calling. This should be obvious. The other dumb comment was that the applications say the error is in other parts of the system instead on in the program itself. Well, hello?!?!? if the developer knew that the bug existed, they would have fixed it, and really, 99 times out of a hundred, if the application doesn't think that you entered the right information, then you probably didn't. As a user of applications, I can only think of a few times out of 10 of thousands 'wrong data' messages I have seen that were the applications fault.


You may have a point about the error messages, but the authors point still stands: Too many apps, blame something else (often the user) for an error with defensive error messages. Even when it is the users fault, or the fault lies outside of the software itself, there are polite ways to help them find a solution, rather than just insulting their competence and leaving them confused. The developer not knowing the bug existed is not an excuse. the default in exceptional cases should not be to "blame the user".

Reply Score: 2

RE[2]: Dumb
by Belial6 on Sat 29th Dec 2007 00:32 UTC in reply to "RE: Dumb"
Belial6 Member since:
2007-06-07

You create a convenient straw man argument there. The choice is "release without stripping dashes, or don't release at all". Really? Good QA would have made strong input validation a priority 1 feature before release. The other 100 bugs would have similarly been filtered into 'nice to have' features and show stoppers. The author is not dumb at all. The author just wants decent software.


You are simply wrong. The cost of covering the hundreds of minor things like input cleansing, can double or triple the cost of a project. You are in denial if you think that the green lighting of ANY project, software or not, does not directly relate to the cost. This is why documentation is often not done. When you tell a client that the cost without documentation is going to be $200k, and it is going to be $300k - $350K with documentation, it is the client, not the developer that makes the decision to start cutting.

Your attitude is typical of developers who resent their users.


Most developers I know would LOVE to polish their apps to a pristine condition, but when no one is willing to pay for that, it doesn't happen. When you figure out how to get the blank checks for every project, let me know. Of course, when when someone goes above and beyond in their job, but get called lazy, or are told that they resent their users for their effort, it makes taking the critique seriously.

This is not about infinite undo, it is just about remembering the current position in a list


Yes, yes it is. If you are going to remember where someone is when they jump to a new task, you have to be prepared to remember that spot when they jump to yet another task, and so on. What is considered a 'task' is a matter of opinion, and if you have more than a couple of users, they won't all match. There is this little thing that developers face when they are dealing with clients. It is call "Scope Creep". The project gets spec'ed out, and the developer meets the spec. Then a user asks for "a simple thing". The developer thinks, no problem. It's just a minor change. After the 100th or 200th 'minor thing' the project is 200% over budget and no end in sight. I have seen several companies go out of business due to an inability to say no to scope creep. Trying to solve complaints about starting the person back at the beginning instead of keeping a trail of their usage is exactly the kind of things that can drive companies out of business.

This is not a 'little thing' and anyone managing a budget should realize this.


Yes, it is a little thing when compared to the core functionality of a project. Which would you rather have, a word processor that does not let you type, but remembers where you were in a list, or one that does let you type, and starts you back at the beginning of a task after you complete one? And anyone managing a budget should realize that FIRST comes core functionality, THEN comes refinement.

You may have a point about the error messages, but the authors point still stands: Too many apps, blame something else (often the user) for an error with defensive error messages. Even when it is the users fault, or the fault lies outside of the software itself, there are polite ways to help them find a solution, rather than just insulting their competence and leaving them confused. The developer not knowing the bug existed is not an excuse. the default in exceptional cases should not be to "blame the user".


Perhaps the problem is that the user is just too touchy. The example of "your network is not functioning" is not an attack on the user. It is a very good indication of where the problem is. If there is an error, the software has to guess at what it is. If it stops giving suggestions and just says "Oops, I must be broken" the user will be WAY worse off.

Reply Score: 1

RE[3]: Dumb
by Chicken Blood on Sat 29th Dec 2007 05:09 UTC in reply to "RE[2]: Dumb"
Chicken Blood Member since:
2005-12-21


You are simply wrong...


Nice. The rest of your post just reeks of similar hubris and clues me in that you have never developed quality software, but wish to browbeat me into the business model that you have been unfortunate enough to be subscribed to. I'm not criticizing you for being in that environment, because I have worked in similar cultures, but I never thought for one second "this is the way it has to be". Your continued discussion about cost is missing the point. Of course cost is an important factor (I never said it wasn't). The simple fact is, the standard of software my team (and others) produce is expected to provide #1 and #2 as a standard level of quality. We are not talking about esoteric functionality here.

The 'scope creep' you write of is only an issue if the
a) Feature is not in the original spec.
b) It leads to another feature, and another, and another.

This would not happen in my workspace for the examples mentioned because:
a) #1 and #2 would be part of the specification, always.
b) A skilled project-review board is employed to ensure that nothing is introduced that wasn't originally intended.

I say you resent the user, because you call the article 'dumb' when it represents what many real users want (and to be honest is a standard expectation in any software of reasonable quality - again #3 is dubious).

I will continue to develop quality software in the workplace, since I am lucky enough (I guess) to work somewhere where customers demand quality and are willing to pay for it. Good luck in trying to increase revenues in software that refuses to validate user input and callously makes their life harder by 'forgetting' where they were.

Reply Score: 2

redbarchetta
Member since:
2005-11-14

Think Monk on a PC and you have a usability expert. Developers, thank goodness, do not have to listen to usability "experts" too often or there would be no software as we would have all shoved hot burning pokers through our eye sockets by now as a result of your incessent nagging. If you don't like it "expert", don't use it. Enough said....

Reply Score: 0

unoengborg Member since:
2005-07-06

I think much of the problem is the attitude of which you are displaying an excellent example.

You seam to see the software Developer as a person who writes (insert your favorite programming language here) code. This person might be very good at that, but that doesn't make him a good software developer, at best it makes him a good programmer. As such he is a very valuable resource to the project, but he is not the only resource needed for a succesfu project.

Modern software projects are far too complex to be handled by people with just one skill, and in most cases you need to engage more than one person to get the level of expertise you need.

E.g. an expert in software design may not only help you design code that is fast and works well, but also design it in a way that it is maintainable, testable and that you easily can add more people to the project in case it grows. That person is not necessarily the same person that is ũbermench at getting the details in the C code just right with impeccable precision.

You need people that can express themselves well human languages to write documentation. If the programmer writes the end user documentation himself he is too close to the project and he will take too much for granted. E.g how many times have you seen descriptions of flags to Unix/Linux CLI programs that tells you that it is used to specify a file size, but it doesn't say if it is in blocks, bytes or something else. To the programmer this is obvious, but not to the user.

You need artist that makes your ikons and other graphics in your software to look good and consistent.

Just like you need the skills mentioned above, you need skill in e.g. usability to help the programmer to make a program that interacts both effectively and efficiently with the user. The things that are important to the programmer might not be all that important to the user.

One typical example of this is GUIs like Gnome and KDE. They both try to be as good user interfaces to Unix as possible, and this might be a good thing if the intended users was sysadmins, or developers. The problem is that in most organizations these roles are in minority, as they just provide services to the people who do the real marketable work of the organization.

So why is it that both KDE and Gnome insists on showing directories like /etc, /proc, /usr, /sbin, /bin, /dev, /sys, /lib to the accountants, salespeople and other people with non computer related jobs that are the most likely target user of the system. The only reason I can think of is that the Programmers/Developers want to show that it is Unix. However, to the accountant or salesperson Unix is most likely irrelevant. This is probably why you don't see these directories displayed in MacOS-X, and in turn, the reason for that is most likely that Apple hires usability experts who can give their programmers good advice in this kind of matters.

All in all, good software development of any non trivial piece of software is teamwork, and all skills are equally needed. Programmers as well as usability people.

Reply Score: 6

Interface Hall of Shame
by DigitalAxis on Fri 28th Dec 2007 03:01 UTC
DigitalAxis
Member since:
2005-08-28

Ever seen the interface hall of shame?
http://www.math.leidenuniv.nl/~xmath/mirror/www.iarchitect.com/msha...

Some of them are really, really frightening. Check the 'confusing terminology' page to see the field of 60 nigh-unlabeled checkboxes!

Reply Score: 2

Losing-Context vs MyLyn vs Visual Studio
by pg--az on Fri 28th Dec 2007 08:23 UTC
pg--az
Member since:
2006-03-15

Context-switching-wise, I recently noticed a fascinating content-packed webinar from 19-December, which you can find with the Google query (( MyLyn 2.2 Webinar )).

Anyway having never used Eclipse and not owning Team System, at a casual glance Visual Studio still seems to be missing the context-switching-paradigm of MyLyn, yet searching say channel9.msdn.com for MyLyn yields ZERO hits.
Appreciation in advance for comments from those who have used say both Team System AND Eclipse/MyLyn, please ?

( about the (( MyLyn )) - I am a religious user of McAfee Site Advisor, which I use with FireFox. If you have SiteAdvisor loaded, then you would see the reassuring green dot beside the eclipse.org-link. This is why I prefer to phrase links in terms of Google queries, it's the way *I* like to be referred to things. )

Reply Score: 1

Wondercool
Member since:
2005-07-08

Number 2:

When you post something you are returned to comment 1-15, not where you were. Coincidentally, yes this in annoying.

Also, it would be nice to have some sort of option where you can see all comments immediately instead of displaying comment 1-15 first and then have to click on "See all comment" but maybe this is because OSNews wants you to see more adverts (which I understand) or to save bandwidth (which is not true, it will cost more bandwidth this way)

Reply Score: 1

PlatformAgnostic Member since:
2006-01-02

Try threaded view... that fixes the 1-15 problem. I agree about the comment posting issue, but I bet it's not so easy to solve.

Reply Score: 2

She doesn't know what she's talking about
by appel on Sat 29th Dec 2007 08:34 UTC
appel
Member since:
2007-12-29

A program should never guess or try and fix a user's input mistake. The user is to blame. Rather ask to enforce a certain arguably more readable syntax than for the program to try and guess the correct answer.

The losing context part I can agree with to an extent, but when using *NIX based, one application for one task and combining them, you won't have that problem either.

Error messages can be more descriptive, yes. With that I agree completely, but even so it's still mostly just a Windows based problem.

Reply Score: 1

Chicken Blood Member since:
2005-12-21

A program should never guess or try and fix a user's input mistake. The user is to blame. Rather ask to enforce a certain arguably more readable syntax than for the program to try and guess the correct answer.


The user is to blame? Don't you think the application should help the user wherever it can? Are computers not a tool to serve us and help us get our work done more quickly?

If you disagree with this, don't ever question why more people aren't buying your software.


The losing context part I can agree with to an extent, but when using *NIX based, one application for one task and combining them, you won't have that problem either.


Explain. As a UNIX user for over 10 years, I fail to see how being UNIX diminishes the problem any.


Error messages can be more descriptive, yes. With that I agree completely, but even so it's still mostly just a Windows based problem.


There are examples of bad error messages on all platforms. The OS has nothing to do with it.

Edited 2007-12-29 20:06 UTC

Reply Score: 1

appel Member since:
2007-12-29

The user is to blame? Don't you think the application should help the user wherever it can? Are computers not a tool to serve us and help us get our work done more quickly?


Sure, thats why I suggested the coder to write the program to take a more readable format. My argument is that the computer should not make guesses on the correct input data as the author suggested.

Explain. As a UNIX user for over 10 years, I fail to see how being UNIX diminishes the problem any.


Well, if you want to keep track of where you are, you can pipe the initial program to another which allows you to keep track.

Even so, as I said I do agree that programs which 'lose' context are badly written.

There are examples of bad error messages on all platforms. The OS has nothing to do with it.


Agreed, but the average *NIX coder and user expect a certain standard, and as a whole you should notice that these error message are mostly more helpful than a Windows: "Something went wrong, sorry" one.

Reply Score: 1

never forget
by trenchsol on Sat 29th Dec 2007 12:27 UTC
trenchsol
Member since:
2006-12-07

Software requirements can be classified as functional and nonfunctional. Usability falls in the category of non-functional requirements, or more specifically "quality attributes". With more quality attributes included application grows more expensive and it takes more time to be delivered to the customer. If the customer insists on low prices and tight schedules, then the result will surely and inevitably be like that.

Never forget that there is no such thing as free lunch.

Reply Score: 2

Don't Blame Developers
by ralphcarlsonjr on Sat 29th Dec 2007 13:48 UTC
ralphcarlsonjr
Member since:
2007-12-29

Most development is for businesses where the developers are not the ones given the option how to layout the design but are told what to do by there managers and simple follow instructions. The managers/designers should be the ones to blame.

Reply Score: 1