Something to think about

[Doug Loss <dloss@csrlink.net>]

This message was posted to the Independence mailing list yesterday.  It's 
fairly long, but I think there's a lot of meat here for us to think about.  
I'll be posting my requests for project updates later today.  For those of you 
who are project leaders, how about jumping the gun a little and updating us on 
your project's status?

--------------------------------------

So you want to be on the desktop?

A Linux programming call to arms.

By William A. Housley

Forward:

How would you like to see Linux PC's for sale at your local general retailer? 
Impossible you say? Linus Torvalds (in a chat interview) seems to think that it 
will take about three years for Linux to become commonplace. 3 years!?! In this 
industry 3 years may just as well be 100. At LinuxWorld he called for an effort 
on the desktop.

Lately, I have been studying Linux and the open-source model and I can tell you 
that consumer Linux PCs will be in stores for the year 2000, 2001 at the 
latest. It has all the signs of an upcoming fad, lacking only one thing more 
and the closed-source software community knows what that is and is working fast 
even as we speak. Wait!  Closed source? If closed-source developers capture the 
user base then who will have control of Linux? I submit to you that there is a 
golden opportunity here to show the world how fast the open-source model can 
get things done. It is all up to you open-source programmers. I mean at the 
moment that I am writing this, old WinTel closed-source developers like Corel, 
Novell, and even (ack!) Microsoft are said to be developing application code 
for the Linux platform! Well, the only thing they have that you don't is 
experience building end user products for the traditional Mac/WinTel consumer. 
Many hardware venders are preparing to build and market PCs with Linux as the 
OS, and those hardware vendors will prefer to package software that is 
open-source because it actually serves their needs better, but only if good,
popular, open-source desktop application software is available.

For the past 18 years I have been learning about computers, programming 
computers, designing and installing computer software and networks, and 
teaching others about computers. I have worked with some Ultrix, Harris, and 
VMS systems, however most of my work has been with small business on WinTel 
machines. I have done a little system programming, and worked on canned 
vertical market application products, all of it closed-source. But most of my 
programming and analysis career has been working closely with the end user on 
in house application development, building their NT and Novell clients and 
servers, and adapting their manual procedures to the information age. I have 
worked very closely with the average desktop computer user for virtually my 
entire career, building their apps, designing their networks, solving their 
problems, and teaching them how to use their machines. Much of the time I was 
the only computer literate person in a building full of users with only 
software that I wrote as their computer interface. I have learned what they 
like, what they do not like, what they buy and what they do not buy. What they 
forget, and what they remember.

Back when programming was most of what I did, my mother asked me why someone so 
skilled with people as I am would make a career out of programming computers. I
told her that the programs I write are not for computers, but for people. This 
paper is an attempt to share with you what I do, what I have learned as a 
programmer, software consultant, and overall industry watcher in the WinTel 
marketplace. Not what I have learned about the computers mind you, but what 
goes on in the heads of most PC and Macintosh computer users. In short, it is a 
paper on how to write programs for people. If you consider yourself a computer 
novice, then this paper is not for you, not because you won't understand it, 
but because you already know what it says. 

Recently, at a local Linux users group meeting, I had the opportunity to hear 
Eric Raymond speak. Not only did I learn for the first time how and why the 
open-source model works, but I also understood why no closed-source developers 
can compete with open-source solutions (accept maybe in the vertical market) if 
they are available in a competitive time frame.

In his presentation, Eric spoke about how to explain the open-source model to 
big name executives, get inside their head and speak their language. I like the 
analogy I read by Dale Carnegie in which he explains that to catch a fish one 
should not use strawberries as bait. Fish do not eat strawberries but worms. So 
to catch a fish we use a worm as bait. Well, to make Linux common in the home 
and desktop market place and keep Microsoft off of it, Linux must "catch" the 
attention of the average desktop user, and to do that you must present them 
with the right bait. Linux must become what Eric calls a "category killer" on 
the average desktop. We must completely replace everything that Windows does, 
we must go for the throat, and we must do it quickly. I will start this paper 
by referring to some points out of Eric's writings that I will use later on. 
Then, to adapt those same principles to the WinTel market I will need to 
redefine a few of the terms Eric uses to describe the open-source model. After
that I will present you with a lengthy "man page" on the average desktop user's 
needs based on my experiences with them. I will share my theories as to what 
needs to be done by you and what I think Microsoft and other closed-source 
developers are already doing, and why you, the open-source developer, must act 
quickly. I will conclude with my thoughts on why I think Microsoft will win a 
battle between closed-source solutions, and how you, the open-source Unix 
community, is very close to snatching defeat from the very jaws of victory.

Chapter 1: Eric Raymond's Writings.

Chapter 2: Definitions.

Chapter 3: The Big Myths.

Chapter 4: What to do about it.

Chapter 5: How Microsoft does it.

Conclusion

 

 

Chapter 1: Eric Raymond's writings

