Enso 2.0 Design Thoughts

Design Our Products Software Development

As part of the our move to Mozilla and thinking about a free-as-in-speech Enso, I want to be more transparent with our design directions and goals. Our designs can only benefit by incorporating the criticism and suggestions of the community we have here. Open-source design is a balancing act between making final decisions and finding consensus. We hope to take the lessons that Jono spelled out in his excellent article on successfully humane open-source projects and use them in our own projects.

This post is about the new directions we are taking Enso. If you haven’t done so yet, start by reading about some of the motivations for doing some Enso redesign. In short:

• Enso shouldn’t make you type all of “open” every time
• Enso should be able to open paths and urls
• Enso should support international character input
• Enso should gracefully handle the case where there’s no convenient place to enter text
• Enso shouldn’t require you to type out text, select it, and then run a command when you’d rather run the command and then enter the text (think calculate)
• Enso shouldn’t make you hold down a key while typing lots of characters

We think we’ve solved these problems with our Enso 2.0 redesign. In this post, and possible follow on posts, I’ll walk through the new stuff. I should note that our upcoming prototype will not yet have have all of the features mentioned here.

Autocomplete

One of the major design challenges in Enso is balancing between descriptive names and short names. This is not a new problem: Unix command lines used short names instead of descriptive names. That’s why Unix ended up with such memorable commands as “df” and “tar -xvzf”. For Enso, the problem is particularly noticeable for commands that that have similar beginnings. For example, the “translate to” family of commands makes my fingers unhappy. I have to type out all of “translate to” before choosing a language. Why? Because “translate from” is alphabetically before “translate to”, so that’s what gets autotyped when I hit tab.

I wrote about the autocomplete problem all the way back in March of 2007. We were hoping to be able to release a much improved autocomplete a month later, but ran into both usability and performance problems that kept pushing the release date back and back.

Our new autocomplete allowed you to select a command by typing bits of the command name. You could even type the parts that were most memorable to you. For instance, “offox” would match to “open firefox“, and “trantojap” would match to “translate to japanese “. We found that this worked very well most — but not all — of the time. When the command you wanted came up (90% of the time), it was like magic. When something you didn’t want came up, it was was like a curse; you had no idea what went wrong or how to fix it. This stems from our “best match” highlighting algorithms; they were clever, which meant that it was sometimes hard to know what to expect. Adding just one character could drastically change where the typed characters appeared, often without changing the matched command. For example, if you’ve entered “of” and then type an “o, the best match will go from “open firefox” to “open firefox”. You can see how it would be easy to lose track of what you’ve typed.

Two Part Commands

The problem with using our autocomplete is that there were too many commands. And there were too many commands because we were conflating the idea of a command and its argument. While it is convenient to be able to type “google pants” and “open firefox” as a direct command, it is cumbersome to type “translate to french outrageous accent”, and impossible to type “calculate 4+(2+.5)^3/5″ (shifted characters aren’t type-able while holding down the command key). Similarly, it is impossible to enter accented and foreign-language characters. One of the more common complaints about Enso is that it is sometimes frustrating to type while holding down a key. If we had our druthers (and could eat them too), we would have special keys below the space-bar that your thumb could hold while typing. Entry into the hardware market is hard, so we went for the Caps Lock compromise. In the new version of Enso we are separating the selection of the command from the entry of the argument. By disentangling the command from it’s argument, we not only gain fewer characters typed in the quasimode and a smaller number of commands to match to, but also more freedom in handling suggestions and matches. For example, we can now do things like suggesting Google suggestions in the “google” command.

Here’s how the command selection will eventually look after the user has held down Caps Lock and typed “o”:

It works like this: You hold down Caps Lock and start typing the name of the command you want e.g., open, go, google, calculate, etc. Because Enso is autocompleting to the relatively small number of commands, it can use the powerful autocomplete. You’ll now be able to type “ttojap” for “translate to japanese”. As soon as the command you want is selected, you let go of Caps Lock and a transparent entry area instantly comes up that lets you enter the rest of the command. When you are done, you hit enter.

Here are two examples:

To open Firefox, you hold down Caps Lock, type “o”, release Caps Lock, type “Fire” and hit enter.
To calculate, you hold down Caps Lock, type “cal”, release, type “31^(5/2.2)” and hit enter.

What happens if you want to calculate some text that you’ve already typed?

Select it, hold down Caps Lock, type “cal”, and release. The entry area will be pre-filled with your text. Hit enter the result is inserted at your selection.

