I’ve setup a gitweb for projects of mine at http://braydon.com. You can look at the code of Sparrow to get an idea of what exactly it does. It’s small and very early in development, keep in mind.

I need to take a bit of a break from it, or atleast work on it on the side. Some things that I will like to work on is creating different branches. One of my ideas is to merge some of the demo you have made w/ it. As well as some other JS work on a radial menu that Michaeljohn Clement worked on. Some other ideas I’ve had is trying different templating languages (Jinja), and http frameworks (Werkzeug). All in all, the project has been a great learning experience for me.

If anyone here is interested in Sparrow please contact me at courier@braydon.com, I am interested in hearing from you.

I’m happy you like the demo. And if the code starts to live in other software, I’d be as pleased as punch.

“If things work out well, I may want to see if you would like to do some more work.”
I can be bribed. ;)

I just took a look at interfce.com earlier today, and I’m very curious how Sparrow is going to look and what, exactly, it will do.

“There are still a few things that I disagree with the interface, however these are relatively minor. I will be able to demonstrate with an example soon.”

That’s great. Keep me updated. I’m afraid the code is almost completely undocumented. Let me know if (when) there’s need for clarification. I should probably modularize this and put it into some kind of repository, like google code. What do you think?

This made me incredibly happy not only watch a demo, but to be able to use it, and the code is available, and it’s for the web. I’m amazed at the amount of work put into this, and so quickly.

With that said I would like to integrate some javascript into a project I’m working on called Sparrow. It’s a free software website revision system (written in python), based around Noun->Verb interaction. It is inspired by Jef Raskin’s book The Humane Interface.

To start this will be part of an experimental branch that pushes forward the interface of Sparrow. If things work out well, I may want to see if you would like to do some more work.

I don’t have the website up for it yet, but it should be soon :)

There are still a few things that I disagree with the interface, however these are relatively minor. I will be able to demonstrate with an example soon. Furthermore I do hope that a scratchpad is integrated into Enso, I think this is a much better solution, and can keep Enso quasimodal, along with many other advantages such as it’s history.

I’ve re-read our discussion, and it seems like both of us have been mixing up technical complexity with interface complexity.

I take back my statements from Feb 7th and Feb 11th about Enso having to focus on a few widely-used and widely-needed commands. After all, extreme extensibility is one of the main advantages of a command line-like interfaces. You’re of course right that Enso commands can be very specific, e.g. svn check-out, shrink image, read new mail, and so on.

Those commands can be technically complex internally. This doesn’t mean though, and I think you agree, that they should have a complex interface. We can still keep our command structure simple while at the same time allowing complex tasks. And in my opinion, having the possibility to choose between noun-verb/verb-noun order, or to allow for optional arguments, doesn’t help, because it burdens the user with too many things to consider when typing command.

The thing is: When an Enso command needs several arguments, some optional under differing circumstances, is it still an Enso command? Or would one rather fill out a small form to provide the necessary info? For example, Enso 2.0′s proposed email command looks more like a form to me. There’s a distinction to be made: Between commands and forms. If it can be kept simple, with one, or at most two arguments, it’s a command. But if it isn’t, you should just open a form that can be tabbed-through, filled in and submitted by pressing Return. You could both have an email command (email) and an email form (compose email) for instance: The email command is there to quickly send a text selection to a recipient, while the form that is opened by compose email sports all the bells and whistles like CC and BCC fields. Of course, there would have to be a naming convention for forms so that users always know what to expect.

I wrote in some more detail about this on my web site.

And here’s a Demo that shows how the scratchpad should behave in my opinion.

About your last comment: At first, in a knee-jerk reaction, I was against it [cf. the notorious quote "make it an option"]. But of course, adding and removing commands is perfectly acceptable, and that would also be some kind of interface configuration. But I, personally, would not make anything else (argument order, form fields, etc.) configurable. If a command would have to have an optional argument, split up the command instead into two separate commands (e.g. email and email with attachment [I'd prefer a form for the latter, by the way]).