Bugs and Stubs

Design Our Products

As usual, our readers delighted us with the number of well-thought-out comments about our recent release of the Enso 2.0 prototype. We’ve posted a new version of the prototype here, with several bug fixes and some tweaks to the visuals of the new argument-input box. If you found the previous prototype to be crashing too much to seriously consider, please try again; the new one should be more stable.

The most serious criticism raised of the new argument input step is that of noun-verb versus verb-noun, and the more complex grammar forms that the 2.0 design raises. This is a serious user interface design issue, and Aza is going to do a separate post that discusses this in more detail. We should have that article out sometime next week.

What I wanted to do now was address a large number of the issues raised by comments on the weblog post and bug reports submitted concerning the prototype. Just so you know, I have two rugs under which I’m going to sweep most of the issues. The first rug is bugs: the prototype has lots of bugs, some of them pretty big. Unfortunately, sometimes it’s not clear that they are bugs. The second rug is stubs: due to time limitations, we were unable to implement all the features of the intended design, so there are several places where we’ve “stubbed” out the parts we couldn’t finish.

Why Require “Enter”?

Several people wondered why we required the “enter” step, even when you’ve got something selected. If I’ve selected something, then why not execute the command with that selection? There are two parts to the answer.

The first reason we require enter is: design consistency. If it is possible to use an argument input step with a command, then that argument input step should always appear. Imagine that we are able to always perfectly detect whether the user has a selection in Windows. Now, imagine you’re in a limited price field on a web site. You use Enso’s “calculate” command, because you want to check some numbers. But because the number in the price box is selected, calculate simply echoes that “3.13″ you had selected. The argument box you were expecting doesn’t appear, and your habituation is broken. So instead of Enso attempting to guess what you were thinking, we always open the argument box, so you can habituate to tapping return.

Second, as people started realizing during the discussions in the comment thread, reliably detecting in every application whether the user even has a selection is technically very challenging. Worse, in Windows (and possibly in most modern operating systems), the concept of the user’s selection isn’t even well-defined; which of the open windows has the user’s attention? It’s not always the active window. Enso does it’s best to fetch a selection if there is one, but even that is buggy. For instance, one user commented on Enso’s behavior if IM-client Pidgin is open; by assuming “Ctrl-C” was the best way to trigger an application copy, Enso triggered an different and undesired behavior. In short, Enso can’t reliably know that the selection is the user’s locus of attention, so Enso can’t reliably make decisions about whether to display the entry area.

Both of these reasons point to a deeper reason for the Enso 2.0 argument input design. Enso is working around fundamental design flaws of Windows that are hard to describe briefly, so I won’t make the attempt. For those of you familiar with it, suffice to say that Windows is not Archy: there is not always a place to enter text. The new design is a compromise, just like Enso itself was a compromise.

Various and Sundry

Has [the learning algorithm] been implemented? I have tried to get Enso to learn that CAPS+C means “close,” not “Calculate.”
The new autocomplete algorithm has only been added to the argument input step. That includes the “learning” algorithm. Sorry; this is a prototype that sits on top of the existing software. We’d really like to have the new autocomplete algorithm and the learning algorithm be part of main Enso, but that wasn’t possible in this prototype.

When confirming an action, the enter key seems to far away from the caps lock. Why not hit the caps lock again instead of the enter?
Using the Caps Lock instead of Enter would make Caps Lock into a toggle. Not good.

I think the orange-box-in-the-middle-of-the-screen functionality is nice, but users should be able to turn it off if we want.
We won’t be adding a user preference for purely-quasimodal versus two-step. Allowing users to “turn off” the argument-input step wouldn’t make sense unless we had a way to provide the same features without the use of that extra step. And if we did have a way to provide all the new features in a purely quasimodal way, we’d prefer to simply stick with that design, rather than making it a preference. If you have ideas about how to enable arbitrary foreign-language input in a quasimode, we are all ears.

What might be nice, however, is if the solution was, in those instances, copied to the clipboard so that it could then be pasted easily to the location of your choice.
For those wanting the output of commands to be placed on the clipboard, try the existing “put” command. Among other things, it respects the contents of the clipboard (one of the hidden things we spent a lot of time developing, which few people realize is there).

I guess a partial solution to the Ctrl+C problem would be to first try WM_COPY, and then if that fails use Ctrl+C.
Good guess! Actually, as we discovered when we started testing Enso in the early stages, many individual applications require different solutions. “Ctrl-C” turns out to work in a surprising number of places, so we chose that as the default. We’ve got the architecture for handling each application in its own way; and some applications are already accommodated (emacs and the command prompt, for instance). In principle, it will be simple to extend Enso to work correctly with other applications where “Ctrl+C” means something different, such as Pidgin. In practice, it’s been frustratingly slow to extend coverage to all the applications we’d like to support. Eventually, we’d like to open up Enso to enable anyone who knows how to communicate with a particular application so that they can contribute that knowledge.

That’s All For Now, Folks

I regret having to say this, but due to our transition to Mozilla we aren’t going to be able to work directly on Enso design for a while. That means that, beyond the prototype we published today, it will be some time before we can release any new functional upgrades. On the plus side, we’ll have good news for you soon about the future of Enso.

It does fix the crashing when showing the list of “open” parameters, thanks.

