Linux/UNIX Usability Research

st. augustine writes "A group of researchers at the University of Michigan School of Information has started a project called the Linux/UNIX Independent Group for Usability Information. Their goal: "to couple the power of UNIX with user interfaces that are consciously designed to allow novices to become experts without removing any of the existing functionality." They look serious. " Check out the Salon article that ran earlier today-they're mentioned in there as well. I've actually talked with those folks as well-they're smart cookies.

Comments

Peer review for user interfaces

[Anonymous Coward]

Where I think the LUIGUI people could best serve Linux OSS developers is in providing peer review for user interfaces. I was thinking of tackling a Linux project with GUI this summer, but I'm no expert on user-interface design. Getting reviewed by the people at LUIGUI could really help me and others put that necessary 'polish' on an app before it is released to the public. Without that polish, people won't start using the app.

Well, them's my thoughts anyhow.

Linux usability

[raph]

A couple of comments here. I'm a Gnome developer, and in the Gnome community, there is a serious focus on making Linux truly usable. We talk of the "mom test," i.e. your mom being able to get useful work done with the software.

Real software usability goes deeper than just interactions with GUI dialogs and so on. For experts, Linux is much more usable than the consumer OS's because it is much more stable, more transparent (less things are hidden under the candy shell of the GUI), and has a broader collection of powerful tools. The challenge is going to be preserving this kind of usability while also making Linux more accessible to non-expert users.

One argument that's often made is that Linux suits the needs of expert users because it was designed by expert users. Since we are people who don't mind learning how things really work, and prefer the tools to be powerful once we do learn them, that's reflected in what we build. The argument usually goes on to say that since we don't want pretty but shallow, easy to learn but limited tools, we will never end up building these things for Linux novices.

This argument misses one important point, in my opinion. Even if you accept that the intellectual challenge of building usable software isn't by itself enough to keep the effort going, this argument pretty much assumes that the world is split up into hacker types and lots of isolated people who don't understand their computers. But this is not the full story. Many, many Linux people are sysadmins for a large number of not-so-computer-savvy users. Let me tell you something, Linux people in Windows sysadmin jobs hate having to do several fresh reinstalls of Windows per day per few hundred machines just because the registry gets wedged and there's no way to figure out how to fix it. Many of them would like nothing better than to have Linux become a viable desktop system so they'd be able to at least work with systems they don't hate.

It may well be that these hardy souls turn out to be the vast army that works to make free software usable. Once Linux starts going into the desktop in sysadminned environments, the channels are in place to collect user feedback, and also to do something about it. If such-and-such feature is confusing to users, then the admins will hear about it. It's probably easier in many cases to just fix it than keep dealing with the problem reports, and certainly a hell of a lot more fun.

Don't underestimate the dramatic strides already made in usability by the Linux community. When I first started working with Linux about six years ago, the usual way to install new software was to check the README, edit the Makefile, more often than not fix a few #includes or function prototypes, then run a series of make commands. These days we have RPM packages and so on, but we also have ./configure; make. To me, the autoconf system is a classic example of "deep usability" as opposed to the surface kind.

In summary, I think we're just going to keep on going until we get there.

Yes, but is it ehe Right Thing?

[Signal 11]

For me, this isn't a question, but an answer, and the wrong one at that. Let me explain.
Right now, linux is only really useful to hackers/programmers/geeks. The reason is, only hackers, programmers, and geeks use it. There is right now a push underway to add another group - the average user. But are we certain we want to traverse this path?
Microsoft has shown that when you combine simplicity with stupidity, you get unstable programs and operating systems. The users demand more and more - they don't care whether code looks beautiful, they care about themes and cool sounds and new mouse pointers and talking paper clips. What's the net result? Software engineering.

Software engineering is built on one principal - "build it to spec". The spec in this case is, make it easy enough for a dummy to use. Well, it does that. It's also woefully unstable.

Now, the UNIX heritage is a different story. It's Computer science. An idea is presented, evaluated by it's peers, and brought to implementation if it's agreed it's the best solution at the time. The net result is - progress is slower, but the foundation is much more stable. You have a powerful set of versatile utilities you can use for a variety of tasks - grep, awk, named pipes. Software engineering, however, does not have "versatility" listed in the spec, nor should it - it's built to order. One goal, one purpose, one solution.

Before we invite the average user into the fold, we should ask ourselves - are we being impatient? Let's show them what computer science can do, and avoid computer engineering.



--

Science, engineering and programming.

[Grenamier]

Computer science has always appealed to me because I like things that blend elements of different disciplines into useful things. CompSci itself is a great blend of science, engineering, and mathematics in varying proportions depending on the problem you're looking at. The main products of computer science are abstract though, things like algorithms, proofs and theory...not operating systems or wordprocessors.

Software engineering applies principles from computer science to the problem of building real software, which is implemented by programmers. Scientists, engineers and programmers all have a hand in the software business, the way an engineer might take ideas from chemistry and physics to design a good bridge which is built by construction workers.

Computer science isn't really interested in creating actual software products (as well it shouldn't be). Saying that "computer engineers" should step aside and let computer scientists do their thing is like telling a civil engineer to take a hike so physicists can show them how to build an overpass. Well, that's not what they do (I just imagined a white-haired physicist in a lab coat mixing cement and cracked up.. :)

I don't think it's fair to blame all of the problems of software completely on software engineering. I think the engineering principles get throw out the window a lot when companies decide they don't want to bother with it anymore. Also, engineering can have versatility if it's decided that versatility is wanted in a project...it's all part of defining the "spec". Bad marketing-driven design can lead to bad specs that include talking paperclips and the like, but good design with clear goals can lead to good specs and good products.

Again, computer science, software engineering and programming are all interrelated, and good software is the result of mixing the best of each. Unfairly denying any one of the three leads to bad software.