Slashdot Mirror

Damn straight. The most bone-chilling comment on Aqua that I've read so far came from Bruce Tognazzini, usability guru and founder of the Apple Human Interface Group -- the main guy responsible for the stuff you love/hate about the Mac GUI. His quote:

I'm trying to get my Mac fully tricked out before January, when the Mac operating system is no more. At that point, I want my machine perfect, so I can go as long as possible before switching over to Windows.

Tog was probably gone by the time OS 8 added tabbed windows, but I definitely would have a bad time using a Mac without them. And FinderPop.

In terms of menus, this means that it's easier to hit a menu if it is placed at an edge of the screen. In Windows apps, there is a space above the menus, so you have to be more precise with the mouse. It's a subtle difference, but it makes a difference in daily usage of the OS.

There is further discussion, with examples, here.

In terms of menus, this means that it's easier to hit a menu if it is placed at an edge of the screen. In Windows apps, there is a space above the menus, so you have to be more precise with the mouse. It's a subtle difference, but it makes a difference in daily usage of the OS.

There is further discussion, with examples, here.

Many user interface studies have shown that it is significantly faster to have the menu on the top than on the top of Windows. Why? The menu height is infinite so there is much less need for fine motor control - you just jam the mouse to the top of the screen. The reason people don't think it is faster is that when accessing a menu on the top of a Window, users are using that fine motor control and lose track of the time it is taking. In other words, you may perceive it to be faster, but if you use a stop watch, it is actually slower. The orignal Macintosh user-interface designers studied this very carefully when they made the decision to put it on top.

