Slashdot Mirror
Salon on why "Linux Needs Help"
Matt Welsh sent us
a link to a Salon story on
Why
Linux Needs Help. It features a lot of truth, and
poses the simple question, can free software geeks write
software for dumb users? Has a spiffy penguin graphic and
a lot of good points (most of which aren't new to us,
but they are well written).
Posted by Mike@ABC:
The last couple of posts prompted me to write, mostly because I believe they show a fundamental lack of understanding about end-user types.
Folks, the vast majority of people who own computers today got them in the past four or five years, and primarily to Web surf and do e-mail. The computer is becoming an appliance, a means to an end and not the end itself. It's unreasonable to assume that people will take the time to become "good" users. Do the majority of the people on Slashdot take the time to become auto mechanics or nutritionists? Same goes for end-users and computing.
There is nothing to stop Linux from becoming a "hacker" OS AND a consumer OS. Today it's doing really well in server, workstation and "enthusiast" markets. But that doesn't mean it's impossible or undesireable to make it easy for your mom to use. Add a solid, hands-off installer (or get more OEMs to install it), make the GUI even more intuitive, and do up the Help documentation that people are used to. That's easy. The hard part -- creating a solid, fast, lean and mean OS -- is already done!
And wouldn't it be nice to have a cross-platform OS that could be used in everything from handhelds to mega-servers? Imagine if all these devices spoke the same language.....!! That, IMHO, is the true promise of Linux.
This article's right on -- if you want world domination, you're gonna have to do stuff you might not want to do. Nobody said it would be fun all the time.
>I hate to >*pop* your little bubble, but the Mac
>interface was designed by programmers.
Yes, it was. After a couple of years of study be psychologists, interface experts, and such. The final interface, perhaps. But they stood on the shoulders of giants, or experts in this case.
>Almost all of the research done in human/computer
>interfaces for the Mac has contributed little tiny
>modifications; the original interface was written
>by programmers who saw a similar interface at
>PARC; and that interface too was designed by
>programmers.
You're right about the PARC interface being designed by programmers, but have you ever seen that interface? It and the Mac interface have very little in common (the WIMP concept, and that's about it).
The program's controls are at the top of the screen, as far away from the actual application as possible.
Wrong. See, here's the thing: I take it you can read English. How is English read? Top to bottom, left to right. Notice: the menubar (the most-often used set of controls) is at the top left. It's a psychological thing, you see. This is also why the trash can is at the bottom right (the last thing you read on the page, therefore the lowest-priority, therefore a good place to put the control representing the most destructive actions you can do).
Please don't get into other languages here; this is not meant as an insult to those languages which are read in different directions.
Also, windows keep disappearing.
It's called closing the window. Or, when you're switching apps, it's called hiding extraneous palettes that you're not going to need when you're working in one application. And make no mistake: even if a computer can multitask a human can only work in one app at a time. I offer the following challenge to prove my point: start up any two X applications (any other platform will do, but I'm guessing you'll be using X). Make one of those applications active. Now, work in the other application without leaving the first. If the window of the first application loses focus, you are considered to have left it.
I'm never allowed to launch more than one instance of an application, so if the application isn't programmed to allow more than one open window, I'm screwed.
That's the fault of a poorly-programmed application, not the OS. By the way, while we're on the subject, please open up two distinct instances of Netscape (in other words, no just opening a second Netscape window; open another xterm and start Netscape from there without quitting the first one). Bet you can't do it without one instance or the other complaining.
There's only one mouse button-- you have to use the keyboard if you want to emulate more than on button.
Nobody needs more than one. It can come in handy, but it encourages convoluted, confusing, horrible interfaces like XFig's.
And this sucks if you are missing an arm. (This is more than a nitpick-- I've worked in a university environment where I've had to help disabled people like that.)
News flash: lots of things suck if you are missing an arm. Ever tried typing with one arm? I'm doing it right now, actually. It sucks. Keyboards were designed for both arms; its width becomes a hindrance to someone typing with one hand. Yes, there are keyboards designed to be used with one hand; some of them are even pretty nifty. There are also pointing devices designed to be used with no hands.
This addresses just the basic ease-of-use GUI choices-- it doesn't even touch on the more complicated technical issues (such as the lack of pipes, redirection, and CLI).
Pipes: a nice convenience, but nothing which can't be worked around with exceedingly simple scripts and a properly-done application.
Redirection: same thing. It merely requires a properly-done app... OH, THE HORROR! The programmer might have to do some extra work!
CLI: Unnecessary. Let's not even go there; I can do everything with a GUI that you can with a command-line; the reverse isn't true. The best would be natural-language processing (which is more akin to a CLI than a GUI, admittedly) but we're decades away from that at least. As evidence I present Forum2000. Assuming it's not a hoax, it's a massive cluster of Alphas totalling, I believe, 32 terabits of RAM. It's the only thing out there even capable of natural-language processing, it still makes some mistakes, and it can't even do it in realtime. In other words, we're a long way off from that.
Plus, have you ever wondered why it took so long to change anything but the most cosmetic aspects of MacOS? It's because the core OS was poorly designed. Copeland failed because it was hard to add basic pre-emptive multitasking.
That had nothing to do with it; Copland was a total rewrite of the OS, which would in fact have required something not unlike the OSX Blue Box to run current MacOS programs. Copland failed for other reasons.
I might also add that back when MacOS was created, few people, including most current Slashdot readers, had even heard of preeemptive multitasking. The guts of an OS don't matter anyway, if it works correctly (which is why Windows still sucks even though it has partial memory protection and pseudo-preemptive multitasking; it still doesn't work, where MacOS at least does a better job of it than the stuff Redmond puts out).
I think I've risked starting enough flamewars for today (without intending to start any, I might add; if any of this is flamebait is is not intended to be so).
You remind me of a father who kicks his son down whenever the son threatens to eclipse him.
I don't see how improving the GUI-useability of Linux systems precludes you from doing what you have always done, yet you damn ordinary users to a world of Microsoft products anyway.
Consider this, a well thoughtout method of interapplication communication can improve execution and programmer efficiency of even command line apps. It reduces the programmer overhead of having to write code to parse STDIN into a useable format and the execution overhead of doing the parsing.
Good observation, in the article; Programmers like to tackle the 'cool' issues, and tend to ignore the more boring ones, like help systems and documentation...
Some of the posts in this thread already seem to be missing the point. Salon was not talking about the relative ease or difficulty of use and install of Linux, though that is surely an issue. They were targetting it's help system, or lack thereof.
In the normal capitalist market, as studied and practiced in the US, a simple way to get unenjoyed activities done is to compensate; to pay for it. In this case, who will pay for it? I would imagine an enterprising company like Corel, Caldera, or Red Hat, would or should soon step up to the bat, or the three of them together, and tackle a uniform and consistent complete help system. Who would pay for it? Anyone and everyone who wants to use Linux for its price, stability, and performance, but who don't already dabble, tinker, code, or play with it.
Or this is the chance for that small group of hacker/coder friends out there, reading Slashdot, reading this article, reading this post, to get together, write a powerful and useful help system, and then start giving out the documentation for recognition, or selling it to corporations and comapnies for 'official' support and such. Or even to just sell it to RedHat, Caldera, or Corel...
Would this idea violate the sensibilities of the Open Source crowd? I'm saying sell the service of documenting and collecting references and information, while maintaining all the info on their site in an HTML searchable format, but providing a more robust and integrated solution for sale...
AS
-AS
*Pikachu*
As much as the hackers don't want to admit it, documentation is a very important part of any software product. And documentation is part of the product...it's not something you sort of tack on to the end when you happen to think about it.
:)
I am a technical writer. I work documenting products with GUIs and also CLI products. Here's some stuff I've learned in my two years (yeah, I'm a newbie still) of tech-writer experience:
a) Tech writers do actually have to be technically competent. Those who are technically incompetent might be able to write, but they can't write good docs.
b) Technical documentation cannot be treated as an afterthought. The documentation team should be incorporated into the development process as early as possible...ideally, as soon as the project team is put together. OSS projects can't really do this, of course, because there is no formal process in place...there is no real "team" that is put together for a project...projects just sort of grow and morph and change and develop as time goes on. Or at least that's the impression I get...if I'm wrong, please correct me. I'm sure there are some examples of OSS projects that do have a more formal development process.
c) Technical documentation is a cooperative effort that involves writers, developers, and users. The developers have to provide the basic information and they have to review the documentation for technical accuracy. Writers have to work with the developers on this, as well as diving in and learning everything they possibly can about the product. Users have to provide feedback not just about the product itself, but about the documentation as well. Writers have to use this feedback to improve the documentation and to make suggestions to developers about how usability of a product can be improved. It's all one big symbiotic process that helps create really good and usable products through an evolutionary development process. It takes time and it takes a lot of work and coordination.
d) Technical documentation has to be written for a specific user audience. You can't write good documentation if you don't know who you're writing it for. This means that writers have to develop user profiles, and then write for people who fit these profiles. If you just start writing, you're going to end up with documentation which is way too technical in some areas (you write for experts), way too newbie in other areas (you write for new users), and a mishmash of in-between stuff. This makes for documentation that doesn't suit anyone's needs. This also means that you might have to write more than one set of docs for a particular product: one set for experts, one set for rank newbies, one set for people who are interested in working on development, etc. Defining your users and creating profiles of these users is a key aspect of writing docs (and in developing apps).
er...
Etcetera. I could go on for days about this stuff. My point is this: the OSS movement is sorely lacking in the documentation department. The vast majority of docs that exist are written by the people who developed the applications, which means that most of it is far too technical for the average user. Most of the docs are also written about the particular product rather than about how to use the product. It's extremely important that documentation is task-based and user-based rather than technology based. Writing docs like that isn't nearly as easy as some might think, because as soon as you know how to use a product, you tend to start skipping the details when you write it up.
Oop...I got rambling again. Sorry.
We need docs. We need good docs written by people who know how to write docs. I volunteered to help the documentation effort for one product but I never got any feedback from the coordinator. I'd like to help. I am not a coder, but I do have skills which I think would be useful in context of the larger OSS movement. The problems are: writing doesn't have the same prestige value as hacking code; writing tech docs is not an activity that can be done in communicative isolation (which means we can't just sit in our basements crankin' this stuff out like code hackers do); developers (in general) don't want to be bothered with docs or with helping writers with docs...etc.
Ach. I could go on and on. And on
We need good docs. If there are any other tech writers out there who are interested in chatting about this stuff, email me. I could start a linux-writers listserv and we could start hashing out some ideas.
- dria