Towards the Anti-Mac

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.

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.

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

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.

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

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.

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

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

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.

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

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

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

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