Towards the Anti-Mac

Posted 22 Jul 2000 at 03:59 UTC by Radagast Share This

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 becomes reality". Recently, someone here on Advogato mentioned it, and I thought I'd sit down and read it again. Much as I remembered, it was an excellent paper, but unlike the last time, I thought I could see the seeds of the Anti-Mac in 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 known for his books on UI engineering, and his Useit.com web site.

For those unfamiliar with the original paper, I'll sum up the philosophy and 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. You'll specifically need to do that to see how these principles are directly opposed to some of the basic design principles of the Macintosh interface. Besides, the original paper has better prose. When you come back here, you can safely skip the summary, I add nothing new in it. If you've read the paper before, though, 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 community it was made for, a group consisting mainly of hackers, who had the time and interest to understand the system and figure out how to use things like the system's utilities and pipes, and who also manipulated relatively few data objects, mainly the files in their own code, text files, and so on. Later, the Macintosh interface was also very well suited to its target audience, knowledge workers with little or no computer science background, who wanted to work with moderate amounts of graphic documents.

The Anti-Mac interface as outlined by Gentner and Nielsen is aimed at a third group of users, which they believe will be dominant in the future (the future as seen from 1996, there are signs that this group is emerging at the moment): People with extensive computer experience (although not necessarily a CompSci background) who want to manipulate huge numbers of complex information objects while being connected to a network shared by immense numbers of other users and computers. Using this as a starting point, the paper postulates five design principles for the Anti-Mac interface:

The central role of language.
This is a sort of bastardized command line interface using heuristics and being able to engage the user in a two-way "conversation" to determine the action the user wants to take. It's not a natural language interface, instead, Gentner and Nielsen propose something along the lines of the parser in text adventure games, which deals with a reasonably large number of syntactical constructs, while still not being the computational nightmare a Nat-Lang parser is.

A richer internal representation of objects.
This is basically a set of meta-data for objects. In traditional file systems, the interface has access only to a small amount of information about a file, for instance. The only known information may be name, size, modification date, type, and user that owns the file. The Anti-Mac interface would make available a much richer representation of the file object. In the case of a document, this might include the authors, topic matter, keywords, and importance; whether there are other copies; what other documents it's related to, and so on. This implies a form of structured document format (the original paper mentions SGML, today we would probably apply magic XML pixie dust).

A more expressive interface.
The richer internal representation can be transferred to a more expressive interface. The original GUIs, for instance the Mac one, were designed to work on 9-inch displays with less than 200,000 pixels, while a modern 21-inch display running basically the same interface has more than 2 million full-color pixels. It's expected that this trend will continue, and the Anti-Mac interface should take advantage of it, using the increased visual definition to give the user more contextual information about the objects she's seeing. The example used in the original paper is that of a bookshelf, where the books' spines have a wide variety of 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 bookshelf.

Expert users.

While today's user interfaces (in particular the graphical ones) are typically oriented towards ease of learning, there's a trade-off between ease of learning and ease of use, power and flexibility. Just as people typically spend a lot of time learning a complex language such as English, so they can enjoy the rich communication they can accomplish using it, future users will spend a lot of time communicating with computers, and we should take this into consideration when designing the interface.

Shared control.

As opposed to a contemporary user interface, where the mantra is to leave the user's things where he left them, and preserve state and perceived stability, the Anti-Mac interface proposes to share control of the environment between the user and other entities, specifically computer agents and other users. This allows the user to share information with other users, and to have tedious tasks performed for him.

The original paper ends on a slightly sobering note:
<cite>"Any realistic person who reads the preceding outline of the Anti-Mac interface will realize 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 users know better than to trust computer-based agents with a free rein on their systems."</cite>

Where are we now?

