notes-whyAreComputersHardToUse.txt

there's an interesting discussion on slashdot on why computers are too hard to use. It was provoked by this article:

http://www.washingtonpost.com/wp-dyn/articles/A32411-2003Feb5.html

by someone who hates new computer stuff and blames the techies.

Here are some points of view from slashdot users on how things have come to this:

Here's a good quote about this last point:

"Typically when I arrive on site to show the customers the software we just spent a year creating for them, (after the customer signs off on the requirements) and I show them some super wham-o-dyne feature that is not included in the base package, I usuallyt get one of these responses...

1. (90% of the time) What a stupid feature. Why do we have that? Does anyone on earth use this feature?

Typical answer: No one else has it but you, your firm asked for it, and we spent about a jillion hours of developer time working it in and testing it even though the only person on Earth who thought it was a good idea was your project manager."



some actual posts are below, from http://slashdot.org/article.pl?sid=03/02/06/2246206&mode=thread&tid=166:

(obviously, my selection is biased by my point of view; you can go to the above web page and see the rest if you want)

 I am the guy with the binder (Score:5, Insightful)by TheNumberSix? (580081) Alter Relationship on Thursday February 06, @06:58PM (#5246274) I'm one of those software instructors who provides the training on the huge custom software package to the customer.

Typically when I arrive on site to show the customers the software we just spent a year creating for them, (after the customer signs off on the requirements) and I show them some super wham-o-dyne feature that is not included in the base package, I usuallyt get one of these responses...

1. (90% of the time) What a stupid feature. Why do we have that? Does anyone on earth use this feature?

Typical answer: No one else has it but you, your firm asked for it, and we spent about a jillion hours of developer time working it in and testing it even though the only person on Earth who thought it was a good idea was your project manager.

2. (10% of the time) What an excellent feature! I'll really use that. It will make my job easier. I'm glad we have this super wham-o-dyne feature.

I've seen it again and again. Most of the software ends up confusing users and being far too complicated because a few people insist on adding bizarre stuff to the base package.

I've seen the same thing in some open-source projects too, where the main developer can't resolve (or doesn't want to resolve) a dispute between two other coders, so they add in "options" so everyone can be happy. But it sometimes ands up making the final product a mess.

And as for spending enormous amounts of time in training on the new computer systems, I have to say that many times customers demand it.

If a customer lays down a lot of money for a custom software package, they simply expect an instructor to appear on site, in a tie, wielding donuts and coffee and lunches. We have CBTs that take about 2 hours and cost virtually nothing and cover the base package really well, but customers would rather have half thier staff sit around in a class room for two days instead. For non-technical personnel especially, they just demand that level of service if it's needed or not. So at least in my case, I can't take the blame for forcing the end users to sit through training! Guilt no more!

 Not meeting the end user (Score:5, Interesting)by JohnFluxx? (413620) Alter Relationship on Thursday February 06, @06:43PM (#5246123) (http://www.compsoc.m...bin/polynet/poly.cgi) I worked on large systems for large companies. However I never got to meet anyone that actually used the product. We were on the forth revision of software by the time I left.

I was basically the main coder. I was pretty good at my job, but I would get 100 page technical specs, 70 pages of which would describe how on the front page this dolphin would swim from one side to the other. On a company intranet. sigh.

Several years later I saw the said company at a careers fair. I mentioned that I wrote quite a lot of their intranet, and how it was doing. They said there were still many problems with it - and I wasn't surprised.

The trouble was that I had to go through my boss, who went through the company bosses, who went through the top level managers. The end users weren't consulted at all.

Also everyone wanted to see results _now_, requiring fast development.

Anyway, I've rambled enough.

 It is because...... (Score:5, Insightful)by Chardish (529780) Alter Relationship <chardish@l3 3 t .ca> on Thursday February 06, @06:37PM (#5246051) (http://lemonwood.aexx.net/) In software..

1) Corporations think it's a good idea to add more features to their software. 2) Corporations have no idea what people actually want to do with their software's new features. 3) Corporations fail to realize that what we often want are not new features, but actually smoother design, better ease of use, more speed, and more stability.

Thus, what we get is "bloatware" such as ICQ - where so many new "features" are added to the program that it becomes impossible to use and navigate even when you want to use the program for even the simplest functions. (When I got the latest version of ICQ it took me 5 minutes to figure out how to add a new contact by UIN#.) AIM is headed this way, too.

I can't stand Office XP because of all the stupid features you don't need.

Even Office 97 has a large plethora of thoroughly useless features. Send To Routing Recipient, Send To Fax Recipient, Footnotes, Comments, Document Map, Field, Cross-Reference, Index & Tables, Insert Object, Insert Bookmark, Look Up Changes, Track Changes, Change Case, Style Gallery, Merge Documents, Letter Wizard, Formula

It gets worse as the version numbers get higher. Maybe what we want is more ease of use and less damn paperclip animations.

 Re:It is because...... (Score:5, Insightful)by iso (87585) Alter Relationship <slashdot@ukhardh ... m minus language> on Thursday February 06, @06:55PM (#5246244) (http://djnumbernine.com/)

I believe that what you're saying is true, but you're forgetting one important thing: people buy on features, not "smoother design, better ease of use, more speed, and more stability." I have done a lot of reasearch in this topic, and read a lot of market research data. The results are quite conclusive: the vast majority of users believe that speed and stability (bugfixes) should be free. While "better ease of use" and "smoother design" are things that some customers are willing to pay for, most decide to make a jump in version almost entirely based on new features.

Unfortunatley, this is the way it is right now. People may want a more easy-to-use program that's more stable, but they don't know it (or, at least, aren't willing to pay for it). So what's the solution? If people are only willing to buy on features, where's the incentive to spend development time on bugfixes and usability? If people truly want this, they're going to have to vote with their pocketbooks.

 The software is usually designed for the wrong reason in the firstplace: to fulfill a marketability niche seen by some buzz-word driven demand. It's sold from a marketing and sales rep, whose usual job description could be summed up under "schmooz with customer", who pulls out his checklist of latest technologies to make sure he promises X, Y, Z and hyperbaric interoperability with toasters from obscure places like Kansas.

These requirements and obscure promises are handed to engineering who satisfy the technical aspect and ship it. Never have any of the QA departments I've seen have a dedicated usability expert; most of the QA engineers were just re-tasked programmers without any HCI design principle background or experience.

So, since corporate and enterprise level software development is driven by the sale by those out of touch with the true needs of those making use of the software the incredibly wide gap develops that frustrates the @#$( out of everybody.

 A very long time ago, I took a class called systems analysis. In thisclass they taught to design computer systems by using very radical technics like; Asking people how they work

watching them work to make sure they did what they said they were doing or even working with them

Asking people what would make there work easier, faster

Letting them make changes to the user interface and participate in testing

It sounds like all of they radical ideas never took. If the workers don't like say using MS office, then get new people. If the business doesn't fit a Quickbooks template, change your bussiness rules. Why do Games work for their users and business programs don't is an easy one, Game programmers play games, bussiness programmers usualy don't run businesses they work for them.