David Beers is enthusiastic about the possibility of controlling mobile devices with a command-line interface. I know what you think - the same I did. You can't possible be expected to learn a cryptic new language to control your telephone! However, his proposal isn't completely off the wall, and he managed to emphasize a few of the great advantages of CLI:s.
First of all, you save time as you don't need as many clicks or button presses to run a command from a powerful CLI as you do from a desktop type user interface. The examples in the above mentioned post uses auto-completion quite aggressively, and when it works well, it requires very few keypresses to make a call, schedule a meeting etc. It should be noted that this isn't about just porting bash to S60. That wouldn't help anyone, as typing is way too hard to use something like that. What's required is a language that's designed to control a phone.
Second, CLI:s don't require diving into data silos (applications) in the same way as you do in GUI:s. To write a message on a regular phone, you have to open the messaging application (click, click), find the recipient(s) in the contacts database (click, click, ..., click), write the message (that'd be the same, regardless of the UI) and finally exit the messaging application (click, click). With a CLI, the whole system is accessible from the same place.
I think a concept like this would require some serious thinking before it has any chance of success. The phone has to be usable by anyone as soon as it's switched on. I don't think a helpful piece of advice, such as "Press 'h' for help" is going to solve that problem. There's no point in developing the next generation UI if it'll only be suitable for nerds like me.
(Background: I grew up with the C-64 (load "file",8,1 ... run), and thought the Amiga was a bit awkward to use at first, as it threw you into a weird landscape of icons and menus intead of BASIC 2.0. I later got used to it, but I still prefer the command-line in Linux, and can't live without Cygwin when I have to use Windows. So I prefer CLI:s, but I can see why not everyone does, and sometimes a GUI really helps.)
Subscribe to:
Post Comments (Atom)
12 comments:
You mean like this? IMG_3395.jpg :)
Personally I think textual and graphical interface elements should be complementary. It's not a either-or proposition. I think you're right about the staying power of CLIs, which will only grow because the general population is becoming more computer-sophisticated and computers are evolving toward mobile devices.
My favorite example of CLI/GUI integration is the Commando feature of A/UX. Type "ls" and hit Command-K, and you get a HREF="graphical version of the command-line options.
I don't believe GUIs require diving into data silos either. OpenDoc and Newton OS are two counter-examples to the standard application-centric paradigm of all the major OSes.
jrc wrote:
Personally I think textual and graphical interface elements should be complementary. It's not a either-or proposition.
I totally agree. Calling this CLI is perhaps a mistake because of the association with DOS or BASH consoles. The key is to be text driven, but to provide the same kind of prompting you get from a GUI and (very important) a nice graphical visualization of your interaction. It's hard to explain without seeing it, but maybe your A/UX example is similar.
I also agree that GUI != data silo. It's more the idea that you have to navigate to an application icon and launch the app to do common tasks that I'm trying to get away from. That's a common feature of PC GUIs that I think we could afford to get away from on the mobile.
Also, I'm not so bold as to suggest that this is the only right way to improve the mobile UI. It's just a way that I think would work well for a lot of users--including possibly the newbies, who may respond well to tasks being more like writing natural language statements: "Call Joe Blow" (only with prompted auto-complete, so you just enter 'cjb')
If it doesn't seem dirt obvious how to use it when you first pick it up I haven't succeeded. This isn't meant to be a power user feature.
David Beers. What a name! I mean, who doesn't like Beers?
On a side note, more like writing natural language has always been what the CLI is about. You don't see captain Jean-Luc Picard of the U.S.S. Enterprise clicking icons, do you? (It's a rhetorical question, but I'll answer it anyway: No.)
Thanks for the comments, boys!
I absolutely agree that textual and graphical elements should complement each other. And I'll have to believe you when you're saying that GUI != silo diving, although I don't have experience with any such GUI.
I also can't remember seeing Picard clicking on any buttons, but touch screen controls seem to be used widely in the Star Trek universe. :)
Puterman: Touch screen controls are usually as command based as a CLI, because the correlation between a click and a command is made concrete. And the Microsoft Vista Speech Recognition (which is a command line interface, don't you agree?) used on the U.S.S. Enterprise (with permission) is similar to the things an experienced computer user would do in an agile shell.
This sentence has been removed by the author.
Every time I played Level 9's text-operated interactive fiction game Knight Orc I was impressed with its parser, and that's the experience I'd want from a CLI phone as well; more so than the experience I get from using Bash, I think.
Puterman wrote:
What's required is a language that's designed to control a phone.
Why? If I talk to a person holding a phone, I don't need a special language. So why should I if the person holding the phone happens to be me?
UL: Touch screens can be used for both GUI:s and CLI:s. I don't really see the difference between clicking a button with a mouse and clicking directly on the screen.
The language needs to be designed with handheld devices in mind because of their limited input capabilities. Natural language would be nice, but we're not quite there yet. If you don't even have a qwerty keyboard, not even pressing 'h' for help might be easy for a newbie. Of course, the language shouldn't be determined by the input method, but they have to work together.
Idiot
Lammer!
You can use some HTML tags
wv: not available :(
Post a Comment