Why oh why oh why

[Beth Agnew]

No, if anything it would be a "we don't get no PR" thread. :-) In 
industries that are more mature than software development, product 
design is responsive to customer needs and complaints. What do _you_ 
think the aerospace industry would be like if it behaved like software 
development? Hint: none of us would ever want to get on anything that 
left the ground. The trillion dollar automotive industry creates 
beautifully designed products that specifically address customer 
problems. You keep banging your knees on the steering wheel when you get 
into the car? Next model has an adjustable steering column. Even the 
smallest rattles and tings get looked at. What if GM said "Starters are 
just too much cost and trouble; y'all are going to have to push the 
vehicle to get it started instead."? Absurd analogy perhaps, but are not 
users being asked to conform to how software works instead of the other 
way around?

About 8 years ago the big thing at the developers conference was the 
three-panel explorer-type interface with a node tree on the left and 2 
panes for options on the right. This was not the big thing because it 
had been determined that it was the best design for user action; it was 
because there were MFC classes and code that would make building such an 
interface faster, easier and cheaper. The users would just have to get 
used to it. So we did. Now, of course, it is "the standard", but only 
because it's ubiquitous.

Gene Kim-Eng wrote:
> I hope this isn't the start of another "we techwriters are 
> undervalued" thread.  Anytme I'm on the verge of becoming "a little 
> testy" because someone's not listening to my suggestions about SW UIs 
> I just take
> a moment to think about a (non-writer) fellow I met some years ago 
> during my previous life as an aerospace engineer:
> http://onlineethics.org/moral/boisjoly/RB-intro.html
> ----- Original Message ----- From: "Beth Agnew" 
> <beth.agnew at senecac.on.ca>
>> As a profession, we are a resource that can help companies avoid or 
>> fix usability problems -- yet so few development organizations use us 
>> in that way, and often resist our efforts to advocate for the user. 
>> Along with customer support and training departments, we point out 
>> areas where customers have, and will have, problems with the product, 
>> but then we see management make decisions that go in a different 
>> direction.  No wonder we get a little testy from time to time. 
>