In Eric's "The Cathedral and the Bazaar", he lays out some fundamental issues 
in the open-source software development model which he found contributed to the
success of the "fetchmail" project. There were a few points that struck a cord 
with me because I have seen other examples of success in the WinTel 
closed-source arena using variations of some of those important issues. Here 
are a few:

Release early release often.

Listen to your users.

Praise your users for work that they do.

Let your users find the bugs.

The programs interface should be well structured to its intended purpose.

If the product becomes useful enough, it could become a "category killer".

To avoid redundancy, and because I am lazy, I will not explain what these 
principles are or why they are important to the open-source model. If you need 
that, go back and read Eric's writings. What I will do is reapply them to some 
areas that I think are crucial to understanding why certain closed-source 
products in the WinTel and Macintosh environments have enjoyed success while 
others have failed. I will also explain how to redirect the open-source 
energies, using these concepts, to defeating the powerful closed-source 
developers who even now are gearing up to capture control of the Linux desktop.

 


Chapter 2: Definitions 

Eric has clearly laid out and defined how to mimic the Linux open-source 
development cycle for system software projects like Fetch Mail. The principles 
he describes are broad in scope the way he explains them, and seen from the 
necessary perspective can be applied to any software project. I intend to 
specialize them here just a bit by adjusting some of the definitions to the 
purposes of this paper...most importantly, the term "user".

The term "User" as applied in "The Cathedral and the Bazaar" refers to the 
users of Fetch Mail which seems to refer mostly to fellow programmers, or at 
least system admins. To design and build software for use by the average 
desktop user the term "user" must be altered to refer to the average consumer 
of WinTel and Macintosh products. In building this average you should of course 
include any user of the WinTel or Mac computer of any level of skill, but it 
also wouldn't hurt to include users of fax machines, VCR's, stereos, palmtop 
computers and the various kiosks as well. This is because these users are 
beginning to view all of those devices as being pretty much in the same 
category. It is important to mention that over half of these users would not be 
considered computer "literate" even by WinTel standards. By most of your 
standards only WinTel admins and programmers like myself would be considered at 
least computer knowledgeable, and we are well under 10% of the WinTel user 
base.

The code one develops for these users of course moves up one layer, from system 
applications and utilities (fetchmail), to desktop applications (mail clients,
accounting software, spreadsheets, word processors, general and specific 
purpose database clients, etc.)

Priorities get shifted also. Good code is still needed, but size and speed must 
be sacrificed (sometimes brutally) at the alter of interface convenience. So 
the definition of the word "code quality" shifts from size and speed of 
execution to user "ramping up time" and speed of user.

Speaking of interfaces...for our purposes here...the definition of the term 
"interface" as used by Eric in his writings needs to be expanded beyond just 
program to program connections, but also must by necessity include the user 
interface. This interface must be simplified and tuned to the special abilities 
and needs of the ultimate of programming achievements...the human brain.

But wait! There are those in the programming community which have not yet "Read 
the Freaking Manual" on the human to computer interface. Fear not! Here it is.

 


Chapter 3: The big myths.

There are many myths that technical people often have about the desktop 
computer marketplace and those who run around in it. For the most part these 
myths reflect a very noble idealism on the part of the computer experts and 
their view of what computing "nirvana" would be. Now my wording on these things 
is going to seem a little cruel (I call it anecdotal humor...my wife calls it 
sarcasm), but understand that I am a tech first and agree with you on how 
things should be. I am only going to try to play devils advocate for a minute 
to try to show you how the users think. Here are a couple of the most common 
myths that we must get rid of before we proceed.

Myth #1 We must evangelize the "All information should be free" concept.

I now largely agree with you on information needing to be free...but I need to 
reflect on what the average desktop user thinks when they hear the phrases 
"free information" and "free code". I do this because you must know how to 
present it to them in a way that attracts instead of repels them. 

The truth is that many people in the real world give things away for free for 
no other reason than because no one would buy it, or to persuade someone to buy 
something else. Traditional information sources charge for content, and treat 
their works as intellectual property. Does that make the publisher greedy? 
Perhaps it does, or perhaps the printing and binding equipment that they use to 
make books doesn't grow on trees. Neither does the fuel and family needs of the 
truck driver who drives the
books to the bookstore. 

This is why the common computer user does not understand free information quite 
the way that you and I do, because our application of it is not what they are
accustomed to. Now I published this paper the way I did for my own reasons. 
Mostly because it is the best way to reach you, the target audience, but also 
because I now believe in the open-source (i.e. Free information) model and this 
paper is kind of my own little experiment to see for myself how to best apply 
it. However the end user does not have a vision about this.

