I come from a CLI background (UNIX), and still use vim as my main editor (vim is a truly modal editor, with functionality like search and replace supported via command line). So you could say I'm favourably predisposed towards command lines. But let's try to analyse the benefits and disadvantages of command lines and GUIs (Graphical User Interfaces).
CLI vs. GUI
(Advantages & Disadvantages)| CLI Advantages | CLI Disadvantages | GUI Advantages | GUI Disadvantages |
| Direct access to commands | commands not displayed (completion helps) | indirect access to commands | commands displayed (in menu) |
| random access to objects like files easy (esp. with completion) | difficult to define graphical/text selection | easy to define graphical/text selection | clumsy random access (since objects are displayed spatially, it is hard to keep a wide range of them visible) |
| easy to manipulate one or more database-style objects with textual search/replace style commands | difficult to directly manipulate graphical objects/text (NB: graphical objects can include objects that are simply represented graphically, such as calendar events) | easy to directly manipulate graphical objects | difficult to manipulate more than one database-style objects |
| easy to implement history and/or repetitive operations (eg. scripts/macros) | feedback from operation limited/implicit | difficult to implement history and/or repetitive operations | feedback from operation usually explicit |
Proposal
CLI's and GUI's clearly have different strengths and weaknesses. In summary, CLI's are better at issuing commands and dealing with database-style records or files and selection on textual-based searches; GUI's are better at direct manipulation of objects that can be represented graphically, and arbitrary but contiguous selections.Using the two forms of UI in combination offers significant benefits:
- remove indirectness of menu access
- allow sophisticated sorting/searching and replacing, even in combo with GUI's graphical representations (to increase contiguity of selection)
- allow history/redo/macro capabilities.
Implementation
So how do we implement this? For a PC, with it's large keyboard, screen, and pointer, I propose the following solution. Get rid of the menu bar (on the top of windows in Windows, and at the top of the screen on the Mac) and replace it with a command bar at the top of the screen. This line will show the command line as it's entered, and drops down a translucent list showing any autocompletion options or history.The command line should be accessible with simple key toggle (like Enso, but probably modal, since holding down a command key while typing limits what you can type). But the CLI should also interact with the GUI's elements, for example, highlighting items which may match (i.e. are in the autocompletion list) with a special "tentative" highlight.
Command scripts should be able to span app's. So, for example, to do a search and replace in multiple documents, you might be able to simply type:
for file in C:\Documents\DS*.doc
open file in Word
Word::Replace "Series 60" "S60"
Word::SaveClose
end
This should fill in the files with autocompletion during the first line, and then execute it at completion.
Mobile Solution?
The problem with this scenario is pretty obvious: it is heavily keyboard relient. Without a full alphabetic keyboard the commands suddenly become more indirect again (with some form of input method intervening). And the long lists generated by autocompletion aren't very friendly on a small screen. Furthermore, keyboard styles vary so much from device to device (and even within the same device in an increasing number of devices, inspired by Sony Ericsson's P-Series phones) that it would be difficult for a user to become fluent in this style of interaction.My preference is actually for a tree-structured command space, navigated using the keypad or stylus/finger. See DreamScribe for an initial implementation of such an idea. The benefit of this type of UI for mobile phones is manifold:
- It is one-handed with one-handed phones
- It works identically in both keypad and stylus-driven UI's, and doesn't require any additional hardware
- Commands are visible
- Commands are grouped by topic (like menus, but in an even more sophisticated way)
- "Muscle memory" can be used for commands, with careful design (so the same command is always in the same place in the hierarchy)
- Commands can be used from anywhere, unlike menus which need to be contextual in order to maintain their navigability (since they have a very flat hierarchy)
- Commands can either be combined with the GUI (basically replacing menu commands) or feed into a CLI (with textually specified arguments)
- Arguments can also be mapped into the hierarchical system, so that rather than long, linear lists of autocompletion options, hierarchies of possible arguments can be presented
There is a lot of potential in such a UI. Keystick (now "morphing" into Kanuu) showed that this was possible even with text input, and it looks like they're extending it to all sorts of navigation, just as I've suggested above. DreamScribe mapped calendar and contact attributes into a hierarchy, and the sky's the limit, really. See also Ring-writer as an innovative approach in this area.