This is a pretty big change. A fundamental change, even. One worthy of debate. When we were discussing this design internally, we were worried that having to release Caps Lock might break the user’s chain of thought into two pieces: choosing the command and then remembering what you were going to do in that command. We found that not only did we Humanoids not have that problem, but we actually re-habituated to the new design very quickly. Not needing to hold down the Caps Lock key while typing long pieces of text is a boon, and getting to any particular command is actually faster. We also worried about the modality of the entry area, but I’ll come back to that in a minute. First, the benefits.

By paring the quasimodal portion of Enso down to just the command name, Enso has become the best keyboard shortcut system in existence. Novice users can type out the easy-to-learn-and-remember full command name (”open”). Long time users can just use one-keystroke commands (”o”). Thanks to our new learning algorithm (I’ll come back to this in another section), those shortcuts will train themselves to your use patterns, yet never shift around on you. This means that the time cost for choosing a command is greatly reduced. Using Caps Lock “o” for open is key-wise equivalent to a hot key for calling up a dedicated launcher! Good design erases the line between beginners and experts.

One of the oddities in this design is that commands that used to operate immediately on a selection (like “uppercase”) now require a tap of the enter key after releasing Caps Lock. We’ve had a number of internal debates about this. There is something unsettling about forcing that extra key press, especially in the case of commands like “lower case” where it is almost inconceivable that you would use the command and then type into the entry area. But with commands like “calculate”, you often want to use the command without the need to first find a place with editable text to write an equation

So why not have the command execute immediately if there’s a selection, and only require the entry area step with it’s enter-key tap when there isn’t a selection? That solution is certainly clever, and I wish it worked. What we discovered in testing was that the method wasn’t reliable enough. When execute a command where you want to type the contents in the entry area, you aren’t thinking about whether or not there’s a selection. Trying to be clever made Enso just unpredictable enough to be really frustrating.

Possible future commands like “reveal”, which opens the folder containing a selected target, may not ever use a selection. In the end, we felt the need for the entry area (for commands like “calculate”) outweighed the oddness of tapping an additional key (for selection commands like “upper case”). And as always, we strove to keep Enso consistent; at least this way you can habituate to tapping the return key as part of the command gesture.

Isn’t The Entry Area Modal?

Stop the presses! Don’t you Humanized folks hate all things modal? Isn’t the entry area modal? The answer is we aren’t certain, but that we believe the answer is mostly “no”. We need user testing to know for sure. How can the entry area not be modal? Because the definition of a mode is:

An human-machine interface is modal with respect to a given gesture when (1) the current state of the interface is not the user’s locus of attention and (2) the interface will execute one among several different responses to the gesture, depending on the system’s current state.

Our argument is that the state of the system (e.g., that your keystrokes are going into the entry area and not into the application) will almost always be the user’s locus of attention. The entry area will never appear unless the user actively asks for it, so they are never surprised, never enter the information in the wrong spot, and never make mode errors.

In our informal testing we have found this to be true, except for one case. That is the case where you choose a command, and before you finish using the entry area, you become distracted by something on the screen and try to interact with it. Your locus of attention has been stolen, you no longer are thinking about the state of the system, and you make mode errors.

So we added a “resume” command to the design. If you are trying to interact with something else on your system, then Enso fades away with a transparent message telling about the “resume” command. The resume command does exactly what it sounds like: it resumes the state of Enso exactly where you left it. This way, you don’t get tripped up where Enso is open and you are trying to do something else, and it’s trivial to get back to where you were.

Resume works the same way when you cancel a command by tapping the escape key. If you’ve gone through the trouble of entering data, the computer shouldn’t just throw that away. So even if you escape, you can resume.

For the quick among you, there’s another question to be asked. Isn’t the state of what will be resumed itself modal? Good question. We are once again in a somewhat choppy waters that are best navigated by user testing. Our best guess, however, is that you’ll only use the resume command when you know exactly what’s in there, i.e., that it is your locus of attention (even if it is invisible). How is this different than the invisible buffer that is copy and paste? Only in one important way: That resume is not being used for storing important content that might not exist elsewhere.

The Learning Algorithm

We’ve been fairly vocal about being wary of adaptive algorithms. Most implementations break one of our mantras of good interface design. They aren’t habituatable because bits of your interface keep moving around. A lot of our readers have been arguing persuasively that we were too heavy-handed in dismissing all adaptive interfaces. If the algorithm respects habituation, then we have no right to complain.