See this article on AskTog (go to question #5)

Woo-hoo! Let's translate this final verdict into clearspeak. "MS Win-duh is nice because they've spent megabucks on UI design, while Gnome/KDE are nice although they didn't. And they should all steal even more from MacOS."

I hate to say it, but this article belongs to the from-the-bulls-ass department. The reviewer has no clue about user interfaces, and no background in CS whatsoever. Can we please get an ignorance filter for Slashdot?

To clarify this before people start to flame me: user interfaces need to be logical. This is a danged FACT! People can learn to use anything, as long as it's systematic. The Linux/Unix core is systematic. Gnome/KDE is not. Windows is a mess, but it's the monopoly so who cares. MacOS is logical, but it's disregarded as a toy. This reviewer doesn't even know what the word "logical" means!

The reviewer should read some of the stuff from Bruce Tognazzini.

--Bud

... since I already have a 4 button mouse (Logitech rocks :), and I re-map all my keys so that they are close to my left hand around the left side of keyboard (the "WASD" diamond keys.) Basically I'm applying Fitt's Law. Having to take your hand of the keys can can prove fatal in the long run when those precious seconds matter at the build-up phase.

Here is an interesting article on security methods, from a user-interface design perspective. Maximum Security

Here's a quote to whet your appetite:
Security in our nation's computer systems is in trouble, and the fault lies with an education system turning out security people unprepared to build real-world secure systems. As a result, many of our most secure-appearing systems sport all the impenetrability of a slice of Swiss Cheese.

(BTW: I recommend looking through AskTog and Alertbox if you deal at all with interface design, or want to know why today's interfaces suck so much sometimes :)
-----
D. Fischer

Here is an interesting article on security methods, from a user-interface design perspective. Maximum Security

Here's a quote to whet your appetite:
Security in our nation's computer systems is in trouble, and the fault lies with an education system turning out security people unprepared to build real-world secure systems. As a result, many of our most secure-appearing systems sport all the impenetrability of a slice of Swiss Cheese.

(BTW: I recommend looking through AskTog and Alertbox if you deal at all with interface design, or want to know why today's interfaces suck so much sometimes :)
-----
D. Fischer

Microsoft has worked long and hard to create a GUI that is clean and usable. And they have done very good job too. There is no reason to do a major UI overhaull, so they stick with the old -- why is that a bad thing? Why should Microsoft force 200 million people to learn some new obscure user interface paradigm?

I believe that a touchscreen is a good replacement for a mouse; and a trackball would also be an even better replacement under certain circumstances (such as smooth navigation, as opposed to point-and-click). Inspired by the non-existent technology of the Starfire project, I've been pondering the idea of using a combination of a large screen for viewing documents, with no controls on it; a small touchscreen for application-specific controls; a trackball for smooth motion; and a keyboard for typing text. I could operate GIMP entirely via the touchscreen, or a combination of touchscreen and trackball. The trackball could be the 3-axis type which would allow some interesting 3D navigation (but Linux is short on apps which would make use of it, so far). Eventually the keyboard (and some other input modalities) could be gradually replaced by voice recognition.

The metawidget idea (that link is getting old, I need to write about my more recent ideas) would be useful in such a system to separate "control" functionality from the document and view parts of the MVC pattern. GIMP for example would keep a socket connection open with the touchscreen display software, on which it would exchange messages about which controls to make available, and receive messages about which controls were selected. So the palettes, the toolbox, and some context-sensitive stuff would be the main things on the touchscreen, and there would be enough real estate to have many more of them available at once, so that most actions can be done with fewer clicks. Cascading menus should be replaced with something more appropriate for punching a touchscreen (when you "dive in" to the next level, the next level replaces the current level; or perhaps with a menu structure that resembles the NeXT file browser). Eventually I will get around to putting up a website at www.metawidgets.org to discuss these ideas.

In short, I think improving ergonomics ought to be done in a holistic way rather than just putting more bells and whistles on existing devices like mice and keyboards. And there is more than one path to experiment with. I like touchscreens but they are not practical in every situation.

Now, I'm going to go ramble on a bit here about my ergonomic workstation idea, in case you haven't already had enough...

• Object
• • Person
  • place
  • Thing
  • file
  • stream
  • device

WHY? well the advantages are obvious aren't they? In this age of always(we wish)on networking it would make sense to represent the most commonly dealt with domain objects as clearly as possible. Bruce Tognazzini made the suggestion that people ought to be first class elements of any net oriented UI. And of course if you have people they have places to go things to do people they do them with, things they need to do them, places where they can work undisturbed, places where they can choose things or make things, places to meet other people, etc, etc. until you reach a place that... well you don't really want to go there now do you?

The neat thing is that it's possible to do almost all of the messy parts in the XML layer, for which there are numerous commodity tools and libraries. It should (in theory) be crossplatform (assuming platforms are compatible to standard).
My major worry right now is whether most of the SVG clients are going to support in-picture-links as that would be the way to implement most of the method calls on objects. Greatest possible thing would be to be able to write the methods in scheme ;-)

Any dialog box with more than one row of tabs (strike 1) will move the rows around, so that the one you click on becomes the front row. Of course, if you missed the one you were looking for (see Fitt's Law) the original target has been moved by the OS. As if it were designed to frustrate users.

And an overloaded NT server has terrible mouse control, so missing your target is more likely than expected.

This will probably work better in the GSM part of the world, where there's usually only one major system. In the US, we have as many as six completely separate cell phone systems in some areas.

Apple Interface Designer Bruce Tognazzini suggested this in a recent column.

As one poster pointed out, a feature that involuntarily cripples your cellphone will be a tough sell.

While much of the basics of human interaction and GUIs was worked out years ago (at Xerox and Apple) there are still people thinking of better ways to do things. Check out Bruce Tognazzini's web site AskTog for some coverage of this topic. He has tutorials on user interface design, cogent criticism of current GUIs, suggestions for improvements, as well as sundry and other essays.

While much of the basics of human interaction and GUIs was worked out years ago (at Xerox and Apple) there are still people thinking of better ways to do things. Check out Bruce Tognazzini's web site AskTog for some coverage of this topic. He has tutorials on user interface design, cogent criticism of current GUIs, suggestions for improvements, as well as sundry and other essays.

While much of the basics of human interaction and GUIs was worked out years ago (at Xerox and Apple) there are still people thinking of better ways to do things. Check out Bruce Tognazzini's web site AskTog for some coverage of this topic. He has tutorials on user interface design, cogent criticism of current GUIs, suggestions for improvements, as well as sundry and other essays.

While much of the basics of human interaction and GUIs was worked out years ago (at Xerox and Apple) there are still people thinking of better ways to do things. Check out Bruce Tognazzini's web site AskTog for some coverage of this topic. He has tutorials on user interface design, cogent criticism of current GUIs, suggestions for improvements, as well as sundry and other essays.

While much of the basics of human interaction and GUIs was worked out years ago (at Xerox and Apple) there are still people thinking of better ways to do things. Check out Bruce Tognazzini's web site AskTog for some coverage of this topic. He has tutorials on user interface design, cogent criticism of current GUIs, suggestions for improvements, as well as sundry and other essays.

First, I am sure that everyone here knows how much work goes into usability and interface design, as most people here have some modicum of programming experience. One of my favorite web pages, AskTog, goes into great detail on the ins and outs of computer user interface design.

I know that many people would use the building/ architecture analogy-- mere building is not art, while architecture is. "Normal" applications, they say, are mere building, while games would be considered "architecture" due to their beauty.

Poppycock! Architecture is art not because it is beautiful, although one goal of the architect is indeed visual appeal. He goes about attaining that beauty, however through the use of some language-- a visual vocabulary-- to make some statement or invoke something in the imagination of the viewer. An example: Le Corbusier's Villa Savoye is a private residence, but its visual elements combine to evoke a steam ship cruising across the lot. That is what makes it art. Art is communication, not pretty colors or "photorealistic backgrounds." Art tells you something that the artist wanted you to hear.

It is my opinion that the true art lies in making complex operations decipherable by even the simplest users. A good GUI is a work of art. Reducing complex-looking physical phenomena to a few mathematical equations, such as Ohm's Law or Maxell's Equations, is art. Pretty pictures are just that. And nothing more. They convey no extra message to the viewer; they are merely eye candy.

Don't get me wrong; these new games are beautiful. The intense graphics do enhance play by making it easier to submerge yourself in the play-world presented. But there's more to art than pretty pictures.

I can understand why many hackers feel GUIs aren't very useful, they haven't changed much since they were invented. I think we could do much better and it wouldn't necessarily take more rendering power.
I remember seeing on CONNECTIONS how people in the middle ages would imagine a cathedral to memorize large amounts of data. They would form this 3D construct in their minds and then "place" facts in each room. Why couldn't that be done on a screen, a 2D construct which you could move through as if it had depth?
There seem to be all kinds of possibilities, but we're stuck in the GUI-as-a-desktop paradigm. Check out AskTog.com for a lot of interesting ideas on usability. The one thing that I read there that I thought was fascinating, was the four spots on the screen that have "infinite depth," so you can hit them easily with a mouse (You know where they are :).
I use autohide toolbars whenever I can because I want to be able to use all of my screen real estate. Those four spots seem like perfect places to anchor some. But that's just one possibilty. Why do our files have to act like folders? I'd like to see some of that innovation we keep hearing about.

Let me guess, you haven't actually tried OS X, but you feel qualified to make an educated guess that it totally sucks based on reading a description and looking at some pictures.

I didn't say it totally sucks. I said there are some UI decisions that are backwards. The traditional Mac window control layout, for instance, is unquestionably superior to the three-buttons-in-a-cluster approach found in Windows 95 - OS 10 copies Windows instead of the Mac layout, why? A screenshot is quite sufficient to spot this rather bizaare choice.

Several reviewers have noted some extremely poor design decisions, see for example Ars Technica's observation on the OS 10 dock, or Ask Tog, who while trying to be positive, properly notes several steps backward in the UI.

Well, while I think that the article you link to has quite a few good points to make, those points deal exclusively with Apple hardware (specifically the RISC based PowerPC CPUs).

Here is a more relevant article about the shortcomings of the Aqua interface, and another article about the improvements that Apple should be making.

Both of the previous articles were written by Bruce 'Tog' Tognazzini, who founded the Apple Human Interface Group, so his opinion should count for something.

Another article, that is slightly less relevant, dissects the UI of the new QuickTime player. It isn't kind.

I hope that these references are of use to anyone reviewing the UI changes that Apple is incorporating into Aqua and it's software, so as to avoid making the same mistakes WRT Linux GUI design.
--

Well, while I think that the article you link to has quite a few good points to make, those points deal exclusively with Apple hardware (specifically the RISC based PowerPC CPUs).

Here is a more relevant article about the shortcomings of the Aqua interface, and another article about the improvements that Apple should be making.

Both of the previous articles were written by Bruce 'Tog' Tognazzini, who founded the Apple Human Interface Group, so his opinion should count for something.

Another article, that is slightly less relevant, dissects the UI of the new QuickTime player. It isn't kind.

I hope that these references are of use to anyone reviewing the UI changes that Apple is incorporating into Aqua and it's software, so as to avoid making the same mistakes WRT Linux GUI design.
--

Well, while I think that the article you link to has quite a few good points to make, those points deal exclusively with Apple hardware (specifically the RISC based PowerPC CPUs).

Here is a more relevant article about the shortcomings of the Aqua interface, and another article about the improvements that Apple should be making.

Both of the previous articles were written by Bruce 'Tog' Tognazzini, who founded the Apple Human Interface Group, so his opinion should count for something.

Another article, that is slightly less relevant, dissects the UI of the new QuickTime player. It isn't kind.

I hope that these references are of use to anyone reviewing the UI changes that Apple is incorporating into Aqua and it's software, so as to avoid making the same mistakes WRT Linux GUI design.
--

Of the screenshots posted, I found the ones of the new QuickTime player particularly encouraging. The current incarnation of the QT player is an affront to UI design principles, and has been rightly pilloried and excoriated. The screenshots of the new QT player seem to address the bulk of the criticisms made; perhaps it's a testament to my cynicism that I am encouraged by a company that seems to have listened for a change.

Coupled with the changes to the Dock, I am now more hopeful that the final version of MacOS X will also take into account the critiques of the previous preview that have appeared on the web.

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".

I'm shocked that nobody else has mentioned Bruce Tognazzini's web site AskTog. He is the founder of the Apple Humam Interface Group and author of a number of good books on the subjects of software design and user interface design. His web site is wealth of usefull information on user interface design issues and asundry other topics.

I'm shocked that nobody else has mentioned Bruce Tognazzini's web site AskTog. He is the founder of the Apple Humam Interface Group and author of a number of good books on the subjects of software design and user interface design. His web site is wealth of usefull information on user interface design issues and asundry other topics.

I'm shocked that nobody else has mentioned Bruce Tognazzini's web site AskTog. He is the founder of the Apple Humam Interface Group and author of a number of good books on the subjects of software design and user interface design. His web site is wealth of usefull information on user interface design issues and asundry other topics.

Hugonz

winamp has a good many themes that do not mess with functionality

Winamp, which popularized this whole app theming thing, is an excellent example of an application where themes, while they may not help functionality, certainly don't hurt it. It's a simple app, with a few buttons and an information display area. Most people who cannot program their VCR can use it to play tapes. They also don't have a problem using the CD player, and that's really all Winamp is, so making the buttons look like brushed aluminum doesn't really slow most users down.

Additionally, Winamp is a parasitic application -- meaning that it usually runs alongside other applications, and the user rarely runs Winamp exclusively. The user spends little time working with Winamp itself, they're busy using their main applications, with Winamp playing in the background.

What's needed is to spend more time working on the basic usability of applications and widgets. Go read (as mentioned before) the Interface Hall of Shame. Read AskTog's rant about the differences in how Windows and the Mac handle cascading menus.

Lemme tell you about my little improvement to widget usability. I'm working on an application that works as a Win32 Appbar (like the Start menu). It can be docked to any edge, and can be auto-hidden, staying out of the way until the user moves the mouse over the edge the appbar is docked to.

When I first started testing it, I set the appbar properties to auto-hide and stuck it at the top of the screen (my Start bar, like most people's, is at the bottom). This sounds fine, but turned out to be a major irratant -- every time my mouse pointer hit the top of the screen (like, say, when I was going for a menu), the damn appbar would drop down! I'd then have to move the mouse pointer down, wait for the window to retract, then, slowly, move back up to the menu (without moving too high!), then make my selection.

A simple timer, with a user-defined delay, solves this problem. When the mouse moves to the appbar's edge, a timer is started. If, when the timer expires, the mouse is still on the edge, the appbar will show itself. If the user clicks on the top edge (indicating they want to see the appbar immediately), the appbar will show without waiting for the timer.

That's the kind of work UI designers should be doing.

Alan Cooper once said that the web has set user interface design back 15 years. I agree. Instead of ensuring that your applications can be themed by every 31337 h4x0r with a warez copy of Photoshop, make the interface work better.

Actually, it's a very smart idea developed based on usability reasearch. Putting a single menu bar at the top of the screen, as it takes advantage of Fitts' Law (the ease with which a user can acquire a target is proportional to the size of the target and inversely proportional to the distance from the target). The menu bar is at the upper edge of the screen, which makes it easy to "hit" -- just move the mouse up and you'll slam the edge of the screen as it effectively has infinite height. M$ is even moving towards this as most of their apps are now MDI (Multiple Document Interface), where there's a parent window with the menu bar and child windows whose menus appear in the menu bar when they are in focus. Check out this article at asktog.com for the full scoop on Fitts' Law.

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.

My primary consolation in watching you people handwave over this nonsense is that it's never going to amount to anything anyhow: file/folder is locked in, there's no room for you the way you're behaving.

You're right brennan - sans-serif fonts are easier to read on a monitor.
see
Bruce Tognazzini's explanation (Tog being an original Macintosh UI guy among other things - he's up there with Jakob in the UI / Usability field).
If you're really interested and want academic literature, start at the Human Computer Interaction Bibliography at www.hcibib.org, search for serif for a couple references.

From Tognazzini's article:

I also very much like the idea of the "gumdrop" window controls that, when moused-over, reveal symbols for close, dock, and zoom.

...it looks cool and it's used on a lot of sites which win design awards. Because there's no long strings of text, MMN makes the page look "cleaner"...[but (from a diferent paragraph)] it's confusing and risks alienating your customers.

[1]BTW, turn on your java before visiting, or you'll miss most of the fun.

Except that I'm not as optimistic as he is that OSS will be able to solve this problem.

But before I get to that, lemme try to explain why this is such a big problem, because many of y'all don't seem to get it, judging from some of the posts so far.

But, you might say, we don't want all those Winblows lusers! We don't care how *smart* you have to be to use Linux, cause we only want us l33t genii (hey! We're even l33t l4at3n speakers!) to be able to use it! Because we all know that, once you learn how to use it (and it doesn't even take me that long, cause I'm so smart), OSS is more flexible, powerful, and faster to use than some "end-user tested" crap.

And 10 years ago, you'd have been right. The problem here is that the above argument is no longer true, and most Linux users/coders don't even know it. Now there's no argument that OSS for Unix/Unix-alikes has had some of the best text-based UI's around. (Or, in the case of xemacs, I suppose we should say "primarily keyboard-based" rather than "text-based".) Sure, most of them are abolute hell to learn (the poster above who suggested that you could adequately teach a newbie to use vi by sitting them down in front of it and pressing 'i' notwithstanding), but, once you get used to them, you realize how incredibly intelligently they were designed. Things like vi/vim, emacs, and the various CLI shells; you'd need a dedicated teacher, a book, or a hell of a lot of patience with man pages to figure any of them out, but once you do you find that they're extraordinarily quick to use, ridiculously full featured, and amazingly robust. As my Harley Hahn Unix book says ad nauseum, "hard to learn but easy to use." And if you're any sort of geek--someone who's going to spend most of your time on a computer, such that the steep learning curve isn't too relevant--then it's not such a bad design philosophy.

Thing is, most of us have realized that a GUI has the possibility to make anyone more productive, even Tom Christiansen's proverbial "vi wizard". However, the people making GUI tools/wm's/environments for Linux (note: not that I'm one of them; not that I'm a good enough programmer to contribute a single line; and really truly not to take anything away from their impressive achievements) seem to have figured that we could use a dose of the old paradigms, a huge helping of superficial Windows UI plagarism, and some skinability (neato!) and have a kickass UI.

Not even close.

Again, Gnome and KDE are incredible achievements for what they are, and are constantly getting better. But. As they stand now, their UI is clearly substandard. KDE is like Win9x, but flakier (from a UI perspective, not a stability one, of course), with less consistent (though more extensive) preferences panels, unconsistent app UI's, much less polish, and an awful excuse for perhaps the most important functionality of a GUI--being able to seemlessly share data between different apps. Gnome has the benefit of not being such a slavish copy of Windows, but is otherwise even worse in all of the above categories.

And what do most Linux users do about it? a) Complain about how GUI's are for wimps anyways, or b) Stick on some badass skins and note how, since E has much more functionality than any Windows wm, it is invariably a better UI.

Meanwhile, what do MS and Apple do about it? They spend millions of dollars a year hiring UI experts and, more importantly, empirically testing thousands of potential interfaces on end-users to find which are better.

Notice I didn't say "easier to learn". I said "better". As has been noted elsewhere in this thread, the Windows UI paradigm isn't any more intuitive from first principles than the KDE paradigm (duh; they're nearly identical). But that's not the point. What good UI testing is all about isn't how easy it is for someone who's never seen a computer before to use, but rather, assuming the user already has adequate familiarity with the paradigm, a) how flexible, robust, and powerful is it; b) how intuitive is it to do an action which is part of the paradigm but which the user has never actually done before; and c) how fast, easy, and nonobtrusive is it to do the sorts of tasks that the user does again and again.

By all these criteria, something like the Unix CLI passes with flying colors. And, by all these criteria, Gnome and KDE, and the programs that run on them, in their current states are quite a bit behind Windows, which in turn lags behind MacOS. (Note: I've never been a Mac user, and have always generally disliked them for several reasons: bad under-the-hood technology, horrible overpricing, lack of good, fast software, one damn button, deceitful marketing. However, I'm just beginning to come around to how well designed their UI is (compared to the alternatives), and damn if OS X doesn't look incredible. But I digress.)

But, you all say, that's what's so great about Open Source! If there's anything wrong with Open Source Software, then someone will fix it! The problem is, very few people notice that anything's wrong. That is, you don't notice how unproductive the way you're doing things is until you see a better implementation. And even then you probably won't notice--it might take someone with a stopwatch showing you how much faster you work the new way than the old way. A quick story to perhaps illustrate what I mean: couple days ago I was procrastinating writing a huge (and overdue) paper, by reading that analysis of Aqua by Tog, the guy who essentially led the Mac UI development. And, since I was trying awful hard to procrastinate (and because once you start reading him, Tog's pretty interesting), I decided to click the link to this article on Fitts' Law, where I read Tog's advice to Word for Windows users: switch to full screen mode to get the Fitt's Law advantages of infinite depth behind your menus, and switch to large icons to speed up finding the right one.

Well, never one to miss a chance to not write my paper, I did some informal tests. And, even though the ideas had never occurred to me (not because I didn't know full screen mode and large icons existed, but just because since it *looks* so much more professional in maximized window mode with by big toolbars full of small icons (which, as I run 1280x1074, really are small), it had to be more productive that way), I realized pretty quickly that they actually improved my productivity. Or, would have, except that in full screen mode the menus, while at the top of the screen and thus with infinite depth, don't show up until you mouse over them (Tog doesn't seem to mind this sort of thing; I find it annoying as hell. But in any case, it's worth pointing out that this is proof Tog isn't designing for ignorant first-time users--because you certainly can't expect any first-time users to know about items which are hidden until you mouse over them--but rather for ease of use for people who know what they're doing); and since MS decided *not* to include higher res bitmaps for all the icons in large icon mode, they looked too damn ugly for me to keep them. But it is true that I could find the right one a lot quicker; and that I'd never realized how my tiny icons were slowing me down until I tested it.

Ok, I'm hideously rambling, so lemme try to sum up. Text-based Unix interfaces were everything that today's Linux GUI's aren't: consistent, robust, quick (from a UI standpoint, not a technological one), and intuitive for those who already knew the paradigm. A simple example is pipes--a simple concept which gives the CLI its amazing power and flexibility--and their GUI analogues, object models like COM, CORBA, etc. designed to allow intuitive sharing of information between apps--which, to put it mildly, work much better on mainstream OS's than on Gnome and KDE. A more interesting problem (because we at least agree on the fact that our object models need improvement, and I have no doubt that they'll catch up pretty soon) is inconsistent and just-plain-badly-designed interfaces--a failure to take advantage of principles--like Fitts' Law--that the other guys have learned from psychological research and intensive user-testing. Perhaps the most difficult problem is the lack of consistency across apps.

The question is, how do we fix this. In regards our lack of UI research, I have a good deal of hope. After all, Red Hat has the money to hire some serious UI people and psychologists and testers and whatnot to get Gnome on equal footing with Windows and Macs; Corel or others could do the same for KDE. Hell, they might even come up with some *new* GUI paradigms, instead of just copying the two rather flawed ones out there, often badly.

The problem is that the strength of OSS lies not in the high-name projects which can now afford serious funding, but rather in all the little ones that provide all the little functionalities we know and love. How to get all of those projects to understand, and furthermore, abide by complex UI standards--when at the moment they can't even agree on standard menu shortcut keys--is a huge problem. Furthermore, there's the fact that a different choice of widget toolkits inevitably imposes a different UI paradigm. Finally, we have the fact that Linux geeks rightly love customizing our systems to the fullest extent; as Apple has clearly realized, with their apparent decision not to allow OS X any skins other than Aqua, customization is the enemy of consistency.

Hopefully this absurdity of a long post has convinced y'all that these UI issues are important, because they really affect how productive any user is--but elite users *especially*. I do think that OSS can come up with a better response to the UI issue than poorly understand copies of the existing GUIs. However, I'm not sure exactly how, and our work so far in this area has not been encouraging...

If you want a lot of good commentary on the MacOS X interface, check out Ask Tog for his detailed critique of the Aqua interface as demo'ed by Steve.

A user-programmer is far more likely to deliver something useful in practice rather than something primarily useful in theory.

Nothing theoretical about it.

Popup a heirarchical menu in Gnome, then try to move to an item in a submenu that is below and to the right. You have to do some intricate threading the needle to get the cursor to exit the main menu exactly at the point where the arrow points to the sub menu. With a Mac, I can select the main item, then move my mouse down diagonally directly to the subitem. Missing the subitem more than once on a non-Mac system gets old very fast. And how about some built-in hysteresis? If I move the mouse along that menu very fast, every submenu pops up. The Mac has a built-in timer so that fast cursor moves do not cause that annoying flashing.

For references on why interface is important, see MacKido, Jakob Neilsen or Tognazzi's website.

Remember, bad interface killed John Denver.

A user-programmer is far more likely to deliver something useful in practice rather than something primarily useful in theory.

Nothing theoretical about it.

Popup a heirarchical menu in Gnome, then try to move to an item in a submenu that is below and to the right. You have to do some intricate threading the needle to get the cursor to exit the main menu exactly at the point where the arrow points to the sub menu. With a Mac, I can select the main item, then move my mouse down diagonally directly to the subitem. Missing the subitem more than once on a non-Mac system gets old very fast. And how about some built-in hysteresis? If I move the mouse along that menu very fast, every submenu pops up. The Mac has a built-in timer so that fast cursor moves do not cause that annoying flashing.

For references on why interface is important, see MacKido, Jakob Neilsen or Tognazzi's website.

Remember, bad interface killed John Denver.

You only think the keyboard is faster. Whenever an experiment that involves a genuine stopwatch is conducted, the mouse wins every time. Ask Tog if you don't believe me.

My personal pet peeve is that the menu bar is permanently docked at the top of the screen and doesn't stay attached to the application that owns it.

There are advantages to that method: For one, you don't waste screen real estate duplicating the menu bar in every window. For another, it means you always know where to find the menu, no matter where a window is. I'm not saying one is better then the other, just that Apple's method is not without merit.

Actually, it is a lot like that; the Mac's menu bar is a demonstrably superior interface. In fact, if one is to actually time users, a Windows-like menu bar is a factor of five slower to use.

This superiority is a result of Fitt's Law, which states that the time it takes to point at a target with a pointing device is a function of the target's size and distance to that target. The larger the target and the nearer it is, the less time it will take to point to it. This is, of course, trivially obvious when phrased that way, but its implications are ignored far too often by software developers.

The Mac's menu bar uses a very special piece of screen real estate, exploiting Fitt's law. Because the menu bar rests all along the edge of the screen, it has an effectively infinite size; you can keep rolling the mouse upward as much as you like, but that cursor is always going to be in the menu bar. Because of this, it's faster to point at a menu title, and the entire process of using the menu is accelerated.

Of course, the most efficient place to put the mouse is right where it is, so that's an even better place for the menu bar: Under the mouse all the time. The problem is that we don't have a good user interface for that; hierarchical menus are inefficient to use (timewise) and cumbersome. NeXT actually did this, though: A right-click brought up the entire menu bar beneath the mouse, arranged hierarchically. This was in 1989, and most likely begat Windows 95's context-sensitive menus, which are a refinement in that they avoid necessitating the task of navigating cumbersome, deeply hierarchical menu structures to access the most useful commands.

But, all that aside, the Mac's menu bar, after nearly 16 years is empirically the best interface we have for presenting an entire menu hierarchy. Most likely just dumb luck, though; I doubt the designers of the original Macintosh considered these implications in the world of 1983's nine-inch, 512-by-384 monochrome displays while Steve Jobs was breathing down their necks with the refrain, "Real artists ship!"

You can read more about interface design and Fitt's Law at http://www.asktog.com/. It's an interesting, if oft-neglegted, subject.

The former book is mainly drawn from his experiences in the development of the Macintosh interface and covers such niceties as how and why to do user testing. He covers the perceived time as an important factor in design (I'd rather walk a mile in 15 minutes than wait 10 for a bus). The Software Design book is largely a case study of an advanced software interface project he did as a Sun fellow (the Star Project.

If some of the arguments presented in this discussion held water, nobody would have written any good music on the piano. It's too damned simple an instrument; however could you play or write anything more complex than twinkle twinkle little star? After all, look at its interface. Notes get lower as you play the keys to the left, and higher as you move to the right. Volume is proportional to the velocity with which you strike the keys. Only "tune kiddies" (or perhaps "score kiddies" is the better term) would be caught dead with one of those things.

I'm a strong believer in having a life and as a result also believe in tools that let you have a life. For most business applications, VB does the job quite nicely. Need speed? I'll use C++ Builder. Writing an enhanced CD? Director. CGI? Python. Given a choice between being "elite" and having a life, the life wins every time.

Perhaps it's time for everyone to go demonstrate the slashdot effect on the Ask Tog site and look at the article How Programmers Stole The Web. It provides the best and most rational argument for having an "easy" language around: "real programmers" aren't the only people with good software ideas. Think of the of those who don't qualify as "real programmers": Dan Bricklin, who came up with the spreadsheet, and Robyn and Rand Miller, who came up with Myst .

There's an interesting article called "How Programmers Stole The Web on Bruce Tognazzini's user interface site, Ask Tog. One point it puts across is that when programming languages and environments were relatively simpler (he says in the '70's, I say in the '70s and '80s), there was an explosion in programming creativity as many people who'd never even touched a computer before were creating all kinds of interesting and even ground-breaking programs. Consider the spreadsheet, which Dan Bricklin cobbled together in BASIC, or MYST, created by the Robyn and Rand Miller using HyperCard. I've seen non-programmers write small (but often-used, even institutionalized) applications that met their own particular needs using HyperCard, Toolbook, FileMaker, Visual Basic, REALBasic and Director -- all without having to run to the local geek for anything more than a little help. In the article, Tog says that Pascal is as difficult as C, but anyone who's had to chase pointers or manage memory (or used Delphi) will probably disagree. The important thing is that the presence of a simpler (than C/C++) programming language couple with a simpler programming environment (no makefiles, no sepearate source/header files) should encourage similar development in Linux. I also think that giving people -- that means anyone, not just the code gurus -- the ability to "do it themselves" fits perfectly with the Linux philosophy. If a "serious" programmer is free to write a utility or driver if it meets some need, a non-geek should also be able to put together apps that meet their workaday needs.

It's also good news for experienced developers. I work in tandem with a hard-core human interface guy, and what I usually do is hand him VB/Delphi forms and have him lay out the interface, after which I attach the code. Having someone who's actually concerned about the interface and giving him the ability to build it and see it all at once is a great timesaver for me (as I don't have to do it) and for the users (because someone's taking their workflow into consideration). Yes, we still always start off with pen and paper when designing, but giving a person with human interface skills (but not programming skills) the ability to build interfaces is efficient and benefits the users too.

A library of ready-made interface and other components is also handy. VCL is so much nicer to deal with than MFC, and I think it'll be a considerable boon to Linux app developers. Yes, I like doing things for myself, but sometimes it's nice (and less expensive in terms of effort and debugging) when some stuff has already been done for you.

However, the most important benefit of Delphi for Linux applies to both newbies and gurus -- RAD enviroments, simpler langauges and libraries like VCL let you have a life! I can't even begin to measure the value of such a feature.

There's an interesting article called "How Programmers Stole The Web on Bruce Tognazzini's user interface site, Ask Tog. One point it puts across is that when programming languages and environments were relatively simpler (he says in the '70's, I say in the '70s and '80s), there was an explosion in programming creativity as many people who'd never even touched a computer before were creating all kinds of interesting and even ground-breaking programs. Consider the spreadsheet, which Dan Bricklin cobbled together in BASIC, or MYST, created by the Robyn and Rand Miller using HyperCard. I've seen non-programmers write small (but often-used, even institutionalized) applications that met their own particular needs using HyperCard, Toolbook, FileMaker, Visual Basic, REALBasic and Director -- all without having to run to the local geek for anything more than a little help. In the article, Tog says that Pascal is as difficult as C, but anyone who's had to chase pointers or manage memory (or used Delphi) will probably disagree. The important thing is that the presence of a simpler (than C/C++) programming language couple with a simpler programming environment (no makefiles, no sepearate source/header files) should encourage similar development in Linux. I also think that giving people -- that means anyone, not just the code gurus -- the ability to "do it themselves" fits perfectly with the Linux philosophy. If a "serious" programmer is free to write a utility or driver if it meets some need, a non-geek should also be able to put together apps that meet their workaday needs.

It's also good news for experienced developers. I work in tandem with a hard-core human interface guy, and what I usually do is hand him VB/Delphi forms and have him lay out the interface, after which I attach the code. Having someone who's actually concerned about the interface and giving him the ability to build it and see it all at once is a great timesaver for me (as I don't have to do it) and for the users (because someone's taking their workflow into consideration). Yes, we still always start off with pen and paper when designing, but giving a person with human interface skills (but not programming skills) the ability to build interfaces is efficient and benefits the users too.

A library of ready-made interface and other components is also handy. VCL is so much nicer to deal with than MFC, and I think it'll be a considerable boon to Linux app developers. Yes, I like doing things for myself, but sometimes it's nice (and less expensive in terms of effort and debugging) when some stuff has already been done for you.

However, the most important benefit of Delphi for Linux applies to both newbies and gurus -- RAD enviroments, simpler langauges and libraries like VCL let you have a life! I can't even begin to measure the value of such a feature.