Some parts of the concept are not completely lost on the common folk though. We 
have a somewhat more limited model we use called "freeware" or "public domain"
that have been around for a while. Now while these are not accurate examples of 
open-source, they are closer than most in the WinTel marketplace ever get to 
giving things away. We also have software for WinTel and for the Mac that we 
call "shareware" (usually closed-source) that has a free version of the 
software with some of the functionality removed. When you pay for the software, 
a built-in patch is applied that activates the disabled code. Many PC users 
like it when you give something to them without charge, so they understand and 
agree with your generosity; they call it a "freebee". But their expectations of 
it are not very high. You will even find some that will still try to give you 
money...feeling guilty about benefiting from something that they haven't paid 
for. Others distrust free things as being tainted somehow, without value, or 
come with some kind of "catch". The users have to be shown by demonstration 
that they can get better software service from open-source solutions,
because up to now they have been indoctrinated otherwise. So they must be 
allowed to be exposed to good open-source products in order to catch our vision 
of it. You have already seen how quickly the users accept an apparently free 
product like IE that appears to them to be nearly equal in quality to a charge 
product.

Myth #2 Computer users should read the manual. 

Unix techs are famous for this one. My dad (who incidentally hates Unix) always 
used to say, "if at first you don't succeed, try reading the instructions". 
That it good advise, and makes perfect sense. Nonetheless, you wouldn't need to 
read the manual on a common hammer and many feel like something as common as 
computers should be likewise. 

Another reason is based on the "new toy" attitude that users have regarding 
neat things like computers. When you were a kid, and you got up on Christmas 
morning and ran into the living room to see what cool STUFF you got, I'll bet 
that the instruction manual and safety warning were not the first things you 
grabbed, now were they. Be honest! Of course not, you grabbed the new toy and 
did everything to it that you thought you should be able to do (and if you were 
like me you took it apart to see how it worked). When you could not get it to 
do certain things your parents (who themselves may or may-not have read the 
instructions) helped you. In fact, do you even remember if the toys you opened 
had written instructions of some kind with them? They did you know. We should 
remember that the next time we laugh at a computer user who threw the manual 
(and the driver disks) away with the packaging. Just cheerfully tell them 
"Merry Christmas" as you charge them for your time while you hit the 
manufacture's web site to download whatever it was they threw away. The 
programmer must understand that a new computer product is a cool toy/thing in 
the eyes of the more productive category of user, and that an adult with a new 
computer component becomes a child at Christmas time. Furthermore, the computer 
manuals (especially if you or I wrote them) are just not interesting or 
understandable to the average adult, who is more accustomed to mysteries and 
romance novels (if they read much at all). I mean face it, when you write docs, 
do you write them for what I call the "poodle groomers" of society, or your 
fellow computer experts? Don't answer that, I've read some of your docs, and 
most of what I have read was written for us geeks. By the way, the less 
productive category of user is quite a large group of people, and is
intimidated and afraid of the computer and the docs together, believing that 
the computer is actually superior to them, both in design and intellect. My 
father swears that computer manuals are written in Greek! These people 
absolutely must be put at ease immediately with the product through an 
overwhelmingly helpful and friendly first experience or they will never touch 
it again. Others hate computers because they resent the fact that they can't 
figure them out on their own. I have a sister that hates computers precisely 
for this reason, she used to call them FREDs for "F*****g Retarded Electronic 
Device". Lastly, both the WinTel and Mac users have very long memories, so 
after their first impression with a product or feature, it is hard to change 
most of their minds. They will be unlikely to easily give you a second chance
saying, "I've been there". An example of this was the first release of the Mac 
Power PC which was heavily marketed to run "all of your favorite Windows 
software". The truth is that the release version of Soft Windows for the Mac 
only ran older (obsolete) Windows Software that functioned on 80286 machines 
(no 386 enhanced mode). WinTel users never forgot it, and even though later 
versions of Soft Windows ran enhanced mode software, the users ignored it and 
cost Apple millions in lost sales of Power PC computers.

Myth #3 Users are stupid. 

