Stanislav Meduna wrote:
>
> I personally thought that Red Hat is the company with
> the strongest potential to bring the Linux "to the masses",
> i.e. also to desktop users. If your top priority is chasing
> performance to beat MS in some server benchmark results,
> this is a bad news for me and (I am sure) for many other
> users too.
As a reluctant windoze developer newly encountering the Linux
learning curve, I may have a few useful observations to
contribute. I lurk on this development forum because I'm hoping
to eventually port my software products to Linux, but so far my
company only uses Linux for its servers. The bottom line for me
is that regardless of how much I might like Linux, in its current
state Linux is unusable as a desktop OS for my customers.
I may call myself a software developer, but my real business is
doing for my customers what they want me to do. They don't use
my software because I want them to use it, they use it for the
value it provides within the context of their own business
operations.
I submit that the primary obstacle to general acceptance of Linux
as a desktop OS isn't Redhat, but rather the current nature of
Linux itself. Linux suffers from an "expectance of expertise".
It doesn't matter how superior the OS might be - as long as its
learning curve and "cognitive operating overhead" impose
significant demands on the user, it will be rejected by the
majority of desktop users.
Consider:
The primary purpose of business software is to provide a valued
service to the user in a cost effective manner.
According to what I call tool theory, every tool requires some
amount of operating overhead. Any operating overhead required by
the tool directly reduces the total mental capacity the user can
focus on the task at hand. The value of a tool is the ratio of
what the tool can do for its user factored against its operating
overhead.
The operating overhead of a hammer probably represents the
minimum operating overhead possible. At the other end of the
spectrum are many computer software packages where the operating
overhead is so all consuming that those who operate the tool have
no cognitive capacity left to actually use the tool.
The objective of tool design should be to minimize the operating
overhead of tools in order to maximize their usefulness in
accomplishing the tasks of their users.
Expectance of expertise is a very common trap for software
developers and manual writers. Those who possess expertise
perceive issues within a well developed context, and tend to be
unable to separate individual aspects from the overall context
within which they operate. Those who have made the effort to
accumulate sufficient expertise with the OS tend to discount the
volume of specialized information they use, and expect a similar
level of commitment in users. (If I can make the effort to learn
this stuff, so should everyone else.)
This perspective is also the reason why so many manuals are
largely "less than helpful" for new users. Manuals tend to be
written by people with substantial knowledge about their topic -
people on the "other side" of the learning curve, who too often
are no longer able to address issues from the perspective of
someone on the uphill side of the learning curve.
I consider my target customer to be "aggressively computer
illiterate" - he doesn't know anything about his computers, and
perhaps more importantly, he doesn't *WANT* to know anything
about this computer. He has no interest in "using" his
computer. He views his computer solely as a useful tool for
accomplishing a task. He wants to put as little effort into
using his computer tool as possible. He has absolutely no
interest in "lifting the hood" to fiddle with the operating
system.
In its current state, Linux is still far too much a technician's
operating system to be acceptable to the desktop market. My
customer's wouldn't have a prayer of setting up their own Linux
system - they would find the idea of manually editing the dozens
of configuration files overwhelming, and the very thought of
having to recompile the kernel would terrify them.
It seems to me that the key to Linux on the desktop is the
development of an artificially intelligent installation,
configuration, and maintenance utility that can take care of all
the decisions and maintenance functions that are beyond the
capability - or interest - of aggressively computer illiterate
users.
While I'm on my soap box, here are a few more principles of
software development that have served me well, but seem to get
missed in programming books:
Debugging is a cost of production that is included in the sale
price. The tech support costs of dealing with overlooked bugs in
the release version have to be paid out of post-sale profits.
Reliability and usability are far more important than aesthetics
to users who depend on their software.
A couple of hours spent pre-emptively eliminating potential
sources of user confusion during the design phase can save you
from having to spend hundreds of hours dealing with unhappy users
later.
The ego of the programmer is best defined by the value his works
provide to users, not by how impressed he is with the cleverness
of his code.
--
Kort E Patterson
http://www.overalltech.net/
http://www.hevanet.com/kort/
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
