Making Linux Easy With Eazel's Andy Hertzfeld

Make no mistake. Andy Hertzfeld, Eazel developer and Macintosh forefather, is an Open Source zealot. Forged in the fires of Steve Jobs and Bandley 3, Andy's leading the team to build a kinder, gentler interface for our favorite operating system. I got the opportunity to speak to Andy last week, and I learned a lot about the challenges and victories of thinking different with Linux.

Slashdot: Tell us what you're doing now, and how it differs from your work at Bandley 3.

Andy: What's similar about it is we're working on another revolution, trying to take usability to the next level -- it's different in that we have the network now. With the Macintosh, we were able to solve a different class of usability problems, but we really weren't able to get at some fundamental issues of system management and robustness. Now, with the network, it gives us the ability to address those.

Slashdot: How is it, working on a hyped-up technologically advanced version of what you've done in the past?

Andy: I don't know if that's really true or not. There's a level of it that's similar, but it is twenty years later, and the possibilities are vastly different. Sometimes I stop and think about when I was working on the Macintosh, it seemed like 128k was a lot of memory, because we were initially trying to fit everything into 64k. Nowadays, 128k is lost in the noise, it's a rounding error. There are possibilities to do so much more than we ever could before. On the other hand, the original Mac prized simplicity, and some of that simplicity has been lost. The Mac has gone, in certain respects, downhill on the ease-of-use curve over the years, and part of that is the natural evolution of a system to order to fulfill the complex and varied needs of it's users. There's just a tendency in the world toward complexity. On the other hand, one of the things distressing me is the lack of innovation over time. Just your very question indicates that even though the hardware now is thousands of times more capable than what we had when we were working on the original Mac, the software paradigms have not advanced in the same way.

Slashdot: The whole Linux craze, you've got Windows, and 'Ooh, look at this new fighter on the horizon.' But it's UNIX.

Andy: Well, but the new fighter on the horizon, from my point of view, is not so much that it's UNIX, but it's a new and better business model, a new and better paradigm for developing software, and that's really exciting.

Slashdot: How did you get involved in the Open Source/Free Software movement?

Andy: When I took off from General Magic in 1996, the Internet was exploding, and I just wanted to learn about it. So, I set up an ISP at my house, got a T1 line, and set everything up myself so I could learn about how things are put together. But also, to justify that T1 line, I started doing pro bono projects of various kinds. I was happily puttering along with those kinds of projects when in January of 1998, the Mozilla announcement caught my attention in a big way. That led me to Eric Raymond's papers, and an epiphany, you know, a moment of insight, where I realized that it solved the structural problems in the software industry. I'd been depressed about the lack of innovation and the stagnation and the anti-user framework that the software industry had fallen into. The idealism of the computer industry had led to this cul-de-sac, where no one was really happy with their machines. The basic problem is that the applications want to converge on a common system infrastructure. That's what's good for the applications, good for the users, good for everyone, to be built on top of a common system software base. The problem is that when that common system software base is controlled by a proprietary interest, the company that controls it necessarily becomes anti-innovative. In order to maintain their control, they are at odds with the users and the developers. I had realized that, and I didn't see a way out until reading Eric Raymond's papers, and learning about the successes of Linux, Apache, et cetera. I saw that if that common infrastructure could be owned by the community on something like the GPL, the problems are solved. You can have a healthy software industry, where anyone who wants to innovate has equal footing. That was really exciting to me, and I saw it as a call to action. The first step was converting my Web servers over to Linux, I started installing all sorts of software, playing around to see the state of usability. The first one I did was KDE, about six months later, I started exploring Gnome, and just getting up to speed in the space which took about six months of just exploring around, and another six months actually programming on gtk to understand it's strengths and limitations. Around the very beginning of 1999, Bart Decren was the founder of an organization in East Palo Alto called 'Plugged In,' which was one of the few organizations trying to address the digital divide, trying to fix the paradox that right next to Palo Alto, one of the most affluent and high-tech communities in the nation, was this little place called East Palo Alto, which was one of the least affluent and high-tech places in the nation and Bart started an organization to try to bring technology to them. So, I supported Bart in those efforts over the years, and he was one of the people I respected the most. He had all the qualities of a classic entrepreneur, but he was applying them for public good instead of his own private interests. So, when Bart came to me and said he had run his course at Plugged In and was looking for something new to do and just wanted my advice, I told him about my excitement about free software. My plan was not to start a company, it was to start an Open Source project. Bart surprised me when he came back to me, a month or two later, and he said, 'I figured out what I want to do, I want to start an Open Source company with you.' That was around April of 1999, so we started putting together a plan, and what really made Eazel happen was the realization that in order to create ease-of-use on the desktop in a broad way, we needed something to fund it. We wanted to do Free software, but we needed some sort of business model.