Having Enso adapt to your behavior is a much-requested feature, so we revisited this subject. As you use Enso 2.0, the commands you use most often start bubbling up, which is similar to most other adaptive systems. However, once Enso thinks you’ve habituated to something (using a particular set of keystrokes to mean a particular command), it locks that command in. What does this mean? It means that if you’ve been using “ca” to issue the “calendar” command, and then add the “calculate” command to Enso, then Enso will choose “calendar” over “calculate” for the keystrokes “ca“, even though it is alphabetically second, because you’ve habituated to “ca” being “calendar”. However, “cal” is still fair game for matching “calculate” because Enso knows you haven’t formed any habitual associations for that gesture.

While this means that two Enso installations might autocomplete differently, that’s no worse than two Enso installations with different sets of commands. Eventually, you’ll want to be able to go to any computer and have Enso know who you are, so that all of your habits can be preserved (Weave, anyone?). But, that’s for much later.

Multiple Argument Commands

In Enso 1.0, the selection was an implicit argument. That’s how “open with” works: The selection is assumed to be the thing being opened, and the explicit (typed-in) argument is the application that does the opening. Something new in the Enso 2.0 design is that commands can have multiple implicit arguments. One of the commands I’ve wanted is the “email” command, which takes the current selection (by it a file or some text) and allows you to email it to a friend. Another is the “send to phone” command, which sends an SMS to a friends phone. Both commands benefit from not forcing you to write the message first.

There’s a design question left unanswered in how we name commands. Take the example of the “translate to X” family of commands. We have a choice:

(A) The language is included as part of the command name. That is “translate to japanese” is one command, and “translate to italian” is another.
(B) “translate to” is the command name and the language is selected as an argument in the entry area.

This doesn’t just affect the translate command family, but any family of commands that takes two arguments, the first of which determines the behavior of the command. For instance, there is the “convert” command family, which does conversions from one unit to another. Does the unit being converted to go in the command name? Or as an argument? We’re still working on this one. The issue is worth a blog post on it’s own right. I’d love people’s thoughts.

Conclusion

When it comes down to it, Enso 2.0 isn’t really much more complicated than Enso 1.0. We’ve split commands into two parts, and we’ve made the autocomplete and suggestions better. That’s pretty much it. Yet, I think that all of the problems we set out to solve have been solved, with a minimum of fuss:

• Enso shouldn’t make you type all of “open” every time
• Enso should be able to open paths and urls
• Enso should support international character input
• Enso should gracefully handle the case where there’s no convenient place to enter text
• Enso shouldn’t require you to type out text, select it, and then run a command when you’d rather run the command and then enter the text (think calculate)
• Enso shouldn’t make you hold down a key while typing lots of characters

There’s a complex process that goes into making products that are simple. Our actual design documents are many times the length of this blog post. They deal with many of the gritty and boring details that I’ve left out here, like colors, fonts, edge cases, state charts, ramifications, etc. Of course, parts of those documents are dedicated to the fun and exotic. Think command chaining/piping. I’ll write about that in a future blog post.

For now, I and the entire Humanized team would love to hear your feedback on the design. Oh, and remember not all of this is implemented in the soon-to-be-released Enso 2.0 prototype.

Why not just use a two part quasi mode?  (> means press    ^ means release)

CommandKey> CapsKey> $Command CapsKey^ $Argument CommandKey^ ExecuteCommandKey> CapsKey> Open CapsKey^ Firefox CommandKey^ Execute

Or for your calculate example:

CommandKey> CapsKey> $Command CapsKey^ $Argument CapsKey> $Command CapsKey^ CommandKey^ ExecuteCommandKey> CapsKey>CapsKey^ 2+2 CapsKey> Calculate CapsKey^ CommandKey> 4

AFIK no problems with special characters like forward slashes and the like, the Apple key would work better, it’s the closest thing to a LEAP you are going to be able to get…  Also solves the problem you consistently force on computers used by groups: the fact your are tuning the caps lock from one mode into another.  Hey, I could finally use it at work!I think I have a simpler solution for your adaptive interface problem too, but let me think about it.

I appreciate this exposure into your design process.

In the “email to” command example, what happens if you want to first type in the name of the recipient, and then type the message body? Would this be a separate command, would you have to do some kind of Tab and then shift-Tab keystroke, or what?

Gah, can we pelase add a rich text editor and/or more support for things like no breaking spaces and block quotes?

http://docs.google.com/Doc?id=dfx73qb9_593f2cjsddt

For a formated version of the above post.

