the luxury of ignorance
April 13, 2004 1:39 PM Subscribe
"We are now deep in the trackless swamps created by thoughtless, feckless UI design — full of glitz and GUI, signifying nothing." In The Luxury of Ignorance, Eric Raymond attempts to set up a network printer in Linux.
I find it ironic that one of the self-professed godfathers of the Open Source movement would write a long-winded screed rather than remember the motto of the movement: if you don't like it, change it.
Dn's link is excellent and nearly sums up the issues imperiling the Linux desktop UI experience. In it, Gruber suggests that open-source applications have assy UI when compared to commercially developed ones because the open source model does not lend itself well to thought-out UI design.
I would argue that this is not a hole in the O-Source movement but in the mentality of the O-Source developer. O-Source guys aren't about ship dates and making sure the product is good and done when its released, they're all about interim releases. Getting -something- working is often times better than nothing at all, but once it works to a point why go and improve it? They have no "next rev" to push with flashy features, nor are they bashful about putting out code that only partially works but gets the job done.
O-Source stuff will tend to remain half-finished without a major development push behind polishing the application. The Open Source design model does fall apart here: the "all developers are to remain as equal as possible" structure native to most projects does not lend itself towards having a design cabal responsible for cleaning up other's design mistakes.
The beauty of Open Source is that there -is- a potential revenue stream for anybody who wants to form their own cabal, usurp the project and chisel out a better design. Or, for that matter, do it for free.
But who the hell does hard UI design for free, anyways?
posted by Ogre Lawless at 2:18 PM on April 13, 2004
Dn's link is excellent and nearly sums up the issues imperiling the Linux desktop UI experience. In it, Gruber suggests that open-source applications have assy UI when compared to commercially developed ones because the open source model does not lend itself well to thought-out UI design.
I would argue that this is not a hole in the O-Source movement but in the mentality of the O-Source developer. O-Source guys aren't about ship dates and making sure the product is good and done when its released, they're all about interim releases. Getting -something- working is often times better than nothing at all, but once it works to a point why go and improve it? They have no "next rev" to push with flashy features, nor are they bashful about putting out code that only partially works but gets the job done.
O-Source stuff will tend to remain half-finished without a major development push behind polishing the application. The Open Source design model does fall apart here: the "all developers are to remain as equal as possible" structure native to most projects does not lend itself towards having a design cabal responsible for cleaning up other's design mistakes.
The beauty of Open Source is that there -is- a potential revenue stream for anybody who wants to form their own cabal, usurp the project and chisel out a better design. Or, for that matter, do it for free.
But who the hell does hard UI design for free, anyways?
posted by Ogre Lawless at 2:18 PM on April 13, 2004
Ah, Eric S. Raymond - the creator of the venerable and utterly over-complicated Fetchmail program. You'd think a program to download mail from a POP3 or IMAP server would be fairly simple and a doddle to configure? Hoho-NO!
Kettle. Black. Pot.
posted by metaxa at 2:19 PM on April 13, 2004
Kettle. Black. Pot.
posted by metaxa at 2:19 PM on April 13, 2004
Great link Dn. I'd seen the Raymond article before and wondered what he was raving about - sharing a networked printer is not an easy task. Unless you're using MacOS or Windows of course.
posted by cbrody at 2:25 PM on April 13, 2004
posted by cbrody at 2:25 PM on April 13, 2004
<barbie>UI design is hard!</barbie>
As an open source software developer, I struggle with it all the time. And that essay on daringfireball.net is very right. Typically when I need to code some random new Scoop module, I spend about 10% of the time on the underlying function and 90% of the time just doing interface stuff. I have no illusions that I'm any good at interfaces, and the ones I've done that I think are decent are (1) rare and (2) accidental.
So if anyone has any really good links about how to approach UI, especially in a web application context, please share! It would be a good way to rescue a thread that is otherwise doomed to be variations on the tried-and-true "ESR is an idiot" theme.
posted by rusty at 2:34 PM on April 13, 2004
As an open source software developer, I struggle with it all the time. And that essay on daringfireball.net is very right. Typically when I need to code some random new Scoop module, I spend about 10% of the time on the underlying function and 90% of the time just doing interface stuff. I have no illusions that I'm any good at interfaces, and the ones I've done that I think are decent are (1) rare and (2) accidental.
So if anyone has any really good links about how to approach UI, especially in a web application context, please share! It would be a good way to rescue a thread that is otherwise doomed to be variations on the tried-and-true "ESR is an idiot" theme.
posted by rusty at 2:34 PM on April 13, 2004
"...this is a crash landing, an unmitigated disaster."
I can't tell you how many times phrases such as that have floated through my mind while sitting in one project meeting or another, although my versions are usually interspersed with unladylike language.
posted by botono9 at 2:36 PM on April 13, 2004
I can't tell you how many times phrases such as that have floated through my mind while sitting in one project meeting or another, although my versions are usually interspersed with unladylike language.
posted by botono9 at 2:36 PM on April 13, 2004
Fetchmail has its share of problems, but being hard to configure isn't one of them metaxa. For most of the simple cases there's even a GUI tool for it.
posted by fvw at 2:51 PM on April 13, 2004
posted by fvw at 2:51 PM on April 13, 2004
Guess what: if you can't use it/set it up...
Without the manual
Exhausted and psychotic from lack of sleep and
too much caffeine
In the dark
Drunk
At 2 AM
While driving at 75 MPH
...and...
On an unfamiliar, unlit country road
Then your customers will say it's too hard to use. Suck it up and spend more than an afternoon doing customer testing next time.
posted by ZenMasterThis at 3:08 PM on April 13, 2004
Without the manual
Exhausted and psychotic from lack of sleep and
too much caffeine
In the dark
Drunk
At 2 AM
While driving at 75 MPH
...and...
On an unfamiliar, unlit country road
Then your customers will say it's too hard to use. Suck it up and spend more than an afternoon doing customer testing next time.
posted by ZenMasterThis at 3:08 PM on April 13, 2004
Sharing printers from CUPS to Windows was even worse IMO. Why couldn't a default install include an option to add the necessary lines (I'm not getting into the bad documentation on CUPS over samba) and include the printer drivers Windows attempts to download.
ObRant: CUPS is not a Linux application. CUPS is a printing system for unix-like operating system. As much as fanboys and slashdot weenies like to pretend otherwise, Linux is not the only game in town.
posted by KirkJobSluder at 3:15 PM on April 13, 2004
ObRant: CUPS is not a Linux application. CUPS is a printing system for unix-like operating system. As much as fanboys and slashdot weenies like to pretend otherwise, Linux is not the only game in town.
posted by KirkJobSluder at 3:15 PM on April 13, 2004
From the article linked to by Dn:
UI development is the hard part. And it’s not the last step, it’s the first step.
and
They have no respect for the fact the good UI design requires a tremendous amount of time and effort.
Spot on. I'm a UI developer with several years experience in client interface design for complex information management systems. I have attempted to contribute this experience to open-source projects and been met with the online equivalent of a blank stare. The entire approach that even the most successful open-source projects take to project management appears almost hostile to advice from UI, and HCI analysts and practitioners.
The corporate/closed-source universe gets it wrong plenty, too, of course, but at least they're generally willing to concede that a basic attempt to understand use-case scenarios and maybe actually writing down some test-cases might not be entirely irrelevant.
posted by normy at 4:04 PM on April 13, 2004
UI development is the hard part. And it’s not the last step, it’s the first step.
and
They have no respect for the fact the good UI design requires a tremendous amount of time and effort.
Spot on. I'm a UI developer with several years experience in client interface design for complex information management systems. I have attempted to contribute this experience to open-source projects and been met with the online equivalent of a blank stare. The entire approach that even the most successful open-source projects take to project management appears almost hostile to advice from UI, and HCI analysts and practitioners.
The corporate/closed-source universe gets it wrong plenty, too, of course, but at least they're generally willing to concede that a basic attempt to understand use-case scenarios and maybe actually writing down some test-cases might not be entirely irrelevant.
posted by normy at 4:04 PM on April 13, 2004
i've got a similar grumble about linux-ish UI, but then again i'm not exactly an expert. i can set up apache, i can do a basic install, i can add a jetdirect printer, i can get FTP up and running. but it took me a long damn time the first time 'round to get apache going like i wanted on a redhat box, found it was easier to edit the conf file than use the redhat apache GUI tool (hell, you can't even change the default directory to serve files from in the GUI tool!)... and still, running two sites, every time i reboot the box, i lose apache unless i go in and remap both IP addresses to the appropriate ports, 'cause for the life of me although i can get it to work i can't get it to remember what the hell i did once it reboots. back to remapping IPs to aliases to eth0. and don't even ask me how long it took me to stumble through the steps needed to get the damn box to forward all server-bound mail to my pop account.
windows may not be the best of the best, but it certainly is nice to be able to just plug something into the box and have it work. i don't need to drop into a command line or edit script files to make windows go. i really think that what linux needs more than anything else is to assign one moron to each programmer, and force that programmer to see things through the eyes of the moron. i'm tired of how advanced even the simple linux info seems to be; every time i search for help i get a garble of stuff from people who think i know what the hell a cron job is and how to set one up. there really is no linux for beginners, is there? microsoft's smartest move was hiding the guts of the OS from the masses, and only letting the "advanced" users see file extensions and hidden settings... seeing a linux geek admit that, openly, is kind of funny. and a wee bit sad.
posted by caution live frogs at 4:33 PM on April 13, 2004
windows may not be the best of the best, but it certainly is nice to be able to just plug something into the box and have it work. i don't need to drop into a command line or edit script files to make windows go. i really think that what linux needs more than anything else is to assign one moron to each programmer, and force that programmer to see things through the eyes of the moron. i'm tired of how advanced even the simple linux info seems to be; every time i search for help i get a garble of stuff from people who think i know what the hell a cron job is and how to set one up. there really is no linux for beginners, is there? microsoft's smartest move was hiding the guts of the OS from the masses, and only letting the "advanced" users see file extensions and hidden settings... seeing a linux geek admit that, openly, is kind of funny. and a wee bit sad.
posted by caution live frogs at 4:33 PM on April 13, 2004
[metaxa - getmail is great]
i don't think we know how to do ui well. not from a programming perspective. it's possible to get something that looks nice and works fairly well with lots of effort, but it doesn't scale well.
maybe it's just that i don't have the right knowledge - i'm not a ui designer (and i tend to try and avoid ui because i think it's too hard; i don't mind a challenge, but guaranteed disappointment is a turn-off) - but i don't see any approach that gives the kind of clean separation of concerns that you get with a good solution in other areas of programming.
for example: there are books and books on algorithms and data structures - they're full of maths and proofs and clear facts. in comparison, info on ui design and implementation is much more vague and poorly defined.
the only stuff i know of that might help is functional reactive programming, which tries to connect interface implementation with the clean approach of fucntional languages. but i don't know enough to do any more than offer it as a google search term for others...
posted by andrew cooke at 4:39 PM on April 13, 2004
i don't think we know how to do ui well. not from a programming perspective. it's possible to get something that looks nice and works fairly well with lots of effort, but it doesn't scale well.
maybe it's just that i don't have the right knowledge - i'm not a ui designer (and i tend to try and avoid ui because i think it's too hard; i don't mind a challenge, but guaranteed disappointment is a turn-off) - but i don't see any approach that gives the kind of clean separation of concerns that you get with a good solution in other areas of programming.
for example: there are books and books on algorithms and data structures - they're full of maths and proofs and clear facts. in comparison, info on ui design and implementation is much more vague and poorly defined.
the only stuff i know of that might help is functional reactive programming, which tries to connect interface implementation with the clean approach of fucntional languages. but i don't know enough to do any more than offer it as a google search term for others...
posted by andrew cooke at 4:39 PM on April 13, 2004
So if anyone has any really good links about how to approach UI, especially in a web application context, please share!
Here, I'll give you the Big Secret to good UI. It's simple, actually.
Design something. Could be anything. Website, application, configuration tool, you get the idea. Fix it up until you think it's perfect and finished. Now, find someone who hasn't seen it before, and let them have at it. Don't help them out or give them hints. If they don't get it, or have a problem figuring something out, That's your fault. Not their's.
If you design a website and they tell you, "I couldn't find the link to the news section easily," the correct response should not be, "Well, you see, if you click on this, then that appears and you can see how obvious it really is..." The correct response is, "If you couldn't figure it out, then I did something wrong."
Too many designers fall in love with their "revolutionary idea" that's going to set the world aflame and get everyone talking about how brilliant they are. You have to be willing to throw your brilliant idea in the trash as soon as someone says, "I don't get it."
This is a hard lesson to learn, especially hard for designers, who tend to be artist-types who have probably been told from early childhood that "It's OK to be misunderstood -- look, Van Gogh and Edgar Allan Poe were misunderstood, and they were geniuses!" Yeah, broke geniuses.
So, the single best way to improve your design is to test it out on as many virgin eyes and computing experience levels as possible. You'll probably start to see patterns emerge and this will make your job easier in the future. Unfortunately, a lot of these patterns have already been figured out by some pretty big names (the elegant simplicity of Google, the tabbed configuration panels in Microsoft Windows, etc.)
posted by Civil_Disobedient at 5:10 PM on April 13, 2004 [1 favorite]
Here, I'll give you the Big Secret to good UI. It's simple, actually.
Design something. Could be anything. Website, application, configuration tool, you get the idea. Fix it up until you think it's perfect and finished. Now, find someone who hasn't seen it before, and let them have at it. Don't help them out or give them hints. If they don't get it, or have a problem figuring something out, That's your fault. Not their's.
If you design a website and they tell you, "I couldn't find the link to the news section easily," the correct response should not be, "Well, you see, if you click on this, then that appears and you can see how obvious it really is..." The correct response is, "If you couldn't figure it out, then I did something wrong."
Too many designers fall in love with their "revolutionary idea" that's going to set the world aflame and get everyone talking about how brilliant they are. You have to be willing to throw your brilliant idea in the trash as soon as someone says, "I don't get it."
This is a hard lesson to learn, especially hard for designers, who tend to be artist-types who have probably been told from early childhood that "It's OK to be misunderstood -- look, Van Gogh and Edgar Allan Poe were misunderstood, and they were geniuses!" Yeah, broke geniuses.
So, the single best way to improve your design is to test it out on as many virgin eyes and computing experience levels as possible. You'll probably start to see patterns emerge and this will make your job easier in the future. Unfortunately, a lot of these patterns have already been figured out by some pretty big names (the elegant simplicity of Google, the tabbed configuration panels in Microsoft Windows, etc.)
posted by Civil_Disobedient at 5:10 PM on April 13, 2004 [1 favorite]
The problem isn't simply bad UI design from the point of view of "where's the button...where's the scroll bar"... It's a fundamental problem with how UIs interact with the underlying system.
I've always been furious, for instance, with graphical X configuration utilities, like Mandrake's DrakX.
Allegedly, it lets you modify your graphics settings.
In reality, it's a script with a GUI front-end that generates XFree86 configration files.
Now there's a big difference here - what if I've installed the accelerated NVidia drivers? DrakX doesn't care! It will just go and generate the same old XFree86 config file it always has, because it doesn't check the file to see what the configuration really is. Instantly, I lose the ability to modify my display settings through a GUI because I choose to install a new video driver.
It's a common story all over Linux. Users demand GUI configuration. Geeks attempt to confront this by creating GUI-frontend-scripts to generate configuration files. But they haven't really answered the complaint, and it goes beyond simple bad interface design into the problem of the unordered tangle of Linux text configuration files.
It makes me mmmmad.
posted by Jimbob at 5:24 PM on April 13, 2004
I've always been furious, for instance, with graphical X configuration utilities, like Mandrake's DrakX.
Allegedly, it lets you modify your graphics settings.
In reality, it's a script with a GUI front-end that generates XFree86 configration files.
Now there's a big difference here - what if I've installed the accelerated NVidia drivers? DrakX doesn't care! It will just go and generate the same old XFree86 config file it always has, because it doesn't check the file to see what the configuration really is. Instantly, I lose the ability to modify my display settings through a GUI because I choose to install a new video driver.
It's a common story all over Linux. Users demand GUI configuration. Geeks attempt to confront this by creating GUI-frontend-scripts to generate configuration files. But they haven't really answered the complaint, and it goes beyond simple bad interface design into the problem of the unordered tangle of Linux text configuration files.
It makes me mmmmad.
posted by Jimbob at 5:24 PM on April 13, 2004
Good design isn't about getting morons to sit with programmers or about designing first and testing for usability later. You need to get typical users, preferably intelligent and articulate but adamantly not computer folk, deeply involved in the design process in the first place. Good UI design has nothing to do with designing for "Aunt Tillie" or for some other intellectually-challenged archetype: this is where otherwise highly capable software developers begin to go wrong in the first place. As soon as you assume that users are "stupid" in not seeing the system the same way you as a developer see it, you are already making that same basic mistake.
Users must be treated as equals in the design process. This is easier said than done, and many books and methods have been written on the subject. The main thing to keep in mind is that as soon as you think of the end user being in some way inferior to you as the programmer, you have lost the battle to create a truly universally usable interface.
posted by cbrody at 5:42 PM on April 13, 2004
Users must be treated as equals in the design process. This is easier said than done, and many books and methods have been written on the subject. The main thing to keep in mind is that as soon as you think of the end user being in some way inferior to you as the programmer, you have lost the battle to create a truly universally usable interface.
posted by cbrody at 5:42 PM on April 13, 2004
as soon as you think of the end user being in some way inferior to you as the programmer, you have lost the battle to create a truly universally usable interface.
I respectfully disagree. Computers are just analogous to every other aspect of our modern society that must deal with specialization: I don't care how a drug manufacturer makes a drug, I just want it to be painless and to work. If it comes in a gell-cap, I'll pay an extra buck. Everything about modern computer interfaces has tried to make things simple and analogous to things in everyday life. End users don't care about the 1s and 0s, don't care about the configuration files, they just would like to use the thing as a tool to get something else done. Designers throw "folders" and "files" at users because they know they don't want to read books about the intricacies of modern file structures.
Developers and end-users are two completely different beasts. Developers have the benefit of already knowing what the system is supposed to do. They forget what it's like to come into something with no prior knowledge of how to use it.
You know what web pages I like the best? The ones with loads of content and some reasonably-sized images to break up large paragraphs. No tables, no Javascript, just content. See, I've already figured out how to use my browser, I don't want to spend another hour trying to figure out another interface.
posted by Civil_Disobedient at 6:42 PM on April 13, 2004
I respectfully disagree. Computers are just analogous to every other aspect of our modern society that must deal with specialization: I don't care how a drug manufacturer makes a drug, I just want it to be painless and to work. If it comes in a gell-cap, I'll pay an extra buck. Everything about modern computer interfaces has tried to make things simple and analogous to things in everyday life. End users don't care about the 1s and 0s, don't care about the configuration files, they just would like to use the thing as a tool to get something else done. Designers throw "folders" and "files" at users because they know they don't want to read books about the intricacies of modern file structures.
Developers and end-users are two completely different beasts. Developers have the benefit of already knowing what the system is supposed to do. They forget what it's like to come into something with no prior knowledge of how to use it.
You know what web pages I like the best? The ones with loads of content and some reasonably-sized images to break up large paragraphs. No tables, no Javascript, just content. See, I've already figured out how to use my browser, I don't want to spend another hour trying to figure out another interface.
posted by Civil_Disobedient at 6:42 PM on April 13, 2004
Civil_Disobedient: There are a lot of open source projects out there that ignore user feedback, but the good ones listen to what users tell them (to the extent that that's possible -- sometimes ten users will give you twelve different and mutually conflicting suggestions about the same thing). I know the "listen to the users" secret. What I was looking for is anything that can help me when it's just me sitting in front of a blank editor thinking about the problem at hand. Right now, the method is to do my best and have some people use it, and see what wasn't right. I'd love to be able to get more right on the first try. Have you got any good "what to consider before you get to the users" type info? Is there any?
On a different note, frogs: You want a GUI for your webserver. On the other hand, I run two web clusters of linux servers, and I thank god that the apache configs are text files. I can securely ssh in to the machines to make changes over a simple, low-bandwidth text interface and change whatever I need to. I can do things like dump a bunch of config file chunks for different sites in a directory and have apache read all the configs on startup. There was a learning curve to all this stuff. But I guarantee you cannot make a GUI interface to apache that I would prefer to the simplicity of the text file configs.
This dosn't mean that I'm right and you're wrong, or vice versa. Just that we have different needs, and I don't think there is such a thing as an interface that would be perfect for both of us. I don't want my servers to assume I'm a moron, because I'm not. What I didn't know before, I eventually learned. I don't think "One Interface To Rule Them All" is always a good approach.
posted by rusty at 7:34 PM on April 13, 2004
On a different note, frogs: You want a GUI for your webserver. On the other hand, I run two web clusters of linux servers, and I thank god that the apache configs are text files. I can securely ssh in to the machines to make changes over a simple, low-bandwidth text interface and change whatever I need to. I can do things like dump a bunch of config file chunks for different sites in a directory and have apache read all the configs on startup. There was a learning curve to all this stuff. But I guarantee you cannot make a GUI interface to apache that I would prefer to the simplicity of the text file configs.
This dosn't mean that I'm right and you're wrong, or vice versa. Just that we have different needs, and I don't think there is such a thing as an interface that would be perfect for both of us. I don't want my servers to assume I'm a moron, because I'm not. What I didn't know before, I eventually learned. I don't think "One Interface To Rule Them All" is always a good approach.
posted by rusty at 7:34 PM on April 13, 2004
Developers have the benefit of already knowing what the system is supposed to do.
With greatest respect I think that's arrogant, and just plain wrong. If you already know what the system is supposed to do before having talked to a single person who is going to have to use the system, then you are not developing for anyone but yourself.
I'm not talking about basic things like using a mouse or selecting an item from a menu - I think it's taken for granted that there are only so many ways to interact with a computer using a WIMP GUI. Application software should be intuitive and easy to learn, no matter what the user's background or prior knowledge of the product.
Of course knowledge of a particular domain is something else entirely: a theoretical physicist might have problems understanding how to use a sequencer in the same way that a musician might have problems using an online mortgage calculator. But that's where the target market comes in: you have to design with the end-user in mind or you're creating in a vacuum. For example, when creating a web application you have to assume a certain level of competence, but you also need to take into account (as Civil_Disobedient rightly says) that no-one wants to have to learn a "new" interface simply to do business with you.
UI design is an art form, but only as far as architecture is also an art: both can better be thought of as an engineering disciplines that put the end user's needs before those of the designer.
posted by cbrody at 7:54 PM on April 13, 2004
With greatest respect I think that's arrogant, and just plain wrong. If you already know what the system is supposed to do before having talked to a single person who is going to have to use the system, then you are not developing for anyone but yourself.
I'm not talking about basic things like using a mouse or selecting an item from a menu - I think it's taken for granted that there are only so many ways to interact with a computer using a WIMP GUI. Application software should be intuitive and easy to learn, no matter what the user's background or prior knowledge of the product.
Of course knowledge of a particular domain is something else entirely: a theoretical physicist might have problems understanding how to use a sequencer in the same way that a musician might have problems using an online mortgage calculator. But that's where the target market comes in: you have to design with the end-user in mind or you're creating in a vacuum. For example, when creating a web application you have to assume a certain level of competence, but you also need to take into account (as Civil_Disobedient rightly says) that no-one wants to have to learn a "new" interface simply to do business with you.
UI design is an art form, but only as far as architecture is also an art: both can better be thought of as an engineering disciplines that put the end user's needs before those of the designer.
posted by cbrody at 7:54 PM on April 13, 2004
If you already know what the system is supposed to do before having talked to a single person who is going to have to use the system, then you are not developing for anyone but yourself.
Right. Getting back to the topic at hand, this is where open-source projects appear to fail before they start. The best open-source software has been tools and technologies developed by programmers and engineers for other programmers and engineers. rusty's experience (above) with Apache is a very good illustration of this. These projects' success is no accident: Programmers and engineers generally have a very good understanding of what other programmers and engineers want, the level of skill and willingness to learn that they possess and their expected cost/benefit considerations when invited to invest time in learning and implementing an improved tool.
When performing such development, the need to perform some form of user-experience analysis and design appears redundant, because the developers are the intended audience - consideration of user types and attributes is naturally inherent in development activity. Where open-source fails with respect to satisfying end users is when that same development approach is translated from the technical domain to some other. The old way of working is inadequate. There is no longer an inherent culture of end-user empathy amongst the development team.
Hence, many open source projects fail to satisfy users because user-empathy has been removed from development activities. Such projects remain unaware of this critical loss of context however, because they're not doing anything different to what they or others did beforewith a successful outcome .
posted by normy at 8:39 PM on April 13, 2004
Right. Getting back to the topic at hand, this is where open-source projects appear to fail before they start. The best open-source software has been tools and technologies developed by programmers and engineers for other programmers and engineers. rusty's experience (above) with Apache is a very good illustration of this. These projects' success is no accident: Programmers and engineers generally have a very good understanding of what other programmers and engineers want, the level of skill and willingness to learn that they possess and their expected cost/benefit considerations when invited to invest time in learning and implementing an improved tool.
When performing such development, the need to perform some form of user-experience analysis and design appears redundant, because the developers are the intended audience - consideration of user types and attributes is naturally inherent in development activity. Where open-source fails with respect to satisfying end users is when that same development approach is translated from the technical domain to some other. The old way of working is inadequate. There is no longer an inherent culture of end-user empathy amongst the development team.
Hence, many open source projects fail to satisfy users because user-empathy has been removed from development activities. Such projects remain unaware of this critical loss of context however, because they're not doing anything different to what they or others did beforewith a successful outcome .
posted by normy at 8:39 PM on April 13, 2004
FWIW, CUPS is a dream on the mac. If CUPS people read this, thanks. CUPS is the best. It's one of those rare software systems that makes computers excede your expectations.
posted by jeb at 11:56 PM on April 13, 2004
posted by jeb at 11:56 PM on April 13, 2004
normy: The best open-source software has been tools and technologies developed by programmers and engineers for other programmers and engineers. rusty's experience (above) with Apache is a very good illustration of this.
Hrm, I'm not certain if Apache is a good example here. The primary user population for Apache is not programmers and engineers. Another feature of Apache is that it is set up with reasonable defaults so that it just works. This is actually true with a number of other server software applications. I found myself having to activate BIND as a proxy, and was surprised that BIND on FreeBSD just works. In fact, I would argue that Appache is an example of how to do a file-based configuration right. The options are very well documented with minimal obscufatory vocabulary. And it just works out of the box. If you want a web server, you have one in 5 minutes.
I also don't feel that it is fair to lay this all down on the feet of Open Source production. Both cups and MS Word are designed with a whopping set of assumptions about what users want and need. I've probably wasted as much time trying to figure out basic Word annoyances. Nor is it fair to say that Open Source communities are not thinking about usability in terms of the end user.
posted by KirkJobSluder at 11:19 AM on April 14, 2004
Hrm, I'm not certain if Apache is a good example here. The primary user population for Apache is not programmers and engineers. Another feature of Apache is that it is set up with reasonable defaults so that it just works. This is actually true with a number of other server software applications. I found myself having to activate BIND as a proxy, and was surprised that BIND on FreeBSD just works. In fact, I would argue that Appache is an example of how to do a file-based configuration right. The options are very well documented with minimal obscufatory vocabulary. And it just works out of the box. If you want a web server, you have one in 5 minutes.
I also don't feel that it is fair to lay this all down on the feet of Open Source production. Both cups and MS Word are designed with a whopping set of assumptions about what users want and need. I've probably wasted as much time trying to figure out basic Word annoyances. Nor is it fair to say that Open Source communities are not thinking about usability in terms of the end user.
posted by KirkJobSluder at 11:19 AM on April 14, 2004
It's telling that Raymond lets us know how much of his article was written in "real time;" he took breaks from trying to figure out cups so he could write an essay about how hard it was for him to figure out cups.
I must have missed the part of the article where he emails the Linux Documentation Project or the cups developers and offerers to help them expand the documentation that they got paid nothing to write, on their own time.
If you consider yourself part of the free software movement, don't write an article about how snotty the programmers are, write an article about how to use cups, you self-indulgent piece of shit.
posted by bingo at 8:09 AM on April 16, 2004
I must have missed the part of the article where he emails the Linux Documentation Project or the cups developers and offerers to help them expand the documentation that they got paid nothing to write, on their own time.
If you consider yourself part of the free software movement, don't write an article about how snotty the programmers are, write an article about how to use cups, you self-indulgent piece of shit.
posted by bingo at 8:09 AM on April 16, 2004
« Older pfixin' pfor a pfight | Extra points for not using the word Monkeyfilter Newer »
This thread has been archived and is closed to new comments
posted by chrid at 1:42 PM on April 13, 2004