Towards the Anti-Mac
Posted 22 Jul 2000 at 03:59 UTC by Radagast
A couple of years ago, I read Don Gentner and Jakob Nielsen's The
Anti-Mac Interface, thinking "It'll be a while before any of this
reality". Recently, someone here on Advogato mentioned it, and I thought
sit down and read it again. Much as I remembered, it was an excellent
but unlike the last time, I thought I could see the seeds of the
systems developed as free software today.
The original Anti-Mac paper
The Anti-Mac paper was written in 1996 by Don Gentner, Human Interface
Designer at Sun Microsystems (where he still works) and Jakob Nielsen who was then a a Sun
Microsystems Distinguished Engineer, but now is at Nielsen Norman Group, and is most
his books on UI engineering, and his Useit.com web site.
For those unfamiliar with the original paper, I'll sum up the philosophy
the five basic principles of the Anti-Mac interface here. This is no
replacement for reading the paper, though, so go and do that now.
specifically need to do that to see how these principles are directly
to some of the basic design principles of the Macintosh interface.
original paper has better prose. When you come back here, you can safely
the summary, I add nothing new in it. If you've read the paper before,
and would just like a reminder, this summary could be useful.
The paper goes something like this:
The original Unix text mode interface was perfectly suited to the user
it was made for, a group consisting mainly of hackers, who had the time
interest to understand the system and figure out how to use things like
system's utilities and pipes, and who also manipulated relatively few
objects, mainly the files in their own code, text files, and so on.
Macintosh interface was also very well suited to its target audience,
workers with little or no computer science background, who wanted to
moderate amounts of graphic documents.
The Anti-Mac interface as outlined by Gentner and Nielsen is aimed at a
group of users, which they believe will be dominant in the future (the
as seen from 1996, there are signs that this group is emerging at the
People with extensive computer experience (although not necessarily a
background) who want to manipulate huge numbers of complex information
while being connected to a network shared by immense numbers of other
computers. Using this as a starting point, the paper postulates five
principles for the Anti-Mac interface:
The central role of language.
This is a
bastardized command line interface using heuristics and being able to
the user in a two-way "conversation" to determine the action the user
take. It's not a natural language interface, instead,
and Nielsen propose something along the lines of the parser in text
games, which deals with a reasonably large number of syntactical
while still not being the computational nightmare a Nat-Lang parser
A richer internal representation of objects.
is basically a set of meta-data for objects. In traditional file
interface has access only to a small amount of information about a file,
instance. The only known information may be name, size, modification
type, and user that owns the file. The Anti-Mac interface would make
a much richer representation of the file object. In the case of a
this might include the authors, topic matter, keywords, and importance;
there are other copies; what other documents it's related to, and so on.
implies a form of structured document format (the original paper
today we would probably apply magic XML pixie dust).
A more expressive interface.
representation can be transferred to a more expressive interface. The
GUIs, for instance the Mac one, were designed to work on 9-inch displays
less than 200,000 pixels, while a modern 21-inch display running
same interface has more than 2 million full-color pixels. It's expected
this trend will continue, and the Anti-Mac interface should take
it, using the increased visual definition to give the user more
information about the objects she's seeing. The example used in the
paper is that of a bookshelf, where the books' spines have a wide
appearances, yet are all clearly recognizable as books. The variation in
appearance makes it easier for you to find the book you want in the
While today's user interfaces (in particular the graphical ones) are
typically oriented towards ease of learning, there's a trade-off between
of learning and ease of use, power and flexibility. Just as people
spend a lot of time learning a complex language such as English, so they
enjoy the rich communication they can accomplish using it, future users
spend a lot of time communicating with computers, and we should take
consideration when designing the interface.
As opposed to a contemporary user interface, where the mantra is to
the user's things where he left them, and preserve state and perceived
stability, the Anti-Mac interface proposes to share control of the
between the user and other entities, specifically computer agents and
users. This allows the user to share information with other users, and
tedious tasks performed for him.
The original paper ends on a slightly sobering note:
person who reads the preceding outline of the Anti-Mac interface will
it is mostly impractical with the current state of computers and
software. Language understanding is still in its infancy; most of the
population are having their first encounters with computers; and most
know better than to trust computer-based agents with a free rein on
Where are we now?
So what was interesting when rereading this paper now, was that there
tendencies towards these design principles in a lot of modern free
software. I'm uncertain whether or not this is intentional, but I
with the possible exception of some corporate efforts, it's not. It
that we as a community, after getting criticized for not being
(meaning, really, newbie user friendly) for a long time, have
set our aims at creating an interface for tomorrow's users. This might
smartest move yet, and we didn't even know we made it.
In fact, it might seem that the path from UNIX text mode interface to
interface is a lot more natural than from Mac or Windows to Anti-Mac.
instance, the typical X screen, be it using GNOME, KDE, Afterstep, or
a lot less metaphor-laden than a Windows or Mac desktop. Where the Mac
Windows desktops show your computer, containing different drives,
over the desktop, etc., this is much less common on an X desktop. The
Windows interfaces are centered a lot more around a metaphor driven
folder, document) experience than the X desktop, where, even though file
managers exist, users are more likely to open a shell window to
Also, ever since CDE, all the way up to GNOME, X desktops have typically
launcher panel, which can contain buttons to start applications or
other actions, as well as embedded programs that show system
interface is a lot more abstract and power-user oriented than the "let's
your office" metaphor of the Mac. Notice that Windows has actually moved
from the Mac interface lately, towards more abstract representations of
user's environment, with such things as the task bar and start menu,
files", and so on.
Meanwhile, in the background, we've developed and actively use powerful
for cooperatively creating, modifying, and publishing information over
network, such as CVS and Apache (specifically Apache with the recent
functionality). While CVS is very probably not ideal for generic use
being stretched way beyond the original intent already), it's a great
of how free software and Unix culture is steeped in a philosophy very
compatible with that of the Anti-Mac interface.
I'll present two examples of recent free software that I believe embody
the principles of the Anti-Mac interface. I apologize beforehand that
examples are very GNOME-centric. I'm
this is a result of my close involvement with GNOME, and my lack of
in-depth knowledge about other efforts. I'd love to see examples from
camps in the follow-ups. In addition, of course, both these pieces of
are pre-alpha, so I'm going from descriptions, my tests of unstable
Nautilus, developed by Eazel and the GNOME community, is an
example of moving in the direction of the Anti-Mac interface. It
feature a much more expressive interface than most file managers,
both the data inherent in the Unix file system, such as write
the like, and thumb-nailing the information contained in the file inside
icon. It also effortlessly retrieves and uses meta-information from a
variety of data object types, displaying most of them effortlessly by
viewing components. In addition, it nicely bridges the gap between local
objects and network shared objects, with support for FTP, HTTP, WebDAV,
on. What's not terribly Anti-Mac about the Nautilus interface is that it
relies a lot on direct manipulation (drag and drop), with all the
this implies. Thus, it doesn't go as far towards an ideal Anti-Mac file
as it possibly could.
Helix Code (which happens to be
employer) also has elements of the Anti-Mac principles. Specifically, it
pervasive implementation of the shared control principle, sharing
with other users and, to a certain degree, with computer agents. Email
area which is inherently influenced by other users, if nothing else then
their email arriving in the user's inbox. However, Evolution's
appointment scheduling lets other users request appointments to be made
user's calendar. In addition, the user can define vFolders, which are in
practice the result of running a search on all incoming email.
running searches with an automatically updated list of results is one of
more common elements of agent technology. It also indexes a lot of
about each email stored, giving a rich internal representation. However,
Evolution is not strongly Anti-Mac like when it comes to metaphor use,
instance, it uses the folder metaphor for storing mail (if nothing else,
in name), which can be a limiting metaphor when it also implements
such as vFolders (where an email can, in essence, be in more than one
So, where does free software dovetail with the Anti-Mac
where do we still need to do work? And, more importantly, do we want
It seems we're doing reasonably well in terms of a metaphor-less
geared towards experienced users. Networking also tends to come easily
software, so at least the right infrastructure for shared control is
into place, although the actual services are still a bit lacking. Our
interfaces are getting more expressive, although this puts a heavier
graphics artists and others directly involved with the look of the GUI
not enough to have the pixels and colors, it also needs to look
feel intuitive. In this area, we certainly have quite a way to go. We're
doing pretty well when it comes to richer internal object
practically all free software of any size using XML as a storage format,
rich metadata capabilities.
So the area where we're furthest from the Anti-Mac interface seems to be
first principle, the central role of language. There's not much progress
this area, probably a rebound effect from us recently "getting out of
primitive text-mode interface and into the drag and drop GUI", but it's
definitely an area worth researching. Luckily, with component systems
Bonobo exposing the interfaces of components in a language-agnostic way,
doing the perfect groundwork for a good seminatural language interface.
basically needs a good parser, a set of heuristics, and some glue code,
could have a language-centered interface quite quickly. (Note that while
personally tend to doubt most predictions that voice-control interfaces
become totally ubiquitous, a good text interface like this would be an
excellent basis for a voice interface).
In addition, we should probably work on cooperating and integrating with
service providers. This might prove to be the holy grail, a working
model for free software companies. Agents, for instance, when done
require servers to run on, direct access to databases, etc. The Helix
updater is one of the few examples so far of integration with services
shared control (indeed, keeping your system up to date seems to be an
arena for shared control scenarios, not least because free software
develop very quickly). But a true agent system should go much further in
it can do on its own, yet the interface to request a specific task from
agent (say, monitor news media for items about a specific topic) isn't
much more complex than creating a vFolder in Evolution, a task that's
solved using a druid.
This matter of initiative on behalf of the agent is the
explored part of the shared control principle, probably because it's
dangerous ground. If the agent acts on its own, it doesn't take many
before the user will just disable the agent completely, fearing what
might do wrong, and that this will result in loss of valuable data.
the concept of shared control seems to creep into more and more free
company business plans, we need to do devote work to agent technology.
is that it'll benefit greatly from a flexible, yet simple language for
communicating the user's needs to the computer, as mentioned above. Raph
pointed out to me that web search engines seem to be the closest we have
widely used language interfaces today, and there is probably a lot to be
learned from this. Of course, search engine queries are a lot more
scope than what would be required for a more general language to talk to
machines, but I'm still convinced that we could end up with something
lines of a text adventure command parser (which most people manage to
effectively after just a few minutes of trial and error).
So, do we really want to move towards the Anti-Mac
I'm rather convinced that we'll have to sooner or later, so it might be
move to at least figure out how we'd like to do it now. In addition,
be a great opportunity for free software to stop chasing taillights when
comes to user interfaces, which, let's face it, it's been doing for the
years. In many instances, it's even been chasing the taillights of
have in turn been chasing the Mac interface, not exactly a model for
innovation. Given that the prediction of the original paper, that
today will be much more computer-literate than the current generation,
require a very different interface, seems to be coming true (maybe even
than the authors imagined back in 1996), and that free software seems to
way to go for software in the future, it seems only natural that we
the first to greet the new (or GNU) generation with tools fit for them.
Wow, posted 22 Jul 2000 at 07:06 UTC by julian »
I was just re-reading some of the anti-mac stuff a month ago, and a lot
of similar thoughts came to me. It really would be cool to see that
newer commandline interface be developed.
I think that because we develop most the pieces which we need, we will
see the anti-mac interface come quickly, just because a lot of us are
designing things to be easy to use, yet powerful enough that we don't
have to use the console for most things. Which is kind of where the
third group of users falls.
As far as nautilus using traditional drap-and-drop... we'll see where
that heads, but I'm pretty sure someone will find a way to extend it as
Maybe the central place of language is not properly in "establishing a
dialog", but rather in making all the important operations and states
accessible to scripts where we can say arbitrarily elaborate and
precise things about what we want.
I suspect the best way to connect scripting with direct interaction is
routinely to generate a log of script commands formatted to make them
easy to turn into useful scripts. Such a log would double as a much
superior substitute for the "auto-save" feature we see in some editing
Yummy, posted 22 Jul 2000 at 09:09 UTC by CentralScrutinizer »
I really like this article. It's a refreshing view on interfaces with
computers, one that brings something new to the table.
My desktop is littered with little information applets. I've got a
stock ticker and several system monitors running. If I found good ones,
I'd have a headline ticker running. I think a system ticker that shows
log files (agent logs) would be useful too (wasn't someone writing
something like this?). Anyhoo, they are just agents telling me stuff in
a non-intrusive way. Very useful.
I beleive hackers are already implementing their own agents. People
have little scripts that gather news headlines for them, or they let web
portals do it for them. As the author says, it sounds like Evolution is
moving in this direction of providing agents closer to the user,
providing very customized data. I'm very excited about this.
Finally, I wholeheartedly agree that interface design needs to move
forward to accomodate people who find computers intuitive. I've often
said that the learning curve for Windows is a plateau, while the
learning curve for Unicies (sp?) and Free operating systems is pretty
much as steep as you wish. As there is more and more to learn, know,
and keep up with, the Anti-Mac system will become more and more useful.
CentralScrutinizer summed up my reaction in his first line.
We might be moving away from metaphores a little but, but we still have
lots. Looking at my screen, I see: "desktop", "windows", a "mixer"
(asmixer), a clock+calendar (asclock), and a folder metaphor (xchat's
Xmms illistrates the problem with excessive use of metaphores. Like most
mp3 players, it tries to look like some peice of stereo
equipment down to the eject button and the graphic equilizer and the
pseudo-lcd display. I find the eject button confusing, and the graphic
equilizer limiting. It also has what I'd think are fastforward and
reverse buttons, but they actually skip tracks. Maybe I'm too used to
tape players. This is a bad use of metaphor.
On the other hand Lavaps
does embody a metaphor: a lava lamp with blobs representing
processes, but it's a pretty contrived metaphor and you have to read the
docs to learn that. The metaphor isn't the point.
Lavaps is the result of an intruiging user interface design methodology
Computing. It's not immediatly obvious what the way the little blobs
in lavaps move, their size shape and color, have to do with the
processes on your system. But keep it in sight for a few days, and
you'll start to subconciously notice things. Now I know netscape is too
big because out of the corner of my eye I see its bloated blob in
lavaps. I'll know if I have a fork bomb running because of all the
dots. I'll know I have a ton of programs swapped out, because they'll be
dimmed out. And so on, all subconciously. Is this an agent? I dunno,
but it gathers lots of information and boils it down in a way that lets
me grasp it intuitively (and does a good job of letting me get facts out
of it when I need them too).
Radagast, thanks for the interesting essay. I know you're writing
primarily about free software, but I think the other major trend
afoot in ui design which is to move things to the web. Advogato itself
is of course an example of that. Consider how many of the original
anti-mac points the Web espouses:
Metaphor: the web is not a metaphor for anything in the real world.
Rather, it seems to be a rich and powerful metaphor in its own right.
Direct Manipulation: the web is not based on dm.
See-and-point: actually, the crappiness of interactive html has led
people to forms as the primary mechanism of interaction. These, of
course, are not visual at all, so the semantics tend to be much more
User control: this is interesting. Very interesting. In fact, I think
one of the great advantages of the navigation "metaphor" is that people
get to control where they are. This came home to me when looking at chat
rooms - the early Java rooms were much, much more polished than the
early "type your message into a form then reload" html rooms, but they
didn't catch on. My analysis was that people didn't like the feeling of
being in the little Java box and not being able to seamlessly move in
and out using their familiar browser nav controls.
Feedback: the web is obviously poor in providing feedback. Note,
however, that your browser provides generic feedback about the
connectivity to the remote site. This is something that users of
distributed apps need, and which most non-web distributed apps
mistakenly try to hide.
Forgiveness: I'm not sure how this fits in. I think it has something to
do with the back button though.
Perceived Stability: <snort/> Actually, they use the Web as an
Aesthetic Integrity: see above
Modelessness: here is the navigation metaphor is pretty strong. Note
that their example is framed in terms of "where" you are. Likewise,
your set of actions at swimmingpool.com will of
course be quite different from those at kitchen.com (the relation that
these examples have with real swimming pools and kitchens is,
of course, a different question).
Re language: one of the primary navigational interfaces to the web is
search engines. These are probably the hottest area of language
processing today, and support interesting diversity in the the style of
the query. For example, I find myself using google when I need
authoritative sources, and altavista for more powerful raw keyword
queries. Presumably, there are other people out there happy with the
fake natural language queries supported by askjeeves.
Perhaps it's no coincidence, then, that we're seeing some of the
Anti-Mac designs coming about in the confluence of free software and
the navigational metaphor, for example Nautilus. It's certainly going
to be interesting to see where all this goes.
now on /., posted 22 Jul 2000 at 20:15 UTC by jschauma »
Maybe it's redundant to point that out, but this excellent article is currently
being discussed over at /.
Well, I guess *it* is redundant - you geeks all read slashdot
anyway. Shouldn't have posted this. Sorry ;-)
Lots of great response here, so I thought I should follow up. I'll try
to do it
one point at a time.
ncm: I think that exposing the internals of the system
arbitrary scripting languages is one half of the way to getting language
the interface. The other would be a language shell with a near-natural
language, using the exposed mechanisms. Most people don't want to
down and write scripts, but if they had a shell that let them
what they wanted done incrementally and in an intuitive language, that
work. Something like a cross between a shell, the interactive Python
interpreter, and an Infocom game. It should also be able to handle
temporary sets of objects, so you can do selection and execution in two
(the need to do both at once is what confuses a lot of people about
command-lines). The level it would be at is something like
> take all jpegs in my home directory that are newer than two weeks
Ok, 23 files taken.
> drop the ones that are larger than a meg
Ok, 4 files dropped, holding 19 files.
> Which files are you holding?
> move them into the dir miscpics
23 files moved into the dir, which already had 213 files in it.
> convert the filenames to lowercase
Converted the names of 23 files to lowercase.
[At this point, the user changes his mind]
> move them back to my homedir
23 files moved to your homedir.
[If the user had said "move them back to /usr/local/share/pixmaps" for
instance, the parser could have noticed that this set of files hadn't
been in that dir, and asked the user if he was sure]
And so on. This isn't *terribly* different from a normal shell, it's a
typing, though, but notice how it would make some tasks that are
normal users (like lowercasing filenames) easy, and also how it holds an
arbitrary set for as long as it's needed, so that you can back out on
you've done, even though you've mixed the set of files into a dir with a
more files. This sort of language parsing is not computationally
(it's at the level of an advanced text adventure, indeed, Hans Petter Jansson
command parser for pseudo-natural English which could deal with parsing
examples above easily (as well as quite a bit more complex sentences).
shell had some memory of sets it had handled, it would be even more
(being able to talk about "the set of HTML files I moved from my homedir
week", for instance).
In addition, it would be useful to be able to perform operations on the
inside the files using similar syntax, for instance being able to do
replace in documents. This would mesh nicely with the rich internal
representation principle, where you could select objects into sets using
This would work out to be a pretty powerful way of handling your files,
believe me, if you have a dir of a couple of hundred files, and need to
out some of them based on complex criteria, and then perform a series of
operations on the selected files, this is the best way of doing it. The
alternatives would be using find (for the poweruser, non-obvious syntax,
or selecting manually in a GUI file browser (cumbersome and
This sort of shell would require reimplementing and/or wrapping a
large set of existing shell utility functionality, so it would probably
implemented in a high-level language, where it could reap the benefit of
existing modules in that language. Python is closest to my heart, of
would be interesting to do some prototypes of this.
CentralScrutinizer: You're right, people are writing
little agents. However, there's definitely a need for a generalized way
doing it, say, an agent wizard where you could define what you wanted
syntax similar to the above, and the agent you created would speak HTTP,
NNTP, and parse HTML, XML (including things like RDF and other common
course), Usenet and mail headers, and so on. It's not that people aren't
it, it's that we need to stop equating computer-savvy users with
programmers. Those are two different things, and you shouldn't need to
programmer to be a power user.
Joey: Actually, XMMS' stereo-like interface metaphor
that terrible, as metaphors go. After all, what you want to do with an
player maps pretty closely to what you can do with a real-life CD
including playing, pausing, skipping tracks, ejecting (changing to a
set of music, really) and so on. It's interesting that the computer UI
metaphors that seem the least contrived are the ones that emulate a
electronic device, as opposed to those that try to emulate a more
conventional object with obvious cause and effect (such as a trash can,
desktop with papers on it). This is actually an argument in favor of the
anti-mac interface, since a stereo component doesn't show you its inner
workings, and does immense amounts of behind the scenes work to respond
commands, yet people learn to master the interface fairly quickly.
Thanks a lot for pointing out the Calm Computing philosophy to me. I've
barely heard the term before, and I'm a bit embarrassed, since it seems
to be a
pretty central and well-known idea. So after reading a lot about it
I've been thinking about how the principles could be integrated into a
"desktop". The original works seems to be concerned mainly with
in physical space, but I think there are a lot of ways it could work on
computer screen too (this meshes it with the Anti-Mac idea, since that's
on the concept that the user spends a lot of time in front of the
sure there are many ways in which the computer could convey useful but
non-vital information to the user without it being too explicit, and I
I'm going to spend some more time thinking about the possibilities.
Advogato: Yes, you're very right, the Web in many ways
embodies the Anti-Mac, at least since it breaks a lot of the Mac user
guidelines. Yet, the web has many other problems that wouldn't plague a
anti-mac interface: The response time is poor (although this is steadily
improving), the interface is not typically very expressive, there's not
rich internal representation of objects (indeed, most web site back-ends
extremely primitive, and need to be, to optimize for speed of response
under heavy load). And so on. I think the web is a forerunner for
services that integrate more with the rest of your working environment,
the web into your applications instead of the applications onto the web,
will. It's going to be an interesting time up ahead, though.
fuzzy logic, posted 23 Jul 2000 at 15:13 UTC by jschauma »
, your example of the intuitive shell reminded me of this
in my german weekly newspaper about Fuzzy Logic. In it, the
author describes how people (speak humans) always work with *very*
unprecise measurements, and they go along very well.
when parking a car, they say "just a little further", or "that was
pretty close". Humans live well with these unprecise measurements, but
To implement anything close to what you mentioned, you'd need quite
a big amount of fuzzy logic, methinks. Actually, it almost sounds
similar to the way voice-recognition will/might handle things.
Just my $0.02...
Re: followups, posted 23 Jul 2000 at 23:45 UTC by joey »
Hm, moving selection into a separate stage seems like a powerful
technique that does indeed have the potential to make the shell more
accessible to normal people. I notice that I often already do this to a
degree when the fileset I'm selecting is complex, using a temporary
variable. The problem seems to be that the syntax for doing this right
now is messy.
My problem with xmms's emulation of a stereo is that I am thus locked
into doing only what a stereo can do, to the point where I begin to find
it hard to imagine other things I might want it to do with my music. A
few things I can imagine though include:
- Figuring out my favorite songs, so I can ask it to just play them.
These would be the items I listen to the most. I actually saw some work
being done toward this in another mp3 player.
- Realizing that I prefer different music at different points in the
day, and making suggestions. For example, at 2 am, there is only
one playlist I ever play (I'm often insomniac and it helps me
sleep); loading my mp3 player at that point should just start it
automatically (would be nice, since I'm generally fumbling around in the
dark w/o my glasses to get it started in the wee hours of the night). If
I am editing 5 different .c or .pl files at the same time and am fairly
active in all 5 windows, I am in a heavy hacking state, and I want
certian types of music then too, to help me concentrate without
- Keeping track of the mp3's I have not listened to in 3 months and
archiving them to slower storage (nfs), pulling them back out if I start
listening to them again. (Yes, I could automate this with a cron job.)
- If I've been listening to the same looped playlist for 6 hours
straight, throw in something different, or turn it off, to get me out of
Think of this as a cross between a mp3 player and an intelligent agent
and you'll see what I'm getting at. I don't know if I'd actually enjoy
all these features -- I don't want some program annoying me with music
it thinks I want to hear -- but as long as we're all locked into mp3
players that imitate existing electronic equipment with no creativity,
this kind of thing is unlikely to be made at all.
It may be that the Mac is the Anti-Mac. I have not seen nor have I used the new
OS X operating system, but from the lengthy articles at Ars Technica, it seems
that Apple may be headed in that direction. Ars Technica has an OS X Q&A page
with links to all its reviews at
for those that are interested.
The current Mac OS is getting old and has problems dealing with currently
available hardware and present day technologies and uses, as Gentner and
Nielsen say. I am hoping that OS X will be both easy to use for beginners, but
the power of the command line interface for experienced persons, and in general
provide the ultimate in anti-Mac experience.
One of the issues with command line interfaces is that few users
are capable of using them with the same ease as graphical user interfaces. I
think most people at the level of making use of advogato have forgotten this. The
overwhelming number of users are on Windows operating systems and have no
clue how to do anything not on the 3 or 4 programs they use at work and home.
These users will never get beyond the level of beginner and will never have any
interest in the operating system as operating system.
An interface that beginning level users can be at home with yet provide power
users with their demanding needs is very difficult. If I understand OS X, the Mac
graphical user interface will be there by default, but the command line interface
will be available when it works better. It looks like OS X will be providing the
information on files that demanding users require, while masking that
information from people who don't need or want to see it. Without having used it,
I cannot do more than hope, though.
Lifestreams, posted 24 Jul 2000 at 01:36 UTC by richieb »
Interestingly, IMHO VMS had a two-way conversation feature in its
command line interface; from what I vaguely recall one could type a
command, and be prompted for each required argument that you left out.
I quite liked this feature; it's not very UNIX-like but it certainly
Also my feelings on drag and drop are that simple DnD (in the Windows
left-mouse-button style) is not a good thing; it's not always clear what
will happen when the nouns (files/documents/other things) are dropped.
Windows-style right-mouse-button DnD, however, adds a clear set of
verbs. Pick up your nouns, rmb them over to the target area, and drop
them, and a set of verbs will appear; you can then pick the action you
want. If the verb requires more information, a dialog can appear to
interrogate the user.
If you all recall your adventure parsers, most of them had a "verb noun"
basic structure, so I guess you could consider this a kind of GUI-based
I don't want my computer guessing what I want. I want to tell it
clearly and unambiguously. I don't want my car guessing where I want to
go. I want to turn the wheel and have the car turn.
Natural language is inherently imprecise. Give me precise control over
what my computer does, with an interface that does not require much
study to become useful. But also make the interface be a full
programming language, so that I can use my previous knowledge.
I learned perl by making good use of perl -pi.bak -e 's/foo/bar/',
substituting various foo and bar's as needed. When I needed more than
that, I expanded my knowledge. In time, I started writing programs in
perl, even though I never set out to learn the language.
Sounds like I'm trying to reinvent tcl! :-) Except that tcl is a
string-parsing language and they're really inefficient.
I stumbled across the following article recently:
SECOND COMING - A MANIFESTO
I believe this article is also an excellent source of inspiration, much
the same way the 'Towards the Anti-Mac' article does.
I also found the following site: WebBrain to be a great
(user interface) example of storing/retrieving information the same way
the human mind does (as discussed in the above mentioned article).
idea of decoupling selection from action in a command-line
environment is interesting.
Unix shells currently have the concept of a "current directory". What if
we added the concept of a "current selection"? Suppose an environment
variable called SELECTION was defined which consisted of some number of
filesystem objects. Further, suppose that a unix command-line shell
called "sf" (for "select files", in keeping with traditional unix
obsure command names) was used to modify the selection. "sf +" adds to
the selection, "sf - " subtracts from it, and "sf" replaces it. Normal
commands such as "rm", when given without an argument, would operate on
the current selection; Or perhaps we could define some easily-typed
symbol to instantiate the environment variable.
> sf *.jpg
19 files selected
> sf - a*
4 files dropped from selection, total 15
> sf + *.png
6 additional files added to selection, total 21
21 files removed
21 files restored
I know this isn't exactly natural language, but it's doable today...
For those who don't keep up with Slashdot, somebody recently asked about
Natural Language CLIs.
Not much of substance that hasn't already been covered here, however
there is a link to an
Adventure Shell, characterized the "most convuluted bash script on
the face of