why are all of these commands verb-noun instead of noun-verb? isn’t the command supposed to go after?

by the way, noun-verb would facilitate command guessing, so that would be more efficient than verb-noun.

What if people remap the caps lock key and don’t use quisimode?

Multiple arguments and typing areas look absolutely great.

I made a mail command for outlook, and it definitely lacks ability to type in the message.

With multiple arguments, I’m thinking of “remind to” “{pay the rent}” “{tomorrow morning}” that would create a calendar reminder in google.

Hope the extensibility follows the 2.0 prototype soon.

On “translate to” “{Japanese}” versus “translate to Japanese” I’d go with the later one to benefit from the learning algorithms. Most people would translate to one or two languages, so getting enso to learn “Translate to Japanese” as ttj would be the most efficient way to use the command.

I like the new interface design and command process. I HOPE you will updating the Developer API and releasing it at the same time you release the prototype, as I have written several commands that will greatly benefit from the new command process. Namely Mercurial which uses commands like hg commit -m “some sting of text”, but I cant get the “some sting of text” to work due to no quote marks allowed.

Now that said, I’ll talk more about command design:

First the requirement to habituate to tapping enter when you type a command with a selection.
This is bad command design IMHO since it would be simple to flag a command as not requiring an explicit enter. {eg. for my Mercurial commands, you need to set the working directory before you can execute the standard commands. So if I have a directory selected, I set the flag that tells the command I dont need to explicitly hit enter. Other wise the standard selection window comes up.}

Second I would like to ensure that Copy and Paste work within the argument entry windows.
Why? Simply because I may need to pause switch out of command entry mode to read something, and want to copy some of what I just read and put it into what I had been typing in the argument window. {eg. I start to send a new email to my buddy and half way though the message I get an IM from someone else that has a funny link I want to send on. I pause my command entry by switching focus to the IM window, then I copy the link (who wants to manually type a long URL) then resume my command entry and paste the text into the body of my email}

