SEUL: So you want to be on the desktop

["Bill" <billh@lgcy.com>]

The following is a forward of a paper I wrote to help persuade skilled
programmers to band together and help build a powerful desktop GUI for
Linux.  Please forward it anywhere you think it would be helpful.

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 in the open-source Unix community are very close to
snatching defeat from the very jaws of victory.

See attached HTML document (it is text only).  Or you can go to
http:www.lgcy.com/users/b/billspg/writings/linux2desktop.htm

Title: So you want to be on the desktop

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.

 

Top Contents

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.

 

Top Contents

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 before buying 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 a Mac.

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.

 

Top Contents

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.

 

Top Contents 

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.

 

Top Contents 

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