Still More on Open Source Usability 408
Theo Kolokotronis writes "Many people replied to the controversial article by John Gruber about UI/Usability in the FOSS developments. Among these replies you will find OSNews' (which had spurred some interesting discussion too), Brad Griffith's about the niceties of GNOME and its future (mirror), Havoc Pennington's promise of a new UI era via Red Hat's newly assembled desktop team in Boston and even Microsoft's Don Box." The previous story was Making Things Easy Is Hard.
Usability is for N(0)(0)bies (Score:5, Funny)
Real men recognize that the text based command line is where you prove your mettle and show who owns this place.
Re:Usability is for N(0)(0)bies (Score:4, Insightful)
Unfortately, it's that "You've gotta type a command to do that!" mentality that keeps average desktop users away.
Re:Usability is for N(0)(0)bies (Score:2, Funny)
You say that like it's a bad thing.
Re:Usability is for N(0)(0)bies (Score:5, Funny)
yes. many people fail to recognise that as a good thing...
Re:Usability is for N(0)(0)bies (Score:5, Insightful)
...and many people here will still bitch about lack of acceptance on the desktop.
Re:Usability is for N(0)(0)bies (Score:2)
from the make-it-stop dept.
Agreed. Wholeheartedly. Please.
Re:Usability is for N(0)(0)bies (Score:5, Insightful)
Anyone know?
Why CLi GUi (Score:5, Informative)
I want to find all documents matching $PATTERN and display their contents. cat `find -name "$PATTERN" | xargs`
Now find all documents with a certain name that have $STRING inside of them cat `find -name "$PATTERN" | xargs` | grep "$STRING"
What if a certain program hangs and it has 50 children and they have differnt names? I find this works well kill -9 `ps -aux | grep $PSNAME | awk '{print $2}' | xargs`
These are just some arbitrary examples of how you can use pipes to combine of few small tools into a single useful tool.
Re:Why CLi GUi (Score:3, Insightful)
No matter how trivial a task you're trying to achieve, nah, we won't give you a complete program. We'll give you a bucket of whatever bits someone could be arsed to write, and it's your problem to figure out how to combine them.
Which is as idiotic as sayin
Re:Why CLi GUi (Score:3, Insightful)
Just had to add a few more words about this.
You see, my dear lemming, it may be hard for you to comprehend it, but not everyone is a cheapskate.
I don't have Windows 2003, I most of the time run on my legit bought copy of Windows 2000. I'm writing this on a SuSE 9.0 box. I actually bought the boxed distro.
What half the "either FOSS or pirated Windows" fucktards don't seem to undestand is that good sof
Re:Why CLi GUi (Score:3, Interesting)
It just boils down to if the interface is turing complete or not.
Of course you could construct a GUI with ability to describe functional abstractions and choices
Command line vs. GUI: Renaming files example (Score:3, Insightful)
Now open a ShellWindow/CommandPrompt. Go to the same directory. Rename the files that end with ".text" to ".txt". If the last step took more than one command, please stop reading Slashdot.
I have yet to see any GUI that can change filenames through pattern matching. I could write one, but that feature is missing from the GUIs I have used. It is not necessary because all programme
Re:Usability is for N(0)(0)bies (Score:5, Insightful)
Creates thumbnails of all of the JPEGs in a directory hierarchy. You can probably find a GUI app to accomplish this specific task, since it is so common, but the point is that you can replace the convert command with just about any processing command (such as strip '\r' characters from text files, or sort images into subdirectories based on size), and this enables doing things that are simply impossible to batch with a GUI (without writing an app).
Let me put it this way: any sufficiently flexible and generic GUI app that enables doing what you can do in a shell, is a shell.
Re:Usability is for N(0)(0)bies (Score:5, Insightful)
For "advanced" users, and users who are looking for efficiency, it's tough to beat the command-line. And I'm talking about the *nix command line - CMD.EXE is not, IMO, a usefull command line. True, using the command line (at first) requires a bit more basic knowledge than using a GUI, but a GUI cannot be as efficiently powerfull or as flexible.
Case in point: Last week my boss was talking to me, asking about some particular statistics and information thinking that I would gather the data and get back to him. I said "hang on", pulled up a terminal window, ssh'd in to the machine in question and changed to the log directory (all this can be done with a GUI too, BTW). I then typed a single line using a series of commands including grep, sed, awk, less and various regular expressions. Almost instantly, the relevant infomation scrolled onto the screen, rearranged, filtered and organized according to his particular question. Based on this information, he asked further questions which only required hitting the up arrow to recall the last command and editing a few characters to modify the command's behavior. BTW, this was on a 2GB+ log file. This could not have been accomplished with a GUI within any reasonable amount of time without the entire logging system having been organized ahead of time into a complex relational database and a GUI with the particular type of querying and filtering I needed at that moment having been designed in advance. It is thoretically possible that I could have imported the log into Excel and performed a series of queries, sorts, filters, etc, followed by dragging columns around to put appropriate info next to eachother while deleting other columns because the weren't pertinent. This is even assuming the log file was even organized into a "tabbular-friendly" format (which it is not as it aggregates textual information from several different sources).
Now, I understand that this example is an extreme one that the ordinary user would never need, or even be able, to do. However, I do this sort of thing most of the day and I can honestly say that most of it would be terribly onerous to do through a GUI interface.
The basic strength of the command-line is the ability to pass data through a series of small, powerfull programs, each one refining or processing the data from the previous one. A GUI implementation would require either a monolithic program that provided all the functionality of the thousands of specialized tools available from the command line, or, it would require the user to launch each GUI version of these programs, import the data successively into each, process it and then export it to the next.
By typing something like:
I've just taken all logs from my directory on down which have been modified in the last 24 hours, removed all lines except the ones I'm looking for, sanitized any references to a particularly sensitive piece of data, aggregated all matching resulting lines from all relavant files and compaired it to a reference file, producing a searchable, browseable report showing only the differences between my current search and the reference file. Now, short of having a custom-written application to do just that sort of thing, how are you going to use "included" GUI applications to accomplish the same or similar tasks with as much finesse or efficiency?
Those who have known nothing but windows (or classic mac
Power for a price (Score:5, Insightful)
It is not a Linux thing, it is a Unix thing, so you might as well include the BSD crowd, the Sun crowd, and the new kids on the block from Apple. In fact, since the only people left standing without a Unix-based operating system (in our price range at least) work for Microsoft, the question should probably be phrased more like: What are the Windows people missing out on?
The Command Line Interface (CLI) is a beautifully designed tool set that will let you solve just about any computing problem elegantly and with very few resources. If you program in C, it is the best environment possible. You have easy access to far more options than any GUI can give you -- liberal use of the "nice" command (decrease the priority of a task) will save you one CPU generation right there. And last but not least: The GNU tools have been in use forever, and are beyond stable. In my ten years of using them, I have yet to have one crash or lock up. When things have gone wrong, it has been the kernel or, ah, me. Usually, me...
However, this power comes at a price: You have to sit down and learn a thing or two. For most computer users these days, this is not worth it, because all they want to do is write emails, chat, and download porn, and don't like learning things anyway. For those who use their computer a lot, be it for fun or profit, and like to use it hard, the time invested is repaid very, very quickly. This is one reason why some CLI fans look down on those who don't speak bash: In their eyes, GUI-only people either don't use their computer for serious (non-email, non-chat, non-porn) work, or -- worse -- are too dumb or lazy to learn how the best tools work. It is sort of like a carpenter who says he doesn't know how to use power tools and doesn't want to learn because it would be too much of an effort.
So basically, the *nix command line is like any other powerful magic: It takes time to learn, it is habit forming, it will change your perception of the (computer) world forever, it can bite you bad, it is not for everybody, and -- obviously -- prolonged use will make you arrogant as hell.
Re:Usability is for N(0)(0)bies (Score:5, Insightful)
majorRant = true;
All these OSS (I haven't seen a lot of this reasoning - thankfully - from the free software people) advocates seem to be banging the "Aunt Tillie Drums" like there's no tomorrow. "Linux" must do this/that for the average/newbie desktop users! The "Linux movement" should focus on serving people ignorant/uninterested in how an OS works or what they can do with it!
I call troll on these people. "Linux" mustn't do any of those things, it mustn't "overtake" the desktop-of-the-masses title. It mustn't even have to try. I'm certainly not alone in coming to GNU/Linux from both Mac OS and Windows because I wanted a free system and culture in which to learn more - not less - about how to make the computer do what I want.
The organic evolution in the free/open source community is also taunted by the same crowd - duplication of effort, waste of resources, blah blah.
WTF? How do these people think coders learn the ropes?! By scratching an itch. So what if there are 900 audio players, or hundreds of Perl modules doing similar stuff? Do we lecture nature about the inefficiency of having so many different species of birds? A handful would suffice, talk about waste! And the knowledge gained while creating yet another RSS aggregator is used in every subsequent project. Plus, everybody can learn from that (duplicious) effort. And every once in a while, there's an evolutionary leap - that everybody can use and learn from too. It's the greatest gift our free (as in freedom) system offers.
If you in the Aunt Tillie Vanguard want to spend your careers getting "Linux" to "just work" for her, fine. Please continue coding, but don't run around like squirrels on PCP, telling the entire community what "must be done to compete on the desktop". Why the hell should that be the number 1 to-do for the entire community?
Re:Usability is for N(0)(0)bies (Score:3, Insightful)
Unfortately, it's that "You've gotta type a command to do that!" mentality that keeps average desktop users away.
It's the "I don't know what sarcasm is and generally don't have a sense of humour" that unecessarily fragments open source development.
Unfortunately... (Score:4, Insightful)
Re:Unfortunately... (Score:3, Interesting)
or... how about trying to upgrade major applications that depends on libraries?
It's easy to use, so long as someone else is administering the machine.
Re:Usability is for N(0)(0)bies (Score:3, Funny)
Re:Usability is for N(0)(0)bies (Score:3, Funny)
Yup, and it's $699 per month.
SB
Re:Usability is for N(0)(0)bies (Score:3, Funny)
Re:Usability is for N(0)(0)bies (Score:2, Funny)
Re:Usability is for N(0)(0)bies (Score:5, Funny)
Re:Usability is for N(0)(0)bies (Score:3, Funny)
Re:Usability is for N(0)(0)bies (Score:5, Interesting)
First, there is the matter of command recall. A command line without this is a lot more user hostile than one that is.
There are matters of teletype help, which allows one to select the right switches. Some of the programs that offer lots of options have a very large teletype help, which can not be viewed by screen-fuls.
Whether command and/or file completion is present is another issue.
An important issue is console leakage: that is, whether things like stacks, pipes and command histories leak from console to console.
Another joy i discovered is that multithreading pipe commands might transfer control to the last window, which nicely ends the console after successful completion.
For those who don't understand, trying to say, "there is no 4dos".....
Even there are several command line interfaces.
- teletype session, where input and output sessions are to the same session, eg cmd.exe, command.com
- command line session, where the command line is for input only, and output goes elsewhere (eg to a different window) eg dbase ii, praxim, IBM DOS E Editor.
Of course, just because the thing looks like a command console, it can be as every bit as hostile as a gui can.Making command sessions more user friendly
Here are some tips for making a command line more user friendly.
Sometimes, PHBs serve a purpose... (Score:5, Informative)
I've seen far too many applications in both the open source and commerical world where it's clear to me that they developer took the option that was easier to code rather than the one that would have followed the standard UI conventions.
In Open Source, far too often developers are ending up coding for other developers rather than users. Only the for-profit concerns like Lindows and Apple appear to be making advancements in helping clueless users use operating systems.
It's something the other OSS projects need to pay more attention to if they want Linux on the desktop. Server opperators are more willing to drop to the command line than newbies.
Re:Sometimes, PHBs serve a purpose... (Score:5, Insightful)
Last summer, in the visual design phase of my current project, we did a 6-week engagement with the consulting arm of a large, blue company to the tune of $30,000, for information architecture, visual design & usability - with the blessing of the clients. When we got to the end and presented everything to the "clients" (internal end-users), they said "that's nice, but we want what we want, so throw out 75% of what you just showed us." They cared not at all about actual usability, they wanted this horrific system that they had all cooked up in their heads.
Our consultant had never seen such a meeting. Never had he heard people answer "yes" to the question "are you saying you want to ignore all these recommendations, industry best practices (and standards) and suggestions presented by this industry giant who have proven that they know what they're talking about?"
Re:Sometimes, PHBs serve a purpose... (Score:4, Insightful)
Whenever you're changing the system that people use on a daily basis to do their job, all they're going to want to know is where you hid the menu function that they're supposed to use where such-and-such a situation is encountered.
These users have to be consulted in the design phase. Afterall, the people who do that job are going to be the world's leading authorities on what tool they most want to have helping them. Also, you'd better talk to their supervisor... there's nothing worse than a rare situation that the old software used to handle that your new software never took into account... so the rules say that the employee has to fill out a form your software never had. Then you've got a big design flaw...
Re:Sometimes, PHBs serve a purpose... (Score:2)
There is no system that's being "changed." It's an entirely new online system to replace their 1950s-era paper-based process.
These people weren't "consulted" - they were given free reign. Their first design (yes, they were allowed to do a huge design before we brought in any exp
Re:Sometimes, PHBs serve a purpose... (Score:4, Interesting)
Heh, I have seen quite a few such meetings with consultants gettign all worked up because the users didn't listen.
I have a simple message for such consultants. The users may not know what they want technically or functionally, but they damn well know how their job is done, and if you make a tool to help them do their job, you should be listenign to them first, and come back to them with every 'technical solution' you think up.
Re:Sometimes, PHBs serve a purpose... (Score:2)
Re:Sometimes, PHBs serve a purpose... (Score:5, Interesting)
The programmers complained, but the users were adamant. The system was delivered as a full-screen app with no minimize button.
By the time the app was deployed, the users had been using Windows for several months. The #1 complaint about the system was the fact that it was full-screen, with no minimize button.
The most dreaded phrase in the industry - "It's just what I asked for, but it's not what I want."
isn't a problem though (Score:4, Insightful)
These developers obviously are unaware that the single most unreliable & error-prone part of system development - is requirements gathering.
So, if you follow a waterfall methodology and deliver everything at once - you're almost guaranteed to have disgruntled users with major change requirements. If instead you provide them with a series of prototypes these problems are easily handled.
So, no - asking or expecting the users to understand the best way for their jobs to work is rediculous - since their jobs should be changing over time, and few have probably seen how it's done everywhere else anyway. The best thing is to develop adaptable systems in iterations - and go to work with the attitude that change is good.
Re:Sometimes, PHBs serve a purpose... (Score:3, Insightful)
Sure, there are several easy technical fixes for the problem.
My point is that the users demanded the wrong thing. Always listening to the users makes no more sense then always listening to the programmers. People are stupid, organizations are dysfunctional, and developing systems is hard.
Re:Sometimes, PHBs serve a purpose... (Score:2)
Thankfully I've never had to deal with customers. I've heard this sentiment several times over the years. You must remember that users are not experts on usability, security, scalability, reliability, etc, etc. At some point someone has to act as a mediator and say "look, that's just not going to work well". Explain why, and try to work out other solutions or a compromise. I guess
Re:Sometimes, PHBs serve a purpose... (Score:2)
Re:Sometimes, PHBs serve a purpose... (Score:3, Insightful)
All too true. Equally true is that they believe that UI == GUI.
In Open Source, far too often developers are ending up coding for other developers rather than users. Only the for-profit concerns like Lindows and Apple appear to be making advancements in helping cluel
Re:Sometimes, PHBs serve a purpose... (Score:5, Insightful)
VB isn't the programming language to use to write an audio codec... but when you just want to play music and don't want to be worried about what audio codec its in, you just call for the Windows Media Player control... You can write a media player with a totally revolutionary new interface without having to understand a single audio codec if you just write your software to use a component you're sure will be there on every Windows system.
VB sometimes blurs the line between being a "programming language" into just being a "scripting langage"... Apple just plain admits they support scripting with AppleScript... where's Linux's entry into this race?
Re:Sometimes, PHBs serve a purpose... (Score:5, Interesting)
Lets see...
sh? csh? bash? have done scripting for ages.
'modern' systems often include languages like perl. For what you want however I'd take a look at python or tcl/tk
Your problem seems to be that you have too much choice. Whatever MS made you believe, they did not invent scripting, and were not the first one to introduce a language that is somewhere inbetween scripting and a full programing language.
Re:Sometimes, PHBs serve a purpose... (Score:3, Interesting)
If I want to copy a list of filenames from the web browser to the clipboard, and then feed them to a command line ZIP compressor, and then burn that ZIP to a CD, could I do all that easily using
Re:Sometimes, PHBs serve a purpose... (Score:5, Insightful)
That said, commandline scripting is a lot more powerfull, and virtually all unix tools are scriptable that way.
For your example, the only 'trick' needed is getting the list from the clipboard and the only gui tool is the browser.
In fact, most of the GUI frontends for burnign cds on Linux do just that, be a frontend, and use underlying commandline tools with help of the scripting support.
Anyway, a generic way of scripting gui components is usefull, but I have yet to see an example of performing a scriptable procedure that can be done with scriptable gui components that cannot be done on Linux. The way in which to do it is different tho.
Unix scripting doesn't easily allow you to tell the gui to press a button, but it does a good job at tellign a tool to perform a job.
With the way piping works on Unix, this is extremely powerfull also.
What you cannot do easily on Linux is embeding a gui control from one application into another (yes, KDE can do this, and prolly other environments as well, ie gnome. THere is however no standard way for doing this) That however has little to do with scripting, it just happens to be soemthing you can also use from scripting languages on Windows.
Unix needs a generic way to talk to gui objects regardless of what produced that gui object. This is needed in general, and would provide for 'Windows/OSX' like scripting of gui components as well.
This however is not the fault of the scripting tools on Unix or Linux, it is the fault of X.
Re:Sometimes, PHBs serve a purpose... (Score:5, Interesting)
That said, commandline scripting is a lot more powerfull, and virtually all unix tools are scriptable that way.
Gluing applications together as tools is not the only issue with scripting them - sometimes you want to be able to automate those existing applications. This is where something like AppleScript is an excellent tool. For example, Safari does not have a "session" capability to easily save/restore all the open windows and tabs I have. With a bit of AppleScript and a UI I put together in Interface Builder, I have a nice little tool that can extend Safari's capabilities by controlling its GUI.
I've also used AppleScript to do stuff with console applications, capture the output, play with it (or have Perl do something with it), then pass it to a text box/e-mail message/whatever in a GUI app.
Scripting isn't just about putting together grep and sed to mess with data - it's also about being able to automate existing apps and extend their functionality. In this regard, OS X Panther (with GUI scripting allowing you to control the interface of any application, even otherwise non-scriptable ones) definitely beats out Windows and Linux.
Re:Sometimes, PHBs serve a purpose... (Score:2)
Re:Sometimes, PHBs serve a purpose... (Score:2, Interesting)
Re:Sometimes, PHBs serve a purpose... (Score:2)
As an example, one of my profs was once tossing around the idea of using a MediaPlayer ActiveX control in an application (archived Anthropology-type films with seekable indices). It turned out that there was no way to seek using the provided API. The control interface was too limited for the project.
Re:Sometimes, PHBs serve a purpose... (Score:5, Interesting)
Take a look at the User interface hall of shame [libero.it]. It has tons of examples with screenshots and explanations of what is wrong in several categories:
Nothing to do. (Score:5, Insightful)
I was right now using FMA [sourceforge.net], an open-source interface for Sony-Ericsson mobiles, and, in 24 developers, 4 of them are graphic designers...
Want any better?
Re:Nothing to do. (Score:3, Insightful)
Re:Nothing to do. (Score:5, Insightful)
Re:Nothing to do. (Score:3, Insightful)
Classically wrongheaded interpretation of graphic design. GD is about more than choosing fonts and phoning an illustrator up.
Good graphic design is about communicating through a number of different levels a complex negotiation between publisher and user. For example, good graphic design would determine when to use an icon, a text description, an image, a sound or an animation. Good design is a fundamental aspect of UI.
The interesting aspect of GUI work is th
Re:Nothing to do. (Score:2)
Hell yeah, I want better (Score:5, Insightful)
- user research [coniferresearch.com]
- interaction design [interactiondesigners.com]
- interface design and rapid prototyping [paperprototyping.com]
- Content-based products like a website or CMS should add information architecture [aifia.org].
- usability evaluation [upassoc.org]
Note that on a small team, one person might combine a couple of said roles.Here's a diagram that shows an incomplete sampling of user experience disciplines [interactionary.com].
It's a profound problem in OSS that people consider having graphic designers the answer (hence the multitude of useless eyecandy as substitute for any real UI innovation). This problem is compounded by the fact that most of the people with the skills needed to develop good strategy and requirements (the foundation of good user experience) don't have coding skills. And in a culture of "don't whine, patch it" these people are shut out from contributing, and are turned off by teams who ask for code, when they should be asking for insight (something lacking in many OSS projects).
Next generation GUI (Score:2, Interesting)
Re:Next generation GUI (Score:4, Insightful)
Re:Next generation GUI (Score:2)
I'd show you the proof, but as far as I can tell Microsoft dumped the project (and for good reason, it wasn't really an improvement in usability at all... it was just pretty.)
Dunno. I've never been a big fan of the idea of 3D interfaces, so maybe I'm just a naysayer.
Comment removed (Score:5, Insightful)
As for BBEdit.... (Score:2)
But then again, BBEdit looks like shit to most of other free software, so I really wouldn't take it seriously
good points (Score:5, Insightful)
In the past, it wasn't a big deal. After all the software was free, it was fairly easy to understand (Linux kernel 0.99 anyone?), and it was for the geeks, by the geeks.
But now, I'm using Red Hat on my desktop machine. I paid money for it. I still pay money to keep it up2date. Next to it I have a couple Macs with Panther. The usability difference is HUGE.
I use KDE with Red Hat (the fact that I have to say this is itself is a warning sign: why should a desktop linux product come with more than one "graphical environment"?).
My Red Hat is full of problems. Let's ignore the technical ones like how I have to log in and out once every couple of months due to some weird memory leak, or how the mouse cursor doesn't get grabbed, or weird things happen when I accidentally press another mouse button while holding down the left one.
Compared to Mac: don't even get me started. The Mac isn't even close to perfect but you can tell they are *trying*. Everything is stripped down as much as possible. Programs like iCal are wonderful examples of "just what you need and nothing more". Error messages are carefully worded so they can be quickly understood. Etc.
Windows is a little lower on the scale, but I can still use it fine day-to-day, because MS has clearly gone out of their way to make common tasks simple.
KDE has a lot of problems. I won't iterate them all here, but most of them boil down to two things: 1) too many choices, 2) too much programmer ego.
#1 can be solved by the distributor. They can step in and say, only this ONE chat client will be available by default. Only this ONE email program. Only ONE desktop environment. The rest can be installed in a separate step, even by the power users.
#2 is related, but tougher. Egoless design is tough. Designing something that works so well nobody notices is really tough and hard for most open source programmers (myself included).
I admit, it is REALLY HARD to come up with good designs. You have to do usability tests and get feedback from users. You have to convince the users that if something is really confusing, it's not their fault, it's the software's fault, and they should speak up. It's tough to strip down a UI from 10 buttons to 2 (look at apple: on their media players, they got rid of separate pause/stop buttons, and rewind buttons. They stripped down the UI to the minimum. Would you have thought of that?)
You have to have a razor blade and trim the fat. This can't be done collaboratively. I feel it will happen one of these days, and articles like these will be part of the reason. I can't wait! Freedom and usability are close cousins, don't you think?
Re:good points (Score:5, Insightful)
If you are looking for a desktop environment that is simple and clean, use GNOME. If you are looking for a desktop environment that has every feature you could imagine available, and has some features multiple times, than use KDE.
You complain about choice, but in this case, choice is your friend. Take advantage of the fact that there are different desktop environments that are geared for different types of users. This is what makes linux wonderful.
Re:good points (Score:3, Interesting)
Mod parent up.
Exactly.
I was a KDE user for a long time because it was close to what I was familiar with (windows; yeah, the shame
I find that I get a lot more done now than I used to, and the UI doesn't get in the way.
Simple and Clean is sweetness, but the really great thing about Linux is having the choice to use what works for one; not what w
Re:good points (Score:3, Interesting)
You're comparing apples and oranges here.
KDE is an entire Desktop Environment that consists of a Window Manager (Kwin), a desktop shell (KDesktop) and lots of programs written for it (Konqueror, Kmail, Konsole, ...). It is also a set of API's tha
Re:good points (Score:2, Insightful)
Re:good points (Score:3, Informative)
constantly gets in your way? so every time i boot windows a
printer sharing (Score:4, Insightful)
It amuses me, then, that I'm currently having problems sharing a printer between two MacOS X boxes. We have a home network consisting of two MacOS X machines, plus a FreeBSD box that I do most of my work on. The printer is on my wife's Mac, and I don't have printing set up on FreeBSD, so normally I just transfer a PDF file to my own Mac, then print it via her Mac. Hee hee -- it almost exactly mirror's Eric Raymond's original situation with sharing a printer between his machine and his wife's, except that the OS has been changed to protect the innocent.
Well it's true that setting up printer sharing was really easy. The problem is that it often doesn't work. I try to print, and I get this beautiful, lickable, throbbing blue dialog box that says "Unable to print" (or "There was a problem printing," or something equally useless -- I forget what, exactly).
So what ya gonna do on an OS that is supposed to Just Work, and one day it Just Doesn't? If it was Linux or FreeBSD, I could read the man page, or find out where the log file was. Oops -- no such option on MacOS X. On Linux or FreeBSD, I'd also probably get some kind of error message that, while written in Martian, would at least provide some hint as to what was wrong if shown to someone sufficiently knowledgeable.
So what do I do? Reboot my machine; no dice. Reboot her machine; no dice. Give up. Some days it works, and some days it doesn't. Shrug.
The solution ends up being just what it probably was in the Raymond household: transfer the file to my wife's machine, then ask my wife to get up from her desk and let me print the file. The main difference is that since MacOS X is a proprietary, closed-source system, there's no way for people with the necessary skillz to dig through the source code, figure out what's wrong, and fix it.
Re:printer sharing (Score:3, Insightful)
Don't know about others, but I for sure know that it's not a minute under Fedora.
Applications - System tools - Printing
pick a Windows Network and choose printer.
Sharing of every printer is the default, Samba by default provides [Printers] as default, which makes every printer on Linux as shared. Same with Linux network.
Eric Raymond has picked a damn wrong case, I for sure know that Mandrake and Suse are doing just as good as Fedora in that
Re:printer sharing (Score:2)
Different solutions for different people (Score:5, Insightful)
That's what a tech-savvy user would do, yes. Anyone else will simply send their computer in to be fixed.
The solution ends up being just what it probably was in the Raymond household:
Same as above. The solution for the average consumer is to send that sucker in. They lump everything into "Just Works" or "Just Doesn't." When something "Just Doesn't," they send it in. They care nothing about looking through source code, or man pages, or any other damned thing.
Re:printer sharing (Score:5, Informative)
Want a text file to edit? Try
Want a manpage? man cupsd.conf
Want logfiles with weird error messages? Try taking a look at
Not saying it will fix your problem. I'm just saying that you can't blame the proprietary operating system. You have the source code for the printing service!
Re:printer sharing (same on Windows) (Score:2)
Presumably things would have been better if we'd been smarter and bought fewer better printers and used them on the network.
I could use the printers OK, but as the lowest programmer on the rung I did tech support and on a weekly basis I had to f
Re:printer sharing (Score:2, Insightful)
ease-of-use not unidimensional (Score:5, Insightful)
The challenge for OSS is that it is, by and large, nerds writing software for nerds. As such, they create software that emphasizes ease-of-power. They ignore the learning curve because they assume users will want to take the time to learn the software and that they will use the software intensively enough that they do not forget the commands. These assumption are false for mainstream users.
If OSS is to become mainstream, it will need to put ease-of-learning above ease-of-power (perhaps providing a dual interface such as OS X's GUI + CLI design). Adoption will depend on the extent that OSS front-end and near-front-end architecture is driven by usability experts/advocates instead of hardcore programmers.
Comment removed (Score:5, Insightful)
Re:ease-of-use not unidimensional (Score:5, Insightful)
If something took you ages to find out, it's common courtesy to share that information with others so nobody else has to expend that much effort ever again. Post about it on your own web site {where Google will find it, eventually} and on the LinuxQuestions Wiki [linuxquestions.org]. E-mail the package author -- it could be a simple, honest omission; after all, what's obvious to one person isn't necessarily obvious to everyone.
These people have given you all this software out of the goodness of their own hearts, and in good faith that you will find it useful. They haven't asked you for anything in return. Even if you're not a programmer and so can't improve on the actual code yourself, nobody is stopping you from working on improving on the documentation.
Root Cause Analysis (Score:3, Interesting)
Most developers are also the designers of a product. So this problem roots down into the fact that software whose roots lie in UNIX have been completely developed in vim, XEmacs, maybe Eclipse. These environments cause the developer to think in this non user-centric point of view.
In sharp contrast, OS X's Interface Builder and Microsoft's Visual Studio affords the developer time and energy to think about the design of the program.
Plus, Apple and Microsoft have real, thought-out interface guideline documentation.
That's my evaluation of psychology of the developer-designer role.
Re:Root Cause Analysis (Score:3, Informative)
And what of Glade or QTdesigner? There's plenty of systems to provide the sort of functionality for FOSS. In the end the likes of Emacs and vi are still popular because they are unparalleled at simply editing the raw code. Of course that doesn't mean that UIs aren't built or designed with the tools above (which, it is worth noting, can stand alone, as
Re:Root Cause Analysis (Score:2)
Re:Root Cause Analysis (Score:2)
Interesting article linked to by Pennington (Score:5, Interesting)
Here [daringfireball.net]
Basically a critique of ESR's article. Key quote:
I disagree with his view that ui design is some sort of mystic, unlearnable talent, and he may take the argument to the opposite extreme, but the position that the gui problem suffers from a lack of respect is spot on. Afterthought guis look like afterthoughts.
There's a lot of "you have to do this" and "you have to target Mr. X" floating around, but I think the real breakthroughs will come as developers begin to view ui design as an interesting and substantial problem to be solved rather than a quick makeover.
Griffith not quite getting it (Score:5, Interesting)
Consider Muine vs. iTunes. Muine stacks artist information on top of individual song titles, so it takes up twice as much space in the window--that means twice as much scrolling. There's also no quick way to alter the sorting order, rip or burn CDs, or switch or create playlists in Muine. iTunes supports single-click/drag'n'drop for all of these. The point isn't that the interface is simple, but that it gives the end-user precisely the abilities he needs to use the application comfortably.
The Unix philosophy for ripping and burning is to have separate apps to handle those tasks, distinct from jukebox software. But, for 99% of the computer-using populace (ie, those who don't need a burner to be able to burn an ISO image to a CD), All three tasks are related: one would want to rip a few CDs, make a play list, and then burn it-- all in one app.
To realize this is to experience the GUI equivalent of enlightenment.
Re:Griffith not quite getting it (Score:2)
The Unix philosophy for ripping and burning is to have separate apps to handle those tasks, distinct from jukebox software. But, for 99% of the computer-using populace (ie, those who don't need a burner to be able to burn an ISO image to a CD), All three tasks are related: one would want to rip a few CDs, make a play list, and then burn it-- all in one app.
One app... you mean like K3B [k3b.org]? I find this much easier to use than its closest Windows counterpart (Nero), due to its lack of clutter in the burning s
Missing the point - again (Score:5, Interesting)
Good interfaces aren't always about GUIs either. man is a terrible tool for beginners who are trying to become an expert and are willing to learn. Visualize that you've never used it before and do a man grep. Not too helpful, is it? There are great CLI interfaces as well, a tool like | is one of the things that makes *NIX OSes awesome and powerful.
The main thing that's missing on both sides of the development equation is a commitment to focus. The extremely pervasive "more features = better than" attitude is responsible for a lot of bad interfaces. And both developers and marketroids are guilty of that crime.
Blind UI elephants (Score:3, Insightful)
UI design is often like the story of the blind men and an elephant, very different, depending.
So who will win? I asked about Longhorn at the RedHat world tour, won a cd but got disinterested scowls... who will win? Too bad there isn't a USPO.gov/preview site. 4-5 years from now 88% of the worlds users may be *used* to a patented UI so good OSS UI design could be a moot issue anyway.
UI != { GUI } (Score:4, Insightful)
Don't confuse interfaces and eye candy.
Plead for Cohesion (Score:4, Insightful)
This is excatly what i think should happen. We need to get everyone together all the time and Innovate. FOSS is the perfect place for innovation to grow, yet the splintering of diffrent groups blows all those efforts out the water!
When all these developers know what everyone else is doing and working on, and how they can hook into eachother, is when we will begin to see innovations that will shoot past M$, or even Apple. But until then, we are stuck in bitter "licencing argument" land, and pissy little fights between Devs.
Sure, perhaps we wont be able to get the "kernel engineer's cube was right next to the app_server engineer's cube" situation happening, but right now what OSS needs most is Cohesiveness. For now, that is the one leg up that MS has on us, as the Open source community, is a cohesive process, where (At least i hope, otherwise MS is in a worse state than i though) the developers know what is happening next, and where. They can then anticipate with their coding and make the product come out even better.
This is not meant to be a black mark on OSS, because for the way we do things now we have produced some pretty incredible products, however we need a paradigm bump, moving towards somthing that fits together much better.
features versus ease of use (Score:4, Interesting)
When I was talking about features, the programmer would wonder about how to integrate it in the interface. If he couldn't do it well, bye bye feature. Keep in a separate "kool things that are hard to implement list" and think it over until it can be done right.
That of course runs counter to software designed primarily for the developer himself, but is really the only way to do software for others.
It's interesting to read how so many Linux advocates think a good GUI is for simple users (Joe Six-pack). It is a sign of otherworldliness that seriously threatens the advance of good GUI standards.
I enjoy being "different", meaning, I don't think of myself as the average guy, although I am married with child and guess do and enjoy a lot of very straightforward and predictable things.
But when you make a thing for "the average human being" it should be understood that this means your neighbour, your significant other and quite a few intelligent people you might know. As well as that mythical figure Joe Six-pack, I guess, but he might be capable of many things, this fairy tale person.
He might however not have the patience to build, do command-line or figure out how to print in this environment as opposed to that other environment.
GUI isn't just about the buttons, it's the whole shebang and I really don't think any Linux distribution is up to the task just yet.
But this weekend has proven very interesting. Keep talking, I like, I like.
Just a random tip: free for downloading, perusing and musing: the Apple Human Interface Guidelines (apple.com-developer tab, free subscription to the ADC and there you go). Even if you don't want to do it the "Jobs way" it really pays to read a bit on what they've learned by focussing on that one issue - and you get all those results of testing, testing, testing, thinking, building and typing free of charge, so what's keeping you? At the very least it'll teach you something about style, close family of placement and spacing. It's easy, they provide the numbers.
What the hell are y'all talking about? (Score:4, Interesting)
My system: Athlon 2600, 2 SCSI3 adapters (Adaptec 2940UW), Linux 2.4.24
My running OS: Debian testing, GNOME 2.4.1
My apps: Mozilla 1.7b, XMMS, Emacs, GAIM, GnuCash, MPlayer
I was using KDE 2.2 with Debian stable and found it eminently usable. When I went to Debian testing it was GNOME. I had some hardware glitches to work out in 2.4.21 (audio and devfsd), but those would have been avoided if I had gone straight to testing at the initial install.
Now that the kernel is fixed, my system works perfectly well, and in many respects much better than my wife's XP system. Need a calendar? Click once on the clock applet and a calendar pops up in its own top-level miniwindow, out of the way of your running application. Need a screenshot? "Take Screenshot..." is right off the GNOME menu! Much easier than Print-screen -> Paste into image program -> Save to disk. Need some more screen? Click on another desktop.
The mouse behaves the same way all over GNOME: single-click activates things, right-click pulls up a context menu, mouse-wheel scrolls, and middle-click pastes whatever is highlighted. There's still a few places where programs crash (GNect "Connect Four" game, while clearing an old game, and clicking the exit button) but even then GNOME has the application crash dialog to go with it so it's not a mysterious "woa! where'd the window go?" experience. Outside of SCSI bus lockups while ripping certain CDROMs -- which "unfreeze" about two seconds after ejecting the offending disc -- the system never freezes much less crashes.
Right now I am: playing MP3's with XMMS (over a 380 hour playlist), burning a CD-R, editing about five files in Emacs, navigating Slashdot in one tab, and browing eBay in another tab. The system is humming smoothly and I have no messenger popups, random noises, or floating flash ads in my way. When my wife has trouble on her XP system she routinely uses mine to check her email and browse. And of course nothing beats MPlayer for instantly starting a DVD without menus, ads, or FBI warnings.
Other than Emacs of course, I've done nothing to change the default behavior or keybindings, though I have modified the program launchers on the panel. I find this system very coherent and obvious at what it does, which is let me do what I need done unobtrusively. What I like most is that applications KEEP FOCUS even when new applications are launched -- something I've *never* seen MS Windows capable of doing. I just can't stand being in a window typing away and suddenly a popup dialog steals focus and my next [Enter] does who-knows-what!
So why exactly do y'all maintain that Linux is mystifying to Joe Sixpack? Just put Joe down in front of the system, point him at the GNOME menu, and provide an icon for logging in and out of his ISP.
I think the Linux desktop is NOW, not next year or whenever.
Still no thumbnail view in save and open dialogs!! (Score:3, Informative)
XPs screenshot right under GNOMEs is a clear example of the point, what if I had to choose from 100 pics named in secuential numbers? things get pretty messy for graphics artists, now that the GIMP 2.0 is out and all
It will save me hours a day in time remembering each file name and then going back to the app to choose the right file
Maybe Ill ask nicely next time hehehe
Plretty please! put thumbnail view on open/close dialogs!
User friendliness at the bottom (Score:4, Interesting)
Apart from using '#' as a comment indicator (and I'm not sure about esd.conf) is there any commonality between them at all? Each has its own syntax and conventions and to work out what is going on you need to find and examine the documentation in detail. Whoops: "man esd.conf -- No manual entry for esd.conf". There are 313 files ending in
The end result is a sort of fragility through overload. In theory, it's possible to wade though all this stuff and work out what's happening and what's going wrong. And this is what professional sysadmins are paid to do and hobbyists do for fun. For everybody else, things just take too much time and stay broken. Things stay broken, not because the people using the computers are stupid or ignorant or uneducated, but because they have better things to do with their time than pay the initiation cost to join the geek brotherhood. James Joyce may have demanded that his readers spend the rest of their lives studying his work, but I don't think that helped him, either.
This chaos is because whoever wrote the various programs that use these files simply ran up a configuration file suitable for that program using whatever conventions that seemed like a good idea at the time. (I'm as guilty of this as anyone.) It's an inherent part of the open-source do-it-yourself mentality, exacerbated by programs which are written to solve private problems and gradually become available to a wider audience.
But it's also why any number of tacked-on GUI front-ends will never provide a halfway decent configuration interface in *nix-land. It's not possible to sensibly cope with the diversity in a complete, coherent way. (And that's ignoring 'configuration' that is actually a Turing-equivalent program.)
Looked at from another angle, this is the same problem that confronts any user of OSS with GUIs. Everything is built to act in a locally consistent fashion, with no global coherence. (Eg. running GNOME, KDE and OpenOffice programs simultaneously.)
The obvious solution to all this is vigourously imposed and followed standards for data, metadata and behaviour, so that both users and programs can work with something new. (Although it does cause the dread monoculture security problem; *nix is partially protected from worms simply by the difficulty in finding something consistent to break open.)
But I don't think that its culturally possible within the OSS movement. It requires a considerable amount of discipline to carefully read up and follow configuration standards for a program that just (for now) prints "Hello World". It also places the cost of entry on the programmer, not on the user, and its hard for most people to pay an up-front cost now so that someone else doesn't have to pay a deferred cost. It may be something that "big ticket" OSS projects, such as Apache, are able to impose, however, and it may be something that turns a project into a big ticket project.
[*] Yes, so I used, "locate
Printing is horrendously overcomplicated. (Score:3, Interesting)
What system is it that makes configuring printers easy?
Windows makes you configure all network printers but the ones that use SMB by configuring a local printer and then figure out what the weird Microsoft-specific name for the protocol the printer uses is. [This produced a followup complaining that setting up network printers on Windows is easy... which proceeded to describe how to set up an SMB (Windows Networking) printer]
Mac OS X uses the same CUPS that ESR had problems with, and doesn't tell you you need to open a web browser to localhost:613 to finish the configuration.
Printing is horribly and unnecessarily complicated. Printer manufacturers refuse to make any concessions to interoperability, Apple tried to solve it the right way by embracing Postscript... but they're not big enough to force the issue, and Microsoft puts so many layers between the user and the printer to make up for it that if anything goes wrong you're worse off.
Neither of them do what ESR says they do. I suppose he doesn't actually deal with printer configuration on Macs or PCs running Windows, or he wouldn't have tried to make this nightmare scenario out as some kind of failure specific to OSS.
My wife has a Windows box and a FreeBSD box, I have a Mac, my daughter has a Mac, and my son has a Windows based PC. We can all of us print from our non-Windows boxes, and I can print from my work laptop running Windows 2000.
I finally gave up trying to get my son's PC to print... I tried using Windows networking proxied through my wife's PC, Windows networking through my wife's FreeBSD box using Samba, Windows networking through my Mac, LPD (standard UNIX printing, what Microsoft called 'Microsoft TCP Printing' in NT4 and hides as a special case in Windows 2000) through UNIX and Mac. Nothing works. I did get it working at one point, but it broke after I upgraded his video card(!) and I haven't been able to get it working again.
That it's hard to set up a printer through OSS isn't surprising. It's a hard problem even with Epson providing Microsoft with drivers!
Re:It's not abot usability; it's about IMAGE. (Score:3, Informative)
You say you read slashdot (this forum) regularely, and have quite a bit of knowledge regardign marketing. You surely should have known that 4 years of administrating NT does not qualify for havign experience to make general statements that concern administration? Its first of all bad amrketing on slashdot (bad marketing for yourself as a trustworthy source) and second, you simply didn't see alternatives, so your opinion about it (technical and mark
Re:It's not abot usability; it's about IMAGE. (Score:2)
Linus, RMS, and the gang just aren't good at marketing. IBM and Sun are, so they're really the ones to turn to.
Unfortunately for Linux, they appear to have attracted an group by the name of SCO to scuttle any marketing efforts...
Re:It's not abot usability; it's about IMAGE. (Score:5, Insightful)
The poster believes that issues can be solved through marketing: Beautiful spokesmodels, Fancy logos, Hiding the real leaders of Linux/OSS, "Buzzword Compliance" (his words, not mine), and "Focus Groups" (again, his words).
All those things help a marketing campaign. But open source software isn't about marketing, and it's not about market dominance. OSS is about a way to create software. Nothing more, nothing less.
OSS is not about putting Microsoft out of business. It's not about "winning". Sure, it makes some of us feel good when the software we developed is winning over hearts and minds. In the same light, Microsoft employees can be proud of some of the software they've developed over the years.
Does open source software need some help in the usability category? Yes. In my opinion, OSS desktop software needs more usability help than the commericial products in the same "product space".
But marketing isn't the real answer. OSS software should be darn good despite any marketing efforts. Open source is by the community, for the community.
The commercial vendors of OSS are free to market as they please. The open source community is free to market its goods as it pleases. But marketing alone does not address the real software issues.
Re:It's not abot usability; it's about IMAGE. (Score:3, Interesting)
What you say about "Joe Sixpack" thinking that GNU/Linux is way too difficult is true, and the reason you give for it is true. When my friends come in and see me hacking away at three different terminals, closing processes by running "ps -A" and "kill -9", of course it looks really scary. Then I start to compile packages from scratch, and they run away.
Of course, I didn't start out that way in GNU/Linux. I started out with a friendly, ready made setup of Ma
It's not about "Linux" (Score:5, Insightful)
You don't get it: there is no Linux. There are only projects and distributions. Just like with patents and copyrights (there is no "intellectual property"), you have to separate one from the other and attribute the proper problems to each category.
DirectX? Where the hell did that come from? DirectX is the most proprietary thing that Microsoft has and there is absolutely zero chance of having that ported to GNU/Linux or *BSD. Forget it -- forget you even heard the word "DirectX" because it is not the way of the future. Open standards make developing software cheaper and easier to sell to a variety of platforms... so rather than bitch about not having Microsoft's heroin-like DirectX, you should be looking for ways to sell OpenGL to game developers.
The penguin logo sucks hard, I'll agree. It's beyond lame. The Gnu isn't much better, but it could be salvaged. This is irrelevant though, because logos belong to companies and products. There is no Linux. There is no Linux. There is no Linux. If you want a cool logo, get Red Hat EL or Fedora Core, or Sun JDS or SuSE or even XandrOS.
You are of a dying breed of old marketers who don't understand the new market. I mean no ill will toward you, but you're the kind of person who is causing harm to the Free Software world by treating "Linux" as some kind of product when in reality it's a set of other people's personal projects assembled in a variety of creative and useful ways. If you want to market something, pick a distribution and run with it... or better yet, if you want to go proprietary take the FreeBSD source code and ad all kinds of amazing features, extensions, plugins, a customized GUI and sell it under $100 for x86 machines and give Apple and Microsoft a run for their money at the same time.
Yes, the spokespeople aren't perfect. RMS is a brilliant man with no regard for image. Linus is a brilliant man with no regard for tact (see the Tanenbaum Minix flamewar with LT for an example of how much of a dick Linus can apparently be). ESR... most people I know are wondering why he is a spokesman in the first place. He's more of a sideshow freak than a leader of programmers. Theo from the OpenBSD project is another stellar example of a brilliant man with the social skills of an abused child. But these people were not elected, they didn't climb the corporate ladder to positions of leadership, and they didn't buy their way in. They worked hard and started important projects that turned into very useful software tools (with the exception of ESR, whose projects couldn't match those of any of the others in this list) that are used every day in the operation of important networks and other systems. They are the leaders because they did the inital work (the hardest work) and the projects belong to them.
Their projects are theirs, not some company's... if they want to use a lame logo and act like assholes, the worst that can happen is a fork. There is no Linux; these people are not on the payroll at Linux Inc and they don't have to answer to shareholders, give press conferences, engage in anticompetitive or unscrupulous practices or lie about earnings.
Your advice is interesting but not useful. If you want to help the Free Software community your best bet is to work on software, help people on lists and in forums, or write documentation. This is one thing in the Universe that gains nothing by talking and advice. You either do or you watch.
Lastly, the kinds of things you said people think about "Linux" and Microsoft are silly. Anyone who subscribes to the uneducated opinions of the feebly tutored, strongly traditioned folk-mind with its predilection for guess and fantasy and faith and its ability to generate rumor and hearsay based on fears and hopes... anyone who listens to these opinions and gives them credence, is wasting their time. It's an exercise in futility. You can't educate people with marketing; you educate them with experience -- positive experience. You give them Knoppix and show them what they can do with it, you show them
Re:It's not about "Linux" (Score:2)
Re:It's not about "Linux" (Score:2)
So here's the parent poster's koan for all the /. linux fans and bashers. There's no Linux. Understanding that will bring
Re:It's not abot usability; it's about IMAGE. (Score:3, Insightful)
Few things piss off a herd of geeks like four long prefatory paragraphs intended to prove that "I know whereof I speak."
Unless they're followed by a huge pile of misguided bafflegab, and are embedded in a miasma of condescension and arrogance.
Oh, and FYI ... "why else would we be in this game if not to win it at all costs". Here's where you need to go back to school, young fella. We're in this game because we love the game. Winning, yeah, that's cool too. But "at all costs"? Sorry, that's Microsoft's
Re:Printing sucks. (Score:3, Informative)
1. Insert CD & watch autoplay
2. Wait to be told to plug printer in
Anything harder than that is a bad printer driver (try a HP or some other name brand.) The only possible problem is if you plug the printer in before loading the software, but the printers I see come with a nice large fold out DO THINGS IN THIS ORDER sheet.
Installing a network printer on Windows:
1. Browse to remote computer
2. Double click on the printer icon
-or-
1. Type in share name
Done. And thi
Re:Printing sucks. (Score:3, Interesting)
If you only want to support ONE network printing mechanism and you can force all the manufacturers to write drivers for you, it's easy... for that very small subset of the whole problem.
Now try "installing a network printer not shared from Windows on Windows". Click on "add printer", click on "network printer". Now you're at a dead end... because to add any other kind of network printer you have to select "local printer".
If you don't think that's crazy you're c