Mitcho has put together a killer tool, The Ubiquity Persistence Project, that lets you tweak the look and feel of Ubiquity on the fly in order to prototype it:
This reminded me of a topic that I have been mulling around in my head. With Bespin we spend time thinking about how text editors have innovated in little ways (and important ones: code completion etc) over recent years. We want to speed that up, hence the social features.
One part of Bespin is the command line which is a core part of the experience and continues to grow in its role. The goal has always been to merge the Bespin command line with Ubiquity in some way, and people have played with that idea since we modeled our commands to be similar to Ubiquity’s.
Since our command line is in HTML and not on a terminal, we had different ways of helping the user do what they want to do. Take the UNIX command line for example, what has changed there?
- A shell created the notion of “completion”: first for files/dirs, and then to now where you can do super smart completion
- At some point we got colors (LS_COLORS and the like). Woohoo!
- Keyboard shortcuts get us to move around our history nicely
Useful things, but nothing compared to what you can do if you have more than text. We ended up following a pattern where, if you don’t put in the right command line parameters, you get prompted. This isn’t the same as having the command program itself ask you, as you can declare it in the command and the prompt can be as rich as you want. For example, here is the vcs clone command. In theory we could make the command take a bunch of options: vcs clone --url https://svn.mozilla.org/... --project myproj --username user --password pass ... or we could ask for it (and allow browser history to kick in and help):
This is a touch crude, but shows you where we are going. I want to be able to declare the types and names of values that a command needs, and have a UI help the user out. As you are typing the command a popup can appear showing you the items that you have to complete, and those that are optional, and help you fill them in with values that make sense.
In fact, although it will be great to make the Bespin command line awesome, it makes me whimper when I am back to good ole Terminal.app. Can’t we mash that up too?
Time for Commandline 2.0! It would be awesome to have an incredibly rich version of Terminal.app that helps you in amazing ways. As the Web becomes the platform, that may just happen via Ubiquity itself :)
August 21st, 2009 at 4:04 pm
I would love to be able use Bespin as a command line, especially when I need to do things on the server on which i’m running Bespin. But can we first have Git support please?
Thanks
August 22nd, 2009 at 12:40 am
Reminds me of the Commando feature in Apple’s A/UX operating system. You could open the CommandShell, enter the command, and press Cmd+K and get this dialog: http://applefritter.com/ui/aux/images/cmdo-ls.gif .
August 22nd, 2009 at 6:19 am
Well, I’ve been working on this very thing in my (not exactly copious) spare time for the past month. I may as well put a copy up … here it is:
http://voracity.org/Well/Well
Supports running ordinary processes, entering input, breaking, detaching/reattaching, html output from ordinary processes (send back as first output data) or text if not a Well-aware program.
Still very alpha, of course, so user beware.
August 22nd, 2009 at 6:20 am
Incidentally, I’d like to integrate BeSpin. If you could give me some pointers, that would be an immense help!
August 25th, 2009 at 2:19 am
You probably know that the bash and zsh shells are “super smart” enough to do smart option completion in the middle of typing a command, so you can type `wget –r` and it’ll list just the options for that program that start with ‘r’. zsh seems even smarter.
As for GUI representation of command-line options, Apple tried it with “Commando” in A/UX and MPW. I wonder why UNIX/Linux never settled on a richer representation of command-line options beyond the usage() string printout so that each desktop could implement a GUI command builder. bash’s per-command completion information is (probably) in /etc/bash_completion and zsh’s is in /usr/share/zsh/functions/Completion (see zshcompsys(1)), but both are written in the shell’s own programming rather than a language-independent representation of command parameters.
August 29th, 2009 at 7:38 pm
great post! our blog is relatively new and we are new to blogging. therefore, we will heed and implement your advice.