Slashdot Log In
Towards The Anti-Mac Interface
Posted by
CmdrTaco
on Sat Jul 22, 2000 01:33 PM
from the future-of-user-interface dept.
from the future-of-user-interface dept.
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.
This discussion has been archived.
No new comments can be posted.
Towards the Anti-Mac Interface
|
Log In/Create an Account
| Top
| 208 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Very insightful, but a few questions (Score:3)
Anyone who is even remotely connected to UI development should read this article (especially the folks over at Mozilla). That being said, I have a couple of issues with some of their examples and ideas:
In conclusion, I offer my own disclaimer: I loved the paper. Anything above that may seem to be critical is only so in a constructive way. And finally: I can't wait for the Anti-Mac UI to arrive!
Re:Mac isn't bad, GUI is. (Score:4)
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.
don't agree (Score:3)
All I can see from skinning and UI schemes is a way to make something look cool but not necessarily function cool.
Your text-based input idea would not work well with graphical artists:
Computer, draw a slightly hazy sphere with a 20 to 50% gradient about 60 degrees from vertical starting and coordinates (120,35) on Layer 2 of the frontmost window
Please repeat command
On top of that, talking to a computer this way is slow and inefficient. How long does it take to grab a mouse/other input device and quickly click a few places and hit some command keys, as opposed to describing in excruciating detail what you want?
Pope
Freedom is Slavery! Ignorance is Strength! Monopolies offer Choice!
Some replies (Score:5)
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.
Exactly. I Wish CLI Elistists Would Realize... (Score:5)
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.
As a matter of fact (Score:3)
Ironically enough, Microsoft is already doing some of the things talked about in the original Anti-Mac article. Iin traditional MS fashion, though, they are done not to improve the end user experience, but to lock us into their products.
For example, MS Office already "extends" the file manager in Windows to know the "attributes" of an Office file, like the author and the date of last printing. (Lock-in: Only works for Office, though.) And Win98 has the "View as Webpage" preview pane, which is a horrible implementation of a good idea. (Lock-in: You have to use IE.)
Re:The future of UI design.. (Score:5)
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?
Interesting contradictions (Score:3)
I think a modal design is a mistake, in almost all cases.
A swimming pool you can only swim in is like a tractor you can only control with reigns... kind of limited.
Why can't I use the appliances of the future in the pool? Already some phones are waterproof, and some radios/TVs. Why can't my laptop be waterproof, etc?
So, why let someone else dictate the limits of a mode? I alt-tab away from install screens while they're copying files even though the program warns me that dire consequences await those who don't sit and watch the whole process. If the author of the program had their way (or their bosses/marketing department's way) I'd be forced to sit and watch this...
It's clear, to me, that modal designs should be limited to the program that the mode is in. An install screen for Winamp shouldn't offer to let you play MP3s, it's just to install. The panel for Winamp shouldn't have an uninstall button, that's not part of the 'play music' mode. But if Winamp tried to control what I did with the system while playing MP3s I'd delete it in an instant...
A mode is only as important as the program I'm running. The biggest problem Winamp could report is that an MP3 is corrupt... The biggest problem Photoshop could report is that a picture was changed on disk, etc. I want the program to halt what it's doing to give me a critical (from its point of view) error. But I don't want it to interrupt anything else.
And big future of interfaces that I can see is to leave a stateless interface behind. In the copying to disk example, not only should the mac empty the floppy trash automatically, but it should say "You're out of room on the floppy" and pop up a file browser to allow you to make room. At least it should have a 'Go There' button on the dialog to let you deal with the problem instead of just 'OK'. The dialog of the future would have "Ok/Stop" "Go There" and "Retry"... It wouldn't be the end of your copy, it'd just pause till you made some space, either by asking it for a browser or by doing it yourself, then continuing.
Cookies (etc) have allowed us to get past the stateless web page. Now you can have a shopping cart, or a slashdot profile, that reflects changes you made when you were last there and picks up where you left off. This is where we should be going. You shouldn't have to tell something what you want to do more than once unless you change your mind.
This is great to see (Score:3)
The fact is, there are some very important principles in MacOS that would apply directly to the 'Anti-Mac' interface- but, typically, do not. The single most important principle is structure.
On MacOS, the menu nearest to the 'Apple Menu' (which is always there) is the 'File' menu. It contains 'quit' and other commands including 'open' and 'close' and 'new' if present. Why? No reason- there's no reason why quitting should be considered a file action. But the structure is the reason- not structure in 'this is how we force developers to code a certain way' but structure in that the user can quickly form a mental model in which there is always this menu that says File, and Quit is in it. It's not important that the menu be called file, or that it be in a particular place- or even that quitting must be a menu action! The important thing is that the user jumps to a conclusion which continues to be valid across the entire interface.
The same is possible for text mode interaction- it just takes different forms.
I wrote a program [airwindows.com] for my own use to remind myself of things. It's not very elaborate (now that I have a small second monitor I might try making it more elaborate) but one way it works is very important in the Anti-Mac style of interface. It runs off a list of events that's kept, and edited, just as a plain text file (something that could be edited by other programs too), and you enter a date or day and event and priority.
The priority ended up being almost meaningless as a feature because there aren't loads and loads of events in the file- but it is important in another way because it is a 'punctuation mark' for the event data format, and that's where the 'user concept' comes in. Basically, the idea was to define a format which could be parsed quite forgivingly by the computer, but which did not get into full-on natural language parsing- instead, you are given one very simple rule. "Type date, then priority in parentheses, then the event text."
That's it. Friday(2) Visit Fred. Or Thu(e)Dance Naked. Or 11/3(1)Third Of December Day. Or just "Go Fishing" (which will always display, until removed. There is an expectation for US date formats, but it's opensource ;) ) The point is that you can get very weird with the data (for instance with the weekdays, it uses a string comparison routine that is case insensitive) but there is an element of structure to focus and direct you- one that is very, very simple to remember. Date(priority)Entry, and the parsing keys off the parentheses.
The reason this matters at all is because it's so easy with natural language parsing to get into a game of 'Do What I Mean', to get so seduced by the challenge of parsing weird inputs that you basically go, "Okay! The user's inputs have NO FORM whatsoever- complete freedom! That is the ideal interface!" That's a crock- the thing you want to do is present interface elements that must be learned, but the elements (textual, conceptual, graphical) are SO SIMPLE that they're nothing to learn. "Quit and file stuff are in File menu" is a very small piece of information when you think about how widely useful it's been made (do _you_ have a File menu in front of you right now?). "Date(priority)Event" is partly textual but it is just as easy to grasp and use- it's syntactically obvious, with the key concept being Parentheses- if you don't have the ( then it's a degenerate case like a quickie-note to be always presented.
There are similar issues to HTML- the bracketed tags like B and I (yes, I know those are stylistic not logical tags) are easy to understand- yet I have so often messed up in Slashdot posts by failing to close a bold tag properly or something- just repeating the 'b' with no / to close the tag. This is possibly unavoidable because of the complexity of HTML, but it's an interface screwup because when typing a message the user does not use the tags the same way as the computer does. To the computer it is an opening and closing tag (entirely distinct entities). To the user the tags are used more like toggles: you hit (b) to turn on bold, and then hit it again to turn it off, only you have to remember to make it (/b). In the flow of writing it's easy to fall back on the opening form of the tag and use it as a toggle- which of course does not work. The funny thing is, it's as if the special closing form is used to make sure that you remember to keep track of the 'stack' of tags more easily- instead of having to count instances of a tag (which the computer can easily do), but if you do forget to keep track the result is just the same as if you treated the tags as toggles and failed to close them with the special closing tags. The result is a special form of the tag to be kept track of by the user, so that the user must be aware of not only 'entering/leaving styled area' but which way you're going- and if you don't correctly specify, the HTML screws up. Treating simple 'off/on' tags as toggles (granted, much HTML can't be reduced in this way) makes the mental model of the style setting much simpler- "hit (b) tag to switch boldface on and off", and suddenly you don't have to keep track of phase at all, only the opening and closing locations of what you want to stylize.
There is no reason this capacity to define simple behavioral models can't be used to improve text-based interfaces, or even Unix shell. Of course, it's mostly not ;P you have certain things. Typing a letter causes it to appear on the screen! Hitting return executes commands (woops, unless you're in a subshell, then it's what, ctrl-D?) Arguments for programs take the form -a -r -g -s, unless it's -args. And so on- the problem is NOT that it's a text based interface, or that it requires learning, the problem is simply that so little of the learning is globally applicable- but that can change. Not with Unix shell, as it would be throwing away a lot of backward compatibility- but in any new text or hybrid interface that comes onto the scene.
I'm picturing a sort of 'agent', but one that you talk to in clearly defined forms and not natural language. It'd be there ready for input or puttering along keeping an eye on things and you'd type Fiday(2)Get ready for job interview! and hit return, and because of the (2) it would know you meant to make an entry in the day-planner, and would figure out from context that 'Fiday' (a real typo that I actually typed just then, fixed, then put back for purposes of the argument) was Friday. You'd be working on something and would suddenly realise that you hadn't coded anything game-related in months and would type Games++ and hit return and it would understand from context that you were establishing a priority level in a simple 'geek code' sort of way- and it might also have the job of sorting your mail and would keep an eye out for 'Games' and sort it up higher based on this new priority level (which you may have just created by typing that). Or you'd read Joakim Ziegler's article and in a fit of admiration type Joakim Ziegler++++++, an 'item' that might never come up in email, but if it did you'd not only be given a priority boost, but would also be reminded that there was something about Joakim Ziegler worth remembering and paying attention to. And the ability to, dare I say it, 'intuitively' plug this things into the computer is the ability to not rely entirely on your own head for all that.
But the important thing is not to devise the most sophisticated arrangement for such things, not to devise the most fiendishly clever way to get data out of sloppy natural language- the important thing is to come up with these simple strokes that can become internalised rules. I happen to think Fri(2)Friday Meeting is a very sensible 'form' for a reminder, because for some reason having a 'priority' there in parens makes sense for me and serves as a suitable 'punctuation mark'. By the same token, you can't go wrong with strings of plusses and minuses to indicate the changing of priority levels for a keyword or key phrase. Possibly the exclamation point and question mark can be used similarly- for instance, the 'agent' might react to OpenGL?(return) by a quick search of other entries in its databanks for things that match this. It becomes even handier if you say Rob Malda? and the agent gives you references including his email address and phone number because you'd entered them into your address book :) You might even end up with web search results if you set it up that way. The exclamation point might serve as an indicator of a command- Slashdot! would launch your web browser and point it at slashdot, email! might be set up to return the 20 highest-priority emails you currently have. The 20 would be a setting kept in some other place- the interface of it would not be about going email-20-all-mail-agents! (unless you really wanted to be constantly specifying all that), it would be about going email! and also being able to go set up email! and have the control panels right there. And of course the basic assumption here is that the exclamation point distinguishes running programs from other actions- it seems fairly obvious, and that is a _good_ thing.
*g* time for me to start working on this I guess ;) it's sounding neat enough that I'm getting pretty interested in exploring it ;)
Face it, GUI's are even more primitive than CLI's (Score:3)
No; most people are verbally-oriented. The ability to visualize and juggle spatial concepts is less common than the ability to describe, narrate, and request things. The special skill of the mathematician is one of expressing in symbols things that ordinarily can only be visualized. In other words, mathematicians (and good programmers) have the ability to formulate and utilize abstractions.
Nonetheless, there is a lot that could be done to make GUI's more useful. Take a look at how limited most GUI's are in terms of their use of visual metaphor: click, drag, drop, click. Things that wouldn't tax a 3-year-old. You would communicate with a real visual interface by drawing, by gesturing, by manipulating a visual representation in much more interesting ways than merely clicking and selecting.
No, today's GUI's are just more compact versions of the menu interfaces of yore, with nice pictures instead of words but with little else that utilizes visual intelligence. We use them because we don't know any better. We use them because, like earlier text menus, they take advantage of the fact that the human brain is much better at recognition than blind recall. We use them even though they make little use of the visual realm.
MS Windows and MacOS have done the same thing to the GUI world that Unix did to the CLI world: they are "good enough" that no one has managed to step back and start from scratch, questioning the assumptions that were made 30-odd years ago at Xerox (for GUI's) and Bell Labs (for CLI's). It would be a monumental effort at this point, given the enormous inertia and mental stenosis that affects the industry. We should salute anyone with enough guts to try and take UI's beyond the mental world of the 3-year-old.
BeOS is on its way (Score:5)
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 [betips.net]) 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.
---
A richer representation of objects (Score:5)
- 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.The Next GUI Paradigm (Score:3)
So what is the the next GUI paradigm. I am not sure---indeed, how could anyone be. Some people are of the opinion that everything is going to end up on the web in HTML and Javascript. Please. That would be a horrible interface. HTML is meant as documentation markup language and Javascript was for those who thought it should be more.
Then there are those who beleive we are going into the VUI era. While I am inclined to agree, in part, some people take it too far. There are certain things that voice is suited to and that is simple commands and queries. But even the crew of the Enterprise-D went to a console to get the real work done. I would never want navigate a filesystem by voice, it would take too much memorization (provided you are not at the computer) and would be much slower to what we have today.
Then there are the advocates of the 3D interface. It is the logical succession of the 2D interface afterall, right? Well that is true but unfortunately it is not so simple. The eye can only see things in 2 and a half dimensions (the half because the two eyes can somewhat percieve distance) and any more than that then we might as well be wondering around a 4th dimensional maze (an exageration to make a point). A principle of UI design is that there should be visual clues as to the presence of interface objects but if such objects are behind other objects, how is the user suppose to know that they are there?
So is the interface stuck? Perhaps. But we must consider what it is users do with their computers that requires an interface.
Forget about the word processor and the spreadsheet. Personal Computers have been able to perform these tasks from the beginning, even in the age of DOS. People do email and browse information, often on the web. People play games. But this only the average user. The interface of the future should consider all users. This is perhaps the largest difference between the interface of the future and that of the past.
Consider the tasks of all users. From the software developer to the web developer to the engineer to the secratary to the airport personel. The thing you should notice is that the interface must be different for each. One overpowering interface, in the future, will no longer do. In fact, the merits of the windowing enviroment seems to only be useful to a subset of all users. Certainly airport personel should not need a taskbar or a main menu with a list of applications when they would only need one application at all.
But these kinds of considerations seem to go against many of today's principles of user interface design. As of now, I do not know how this can be reconciled but the Anti-Mac article does foster a clue. That perhaps the usability principles need to be changed. I like what the guy has to say. He questions every common convention in modern user interfaces. He puts us well on the way toward the next GUI Paradigm.
Re:Interesting... (Score:3)
It's not terribly usable, but the increase in speed now that I've started mousing and typing with the tentacles growing out of my face more than makes up for the lack of a consistent desktop metaphor.
--Shoeboy
Interesting... (Score:4)
Sounds good to me
Only the metaphors of this article make any sense. (Score:3)
For example, the proposed motivation for violating the Mac "Forgiveness" principle was weeak! No one gets mad when they have to click through one more warning in an unprobable situation like the one they describe, if they can in exchange feel secure that all of their actions will be reversible for a while.
In fact, one problem with Windows, and to a lesser extent Mac and Linux, is that the reversability principle that falls under the heading of Forgiveness is constatnly violated. When I install something into Windows from the internet I have to pray that it has an uninstaller, because it sure as hell isn't going to tell me where it is putting all of its files, and what lines of the registry it is modifying. And even most GOOD uninstallers don't fix your registry. RPM and DEB are a pretty good solution to this in Linux, but how much fun is it to uninstall WordPerfect 8? Or KDE? I have a feeling no one really tries; we just install fresh, because by the time we muck up our drive enough, our favorite distribution has released a new version. This does not cut it in the way of reversability.
In short, there is nothing to be proud of in violating the Mac design principles. It might have a pleasant "look, I'm a bad boy!" feel to it, like using profane words or screwing some chick in the butt used to have for me when I was in grade school--but come on, people, let's grow up!
Probably the best way to accomodate to new and advanced users at the same time is to start with an intuitive interface which is hard-core customizable. And I mean more than just E or something we have now. This is where Linux beats the Mac interface--because the Mac people are too afraid to let users customize the interface (and it looks like this won't change much in OS X). For tedious operations we write scripts, and for all I care, if they program some friendly voice that helps me write it, that's fine with me, as long as it doesn't remove any power from what I'm able to do. The nice thing about this "newbie default, rich customization" attitude is that it's self-regulating. Newbies don't seem to mess around with complicated preferences until they are to a large part over their newbieness. But then, at least in Mac and Windows, they hit the program's ceiling and aren't able to customize any more. This is what needs to get fixed.
The solution isn't some language-based agent living in my computer with whom I negotiate an action. No way! My computer should be my bitch and to exactly what I tell her to, and nothing else. Most of the configuring I have to do in Windows involves turning shit OFF that they have on by default. (Including the paperclip!) No thanks, I don't want an OS that's more autonomous than Windows; I want one that's less. I'm not quite a newbie user, but as I taught my mom Win95 she was almost demoralized by how unpredictable everytihng seemed ("Why is the program capitalizing that word for me?"), and how easily she might screw something up. So it's not just me that wants my computer to behave predictably.
Interfaces are subjective... (Score:3)
The idea that interfaces should be a one-size- fits-all implmenation is what needs fixing.
Re:1996 may as well be a thousand years (Score:5)
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.
Some things (Score:5)
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.)
File attributes (Score:3)
Personally, I think this is better handled as shared user-space glue code which all applications make use of. One of the design goals of Unix (for better or worse, although it seems to work well) is to keep everything in small parts. Rather then building application file attributes into the code file system (where, really, they don't need to be), invent a libFileAttributes (or whatever) API that provides a consistant interface. Kind of like file(1), mailcap(4), and a few other things rolled into one. Indeed, such functionality might be best implemented in terms of these existing tools.
Projects like GNOME and KDE are heading in this directory, but my only real beef with such efforts is that they are generally being done at too high a level. File attributes shouldn't require a GUI to function.
Re:File attributes (Score:3)
Of course, your assumption that "where, really, they don't need to be" isn't necessarily true either; in a lot of applications, the metadata are just as important (or at least, accessed as often) as the associated data. In this case, it would be a really bad idea to impose an additional layer of abstraction between them.
I found this particularly curious:
One of the design goals of Unix (for better or worse, although it seems to work well) is to keep everything in small parts.
Keeping everything in small parts is a Good Thing, yes. But it should apply at a finer grain: instead of having a thousand statically-compiled (from one single big-assed C procedure) programs of a few dozen K talking to each other through a half-assed character stream system (piping? WTF?), it's better to have a million dynamic modules of a few hundred bytes, with well-defined interfaces in a high-level declarative language. And then it ceases to be the Unix philosophy, and becomes the (much better, IMAO) Lisp Machine philosophy!
(Note that my +1 bonus remains turned off
MacOSX anti Mac? (Score:3)
Re:this makes me sick (Score:3)