>>If you can't define acceptable software, how will you know when you're using it, or have achieved it as a developer?
>
>Sorry, Al. I had misread that you wanted examples. My mistake.
>
>I'd define it, for stuff that I get to work on, as having characteristics like what the article discusses.
>
>For stuff that I use I would expect it:
>1) to have clear clear and consistent interfaces:
>--- use words/icons that have clear meaning;
>--- use consistent exits for dialogues;
>--- use something consistent to indicate that a dialogue will happen on clicking;
>--- use something to indicate that options are available on right-clicking something;
>2) operates consistently as expected/indicated by the UI component used.
>3) is designed to assist the user on error conditions.
>4) has genuinely helpful ToolTips/WhatsThis/Help.
>--- Help that doesn't take one on a long excursion of short paragraphs with click after click needed to reach the meat of an issues.
>
>I think those would be an excellent start.

Hmm, my list would be considerably different (in order of priority):

1. Does the job
2. Is reliable
3. Is reliable
4. Is reliable
5. Requires little or no maintenance
6. Support is available if required
7. Has a standards-based interface

From my POV you're spending a lot of effort complaining about problems with an aspect of software that's way down my list. Or, have I misunderstood you completely - are you talking about "crappy" simply in the context of UI?