I seriously doubt any of my clients will ever be “Linux newbies” for the simple reason too many Linux people assume “newbie” means someone who will become one of the techies. That is, the term seems to assume this person will eventually have to see the commandline, and they better get used to it already. This arises from what I believe is a mindset which excludes other possibilities, even if subconsciously. So while I may get them using Linux, calling them “newbies” might be inappropriate.
Once in awhile I run across a Linux techie who actually seems aware of this. They realize there are a great many potential Linux users out there who will never be Linux techies. It will simply be the OS running on their computer, and that’s that. Today, honorable mention goes to Ed Ropple, AKA FishWithAHammer on Slashdot. Commenting on a Slashdot post noting Canonical is pretty much financially self-sustaining now, Ropple points out what is missing from Linux and Open Source development:
This post is a prime example of why you, and people like you, should not be involved in building user interfaces. That’s not an insult, don’t get me wrong. Techie types are valuable in areas where their expertise is useful. Trying to reason out how people actually use computers — that’s not an area of expertise for most techies. I wouldn’t have most UI designers writing code, either.
The GUI is less flexible, yes. That’s a drawback. But for the majority of people it is far more valuable because it does not require prior knowledge to operate. A button that says “Do Foo” with checkboxes “Initialize ‘Bar’ Subsystem” and “Provide verbose output” is easily grasped by an individual user (especially because it’s very easy to add tooltips to each of these in order to provide more information”. A CLI command of “foo -Bv” is much less easily grasped by an end user who is not already comfortable with the command line.
“Microsoft Word has committed an error and must be closed” is about the most useful information for basic users. What information could you give them that’s actually useful and valuable? The DLL that failed? Why will they care? What error did Microsoft Word commit? Again, why would they care? That information is available for me, as a technical user, if I want it — but I have to click a button to access it and it’s out of the way of those end users.
Users don’t want to know how their computers work. They don’t care about that. Users don’t want to have to learn how the CLI works. They don’t care about that. Users want a quick, relatively efficient system for doing their stuff, rather than doing the computer’s stuff. The CLI is not that system because the benefits of the CLI require more time investment and effort than users want to devote to their computer’s stuff when they could be working on their own stuff. A good desktop environment tells the user nothing that they don’t need to know and doesn’t ask for the user to waste time on the computer’s stuff, as far as that is possible.
Call it “dumbing down” if you want, but a great many users don’t need all the extra information. When told this, techies react as if there is something immoral about hiding details, as if the lack of interest in knowing just what really happened is somehow sacrilegious. It’s not.
Granted, it’s pretty tough to help someone who doesn’t have more details about what happened, but there are ways to generate reports. I don’t mean simply the bug reporting tools which scoop up the crash data and send it off to the coders. All they will do is consider ways to improve future versions. The likelihood that crash report will result in a fix for the user on their current system is about zero. For this reason I seldom attempt to make bug reports. The process of bug reporting compares favorably to kissing the developer’s butt to gain permission to do it, knowing it will never, ever make your life one bit better — unless you are willing to fight the damnably hard process of upgrading everything attached to the next release of whatever we are discussing.
In other words, this thing is so developer centric, they have precious little accountability to anyone outside their little team. I’ve had plenty of really decent human beings discuss with me what I might do to improve my experience with their product — Netsurfer and Elinks come to mind. Friendly response, useful suggestions, honestly answering my questions and making sure I understand. But you will notice those two projects are pretty much “free standing” — they can be built on a wide range of systems with varying releases of the dependencies. Less than a year ago, I built Elinks on RedHat 7.3, and it worked fine.
Why is it the developers working within really big projects — GNOME, KDE — and stuff which relies entirely on either one, can’t be bothered with such courtesy? What is it about those big projects which requires users to crawl on their faces just so they can support the project, a project which will do nothing for them in return? Do the bigger projects simply draw a different kind of developer? Are the smaller ones led by people who can’t tolerate that atmosphere?
I wish I knew. I also wish the bigger projects included more people who thought like Ed Ropple.
I sort-of see where that slashdot commenter is coming from, but I really see no reason that a computer newbie can’t use a command line. Sure, it takes prior knowledge, but most Linux users underestimate the amount of knowledge regular people have built up about Windows. Using a GUI doesn’t automatically mean “no knowledge required.”
I’ve had non-techie English teachers explain complex and unintuitive methods to make Microsoft Word make papers follow some standard, not to mention all the proprietary software out there for Windows with less-than-intuitive interfaces that regular people use for their jobs every day. People are smart and willing enough to learn how to use a computer, and doing basic things with a command line (say, using a package manager) is not really much more difficult than using a gui.
Hell, much of Linux is already more “user friendly” than the equivalent features in Windows (the installer in Ubuntu, for example)… the problem isn’t being “user friendly,” but the fact that so many users have already learned how Windows works and are not all that excited about learning something new if what they already have works just fine.
All that said, I think it’s perfectly reasonable to try to make the interface in Linux reminiscent of that in Windows and Mac OS, so new users won’t be forced to use the command line. I’ve heard people say that having both KDE and Gnome competing hurts this effort, and there’s probably some truth to that. Personally, I think Gnome’s philosophy of simplicity up front and complexity hidden away in back is perfect for new users.
As far as smaller projects go, the only time I’ve seen a genuine non-techie using Linux on his own PC was a guy running Xandros Linux on an EEE PC (using icewm). He probably didn’t even realize it was different from Windows, or at least in any meaningful way. The interface was intuitive, it had programs to do what he wanted, and he never bothered with trying to mess with it or customize it.