Third (and finally for this post) I would like to ensure that if I escape out of a command that I have started, then do another command and finish it, that I will be able to resume the command I escaped out of.
This may seem like an odd idea, but it does have several valid use cases. {eg. I enter a long command hg push -f to http://some.really.long.url/with/a/bunch/of/crap/in/it Then I realize I had not entered the commit command, which is required before a push, so I escape out, enter my commit command, then resume my push command where I left off}

Jo Huang is spot on the money. Trying to use Noun -> Verb more consistently allow better context for predicting the verb (this is what Quicksilver does).

Regarding verb-noun vs noun-verb, are there not more nouns than verbs? It seems to me there are so many possible options for nouns, especially as the number of plugins increases, that you’d almost need to add an initial category step just to narrow the choices of noun. Just thinking about the plugins currently available for enso, a complete list of nouns would include all start menu items, services, the music playing, file system paths, the selected object, open windows, bookmarks, search terms, email contacts…

I’ve always wondered how quicksilver dealt with this issue. It seems like the verb search space would be smaller, especially if it’s smart about normalizing verbs across heterogeneous nouns. And the verb would simultaneously narrow the noun search space significantly.

Having to press enter makes me feel uncomfortable, but it’s probably something I’ll get used to.
The advantages of the new system do seem nice though. It’s good to see you, whether purposely or accidentally, following my suggestion for the autocomplete algorithm.
One request would be to add a “scrollbar” to the scrolling. Not one that you can drag up and down, obviously, but just an indicator then of how many items there are to scroll through.

With regards to the noun->verb vs. verb->noun I prefer verb->noun simply because it closer models how I think. I don’t think “Firefox, I want to open that” it’s “I want to open Firefox”. It’s not “2+93 I want to calculate that” it’s “I want to calculate 2+93″

in English the direct object (noun being acted upon) comes after the main verb of the sentence, so this order is natural for the English edition of Enso. In many other languages (such as Japanese) the main verb comes after the direct object. I suspect that when Enso is internationalized this will be carefully considered.

Using [ENTER] to switch between the parts of a command is a really bad choice. By default, users know that TAB makes the cursor go into the next available field.

[ENTER] ends things. If you “enter” something, you want to get something back - have the command executed, the sum of 2 numbers shown to you - and don’t want to “enter” the next part of the command.

What if after entering the command and keep holding caps lock, it behaves as it does now. But if you release caps after the command it switches to the text box requiring you to press enter. That way for the short commands its as efficient as possible. It would still be a consistent interface in the sense that all commands work the same way, it’s simply how you use it that dictates the behavior.

You don’t need to type OPEN every time you want to open an application (or file)
- Hold down ‘Caps Lock’ (or whatever the access key is)
- Press the ‘O’ key
- Press ‘Tab’ to complete the word. It even puts in the space.

Why all the talk about why this is so difficult? I don’t even see it as a problem.

Compelling argument that the new argument entry isn’t necessarily modal. So if you buy that, why have the quasi-mode at all? Maybe press and release Caps Lock should bring up Enso. It might be faster (or might not), and it seems simpler and less awkward to me.

Also, given you now have discrete fields for each argument, would it be helpful to put default values in them? The user can then see what the default will be, and alter it if desired (by typing directly or changing the selection outside Enso or maybe even selecting previous/common entries from a dropdown). For some arguments, the default could be the product of the learning algorithm: let “Japanese” be an argument to Translate To, but with repeated use, it soon comes up as the default –no need to enter the argument at all for the one language I translate to all the time.

My reply is too long for the comments section, so check it out here:

http://jay.mcgavren.com/blog/archives/762

Caution: negative kneejerk reaction enclosed!

I don’t know if you doing it just in the site. but i really like the strips and would love to actually see them in enso 2.0

“You don’t need to type OPEN every time you want to open an application. Why all the talk about why this is so difficult? I don’t even see it as a problem.”

See the example of “translate to japanese” and other long commands. You have to type “translate to j” before you can press tab for the auto-complete. Of course, saying that if the command was broken into two using the new argument system you wouldn’t actually need that, and I suspect most of the long commands could be broken up similarly.

“Why have the quasi-mode at all?”

Pressing a key is too accidental. I knock the Caps key all the time (I notice it so much when I’m typing on a computer without Enso :S) You would have then lost data into Enso and it would be very disconcerting. But *holding down* Caps and typing something approaching a valid command is quite difficult to do accidentally, and so you can pretty much guarantee the user actually meant to invoke Enso and not just do it accidentally.

I’m really looking forward to getting my hands on this! I’m also looking forward to messing with the developer API - and hoping it’ll be changed so Enso can just load a Python module.

Any updates on the possibility of open-sourcing Enso?

I’m with Jay McGavren here. His blog post is really worth a read and I agree with every point he makes (maybe I’m a little less dogmatic concerning the Quicksilver-like learning algorithm).

I can imagine that, to the folks at Humanized, it may look like if we were trying to be more catholic than the pope, but to me, too, the quasimode tangibly reduced the stress from what I like to call “what-will-happen-if-I-press-a-key anxiety”. I feel much more at ease with Enso than, say, Quicksilver.

It may be that I’m too selfish. I’m an apt touch-typist, and I’m using a Kinesis Contoured keyboard that lets me go into Enso quasimode comfortably using my left thumb, which is very comfortable. (Heck, I could type several paragraphs in the quasimode.) But isn’t exactly this the way Enso (or Archy, or THE) was meant to be used? Maybe the changes in Enso 2 would make it slightly better to use for those with a “normal” keyboard, or for those who can’t type well. But for people like me, Enso will be reduced from the best thing since sliced bread to just yet another launcher.

There are already people out there to whom the vision of Jef Raskin has become a reality. Don’t take it away from them.

Will the prototype also be in a mac version?
Just a question.

What is needed is a Enso scratch pad built to work with the Enso command interface.

Steps to Calculate:
1. Capslock press > (Sc)ratch > Capslock release
2. Type equation
3. Capslock press > (Cal)culate > Capslock release

Note: The scratchpad will automatically bring up a new fresh page, and will save every keystroke much writing on paper, but better. For example you could navigate the history of that text so that you could see the previous equation.

Steps to send Email:
1. Capslock press > (Sc)ratch > Capslock release
2. Type email.
3. Capslock press > (Em)ail > Capslock release

Note: for specifying other arguments such as email, send to, cc, etc. These would need to be specified in the scratchpad. For example, , could be used to specify the subject. Also, , and could be used. These argument fields could have auto-suggestions for assistance, like shown in your examples.

(subject: foo bar), (to: foo@bar.org) and (cc: bar@foo.org) could be used to specify arguments.

Braydon - while I would love to see a scratchpad for other reasons, I point out in my response to Jay’s blog post my reasons for why it’s not a solution to the calculate problem.

Could you think ybout adding time calculation ? For example: 11:54:32 - 1:49:12 = 0:05:20
?

@[ICR]

Perhaps instead of

1. CLpress > (sc)ratch > CLrelease [opens a fresh scratchpad]
2. Type equation.
3. CLpress > (cal)culate) > CLrelease [calculates the equation in the fresh scratchpad]