One of my favorite Dilbert comics was while Dogbert was running for President. 
He said to Dilbert, "From now on I am not going to try to reason with the 
idiots that I encounter, I will just shake my paw at them and say `Bah'". 
"Dogbert" Dilbert scolds, "just because people disagree with you doesn't make 
them idiots". "Bah" said Dogbert...shaking his paw.

Users and (gasp) even marketers are not idiots. They are very often every bit 
as skilled at what they do as you and I are. This is one of the myths that 
techs like us frequently seem to have about the user base.

Do you really believe that those all around you in the office area of your 
workplace are stupid and that you (and your fellow hackers) are the only really 
smart ones? You and I see self-righteousness in others as arrogance most of the 
time. Then we turn right around and interpret a disagreement with a user as 
being just stupidity on their part. Think about it, what's the difference? Most 
of the time it is just a matter of perspective based on a different expectation 
of the computing experience. If the user saw computers exactly the way we do, 
it would be because they know the same things about them that we know, then 
what would they need us for?

Dale Carnegie said in "How to Win Friends and Influence People", that every 
person that you bump into on the street has something that they do better at 
than you. I had a Macintosh user say to me once, "(We) do not believe that it 
should be necessary for us to be experts at whatever we do for a living AND be 
experts with computers just to make use of them in what we do". He was trying 
to complain to me about what he saw as a fundamental difference between Apple 
users and WinTel users. But he actually hit the best fundamental description of 
the average desktop computer user in general; it is just that Mac users are 
probably the more dramatic example of this. What he describes is a very 
reasonable expectation, should you have to know how to build a car just so you 
can drive one? Should you know how to fly an airplane beforebuying a ticket to 
travel in one? Of course not.

Myth #4 Marketing is slime.

Actually, this is not so much a myth as it is a misdirection of purposes. I 
have never met a sales person who was hired for their technical knowledge. Some 
have it, but it doesn't serve their needs or make their money. Sales and 
marketing folks are judged and paid directly from how much $$$ worth of 
merchandise they move out of the door. They have few preferences at all for 
selling one thing or another on that thing's merits alone. For the most part, 
the only thing that excites them about a product is the likelihood that someone 
will give them money to take that product away. This is not so unusual really 
since teachers are hired more for their teaching skill than for what they know. 
In fact I had some difficulty making it in the teaching world because I am a 
tech first.

I guess it is true though that marketing IS slime, and everybody admits it. But 
like lawyers (who are also slime) and teachers, they serve a necessary purpose 
and specialize within that purpose. Here's a thought, how would you like to 
have some of that slime bubbling on your side for once? You will have to do a 
little fantasy role-playing and think like them for a moment (ick!). There is a 
lot of complicated personal confidence and psychology stuff involved, but I 
will not sicken you with the details of that. The bottom line is that they are 
sales folks not just because they love to sell things, it is also a very 
potentially lucrative profession and most sales and marketing folks spend much 
of their time roaming from product to product looking for the money. Sales and 
marketing turn persuasive skill into hard cash in the same way you and I turn 
programming skill into good solutions. I will also tell you that I have tried 
sales and it is no fun at all if it doesn't work. It is true that a really good
sales person should be able to sell anything, but it is also true that they 
follow the path of least resistance. If they don't think they can sell it, then 
they will spend their time and resources selling something else. They want to 
make the most money in the least amount of actual time possible, so they will 
spend their time working what will sell.

Now I would not try to persuade you to sell out your principles of quality code 
for marketing advantage, what would be the gain? It would be pointless. But if 
Linux PCs are going to take the place of Microsoft PCs and Mac PCs on the 
shelves, then they have to out sell them. They have to be made to look good 
next to the Barbie dolls, VCRs and lawn mowers where WinTel machines are 
currently being sold. 

Even if the internals of Linux are so much better than Windows, that interior 
quality has to be packaged in such a way so as to fool all those slimy sales 
folks into thinking that it is just another stupid toaster. Do that, and it 
becomes the NEW fad, the toy that I spoke of earlier, the "pet rock" of the 
millennium. You see, WinTel sales have stagnating a bit, so if you provide a 
new product that ordinary people like and the slime can sell, then the sales 
and marketing folks will suddenly love Linux (but for their own slimy reasons). 
They will salivate. They will get all exited about the open-source model and 
start to view your favorite OS as the next new popular (i.e. money making) 
computer product/market and vehicle to their own success. They will pay to advertise it in some stupid half-time commercial during the Superbowl. They 
will put it on their shelves next to those lame home gaming systems. They will 
hang their stupid red ribbons and balloons all over it, and blow stupid little 
whistles at every 1000 units sold. They will use their pathetic knowledge of 
the cutsier parts of the new Linux GUI you are going to write and froth up the 
customer into a state of artificial uforia of how that one box contains the 
answer to all of their problems. The consumer will then dig deep, and go home 
and put a Linux box on their desk instead of aMac.

Myth #5 Size and speed.

The desktop user doesn't care about size or speed. Well, they do care, but they 
will never get to see how fast the program is if they never figure out how to 
start it up and make it do the things that they want to do the way they want to 
do them. They do not care about fast features that they don't use, and here is 
the most important part, they do not care about speed that they do not notice. 
In short, they do not care about speed for the sake of speed itself.

First, they care about interface conveniences on the first layer. Those are the 
mechanical issues that they do with great frequency, like open files, type on 
the keyboard, click with the mouse, push the buttons, use the scroll 
bars...etc.

Second they care about similar "handles" to activate similar features in 
different types of software, so that things are consistent and they don't have 
to relearn different mechanisms to do the same thing the same way. Example: The 
key press combination for a non-destructive copy to the "clipboard" in 
virtually all software packages on both Windows and the Mac is Ctrl-C. You can 
call it a de-facto standard.

Third they care about the availability of features they like. This can change 
somewhat rapidly from time to time as new inventions open new possibilities.

Forth, they care about interface convenience on the second layer. These are the 
things that are implemented through buttons and drop down menus and the like,
features that they use only occasionally but do not want to have to relearn 
each time. For this reason, complicated options must somehow be featured in the 
very most informative and intuitive way possible. The most common combination 
of options must be available in the most brainless way you can implement, while 
still being "open" enough to conveniently alter those options. For example, the 
find command in the bash shell would most commonly used by thusly by the 
average desktop user; "find / -name `file*' -print". In the slightly more 
intuitive DOS, the same command would be; "dir /file*.* /s". The "dir" command 
in DOS is the equivilent of "ls in Unix and is case insensitive automatically, 
the "/s" means to scan the subdirectories of the given path. The DOS version 
also has many other more advanced options, but of course not as many as the 
bash "find". The users still dislike even this simple DOS command. In the GUI, 
they invoke the "find" command from a drop down menu somewhere and fill out a 
simple dialog box. The more advanced options are hidden from the default screen 
by an option tab like a rolodex tab. The dialog window itself is made just 
large enough to contain the most common and popular choices, while covering as 
little of the background screen objects as possible.