So what was interesting when rereading this paper now, was that there are tendencies towards these design principles in a lot of modern free software. I'm uncertain whether or not this is intentional, but I suspect that, with the possible exception of some corporate efforts, it's not. It might be that we as a community, after getting criticized for not being user-friendly (meaning, really, newbie user friendly) for a long time, have subconsciously set our aims at creating an interface for tomorrow's users. This might be our 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 Anti-Mac interface is a lot more natural than from Mac or Windows to Anti-Mac. For instance, the typical X screen, be it using GNOME, KDE, Afterstep, or FVWM2, is a lot less metaphor-laden than a Windows or Mac desktop. Where the Mac and Windows desktops show your computer, containing different drives, documents all over the desktop, etc., this is much less common on an X desktop. The Mac and Windows interfaces are centered a lot more around a metaphor driven (desktop, folder, document) experience than the X desktop, where, even though file managers exist, users are more likely to open a shell window to manipulate their files.

Also, ever since CDE, all the way up to GNOME, X desktops have typically had a launcher panel, which can contain buttons to start applications or perform other actions, as well as embedded programs that show system information. This interface is a lot more abstract and power-user oriented than the "let's model your office" metaphor of the Mac. Notice that Windows has actually moved away from the Mac interface lately, towards more abstract representations of the user's environment, with such things as the task bar and start menu, "recent files", and so on.

Meanwhile, in the background, we've developed and actively use powerful tools for cooperatively creating, modifying, and publishing information over the network, such as CVS and Apache (specifically Apache with the recent WebDAV functionality). While CVS is very probably not ideal for generic use (it's being stretched way beyond the original intent already), it's a great example 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 some of the principles of the Anti-Mac interface. I apologize beforehand that these examples are very GNOME-centric. I'm sure this is a result of my close involvement with GNOME, and my lack of similarly in-depth knowledge about other efforts. I'd love to see examples from other camps in the follow-ups. In addition, of course, both these pieces of software are pre-alpha, so I'm going from descriptions, my tests of unstable preview releases, etc.

Nautilus:
Nautilus, developed by Eazel and the GNOME community, is an excellent example of moving in the direction of the Anti-Mac interface. It promises to feature a much more expressive interface than most file managers, expressing both the data inherent in the Unix file system, such as write permissions and the like, and thumb-nailing the information contained in the file inside the icon. It also effortlessly retrieves and uses meta-information from a wide variety of data object types, displaying most of them effortlessly by embedding viewing components. In addition, it nicely bridges the gap between local objects and network shared objects, with support for FTP, HTTP, WebDAV, and so on. What's not terribly Anti-Mac about the Nautilus interface is that it still relies a lot on direct manipulation (drag and drop), with all the shortcomings this implies. Thus, it doesn't go as far towards an ideal Anti-Mac file manager as it possibly could.

Evolution:
Evolution, developed by Helix Code (which happens to be my employer) also has elements of the Anti-Mac principles. Specifically, it uses a pervasive implementation of the shared control principle, sharing control both with other users and, to a certain degree, with computer agents. Email is an area which is inherently influenced by other users, if nothing else then by their email arriving in the user's inbox. However, Evolution's distributed appointment scheduling lets other users request appointments to be made in the user's calendar. In addition, the user can define vFolders, which are in practice the result of running a search on all incoming email. Continuously running searches with an automatically updated list of results is one of the more common elements of agent technology. It also indexes a lot of meta-data about each email stored, giving a rich internal representation. However, Evolution is not strongly Anti-Mac like when it comes to metaphor use, for instance, it uses the folder metaphor for storing mail (if nothing else, then in name), which can be a limiting metaphor when it also implements features such as vFolders (where an email can, in essence, be in more than one folder at a time).

So, where does free software dovetail with the Anti-Mac interface, and where do we still need to do work? And, more importantly, do we want to?

It seems we're doing reasonably well in terms of a metaphor-less interface, geared towards experienced users. Networking also tends to come easily to free software, so at least the right infrastructure for shared control is falling into place, although the actual services are still a bit lacking. Our interfaces are getting more expressive, although this puts a heavier load on graphics artists and others directly involved with the look of the GUI (it's not enough to have the pixels and colors, it also needs to look aestetical and feel intuitive. In this area, we certainly have quite a way to go. We're also doing pretty well when it comes to richer internal object representations, with practically all free software of any size using XML as a storage format, giving rich metadata capabilities.

