Forgot your password?
typodupeerror
Software Programming IT Technology

Why Software Sucks, And Can Something Be Done About It? 498

Posted by Zonk
from the make-it-work dept.
CPNABEND tipped us to a story carried on the Fox News site, pointing out that a lot of programmers don't understand their users. David Platt, author of the new book 'Why Software Sucks ... And What You Can Do About It', looks at the end user experience with end user eyes. While technically inclined individuals tend to want control, Platt argues, most people just want something that works. On the other hand, the article also cites David Thomas, executive director of the Software & Information Industry Association. His opinion: Users don't know what they want. From the article: "'You don't want your customers to design your product,' he said. 'They're really bad at it.' As more and more software becomes Internet-based, he said, companies can more easily monitor their users' experiences and improve their programs with frequent updates. They have a financial incentive to do so, since more consumer traffic results in higher subscription or advertising revenues." Where does your opinion lay? Should software 'just work', or are users too lazy?
This discussion has been archived. No new comments can be posted.

Why Software Sucks, And Can Something Be Done About It?

Comments Filter:
  • by yagu (721525) * <yayagu@@@gmail...com> on Friday January 05, 2007 @03:39PM (#17478292) Journal

    One example I encounter almost every day is the notion of a computer's "state". People just want to turn something off and on, not easily abstracted for computers.

    So, there is this myriad combination of "states", not too complex for slashdotters to understand but off the scale for lay users. It doesn't help we use "our" terminology. I've stopped trying to explain and describe the difference between "hibernate" and "standby".

    Files, directories, logical drives..., all foreign and abstract curiosities to computer users -- most are technical artifacts from early on abstractions. It's not a wonder these lexicons ripple out the the general population, unfortunately it's of no use to the general users and mostly to their detriment.

    I don't know how to get there, but users/people want computers to behave like toasters. They want very simple, limited-option and intuitive behaviors. Not all software lends itself to those but I think there is a much happier in between, and the group that can move is the programming group. I don't think the general population will ever educate itself about the differences between relational/hierarchical databases, the differences between NTFS and VFAT file systems, nor do I think they should be asked to know.

    The closest I've seen to getting "there" in computers is probably Apple... I've seen novices sit in front of Apples and almost immediately be able to be productive.

    The second closed I've seen is Unix/Linux, etc... not so much because of it's ease-of-use, but because it's one of the most consistent "flavors" of computing I've experienced (NOTE: I'm not discounting the complexity of Unix, it's certainly not for novices, but at least it's consistent).

    One of the most popular applications I've written was one where the interaction with the user was basically a singly input field, a la Google. Users would instinctively type anything in the input field, and the application would do a pretty decent job of offering meaningful results. Analysis of logs showed users typically received meaningful results from their "input" 80 - 90% of the time. Granted it was a narrowly defined application, but I've seen indecipherable interfaces on top of narrowly defined applications.

    The best general computing out there is something I'd predicted long ago, devices that are for narrowly defined and specific use with high powered computers underlying the gadgetry transparently (think TomTom (gps), ipod (no, I'm not a fanboy), etc.)

    Ironically, or perhaps paradoxically, the most dominant technology available is the least intuitive to just sit down in front of and use. Of course, there is a latest and greatest new version out this year that should fix all of that. .

    Bottom line, my opinion, users are not lazy, they just want to get some work done without needing the equivalent of a Bachelor's in Computer Science to get that work done.

    • Fine, not lazy (Score:3, Insightful)

      by Mateo_LeFou (859634)
      I'm guilty of some sneering at the 'average' computer user, and I'm working on that, but I'd like to point something out:

      Computing -- especially in a *globally networked environment -- is *in *fact complicated. Doing it responsibly, in a way that doesn't wreck the environment for others (Cf. botnets) is difficult. Many of the users who "just want to get some work done" outsource the complexity, but don't mind if the network suffers the externalities because they don't feel like learning what true security r
      • Re:Fine, not lazy (Score:5, Informative)

        by drinkypoo (153816) <martin.espinoza@gmail.com> on Friday January 05, 2007 @04:13PM (#17479014) Homepage Journal
        But taxis and buses don't damage the roadways and the other vehicles on it during ordinary use.

        Au contraire! A bus does more damage when it runs across a roadway than would a line of cars with the same seating capacity because a larger amount of weight is put on the four (or perhaps six wheels - either double-axle or dual-wheel in the rear) wheels than from any car.

        This is the reason why we have laws that say that vehicles over certain weights may not travel through certain neighborhoods except to make a delivery, and why you are supposed to need a commercial license to drive a vehicle over a certain weight. Of course, we don't actually enforce these laws because it means some rich people in LA and SF wouldn't be able to drive their Hummer home...

        • Re: (Score:3, Insightful)

          by nasch (598556)

          you are supposed to need a commercial license to drive a vehicle over a certain weight. Of course, we don't actually enforce these laws because it means some rich people in LA and SF wouldn't be able to drive their Hummer home...

          Maybe you're just joking, hard to tell online. But a quick google shows this is not correct.

          From http://drivingrules.net/cdl/needaCDL.htm [drivingrules.net]

          DO YOU NEED A COMMERCIAL DRIVER'S LICENSE? You need a CDL if you operate any of the following vehicles.

          • All single vehicles with a manufactur
      • Re:Fine, not lazy (Score:5, Insightful)

        by Daniel_Staal (609844) <DStaal@usa.net> on Friday January 05, 2007 @04:22PM (#17479210)
        But learning to drive is not the same as learning to fix and maintain a car. To drive you only need to operate the car, and to own it you only need to remember to take it into the shop occasionally to get looked at.

        Computers, right now, require you to be mechanics to drive the car, and users don't want to be mechanics. They want to get their work done. Part of this is changing user expectation (so that they know to get routine maintaince from someone trustworthy), but part of it is building the systems so they can survive routine wear and tear for an extended length of time, without the intervention of computer 'mechanics'.
        • Re: (Score:3, Insightful)

          by Mateo_LeFou (859634)
          You missed the point. Computers are like cars that can do a tremendous amount of damage to the driving experience of others without the operator even necessarily knowing about it. No, drivers don't *want to be mechanics. They don't even *want to take drivers ed. These things are required of them by law in accordance with the externalities that the resepective devices do/can generate. If there were a flux capacitor in your car, so that it was potentially capable of blowing up your city, the driver's license
        • by Anonymous Coward on Friday January 05, 2007 @05:58PM (#17481088)
          Computers have exactly four purposes:

          1: Pr0n
          2: Games/entertainment
          3: Communication
          4: Doing our work for us.

          Building machines to do your work for you does not make you lazy. Using the machine that someone else built also does not make you lazy. In both cases, the machine is freeing you from a mundane burden so you can do something else more useful with your time. Making efficient use of the tools available to you is not laziness.

          Laziness is when you push your own responsibilities off on to other people, without paying them for it (like, you know, leaving your dirty dishes in the office sink so your coworkers can wash them for you). Yes, payment absolves you of laziness since it is ultimately an economically productive action in and of itself.

          Paying a developer for a program that "just works" isn't lazy, it is efficient.

          End users don't like a complicated interface. Why should they? The less complexity they have to deal with, the more time they have to do something else that is useful.

          Yes, some amount of complexity is going to be unavoidable. That's a fact of life. Users will naturally resist it as much as they can, but ultimately accept what amount of it they cannot escape. This is not a vice on their part, it is just a path of least resistance.

          If you can design an optimized balance between complexity, intuitiveness, and productive outcomes in your user interface, your product will do well.

          It is that simple.
          • Re: (Score:3, Informative)

            by Sj0 (472011)
            My only question in response to your post would be "Are interfaces today really all that complicated?"

            My landlady hasn't touched a computer in over a decade, but I hooked up a little PC to the internet for her, and she can happily look up what she wants and check her e-mail.

            My brother doesn't even have a high school education, but he can run up torrents, install games, and use whatever software he wants without a word of hassle.

            My sister isn't even literate enough to form a single sentence without massive g
          • by wavedeform (561378) on Friday January 05, 2007 @09:43PM (#17483736)

            Computers have exactly four purposes:

            1: Pr0n
            2: Games/entertainment
            3: Communication
            4: Doing our work for us.

            Well, yeah, but the same could be said for paper products. :-)


            I think that there are either;
            -many other categories, such as art, research, etc,
            -or only one category, which I would call "Stuff".

    • by Qzukk (229616)
      Bottom line, my opinion, users are not lazy, they just want to get some work done without needing the equivalent of a Bachelor's in Computer Science to get that work done.

      The problem is that people insist that everything be as simple as a toaster, regardless of the actual complexity of the task. It's easy to say "narrow down the task until it fits", it's harder to figure out how to drive a car using one rarely-used slider and one button.
    • "the article also cites David Thomas, executive director of the Software & Information Industry Association..."

      I think the idea that information is an industry is part of the problem.
    • by TheCrayfish (73892) on Friday January 05, 2007 @03:51PM (#17478526) Homepage

      Well said, yagu. For a good illustration of the truth of what you've written, try teaching a Computer Literacy class for adults who have never used a computer before. I got questions like "what's a mode?" and "why are these little arrow keys for?". If normal humans -- the kind who don't read Slashdot -- have trouble with concepts like modes and arrow keys, you can imagine how difficult it was for them to understand that, when their Word document disappeared from the screen when they minimized the window, it did not also disappear from "the computer", but was sitting somewhere invisible to them.

      I think it would serve every programmer well to spend some time teaching novices how to use something the programmer finds simple, such as the Windows calculator, Notepad, etc., to see how "normal" users think and react.

      • by sammy baby (14909)
        I got questions like "what's a mode?" and "why are these little arrow keys for?"

        Um... what's a mode?

        I'm not being facetious - various editors having differing input modes, monitors have modes, most *NIX systems have a single user mode, et cetera. I'm wondering what you're referring to.
      • by try_anything (880404) on Friday January 05, 2007 @04:37PM (#17479554)
        I don't agree that novices can be considered "normal." The computer illiterate are quickly becoming an oddity, a special niche in usability design. There's really no need to consider them anymore unless you have a special reason to.

        The real question is how much sophistication can be reasonably expected from lifelong computer users. The file concept and needing to save one's work is an example of something that we've accepted that everyone can and should learn, in spite of the dire predictions of UI experts. The idea that people would be better off sheltered from the file concept is, in retrospect, pretty silly -- as silly as the idea of equipping an automobiles with reins and a whip so it would feel like a horse-drawn carriage.

        I think we should stop projecting limitations onto humanity and see what happens. The typical "poor ignorant user" of 2030 is going to be at least as savvy as today's typical middle-class college student, and maybe more savvy in ways that surprise us.
        • Re: (Score:3, Insightful)

          by misleb (129952)

          The real question is how much sophistication can be reasonably expected from lifelong computer users. The file concept and needing to save one's work is an example of something that we've accepted that everyone can and should learn, in spite of the dire predictions of UI experts.

          Ah, but couldn't you make a system that simply saved changes in realtime? Why should we expect users to save their work? Is it just the principle of the matter? Is saving work some kind of fundamental lesson, without which users wou

        • Re: (Score:3, Funny)

          The computer illiterate are quickly becoming an oddity, a special niche in usability design. There's really no need to consider them anymore unless you have a special reason to.
          Considering most Slashdotter are related to at least one such person in their immediate and extended families, your point is summarily rejected by the collective Slashmind.
      • Re: (Score:3, Funny)

        by kubalaa (47998)

        how difficult it was for them to understand that, when their Word document disappeared from the screen when they minimized the window, it did not also disappear from "the computer"
        I'm skeptical. Did these people also think that all the little people in their TV die when they turn it off?
    • by plierhead (570797) on Friday January 05, 2007 @03:52PM (#17478544) Journal

      Bottom line, my opinion, users are not lazy, they just want to get some work done without needing the equivalent of a Bachelor's in Computer Science to get that work done.

      But what if its simply not possible to make things so simple that average Joe can "just do it"?

      Everyone uses Google's search box as an example, but the fact is that that box is the front end of a task that is very easy to describe - "show me a list of documents that more or less relate to these words".

      As soon as you stray from there into some of Google's other functionality you are into some far more complex screens that I personally have heard people confused by. Well-designed though they are, it sometimes just takes a fiew fields, links and words to make the interface powerful enough to be useful for the task at hand. This is even more so when there are financial ramifications to the task at hand, immediately requiring history, confirm dialogs, balances, tec etc.

      As computer gurus our very DNA is infused with the belief that we can build it, and make it so simple anyone can use it.

      Personally, I find that this feeling diminishes as the project progresses. Sometimes because we don't have access to Googe's level of funding for UI design, usability testing, etc. But often, in my opinion, because some tasks simply can't be made simple.

    • Completely agreed- and it's been pointed out many times over the years. My favorite is About Face by Cooper- he's the guy who created Visual Basic version 1.

      However, a couple of quibbles- the first is:

      I don't know how to get there, but users/people want computers to behave like toasters. They want very simple, limited-option and intuitive behaviors.

      A toaster is a pretty non-intuitive interface. The first toasters were worse (only one heating element, you had to time the bread yourself, and flip it ov
      • Re: (Score:3, Insightful)

        by drinkypoo (153816)

        The article isn't calling USERS lazy, it's calling Software Engineers lazy. In combination with what I said above, though, I disagree. Most machines take a lot of know how to use them- then the know how becomes custom, common sense, a part of the culture- and suddenly it's "intuitive".

        I don't think that engineers are lazy, at least, not always. But that statement leads into this one: lazy is subjective. If a programmer failed to implement a feature that I think would probably be easy, then I think he's

      • by nuzak (959558)
        > A toaster is a pretty non-intuitive interface.

        I've heard the nipple called the only intuitive interface, but I've been told that a lot of newborns have trouble even getting that. We have some inbuilt tendencies, but as far as actual learning goes, we're really tabula rasa.

        The push lever on a mechanical toaster is something you cannot fail to get. Lever goes down, toast goes down, toaster gets hot. Anyone who cannot comprehend that should probably not be operating it, lest they cause injury. The toa
    • by danpsmith (922127) on Friday January 05, 2007 @04:19PM (#17479136)
      I don't know how to get there, but users/people want computers to behave like toasters. They want very simple, limited-option and intuitive behaviors. Not all software lends itself to those but I think there is a much happier in between, and the group that can move is the programming group. I don't think the general population will ever educate itself about the differences between relational/hierarchical databases, the differences between NTFS and VFAT file systems, nor do I think they should be asked to know.

      That's all good and fine, but there are cases, many, many cases, where users aren't able to use even the simplest interfaces. This can be expected of them, as the people unable to use these interfaces tend to be old people, while younger people immediately know how to use them regardless of previous training because they are at least used to the idea of an interface.

      I used to work at wawa, and I can't even tell you how many people used to complain about how the touch screen ordering system was oh so complicated. The entire thing was self-explanatory. You touch what type of food you want, then touch the ingredients then hit complete. Not exactly rocket science. For these people even using a touch screen to manipulate words is something they are uncomfortable with. We cannot stoop to this type of illiterate and design software to accommodate them. They simply cannot be accommodated. People need to learn to read and interact with a basic interface, if they can't, then they will get left in the dust, same as other dinosaurs.

      • by Hans Lehmann (571625) on Friday January 05, 2007 @05:44PM (#17480834)
        I used to work at wawa, and I can't even tell you how many people used to complain about how the touch screen ordering system was oh so complicated. The entire thing was self-explanatory.

        If it was really self-explanatory, then they wouldn't have a problem with it, now would they? Unfortunately, what might seem self-explanatory in hindsight to the developer, or to someone like yourself that's around it 8 hours a day, can be completely baffling to someone that's never seen it before. Take, for example, all those web sites with Flash navigation that force you to poke around with your mouse, trying to guess where where the menu is. The developers that created those atrocities thought they were 'self-explanatory' too ; the rest of us want to beat the developers with a stick.

      • Re: (Score:3, Insightful)

        People need to learn to read and interact with a basic interface, if they can't, then they will get left in the dust, same as other dinosaurs.

        Or, more likely, they'll learn to shop at someplace other than wawa where they can get service from a real human being.

        Peace be with you,
        -jimbo

    • by w3woody (44457) on Friday January 05, 2007 @04:32PM (#17479424) Homepage
      So, there is this myriad combination of "states", not too complex for slashdotters to understand but off the scale for lay users. It doesn't help we use "our" terminology. I've stopped trying to explain and describe the difference between "hibernate" and "standby".
      You know, I think this captures the fundamental problem here.

      From a technology standpoint we programmers think in terms of how the underlying stuff works. To us, it's clear what hibernate and standby are doing, why they're different and what the relative advantages and disadvantages of each technology are. However, in being so focused on the underlying technology and how it works, we start overlooking the problem that both technologies are trying to solve, which is this: how to extend the life of a computer (computer's battery, in the case of a laptop) when a computer is left on but is not in use--and do it in such a way that the computer can come back on relatively quickly when the user comes back.

      Users want us to solve problems, we want to provide technology.

      And so when the user wants to solve the problem "I walked away from my laptop for an hour; please make it so the battery doesn't drain dry when it is idle", we come back with "well, we have sleep and standby and hibernate; hibernate is really cool because the computer is almost completely powered off but standby allows the computer to come back a lot faster"--of course we're going to get a glazed look on the poor user's eyes. All he wants is to come back, jiggle something, and have the computer come back to life.

      Unfortunately because we talk about providing technology and the user wants to solve problems, we then wander off grumbling "stupid lusers; they're not willing to learn how to use their computer." And the poor users stumble off grumbling "why do they make these damned thing so hard to use? I don't care about bits and bytes; just tell me what I need to do so I can get my important work done."

      The really ironic part is that users are not stupid--contrary to about 90% (caution: made up statistic) of technologists complaints. They just happen to have a different job than us. I mean it's easy for us to look at some poor overworked doctor (for example) and claim he's a moron because he doesn't know the difference between suspend and hybernate--but then, the reason why he doesn't know the difference is because he's more worried about knowing the difference between opioids and non-opioid drugs and knowing which class of drugs will better relieve his poor cancer victim's pain.
    • Re: (Score:3, Interesting)

      by diverman (55324)
      >> Bottom line, my opinion, users are not lazy, they just want to get some work done without needing the equivalent of a Bachelor's in Computer Science to get that work done.

      I wouldn't say user's are lazy, but they often don't seem to care about the choices that exist in what it is they want to do. Regardless of needing a bachelor's degree in computer science, how about at least understanding the complexity of the task they've chosen to do, or at least have some appreciation for the complexity. The
    • I see the same old argument over and over again about computers. "Users want toaster-level easy." This is only true for someone that might have NEVER used any modern technology. Pretty much everyone that uses a computer invariably finds new things to do with them, or wants to do new things, and thus your toaster also needs to be able to cook bacon and eggs - not so simple any more.

      If you want to toast bread, buy a toaster. If you want to print photos, get a photo printer, no computer necessary. If
    • by cinexero (983612)
      Prehaps it is consistent across flavors (kinda) but take something as simple as quiting a CLI app. Oh, that's simple you say, just type c * Man: q * Vi/Vim: :q or :wq if you wanna save * Nano: x * Octave: quit() * Axion: )quit * EMACS: x, c Do you see the mounting frustration? Do you know how many new *nix users admit to restarting a machine/terminal because they could not figure out how to exit the man pages! And don't get me started on command/app names... Vi vs Word Pad.... Hmm tough choice...
    • by ericfitz (59316) on Friday January 05, 2007 @07:35PM (#17482616)
      I agree with you about Macintosh, but Linux more consistent than Windows? Give me a break. Let's get past the /. mind-numbed-robot FOSS advocacy and anything-but-Micro$oft FUD for a second.

      If there is one thing that Windows does well, it's consistency. Cut, copy and paste work the same in 99% of Windows programs. They do NOT work consistently across Linux programs that often use different underlying graphics toolkits, etc., and different shells, etc. Also every single one of the command-line utils in any flavor of *nix has a unique syntax. That's not consistency.

      I'm not trashing Linux or glorifying Windows, but let's give credit where it's due. Windows is remarkably consistent and that is probably one of the main reasons for its commercial success.
  • Should software 'just work', or are users too lazy?

    Yes, and usually (but it depends on the market).

    Of course, there are a lot of things that aren't excluded by those constraints. For example, software may be simple-but-effective or complicated-but-powerful, yet still "just work" for its desired target audience. It can lead new users clearly and effectively through the more complicated functionality, yet still provide a streamlined interface for experts who already know the software and don't need thei

  • by iplayfast (166447) on Friday January 05, 2007 @03:45PM (#17478394)
    Ninety percent of your users will not have an opinion about your software.
    Ninety percent of the users who have an opinion, will have a misconception about what the software is supposed to do.
    Ninety percent of the users who understand what the software was supposed to do, will have a preconceived idea on how it should work based on their experiences with your competitors.
    The final 10% of the people who have an opinion, have no misconceptions about the software, and have no preconceived idea, will have useful input.

    Unfortunately 90% of those people are idiots.
    • Poochie!! (Score:3, Informative)

      by porkThreeWays (895269)
      Man: How many of you kids would like Itchy & Scratchy to deal with
      real-life problems, like the ones you face every day?
      Kids: [clamoring] Oh, yeah! I would! Great idea! Yeah, that's it!
      Man: And who would like to see them do just the opposite -- getting
      into far-out situations involving robots and ma
  • Let's draw back... (Score:5, Insightful)

    by neimon (713907) on Friday January 05, 2007 @03:45PM (#17478404)
    ...a few thousand miles.

    If people are bad at figuring out what they want from a computer, and terrible at designing (which, yes, they are) then maybe the problem is that the computer sucks. General-purpose computing is best left in the hands of experts. That model worked for 20-mumble years, and it was a good one. It still is, if you need to get industrial-grade stuff done.

    But "personal computers," to be distinguished from "desktop computers," are a bust. Ordinary people can't deal with the complexity, and attempts to make computers act like a friendly thingy with stuff on it all fail because the computer isn't a friendly thingy with stuff on it. It's a computer.

    People need, say, the Pure-Digital video camera that lets you take digital video with one button, has no memory cards, and runs on aa batteries. They need the microwave oven with the popcorn button. They need the car with a computer in it so they don't have to know when to use the choke. Special, optimized uses of computers work great for ordinary people.

    People aren't stupid, they just don't act like a computer. Maybe there's a lesson there.
    • by megaditto (982598) on Friday January 05, 2007 @04:30PM (#17479368)
      Reminds me of that Bible story where Moses was taking some escaped slaves for a walk in a desert that lasted some 40 years.
      When asked why it took him so long to get to a free land, he replied that they had to wait for all the former slaves to die off, since only their kids could be trully free.

      My point here is that most kids (9+ years) these days have no problem getting their family computer to do just about anything they need, so in 20+some years when their parents will pass away, all the 'luser' issues will go away.
  • by Oz0ne (13272) on Friday January 05, 2007 @03:46PM (#17478420) Homepage
    I totally agree that most software sucks. I'll even admit that some apple software sucks, but since switching (almost 2 years back now,) my world has completely changed. I'm no longer frustrated most of the time when working with my computers.

    I've been a software developer for near a decade. There's two extremes to this, ignoring your customer, and letting them run the development, both are bad. The best path is to have some intelligent people in your company that sit in between customers and clients and act as a translation layer. Throw out the ideas you can't implement, give them the good ones. These people have to be at least partially developers themselves, they serve as architects as well as PR.

    Customer Ideas -> Architects -> Code Monkeys

    • I totally agree that most software sucks.

      I'm about to throw Firefox and yahoo.com out a fscking window, because Firefox intermittently ignores the scroll wheel on my mouse. Also happens on Slashdot.

      Sorry, I had to get that off my chest, and when the scroll wheel stopped working and I was forced to go to the elevator bar to scroll past a story about how software sucks, well...

  • by MadTinfoilHatter (940931) on Friday January 05, 2007 @03:48PM (#17478452)
    On a completely different note, I just bought a guitar, but I'm going to return it because I think it should just produce the music I want to hear when I hammer at it like a retarded orangutang. Someone told me that I'd have to take the time to learn stuff like "notes" and "rhythm" and who-knows-what. That person obviously just doesn't know how to make a guitar. [/sarcasm]
    • by Quiet_Desperation (858215) on Friday January 05, 2007 @04:02PM (#17478742)
      It's more like buying a new "upgraded" guitar, and in order to hit any flats or sharps, you have to open a small panel on the back and hold down a button. Oh, and replacing a broken string may lead to complete inoperability.
    • by captainjaroslav (893479) on Friday January 05, 2007 @04:03PM (#17478782)
      Okay, so you're being sarcastic, but you're also missing the point. A better analogy would be somebody who wants to listen to music and is given a guitar rather than a radio. Sure, if they put in the time and effort, they could eventually learn to play the guitar and possibly even make better music than what they could find on the radio but it's not really a reasonable answer to the person's need.
      • Re: (Score:3, Insightful)

        by Spaceman40 (565797)
        (Where's Bad Analogy Guy when you need him?)

        To take this one a little farther: If you give someone a guitar rather than a radio, they can produce content. The person with a radio can only consume. Producing content will always be more complicated than consuming it (law of entropy-ish).

        (Tangent: There are definitely different degrees of difficulty on the production side, though. There was an article I saw (probably on here) about interface design needing to be simple but powerful. A lot of interfaces can
  • The problem is that even the most competent programmers tend to know C++ better than English.
    • by yeremein (678037)
      The problem is that even the most competent programmers tend to know C++ better than English.

      Hey, I resemble that remark!\n
  • by ewg (158266) * on Friday January 05, 2007 @03:51PM (#17478516)
    It's true that developers don't think like users, but that's not the only reason software is hard to use.

    In most cases in business, users aren't the ones making software buying decisions. The organization makes choices for them based on a number of factors. There's no conspiracy against usability, it just has to compete with cost, features, regulatory compliance, and other considerations. Software developers naturally target the criteria that drive purchase decisions, even if the result is a compromised user experience.
  • by wuie (884711) on Friday January 05, 2007 @03:51PM (#17478530)
    I'm reading TFA, and some of this stuff is just silly.

    For instance, the "Save" button. He argues that a statement that says "Do you want to save your changes before you exit" is a hard sentence, and that "Do you want to throw away everything you just did" is a clearer sentence.

    The word "save" isn't that hard of a word to grasp. People save money. People save possessions. Saving documents is no different. Grade schoolers understand it.

    What really cracks me up, though, is that he argues that when deleting documents, there should be *no* confirm. I've had a few times when that windfall was really helpful, when I've accidentally hit the delete button or selected delete, and then said "No, I don't really want to delete this file." He compares it to starting a car, where the car doesn't ask you if you want to start the car or not. This is a horrible analogy: the last time I checked, turning a key didn't do something as devestating as, say, deleting your car.

    I deal with end users every day, and I've had many of them admit that they don't read error messages or confirm dialogues. If they don't read it, what difference does it make what's included in the dialogue? I've made messages that were very easy, simple to read and understand, only to have them overlooked.

    Next, the author mentions that error messages need to state *why* something failed. Wait a second... I thought he was just arguing for simpler error messages, but now he wants to know specifically what happened? That's not exactly simplifying things for the end user.

    Now, I'm not saying that it's all the fault of the end users. There are some rather atrocious error messages out there, but it'd be safe to say that there are more end users out there that don't read things carefully. Computers are a tool, not a replacement for thinking, and users need to know that in order to get the maximum use out of technology.
    • Re: (Score:3, Interesting)

      by markov_chain (202465)
      Good points. Now that we're doing car analogies again, note that most cars won't start unless the shift selector is in Park, or won't let the user move the selector out of Park unless the brake pedal is depressed. Sounds like the Fox author is a weenie.

      I don't even agree that software sucks, I'm perfectly happy with most of it. In fact, what am I even doing here reading this?

      /backtowork
    • "This is a horrible analogy: the last time I checked, turning a key didn't do something as devestating as, say, deleting your car."

      Wait until you install MCE in the dashboard...
    • by arkanes (521690)
      Whenever a tech writer feels like he needs a little more exposure he writes something about how programmers don't write good interfaces, and they're condescending to users. It's trivial, obvious fluff writing that people have been doing for at least 20 years. There's never anything new in the articles, and most of what *is* in them is wrong.
    • by Quiet_Desperation (858215) on Friday January 05, 2007 @04:05PM (#17478816)

      This is a horrible analogy: the last time I checked, turning a key didn't do something as devestating as, say, deleting your car.

      Well, outside of organized crime, anyway.

      Tends to delete the user as well.

    • How about this silly, uncited claim:

      To illustrate his point, he notes that computer programmers tend to prefer manual transmissions. But not even 15 percent of the cars sold in the United States last year had that feature.

      I checked Google, and the only page that is even closely related to the claim is a blog post by "Joel on Software." Ironically, Joel can at least explain in technical terms what it is about a manual transmission that might appeal more to a computer programmer.

      Regardless, it's a silly claim. It's just an attempt to pigeon-hole two groups that are a minority of the population into the same hole. I agree that there's a disconnect between developers and users, but it has not

      • Re: (Score:3, Insightful)

        by Tim Browse (9263)

        I checked Google, and the only page that is even closely related to the claim is a blog post by "Joel on Software."

        In addition, here in the UK, almost all cars have manual transmission. I can't remember the last time I got into a car in the UK that had automatic transmission. You can get automatic transmission if you want (on probably almost any new model now, I'm guessing), but you have to request it.

        Does this mean that the UK is populated entirely by programmers? If so, how come I have to help people with their computers so often?

    • by 99BottlesOfBeerInMyF (813746) on Friday January 05, 2007 @04:22PM (#17479200)

      The word "save" isn't that hard of a word to grasp. People save money. People save possessions. Saving documents is no different. Grade schoolers understand it.

      Part of the problem is that computers intimidate users. They never know if it is going to break when they do something. "Save" is a term that is strongly associated with computers these days. Saving a file and saving changes aren't so much "saving" as they are writing something to a semi-permanent record. They don't fit well with the document/folder metaphor because on paper people save a file or they toss it, they don't save part of a file or undo all the writing they have done in the last hour but keep the file itself and the old work. On the back end saving changes or saving a new file is pretty much the same thing. You write to disk. It is not so in the minds of many users.

      What really cracks me up, though, is that he argues that when deleting documents, there should be *no* confirm.

      It is hard to see what the author is arguing from this brief bit, but he's right that their should not be a dialogue confirmation. Users already have a trash can they can look through and it properly asks for confirmation. When you delete a file, it goes to the trash and you can always take it back out. The huge number of dialogue boxes, particularly on Windows are a classic design flaw.

      If they don't read it, what difference does it make what's included in the dialogue? I've made messages that were very easy, simple to read and understand, only to have them overlooked.

      Many dialogue boxes don't even give the user a choice and most users simply click "OK' over and over again until it is a conditioned response. Worse than the number of dialogues is Window's penchant for keeping the buttons the same, which facilitates this behavior. Is it so hard to have it say, "Do you really want to throw this file away, (Throw it away)(Don't throw it away)." With such a message the user must read at least the button, at which point they know what action is being taken because the button is itself an action, not "OK."

      Next, the author mentions that error messages need to state *why* something failed. Wait a second... I thought he was just arguing for simpler error messages, but now he wants to know specifically what happened?

      Messages need to be fewer and clearer, not necessarily simpler. Adding more information in a dialogue is just fine, so long as it is properly constructed.

      There are some rather atrocious error messages out there, but it'd be safe to say that there are more end users out there that don't read things carefully.

      Yeah, and dogs salivate when you run the can opener. If you build a system that operant conditions people, you bloody well shouldn't expect them not to be conditioned, especially when they're just trying to get things done and don't care about using the computer at all. It is a tool, and a badly designed one in many ways.

    • Good, fast UI (Score:5, Insightful)

      by tfinniga (555989) on Friday January 05, 2007 @04:24PM (#17479248)
      Something that I learned in my UI design class was that when designing interfaces - the less risk there is associated with each action, the faster the UI will be to use.

      So, exactly like you said, there's less risk in turning the key to your car if there's no chance that sometimes it will mean your car disappears. If there was that chance, you'd have to train yourself to check and doublecheck the state of your car before turning the key. This would slow you down quite a bit, and would be bad UI.

      Instead of just deleting the car, the car's UI could confirm with you (similar to popping up a dialog) when it seemed like you were doing something that you might not want to. Or it could keep you from doing it altogether, although that would mean less capability.

      However, a better solution is to make everything undoable, quickly and easily. In the case of deleting files, if you delete files, they are deleted. If you save over a file, the previous contents is gone. But if you want to bring them back, make it easy and always possible. For much of computing history, that wasn't really feasible, due to performance and storage constraints, so they opted for confirmation dialogs. But those technical limitations are much closer to being removed now, at least for simple interactions by untrained users. For those playing at home, see Apple's Time Machine [apple.com]. For more complex interactions, pushing the limits of the machines further, I imagine you'll still rely on better-trained users.
      • Re: (Score:3, Insightful)

        by RAMMS+EIN (578166)
        ``But if you want to bring them back, make it easy and always possible. For much of computing history, that wasn't really feasible''

        Yet VMS had versioning ages ago.
  • by 99BottlesOfBeerInMyF (813746) on Friday January 05, 2007 @03:52PM (#17478542)

    RANT: Designing good, easy to use software is not as hard as many people to think, although writing it is harder than what most people do now. User's are not good at designing software, but only the user knows what they want to do and how they want to do it. This should be the beginning of the UI design. "What does the user need to do, and how can they do it most effectively." This should be almost completely divorced from how the program goes about providing the functionality. Usually, the UI should be up and running before the back end is really started. Most software today is designed the other way around. "We can make software that does this and this and this, now how can we let the user get to those features." The term "user centered" is in contrast to feature or engineering centered. Users should not be designing it, but you do need their input and testing to see what works and what doesn't. Follow the basic rules of UI development and you can miss many obvious problems, but at some point you need users to show you what you missed.

  • Movies, Music, games - other kinds of totally different softwares. Movies are non-interactive, yet, are as complex as a piece of software. If you can engage your user with the software, you job is done. Id say a writing a piece of software that people would like is an Art form - not science. Much like movie making. No school can teach you that. Case in point - Steve Jobs. Point made.

    In other news - who's the David Thomas the articles refers to. Wikipedia [wikipedia.org] has nothing on him. David Platt - the author of th
  • Users expect far too much. Yes I admit there is a lot of software out there that is confusing and difficult to use. However one does not expect to sit down in a car and expect to be able to drive it without learning or being shown how to do so first. Similarly with kitchen devices such as ovens, even frying pans. You cannot expect to be able to use something easily without taking the time to learn to do so.
    • Re: (Score:3, Insightful)

      Well, if i can drive a chevy, i can drive a honda, and a buick. Maybe I can't drive a Panoz, without additional training, or a semi, but i have a descent idea of what I am doing.

      I think it is reasonable to say that some developers fail to realize that making a program familiar and consistent is very helpful.
  • My company needs a custom, web-based, Database driven app built. We have a pretty good idea of what we need it to do, and I have a good idea of how I want it to work. Now, I'm not a developer, I'm just the sysadmin, and the one in the office with the best understanding of computers. How can I best convey what it is that we want built to the developer (we already have one lined up.)
    • Re: (Score:3, Informative)

      Write a requirements document.

      Put in measurable terms (at least as much as possible), what you want it to do. This has the added benefit of making *YOU* think about what it needs to do, as opposed to having a "pretty good idea".

      Second, the UI is king. Make sure the UI reflects what needs to be done, and not the internal architecture of the program. For example, I've been using a tool (which shall remain nameless, to protect the guilty), where to change a displayed value in a table, I can't just double-cl
  • People keep paying for it. Look, if you don't know what "The program is closing, do you want to save the changes since your last save or discard them?" means, you shouldn't be using a computer. They bring up the car analogy (I read this elsewhere), but they leave out one crucial part:

    Anyone can use a computer, you need to study for a license to use a car.

    That's why people accept the way cars generally work, they've been taught about it. They have experience. If you sit down at a computer, try your best ne

    • by whoever57 (658626)
      The save dialog exists for a reason and is well thought out, in my opinion.
      While I disagree with many of his comments, let me suggest a change to the save dialog: No preceding question, just 2 buttons:

      Save Changes

      Discard Changes

  • by Phrogman (80473) on Friday January 05, 2007 @03:57PM (#17478666) Homepage
    I don't think the typical user wants to be bothered learning to use a piece of software, they are focused on the task they have to accomplish. If your software easily facilitates that task, with the minimal (preferably zero) learning curve, then they think its a good program, if it obfuscates that task, requires more extensive learning, or simply doesn't perform in the manner they expect it to, then its a bad program. Rightly so in most cases. Its only those in highly technical fields - or computer programmers etc - that usually need software with any real complex functionality. For those individuals, the cost of the learning curve (time and effort) is worthwhile if its more efficient that some other method of accomplishing some complex process or processes (time and effort).

    Most programs seem to come with more bells and whistles than they need to, but then I guess they are trying to provide all the tools that I *might* be looking for in one package. I have never used more than about 10% of the features in any office suite for instance, mostly I just want to present a document containing well formatted text in the font I want.

    The only place I appreciate complex software is in the areas where it suits my needs - a good IDE, Editor, graphic and sound manipulation software, and the Games I play. Outside of that most software is more hassle than its worth and I resent having to learn to use new programs just to achieve one tiny task.

    I think the answer is coming in individual devices that serve specific functions and don't try to go beyond those functions. My cellphone has no camera, no email, no web-browser etc, but it does let me talk and receive calls. Thats all I need it to do. If I wanted the bells and whistles I woulda shelled out $350 Cdn for a Razor :P

  • by wiredog (43288) on Friday January 05, 2007 @03:58PM (#17478670) Journal
    Most of my end-users are as well. We're unhappy with 'doesn't work' and especially with 'fails randomly, in interesting and unrepeatable ways'. Sure, most software sucks on some level. The users want it fast, cheap, and working (choose any two), the programmers (including me) want it to work excellently. The stuff that ships is a compromise between 'works' and 'insanely great', the level of compromise defined by budgeting and timelines.
  • We have a massive database-interfacing program, that keeps track of everything for medical records...it's truly a monster of a program. There's at the moment 9 full-time .NET programmers working on it (prior to switching to .NET it was a VB6 thing...which sucked); anyway, there's a lot of work that goes on with it, and aother group (3 people) get to determine what information is added, removed, or accessable from the main program. These three are supposed to be experts. But they're just reactionaries to wha
    • Re: (Score:3, Insightful)

      by mollymoo (202721)
      Out of curiosity, why do you choose to work with reactionary morons? Perhaps if morons couldn't retain staff their software would be even worse, the morons would be sacked or their companies would fold and there would be less crappy software out there. If you consider yourself an above-average programmer (and who doesn't!) you can help make software better by choosing not to work on shit, so the morons only have sub-par programmers working for them.
  • This is a common issue in products designed for functionality rather than how easy it is to use, which, unfortunately is a major issue with quite a few of the big software packages. When I tried to use the GIMP for instance I was greeted with a horrible mess of floating windows and quickly switched back to paintshop pro (I only do light editing). Linux had to deal for years with requiring users to use a commandline interface to do certain things and although it's improved greatly, unexperienced users readin
  • Yes, it would be nice if all software "just worked", but, until we develop Strong AI (such as HAL... hmm...), this is not possible. Since a user can't just tell his computer, "do my taxes for me, pronto !", the user will have to use his own intelligence to instruct the computer in what to do. This means that they will have to learn how to talk to the computer in its own language. The best software strikes a balance between the steepness of the learning curve, and the power it exposes to the user.

    Apple tends
  • by pla (258480) on Friday January 05, 2007 @04:06PM (#17478840) Journal
    Users don't know what they want.

    No frickin' kidding.

    If you give users a choice between two mutually exclusive features, they will answer "yes". They will then complain at needing to pick one at runtime (or complain that you didn't include the other option, if you made the choice for them).

    If you ask them if they need proveably-never-used features X, Y, and Z, they will vehemently insist they do. They will then complain that the final product confuses them with far too many features they don't need.

    If you ask them how they want something to work, they will either A) Shrug their shoulders (then later complain you didn't listen to their input); B) lie to hide their own abusive behavior (then later complain that they can no longer get to their por - ahem - family photos); or C) Give a long, detailed explanation of what they (then ask what madman came up with how the final product works).



    Should software 'just work', or are users too lazy?

    Both. Software should do one task very, very well. If it doesn't try to manage photoalbums while doing your taxes and making coffee, it can perform its function well while not overwhelming the user with confusing options.

    At the same time, users need to realize that computers have FAR more complexity of control than their car. In most states, to drive a car, you need to have reached a minimum age, pass certain tests of physical capability, take a six week training course and pass a written test on that material, and finally take an actual road test to prove you can handle a vehicle - And even after all that, you usually have only a probationary license until you've remained incident-free for a few years. Yet software should "just work"?

    Where can I sign up to sue Chrysler over my car not automatically driving me to work (with an unannounced side trip to the grocery store) when I get in and turn on the wipers?
  • > While technically inclined individuals tend to want control,
    > Platt argues, most people just want something that works.

    And after "most people" have used a program for a certain amount of time, they'll also want control. That's part of programming - figuring out a way to make an app immediately accessible while still allowing advanced users to do what they need to do.

    For the app I work on, indi [getindi.com], it should be easy to create a secure channel, but maybe it's a little harder to customize your profile st
  • One big reason why software sucks is that the internal data structure is exposed at all levels. Rather than appropriately abstracting data at various levels, and proper interfaces developed, the original organization of the data drives the entire process. This means that either data must be organized to match real world expectations, or, more commonly, data is organized in a machine effecient manner and the user must adjust.

    The most common examples of this are websites. Some websites are organized by t

  • by MagicM (85041)
    No, YOU suck!
  • Yet another article comparing software with cars, claiming cars are so reliable and usable while his computer is not. He even uses cars as an analogy insight into programmers's minds. 15 percent of cars sold in the US have manual transmission, but how many among the 85 percent who bought an automatic would have claimed they prefer manual as well? Does the fact that most programmers are men influence the programmer's profession for "control" as represented by a manual transmission?

    Additionally, cars aren't a
  • by flaming error (1041742) on Friday January 05, 2007 @04:15PM (#17479052) Journal
    I'm the lead software developer on critical carrier infrastructure software. I get vague market requirements, no spec, and despite repeated requests my company won't send me to customer sites to see how they use the software. Most input from the field is not forwarded to me. I deliver a product I'm reasonably proud of, but whether it's what customers want, I couldn't say. If it's not, don't blame me.
  • would taunt the user and tell them to RTFM, or if they want that feature to open up the source code and write it themselves.
  • He wants it to default to saving, but doesn't want to confirm to delete?

    I see my car prompting to start like my computer prompting to create a new file.

    I see prompting to delete a file like prompting to drive into a wall.

    The problem is that most people don't care what they're doing, they just want to be done it without thinking.
    Many technical people aren't like that, they want it to be done, but done their way.

    The idea of automatically doing the default action doesn't make sense to me, but for many people t
  • On the other hand, the article also cites David Thomas

    He demanded more pickles and square burgers. He thinks this is the big problem with software today.

    Oh, and a biggie Coke too... he's in favor of that.
  • Users want software to be psychic and do what they mean not what they say.

    Programmers write robots that do what they say. There in lies the fundamental problem.

    They say they want everything to be as simple as a toaster. But they also want their toasters to toast bagles, and control the browning and they sometimes toast twenty batches of toasts in a row, and sometimes only one single piece of bread and they want the toasting to be as fast as possible too. They would also like the toasters to make coffee a

  • ...it was difficult to learn the ins and outs of our users (flight dispatchers and pilots) because their jobs were themselves quite technical, required specialized vocabulary, etc. But that's what our business analysts were for (to act as an interface between the end users and the software developers). Most of them were former dispatchers or pilots themselves, so they understood the user issues, and some had programming experience as well so they had some handle on technical issues.

    Our design process was
  • Software should just work. Of course, that is oversimplified.

    Too many times a project goes like this: Customer places request. Project Mgr talks to client. Requirement Analyst turns request from PM into low level requirements. Programmer reads requirements document, writes program. User gets program and guess what? It's not what he wanted! So, he places another request, and we are back to square one. Sound familiar?

    Users request crazy things. Sometimes, they ask for things to work around other
  • Part of the problem was the whole desktop metaphor. It's slightly implemented, but just for pretty pictures. For example, when I want to save some physical document I'm working on, I either drop it into a folder or a binder. The current desktop metaphor is to navigate a menu system to save the file in a hierarchical location that's easier for computer OSes to manage. Why can't I just drag the document to a folder?

    When writing a document with pen/paper I can easily pull back revisions since I just cross the
  • I think at the heart of this issue is the concept that computers are supposed to abstract complex ideas and/or operations.

    Let's use the example of something that is very common with computers: editing a document.

    Editing a document, producing a pleasing, flowing layout is not a trivial task. How could any application that abstracts this idea not reflect most of the complexity of the task? That said, I think most modern document editors are far from perfect, but I don't think they will ever be completely triv
  • You don't want your customers to design your product,' he said. 'They're really bad at it.

    I would disagree with that statement. Most users I work with know exactly what they want, after seeing what they don't want. That's why, in my opinion, organizations that put a huge amount of effort into requirements gathering are, for the most part, wasting their time. Your users won't know what they want until they see what they asked for. A prototype. I know, a lot of you hate prototype development, but user

  • by logicnazi (169418) <logicnaziNO@SPAMgmail.com> on Friday January 05, 2007 @04:38PM (#17479576) Homepage
    I think a perfect example is OS X. It just works for the users like my grandpa who want that but offers easy access to the command line and BSD parts for the technically inclined.

    The key is good UI design, in particular good separation between advanced options and standard options. Windows fails because far too frequently a normal user needs to go access the advanced features so all the advanced features and terminology are there to confuse the user. Try sharing files in windows and you need to do arcane things like change the workgroup name. Just to check if I could uninstall programs I've needed to run msconfig. Conversely on a mac the normal user just deals with the preference pane and never has to run command line programs or the like.

    I don't mean to be a mac zealot. They've done things wrong as well (I'm pretty pissed about their special power cord) but they did a good job of separating advanced from basic features, partially because they were willing to jettison the old ways of doing things.

    In any case good design doesn't require a choice between power and ease of use. It just requires a clear cut distinction so the normal user never needs to deal with the advanced features.
  • false dichotomy (Score:3, Insightful)

    by RaymondRuptime (596393) <raymond&ruptime,com> on Friday January 05, 2007 @05:07PM (#17480168) Homepage
    Where does your opinion lay? Should software 'just work', or are users too lazy?

    These choices are a false dichotomy. It is possible to have products which just work and which allow users to access more advanced features (and rewards them for learning a little more about what they're trying to use). The UI principle [which should be] at work is called "progressive disclosure": don't overwhelm the user with stuff they need to know or complex steps they need to follow for basic tasks to be accomplished, but let them work their way up to it.

    A good example is the UI of a well-designed VCR. Power-on and Play are big buttons right on the front, and the more complicated stuff is behind a flip panel. My non-/. parents don't want to program a Mars rover; they just want to put in the tape of their grandchildren and watch it. On the other hand, my wife who doesn't want Tivo programs complicated, recurring weekly recording schedules; and she took the time to learn how to do it, and has figured out which VCR you just hit Power-off and which VCR who have to hit Power-off and Timer together. And I just want to flip the panel and find some arrow buttons so that my parents' VCR isn't flashing 12:00 while I'm trying to visit with them.

    If you want to do something more sophisticated, you need to expect to learn a little about the application you're using; and IMHO most reasonable people are willing and try to do so. But you should be able to just push Play without knowing which codec was used.

  • Perfect timing (Score:5, Interesting)

    by BlazeMiskulin (1043328) on Friday January 05, 2007 @05:41PM (#17480788) Homepage
    This post couldn't have come at a more precipitous time. I work for an educational facility which uses a web-based "business portal" for all of our HR, Payroll, Purchasing, and Accounting functions. At this very moment, I am (pretending to be) entering data into this system. There are (on a guess) 100 fields that need to be filled. About 85 of them will always have the exact same data. Another 12 will be identical for every entry from the same order. Only 3 are unique--and one of those is the auto-increment primary key. It requires 3 mintues and 5 different forms to enter all this information. And all but 2 fields could automatically be captured by the system and applied to the form (right now, we're just reading it from one form and typing it by hand into another form). Now, this is a program that's supposed to improve the efficiency of the businesses that use it, however, it's laid out in ways that actively hamper the effective use of the software. This is a perfect example of a situation in which you absolutely want the users telling the programmers how to do things--not how to build the code, but how to design an interface that allows for smooth, efficient use of the tool. I run into the same situation in so many programs, and it really frustrates me. I think one of the reasons that Apple has become so successful in the various niche markets is because they put so much emphasis on creating a smooth interface between the users and the code. Most users don't care about the code. They care about how easy it is to accomplish what they want to accomplish. There's no reason that a program can't both be properly-coded and "just work". The two are not incompatible.
  • by mkcmkc (197982) on Friday January 05, 2007 @06:17PM (#17481452)
    A few reasons that software sucks:
    1. Programmers don't really understand users' domain,
    2. Users don't really understand programmers' domain,
    3. Users don't really even understand their own domain, and finally
    4. Programmers don't really understand their own domain either.
    The first two are obvious enough, and programmers eventually see instances of the third. As for the fourth, most programmers do not even know of the critical insights of the field (e.g., The Mythical Man-Month, Dijkstra's essays), let alone accept them (or knowledgeably deny them).
  • by FiloEleven (602040) on Friday January 05, 2007 @06:29PM (#17481664)
    Several slashdotters have already pointed out why the car analogies that (apparently) pop up in the article as well as in the comments fail. Ultimately, a comparison between computers and "real-world" devices fails because of interface.

    To start a car, you turn the key clockwise. To open a new file, you click with the mouse.
    To stop a car, you push the brake pedal. To save a file, you click with the mouse.
    To turn a car off, you turn the key counter-clockwise. To delete a file, you click with the mouse.

    A significant factor in the difficulty of software use is that when we speak of "interfaces" we are almost always thinking one level lower than we should be - that is, no matter how nice and clean and useful your GUI is, the real interface for ~90% of software users is the mouse, keyboard, and monitor, regardless of what is displayed on it. In a car, turning the car on or off is an entirely different motion than making a right turn, which is different from putting on the brakes, which is different from putting down a window. We also have years of experience riding in cars and watching parents drive as children to teach us that "when Daddy does X, Y happens."

    Computers are fundamentally different. Using only a mouse and keyboard and looking at a monitor is for all intents and purposes the only way to interact with the computer. Watching others use it to learn doesn't work nearly as well because the movements involved are much more precise, less varied, and their effects vary greatly depending on what state the computer is in: moving the mouse in a word processor moves the pointer around, while in Quake it'll change your view of your in-game surroundings.

    Encouraging software makers to adhere to user-interface models helps a lot -- once the users are familiar with the model. Our current practices are inconsistent at best - the "desktop" metaphor exists only at the most basic level; once an application is open there is generally a half graphical, half menu-driven approach. From what I've seen, I think the Ribbon interface in Office 2k7 is an improvement, albeit an incremental one. I don't pretend to have a good model that will help ease-of-use, but I think the problem is on the decline anyway.

    Those of us who grew up with computers do not have issues with the mouse/keyboard interface; we are familiar with it and the software models underneath. I have a feeling that as younger generations join the workforce, the interface problem will disappear or at least be greatly reduced. As long as some consistent GUI guidelines are followed, I believe that the metric for "ease-of-use" will evolve so that more complexity and control can be folded into the software without complaints from the users.

No amount of genius can overcome a preoccupation with detail.

Working...