AA asks via email:

When using your url CLUI, are you letting the browser _guess_ at what url you want and fill in the rest of it? Is this still a CLUI? Are there smart CLUI's and dumb CLUI's? Is the real threat to the GUI, a really smart CLUI?

Very good questions. Right now I usually use Netscape Navigator 4.6 on Linux (I know, I know...), which has no URL guessing, and IE 5 on a Mac, which has too much (the popdown of recent URLs that match, prefilling the closest match (the one that needs the least to complete). While I like URL guessing, I've never implemented in the way that I would call 'right'.

URL matching should work the same way as file matching in bash (and a handful of other shells), with a few tweaks (that bash should have too): When you're typing in a URL, you should never have autocompletion done for you, forcing you to backspace if you don't want it (unfortunately, IE does this). If I've been to http:/fury.com/aoliza/, but I want to go to http://fury.com this particular time, it should work as follows:

While typing the URL, the system should look for possible completions, but only autocomplete if I hit [tab] (like in bash). If there are multiple possible completions, one of two things should happen. If all the possible completions share part of the path (say I've typed in http://fury and the possible places are http://fury.com/, http://fury.com/cameo/, and http://fury.com/aoliza/, the system should prefill up to http://fury.com/, because it knows at least that part is right. If there are multiple paths that immediately fork (have no commonality beyond what has already been typed) for example, the state after I originally hit [tab], it should show a list of the possibilities. The user should either be able to pick from the list or type more until it's unique and hit [tab] again. For example, having typed in http://fury.com/ and hitting [tab] I should get a menu with http://fury.com/cameo/ and http://fury.com/aoliza/ in it. Typing in 'a' and hitting tab again should autocomplete http://fury.com/aoliza/.

This is pretty much the way bourne shells (bash) work, except this allows you to click or elaborate when there's a choice, instead of forcing you to elaborate. I think both shells and browser guessing could be improved though. If the path, or part of the path, is unambiguous (that is, if by the above rules, it would autocomplete some or all of the url), that portion should be displayed in a ghosted form in the command line (something like this: http://fury|.com/ ) to let you know the consequences of hitting [tab].

Basically, so much effort has been put into designing consistant GUIs that GUI devices and mechanisms (menus, scrollbars, pointers, windows, icons) have drifted across all major operating systems. The same is much slower going in the case of new CLUIs, and I believe it's mostly because people adding some CLUI functionality to their software think of it as new functionality with no rules or conventions, a romping ground whee any little bit of functionality is a bonus, when in actuality they're reinventing wheels in their own images, to the confusion of the user.

Anyhow, to get back to the questions, I think there are definitely smart CLUIs, but that it takes a smart designer to make a CLUI that doesn't try to be 'too' smart. Taken to the extreme, the assistant in Microsoft Office is in some ways a 'too smart' CLUI. Type "Dear John," into a new Word document, and it will ask you if you're trying to write a letter, and do you want help. In my opinion this gets in the way, but this is a matter of preference. Certainly there can be smarter CLUIs than we have today. A CLUI is traditionally thought of in a pure text environment, like a shell window or dumb terminal. Rich visual information can be expressed in CLUI enviroments though, it just dictates that the command itself is given in typed text. I could see something as simple as a bash shell having robust contextual help. for example, if I type in 'egrep", as I'm typing, a window could pop up on the side showing me all the switches egrep uses, and possibly a list of special characters used in regular expressions. For the most part, I think making CLUIs smart is enabling them to better interpret what we mean (instead of what we say), learning from past experience, and providing nonintrusive data on the actions we're performing.

Will CLUIs ever replace GUIs? I don't think so, unless you see voice commands as being a CLUI environment, which they well might be. I think we'll continue to see a mix. There's always been crossover. Emacs, vi, and pico all have GUI attributes as well as command lines, and more and more often GUIs resort to dialog boxes that are really just prettified front ends for quick CLUI interaction within a GUI environment.

then of course, there are blurred distinctions: Is a WAP phone a CLUI or a GUI environment? It's a little of each. I think as time goes on we'll see more and more GUI for displaying information, and CLUI for inputting information. This, incidentally, is how half of the web works now. Go to askJeeves or amazon and focus on search, and you're using a CLUI for inputting information, then getting back rich visual data. Type in a URL and it's the same. Of course, there are always places where one wins hands down. Automated file processing (grep pipes and such) will always be the domain of the CLUI, and graphic arts will always be better served by GUIs. The most important thing is the understanding that each is better in specific environments, and that those environments are different from person to person.