The speed seems to be back with this release. (no more delay after choosing an item) Thanks!

“We won’t be adding a user preference for purely-quasimodal versus two-step.”

This seems entirely reasonable. However, I am curious about whether or not thought has been given to the idea that Enso could remain quasimodal when the caps key is held down and the user continues to type. (This was discussed by a few people in the last thread; I believe Leafy was the first to suggest it.) I certainly agree that it doesn’t make sense to offer a preference that removes some of the functionality of Enso, but that doesn’t preclude the possibility of allowing people to run limited commands on the fly without using the input box.

I genuinely appreciate the prompt and informative response to the concerns of both myself and other Enso users offered in this post. Good luck with your transition to Mozilla.

Just open the source! I’ve got the developer API beta but there are many things that I’m not succeding in doing (for example, interacting with itunes from within a custom command).

If you’re time/resource constrained, just open-source the app. Do everyone the greatest favor you can. Enso is great — but its potential is far from realized, and there will be a highly grateful user & developer community waiting for you when you decide to embrace them.

Rock on! :)

(It doesn’t really matter who suggests it first ^_^)
If quasimodality is removed I might just as well stick to Enso 1.0 :(

There’s a particular reason why I just loved Enso — the quasimode let me feel confident about where my input text was going; and I don’t need to give a delimiter command (enter).

As for the enso’s utilities, all of them don’t need an enter, such as the Calculate command in Launchy as mentioned by Russ in previous thread.

CapsLock needn’t work like [Enter], but it can do good as an [Esc] command when modal boxes are open.
IMO Toggles aren’t *that* bad especially when we can tell if there’s a change of state — take for example the power button of an LCD monitor..

Thanks for the quick answers and the new prototype. Keep the good work and good luck at Mozzila.

While i’m writing this, i’m listening to Astor Piazzola at Songza, thanks for that :)

Idan, I have no inside knowledge, but I have a feeling that if it were as simple as “just” opening the source, it would have happened already. There may be licensed code or other such encumbrances inside Enso.

On the plus side, we’ll have good news for you soon about the future of Enso.

Damn the innuendo! I’m not asking for anything crazy or inflammatory like BSD vs. GPL — but just say it already. The suspense is killing me.

Personally… I don’t mind if it’s closed-source or open-source as long as it’s multi-platform and extensible (which are the goals of enso launcher anyway, I believe).
Also, having it closed-source means singular focus… There are very few major open-source projects of whose all the forks are monitored by the head team.

By the way; BSD FTW :P

I really feel that if the user arrows into the auto-complete list, the first Enter should bring the text up to the box for the user to confirm. The second Enter executes it. I realize this overloads the Enter key, but Shift-Enter does not feel obvious or discoverable. And commands with multiple entry boxes (open with) require a mechanism for pulling the text up prior to command completion. Overloading is the lesser of two evils.

I want to expand upon Boris’ comments regarding “open with.”

There is no need for “open with” to be a separate command with separate gestures. “Open” should always provide the “with” box for optional entry. When it is not needed, the user just presses Enter as normal. When it is needed, it can be tabbed to. Commands that do not require “with” can have the box preloaded with the appropriate value (Firefox, Windows Explorer, -blank-). All commands would behave this way, with additional auto-complete boxes popping up where applicable.

Define water with dictionary.com
Translate water to Spanish
Translate wasser from German.
Translate wasser from German to Spanish

Implementing the same concept, but with a single text box has its virtues and challenges. That should be considered as well. (That is, all commands, extenders, and argument are entered into a single textbox and the auto-complete list changes based on cursor-position within the command.)

it still won’t install with vista 64

> the first Enter should bring the text up to the box for the user to confirm.

It is amazing that in 2008 there still isn’t a universal gesture for something as primitive as “select.”

I revise my previous post. “Enter to select” can’t be used since selection is needed even when the user has not arrowed down into the auto-complete list. I still don’t like Shift+Enter. Shift tends to indicate a promoted version of the base command (as in Shift+Delete vs. Delete). Shift+Enter does not follow that trend.

Though popular, Tab for select is a poor choice. Tab is already being used for navigation. Allowing it to double as the auto-complete trigger can be annoying in the cases where you just want to navigate and you don’t want your text “completed.”

Within Windows Ctrl+Space is the de facto choice. Windows Explorer uses it. My vote goes to Ctrl+Space.

One more addition:
When the user arrows into the auto-complete list, Enso could follow the cursor using a popup-graphic similar to the Songza.com four-headed-arrow. This popup would be a 3-headed version (missing the left-pointing arrow). Instead of “play, add to play list, rate,” the arrows display “up, down, select.” When arrow-ing through the list, the keyboard right-arrow selects the highlighted item and sends it up to the orange box.

On a sidenote…..
When I press [alt] while holding [capslock], it shifts the program to a modal state. Isn’t that nuff?

congratulations!

I tried an early version of enso last year, and found it to be not very stable. This most recent prototype is working very well for me.

Thank you for making this free also!

I have a sort of request.

Can the second input box in “open with” be on focus by default?

If I go through the whole trouble of typing “open w” as opposed to “o,” maybe I already have something selected that I want to open. I guess that could be checked, too:

if command == “open with” and selection != empty:
second_textbox.focus()

=o)