If the user makes a choice they do not like in a step-by-step process (like an 
install, xconifgurator, or Kernal configuration), they should be able to re-run 
the easy interface to the feature and alter only that option that they want 
changed. The default options of course should then be their most recent choices 
for that object or session, not the original defaults of a new object or 
session. Otherwise they will be afraid of changing one option for fear of 
messing up the stuff that works the way they like it.

Fifth, they care about the availability of cool features that they have never 
seen before, have wished that they had, and that seems to solve new problems. 
Microsoft used to serve this user need better than they have lately.

Somewhere in there they care about having fun. So the product usually needs to 
be entertaining to some degree.

Then, when all of the above are pretty much equal...they begin to compare 
products based on speed and code size.

You doubt? How many politicians do you know actually get elected for their 
stand on the issues only? Even those politicians who care about the issues 
can't get elected until they hold their noses and do the slimy marketing things 
necessary to get elected if they want to ever have the power to effect those 
issues.

Myth #6 Bugs.

To the user, anything they expect to find and don't is a missing feature, and 
every missing feature is a bug. Therefore from the perspective of the average 
WinTel or Mac user Linux currently is a very backward environment that reminds 
them of (don't hit me) DOS! They see it as being full of bugs and lacking in 
real world usefulness. They say this because most of the usefulness is hidden 
beneath the bottom two layers of the interface where the typical desktop user 
never sees them! They are also very picky and narrow minded about what 
constitutes a useful GUI. This is often based on familiarity alone.

So what needs to be done?

We need to do for the user with Linux what Windows is currently doing for them. 
Not convinced? Read on.

 


Chapter 4: What to do about it.

Again, I am not saying that it is ok to get sloppy with your code. What I am 
saying is that the biggest difference between Linux and Windows remains that 
Windows and the Mac have the more intuitive, interactive UI, and cross product 
familiarity that the users want, and Linux still doesn't. At this writing, 
Linux and BSD seem to have solved all of the most important problems to getting 
to the average user's desktop accept that which is the most important to the 
user. Linux needs a very strong, very obvious, open-source, graphical 
front-end. I am not talking about changing or replacing the X server. I am 
talking about an open X client interface and suite of open-source application 
software which compare closely too, or beat Windows and the Mac at the issues 
the average desktop user cares about the most.

After that, the benefits of the open-source model, the speed of the code, and 
the strength Unix has at the third, forth, and fifth layers will win the game.

At this writing, numerous developers of closed-source WinTel software including 
Microsoft and Corel are said to be working hard to fill this need. Even if you 
in the Linux world have not seen this, those of us in the WinTel world who are 
open minded enough to accept Linux see it clear and obvious. The closed-source 
WinTel community also view you as being too arrogant, too ignorant, and too 
closed minded and caught up in "small and fast" code philosophy and a RTFM 
attitude to fill this need quickly. They see this as an opportunity to exploit 
you and your platform for slimy marketing reasons. They think that they must 
show you what the users need and make some bucks off of YOUR Linux before you 
will see what I am telling you here today. If they are right, then Microsoft 
(or some other closed-source developer who may be worse) will build their own 
loyal user base with Linux. They will then take control of the Linux platform 
in the same way that you feared Microsoft would take control of the Internet 
when they released an HTML client and made it part of Windows. That will keep 
your influence off the desktop for another 3 years just as Linus Torvalds 
predicted.

I know that most of you hate writing UIs. So do I. Think of it as doing the 
dishes, it needs to be done and the quicker you get started the quicker it will 
be over. If you don't do it, then someone you don't like will.

I have spoken of intuitiveness before, this is defined as the presenting of a 
required sequence of user actions that pretty much teaches each step to the 
user as it goes along or does things in a way that the user automatically 
expects. Familiarity is one important issue here...a ball, whatever the size 
and color, is still round and still bounces in almost exactly the same way. 
That shape and bounce must be similar to that of other balls for people to 
recognize it as a ball. But with the complexity of computers, that consistency 
of interface should go even further. When teaching MCSE students about Windows 
NT's Macintosh network gateway product, I have to make sure to warn them about 
a particular user interface problem. While the same files stored on the NT 
machine are equally accessible from both platforms (NT/95 and the Mac) over the 
network, the "look and feel" of those platforms on the desktop are different 
enough to create confusion for some Mac users. Seeing the icons for their files 
on someone's Windows 95 file manger (Explorer) screen, they will not recognize 
them. They will think that there is something wrong with the system, that the 
files have been lost or something because to them those are Mac files and 
should still look like Mac files even on a Windows screen! Seem stupid? Well if 
you looked out the window of your home tomorrow morning and your brown car had 
turned into a green car over night, you might wonder if something were up. Mac 
and PC users both see their computer desktop as such a literal extension of 
their physical universe so as to make this sort of thing quite common, though 
it is usually just a certain category of user that takes it to the extreme 
described above. Personally I see little difference at all between the two 
interfaces (except that the Mac lacks the ever-useful command shell prompt). 
But the fact remains that the regular users don't like to see their toasters 
change shape. The Linux interface (at this writing I am using RedHat 5.2, your
mileage may vary) out of the box does not seem to even have a GUI. There is 
nothing after startup and logon that tells the user that they need to type the 
words "startx" or "init5" to get into the GUI, they have to read it in a book 
somewhere. But in order to make it on the desktop, you have to assume that all 
that the user has access to is the machine, and no docs whatsoever because they 
rarely read the docs anyway. When they do read the doc's it is only to look up 
something specific and then get back to work. That is why there are world wide 
computer training organizations making millions offering application level 
training to other corporations' employed computer users. Did you know that 
"startx" is not even that easy to look up in the documentation? There is no 
"man X". Without someone telling them what they need to do some will wander the 
directory structure, find X, and run it (ok, stop laughing). It would do no 
harm to have a logon welcome screen configured from install that says simply, 
"If you want to enter the Windows-like environment, type startx below".

Once in X, there seems to be no apparent copy/cut/paste ability between 
different applications, which is one of the most popular features of the 
Windows and Mac GUIs. Scroll bars in different programs work differently, 
sometimes requiring experimentation or doc searching to figure them out. 
Context sensitive (directly feature specific) help is weak or non-existent, no 
file browsing with pre-configured associations... the list goes on. Now to you, 
these are not serious problems, but to the unskilled/non-hacker users these 
things are crippling.

Now for the user's perspective of speed. The measure of speed for them is 
similar to yours, how fast can they get done what they want done. Except that 
for them this is more a product of their speed on the interface and a shallow 
learning curve than the raw processing power of the code. In the first 2 or 3 
minutes of interactive time after startup, and right after install, the new 
user must be able to wander each part of the system that stands between them 
and printing a test file from their favorite program. They need to be lead from 
scene to scene like the steps in the plot of a good movie, or the chapters of a 
good book with each phase setting the stage for navigating the next. I say 
interactive time because the user fully understands that the Internet dialer 
and the printer require a specific period of time to perform their functions, 
but they become increasingly frustrated and intimidated as the machine sits and 
waits for them to figure out what to do next. If they have to spend a minute or 
two researching each step, they will wonder if they will remember all those 
steps the next time or if they will they have to work this way everyday. I have 
seen them do it, they eventually throw up their hands saying something about 
"(not having) time for this crap", box up the machine and take it back to the 
store. The goal when building for these people is Immediate Personal 
Productivity. Sales slime just wants to sell the machine and desktop users just 
want to start doing their work. For the user an in-efficient user interface is 
a strike against it on speed because they will say they could get their work 
done faster with the some other system.

It has been said that disappointment is the frustration of unrealized 
expectations. Well here is a small sample of key things that the user of PCs 
and Macs expects out of an OS, and are accustomed to getting in abundance from 
Windows and Mac software.

-An automated step by step install process. The install program should be 
called "install" or "setup". It should also optionally have a completely 
brainless "minimum questions asked" install mode.

-The user should be able to implement most if not all of the crucial 
functionality, with the most common set of options by simply closing their eyes 
and pressing ENTER at every step throughout nearly all of the install process.

-The user must be able to rerun the entire install and keep all pre-selected 
settings, accept for one that they want to change, with the choices they 
selected in the most recent install being the defaults. Sometimes the user does 
want to go back to a clean, new default install, so they do still need that as 
an option as well, but as the exception rather than the rule.

-All prompts for anything anywhere should list and explain each of the more 
popular choices, in some instantly and brainlessly available form.

-All documentation must be available online at 2 or 3 mouse clicks, and should 
be context sensitive whenever possible (use a special "help key" method for 
each object for which context sensitive help seems reasonable, use parameter 
passing to a subroutine to customize the lookup to the docs for that object). 
The user should be able in two or three clicks to find exactly what they need 
to know before reading no more than 300 words (and preferably a lot less) or so 
to solve the most common problems. The time span between the decision to go to 
the docs and finding the solution they seek should not exceed that of a typical 
television commercial break. This is no coincidence.

-It is best if professional technical writers (i.e. less technical skill, more 
writing skill) write the docs but I do not know how to do this under the 
open-source model.

-Scroll bars and other common on screen productivity devices should look and 
act in nearly the same way on all apps, or explain their different 
functionality clearly in docs that the user does not have to go find.

-Take every opportunity to tell users what to do with things they find on the 
screen. At the bare minimum there should be onscreen links to good docs, 
sentence long descriptioms should appear in the status bar when command objects 
are selected but before their default methods are activated and object labels 
should appear in screen pop-ups resembling what HTML does with ALT tags.

-While having a "welded on GUI" like the one that Windows uses is clearly not 
necessary; the default X client should be powerful in terms of user features 
and consistent in most details. The radical differences between the "old" 
Windows and the Windows 95 desktops created significant stress on the market 
and nearly killed Windows 95. It was all the money that Microsoft spent on hype 
that made the difference. Even today there are users who hate it still, despite 
the fact that it is superior to and more productive than the older Windows 
interface.

If you in the open-source community do less than this with Linux some 
closed-source developer like Microsoft will do it for you and will endanger 
your control over Linux.

Now, is this hard to do? For you people, certainly not. But in the next section 
I will tell you why Microsoft has trounced its competitors every time it's 
products have had similar exposure to the user. What you may have heard on this 
is only partly true, and is not complete. The old "well they own the 
environment so they have the control" argument is only half-right...the rest is 
even more frightening, and uses a couple of the more successful components of 
the open-source model in some interesting ways. No you say? Read on.

 


Chapter 5: How Microsoft does it.

You are about to learn what many closed-source WinTel software developers never 
learned and died trying to fight. They were simply to closed-minded to succeed.

Ever wonder why Microsoft application software is so fat and slow? Some of you 
have alleged that it is a lack of attention to such things in their programming 
priorities, but what you may not know is that the mechanism of those priorities 
is Microsoft's favored GUI development environment, Visual Basic.

Users like features. Following is an example of how Microsoft implements 
"category killer" features. It is not an isolated example:

A long time ago I was writing application software for DOS and I did some 
debating with some other programmers about what to do with that right mouse 
button (looking at some application software under Linux I can see that you 
have struggled with this question as well). With the PC, the race has been to 
continue to provide new features, but at the same time not complicate the 
interface too much because the average PC user is typically very unskilled and 
results centric. Well, somebody came up with programming the right-mouse-click 
event to provide a small menu in the place clicked containing things to do to 
directly to the object clicked. Not only that, but an option to edit the object 
properties (that is what Visual Basic calls "instance variables") directly 
could be presented as one of the menu choices. Then they would built a GUI 
screen that organized (somewhat) the object properties to be changed. The menu 
choices that were implemented were limited to the very most common second level 
operations. It saved the user from having to wander around the regular drop 
down menus to try to remember how to invoke those features. Key among those 
choices were cut/copy/paste. This is because the average user does not remember 
that the common quick key for those things are Ctrl-X, Ctrl-C, and Ctrl-V 
respectively and using the regular drop down menus for this frankly just takes 
too long and limit's the feature's usefulness. Anyway the "right click on 
object for quick menu" very shortly became a popular feature among the users. 
Microsoft noticed this and immediately incorporated it into the next release of 
all of their office products (truncating the beta process to do it), beating 
most everyone else (who also put it in there new releases) to the punch. This 
is because Microsoft office products are written largely in Visual Basic and 
even I (a relative novice at Visual Basic programming) can write a quick menu 
routine for the right click mouse event in about 17 minutes. What they probably 
really did was to add a quick menu building tool to VB first, then utilize that 
tool in building quick-menu methods onto all of the screen objects on each 
office app in just a matter of days. The quick menu choices consisted mostly of 
features for which there were already menu driven routines, the programmer just 
copy/pasted that menu entry object, with it's attached method from the dropdown 
menu code to the new quick-menu object.

The next step was to market the quick-menu "feature" as their very own great 
idea. I don't think that it had been called a "quick-menu" previous to MS's
implementation of it in their products, that was the name that Microsoft gave 
it. The code wasn't ready for release by good programming standards, but the 
users did not care about the bugs because those bugs were not all that 
intolerable, especially when balanced against all the cool new features and the 
newly simplified user interface. Besides, the users who call Microsoft tech 
support with bugs get their call and help for free and often get private praise 
from Microsoft. Ordinary people often don't need public praise, just the 
private praise from someone as big and well known as Microsoft is adequate, and 
often they get the first copy of the patch as well. 

As for the speed, who cares? Heavily interactive user application features like 
the one here described spend most of their time waiting for the user anyway. 
Heavily interactive features under Windows that the user needs to see updated 
right away like mouse activity and quick menus are dramatically optimized over 
the other things in the multi-tasking interface. The user sees what needs to be 
done, reaches for the mouse, and by the time they are finished with that 
agonizingly slow thought reaction and motor process, most of the other on 
screen things have usually had time to happen. Strictly background things that 
have no on screen presence can take all the time in the world because the user 
is given things to do, so they don't end up waiting for the background 
processes to finish. Sometimes things like disk activity are masked behind a 
"user agent" animation on the screen which, while it and the sounds it makes 
eat up time slices, it also has the effect of distracting the user so that the 
operation does not seem to take so long. For the interactive activities on the 
desktop it is not the actual speed but the perceived speed that effects the 
user's actual opinion of the speed of the product.

So what happens to the other closed-source competitors writing their code 
strictly in C++ for super fast, super small code? What happens to the 
competitor who first invented the right-click mouse event menu thing but did 
not realize what they had done or didn't market the feature very well? Or 
perhaps they didn't apply it as accurately to the user's needs? Or first 
released it in a less visible product? What happens to competitors that prefer 
to wait so they can find and smooth out a few more bugs before they release? 
What happens to products like early versions WordPerfect where the source code 
was not as well structured as it needed to be, slowing the development process 
and making upgrades more expensive to develop? Microsoft also strategically 
times their product releases and announcements around released advances in 
hardware speed and announcements and releases by their competitors. They are 
very good at this one. It is true that MS uses some marketing behaviors that 
leverage their monopoly on the desktop and make it hard on competitors, but I 
have noticed that the users actually do like to buy a new product feature from
whoever releases it first. Those other "unfair" things that MS does seem mostly 
used to break down marketing barriers for themselves and to maximize the damage
already done to their competitors by product development and release strategy. 
You think you hate Microsoft? Stand in line.

In the above (closed-source) example, did you see some of the things that Eric 
say's makes open-source so effective? Microsoft listens to users, though not 
like they used to. Microsoft releases early, and often (if you count bug 
patches), though not like the open-source model. They let the users do much of 
the bug discovery, and the users sometimes are VB programmers themselves and 
willing to offer suggestions and help so that Microsoft might "notice" them. MS 
often praises others for helping them though usually not publicly. They make 
use of a rapid development, high level programming environment (VB), though I 
think that you have some better ones and the open-source approach itself should 
speed development of projects. MS makes an effort to make their products rich 
in features, though they filter those things through the marketing slime and 
often leave out features that the users don't know that they need and are not 
aware are possible.

 


Conclusion:

Now comes the scary part. Before the IBM-PC, Microsoft made their money 
programming functionality into new environments/hardware. That was what they 
did with CPM and the Intel 8086 based IBM-PC but they had done it many times 
before with other small computers that others were inventing at that time. 
Usually the first step that they did was to develop an assembler for the 
platform. Then Gates would write an implementation of interpreted BASIC for the 
platform using that assembler. Then they built the "user" software for that 
hardware platform using Basic. Microsoft Basic was the first higher level 
programming language available for the IBM-PC, and some version their BASIC 
interpreter have always been packaged with DOS along with an assembler. I even 
remember a time when the IBM-PC would boot into a ROM based BASIC if there was 
no bootable OS on any of the drives. I am told that a version of IE 4 is 
available for Solaris, if that is true, then they probably have a version of
Visual Basic that they used for developing the UI for the IE 4.0 port to 
Solaris. They love using the same source code on multiple platforms and tying 
them together with a common compiler that has been customized on the backend 
for the different platform. NT uses the same source code for Intel and all of 
the RISC platforms it runs on. NT also uses the same source code for NT 
Workstation and NT Server. If the rumors are true that MS is writing office 
products for Linux (they deny it but it would certainly fit their pattern), 
then they must have or are working on a VB for Linux. Once the VB is completed 
for a platform, pretty much all that is left to do is to just recompile already 
available proprietary source code into a product port and release it at whatever time it would do the most damage to it's competitors. I would not be
a bit surprised of they wait for the success of Linux to get a little further 
and then somehow release a version of Windows 2000 for it as an X client or 
window manager, complete with IE 5 and the Office 2000 suite! Then they will be 
there, and will take control of your platform.

I hope that you believe me, and that some of you act now to find the best 
currently available open-source X client and GUI interface products and improve 
them in whatever way needs to be done. The front-end of Linux needs to stay 
dominated by open-source projects and have the same power, flexibility and 
capabilities that you folks have spent so much effort putting into the 
back-end.

 

 

Please forward this anywhere you think it would be helpful.


This document may be freely distributed in whole or in part so long 
as I am acknowledged in print on as its author on any distributed copy, printed 
or otherwise. As a favor though, I would request that you also tell me if you 
use it just so I can know what effect it is having.

            William A. Housley billh@lgcy.com