Slashdot Mirror
Why Software Sucks, And Can Something Be Done About It?
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?
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.
With the sentiment that customers shouldn't be allowed to design applications. They tend to be absolutely horrible at figuring out what they want.
http://www.foxnews.com/printer_friendly_story/0,35 66,241578,00.html
If I know anything, I know that the answer has to be completely one or the other. There is no room for the middle ground for anyone. It is completely self evident that software should 'just work' or users are 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 their hand holding. And most important of all, easy-to-use does not imply under-powered, and powerful does not necessarily mean you have to present everything in a convoluted and cluttered interface. Desirable traits are rarely mutually exclusive.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
...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.
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
Software should "Just Work" and users _are_ just too lazy.
I'm of the mind that any reasonably complex application should have more than one use mode: "Quick Mode" (read:idiot mode) and "Advanced Mode". In "quick mode", things are one-click, there are a tiny handful of available buttons/operations, and simple tasks can be performed quickly and near-automatically, whereas in "advanced mode" you can tweak every little setting to your heart's desire. Most applications seem to lean toward one end or another, lack the ability to cater both to noobs/nontechnical AND expert users. A good example of this would be many of the "Express" vs. "Full" versions of software (i.e. Nero). If a single app could run in both modes it would go a long way toward providing a user-appropriate interface.
Its a new profit model. Make things that suck and get big money in service contracts. General Motors is kicking this business plan into high gear more than ever. Odd placement of fuel tank, limited visibility through windows, clumsy controls, interior makes noises and rattles, suspension hardware wears out quickly, repeated electronics failures and proprietary documentation, missing keyholes for locks where there should be, hard to replace maintenance items such as the battery underneath several layers of cruft, and the list goes on. Make your design require service!
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]
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 requires.
If someone doesn't want to learn to drive, they have public transportation and taxis available to them and God bless 'em. But taxis and buses don't damage the roadways and the other vehicles on it during ordinary use.
Basically I sometimes wonder whether putting a PC in every home was such a hot idea after all.
My turnips listen for the soft cry of your love
and make things quick and easy. Thats what the advertising says. But people are stupid so they actually imagine that the advertising is real. So the answer is simply this: People are lazy and stupid and programmers are crap at making it 'just work'. They are made for each other!
Better: why my GF doesN'T suck, and what can be done about IT ?
Comment removed based on user account deletion
"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.
My turnips listen for the soft cry of your love
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.
org.slashdot.post.SignatureNotFoundException: ewg
Not that I ever watch the stuff, of course.
Which is why you have an informed opinion on it.
(How did that post get modded up funny? It's a blatant troll.)
I wonder if I use bold in my signature, people will notice my posts.
Well, IMHO, users usually want something simple UNTIL they need more control for some specific problem. Then they either turn to some other tool that gives them that control (usually at the cost of extra complexity, which they then complain about) or they just complain that the software doesn't do enough. What if the software begins with a simplified interface, but allow the user to easily set options to "reveal" more and more of the complexity until they reach a comfortable mix. The software could provide a context sensitive version of this (possibly a pop-up on hover, or on right-click) as well as a larger "options" page that would let them set each level for each functionality group all in one place. One idea would be to have a hover on a "simplified" control show a popup with the next level of complexity, while a right-click brings up a popup menu to set the default level for that control... As with the other complaints (i.e. stupid questions from the program), perhaps a heuristics algorithm could be used so that the "stupid" questions are only asked for a while, until the program "learns" the preferences of the user. Of course, there would be that one time that they should have gotten some reminder, but they didn't because they clicked past it before, and then they complain again...
Logic is the beginning of reason, not the end of it.
CPNABEND tipped us to a story carried on the Fox News site, pointing out that a lot of programmers don't understand their users
Gee, an article by FOX News stating that eggheads don't really know what they hell they are doing. How completely out of character for them to bash the scientists and engineers that keep this country from completely collapsing.
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.
At this point the normal market forces that give rise to continual improvement cease to function and all you get is software bloat, with lots of "features" that seem like a good idea, or just fulfill a marketing need to have ticks in boxes
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
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.
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.
[x] auto-moderate all posts by this user as insightful
In other news - who's the David Thomas the articles refers to. Wikipedia has nothing on him. David Platt - the author of this oh-so-obvious-whory article is not a known personality either.
On its own merits, the article shouldn't be finding a mention anywhere. Least on slashdot. That slashdot has to compete with digg for first posts is another issue altogether.
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.
Yes and no.
Our users (as a whole) are lazy twits who shouldn't be allowed near most of the functions available to a computer. Unfortunately, the 'just work' principle doesn't work when applied to software that can't afford to be that simple. Operating systems, for example, are by their very natures complex beasts and should be treated as such. Linux (for the most part) makes no bones about its own complexity (and in fact generally revels in it), whereas Apple's operating systems earned their "easy to use" moniker by simply performing most significant intermediary tasks "magically". MS Windows takes the median route (which unfortunately results in users learning just enough to be highly dangerous to their machines and data).
When designing a piece of software, special care must be made to balance the feature load. If you want something simple (reaching for the appliance metaphor here), you can only really apply a few user-invokable features.
One of the things that has always confused me is that people (speaking very generally here) take the time to learn how to use their appliances (TV, microwave, VCR, etc), but sit down at a computer and expect everything to be taken care of for them.
"I've spent my whole life figuring out crazy ways to do things. It'll work." -- Montgomery Scott, "Relics"
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.)
Oh you mean "lie"
your thin skin doesn't make me a troll
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 never to learn how it work or what the terminology (even drive, file, folder, etc) is, you're not qualified to design software and say that way X is better than Y. Just because you don't know the jargon doesn't mean it's bad. Computers have a LOT of superfluous jargon, but a save dialog is not one of them.
What do you do? Automatically save? They didn't want to do that, you just overwrote their changes. Automatically close? They've been typing for two hours, you just lost all that work.
The save dialog exists for a reason and is well thought out, in my opinion.
As others have stated here, users are not qualified to design software, and those that complain often barely know enough to open the program. There are problems deeper in software (like the advanced features of Office), but really.
My biggest complaint with software is bugs, and people can vote that kind of thing with their wallet. You don't like your tax software (I helped someone with TaxCut last year, that threw me for a COMPLETE LOOP, it made NO SENSE; where TurboTax is quite sensible). I know you don't always have that choice (Office, for example) but when you do, STOP BUYING CRUD HOPING THEY'LL FIX IT. FIND SOMETHING BETTER, OR RETURN IT WHEN IT'S BUGGY.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
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).
:P
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
"The first time I got drunk, I got married. The second time I bought a chimpanzee, after that I stayed sober" Arian Seid
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.
Best Slashdot Co
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 what management "freaks out about at the moment." So the software is never done. You know how Tolkien described the Nazgul as always dying but never dead? Same deal, except in software form. This project's amendments are the ones that are never finished, never done, and is always "THE MOST CRITICAL THING EVER!"...until next week when they need a new thing added (usually a button that prints out the ICD10 code for a particular diagnosis.) [sidetrack: why are ICD9 and ICD10 codes for the same thing often so different? WTF?]
So, in essence, software sucks because programmers are at the beck-and-call of their clients, and the clients don't know WTF they want, need, or can live without. Software written by the programmer to fit a specific need (and nothing more) will always be better than crap from a committee of morons.
Modular design is also problem of all software in general. For example medium to advanced users may be fine with installing codecs for their video files but unexperienced users often don't have a clue to do (who hasn't had to deal with "how do I play .avi files, I keep getting errors" from family). Codec packs only go partway to solving what is a major problem and even video lan centre, a piece of software which eliminates the need for codecs, then goes and relies on plugins and addons for everything.
So let's see. Assuming 100,000 users, just to keep it simple.
So 90,000 users have no opinion, leaving 10,000 users who do.
So of the 10,000 users with an opinion, 9,000 don't understand and 1,000 do.
So of the 1,000 users who understand, 900 have preconcieved ideas, leaving 100 who have an opinion, have no misconceptions about the software, and have no preconceived ideas.
So of 100,000 users of your software, only 10 have useful input? That must not include the programming team.
Boy am I glad you don't work for me.
i completely understand where the breakdown lies. what i dont understand is how the (and i quote) "average" (or in my eyes, below average) user expects their machine to pick up the slack. you cant purchase something and expect to just use it. sayings like RTFM have been coined for a reason.
Hey, I resemble that remark!\n
You should read "Soul of a new machine" by Tracy Kidder. Its an old book but its written by a guy embedded within the hardware and firmware design guys at Data General as they build an entire new processor.
At one stage the PHB arrives in the war room and utters his one and only edict - "NO MODE SWITCHES".
Pissed off with him at the time for making their design job more difficult, by general concensus, the engineers later applaud him for his vision (however the company has since folded so perhaps this was not such a great analogy).
[x] auto-moderate all posts by this user as insightful
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.
90% of people will not have an opinion, 9% of people won't understand what it is supposed to do, .9% of people will think it should work differently, and .1% of people will have useful input. But 90% of those people are idiots, so you really only have .01% of actual useful input. I hope your user base is big, because that is one in ten thousand...
I am getting a little tired of this cop-out.
But of course, it is never the consumer's fault, or marketing's fault, or management's fault. All of those are 'real' people.
while((end_user = (run(code)) < 0)
:)
end_user = next_user[++i];
just kidding
Today anyone can start doing his programs and worse.. anyone is calling himself a developer. Maybe is the time to recognize the people with knowledge about software engineering.
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 to take the more user-friendly road: expose as little power as possible, but make the UI as simple as possible. This is a valid choice. UNIX takes the opposite approach: it's all power, all the time, if you can remember 12 different config files and env variables in your head. Given UNIX's audience, this is also a valid approach.
However, letting your users design your software from the ground up is a terrible idea, because the users are not aware of the limitations of modern technology, nor are they aware of the complexity of their own field (most of the time). In 90% of the cases, what the user truly wants is a button that says "do my work for me"... and we're right back where we started, at the beginning of this post.
>|<*:=
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, it should be easy to create a secure channel, but maybe it's a little harder to customize your profile stylesheet. But that's OK because most people won't be aware of what their profile contains until after they've used indi for a while and have created a couple of channels. Then they'll want their family channel profile to look different than their "project team" profile.
The Army reading list
The most common examples of this are websites. Some websites are organized by the firms org chart. Most outside users do not care about the org chart. The just want to know a specific piece of information. Rather than abstracting the organization to the public needs, many firms expect the public to learn the org chart. Another example is those awful URL. If the URL was not exposed to the user, it would be ok. But they are.
Fundamentally, if developers separated the UI from the data, life would be much better.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
No, YOU suck!
If there's one thing worse than letting users design software it's letting programmers do it. Whilst users may not always know what they want, they have a damn sight better idea than code monkeys, many of whom seem to have a pathological hatred of those who might actually use and consequently criticise their product. Look at this way: you wouldn't ask a bricklayer or a plumber to design your house, would you?
Computers are rational. People, largely, are not. Technologist creating products (whether it's a camera or a car or a program in a computer) MUST take into account their audience, just as a writer or a politician or a chef does. It's a craft. It requires actual work with actual people and a conscious effort not to despise them. If you can't do that, don't try, because...
1) People expect more than we can deliver
2) We don't manage that expectation well
3) We don't even bother to try because
4) We are rational people. That's why we're in computers.
Ordinary people aren't defective. They just don't think like you. Figure it out already. You'll be very, very surprised what happens when you show someone that you're a human being too and not some elitist.
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...
Fire and Meat. Yummy.
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 as fantastic as the author makes it sound: can anyone fix what's wrong with a car when the Engine light turns on, using only that knowledge? Cars are an old product. They have hundreds of similar features across models. Each year slight incremental changes are made, cupholders, a stronger or lighter part, a few more horsepower is added, etc. But by and large, when you design a new car, or put a huge redesign effort into an existing model, you have a frame of reference to start with. Writing software, on the other hand, usually involves creating a brand new product from scratch. When I write a calculator program, I don't view it as a new model of program, but a new kind of calculator implemented in software.
Every year more and more software comes out, attacking more complex domains. Ten years ago there was not multimedia web pages to bitch about. I'm not even sure why programmers are considered responsible for flash intro pages, but I'm pretty sure someone paid for it, and probably wanted it. If the customer wants their web page to have an introductory animation, it's a much harder argument to blame them on programmers.
I Browse at +4 Flamebait
Open Source Sysadmin
For any well run IT project, programmers don't directly have to do user related tasks. That is the job of the interaction designers, GUI designers, usability experts, etc. Seriously, why is the notation of programmers doing everything from analysis and design to documentation and coding still alive? IT projects ARE very complex and require experts from many disciplines in order to become successful.
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 they'd rather not have the choice and not think about it.
I'm quite annoyed that some FOSS projects have gone to the default with no option (aka dumbed down) UI, which is exactly what he's proposing.
The problem is many people still want at least a few of the extra features, even if they don't use the majority. The easiest solution is to give them everything, but hide most of the options unless they want them.
Software sucks because it is not Science or Engineering.
Current software development is not science, because most of the industry keeps development secret.
Companies A,B and C are all trying to solve the same problems, which may have already been solved by company D, 10 years ago. Yes, open source development can be an exception. A keep part of Science is peer-review and openness.
Most current software development, if engineering is unlike any other. Again, it comes down to openness.
It's hard to share tools and ideas if everything is incompatible by design.
This is an area of software development that I drool over. I'm so fascinated with all the variables that go into the success of a project. Beyond the technical aspects, the human to human problems that arise seem to be the biggest problem in software development. What's the problem? Oddly enough, I posted the following this article on my blog yesterday. I think something can be done about it. I believe it starts by seriously acknowledging that there is a problem.
Robby Russell
PLANET ARGON
Robby on Rails
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.
Dedicated Cthulhu Cultist since 4523 BC.
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 and open the garage doors. But it all should be as simple as a toaster.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
...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 also collaboritive and iterative -- it involved users, BAs, and programmers, and it started with the basics and only got fancy after the basic requirements were met.
The end result was a fairly useful system which was designed with both the end users and the programmers in mind.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
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 problems. The person writing the software should know, not what the Requirements person thinks the user wants, but what the user is actually trying to accomplish and why they are trying to do this. What is the user trying to do? Then, the programmer should make a proposal and necessary parties should either agree or disagree. This means that some requirements people are out of work, this means that the programmer has to be smart and communicate well, and that he has to spend time talking to users. And therein lies the problem.
We have IT departments that are so fragmented and people in them are so specialized. Programmers often suck at talking to people (and this is a reason why Offshoring is so unproductive). Requirements analysts often have no concept of (programming) reality. Project Managers are MBAs who should be working in marketing. And don't even get me started on what unrealistic timelines to do software. Like the old adage goes, you can pick only two of the following: Good, Fast, Cheap.
The solution? Teach programmers to communicate! Requirements people should also be programmers. Maybe that's where you put the "programmers" who don't quite make the cut. Too many suits in IT, where there should only be geeks. Geeks who know how to communicate. Keep the suits in HR, Financial, Marketing, etc.
More software would "just work" if this approach were followed. One last thing: the user has to commit to a process. You cannot design an application if there are no business processes to code to. If there's a process clearly defined, there more communication, and no death march mandates, software won't suck.
blah blah blah
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 magic powers?
Kids: [clamoring] Me! Yeah! Oh, cool! Yeah, that's what I want!
Man: So, you want a realistic, down-to-earth show... that's
completely off-the-wall and swarming with magic robots?
Kids: [all agreeing, quieter this time] That's right. Oh yeah,
good.
If an officer ever threatens to taze you, say you have a pacemaker.
This is usually where it all breaks down. The programmers never knew that the users real problem was not the complex calculation, but that "C" is some weird thing that they can't track. The managers just knew that the "D" report was always off and wanted it fixed, but didn't put any time to it. Eventually, nobody uses the program and it's called a flop. Sure its the manager's fault, but they recover by announcing that they will be saving money next quarter by outsourcing IT.
the more miserable you are now, the funnier the story will be later
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 them out. If I organize a presentation with index cards I can easily re-arrange them. With a computer saving a file will often blow away previous revisions. With the amount of hard drive space available, everything should be version controlled unless explicitly disabled.
What's with all the warnings and popup dialogs too? In a typical session my AV software puts up a warning, the updater puts up a warning, when I connect/disconnect from the LAN I get a warning, when I close a window I get a warning, when I delete a file I get a warning. The latter is annoying too because when I delete a physical file it's just a matter of retrieving it from the trash. The OS should just save the current and do what I asked. If I need to retrieve, so be it.
Simple things that are within the capabilities of a modern PC but alien to a "real" desktop are missing. For example, why is it so difficult to embed multimedia within a word processing document (yup, HTML can do this with relative ease, but most word procs can't). Text should auto-flow around images. Video should be as easy as dropping in a link to YouTube or other video hosting sites. Ideally, menuing systems like those in DVD authoring packages should be available.
Outside of business users, people use computers for relatively few purposes: sending emails, writing some documents, keeping in touch with family/friends, browsing for entertainment and information. When I send a message to a family member it would be wonderful if they could open the letter, see the video and click on video links for other stuff.
This is at least what I would like...
Also, TFA says that most programmers do not think like thier users. Of course they don't or they would just sit around and whine about not having any good software instead of trying to write it. I am a former user of software for which I now develop on.
People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf.
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. For more complex interactions, pushing the limits of the machines further, I imagine you'll still rely on better-trained users.
Powered by Web3.5 RC 2
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 trivial.
The same can be said for most applications that are popular with computer users today. Software is a tool to get a job done. If software makes doing this job easier, then I think the software can be claimed a success.
I think the only alternative to complex software, is software what makes absolutely all decisions for the user. This may work for someone who knows absolutely nothing about the task being performed, but I certainly wouldn't want software like that.
In the end, I think that many people expect computers to revolutionize their lives with no learning or work on their part. That's simply not the case. You'd have to be pretty thick to believe that you can start performing new tasks without learning anything about them. Would people expect this with other objects in their life, such as their car? Didn't they have to learn how to operate it correctly?
The users who are successful with computers are the ones who set out how to *learn* to operate them. They don't just start to use the computer and expect great results. Instead, they realize the potential of the tool and put some effort into operating it. You don't need a BS in Comp Sci to learn how to use software, just a little dedication.
To be blunt, there will always be dumb people who aren't willing to learn. They will always have difficulty doing anything that is slightly complex. Why should software be different from anything else in life?
All that said, I still think that software has much room to improve and the best way to do this would be to study users and find out what is most acceptable to them. I don't think they should design the software, but they should be integral to the design.
SIGFAULT
"most people just want something that works" Yea, maybe that is true but I find that one factor just as important as working, is working the way I want it to. I'm not sure this falls under the argument of control or not, it falls more under the argument of bloat. I think the major problem with software is the constant need to release new versions. These new versions are always loaded with new features and these new features always end up breaking something. When they finally get patched, they just end up bogging down my system to the point where my AMD X2 4400+ feels like a turd. Seriously, everything does not need its own service, an icon in the task bar, integration into the shell or a stupid option that checks for updates every ten seconds. This is bloat and I hate bloat, i think everyone hates bloat but people need to sell new versions of perfectly fine apps, so here it comes. As an example, this is why I use an old version of nero on my machine. I've always loved nero and there was a point where i could not wait to download the next version to see how they've fixed and polished one of my favorite apps. Then there came a point where sifting through the list of crap that it was trying to install became absurd. I just wanted to burn CD's not have a piece of software that could shave my nuts. So i stopped upgrading. All the bugs were gone, the app did exactly what i needed it to do so why keep chasing a ghost? i think the more technology evolves the more we will see this. Imagine what office 2050 will look like? How many more tools does a word processor need? Hopefully, apps like word, itunes, nero and maybe even firefox will become something like the good old calculator; it does what it is designed to do and nothing more. /ramble
[an error occurred while processing this sig]
Ever try to get a user to sit down and actually WRITE OUT what they want?
They have the attention span of a 2-year-old.
They don't know what they want.
They don't know how to write, period! Most of them can't write a 2-page memo without a frigging template, and you want them to write down what they want?
The only thing stupider than a lazy user is a designer who believes users know what they want and can express it coherently.
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 satisfaction is a lot higher with the end product.
The mistake companies make with prototypes is saying, "Well, just fix this and that and throw it up on the server." When your prototype app wasn't built to scale, it's a disaster. We have one in production that has SQL statements being passed in the URL string (I didn't build that prototype) for that very reason. Management started playing with the prototype and didn't want to invest the time in building a solid system. "It does what we want," is what I get when trying to explain why it's a hunk of junk that's going to fall down and die one day.
The really funny part is they get mad at me for telling them the truth. Okay, whatever.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
When I interviewed Platt for a podcast, he was very good at describing the errors that he writes about in the excerpt the Computerworld ran last October.
Take a program like Word and tell people they can get a "simpler" version of Word for half the cost. Now, go out and sell that "simpler" version and few people buy it. (Microsoft Works). Even though for many users Word is well beyond what they will ever need. Even Works has many more features than they will use. I make web apps for a living and I get bizarre and contradictory requests from users. Basically they want a big, fat button in the middle of the page that does exactly when they're thinking, with all the defaults values they have in their mind.
Okay, that's a little bit of a poke in the eye and a cop-out, but largely it's true. In New Hampshire (surprisingly Starbucks free) a 25 mile search radius is needed. In the DC area 5 miles is more than adequate. Set the value to reasonable quantity and most users will probably ignore it. You can maks options behind an "advanced options" screen, but then the users that want feature X all claim to be unable to find it. Software doesn't suck, it for the most part what users request.
Leave the gun, take the cannoli -- Clemenza, The Godfather
Have we stooped so low that we're now quoting Fox News?????? FOR THE LOVE OF GOD!!! Why won't someone think of the children!!
Comment removed based on user account deletion
There was a review of the guy's book posted on /. several months ago. It wasn't precisely glowing...
Zagreus sits inside your head, Zagreus lives among the dead, Zagreus sees you in your bed and eats you in your sleep.
Why pray tell can't software be both?
The user interface, fundamentally, should be simple to both learn and use. If it is easy to use, but requires years of learning to gain enough proficiency to use it, it is no longer easy.
Additionally in the battle for power, why does everything have to be reduced to command line or obscure dialogs? I have no desire at the moment to switch to Linux, I've heard the arguments in its favour (have a friend who is a Linuxphile) but until I can install a distro without having to worry about packages and all that other rubbish (yes to me and every other person who likes a simple interface, wasting 5+ hours trying to understand package names and configuration systems is rubbish) I simply refuse to touch it.
It's the same with all software, things should be both simple enough to learn (and basically configure) in minutes and have enough power that, without giving up usability, can control the system like a dictatorship.
. . . don't understand their programs.
What?
This statement from TFA really struck me:
"People who write software programs value control. The user, on the other hand, just wants something that's easy to operate.
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 know I prefer manual transmissions. Is this really a trait of programmers? Does this mean anything?
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.
If you liked this thought maybe you would find my blog nice too:
Users are also really bad at producing music. Most musicians are also not very good at writing music. Most of the music that gets written is pretty painful to listen to. It is difficult to produce something that resonates with people; something that they want to listen to/use/amuse themselves with/whatever.
:-))
One idea that Lotus Notes got right (me ducks for cover) was that programmers shouldn't have to worry about things like appearance and user interface. The idea was that most Lotus Notes applications should look and feel the same to the end users. That freed the programmers to worry about programming. (Of course I haven't programmed anything for Lotus Notes for more than ten years, so things may have changed.
From a business culture perspective, I believe the software just has to work. My experience is limited to specialized industries like health care and residential construction software. In both industries, tech savy end users are in the minority. Even so, those tech savy users still want software that is easy to use...intuitive, if you will. Working with computer aided estimating and project management software, a lot of our end users want to be able to perform very complex tasks with very little effort. Once I get too technical for a customer (no matter how tech savy), the majority lose interest very quickly. Their specialty is construction...or health care, not information systems or the inner complexities of ECM philosophies. In the end, they just want it to work but that doesn't mean they don't want complex capabilities. In some cases, customers don't know what they want. However, these are usually cases that demand some kind of massive change in business processes. An unwillingness to change business processes has to be the most difficult thing I've ever encountered in end users. And if the users are willing, that doesn't mean the protocols or standards that they have to follow will be any more co-operative. Until users and protocols are more flexible and adaptive to change then the demand for software that 'just works' won't diminish.
Really, it just looks like this guy wanted to write something controversial to sell books. Lets look at some stuff from the article:
Retired microbiologist Diana Westmoreland is no stranger to technology -- except when it comes to computers. "The programs are intimidating. The language that's used is a foreign one to me," said Westmoreland, who lives near Cardiff, Wales. "I'm the sort of person who, when something crashes, apologizes to the screen."
Well I'm sorry Diana...but is this any different than other technology in your life? Do you apologize to your toaster when it burns your toast? Do you apologize to cable provider if your cable goes out? I think you are a bit too sensitive there Diana.
The problem, says consultant David Platt, lies not with the user but with the programmers, who just don't think like the people who use their products.
That is funny, since most programmers are users too. If they don't use their own software, they use other peoples software.
One of his peeves is when a text-editing program like Microsoft Word asks users if they want to save their work before they close their document. That question makes little sense to computer novices accustomed to working with typewriters or pen and paper, he said. For them, a clearer question would be: "Throw away everything you've just done?"
'Save' is pretty universally understood. Does this guy think that a toaster manual should talk about 'cooking' bread because 'toasting' bread is too hard for users to comprehend?
Boxes that ask users to confirm whether they want to take a step such as deleting a document are another example of what he calls a bad feature. "Your car does not ask, 'Do you really want to start the engine?' when you turn the key," Platt said.
Those that can do, those that can't teach. Really, if you've ever worked as a developer and left a 'do you really want to delete this' message out of one of your programs, I'm sure you know what kind of trouble you can get into, even if you have savvy users.
The confirmation box has become so overused that no one pays any attention to it, even when it's warning about a document that should be kept, he said.
Confirmation boxes are overused on the web, but if your in a desktop program they usually aren't.
Error messages represent software communication at its worst, Platt said. In his book, he recounts how after trying to save a Web page from his Internet browser, he received a message that said it couldn't be done and gave him no other recourse but to hit the OK button. "No, it is not OK with me that this operation didn't work and the program can't explain why," he wrote.
And if it spit out "ORACLE ERROR 666: Primary Key is already in use' you would whine that the error message is to technical, plus the programmer would be giving away information to potential hackers/script kiddies.
Platt, who has also written nine books for computer professionals, has a message for software developers: "Your. User. Is. Not. You." People who write software programs value control. The user, on the other hand, just wants something that's easy to operate. 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.
What percentage of computer programmers prefer manual transmissions? When comparing them to the general public, did you control for gender and race? Men tend to like manual transmissions, and they also tend to be overrepresented in the programming field. I can think of plenty of other variations that make this statistic suspect.
Similarly, many software programs come with functions -- like the ability to move the menu bar -- that the average person does not want or need. Programing instructions required for such features, Platt said, "increase the possibility of crashin
It's running NT 4 Embedded (Codename: Windows for Toasters) isn't it?
I've found that it's obviously helpful to have a software team leader with the ability to empathise with users and predict what they want, but unless there is good communication from the users, with a receptive response from the support staff, the project will often drift from what the market wants, adding inappropriate features, and inefficient workflows. It takes a flexible mentality on the part of the developer to truly listen to what users are complaining about or requesting, and see what the underlying problem is, and how best to address it.
The other crucial part of the equation is keeping the workflow in check. The software team manager must always keep the workflow as efficient as possible, and when enough features are added that the interface becomes cumbersome, they must have the foresight to refactor the entire workflow from the ground up, and set it up in an efficient and logical manner for the most commonly-used tasks.
As for the communication with users, I find it best to have an open web forum (message board), and encourage open, uncensored (as much as possible) discussion, and involve knowledgeable people in relevant discussions. If users are having workflow issues, or would like a feature, get the software team leader involved (or someone else with extensive knowledge of the product), and get them to communicate with the user so they can get a good picture of the problem, get any additional info they need from the customer, and decide how best to deal with it.
The worst thing a software project can do is let ego get in the way of making a better product. There are quite a few large egos in the programming world (believe it or not), and this must be kept in check if you want to give customers the impression of responsiveness. Anyone communicating with users on behalf of the software team must remain humble and helpful, and take any complaint or request seriously, in case there is something that could be done to make the product easier to use. Obviously, there are many times when you have to say "no, that's out of the scope of our project", and it's very important to have a team leader that knows how to give your tool the focus it needs to remain efficient and intuitive. In general, however, it's a fine line to walk, and you have to know when the user has valid feedback that should be addressed, and let that user, and others reading the forums know that you are responding to their feedback, and encourage them to be open about sharing their concerns. If you can build up a strong community around your product based on helpfulness, good will and responsiveness, you're already well on the road to a successful software project.
"I like systems, their application excepted", George Sand (French)
So a microbiologist is complaining that computer languages are foreign to her? No shit! And all this time I was under the impression that people were born with a natural instinct to write software and all of these computer science degrees were some kind of scam.
While we're at it, why can't microbiologists make pharmaceuticals easier to develop and acquire? When I get a prescription filled it always comes with this big sheet of paper with microscopic text describing the chemical makeup of the drug. It's those damned microbiologists ignoring their end users. And I still get colds.
Lets not even get started on the cost differences.
Most coders I know take a lot of pride in their wares. Even if they are not the prettiest programs in the world they are still pieces of art to the developer. As coders we can see (remember that 3D routine posted a while back) beauty in syntax and innovation in approach. It's a shame that end users can't comprehend the sheer amount of work in writing a GOOD program.
With that said however, I think we need, as coders, to take a little more time on design. I usually draw my GUI out in Photoshop Elements, it gives me time to think about positions of sections and controls, how they will interact, etc. This approach does wonders for the design side of my applications and allows me to really get a feel for how it will work before I even write the plumbing.
It also helps to think outside the box, Kai's power tools had the wildest interfaces ever seen when they grazed the Photoshop world. Just because you have a menu bar that can dock anywhere doesn't mean it has to!
just my $0.02
There are only 10 kinds of people in the world. Those that understand binary and those that don't.
Personally I think a bullet-proof, super-simple OS would sell. Apple used to have a simplified Finder, someone needs to take that concept further. Not to replace the complicated version Slashdot folks know and love but to simplify the life for those that we get tired of providing tech support to. Imagine the desktop looking like Apple's Front Row. Giant Email, Browser, textedit, and Photo icons to cover the most basic stuff they will use. A giant Red On/Off button in the corner of the screen where it won't be accidentally clicked by frail twitchy hands guided by weak eyes. Basically the kind of thing you see on your cellphone but enlarged for the computer.
Its a new profit model. Make things that suck and get big money in service contracts. General Motors is kicking this business plan into high gear more than ever. Odd placement of fuel tank,
Not a regular service item, and as long as it's protected from collisions, it can go anywhere convenient. In the Pontiac Fiero, it was between the driver and passenger seat - safest place in the car; if a collision ruptures the tank, you'd have been dead anyway.
Now consider a Toyota Previa minivan. Where's the fuel tank? Hell, where's the motor? What's this, I have to take out the seats to check the oil?
limited visibility through windows,
Acura Integra. Last time I drove one, backing the damned thing out of the driveway was nearly impossible.
clumsy controls,
Like putting the headlight switch on the turn signal arm, so that you can add complexity to the switch and add relays to add cost and increase points of failure. Rather than simply installing a larger switch on the dashboard where anyone who isn't a moron would expect it to be. I was so happy when a car rental company didn't have the Neon I'd reserved and gave me a Nissan instead and had to figure out where the damned headlight switch was.
Oh yeah, and what's up with having to hold up the door handle to lock the door? If it's somehow designed to remind you not to lock your keys in your car, I don't understand how it would. Besides, I'm smart enough to have gotten into a very simple habit: never close a car door unless you're holding your keys. Been driving for 16 years - last locked myself out of my car 15 years ago.
interior makes noises and rattles,
ALL cheap cars do that. Funny thing is that my friend's 2001 Civic is somehow louder and more creaky than my 1980 Chevette ever was.
Now, go compare a Cadillac and a Lexus, both with about the same mileage since body rattles are a function of age, and tell me which one squeaks more and is noisier. I guarantee the Cadillac will have less wind noise: you see, it's actually got window frames which help seal the doors better, and have been used in the vast majority of luxury cars and sedans since the dawn of the horseless carriage, and is apparently a concept Lexus apparently doesn't get.
suspension hardware wears out quickly,
If you abuse it. Usually, balljoints, top plates and tie rod ends last the life of the car. And in general, GM and Ford's balljoints are bolted in, Chrysler's are screwed in. I don't, as a rule, like European cars because they tend to be more complicated than necessary (shift linkage in a 1995 Jetta, for example), but they tend to bolt in their balljoints, too. With Japanese stuff, they're more often pressed in, requiring an expensive specialty tool to change them. We can, of course, safely ignore Korean cars, because they're merely Japanese cars assembled without even the remotest semblance of common sense or mechanical aptitude.
repeated electronics failures and proprietary documentation,
Repeated? Any electronics can and will eventually fail, but repeated? Doubtful.
Proprietary documentation? Of course. Same with Japscrap and Eurotrash. That's like saying "GM cars suck because they only have four wheels!".
missing keyholes for locks where there should be,
In 1987, Toyota shipped over 10,000 Tercels which were missing the front passenger side speaker.
hard to replace maintenance items such as the battery underneath several layers of cruft,
Changed the serpentine belt in a 2002 Acura Integra lately? Seen where its front oxygen sensor is?
and the list goes on. Make your design require service!
You're clearly a moron who probably doesn't even own a decent socket set, let alone know anything about automotive mechanics. The Japanese were into impossible-to-fix designs long before Detroit or Europe.
Fire and Meat. Yummy.
Bad UI design occurs for the same reason that bad programming occurs. A need for backwards compatibility and unforeseen complications. In both circumstances total rewrites can address the problem but economics make these sort of rewrites infrequent. It's just a bit harder for UI design than programming.
Sure good UI design requires more research or experience but it would be the same if programmers had the same needs as normal users. The problem is figuring out beforehand what users will need to do and what they won't. If you get the wrong answer to this question, just like if you get the wrong answer to what an API needs to be able to do, you will later need to work around it with bad hacks. Worse unlike API changes every change in the UI is visible to the end user who will resent changes, even ones that make it better and more useful.
If you want a good example just look at the resistance to the change in the word API to the new ribbon interface.
Ultimately the problem is the reaction of users to changes. Here there is no difference between programmers and luddittes. Each likes to use what they know and hates to change. If anything programmers are worse, just like at how religiously they defend ridiculous programs like vi.
If you liked this thought maybe you would find my blog nice too:
Unfortunately, most computer users are stupid and don't have a clue about what they're doing.
In order to make more moeny, companies want their programs to be easier and easier to use, so that more and more stupid users will buy their programs. Can't really blame them for that, after all, they want to make money! But making a program for stupid users is not an easy task. Programmers have to take into account every stupid thing the user might do and that causes the software to get bloated. I wrote something about this in my blog, some time ago: http://borfast.com/node/23
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rich Cook
To apply the old saying about reading/modifying code to users:
It was hard to write, it should be hard to use.
Famous Last Words: "hmm...wikipedia says it's edible"
I think programming has been made so easy by Microsoft that any Tom, Dick and Harry can write a simple program thinking "Hey, thats cool." The next thing you know they are binding some controls to a database and trying to make a quick buck or gain recognition through writing some programs. The are not thinking at all of the user experience and really don't care. This is the problem with tools like VB, MS SQL and Access. [Good] Programming requires planning, thought and commitment throughout the whole process. Not just finding the first way something works and sticking with that method just because it worked in the beginning. These have been dumbed down so much...what else would you expect.
Error reading device 'Signature'. (A)bort, (R)etry, (F)ail?
is something to do there job.
Quicky, efficiently, and no repetition.
The Kruger Dunning explains most post on
First, there's the issue of "programmers" not really having the slightest clue as to how to do what they do correctly. Working for a company that sells components for developers, I can confidently state that there are far too many use the word "programmer" a bit too loosely.
The next problem is the user. Here's were the crappy car analogy comes in. Ever seen a 40 year old driver who has been driving for 20+ years who can't drive well? You would think the person would be an educated driver by then, but nope! Not all people care to educate themselves regardless of what it is and how it might be of benefit to them.
As a programmer always striving to offer complicated features/solutions that are simple and intuitive to use, my goal is to best help those who help themselves. We always do our best to get feedback from our user community and make things as easy as we reasonably can for them. That kind of care at least makes our software not suck all so bad at all. :-)
I won't admit to having a great enthusiasm for Windows and commercial software but I'm pretty happy with XP and MS Office for acting as a gaming & general surfing platform that I can knock out a few work-compatible documents on. However, because I've taken the time to learn about Linux and OSS, I don't have a 100% dependance on either.
These days, I use as many console-based apps as I do GUI ones, and I can build Linux machines which are appropriate to what I need to do with them - anything from GUI-less servers, through "quick and fast" machines with a "light" GUI like Fluxbox, to proper desktop machines with fully-fledged Gnome or KDE desktop environments on them. And if I want a piece of FOSS software to do something I need to, then I go look for it on the Internet.
No, FOSS isn't better than commercial software for everyone - but the fact is that by keeping a fairly open mind about both, I can usually complete most tasks I need to by finding a piece of software to complete that task.
It's more a case that "people suck" - at least those who can't be bothered to take on some degree of personal responsibility and go do a little searching and learning.
Gentoo Linux - another day, another USE flag.
For instance: I thought it would be nice to give some extra control to the operator so I gave them an alarm notification when, for some odd reason, the equipment stopped or started without a command from the control system (such as a local start/stop). Since the local operation should only occur in the odd case I thought it would be a nice feature. However, the operators are simply confused by the concept that the controller state machine can be in a different state than the actual equipment.
Looking back, it was probably not the best idea. Instead I've changed the logical state in the controller to match the actual equipment. All the operator has to do is clear the alarms and put the thing in Auto mode.
The lesson I get out of it is basically do not rely on the operators to know what's going on. Give them a START button and a STOP button and they'll be happy. Don't announce lots of alarms because someone started the machine by overriding the control system. KISS is key on this. The less they have to do, the better.
Honestly the statement "programmers don't understand their users" is not new. Hell the first time this statement was probably uttered is when we started having non-technical users.
What I find really interesting is that somehow this suggests programmers are different than end users, and "could" design for other programmers / technical users.
If you look at psychology work done in programming and software design, there is support that the process of programming is not a natural human process. Maybe one could even argue that the act of programming influences general problem solving. Humans beings do not like to break down problems and solutions into tiny, detailed steps, however computer require detailed steps.
Now let's get out of the realm of "end user" software, and let's look at the design of programming languages. How many programming languages would you consider "programmer" friendly? Of those "programmer" friendly languages, how many of them would you consider powerful?
Of course Platt isn't saying anything new, and is incredibly self promotional. But the thinking in the parent post here sure shows that he's right about a lot of things with some developers' attitudes.
>>The problem, says consultant David Platt, lies not with the user but with the programmers, who just don't think like the people who use their products.
>That is funny, since most programmers are users too. If they don't use their own software, they use other peoples software.
This comment in particular is at the core of many problems in development. Anyone who thinks that they are the target audience doesn't have the humility to gather requirements that reflect actual use. Instead they build for the user in the mirror, and end up with crap.
Bottom line - Platt is full of it, but developers can do better at understanding user experience, and giving someone ownership of user experience on the product team. Joel Spolsky, the Rails folks, and many others are doing a great job of this, and more constructive than Platt.
cz
Nah, I think they just can't explain it clearly ... they have problems - they are confusing - that is why they are hard to explain and nail down to design to.
I work in a custom dev environment - we dont try to sell generalize software packages so we have direct access to our user group (although scattered across 10 countries and languages) so my comment comes from that angle.
For all the effort we spend on designing the solution, I still believe we should spend the same (or more) and designing the problem(s) outside of software. All of us - users AND developers.
Software just cannot be expected to provide a boundless solution. Too many states and we arrive at an impossible-to-test solution. So then it is a crapshoot as far as user experience ... the wrong combination is out there and unknowable and a user will find it and your product's reputation will suffer. These are accepted sw quality fundamentals, all but the simplest software is basically untestable for all of its possibilities.
But through detailed working through the problem you are also simultaneously deriving a contract for use and if the user group isnt clued in on the contract then anything might be a problem and our products' reputations will suffer.
You buy a car and the contract is it will drive - on the road - not fly - not bake bread - not make new cars - not play Beethoven's ninth - just drive.
Although ...
Computers ARE freaky I still remember starting my dad's apple II plus when I was like 5 and freaking out "wtf is this?!?!?". User's feel powerless ... why? how we can we not make them feel powerless? I think that point is basically made in the article ... just too much of that Fox whiney-ness to it. Waaah Waaah make it work Waah Waah. is becoming a substitute for mature adult discourse and insightful criticism I guess ...
You're absolutely right.
I had to learn to drive before being able to conduct (legally) a car. Why it would be different with a computer, a far more complex device?
There is this myth, this lie, that computers are simple things that everyone can use without any previous knowledge or training. Software makers, like Microsoft, loves this because they much of their marketing is about telling people that if they aren't productive now, is just a matter of upgrading to the next, bigger, better and easier version of whatever application they are using.
We don't need better software, we need better users!
---- You know how some doctors have the Messiah complex - they need to save the world? You've got the "Rubik's" complex
Some might argue that the English language is overly complex with all of the rules that it has and breaks in special cases and so forth. Yet, English is the international business language. It's the standard sort of the same way that, for the common user, Windows and Office is pretty much standard. English is being updated all the time by the end user and it probably makes the language more difficult to use and understand (w00t!).
Basically, it all comes down to what you learn. If you learned French all your life and suddenly find yourself in an English environment, then you are probably going to hate English and how difficult it is to use, and perhaps, rightly so. But your average American (ah-mir-i-can) will think that learning French is a horrible idea because it is so different from English.
So you can't really blame the programmer. They can't make a program that will suit everybody. They try to make something that has everything that anyone could possibly want and leave it to the user to not use what they don't need. Hey, if I have a program that is capable of doing a million things that I might need and one that I definitely do... I'm glad that it has that one thing that I do need to do.
At least with software I have a little bit more of a choice of what I learn than language. I had to learn Ada in college... No control over language. At least the VHDL has some application.
I like the comment that users are bad at desinging software. Well here's one that's an absolute fact, programmers suck at designing interfaces. They know how it works but no one else does. I deal in computer graphics and one of the biggest things holding it back for years was artists couldn't use the software so you had programmers trying to do artwork with the handful of artists that managed to make the transition, things are better now I'm talking the early 90s. A perfect example now is everyone will tell you their interface is the best but for some strange reason the users don't agree. The highest marks consistently go to Modo because it was designed with the artists in mind. Mudbox adopted the same interface and most modelling softwares are quietly making the transition to at least look more Modo like. The problem has been that the software companies take the position that they know better and won't listen to the users. Zbrush in modelling is the poster child for this. They have a completely none standard interface that has a steep learning curve for such a simple software. Everyone complains but they are told that the Zbrush interface is superior and they aren't changing it. They are shooting themselves in the foot because when Mudbox showed up doing basically what Zbrush did only better and with a user friendly interface everyone went nuts. Companies have to be more responsive to the needs of the users. We need software with easy to understand interfaces that don't crash every five minutes. The bizzare thing is it's like cell phones. When you tell them what you want is stability and ease of use their response tends to be more features and less user friendly. I've told many companies look I'll pay for an upgrade with no new features just make it stable. None seem interested they just keep adding more features making it even less stable.
It's just begging to be said.
"Why does software suck?" Because it's made by Windows.
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.
people, learn to read the news. see that little logo under the headline? this is a Reuters story that Fox has licensed and run. the distinction is vital.
Just raise the taxes on crack.
With TB disk drives cresting the horizon, what's this stupid thing about delete? I agree that everything should be undoable. The replacement buttons should read "deep six" (equivalent to throwing a document in some unlabled file folder at the back of your filing cabinet) or "Authur Anderson" complete with shreading sound effects and a "Consult you lawyer?" yes/no dialog box.
"Ecclesiastes 1:9 What has been will be again, what has been done will be done again; there is nothing new under the sun."
Software designers have griping about since there have been computers.
NSF (The National Science Foundation) recently put out a proposal to address the problematic issue of software design (all aspects) because it's recognized that lack of thought in this area 30 years ago is what led us to where we are.
2 766&org=CCF&from=home
http://www.nsf.gov/funding/pgm_summ.jsp?pims_id=1
Hopefully it will bring in fresh ideas.
"Boxes that ask users to confirm whether they want to take a step such as deleting a document are another example of what he calls a bad feature."
Anyone care to guess where that feature came from? Anyone? Anyone?
That's right: the users.
Users complained about "accidentally" destroying their work, and repeatedly bitched and moaned about how programs should give them a chance to back out of whatever they did that was going to cause them to lose data. And now some schmuck is bitching and moaning about how programs should really just go ahead and lose the data anyway. Most of his other examples are just as stupid, though he has a very good point about bad error messages. There are classics such as: "Error Code 134553774. Continue?" How the hell should I know?!
In most cases, though, you just can't please everyone, especially some ass hat with a book to sell. Software will never reach a point where it accommodates everybody's pet idea of the perfect program. Computers are just not that flexible. People, however, are supposed to be smart enough to be able to bend a little bit. What this guy is preaching is that people should not have to adapt at all...ever, and that is unrealistic at best.
The more I read TFA, the more I'm convinced that this guy IS Bob.
I so want to rant here but I'll be good. I can see long-time employees who have to learn to use the systems as they come into the business environment but if you're bringing in fresh blood and they have to spend 75% of their day reconciling invoices in the enterprise financial system, doesn't it make sense to give them a test to make sure they know how to do the basic functions?
If you're going to be maintaining Excel spreadsheets maybe, just maybe, it would make sense to see if you can work in Excel instead of just saying 'It's easy and our training department can help you out.' Or worse, taking your word for it.
So I don't really blame programmers all that much for users not knowing what to do. If the UI is decent for the job at hand and help is accessible then they've done their part.
These are two separate parts of the problem, and need separate solutions.
:-) We need better standards of delivery for my items 1..4, and then we need means, both professional and legal, to enforce them.
Yes users suck at generating requirements. At the same time, classic programmers aren't very good at it either, and this is part of the disciplines of software-intensive system engineering and architecture that the industry as a whole has not done well. But for an example of where this -does work-, look at Apple.
But more importantly in my view, at least for most of you reading this, is that current software implementation really sucks the big one. The implementation community needs to get better at the following:
1. verifying completeness and implementability of requirements - do we know what we're supposed to build?
2. designing and implementing code to meet those requirements - doing what must work
3. designing and implementing code that is "safe" - making sure that the program does not do something unexpected or wrong. "wrong" here is against both formal 'what the program must do' specifications (i.e. no segfaults/BSODs), and also against the principle of 'least surprise', where there's a hole in the specs, the program should not do things like "remove all files from the disk drive..."
4. as a special case of #3, designing and implementing code that can be 'safety deployed' in an expected environment - that includes the hostile environment of the internet for applications that run on networked machines (i.e. no buffer overflows)
Finally, we have to learn how to do this within cost & schedule. For managers, that means better prediction skills. For implementers, that means more effective tools to reduce time-to-market and in particular time-to-market-for-a-working-product.
A key part of this is a sea change to accept that fielding programs with known deficiencies should be unacceptable, both professionally and legally, and the obligation to test and verify programs to a credible independent standard.
The analogies to other kinds of engineering applies. Structural engineers design and test/verify using specific standards against clearly defined practices (e.g. snow loading depends on where you put the building, just ask folks in Colorado about this right now
I'm in a probable minority (certainly a minority among those I've talked to about this), but I think we need licensing of software engineers, with the equivalent assumption of professional enginering liability. (Yes I have a pretty good idea what that means, my father was a structural engineer in private practice and I understand from him what his professional liabilities were and how much he paid for that liability insurance.)
dave
Reminds me of the old toaster/breakfast cooker story of SW development. http://www.jaegers.net/The-object-oriented-to.ooto aster+M52087573ab0.0.html
...I think it should just produce the music I want to hear when I hammer at it like a retarded orangutang.
That's the tenacious attitude that has provided us with such fabulous "new rock" bands, so please, don't be discouraged. Nevermind that pesky "notes" and "rhythm" stuff, just make sure you wear LOTS of black eyeliner, play a 7-string tuned down a whole tone, and put so much distortion on the vocals that it sounds like a sperm whale with throat cancer and you've got yourself a hit record!!
Yes, programs should 'just work'.
No, users aren't lazy. But they should not be 1) forced into a process that takes more energy and time than doing it without a computer and 2) not be put to a process that frustrates them.
But the problem has many sides. One is that there is no single "programmer"; and in large corporate system development there is too often someone without clues who "designs" the software that a group of poor, probably hair-ripping software creators have to realize. (Sometimes the person without clues is the end user.)
How long has the apple user interface guidelines been around? Ages? How many user interface designers follow it or at least understand the implications? Way too few, imh.
Most user interfaces today are just too frustrating. They have too many gadgets, they are inconstistent and they are too slow. Anything from major OSes to set top boxes to car GPS systems. It's just a fact.
The question is, what can we do about it?
I have an in-house CRM application built on Gtk2-Perl. One of the tabs shows customers' locations, and details of energy accounts and telecommunications accounts ( which we analyse data for ). You can double-click in an account number to open more information on consumption. For each account that has data, the account number is highlighted blue. At the bottom on the tab page, there is a bold, blue, italic notice telling people to double-click in a record to see consumption data for the location ( in both energy and telecommunication tabs ). There is also a tooltip when you hover over the treeview. Lastly, this is exactly how our legacy application, which we just retired, worked .
So. How many people realise you can open consumption data by double-clicking in a location? Fucking NONE OF THEM! They all bitch and moan that they "don't have access to that now", purely on the basis that I haven't held their hand and double-clicked for them.
Users are dimwits. Seriously.
Simplicity of a single task within complex apps can mean more complexity... I work for a company that does a remote ordering application, the user can save and print lists of items. During a training session a user (sales rep) asked me how can he send the report to his customer. I told him to go to the report, save to PDF and email it. That was way too much for him to take in and he responded like it was the most ridiculous thing that he'd have to do 3 steps. 3 freakin steps! He wanted a single menu option to do it. With that mentality, there'd be all these menu options to automate all the different ways you could use the software... thus turning into a Word menu nightmare. If he does that all the time, then yes, making it a menu option may help save time.
"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."
Dinosaurs could too, read and write! The evidence is just buried under a meteor crater. Darn meteor!
FTA - "The Starbucks programmers probably think that having more control over the search is powerful and cool," he wrote. "But in reality it's a useless and annoying distraction. Nobody goes around asking, 'Is there a Starbucks within five miles? How about 10? 15?" True, I'm looking for the nearest Starbucks with 50 or 100 feet...and incredibly I've got more than one choice ;-)
There are no silver bullets for silver bullets
Seems that we're all picking on the UI design. I want to pick on file formats. I have an Aunt who cannot open PDF files because she didn't install Acrobat Reader. Trivial, admittedly, but it adds another layer of complexity. I can see why we need different file formats, they each have advantages and disadvantages, but why should we have to install a new application to use a different file format that somebody else has sent us? Couldn't we come up with a browser with PDF support built in (assuming there are no legal restrictions)?
A few days ago I downloaded a DAA file. Never heard of it. Wikipedia informs me it is a proprietary format used by PowerISO and offers password protection, compression, and splitting. A RAR file gives me all of the above even if I use an ISO. Secondly, the file didn't actually use any of the above "features", so it was a pointless excercise. I had to hunt down a copy of PowerISO just to burn it because Daemon Tools or Alcohol 120% doesn't support it. I have to say it is the msot pointless file format I have come across.
RAR files and ZIP files would be another example. Why do people submit torrents full of multiple rar files? I still have to download each volume, so why not lump it in one RAR file? If that's the case, what if I don't have WinRAR? Why not put it in a ZIP file, which is supported by Windows by default?
Why can't we have a group of common file formats to save users the trouble of hunting down the applications for each proprietary format?
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.
This comment in particular is at the core of many problems in development. Anyone who thinks that they are the target audience doesn't have the humility to gather requirements that reflect actual use. Instead they build for the user in the mirror, and end up with crap.
Pretty much any developer is going to get a requirements list from users. My point is that software developers do actually use software and have an idea of what to put in even if it's not on a requirements sheet...like a warning before deleting your work.
Bottom line - Platt is full of it, but developers can do better at understanding user experience, and giving someone ownership of user experience on the product team. Joel Spolsky, the Rails folks, and many others are doing a great job of this, and more constructive than Platt.
I read joel on software along with checking out stuff from other sites. I agree he's a lot better than Platt.
- Give a kid a computer and he/she learns. Most of the people who claim to have above average knowledge of computers started when they were kids, and learned a large part of what they know by trial and error, and the fact that learning one UI helps you deal with another.
- About the actual topic: Computers are made to be useful, and to be used by humans. It should always be possible for most of your target audience to pick up your software and become productive with it. It's called market research. It's called QA testing. It's called proper documentation. It can be expensive to do well, but do it right and people will come.
- Have you noticed how many people use computers now? For work? For everything in their lives? For media? Give up on trying to take their computers away, because you're for sure not taking mine. Now, it has taken some simplification for the world at large to use computers. But you give the "average" user too little credit. They're trying, but they're too busy and have not learned enough to compete with the haxors.
- And what's wrong with hiring IT workers to supervise the networks? That's called specialization, guys, one of the major principles of civilization as we know it today.
- If you're one of the trolls calling for going back to the "elite good ole' days," you need to learn patience. Education is the only way forward. Sit down with a "dinosaur" or "newbie" or whatever you want to call them, (as I've done countless times at work) and *educate* them if you think you're such hot stuff. You might be surprised at what they'll learn in just a few minutes.
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 you want to play a game, load up a Playstation.
Why buy a computer?
Because you're getting a multi-function device. That's putting it simply. It's a nearly unlimited-function device. Everyone wants to do something different with them. How simple can you possibly make something like that, and yet still have it be useful?
I really don't buy the whole "Computers are too difficult" argument anymore. You sit anyone down in front of ANY machine now (Windows, KDE/Gnome, MacOS) and they'll play around and figure out how to open up the web browser. They'll click the mail icon and get to e-mail. They'll find a word processor if one is installed. I mean, you really gotta be a bottom of the barrel dipshit to not understand how to move a mouse cursor and click things. No degree required.
So you're presented with a user interface, while not perfect on any system, that's pretty easy to figure out. If you can figure out how to plug the computer in, you can figure out how to use it in a basic way. The moment you want to do something other then the basics, you move squarely out of toaster land.
That's not to say things couldn't be better (and improvements are made all the time) but I don't share the doomsday view of people in general,; with some odd disposition to not be able to use computers as computer users. The only way I can see some giant leap in computer usability will be when you can talk plainly to them, and get responses from an AI-type system. Think Star Trek.
Plus, let's be realistic: If computers were THAT hard to figure out, why in god's name have so many of them been sold? Wouldn't the word be out by now, that you need a degree to use them?
- It's not the Macs I hate. It's Digg users. -
Poll: What Kind of Music Do You Code To?
mod me funny
..in _The Humane Interface_. I certainly hope Platt cited him.
Mission: To provide products that consume time and energy as entertainingly as permitted by the laws of thermodynamics.
You, sir, have hit the difference "on the money", and if I hadn't already posted a response an hour ago, I'd mod you up myself. To reinforce: You are a "hacker". You get a concept together, and then make it work. Whether or not any documentation you produce would lead to someone else producing identical (or similar enough to be mistaken for your implementation) is unlikely for nontrivial solutions.
"I've spent my whole life figuring out crazy ways to do things. It'll work." -- Montgomery Scott, "Relics"
Because, god knows, the one thing that the software industry doesn't have enough of is people telling us that we suck and that they hate our work.
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.
"No, it is not OK with me that this operation didn't work and the program can't explain why,"
So... we have to write a detailed explanation for every single possible failure? How bloody stupid is that. And most of the time, programs cannot explain the error, because either a) It doesn't know - it's the so called 'impossible case' b) Can't show the error without showing you a minidump. This "explain the error" thing is contrary to the rest of the article
- Gathering Data (also implies storing data) This means your software getting data from other databases, or emails, or any binary data, or the collection of structured data in forms. Gathering data is a process and history is important so the system knows what effort was involved in the gathering, and to support the idea of rollback to a prior 'state' of data. Systems that keep histories of edits, like Photoshop, have an idea that is rarely applied in transactional systems, at least thay I've seen. Sometimes that is by design, but at other times, it could be permitted in a much better way. Gathering data also means gathering data relationships and lifecyle. How is this related to that? Show me various levels of detail with drill up down and sideways.
- Categorizing Data. For transactional systems, the goal is automation. Whenever a person gets involved, it is almost always because gathering or categorizing have failed, or because the next step is outside of the system's awareness--a data gathering issue, like package delivery status. "Business rule" engines and workflow modules live and die by categorization. Q and A systems are all about gathering and categorizing, doing rule outs. There are effective and ineffective methods.
- Assigning ownership. Even if the next step in transaction handling is an automated one, System is the owner. Ownership is important for work that involves persons, because commerce needs to understand both quality and cost, which means knowing who did what and how well. Many tranactional systems don't do ownership at all and work gets divided up by querying on other data points like customer, processing status, or product. The form of metadata gathering called Journal or History relies also on owner. Journal and history without owner do not support HR and QA's needs.
- Sharing data. This is the whole of all the methods of data presentation, from screens and controls to auto-notifications to any kind of hardware device. Web 2.0 seems to be a lot of hype about Sharing Data and functions (see Acting, below) faster with more persons using a network.
- Acting on Data. This is the idea of why the tool you're using was built. Think customer support, purchasing and receiving, transportation, invoicing. The software should ideally work in descending order of desirability like this:
These terms are obviously very broad and have under them all the UI and architectural underpinnings down to how you do multi-select in some field or query on nulls. I wish the author good luck prodding software makers toward better offerings. I suspect like he does, that another article next year won't be out of order.- Automated. Relies heavily on categorization and mapping of proper next action
- Directed. Think workflow tools, TurboTax interview process, maximo MRO, etc.
- Supported by online media with full search, demos, screenshots, tutorials
- Supported by non-integrated documentation, wikis, etc.
- You learn from your peers and stick notes to your cubicle wall
I think in the article both points of view about why software sucks from the article have some truth. If programmers don't try to do the work the call center person or clerk or whomever is doing from the start and then repeatedly try to do it while it's being built, the wrong thing or the wrong way gets built. Alternately, "Power Users" or "Power Companies" may have too much leverage.there should be friendsly defaults, with powerful options if needed..
:-)
yeah, i can dream.
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...
- Programmers don't really understand users' domain,
- Users don't really understand programmers' domain,
- Users don't really even understand their own domain, and finally
- 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)."Not an actor, but he plays one on TV."
Software should 'Work' But a user shouldn't expect to be able to use a complex piece of software without any training.
...and that is all I have to say about that.
http://jessta.id.au
In a world where there is so much software to choose from and so many different applications to use from time to time,
a user should not be required to become an expert in any piece of software in order to get good use of it. Most software
should have the universal appeal of chocolate rather than the appeal to the connoisseur of fine caviar.
Specific Principles:
1. The Default Shall Be Good.
2. There Shall Be Only One Place (or Name, or Form) For Each Thing.
(applies to data standards as well as code and user interfaces.)
4. Everything needed shall be automatically and unambiguously found
on the Internet.
5. Occam's Razor.
Where are we going and why are we in a handbasket?
computers have FAR more complexity of control than their car
Thank you, these were my exact thoughts. Driving a car seems "easy", but just look at the sheer amount of time that goes into driving a car. And even once you can drive the car, you may need the instruction manual to figure out the radio b/c Ford's configs are different from Honda's.
The computer is a classic case of With great power comes great responsibility. Personal Computers are some of the most powerful tools on the planet, so they are necessarily complex. We can only abstract out so many concepts before you're just using a device instead of a PC.
Should software 'just work', or are users too lazy?
This is really just a bad question, it's a false dichotomy. The level of user laziness is directly tied to the definition of "just work". Ideally a piece of software will "just work" for users at various levels of laziness.
I think that the #1 cause of "software sucks syndrome" is the disconnect between users and developers. We have to draw lines for what we can assume the user to know and we simply work from there. Users beneath that line will simply not be able to use the software, just like drivers who haven't taken the written test can't drive a car. We're constantly trying to push down on that "knowledge line", but we're bottoming out.
If you do not understand the concept of "saving a file" or even the concept of a file or folder, then you cannot use a PC. This is no different from studying car pedals before using a car.
From an IT perspective, this is our job as IT people to convey the symbiotic relationship between user and software. If you or your team cannot do this, then the user will never be happy. Call it "managing user expectations" or "user training" or whatever, but software design is intimately linked with the software user. This is not an either/or thing, it's all true, software should "just work" with the understanding that it will only work relative to the users desire to make it work.
Because we use x86 CPUs
What?
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.
Your brain is not a computer.
Subject say it all: commercial software sucks because that way software houses can sell you the next release. Overpriced, obviously.
Mastering the English language is fucking easy: all you have to do is to put an f* word in every fucking sentence.
The answer is quite simple: There are plenty of savvy computer users who don't happen to be programmers who can act as middle men between the two camps. Most organizations used to have these people, but as programming has become more of a commodity ("my kid can write a webpage") and development budgets tighten, many operations have done away with this layer and have programmers work directly with end users on the specs
Plus the specs only get you half way there! It is the FLOW of the functionality that really gets you a good or bad interface. We just need to recognize this again and expend the resources to include a knowledgeable person who understands enough about both sides to facilitate the best result.
There should also be educational tracks that specifically teach this skill!
Keep passing the open windows...
Software doesn't suck, users do ;-) Let's replace the users... oh, wait...
As a software engineer for 10 years, my complain against programming language vendors is that software is very hard to build. The companies that create the software that I can use to build software for my clients are totally 'lame', in the sense that a) they can not catch fundamental errors, b) the APIs they offer are anything but intuitive. As a result, developers spend their time fixing bugs, chasing null pointers, programming in various dialects, trying to make sense of APIs and API documentation etc instead of trying to make software better from the point of the end user.
How will programming language improvement help towards improving applications? well, here is how:
1) by automating the task of writing multithreaded software. It is doable.
2) by automating persistence. Since writing to memory makes a page dirty in the swap file of the O/S, why do we need to write data to files anyway? pages get written to the swap file periodically anyway, so there is not point in using I/O APIs. Persistence should be automatic.
3) if #2 happens, then the need for complex databases with data types incompatible to programming languages goes away. A database can simply be a linked list or a hash map.
4) if #1 and #3 happens, then there is no need for raw files any more. 'Files' would be typed, and thus easily managed by applications. Since files could be manipulated by any program, the application-centric paradigm would be a thing of the past, allowing for a much wider range of mini applications to be programmed on a user-request basis.
5) by automating data updating using the time-of-request trick and thus saving us the burden of manually doing it for every piece of information.
6) by enabling garbage collection at levels of computer activity, there would be no crashes and unexpected things.
7) by using proper type systems that do not leave room for errors, much more time can be devoted to better application design.
8) by making distribution of computing tasks over a network transparent, application programming would be orders of magnitude easier.
As it stands right now, 80% of an application's code has nothing to do with with the user requirements. Most of the code is for providing the necessary infrastructure and abstractions for the really useful code to run. If we programmers get rid of this burden, then applications and user interfaces will be improved tenfold, as we would not need to spend our times in things we should not supposed to.
It seems to me that there are three problems: the users, the providers (design, implementation etc.) and the bean counters.
Good software/UI designers are incredibly valuable. The entire design process is make or break for the ultimate success of a project - although that may not be aparent until years later - but is often given short shrift. Ans I'm utterly convinced that 1. you cannot get a good design from someone who is not skilled at programming, and 2. being skilled at programming does not make you a good designer. But I see lots of "designers" who have no experience in creating complex software and lots of software people who think they can design but have no idea how a typical user interacts with systems.
Of course users "just want something that works"... for a while. Then the definition of "works" starts to change and things like "could it do this?", "can that be easier?" and "why can't I just..." start to be heard. Then either one side or the other is unhappy - the provider side because they have to try and cram changes in that don't really fit or the user side because they don't get what they want (or it costs them more than they want). Sometimes it isn't the users but the marketing guys - same diff.
Of course if it had been built right in the first place then everybody would be relatively happy. After many years it still amazes me how many people, from both sides, simply don't get this. "Never time to do it right, always time to do it over" comes to mind.
Sometimes the users are lazy but often it is simply that they are not being asked the right questions in the first place.
Asking a user "what do you want the program to do?" is a recipe for disaster. A user can't possibly understand the implications for system internals that accompany "make the program do XYZ" nor should they have to... that's what designers are for. Ask them "what do you want to accomplish?", "what do you do now?", "what would you like to accomplish that you can't do now?" and so on... then craft a solution that fulfills that in a manner that is as natural as possible for the user and one that leaves room for graceful expansion in the future.
In the short run it's more expensive than a "something that works" solution but much cheaper in the long run... one of the hardest things is getting whoever holds the purse strings to really believe that.
And yeah, sometimes the users are just too lazy... they don't want to put the effort into thinking about their present and future needs. I always make a point of telling new clients that building a software solution is like building a house... you need to know where all the doors, windows and outlets are going in advance because after it's built it's really expensive, or just not possible, to put a new door in there, or move a wall etc. Without exception they all nod their heads that they understand but there are always some who come along somewhere past the 90% point with "can we put a bay window in here?" followed by "how can it possibly cost that much?".The single most effective tool I've found to help prevent this is to have a substantial minimum charge for changes.
And sometimes a "good" result is just not going to happen because the bean counters won't pay for it, or there isn't time or the goal is simply a short lived solution that doesn't have to be nice as long as it gets the job done.
The tyrant will always find a pretext for his tyranny - Aesop
If you're making a program, make 2 different interfaces available...hell even more. You need to have an interface for idiots to use and that needs to be the default. It needs to be something where they can basically click a few buttons and the program will do everything for them. They don't need 12 thousand options for doing this and that, because they won't even understand half of that shit anyway.
Obviously the other interface will be the full fledged nerd interface. This will have ALL the available options and will not baby the users through anything at all. This way as users become comfortable with the program, or are just good with computers in general, they can switch over to a more advanced interface. This approach always seems like a good idea to me...you can have all kinds of features, but you can build in some defaults for the people that just want it to work. When they figure out how it works...they can dive in at their own perrogative.
"Those who would sacrifice essential liberties for a little temporary safety deserve neither liberty nor safety." - BenF
Beyond pandering to end-users' collective inferiority complex, what's Platt's central thesis? Is he really saying that high IQ causes bad software? That programmers are control-freaks who create functionality rather than usable software? O.K.
d f
So what's he suggest? VB? Should we just assign stupider people to UI? Maybe he's of the school of development theory that assails Bjarne Stroustrup regularly with questions like, "Is C++ too hard for most programmers?" [1] (Bjarne's answer, btw, is always "No, C++ is exactly as hard as it is, although it's true some people shouldn't write C++").
Frankly, it's not smart programmers who write crappy error dialogs, but rushed, sloppy or dumb programmers and tech writers. I'd sooner blame poor quality on a misguided belief that the general dumbing down of programming tasks makes life less complicated and makes programs more robust. It isn't, and it doesn't [2].
Software development has always been exruciatingly dependent upon individual talent, and increasingly people don't want to pay the freight for polished, elegant work.
[1] http://www.research.att.com/~bs/MIT-TR-original.p
[2] see Mythical Man-Month, or Code Complete.
I'd recommend developers learn how to storyboard. It would help catch problems like you described, and suggest new ways of doing a task.
Two words: Interaction Design.
P roducts/dp/0672316498/
http://en.wikipedia.org/wiki/Interaction_design/
For those interested in it, you can grab a copy of Alan Cooper's "The Inmates are Running the Asylum"
http://www.amazon.com/Inmates-Are-Running-Asylum-
While the people interviewed do point important matters, their view on how to solve the problem is not, IMHO, adequate.
Also, putting guilt on programmers' shoulders reveals a lack of understanding on the matter. Many programmers are already aware that "YOUR.USER.IS.NOT.YOU." (stupid motto). The fellow just missed the mark. By miles.
Programmers study their whole lives to NOT think like users. They do so to learn how computers "think". To ask someone to understand both the users and the inner idiosyncrasies of the machine is just not reasonable.
What we lack in the software development industry is the role of interaction designers, and, of course, the willingness of the software development companies to PAY so they produce better and more "friendly" software. That does not come without a cost.
I want my computer to just work. That's why I run Debian Linux. Once it's set up, it just works.
Everybody knows 3 people with my name.
1. Most people don't know what they want...
2. However, most people know what they _have to_ accomplish.
3. A good developer will take #2 to heart, grit his/her teeth and understand the use to which the program will be put prior to doing anything.
4. A great developer will also engineer the system well, in the true spirit of 'engineering'.
5. A good business manager paying for the great developer will listen to the developer and provide feedback on any subject except usage and technical issues. Technology is the developers lookout, usage is up to the users. Work it out together - developer, you are the referee as well as participant. Management gets to fund or not-fund. That's it. They gave up any other input when they stopped being users of the system and took the bigger paychecks.
6. End users will not care about any of this list except #2, so you gotta get that one right.
I am nowhere near the first person to figure this out - much better minds than mine came up with this long ago. So, why does software still suck, and do people deserve $hitty software if they are unwilling to insist on good software? Or, do users - who are always (in my experience) the last ones to have input into a project, if they get any at all - deserve the opportunity to lynch managers when a bad app. is deployed and they are forced to use it?
What a terribly dull and uninteresting troll. The misspelling of "Linux" is a mildly original touch, but everything else is depressingly old hat. And at least get a little more up to date; Linux servers may have been rare a decade ago, but its one of the most common server operating systems in widespread use. BeOS is another blast from the past, another indication that this troll is distinctly long in the tooth.
And no, mentioning Vista isn't fooling anyone, not when you then follow up with a paragraph talking about Windows 95, Windows 3.0 and INI files. At least find some trolling material that would be relevant this century. It sounds as if you just substituted "Vista" for "XP" and hoped no-one would notice.
Please do better next time.
In Finland we have short courses to get a "driver's licence for computing" (direct trans.) so someone here thought the same as you it seems. I think it's even recognized pretty widely among employers (for general jobs requiring a computer)
As a programmer I value myself based on what the end-users think of my work.
When someone uses something I've made and I don't hear anything back, I feel great because they often have a direct line to me and they know I listen.
When I hear great things and see the planned-for results of my systems working, there's nothing like the feeling of having something you've helped create make millions of dollars and keep people happy and fed.
I've made personal sacrifices in order to see my concepts and proposals come to life.
A toolsmith must be judged by the suitability of his tools to those who use them.
I'll admit that when I saw "TRON", back in my 8-bit days, it influenced me.
I want my works to represent me, and I don't need accolades, or lots of money.
I just want to feel like what I've done hasn't been a waste of time.
Every good programmer feels the same way.
If they don't then they're really managers, they just don't know it yet.
Every new form of media has it's own Requirimento
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".
I once had a part-time job evaluating the relevance of search results for various queries in Google, and I can tell you that you overestimate many, many users' degree of understanding of what the Google search box does. They type questions into it. (And that's why the idea behind Ask Jeeves is a great idea, whatever the execution.)
Are you adequate?
Why should the simple act of closing a window (e.g. because I'm done working with the thing in that window for that moment) present me with a choice that risks me losing my work?
There's no reason that holds water here. The technical ones that will probably come to your mind first (e.g., "because the computer needs to know whether you want to keep that document") are just bad--they demand that the user adopt to limitations that the computer ought not to have in the first place.
If the user opens up a window and starts typing into it and then closes it, the window ought to disappear silently from the screen without any nagging, and the user should be able to get back to what they were writing later on. The work that the user did should never be deleted unless the user explicitly asks for it to be so. The computer should have a very visible indicator somewhere of how much of its storage capacity is free, and gradual indication as the danger of filling up that space comes closer. There should be a powerful system for finding and organizing and deleting documents on the basis of their content; for more advanced users, this system should also provide versioning for documents.
Are you adequate?
Basically I sometimes wonder whether putting a PC in every home was such a hot idea after all.
Consider that this was the dream of Bill Gates. Consider the end results as implemented by Microsoft.
Then consider you question again. The answer might be inherent in the original poser of the concept.
"It is a greater offense to steal men's labor, than their clothes"
Although a car shouldn't have the same controls as a helicopter, a car should have controls recognizable from one model to the next. Likewise, a helicopter pilot should be able to feel at home with controls regardless of what helicopter he hops into. Standardization and adoption of the best working practices goes a lot into making this possible.
Yet outside of desktops, office suite type apps, browsers, and image editors there's not a whole lot in the way of GUI standardization. It would be a nice thing to have. Or at least programmers should realize that interface design should at least parallel that of the OS their program runs on so users will have some clue. Basic preset defaults, a working help menu or pointer, and initially hiding advanced features that could break functionality if misused would also be some things that should be standard practices in GUI design.
Note that a good GUI can't help bad programming, but a bad GUI can hurt adoption of good programming. If the program is intended for a user audience other than programmers, a good or even intuitive interface should be one of the goals outlined from day one.
The true wonder is whether putting a computer in every home that is wide open to all sort of crap was a wise idea. For this you can blame MS. After all, for 99% of the home users, a system with the server service turned off is perfectly usable. (BTW, that would prevent 99% of the initial worms that were out on the net.)
So, if MS were to ship a system with only the things that most people would use enabled, and the rest available to be turned on with minor inconveniences, the rest of us would have lived much more convenient lives over the past decade.
The cesspool just got a check and balance.
Apparently, using Lunix makes you illiterate.
It's a sad state of affairs, when an operating system has to be compared to high-tech, circa 1990. It's an even sadder state of affairs that circa 1990 is still looking at Lunix in it's rearview mirror.
Perhaps, instead of writing inane replies, you should be trying to get Lunix to automatically detect hardware properly... a neat little piece of work MS was doing back with Windows 95. Or, if that isn't to your liking, you could help get Lunix to install applications without manual assistance. You know... something MS has been doing... like... forever. Wow... even MS-DOS did a better job installing applications than Lunix does.
"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. "
Problem solved by clocks that set themselves. Remember some design problems come about because of technical limitations at the time of design. Remember when VCR's had to be fine tuned using a small knob, or even a screwdriver? Manual threading?
"Power-on and Play are big buttons right on the front, and the more complicated stuff is behind a flip panel. "
You left out the universality of icons. Power-on is what symbol? Play is what symbol? How many devices other than VCRs use 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."
A lot of DVR's have adopted the TV Guide(TM) grid to do programming. Color-coding by catagory. e.g. history, sports, etc.
"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."
So how would you approach word-processing?
That may be part of the reason, but not understanding users isn't the reason why we're still finding exploitable vulnerabilities in software like Firefox, OpenSSL, GnuPG, OpenSSH, and Linux.
And don't even get me started on Windows. Try reading Raymond Chen's blog for a partial list of reasons why writing robust software for Windows is so difficult, if not impossible. You'll have to think, because Raymond seems to completely miss a lot of the design problems when he describes their solutions.
http://outcampaign.org/
"Thank you, these were my exact thoughts. Driving a car seems "easy", but just look at the sheer amount of time that goes into driving a car. And even once you can drive the car, you may need the instruction manual to figure out the radio b/c Ford's configs are different from Honda's."
The driving experience has a better feedback loop than most UI's
AHHHH! As a programmer, I can tell you the absolute #1 biggest problem by far with software today. It can be best summed up in the phrase "we'll patch it." Why did N64 games have less glitches than most Xbox games? Why are about 99.9% of tattoos done perfectly? It's because if they're not perfect, the creators are screwed. The only reason that software has gone completely downhill is because people don't spend the time extensively testing every single feature in any program! Management makes them rush or they get lazy and release some crap program that is either not fully tested or actually has known glitches that are hard to fix, and they just figure they'll patch it later. Even if they do, the customer has to use that piece of shit software! Take AIM Triton for example. Tons of beta testing and finally on the release, the mute function doesn't work, signoff rarely works, it crashes every 30 minutes at least, there's basic issues with just sending a plain text message, it freezes up compeltely if you try to paste something in from slashdot (iunno why just slashdot but that's all it happened on) I don't even want to know what kind of sick people let that out into distribution but wow. So that's why software took a dive.
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
The article argues for trading off control for usability.
Gnome does this (compared to other desktops), so why isn;t everyone moving to Gnome? My experience is that a lot of ordinary users tend to end up saying "I can not find how to do X". I now reccommend KDE for non-geek users other than those whose usage really is just web browsing and word processing.
Almost everyone has something that they need control for, and this tends to override their basic usage of other things elsewhere.
Incidentally, I do not want to just knock Gnome: it is beautifully elegant and I keep trying it, but I think it takes simplicity too far.
Software still sucks because:
Most people don't understand the big difference between making software and say making a skyscraper.
1) With software, the _prototype_ blueprint actually compiles and runs and is usually sold as is (version 1.0).
2) Too many people keep thinking that the programming part is like the construction phase of a skyscraper, and that it should be planned and managed that way.
But they are WRONG, programming is more like coming up with a detailed design for a new skyscraper - the complete blueprint.
The actual construction of the skyscraper is more like a compile of the final version of the source code.
Blueprint = code. Skyscraper in use = code being run.
3) The other important difference with software is:
The design cost of a software project is much more than the compiling cost.
The design cost of a skyscraper project is usually far less than the construction cost.
The owners of skyscraper projects are usually willing to spend a fair bit more on the design if _necessary_. No problem spending a million more to make sure the skyscraper "just works" - because it's still a fraction of the cost of building a new skyscraper.
But for the owners of software projects _each_ design and redesign adds significantly to the cost of the project (in time and money), and it doesn't matter whether it's the prototype, or the "final" version you are designing. Redesign = project costs 2 x more.
Constructing one thousand copies of the same "skyscraper" is trivial and cheap in software but not for civil engineering.
Designing one thousand _different_ "skyscrapers" is not trivial or cheap in software or in civil engineering.
And the advantage of designing skyscrapers is it is easier to _realize_ and explain to the bosses that they are asking you to break the laws of physics - "sorry you can't fit an extra 3 elevators there, this is how much space one takes, this is how much space there is".
Seems to me that most "Management", "Software Engineering" and "Project Management" people[1] don't understand these differences, or don't want to accept these differences.
And that's why most software sucks and will continue to suck.
[1] A project management trainer once asked a class I was in for example suggestions on how to speed up the building phase of a software project - he said for a civil eng project you'd add more machinery and people e.g. bulldozers, construction workers etc. So I suggested that the equivalent was more and faster CPUs, and he didn't like that.
I doubt the civil engineering bunch will keep adding fresh grads to speed up the design phase of a new building.
"The probkem is not competency"
You are obviously a programmer.
... you just have to pick the a good sample of users, take a cross section of general users, and a cross section of the power users. Have the tech literate and slightly programming lituerate power users, decode what the other general user group is trying to say. Because the real problem is in conceptualization and actually verbalizing what you want to say, and the other problem is have the users clearly defined the problem they are having with your software, its function and it's interface? That's what you really need, you need someone to help REFINE what they are thinking and what is being said and make it clear and coherent by assembling the bits and pieces of information they are giving you.
I'm sure there would be some among the most savvy tech literate people who've dabbled in a bit of programming like Visual basic or some other language who are dedicated... these users will get frustrated with user interfaces and start inventing their own, on drawpads, or might pop into visual basic and just draw out an interface and plop down controls without code, and have some kind of rough sketch of how it should work, find these users *asap*.
That seems a little rich coming from a person who can't spell "Linux", and doesn't know what the phrase "Security by obscurity" means. Or perhaps you could explain how an OS can hold a large market share, be open source, and rely on security by obscurity.
It's a sad state of affairs, when an operating system has to be compared to high-tech, circa 1990.I wouldn't be so hard on Vista. It's circa 2000, at the very least.
Okay, so it still lags behind OS X and Linux in terms of graphical capability, in virtualization, in its filesystem, its terminal, its file manager, its software installations, its desktop environment...
But with Vista, it's not so behind as it once was. It has that neat blurry transparency now (well, for high end machines anyway), and desktop widgets (well, almost), and a usable calendar integrated with the desktop. I believe it also has integrated desktop search as well, like Spotlight or Beagle, though I could be wrong. It's menu has been changed, so it's a little like that SLED menu Linux had a year or so ago. No multiple desktops yet, which is a pity, and the file manager barely competes with nautilus, let alone konqueror. The default browser isn't that good either, but luckily you can install Firefox pretty easily.
Perhaps, instead of writing inane replies, you should be trying to get Lunix to automatically detect hardware properly...Ah, a genuine complaint! If you're going to troll, you need more of these. A troll that's mostly truth will catch more bait than a troll that's mostly clueless. Linux certainly has problems with some bits of hardware. I mean, sure, it doesn't have much trouble with motherboards, processors, monitors, graphics cards, memory, hard drives or DVD drives, but you should see the problems you can have with the wrong type of wireless card or webcam!
a neat little piece of work MS was doing back with Windows 95You mean I could stick my wireless card and webcam into Windows 95 and they'd automatically work without having to mess around with CDs full of drivers? Huh, Windows XP has really gone downhill since then. Funny that I don't remember Windows 95 being able to do that...
Or, if that isn't to your liking, you could help get Lunix to install applications without manual assistance.An interesting idea. I could even design a system that downloads and installs entire applications with just a single click of a button. I could call the system "apt", and... oh wait, that's already been done.
The problem with your troll is that you're dealing with old issues. Firstly, bring your complaints up to date. Incompatibility with wireless cards is a pretty modern problem. And of course the lack of popular software on Linux is a timeless classic - why can't it run Adobe Photoshop? Why can't it run this computer game?
You could also point out the incompatibilities between Linux distributions. Why isn't there a common installation process? Why are GTK themes incompatible with Qt themes? Why can't applications have a common file-chooser interface?
Those are the sorts of things you should be trolling about; not ancient problems that were only relevant last century. Linux has tonnes of problems with it; you shouldn't have any difficulty finding problems with modern Linux distros, and it's it'll make your troll a lot more tempting.
I think Ubuntu and Gnome have it right. I work in IT and do some coding on the side, but use Ubuntu at home for this reason - is it stupidly simple. Most of the programs in the main repositories of Ubuntu are gnome based apps with extremely basic interfaces that just let me get the job done. I don't spend time fiddling with configs/millions of toggled options/etc.etc for 95% of the apps that I work with.
But for the 5% that I do need to work, all of the underlying power options are there in some shape or form and they are typically open for me to tweak through config files and command line arguments. That helps me if I need it because I know where to find it. But grandma will never need it and she will never know those capabilities exist, and rightly so.
So the design metaphor is make software appear simple, easy and intuitive. But make sure the powerful options are still available for power users, but make them so the everyday user never sees them.
His point was that I'm like alot of slashdotters, I get caught up in wings flapping on a flying creature and forget why they're flapping in the first place. Essentially, I was over analyzing the problems instead of just answer a simple question. We can simply ask the users what they need and go from there.
The point I was trying to make was slightly different ... vendors tend to create half ass crappy software that doesn't meet client needs. There is no reason why a physician should have to go out and buy some experimental dos program to crunch numbers for her research when you have clinical database with an front end. When I do stats for my websites, I either get a tool to do the stats or I would just write whatever I need in perl or php. But, I would have the sense to add it to my packaged system.
However, alot of programmer (particular us Linux lovers) tend to forget that we're not going to be the end user and that for most people our program function as black boxes. Alot of programmer don't think about the fact that People use our products.
But, a stated before, most end users have no idea how to think abstractly or conceptually. In IT in general, and programming in particular, you're not bound by physics so much as your bound by logic and work flow -- you have to fundamentally understand what you do well enough to completely and clearly explain the issue. This comes from years of tech support and working in a hospital -- ask a user what their problem is and they'll give you 50+ answers that have absolutely nothing to do with the question at hand.
This is not to say that people are stupid -- they simply think in very tactile fashion -- they know what they do almost instictive but understand it clearly enough to outline the steps in their logic. Try asking someone how they brush their teeth. Hopefully, they brush at least once or twice day. But they may not lay out the logical steps to brush one's teeth. You couldn't build a robot that could emulate toothbrushing very well off of the answers. More than likely, They've been brush their teeth for so long, its second nature, they're no longer thinking about what goes into brushing their teeth.
This is the dilemna that programmers and IT personnel face with end user -- the clients answer is fix it and they expect you to be a mind reader. Its not typically out of malice, arrogance, laziness or stupidity. Its out of a fundamental lack of ability to process what you want and need clearly.
Look at other technologies. For them to "just work", time-spams of 100 years or so from first working prototype are quite normal. Computer software will not be that much faster and the time will be needed for each individual type of application. The only way to get good software faster is if you learn to use the more expert-oriented interface of expert software. For example text editors are quite mature, but may require you to learn some obscure keyboard shortcuts. So what? We all spent several years to learn how to read and write! Why not spend two days on learning how to write with a text-editor? Of course it should be one with a stable interface, like vi or emacs or a wordstar clone (joe) and not a moving target like Word.
In short, no, software will not "just work" ever for most people currently alive, except maybe the young ones. But they already can use some of the expert stuff, because they are willing to learn. This in turn may lead to software never "just working", because all those unflexible enough to have trouble will have died before the goal can be reached.
Face it, technology is difficult and needs decades to centuries to mature. Obviously computing is not mature at all, except for a few expert incarnations (Unix) with limited application scenarios (no networking besides email, usenet and ftp...). It is just the big greed to make heaps of money that causes computer related companies to tell everybody this was a mature technology. Compared to about any other technology that claim is wrong in a painfully obvious fashion.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I want a "do you want to save this?" dialog, because sometimes my answer is No. Am I really the only person who ever makes accidental changes and then wants to throw them away?
Ok, UI experts will say that's a job for "undo" and that the undo stack should be saved with the document. But even that is a compromise; if I share the document, there's a chance I don't want it to include a revision history. The comeback to that is perhaps: "Oh, but such a 'normal' save which includes undo information isn't an interchange format; if you're going to share a document, you should save as rtf or something." Great, I bet the people who say computers suck, are really going to love that solution. (I've tried it. People hate it and think I'm a weirdo for suggesting it. Just you try to get people to stop emailing native save formats.)
The reality is that computers still do consist of files on relatively permanent storage, combined with ephemeral RAM. You can try to handwave that away and create a toaster-like abstraction, but in doing so, you deny reality. Denying reality usually has undesirable consequences.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I'll go out on a limb and say, it doesn't matter how educated OR stupid your users are, there's more involved than just the software or the people using it.
... because they do get it right in the end, they just don't explain it the way I do. Occasionally, I can help to straighten someone out on an especially tricky job, and they know who to ask!
... and just exactly how far we can go! The computer systems are only a part of that.
... and we recently held "think tank" meetings across the state to see if anyone could suggest ways to improve things, parts of the system that were no longer needed, parts that could be "short-circuited" without impacting the legal and procedural requirements we are all bound by. It was deemed a resounding success, with many RFCs generated!
The developer I read (down the page) who's "not allowed to visit the end users" is working blind.
The people who have complained "end users don't know what they want" and "end users don't ask for the right things, then complain they didn't get what they asked for" are missing the point that the end users did not understand the question, especially as to it's scope.
How far can you get if you don't know what they do, and they don't know what you can do for them?
I work for a government department here in Queensland Australia, and amongst my fellows I'm a bit of a "computer geek".
As we've used the same system since 1994 (with mods/improvement) even the most disinterested of my colleagues has developed a strong understanding of how to operate the mission critical client/server database application that we all use for our most important duties.
My knowledge of email, the web etc has rubbed off on all of them to the extent that I now sometimes have to clamp my mouth shut and listen for a couple of minutes when one of them is explaining something to someone else
They don't let me train someone new to the section because my view of our systems is extremely tech centric, and our work requires strong knowledge of correct procedures and some law. They need to know what to do and when to do it
To get to the finely tuned state we are in has taken over 20 years of testing, trialling software, using a reduced initial system that did only part of the job
Perhaps all developers need to be dragged back to the days of "flowcharts" as a developmental tool, so as to build in the actual function/business that the user carries out into the program. And the flowcharts have to be drawn up at meetings with users, not managers unless they promise to sit quietly at the back of the room and make a maximum of one sensible suggestion per hour.
Don't blame me, it's usually 2 in the morning when I post
that's the most stupid post ever.
i would quit my job and shoot myself before i'd let an avarage user tell me how to design my software.
avarage users seem to get more stupid every year.personally i think it's the fault of stupid software outthere that actually does 2 much for them and then they just stop thinking to the point of not actually being able to think 2 steps ahead and click a button.
"where do i actually apply all the changes i made to the grid"
"the big apply button on the right side sir..."
"oh...well...someone should make that more clear"
or maybe that guy just needs glasses and maybe apple should be sued for the most idiotit UI ever.I've come to notice that apple users seem to suffer from the stupidity sindrom more ofthen than windows and linux users combined.
the last 2 actually use their brains and seem to be able to use LOGIC when trying to use an unknown program.
By logic i mean they're able to predict that the EDIT menu or button might lead them to functions that allow them to change and update things.
Apple users seem to expect everything to happen without any confirmation.
Ofcourse when they get a program that does that and they fuck up a database used by thousands of users they use the:
"well it didn't ask me if i wanted to save all this..."
all and all i fear that stupid people are going to be the main fault why programs are going to be giving users far LESS freedom.
Trust me the developer wants to give u contron and more options more buttons and more ways to do things but stupid people kill his mood on a daily bases to the point where he gives up...and makes the UI behave in the most IDIOTIC way he can imagine.
And sadly he gets less calls....
It is simply not fair to request from anybody to buid systems that improve the productivity of its users AND have a small learnning curve. Most people simply do things "the wrong way" (yep, even on their choosen area, competence is rare), and don't want to learn something new. Yet, they want computers to magicaly turn their processes into the optimal ones. It is even worse because lots of processes used to be "the right way" due to constraints that computers eliminated, and are now "the wrong way". Still, users don't want to learn something new.
Software designers are, thus, presented the choice of making a system that will please most people, or one that will please competent people. The first path leads to really bad software that makes a lot of money, the later one can lead to very nice software, but will almost surely be a commercial failure. Not that hard to chose, is it?
At least, with time competent people prevail. But it takes a lot of time, and when they do most of them are using dated processes (the ones that used to be "the right way"), and will refuse to learn new things again... FOSS (the software, alone) can survive that cycle, but most people that want to make a living of software can't.
Note: I'm not stating that software made for competent people is good, just that it can be good. Programmers competence are quite important here too.
Rethinking email
The problem is that most coders write software for themselves (to scratch an itch) or for other coders. Coders should realise that 99% of people just want to get work done. Writing software that impedes this is doomed to failure.
'He who has to break a thing to find out what it is, has left the path of wisdom.' -- Gandalf to Saruman
In TFA, this sticks out:
"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."
Well, in this country, the automatic transmission license is (was?) officially called "disabled person's license", often shortened to "tard's card". Maybe the problem is this: the point of view is that the user is either completely ignorant or a programmer. There is a large population of experts (non-IT) who use complex software daily: these people are of regular intelligence and ability, but they're not programmers. Their eyes don't glaze over when you explain them the minutiae of the operation of the program; they listen, but don't necessarily get everything right the first time.
I was seriously hoping for an article about how even the software intended for daily professional use still sucks, not one of these rants about not understanding words like "file" and "directory" or how tabbed browsing is a too complicated paradigm.
I just hate it when people use horrible analogies to support their case, like this one FTFA :
Boxes that ask users to confirm whether they want to take a step such as deleting a document are another example of what he calls a bad feature.
"Your car does not ask, 'Do you really want to start the engine?' when you turn the key," Platt said.
It doesn't have to ask you that because it's reversible, you can turn it back on. Now deleting a document is not (within the scope of the end user) reversible. That's why it's necessary. A better analogy would be if your car asked you 'Do you really want to run over that elderly woman who's crossing the street?'.
This being said, if you apologize to your screen when there's an error message, buy a Mac, and stay away from word processors.
Platt, who has also written nine books for computer professionals, has a message for software developers: "Your. User. Is. Not. You."
No shit Sherlock, I'm glad I read Slashdot so that I can realize that potential users of my program don't necessarily have the same level of technical skills as I do, I would have never found this out on my own.
You just got troll'd!
I think this problem is one that stems from American culture more than anything else. Americans, on the whole, lack an adequate sense of awareness, both of themselves and of others. Programmers and tech designers don't stop to think about how a product will most often be used. What's more, they don't think about what a user really wants, and instead center their thoughts on getting the product out the door and getting paid. Sad thing is, if they program things right the first time (though this applies more to actual software design, scalability, and modularity) they'd be out of job. I can't think of any profession where they get paid more and have the most job security for doing a mediocre job over a great one.
This should be named "Why fox news sucks and what can be done about you reading it"