It would be:

1. CLpress > (cal)culate > CLrelease [if no selection was made previous, it would open a fresh scratch-pad (or equation-pad) which can save all it’s history, and can later be moved, or modified.]
2. Type equation.
3. Press enter [calcuates the equation]

SUBJECT: Nouns & Verbs

CONCLUSION:
Both Verb -> Noun and Noun -> Verb should be considered, and optimized.

BODY:
If you say “I must drive that car!”. Before the sentence, you had already selected that car in your mind, and is thus Noun -> Verb. This is true unless your ambition is simply to drive. Then it would read, “I must drive… that car!”, and is then Verb -> Noun.

The Wordpress Admin is organized Verb -> Noun. In this case the verbs are the most important. “I must blog… this entry!” However this isn’t often how it’s used. You might be writing or surfing the net, and then think, “I must blog this article!” In this case, the process is, Noun(the article) -> Verb(wordpress admin) -> Noun (wordpress entry).

The command-line interface is structured Verb -> Noun:
tar -xvf foobar.tar.gz. However, it’s not often how it’s used. We often will have already selected the noun previous to running the command, so it actually is Noun -> Verb -> Noun. In the case with the command “python”, you are not required to have already selected a noun, and can enter python interactive mode. Here the verb, python, is the focus.

Verb -> Noun is useful if the focus is on the verb, such as the python interactive terminal. Noun -> Verb is useful if the focus is on the Noun, such as “tar -zvf foobar.tar.gz”, and “I must drive that car!”. Both sequences should be optimized.

Enso 2.0 should integrate with firefox’s bookmarks so that they can be opened the same way applications in the start menu are opened

Noun-verb vs verb-noun is already covered in The Humane Interface, so i don’t see why the humanized people do verb-noun.

imagine i’m typing a web address. enso could easily guess that it is an address, from http://www. and other characteristics such as no spaces. firefox would be inferred, and displayed as the default command.

noun-verb is covered in Raskin’s widget of the week #9.

fixed link.

I find Braydon Fullers first suggestion most promising:

1. Capslock press > (sc)ratch > Capslock release
2. Type equation.
3. Capslock press > (cal)culate > Capslock release

I think the scratchpad’s special function for enso would warrant a shortcut in this case, like invoking it with CLpress > [Space] > CLrelease.

Brandon’s first suggested behaviour would be strictly Noun-Verb, and, with a scratchpad history, it can easily accommodate multi-noun commands like “email”:

1. CLpress > [Space] > CLrelease
2. Type email address
3. CLpress > [Space] > CLrelease
4. Type message
5. CLpress > email > CLrelease [sends an email composed of the two last entries in the scratchpad history]

The scratchpad history would be an equivalent to Archy’s selection history.

As visibility is important, when selecting a command, Enso should show the scratchpad text(s) the highlighted command would use if it were executed.

When the scratchpad is active, at the moment the user pushes down the Capslock key for the next time, the currently open scratchpad is dismissed and its content moved to the scratchpad history. Of course, this press of Capslock brings up a fresh enso interface immediately, just as it normally would. That way, sending an email is really a sequence of simple Enso commands, and not one complex Enso command.

What follows is that pressing and releasing Capslock is the primary way of dismissing the scratchpad. Natural: If you don’t want to do something with the text, just don’t type a command. (Dismissing with [Esc] should still be supported to conform with user expectations.)

You can always get to the earlier entries in scratchpad history by pressing the page-up key when the scratchpad is active. (And back again with the page-down key.) No special “resume” command necessary. You can immediately re-edit any old history entry just by typing in it. When you dismiss the scratchpad, the currently active text becomes the latest history entry. That way, you can make any old history entry the latest entry (”bump” it) and re-use any old texts like mail addresses etc. easily.

When using a command the way it was meant to be, e.g. calculating the current selection in your text editor, of course that selection becomes the latest scratchpad entry, so you can always get back to it later, and Enso’s behavior stays fully consistent.

That’s the reason I don’t really like Braydon’s second suggestion: the interface would act this or that way depending on the context.

What interesting about Andreas suggestion is the ability to link a series of scratch-pad entries into arguments for a command. I think that this can allow for a rich flexibility.

However, there should be a way to specify between a “fresh” scratchpad, and a scratchpad that “extends” the previous…