So the area where we're furthest from the Anti-Mac interface seems to be the first principle, the central role of language. There's not much progress in this area, probably a rebound effect from us recently "getting out of the primitive text-mode interface and into the drag and drop GUI", but it's definitely an area worth researching. Luckily, with component systems such as Bonobo exposing the interfaces of components in a language-agnostic way, we're doing the perfect groundwork for a good seminatural language interface. It basically needs a good parser, a set of heuristics, and some glue code, and we could have a language-centered interface quite quickly. (Note that while I personally tend to doubt most predictions that voice-control interfaces will 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 revenue model for free software companies. Agents, for instance, when done right, require servers to run on, direct access to databases, etc. The Helix GNOME updater is one of the few examples so far of integration with services and shared control (indeed, keeping your system up to date seems to be an ideal arena for shared control scenarios, not least because free software tends to develop very quickly). But a true agent system should go much further in what it can do on its own, yet the interface to request a specific task from an agent (say, monitor news media for items about a specific topic) isn't really much more complex than creating a vFolder in Evolution, a task that's elegantly solved using a druid.

This matter of initiative on behalf of the agent is the least explored part of the shared control principle, probably because it's very dangerous ground. If the agent acts on its own, it doesn't take many mistakes before the user will just disable the agent completely, fearing what else it might do wrong, and that this will result in loss of valuable data. However, as the concept of shared control seems to creep into more and more free software company business plans, we need to do devote work to agent technology. My hunch 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 to 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 limited in 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 along the lines of a text adventure command parser (which most people manage to use quite effectively after just a few minutes of trial and error).

So, do we really want to move towards the Anti-Mac interface? I'm rather convinced that we'll have to sooner or later, so it might be a smart move to at least figure out how we'd like to do it now. In addition, this could be a great opportunity for free software to stop chasing taillights when it comes to user interfaces, which, let's face it, it's been doing for the last 10 years. In many instances, it's even been chasing the taillights of systems that have in turn been chasing the Mac interface, not exactly a model for innovation. Given that the prediction of the original paper, that children today will be much more computer-literate than the current generation, and require a very different interface, seems to be coming true (maybe even faster than the authors imagined back in 1996), and that free software seems to be the way to go for software in the future, it seems only natural that we should be 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 » (Master)

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 we need.

"Central Role of Language" == "scripting"?, posted 22 Jul 2000 at 08:10 UTC by ncm » (Master)

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

Yummy, posted 22 Jul 2000 at 09:09 UTC by CentralScrutinizer » (Apprentice)

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.

metaphores and agents, posted 22 Jul 2000 at 09:49 UTC by joey » (Master)

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 tabbed windows).

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 called Calm 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 little 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).

The Web as {anti,post}-Mac, posted 22 Jul 2000 at 16:22 UTC by advogato » (Master)

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 logical. Consistency: <snort/>

WYSIWYG: <snort/>

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 example here.

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 » (Observer)

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 ;-)

Followups to miscellaneous comments, posted 23 Jul 2000 at 08:32 UTC by Radagast » (Journeyer)

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 to arbitrary scripting languages is one half of the way to getting language into the interface. The other would be a language shell with a near-natural language, using the exposed mechanisms. Most people don't want to sit down and write scripts, but if they had a shell that let them describe what they wanted done incrementally and in an intuitive language, that would work. Something like a cross between a shell, the interactive Python interpreter, and an Infocom game. It should also be able to handle arbitrary, temporary sets of objects, so you can do selection and execution in two steps (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 this:

> 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? 
[Lists files]
> 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 actually 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 bit more typing, though, but notice how it would make some tasks that are non-obvious to 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 things you've done, even though you've mixed the set of files into a dir with a lot more files. This sort of language parsing is not computationally difficult (it's at the level of an advanced text adventure, indeed, Hans Petter Jansson implemented a command parser for pseudo-natural English which could deal with parsing the examples above easily (as well as quite a bit more complex sentences). If the shell had some memory of sets it had handled, it would be even more powerful (being able to talk about "the set of HTML files I moved from my homedir last week", for instance).

In addition, it would be useful to be able to perform operations on the data inside the files using similar syntax, for instance being able to do search and replace in documents. This would mesh nicely with the rich internal representation principle, where you could select objects into sets using complex criteria.

This would work out to be a pretty powerful way of handling your files, and believe me, if you have a dir of a couple of hundred files, and need to single 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 other alternatives would be using find (for the poweruser, non-obvious syntax, etc.) or selecting manually in a GUI file browser (cumbersome and error-prone).

This sort of shell would require reimplementing and/or wrapping a reasonably large set of existing shell utility functionality, so it would probably be best 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 course. It would be interesting to do some prototypes of this.

CentralScrutinizer: You're right, people are writing their own little agents. However, there's definitely a need for a generalized way of doing it, say, an agent wizard where you could define what you wanted using a syntax similar to the above, and the agent you created would speak HTTP, FTP, NNTP, and parse HTML, XML (including things like RDF and other common DTDs, of course), Usenet and mail headers, and so on. It's not that people aren't doing 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 be a programmer to be a power user.

Joey: Actually, XMMS' stereo-like interface metaphor isn't that terrible, as metaphors go. After all, what you want to do with an MP3 player maps pretty closely to what you can do with a real-life CD player, including playing, pausing, skipping tracks, ejecting (changing to a different 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 physical electronic device, as opposed to those that try to emulate a more conventional object with obvious cause and effect (such as a trash can, or a 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 to your commands, yet people learn to master the interface fairly quickly.

Thanks a lot for pointing out the Calm Computing philosophy to me. I've just 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 yesterday, I've been thinking about how the principles could be integrated into a "desktop". The original works seems to be concerned mainly with manifestations in physical space, but I think there are a lot of ways it could work on a computer screen too (this meshes it with the Anti-Mac idea, since that's based on the concept that the user spends a lot of time in front of the screen). I'm 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 think 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 interface guidelines. Yet, the web has many other problems that wouldn't plague a true anti-mac interface: The response time is poor (although this is steadily improving), the interface is not typically very expressive, there's not much rich internal representation of objects (indeed, most web site back-ends are extremely primitive, and need to be, to optimize for speed of response when under heavy load). And so on. I think the web is a forerunner for network services that integrate more with the rest of your working environment, moving the web into your applications instead of the applications onto the web, if you will. It's going to be an interesting time up ahead, though.

fuzzy logic, posted 23 Jul 2000 at 15:13 UTC by jschauma » (Observer)

Radagast, your example of the intuitive shell reminded me of this article 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.
For example, when parking a car, they say "just a little further", or "that was pretty close". Humans live well with these unprecise measurements, but computers...
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 » (Master)

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 distracting.
  • 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 my rut.

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.

Maybe the Mac is the Anti-Mac, posted 24 Jul 2000 at 00:19 UTC by stripling » (Apprentice)

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
http://www.arstechnica.com/reviews/2q00/macos-qna/macos-x-qa-1.html
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 offer 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.

Phil Stripling

Lifestreams, posted 24 Jul 2000 at 01:36 UTC by richieb » (Journeyer)

Another different metaphor for the user interface is called "Lifestreams". I've read an article about Lifestreams in Wired few years ago. Anyways here is the main page:

http://www.cs.yale.edu/homes/freeman/lifestreams.html

It's a pretty neat idea...

...richieb

VMS and right-mouse-button drag and drop, posted 24 Jul 2000 at 16:11 UTC by jmason » (Master)

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 saved RTFMing.

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 adventure parser.

Natural language? No thanks!, posted 25 Jul 2000 at 02:32 UTC by nelsonrn » (Master)

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

Another similar article., posted 25 Jul 2000 at 17:19 UTC by ReCoN » (Journeyer)

I stumbled across the following article recently:

THE 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).

Decoupled selection, posted 28 Jul 2000 at 05:27 UTC by Talin » (Journeyer)

Joey's 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.

For example:

> sf *.jpg
19 files selected
> sf - a*
4 files dropped from selection, total 15
> sf + *.png
6 additional files added to selection, total 21
> rm 
21 files removed
> undo
21 files restored

I know this isn't exactly natural language, but it's doable today...

CLI Shell as Adventure Game , posted 31 Jul 2000 at 16:34 UTC by maphew » (Apprentice)

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 the planet." *

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page