Slashdot Mirror
Towards The Anti-Mac Interface
Pointwood writes: "Joakim Ziegler (Webmaster for Helix Code) has written an article about where computer interface design may be heading. It takes a paper called "The Anti-Mac Interface" written in 1996 by Don Gentner and Jakob Nielsen and take a look at where we are now.
In the Anti-Mac Interface paper, Don Gentner and Jakob Nielsen explore the types of interfaces that could result if they violate each of the Macintosh human interface design principles." Excellent article.
But my point: GUI is not the future. Real conversation is the thing. Combine a computer smart enough to have a conversation with a WWW filled with advanced standarised meta-data tags, and you have it.
"Now draw a line from just above the middle of the window to about 78% of the way across to the right"
"Like that, Dave?"
"No, down a bit"
"Like that, Dave?"
"No make it a little longer on the right"
"Like that, Dave?"
"No, I want it at a slightly deeper angle"
"Like that, Dave?"
"No, I guess slightly less of an angle"
"Like that, Dave?"
"No, it should start higher up"
"Like that, Dave?"
"Damn it, I'll just use the mouse"
Voice commands are not good for many things you want to do with your computer. We'll have GUIs around for a while yet.
Sailing over the event horizon
What we want are high-level objects with implicit structure. Text files with XML structure are not good enough.
... the system should be developed in a high-level language itself, which could be used for remote scripting and automation as well.
:-)
;-) </BASH>
Can I ask why text files with XML structure are not good enough?
You also have to consider the issue of multiple agents. This requires a clear-cut, high-level model of interaction between systems, which, of course, doesn't exist (nor could exist) on Unix.
While I agree that such a model does not exist under Unix, can I ask why you think it cannot? I generally agree with you that a lot of the things UI-ish talked about, both generally and with this article in particular, aren't there yet on Unix, but by and large I think it is only a matter of time. I see no reason why the Unix security model in particular cannot be extended to support safe, shared control of user applications.
I think it's worth pointing out that safe, shared control in general is hard to accomplish. Almost all (working) security implementations use the principles of KISS and system high: Larger, more general security compartments tightly segregated from other systems. Consider: chroot() jails, mapping all remote access to nobody, Java, firewalls and DMZs. All of them are basically variations on the sandbox concept.
The reason is that designing and implementing a system which allows safe mixed-mode secure operation is very difficult. People make mistakes, and complexity makes mistakes harder to find and harder to prevent. The solution to this problem of limited human capability is the sandbox model. Separate systems with tightly controlled interfaces are easier to design and debug then mixed-mode, complex, interwoven systems. I don't think we'll see this changing anytime soon.
And, since I know someone is going to bring this up: No, simply stating "Use a capabilities model" is not going to solve all your problems. Capabilities (just like everything else) provide no additional security simply by existing; they have to be applied properly for them to work. Applying them properly is the crux of the matter, for there you run into all the same complexity problems you do with everything else. Capabilities are interesting and useful, but they aren't a panacea.
I think Sun calls that Java.
Although there's native support to network graphics, it's much too low-level and just generally broken.
??? Please elaborate.
Finally, as a lot of people often point out, most of the work in Free Software is still driven by imitation.
Indeed. Open Source/Free Software isn't about radical new software concepts, it is about radical new approaches to software design. (Well, actually, they're tried and true approaches to software design, but don't tell the press that.)
I don't think this is necessarily a Bad Thing. We steal from everywhere, taking what we like and leaving the rest. We then make sure what we have works, and works well. We do refine the concepts somewhat, making things more flexible and general, but we don't redesign everything. After all, you can try all the variations you want, but you always end up with a flat cylinder for the wheel.
<BASH TYPE=Gratuitous TARGET=Microsoft> I wouldn't want to take away Microsoft's Freedom to Innovate, after all.
In conclusion: unlike the author, I don't see that the GNU/Linux world is going the Anti-Mac way, quite the contrary.
I agree. And for more reasons then the ones you state. The biggest is that Unix folks are generally quite pragmatic. We stick with what works and don't try to accomplish radical new things that give us little benefit in the end. That is why we still use the same API Denis Ritchie and Ken Thompson designed. And it's why we still use X11 and the WIMP model. They work well.
Let's take a look at the so-called "Anti-Mac" interface concepts, in the context of what is being done today.
The central role of language
Basically, what this boils down to is, a voice recognition and command system with limited scope. I think we've already accomplished most of this, and I think we've realized it doesn't get you much. All you are effectively doing is using your voice instead of the mouse and keyboard. That isn't a particularly efficient way to get things done.
To truly get the benefits of the central role of language, we will need full-blown language recognition with not inconsiderate AI capabilities. Cliche as it is, the "Star Trek interface". And we're a long way off from this.
A richer internal representation of objects
Ironically enough, this is something Microsoft is pushing and doing, while Unix mostly ignores it. However, I can't help but notice that what MS has been doing seems to have the goal of tying everyone to MS Office. Not that that is a surprise.
I think it is only a matter of time before we see some sort of standard interface to application-level attributes. I mentioned this in another comment, but I think this is best done in a separate userland library, not tied to any particular filesystem or desktop environment. GNOME and KDE are both heading in this direction, but I consider that too far up the UI food-chain. This should be done at a level only slightly above the standard C library.
A more expressive interface
This is pretty much a non-issue, IMNSHO. What the authors describe in the original paper are pretty much gradual improvements and evolutions which would work equally well with traditional the WIMP UI as any other. For example, the file manager in mumble GNOME-related project mumble overlays little icons over the main icon of a file, to denote things you can do with it. Or take MS Windows. It does the same thing with the "Shortcut" icon overlay. It also has that "View as Webpage" option, which is a horrid implementation (again, designed to lock us into IE, not really make things easier) of a generally good idea: A preview pane which provides useful info about a document.
Expert users
This is another thing that would work well in a WIMP system, too. Basically, it says: Ease of use is fine, but don't make the system easy to use for the complete idiot at the cost of making it hard to use for someone with an IQ higher then 60.
It has long been observed that what the industry market-speak term "ease of use" is really several things:
Ease-of-learning: How quickly can you jump in and start using a program? Mac GUI does well here; Unix CLI does not.
Ease-of-use: Once you understand the system completely, how quickly can you get things done? The classic Mac GUI does poorly here, while the Unix CLI does very well.
Ease-of-administration: How hard is it for the people responsible for maintaining the system to keep the thing working? (This applies more to OS level stuff then application-layer code, but I mention it here for completeness.)
The "Expert users" part of "Anti-Mac" is simply the realization that one should not sacrifice ease-of-use for ease-of-learning. The old PC/GEOS environment for MS-DOS included a feature called "User Level", where you set the level of experience the user of the system had, from "Novice" to "Expert". Application programs could then adjust their presentation, hiding some features while enabling others. Unfortunately, you don't see this very often. (And, no, the "learning menus" of MS Office 2000 don't count. Everyone I know hates those things. That's not a good sign.)
Shared control
This is already being done, to a very limited extend, with things like Java and MS VBA. You let third parties provide some intelligence for your data. The problem is, of course, security. Java restores to running everything in (often poorly implemented) sandboxes, while MS VBA just ignores security completely. As previously stated, the hard part here is the complexity of mixed-mode security systems.
So, in conclusion, I don't think "Anti-Mac" is all that radical (today -- things may have been different when it was written). Most of it is already being done, to some level or another, and the rest isn't going to be feasible for some time to come. If ever.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
I wish CLI elitists would realize that the vast majority of people want a GUI that doesn't require and command-line parameters at all, ever. That's NOT to say that all CLI users are elitists, but it IS to say that there are many CLI users who not only consider it a more useful, better, and more "pure" way to interface with computers, but also believe as fervently as any medieval crusader that all users should either feel as they themselves do or need to be "educated" to have the same faith in CLI. These people are not just egocentric and want to force their own opinions on others, they are also actively dangerous to those who would like to see Free Software dominate the market for desktop workstations and home PCs as well as server and technical-user markets.
/. who say things like "We need to stop screwing around with making KDE and GNOME look like Windows and Mac, because people who want to use Linux should know enough to open a CLI window and go at it." Linux and Free Software will never take the desktop market from the big corporations with this attitude, because people who say things like that are coding for themselves and not other people. That's fine, if you want Linux to be a niche market for sysadmin and technical types, but then most schools and colleges will continue to teach with Mac and Windows and home users will continue to use Mac and Windows because the opportunity cost of spending so much time learning/teaching CLI is arguably greater than spending $120 for a copy of Windows. But if you want to build software that'll free most people from corporations like MS, then you have to start thinking like a non-technogeek.
How is it I can make these assertions? Well, they're all based on facts. The first fact is that the majority of people are spatially-oriented, rather than mathematically oriented. This has often been said of women, and is especially true of them; but it's true of most men as well. After all, what percentage of men major in math and computer science and sciences like physics which require extensive math, compared to the percentage who major in social sciences, language and literature, and sciences which aren't as math-centered (like biology, which requires some math skills but not extensive ones)? Math is simply not a priority skill for most people, but the problem comes when you have the geek community designing and discussing interfaces which are intended for non-geeks. The article in question, for example, propose an advanced CLI with language heuristics as part of their propesed new interface paradigm--but poll actual computer users, and you'll find less than five percent (pulling # out of ass, but I'd bet it's accurate) who'd be interested in having to learn such a CLI instead of using a standard contemporary Mac or Windows style GUI. The problem is, geeks live in a different culture, in which most of their friends and associates have far richer math skills and far more extensive desire to explore computers and interface with them more closely, than the average user or even the average advanced user. I manipulate literally hundreds of files of varying types every day, I configure applications and OS parameters very frequently using both graphical and CLI utilities, and do the type of work most geeks would say can be more efficiently done with CLI--and yet for me and for most other people, a CLI would be a cumbersome burden. Yes, you can do things faster with a CLI--if, and only if, you can a) type quickly b) remember complex sets of commands and modifiers c) count on those command sets and modifiers being standard across every platform you use, else confucion can arise, and d) have a good memory for where everything is located on you computer/network. But, if you type slowly then CLI is asking too much. If you have trouble remembering lengthy sets of commands, because you're not math-language-oriented or just because you have a bad memory, then CLI is a burden. If you use multiple CLI platforms with different command sets, it's easy for most people to confuse what to use with which environment (as contrasted to modern GUIs, which have comparatively subtler differences--a Mac user can learn Win98 pretty quickly, and vice-versa). If you have a poor memory for which files are where, a GUI is better for you because you get visual cues about your folder hierarchies and can list more objects at once than in CLI.
This isn't to bash CLI at all, or to say it's outdated. There will always be technical people who speed along CLI style and love it, and that's great. But it's a fallacy to think, as far too many geeks do, that even power users of today who grow up on GUIliciousness will ever want to learn arcane CLIs. The archetypal example is the small but vocal number of people on
That's where the authors of this article went wrong--they assume that as more people get more and more computer experience, that those people are going to want the richness and power of an advanced heuristic-based CLI mixed with the visual cues of an "expressive interface" GUI. But most people these days have the comfort and ease of use of an entirely graphical environment, which since we humans exist in a graphical world rather than a world full of letters and numbers and command lines, is far easier to work with than any CLI. Such users will never want to revert to a CLI, unless that advanced CLI gets to the point that it's as easy to use as the interface of the computers in Star Trek--where you just talk to the computer and it does what it's told in plain English. The authors of the article dismiss that as a "computational nightmare ", and they're right--so it's not going to happen any time soon that any sort of CLI will become popular, whether typed or voice-based, because of the ease of use associated with GUIs. The article also dismisses, as many CLI elitists do, the idea that a GUI can be as powerful as a CLI. Bullshit. It depends entirely upon the uses of the computer; even the best, fastest-typing CLI user would be entirely unable to sort through a folder containing several hundred files and separate them based on arbitrary criteria as quickly as a GUI power user could, because the GUI can list all the files and all their attributes and list them by whichever attribute you choose with a single-click, for arbitrary selection and transport. The article also makes the mistake of throwing out the ability for the user to sort his objects as he sees fit, into whatever hierarchies he finds most useful, in favor of multi-user standardization which doesn't allow you to work "outside the box" even on your own computer. Most people do NOT want "to share control of the environment between the user and other entities, specifically computer agents and other users"--they want to put things in the dir structures which are most convenient for them; this is especially and ironically true of power users, who like to arrange things for quick access in ways which multi-user system paradigms would not allow. The only way around this conflict of paradigms would be to have the user exist in a virtual environment in which he hass access to all resources in user space, while things outside user space are completely hidden from him--rather like the way Mac OSX will probably work; hiding the Unix system structure from the user, while nonetheless being Unix at heart with Mac behavior grafted on top. But then of course you'd alienate the true power users, who want to see and manipulate all that can be tweaked and changed to taste. So there's no way to win on this one.
In short, until computing power is sufficient enough and code is bug-free enough to execute commands based on spoken language with few or no errors, the CLI will never make a resurgence in any form among non-techno-geeks. I myself am a geek, but not a mathematical-minded CLI-loving one. The reality we have to start getting used to is that only a select few will ever be using CLI extensively--some of you may not like that, but that's the way it is.
"The more corrupt the state, the more numerous the laws."--Tacitus, *The Annals*
Do remember, however, that even though I drive a 1990 Toyota Camry, I can pop in ANY car and count on consistency. The gas will always be on the right. Steering wheel will always be right in front of me. Spedometer will always go clockwise smaller to larger numbers. Perhaps there are fringe exceptions, but part of the reason you only have to take driver's ed once is because cars are so similar in their operation.
Cars are several orders of magnitude simpler than computers. If a computer was a physical console, it would be monstrous, there are an almost infinite number of controls that exist on your computer that aren't directly visible. How many programs are in your path at the command line? Even if you use a windowing system, how many buttons and menu choices could you access if you navigated through all the menus? If there's not a standard way of accessing resources not directly visible to you, using a computer other than your own would be like completely starting over.
I'll grant that I don't know how involved the "user's own preferences" you propose would be. Preferences certainly exist today, in X more than any other system of course, but we're seeing that the price is complexity. Windows and the Mac are much easier to learn than X, because they are so standardized--you only need to learn things once. A new user obviously won't care (and should need to) what window manager they're running, what desktop environment this application belongs to, etc.
You mention skinning, and I fail to see how amazingly innovative skinning is. Skins in their present form (XMMS, Mozilla) are nothing but different ways of presenting the same information. So the button is blue with white stripes instead of grey. Maybe the buttons are arranged differently, I could almost see how this could help target different groups of users by stressing different parts of the UI. But we're still in the WIMP paradigm that has been only slightly modified since the original Macs.
I've thought about UI design changes a lot before. What I find more than anything is that it's very hard to think outside the box, because every computing task has been adapted to the current model, and so one involuntarily defaults to this mode of thinking. It's hard to imagine anything else.
One thought I've had is that since programs are written by programmers, they naturally think in terms of low-level concepts such as files, directories, input, output, etc. Almost every Windows Application in existence has a "File" menu with "Open," "Save," etc. This is a wonderful standard to have in terms of consistency in UI design, but it spotlights the fact that we adapt the application to the low-level concepts that support it, and not the other way around. Are there applications for which a "file" menu is not appropriate?
One thing I like about the article is that in looking for new ideas, it seeks to violate every one of the existing standards. Perhaps that's what needs to happen for innovation to take place. Also, in attempting to "think outside the box", we need to imagine different input and output devices. A mouse is well suited for the WIMP system, and relying on it as the primary input device somewhat locks us into it. What other kinds of devices could you dream up that could support other UI designs? A screen is the most standard output device obviously, and it's hard to fathom another, but again, what possiblities exist?
The Anti-Mac interface reminds me a lot of the current BeOS interface, though with obvious differences. BeOS isn't there yet, but it's on its way. Point by point:
Central role of language: Right now BeOS has a POSIX-compliant underbelly, which gives you the flexibility of a command-line interface alongside the normal GUI interface. The two are intermeshed practically seamlessly. While it doesn't have the fancy "interpreter" capabilities the Anti-Mac ideal proposes (like a spell-checker, which isn't such a bad idea) it IS a working CLI, so you have the strength of language alongside the ease of a GUI.
A richer internal representation of objects: All files in the BeOS have what's called "attributes", which are little bits of meta data stuck onto each file. This means that while your MP3 collection has the usual name, size, modification date, etc., it can also have attributes of title, band, album, bitrate, length, etc. These attributes can be on any file, and are easy to impliment, so you can make a special type of text file complete with author, chapter, and page attributes, all of which can be utilized in queries and so forth.
A more expressive interface: I'm still not entirely sure what this point means, but the BeOS has several key visual features, like distinguishable icons for folders (so your /mail/ and /people/ folders both look like folders, but you can tell which is which without even looking at the name). Little things like this make files easier to distinguish.
Expert users: Again, the GUI is there (and is much, much nicer to use than any other GUI I've used) but the power of a POSIX shell is underneath it. You can get a lot done the simple way, or if you're willing to learn a little scripting or some tricks (BeOS Tip Server is full of them) you can get a lot more done a lot faster.
Shared control: The BeOS isn't multiuser quite yet (should be with the addition og BONE in the near future) it's designed to be that way, in a typical UNIX style. Permissions, separate user directories, et. al.
The BeOS isn't nearly the Anti-Mac interface, but it's the closest I've seen since 1996. Hopefully the key principles will be kept in future development.
---
"Okay, who taught the cat how to type ctrl alt delete?"
- A file browser could show different icons for different sized text documents; a single sheet of paper for a very small file, a stack of paper for a medium sized file, and a book for large sized files.
- Depending on a file's creation time, the color of the object could be different, say a color of the rainbow for each day of the week. Of course there would be overlaps like in real life, but the way the mind works, you might remember it was the red one, which would make finding things easier.
- Files that were modified recently could be represented differently; for small and medium text files, leave a pen on top of the paper for a few days. For large files leave the book open.
- As the last access time for a file gets further in the past, the icon could become smaller or more transparent - up to say 50% or so. The most recently accessed files would stand out, but the others would still be there.
Obviously not all of these would work out wonderfully, but they would be interesting to see.Could we have Anti-Windows next? Take the basic principles of Windows design (slow, clunky, bloated, crash-prone etc) and reverse them and see what happens? :-)
Sounds good to me
The pro-Mac principles target the wretched masses who are so technically challenged, no?
NO.
The purpose of the Mac user interface is to enable the user who is not inclined to spend time needlessly learning technical minutia when he could be using the computer as a tool towards other ends. The point of computers is not computers, but as tools to be used to accomplish a wide variety of tasks.
It has nothing to do with whether or not you are technically challenged; I have worked with brilliant scientists who have no use for computers other than simple tasks like email and writing papers. It is about whether you see the computer as an end or as a means.
I've done some research in UIs for expert systems before; I read the original Anti-Mac article in 1996, and have been pointing to it whenever there's a discussion on user interfaces here at Slashdot. And while all in all this is a very good article, I don't believe that the Unix/X way currently embraced by most Free Software projects is the way to an Anti-Mac system, especially not as it is today. Why?
Well, first of all there's the issue of files. While Unix is almost entirely based on the notion of files, unstructured blobs of data, this paradigm is wholly inappropriate in the network-centric Anti-Mac world. What we want are high-level objects with implicit structure. Text files with XML structure are not good enough.
You also have to consider the issue of multiple agents. This requires a clear-cut, high-level model of interaction between systems, which, of course, doesn't exist (nor could exist) on Unix. A capabilities model would be more appropriate, but even capabilities by themselves aren't enough; the system should be developed in a high-level language itself, which could be used for remote scripting and automation as well.
Then there's the issue of the existing Unix UI systems - by that, I mean X. (Yes, I know about Berlin. I hope it'll be good, but I'm not holding my breath.) Although there's native support to network graphics, it's much too low-level and just generally broken.
Finally, as a lot of people often point out, most of the work in Free Software is still driven by imitation. This is true even (especially?) in GNOME, which is admittedly modelled after Windows' model of low-level, unsafe components with an accordingly brain-damaged user interface. I don't believe that a lot of people working on Free Software have done a lot of UI R&D (with some notable exceptions in the Eazel and Helix teams), so the general tendency for GNU/Linux UIs is (and will be, apparently) that of imitation.
In conclusion: unlike the author, I don't see that the GNU/Linux world is going the Anti-Mac way, quite the contrary. Perhaps some other, entirely new Free Software project might spring up which would be a better match to Nielsen and Gentner's vision; the Morphic UI system of Squeak is a very good start.
(Note: I'm not feeling too well, and I'm writing this kind of in a hurry, so I probably left a lot unclear and unexplained. I'll be glad to clarify.)
To the editors: your English is as bad as your Perl. Please go back to grade school.