so that instead of:
1. CLpress > [Space] > CLrelease
2. Type email address
3. CLpress > [Space] > CLrelease
4. Type message
5. CLpress > email > CLrelease [sends an email composed of the two last entries in the scratchpad history]

It would could be:
1. CLP > [Space] > CLR
2. Type email address
3. CLP > [Enter] > CLR
4. Type message
5. CLP > (Em)ail > CLR [sends an email of the last series of scratchpads]

This way if you would like to start over, you simple press CLP > [Space] > CLR again, this woul also tell enso which arguments belong together.

There would need to be classes of scratchpads, so that upon the final command, it would know what argument it represents.

For example you could get complex:
1. Select a file.
2. CLP > [Space] > CLR
3. file: selected file [this is automatically entered]
4. CLP > [Enter] > CLR
2. person: Type persons name, and another person, and another
3. CLP > [Enter] > CLR
4. text: Type message
7. CLP > [Enter] > CLR
8. person:bcc: Type persons name [you’re allowed to use multiple compatible classes]
5. CLPress > (Em)ail > CLrelease [sends an email based on the collection of previous entries.]

To assist in choosing the right class, there can be auto-suggestion, and a reference guide based on what the user has installed.

You could also use different final commands, Search, Blog, etc…. If a class type (or argument) is not understood by the command then it would then give en error saying that previous arguments were ignored, and would continue. Likewise, if an argument that is required was not specified, it would tell you what is missing, and you would continue the scratch-pad with the missing arguments, and then you would try the command again.

This kind of thing could allow for both Noun->Verb, and Verb->Noun, so that if your locus of attention is on the verb rather than the noun, you’re not interrupted.

To calculate you could:
1. CPL > (Cal)culate > CPR
Enso would warn, “Nothing to calculate” and would bring up a fresh scratchpad automatically, with a default initial class already chosen (for multiple argument commands).
2. Type equation.
3. CPL > (Cal)culate >CPR

Or you could:
1. CPL > [space] > CPR
2. Type equation.
3. CPL > (Cal)culate > CPR

Also by choosing a verb first you could get assistance w/ which arguments are required.

To email w/ verb first:
1. CPL > Email > CPR
Enso warns, “Nothing to email” and brings up a fresh scatchpad with a “text” class already selected.
2. Type message.
3. CPL > [enter] > CPR
Enso then brings up an extension scratchpad with a “person class” already selected.
4. Type person’s name
5. CPL > Email > CPR

This would be good for learning, as entering the email command twice is repetitive, however you’re assisted through which arguments are needed. The optimized (expert) method is to start with CLP > [Space] > CLR, this will also give you freedom in the order the arguments are specified.

Braydon, I think I understand what you’re aiming at.

You suggest the arguments to be explicitly grouped for a command (CL-[space] would separate them). And, for complex commands, you suggest there will have to be types.

I understand that it’s somewhat unusual to have a command fetch the one or two last scratchpad entries without having a way to tell it what and how many they are. But that only holds true if we let commands become arbitrarily complex.

So while it may seem that will be uncertainties about the comments, there really won’t:

Firstly, every command always has the same number of arguments. Their order is always the same.
Most commands only have one argument. Very few, like email, will have two, but there shouldn’t be any commands with more arguments, because that’s where Enso doesn’t bring much improvement any more.
More complex commands would need forms to guide the user. But, as it is, those kinds of forms already exist the user interface. For instance, there should be a command “compose email” that takes a mail address and invokes your mail client’s new mail form with it. No need to implement a full-featured mail client in Enso.

To me as a long-time Quicksilver user, the suggestions sound very familiar. In Quicksilver you can group arguments (nouns) by pressing “,” (Comma) instead of Tab. Your CL-[Enter] suggestion reminds me of this. Quicksilver commands with parameters had a strict noun-verb form, but you could swap the order of the “direct” and “indirect object” in the noun-verb-noun form. This is what your verb-noun suggestion reminds me of.

But for me, this added complexity in Quicksilver just didn’t catch on. Having those choices feels good, but making those choices wasn’t easy at all. Every time I tried to use a command in inverse order (such as [person]-mail-[file]), it took me a couple of seconds of additional conscious effort to achieve the same goal that was easy the other way round. I could become comfortable with one way of performing a particular command. That’s why I prefer to think of the verb-noun order as a mere fallback, at the most.

