Slashdot Mirror
User Feedback and Open Source Development
Earl Shannon writes, "With the new release of Sendmail I was looking over Sendmail.net and
came across this essay called It's the User, Stupid. Author Mike Kuniavsky states a very important question if Linux wants to make inroads on the desktop as an open source solution. How can the open source development model obtain the necessary user feedback to development interfaces that the user will intuitively able to use?"
Unfortunately, intuitive seems to mean a Windows-like OS, for most purposes. Though I don't doubt that, through the sort of studies that Tog does, it's possible to develop truly intuitive OSs, that's not likely anytime soon.
No, what "intutive" really means is "like Windows." Having worked with all 3 major platforms for quite some time now, I've found that what most people really want is a Start button and Explorer as their OS. Disgusting, no?
Obviously, you and I aren't most people. That's why we're reading Slashdot. But trying to get your grandmother to use anything but Windows, which she's used twice, is going to scare her.
So that's how we do it, that's how we make an intuitive GUI. Imitate Windows.
Gosh, that's an awful thing to have to say.
This issue, and this article, have been raised on /. before. IIRC, the result was much heated debate . Wish /. was responsive enough today to let me get a search done. :)
:) Linux is, first and foremost, a hobbyists system. Then, it is a server-side OS. Then, and only then, it is an end-user workstation OS that looks pretty and holds your hand, and comes preconfigured out of the box.
In a nutshell, the point of the debate was: Who is Linux targetted at? The developers of Linux are the users of Linux - the users of Linux become the developers of Linux. This is the way it has been before the IPO of AllThingsLinux.com
I have to ask, has the intention of Linux changed? Is it no longer software of the people, by the people and for the people? Has it become a supplier-consumer relationship?
If it's still the former, then the developers are the users and vice versa, and it's a stupid argument. If the latter is true, and the developers are the Morlocks to the users Eloi, then what Linux is all about is dead.
Linux WAS about solving real problems. Performance, technical issues, doing things 'right' without market pressure. If the focus must shift to 'end-users', and to providing 'unwashed masses' with a comfortable experience, then that goes contrary to the spirit of Linux - at least as I see it.
Let them eat cake, and run Windows and MacOS, I say! If they want to use Linux, they'll have to learn regular expressions.
In fact, out of the box is exactly where this end-user convenience should come from. Let the people making money on Linux distros add that value. They're the ones who depend on a growing user base. "Hey you, in the red hat! Are you listening?"
The core community is it's own user base and doesn't seem to care too much about auto-configuration wizards and user-friendly dumbification. If they did, those features would be there by now. See how it works?
-- What you do today will cost you a day of your life.
I originally tried to put this in my own words, but I just couldn't do it any better than Jakob Nielson, so here's his take on this issue (his emphasis):
"The "paradox of the active user" is a concept introduced by John M. Carroll and Mary Beth Rosson (then at IBM, now at Virginia Tech) to explain a common observation in several user studies done at the IBM User Interface Institute in the early 1980s (later confirmed by many other studies, including my own): Users never read manuals but start using the software immediately. They are motivated to get started and to get their immediate task done: they don't care about the system as such and don't want to spend time up front on getting established, set up, or going through learning packages.
The "paradox of the active user" [PDF,66k] is a paradox because users would save time in the long term by taking some initial time to optimize the system and learn more about it. But that's not how people behave in the real world, so we cannot allow engineers to build products for an idealized rational user when real humans are irrational: we must design for the way users actually behave."
Source: http://www.useit.com/alertbox/ activeuserparadox.html
The paper is old, but still very relevant. It was written before Gooey Tarbabies achieved World Domination. I was really surprised to discover that many of my current user interface issues have actually been thoroughly documented and processes for (potentially) surmounting them outlined.
Why is it that since we've known about this for so long, so little apparent progress has been made?
My short 2bit answer is the evil upgrade treadmill - everybody is so busy preparing for and researching the Next Big Thing, they don't have time to refine and polish the tools already under our noses.
Some things are not intuitive. The only time a user interface is "intuitive" is when its model of what you want to do is the same as your model. Users do not share models very often, so we invent "common" approaches, but these simplified approaches *cannot* model the more-complicated tasks!
Frankly, a lot of the "desktop" market is people who would not be able to administer sendmail if it understood English, because they don't know *what they want it to do*. They just sort of want, you know, the thing where the other thing isn't done unless it's supposed'ta.
This can't be resolved by making interfaces intuitive, any more than we can make graduate-level math accessible to children by using "intuitive" words and pictures to describe it.
Eventually, we have to accept that part of what we want to do is educate the users a bit more, so they can figure out what they want to do; at this point, the interface can be designed for efficiency.
Expert-friendly is the way to go.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
He's not saying that we need to imitate windows to create a better GUI; he's saying that that is what we are doing already.
To provide something new, we need to have a more direct link to what the users of a particular application want. This is something that the commercial houses can and do spend a lot of money on (Aqua, anyone) but in the OSS realm, so much effort is spent in just making the thing run, or better yet, play nice with others (not that there's anything wrong with that), that any UI improvements are an afterthough at best.
We are in a position to take the UI paradigm in any direction we want, but this opportunity is raerely being seized.
At least, that's what I got out of it. Anyone else?
--sugarman--
I've seen this a lot around here, mistaking what is easy for the average technical /. reader for the average user. Linux is very well designed for its current user base. Its various UIs are far better than Windows for its current user base.
But what people really need to have hammered into them is that this is not at all the same as being well designed for the average person. For me, you and most other Linux users, being able to just edit the config file with vi instead of wading through a bunch of menus is a dream come true. For the average person, this is hell.
There is no one perfect UI. There are UIs that are good for techies and UIs that are good for nontechies. Don't expect them to be at all the same.
The "Open Source" model is probably the supreme way of getting feedback from the average technical user. This does not mean that it is at all good at getting feedback from the average nontechnical user.
The cake is a pie
Firstly, "intuitive" is a slippery word. There's "intuitive for power users", "intuitive for somewhat experienced users", and "intuitive for newbies". Some would say the last category is the empty set.
Metaphors are the key. Read John Lawler's 1987 lecture "Metaphors we compute by" for a quick intro on metaphor and metaphors in computing. The situation has unfortunately changed very little in the last 13 years. George Lakoff's book "Philosophy in the Flesh" shows how metaphors actually are the basic working units of the mind, and that all basic metaphors are based on sensory-motor concepts - in fact, sensory-motor neurons very probably do double duty as metaphor processors.
So, as long as one bases GUI metaphors on basic sensory-motor stuff - things like "time is space-like" (progress bars), "nearer means on top" (overlapping windows), and so forth - you have some chance of being more newbie-intuitive. I've used a prototype ancient GUI where scrollbars worked the other way around; the thumb moved down to scroll up for some reason the designer considered compelling, and it was pure hell to use. Needless to say it didn't survive.
Now, something I've noticed in most (thankfully not all) replies here is a restricted understanding of what a GUI should do. Yes, having icons represent files is useful; installing by running a single program and marking off some options is useful; using menus is often useful. But that's only a small part.
I've released an application for the Mac OS recently. As long as one uses the standard system calls, one gets the expected GUI functionality for basic items - that is, menus work like a Mac user thinks they should, windows drag, roll up, close and whatever. But I spent very little time on that - thanks to a neat C++ framework called PowerPlant - and spent much time making sure other things worked as Mac users are used to.
For instance, placement of the exact hot spot in cursors is important. Shift-click selection of long sections of text is important. Exact timing and graphical progression of drag-and-drop is important. Wording, defaults and back-out options in dialog boxes, sound cues, selection behavior - the list is very long. And the extra time spent on subtleties was rewarded by a five-star review where the reviewer said "I love using this program, but it's often hard to say why unless I watch very closely".
When I'm using CAD software I'm often forced to use Windows NT, and frankly, it's terrible. People argument there are Microsoft UI guidelines, but it seems most people either don't know them or think they're unimportant. For instance, in the PCB layout program I'm using right now, if you select a library component to place on the layout, you select the component from a list - OK, the cursor changes to a translucent image of the component - also OK, but if you want to click on the scroll bar to place the component somewhere else, the component is placed _under_ the scroll bar with no visual indication that the scroll bars are inactive! If you click on a tool palette the component is placed under the palette! If people don't think this sort of flagrant misbehavior is important, are they likely to worry about more subtle things? No way...
So, what the original article says about "skins" being just skin deep is very accurate. Most Linux programmers seem naturally disdainful of graphic interfaces and therefore are slapdash in implementing one. And reaching consensus among a large group about any particular GUI feature is nearly impossible. This is definitely a field where the "absolute dictator" method is the only one which may work - granted it may also fail spectacularly.
The point of OSS (to me) was never to make it easier for anyone to use. It's to make it easier for you to use.
Is there a difference? You bet!
Windows 98 has to be written to the lowest common denomonator of user. Limit configurability and leave that to the programmers. It made it easy for anyone to walk up and use.
OSS (take GNOME, which I'm using now) is highly configrable. My bottom panel is probably guaranteed to not look like anyone else's, and if someone else walked up and used my machine, they'd be lost trying to figure it all out. Heck, people get messed up enough since I have "focus follows mouse" and "auto-raise" on.
Does this make OSS harder to use? There's a learning curve to figure out the interface, but not a whole lot. The concepts between Windows 98 and GNOME are similar, which were mostly developed 20 years ago.
Take another fun OSS example - Emacs. There's a steep learning curve, but those that get past it swear by it and use nothing else. It's probably a dismal failure when looked at in a general usability standpoint, but for each person that customized Emacs to work the way they do, it's a success.
-- Ever notice that fast-burning fuse looks exactly the same as slow-burning fuse? I didn't... (Edgar Montrose)
So intuitive, in fact, that that should read "you and me ."
Chinese is a wonderful language; the grammar is amazingly simple and easy to master. There are exactly three pronouns (four if you're reading instead of speaking) and there is no concept of tense at all. I studied it for three years in high school, and although I've forgotten most of the words, I can still remember most of the grammatical rules.
OK, so what does this have to do with designing UI's? The answer is that, IMO, UI's need to be more like Chinese. They need to be simple and have easy, unalterable rules that exist in ALL situations. Apple was very good at this. Microsoft never was. X interfaces are absolutely awful. Apps written in different toolkits, or in raw X all look different, there is no standardization of interface items, control keys, etc. The Apple Human Interface Guidelines (sorry, no URL handy) were revolutionary not only because they described how something should look (only one widget API) but also how it should feel. i.e., you can expect this widget to ALWAYS behave the same way. This is what makes MacOS intuitive, IMO, and what makes learning MacOS apps so easy. (except for Microsoft MacOS apps, since they've tried, and failed miserably, to simply put their abominable UI on the Mac desktop.)
So now that I'm done rambling, I'm not saying we should immitate MacOS - I'm saying that in order to be intuitive, there needs to be standards. The problem, of course, is that users of Open Source projects generally like to have choices. If I want to write a graphical app with Qt instead of gtk, I should be able to. If I want to use a set of nonsensical, inconsistent grammatical constructs like English instead of Chinese, I should be able to. The answer here, IMO, is that Unix OS's are not for the casual user. It was never intended that way, and I think we're kidding ourselves if we think we can make it useable for regular people.
Just my $0.04.
...ahem...
Command line power
yet some prefer point-and-click
What's intuitive?
.. or isn't it a bit ironic that an article about user-friendliness is hosted on the Web site for Sendmail? Is this the same Sendmail whose configuration file often looks like incoherent line noise? A friend of mine, having once examined my sendmail.cf, commented that it looked like I had written it by pounding my fists randomly on the keyboard. I simply smiled knowingly and nodded, too ashamed to admit that that was exactly how I had configured it ..
What has happened is that Windows has become part of peoples' learned expectations.
Much as with English, people have learned about its warts and aspects of non-intuitiveness, and have figured out how to work around them.
If something is truly intuitive, this means that there is no learning process required. The thing in question simply works the way people expect.
UNIX has the merit that it is a simple enough computer system that some people can get a sufficiently accurate model of its operation so that it becomes possible to predict what it will do.
In contrast, as soon as you strip the veneer of "learned things about its behaviour" off of Windows, it's a richly complex system whose behaviour is much more difficult to predict. (The lack of source code or other disclosures don't help either...)
The above approach to "intuiting" about Windows and UNIX take a rather different tack than the usual, assuming that the individual will actually try to deeply understand the system. It replaces the "black box" with one that is expected to be understood.
Rather unlike the usual model of trying to know nothing about what is going on behind the curtain...
If you're not part of the solution, you're part of the precipitate.
This is really the oldest problem in the free software (Open Source/label of choice) community. There are authors that elicit and get feedback, but they are ususally getting feedback from other programmers, so it's just an inbred feedback loop.
People growl at the thought of having to edit a text file to make an adjustment or configuration. Geeks say "Awesome - text file" and whine to people to just learn how to do it.
Teching the masses is not the point and will never be the point. The masses will not learn and any software that is predicated on a painful interface will be opverthrown by software that is pretty and easy to use.
It's not what any of us wants to hear, that free software utterly fails to companies like Microsoft that spends millions of dollars on research with people who are not geeks, who are not programmers, who are not even proficient with computers.
Money is not the point. research, forethought, and feedback is the point. There is reason that Apple and Microsft have fixed UI models. They recognized that the biggest weakness of most programmers is intuitive UI design.
Programmers and geeks as a whole are extremely intuitive people, and that intuition allows us to make tremendous leaps of the non-obvious. Most users are not capable of these tremendous leaps and fail to understand. These users are not stupid or even lacking in intuition. One component of intuition is past experience, and if they have not spent a long time around computers then they do not have the necessary reference material.
There are UI guides out there, and there have been some efforts by the GUI people to get coders to follow them, but we all know that they are herding cats because we won't follow anything that somebody else is going to impose. <sarcasm> I don't need those frigging kernel patches that king linus and prince alan keep trying to shove down my throat.
To get back on subject. If we really want to take over the universe (duh) we are going to have to figure out how to make software that is easy to use, friendly, and intuitive to -non-computer users. There is no compromise.
Thank you Redhat, Corel, and all of other distributors that have gone to great lengths to make is easier to install Linux. I mean there are tools around now so that I don't have to manually program my monitors frequencies into XF86config!
enjoy,
chris
-- I need more coffee. It's Monday. There is no such thing as enough coffee on a Monday.
Am I the only one tired by titles of 'It's [whatever], stupid'? This always sounds to me like a somewhat veiled attempt from the author at placing themselves above the reader from the get-go, by claiming they have such a clever bit of information that the reader should feel 'stupid' for not knowing it.
More on topic, I have to say there probably isn't such a thing as an intuitive control. If you think, for instance, that a mouse is an intuitive device, you should see 80 year-olds who never touched a computer before try to figure them out.
Rather than considering so-called 'intuitive' controls, the goal should be to develop methods which are built upon existing and well-known ones. Ultimately, nothing is intuitive in controlling a computer (unless we developped Herbert's genetic memory in the last 50 years), but rather part of a slow learning process.
So don't shoot for intuitive; shoot for ease of learning. Mounting and umounting a drive, for instance, isn't intuitive to a Windows user. But it's easy to learn, and once you catch the principle, it's acquired.
Is that more on topic?
A common misconception is that Linux GUI's are hard too use. For what the average user does, this is a very false statement.
.ini's are created, and the monster known as the registry is altered.
Most people use only 3-5 of the icons on their Windows desktop, without ever delving into any of the menus. AOL, Word, Internet Explorer is all they know.
For most people, it's all they need to know.
So when we talk of usability of Linux GUIs, there is nothing "hard" about starting Linux programs from the GUI. What gives average users trouble is installing the actual program.
For Windows most installers automatically put the icons on the desktop and the user never has to worry about fiddling with any settings.
There is an immense number of technical things going on with the installation of a Windows program, but the user never ever sees it. DLLs are copied,
The same should also work for installing Linux programs. Install scripts which hide the ugly technical stuff from the user, place an icon on the desktop, and thats all.
Instead of a "better" GUI, Linux needs a better install procedere which lets the user click and go.
One possible solution (and feel free to rip this apart as unworkable): Create a consensus document that sets forth interface guidelines, like Apple has for Mac developers. Not to create a rigid dogma, but to provide a starting point for interface design, so that one person or group isn't starting from one end of the spectrum while another group starts at the other. To create a common language for UI design. As for user feed back, well, a web based feedback forum, like /. boards, could allow end users to comment on interface features. This problem is not one that is insurmountable. It simply needs to be recognized.