Slashdot: Someone's gotta pay the bills.

Andy: Yeah, so the real 'eureka' moment was when we realized that the GUI is only part of the problem. The real problem vexing users is system management, as well as lack of coverage on the GUI, and lack of fit-and-finish and all of that, as well as the lack of innovation. We had ideas for years that have just not made their way into the main platforms because things had stagnated. Anyway, the system management problem seemed to be the real opportunity that it would take a company to address, and it could have a potential business model behind it because of the ongoing nature of system management. What needed to be done was to create a service that could manage people's systems for them, and that we could charge people a subscription-based fee for and use that revenue to fund our efforts at making the GUI really great on the desktop. So, that's what happened. That all came together in the summer of last year, we got an office in August, or early September.

Slashdot: Tell us about the technical aspects of what you're doing. I don't know how much time you're spending in front of a compiler everyday.

Andy: Oh, I'm in there programming every day and every night, like I always do.

Slashdot: Well, tell us what you did this morning.

Andy: Well, the very first thing I do when I come into work after I put my backpack down is to go get a Diet Coke. Usually, I read the Web, I read my E-mail. The first thing I did this morning was work on our test database. We're using Bugzilla to manage all the various tests that need to be done with the project, so I go over that to close some out from the previous night, write some new ones, and then look over which ones I should work on today. Most recently I've been working on what I call the 'novice home' directory, which is the place where novice users go and there's a nice set of links for them to access the functionality of the program.

Slashdot: Tell us what excites you about Eazel.

Andy: One of the really exciting things to me about Eazel is the great team that we've built and are continuing to build here. One of the very best things is getting to work with Bud Tribble again, who was my boss on the original Macintosh project.

Slashdot: The original Macintosh project is usually defined as a cult of personality led by Steve Jobs.

Andy: Well, it varied over time. The Mac group got a reputation for being really spoiled, but that was in the very late stages of the project. The Mac team was paid less than the average people working at Apple initially, because we were pretty young and out of the mainstream. We had a tiny little office above a gas station, that's the place where the Mac project really took root, we called it Texaco Towers, and we weren't spoiled at all really, compared to the rest of Apple. In mid-83, we moved into a fancy building, then they put the piano in ...

Slashdot: You had the piano, you had Defender ...

Andy: Yeah, Defender was actually partially due to me. Burl loved it. Burl was the hardware designer of the Macintosh, and he just loved Defender. We always used to go to Cicero's Pizza, which was across the street, to play Defender in the afternoon. When we had the opportunity to buy a Defender game, we sprung for it. Joust was the other video game we had there.

Slashdot: How closely are you working with Helix Code, and how does that affect the hacking you do everyday?

Andy: Well, I'm not sure it affects the hacking we do every day very much, but we closely coordinate with them to make sure that the Gnome platform is coherent, and we try to avoid reduplication of efforts, so we have a process where the folks at Eazel have a conference call with Miguel and Nat usually every other week. It's really fun. We almost became one company last summer. We had a lot of natural synergies, but there were enough differences that we decided to go separate ways, but we consider ourselves, I think both sides consider the companies to be siblings, so we each try to help each other wherever we can.

Slashdot: How much of your original Apple Macintosh design influence is finding its way into Eazel?

Andy: What I would say is that our design values have remained pretty consistent.What we think is important is the same. Essentially, making the user happy. Bill Atkinson, who is really the person I learned the most from on how to do good user interface, his one rule of user interface design is 'make the user happy.' What you do is put yourself in the shoes of the user, look through their eyes, and try to make things work from their perspective. That being said, one of the things we didn't know how to do on the Macintosh, that we learned subsequently, is that it's very important to user test. So, to make usable software, you have to take your best shot with your own empathy with the user, seeing the way the user sees, but then you have to test that against real users. You put them down in front of it with a video camera running, and you see where they 'get it' and where they don't.

Slashdot: When a wirehead designs an interface for wireheads, that's fine. The Linux command line works fine for wireheads. For that reason, it's why the popular Linux interfaces don't work well with people coming right from Windows.

Andy: One of the big problems in terms of usability and Open Source software is that no systematic user testing has ever been done. That's one of the things we're trying to change at Eazel.

The personal computer has come a long way since 1984. Microsoft has a vast marketshare of the desktop computer market, and most people are content with machines that don't perform nearly as well as they could. With new ideology and a team of experienced developers, Eazel is helping to build something that Open Source and Free Software advocates have been waiting for. A computer industry for the rest of us.

Comments

Re:Interface Testing

[jacoplane]

I agree.

If anyone's interested in the theory behind usability, I recommend this book on Human Computer Interaction as an introduction.

Also, here are some web-sites I found useful:

- Cooper design
Excellent collection of articles, case studies and, for students who want bullet-point summaries for ease of recall, a nice list of HCI design axioms. See in particular http://www.cooper.com/design/ where there is a series of articles, including one entitled "The myth of metaphor". Cooper is also the author of two excellent books on interface design.

- Ask Tog Design
Bruce "Tog" Tognazzini developed the first version of the Apple Human Interface Guidelines in 1978, moved to Sun, and is currently lead designer at Healtheon. He has published two excellent books on interface and software design and at this web site, he answers questions and discusses interface issues with wit and insight.

- Jacob Nielsen's website
Nielsen produces a bi-weekly column on web usability and has also just published a book called Designing Web Usability: The Practice of Simplicity which is getting rave reviews. He is widely regarded as a leader in the field of web site design and usability testing.

- Interface Hall of Shame
An excellent collection of scathing but accurate reviews of user interface disasters of one sort or another. The ultimate depressing experience for any interface designer must be to end up here.

- HCI Reading List
If you want an exhaustive list of HCI reading materials, this is a good place to look. It is reasonably up-to-date (Feb 98) and has useful comments on the majority of textbooks in this area.

- University of Maryland Human-Computer Interaction Lab
The Human-Computer Interaction Lab (HCIL) at the University of Maryland conducts research on advanced user interfaces and their development processes. They study areas such as new approaches to information visualization, interfaces for digital libraries, multimedia resources for learning communities, zooming user interfaces (ZUIs), technology design methods with and for children, and instruments for evaluating user interface technologies. The director is Ben Schneiderman, author of the book "Designing the user interface".

Go Eazel!

[Junks Jerzey]

Once again, I see at least one legitimate response claiming that Linux should remain difficult to use, as it keeps away people without enough knowledge. There's one fundamental flaw to this line of thinking:

It's also keeping away people that *have* enough knowledge.

I've done my share of assembly coding. I spend my day job immersed in C++ code. I've used UNIX as my primary operating system on the job. I've written tens of thousands of lines of production code using vi on a Sun workstation. I also have both Windows and Linux installed on my machine at home, and, more often than not, I find myself using Windows.

Most of the reason is that Linux is just too tempermental and fussy. I admire the work that's gone into the kernel, but twiddling with Xwindows settings and getting my video card to work properly and having to deal with weird X cut and paste standards is just too much. And there are little things no one thinks about, too, like having to login as root in order to shut down, or remembering how to set it up so any user can shut down. Crusty.

Yes, you can respond with "You dolt! Here's how you can get around that problem!". But the bottom line is that some people have gotten tired of the attitude that getting to play 1970s system administrator is a wonderful thing. Some people don't mind, like people who passionately hate Microsoft and love to start email campaigns about getting game ABC ported over, and people who equate snagging MP3s and constantly upgrading different parts of their systems with "using a computer." It's almost cultish how these people will deny that Linux is hard to use. Get over it!

Interview suggestions

[gammatron]

It would be nice if you guys could do an interview with someone where you get to ask you questions, like this one, and in addition you have user-submitted questions. If I were you I'd ask your questions first, which would let you get the obvious stuff out of the way, and would also give us a chance to ask questions based on the interviewee's answers.


--

No clue whatsoever.

[be-fan]

Half you people have no clue whatsoever about what makes Windows easy to use. People could care less if the Windows interface is simple, or intuitive. It's easy to use because everyone uses it! The vast majority of people with any semblance of computer background are used to windows. Thus, KDE 1.x is easy mainly because it seems to be a Windows clone. Then you have the segment of the market that is totally new to computers. In that case, UNIX is way out of their ballpark. Sure they can wordprocess or whatever once everything is set up, but not everyone has a sysadmin. It is irrelevant on how easy to use the interface is in most cases. What matters is how easy to use the system is as a whole. Take something simple as adding new fonts. Even iMac people can do it, just drag it into the directory. In Linux, you have to put it into the directory, rerun mkfdir, do cp fonts.dir fonts.scale, and if your adding a truetype font, go to XF86Config and change the fontpath. Or take the example of somebody getting DSL or such. People aren't stupid, at least 50% of users can handle clicking on preferences and changing their IP and gateway. Would you like to walk the same user through doing that in Linux?

Obvious answers to ease of use

[Vanders]

If you want to make Linux easier to use, there are some pretty obvious things that could be done straight away:

1. Seperate UI designers from the hackers. Hackers make interfaces for hackers. Joe A. User doesn't want to use a hacker interface.

2. Integrate X more for those who want it. Ask yourself this, how do you change the display settings in X? How do you change the display settings in Windows/Mac OS? Which is easier for Joe A. User to do?

3. Make the documentation easier to read. Avoid acronyms, hacker-ish speak, obscure references, in jokes etc. etc. Joe A. User doesn't want to slog through a load of unrelated documentation to find what he needs.