Quicksilver sort of tried to replace much of the OS behaviour with own commands. I don’t think that’s Enso’s goal. I think Enso takes the, say, top 50 routine tasks that are tedious to perform normally, and gives us a better way to deal with them. When the tasks become more complex, so we have to think about them anyway, Enso’s advantages rapidly diminish. The gain of those features would be relatively small, and they would make the top tasks more uncomfortable for everyone else (e.g. due to more choices having to be made by the user [or more keys having to be pressed — cf. Enso 2.0]).

Noun-Verb works a lot better for a waterfall model of selection, especially visually. However, the speed at which Enso is designed to work I find a natural language (for me, English) works a lot more effectively.
Don’t forget of course that Enso does also work with Verb-Noun with respects to selection.

@ Andreas

In my humble opinion, an interface such as Enso does not have *significant* benefits until it is deeper and integrated into the OS.

Often the largest performance gains are not making something you can already do faster, but to allow you to do thing’s you can’t do at all.

Something to consider.

Furthermore, is “faster” even what is desired, or is “quality” what is desired. Perhaps significant *quality* improvements can be made in a similar way of writing software to do that software doesn’t already do.

@Braydon

I hear you and I see your point. We probably just have different opinions. I see it from a 80/20-like perspective: Pick the few most frequent annoying tasks and make them easy.

As an example: With Enso 2.0, people who were perfectly comfortable with the previous version will have to press an additional perceived “execute” key. While this allows for complex commands like “email [this] to [them] attaching [file]”, i’m afraid of Enso taking the direction of trying to “be everything to everybody”, and, in the course of adding more and more functionality, the few most frequent tasks get more tedious.

Again, I also understand your argument about the “quality” that is improved. Yes, I’m convinced that a full-featured mail client by Humanized would be much better to use than, say, Outlook. But, while the programming effort is tremendous, the gain would be relatively small. While I see Enso’s benefit of sending a short message or text clipping to a colleague, there’s hardly any such benefit in complex use cases. For those, there should be an Enso “compose mail” command that just opens a “New Mail” window in Outlook:
- Enter recipient, Tab
- enter CC, Tab
- enter subject, Tab
- enter message
- press Ctrl-Space to send.
That workflow already is pretty close to optimal. If Enso had that built in, it would just replicate existing functionality without much gain for the user.

@Andreas

Picking the few most frequent annoying tasks and making them easy, contains Enso in a box of tasks we already do. To get a significant advantage, Enso can tackle tasks don’t do.

One of these not-done tasks might be manipulating large quantities of files at once without leaving the file system structure. For images, ImageMagick could be used. Another task could be controlling a revision control system such as Git or Mercurial, without navigating to the command line, this would allow for much more granular revision control.

Also integrating Enso w/ other filesystems that are database-like, such as OpenBeFS used in Haiku, could also introduce a completely water-like way of organizing your space. Using Enso as your system search you could ‘without thinking’ navigate to (spaces) that would automatically have files there. You would never need folders. Separate virtual inboxes, (in your file system, not in your mail application), could be based on Enso-Haiku search queries, and kept available for quick reference, or by quick key command.

On your point that the programming effort for a mail client would be tremendous is not true. There are many email applications that are already written, and Enso can interface with it’s API drastically lowering the barrier of entry. Such applications being, Exim, Postfix, and Courier. SpamAssasin, ClamAV could be used locally for email cleanup. GnuPG can be used for encryption. Furthermore all you your emails could be stored in the FS and not in the mail client, meaning there wouldn’t really even be a “mail app” to go to. The wall around that application, gone! :)

@ Andreas

To your point about frequent tasks being clouded by the bloat of expanding features: This can be easily fixed by allowing for a highly configurable interface. This way if a task is more common to you than to others, you can optimize it to be less tedious. Furthermore the features that you use can added, and removed as you see fit so that you never have too much, or not enough.

For me, 2.0 is a BIG leap forward in usability over 1.0. Keep up the good work!

(and count my vote with the verb->noun group.)

@Braydon

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]).

…watch a quick tour of the Interface Demo: part one, part two.

@Andreas

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.

@Braydon

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?

@Andreas

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.

Would it be possible to begin typing “firefox” and then choose “open” or have enso guess that obviously we may want to open or close it whether it is opened or closed. Of course, just opening firefox may be already old, since we could start a web search already and have it opened automatically. But I wanted to know if starting with the object then choosing the verb could be in the plans… because there are often cases we think in this order… Is it possible to guess if the user has entered a subject or a command… Maybe it is (quicksilver already does this?)

vxmp1zz1517nm034