4. Standardise. Want help on a command program? Is it prog -h, prog --help, or just prog? Wanna guess? Joe A. User doesn't.

5. Instalation & configuartion. Most programs are either source & a makefile, or an RPM/Deb. Some arn't, and use non standard installation routines. Stop it. Try to keep the config files in one standard place (/etc for example).

I'm sure there are more, these are the most obvious. Work on these first, then shine it all up nice & purdy. Remember, Joe A. User will still use Windows, if it's easier to use.

Interface Testing

[n8willis]

Man, am I glad to see that Eazel is concerned with actually testing their products with real users. This is something I give dearly for other people to do. Take NaN for instance: Blender is a great program, but it's interface is mind-bogglingly indecipherable.

And every time someone (for instance certain DE teams) talks of copying the interface of a successful program to use as the starting point for their OSS version, I have to roll my eyes. What for? Do we think that the UI teams at Microsoft and Adobe are infallible?

I mean, take a look at the tool icons in Photoshop: half of them are references to wet darkroom printing, something that in a few years it will be nigh-impossible to find experience with among their customers. A little testing would reveal in a matter of minutes that the majority of Photoshop users don't know why there are two tools shaped like a human hand, and two tools that look like magnifying glasses, nor why one of the hands is labelled "Burn" and one of the magnifying glasses "Dodge."

And don't get me started on the 30,000 tiny buttons sitting along the toolbar(s) in MS Word. If it takes a "tooltip" to explain what the icon represents, then the icon is a failure.

Last week's discussion about how programmers don't make good UI designers could take a lesson from this: if all else fails, you test it and see what works. That isn't rocket science. I happen to believe that the major impediment to good interface design in Open Source software isn't an inherent incapacity in the programmer mindset, or a matter of different "personality types", but simply not remembering to think about the interface. Two chapters into Norman's The Design of Everyday Things will convince even the most self-depreciating hacker among us that he already knows a lot about interface design, he just doesn't know that he knows. You're a user every day, after all.

Nate

All GUI's suck. A lot.

[delmoi]

A while ago, someone here posted a link to an interview with Douglas Egglebart (I'm sorry, there's no way I'm going to be spelling his name right), the man who came up with the GUI. (A long with a little thing called Hypertext, I believe). To solve a problem, he also invented the mouse. A long with another device, a one handed keyboard.

From the tone of the article, it seemed almost that he was pissed that it had taken so long for his ideas to become reality. When Job's showed him an early Macintosh interface, he said he was upset that it didn't have networking, one of the key components of Egglebart's vision.

One other thing that the story mentioned was the computer he ran at home. It wasn't a Mac, or a Windows box, or even a Linux or other UNIX. He was running his own software, something called Augment. And he was using his one-handed keyboard (you hit 'chords' of a few keys to enter a letter).

A lot of 'hard-core' really seem to prefer a command line to anything else. I don't really believe its just nostalgia that makes us what to do it ether. Using the command line is just a faster way to interact with the machine. And there's a simple reason for that. With the keyboard, you have an infinite number of verbs that you can use to communicate. With the mouse, you only really have 3, 2, or 1 verb on UNIX(with X), windows, and the Mac respectively. This typically means ether "CLICK" or "CONTEXT MENU", where the context menu is another list of items you can "CLICK" on. While looking for a particular file that you forgot about (along with the filename (?)) might be speed up, just about every other type of file operation is slowed down. A lot.

When the interviewer saw the one-handed keyboard he said (something like) "They'd have to make it more user-friendly in order for me to want to use one". At witch point (and I wish I had the quote) Egglebart said that 'user-friendliness' was over-rated. If you weren't willing to learn anything new, you couldn't really use the computer to its full potential.

To be honest, I think the idea of the GUI has been tied to tightly to the misnomer 'user-friendly', and 'ease of use'. When in fact, a GUI isn't anymore easy to use the a command line its just easy to learn. You get to see all the options available to you, instead of needing to memorize commands. But in a lot of ways, what you learn ends up being weaker.

This gets me back to the one-handed keyboard. If you had a device like that, you could have the best of worlds, infinite data entry, and graphical layout. Imagine you wanted to copy a file to another directory. You could click on it and type "cp /wherever" directly into the icon. You could open any folder on the system (just click the desktop and type "open /bla/openthis". (One of the things that bugged me about BeOS was the lack of integration of the GUI and the CLI. It would have been nice to be able to open the folder I was in the CLI in the GUI, and vice versa. You can do this in Windows for god sakes.)

Unfortunately, in keeping with our two fisted keyboard design, we've really, really, limited what we can do with the GUI. Its my opinion that the current CLI/GUI combo is a horrible hack, inflicted on the world by the original Mac, Microsoft, for blindly following Apple, and the Linux Crowd for blindly following them both.