Enso 2.0 Prototype

Our Products

Get ready. Flex your pinkie finger. It’s time to try out the Enso 2.0 Launcher prototype. It runs on top of the free Enso Launcher, so all you have to do is download the prototype, install, and try it out. You’ll get some new features, several improved commands, and (of course) all of your old commands will still work. If you haven’t been following our weblog, you might want to read about the motivation behind this design, and our explanation of the design .

What’s In The Prototype?

Open has a lot of new tricks. It splits the argument off from the command name, making it possible to do all kinds of things. It uses a new autocomplete system, so you can type whatever you remember. It can open URLs and paths. It remembers what you’ve opened in the past, and makes suggestions appropriately. You can even browse through the your hard drive using tab-completion (actually, we picked “shift-enter” for these completions — we’re still experimenting).

Joining the improved open command are several other new-style commands, including open with and calculate. And the google command now provides as-you-type suggestions for your search term. It works great for quickly checking the spelling of those hard-to-sound-out Russian composers.

What’s Not In The Prototype?

There’s a lot of odds-and-ends that didn’t make it into the prototype. Things like being able to use Ctrl-V inside of the Enso entry area. For these not-yet-implemented features, the prototype displays transparent messages letting you know that the feature would work, if only this wasn’t a prototype. As for the larger stuff: The visuals aren’t up to speed yet, we haven’t revamped the quasimodal portion of Enso, and not all of the commands have been ported.

Enjoy! And let us know what you think.

The orange box should appear right next to the original command in the top left corner of the screen. It is distracting to have to look at the middle of the screen after I was just typing in the top left corner.

I agree with Patrick.

But this crashes much more than the regular version for me, so I’m switching back until later.

hitting tab once you’ve confirmed the displayed command is what you want should add a space as well — currently if you type “goowindows” you get “googlewindows” and not “google windows”

i love the new open functionality though. works much better.

Hey. I am a paying costumer, in other words, I am using the old version of enso. I tried to install the prototype since it says it installs on top of existing enso, but as far as I can see there has been no change. What do I do? I don’t want to uninstall the old one, at least not yet..

oh my god.. what have you done? I couldnt get the prototype to work, so I uninstalled enso (couldnt find an prototype installer) and reinstalled the free version (I want the one I payed for instead please?) and now it behaves differently? Typing “op” and hitting tab or enter will autocomplete the open BUT NOT ADD A SPACE. This is frustrating, since I have habituated that auto-space..

ok sorry for the spam. But the actual problem seems to be that it doesnt work at all now. it doesnt recognize any commands. How can I fix it please? I am now an enso addict..

The prototype should support other keyboard layouts. I use a qwertz keyboard, but in enso, the querty layout seems to be hardcoded.

Hi,
the input box of the calculate programm does not respect foreign keyboard layouts.

If i want to enter the “+” sign with my german keyboard I first need to find it…

oh, I just saw Florian’s post…
sorry!

I agree with the first two posts in that the secondary command box should be located near the original command box. Moving from the top left to the middle doesn’t allow for a fluid process.

ok. im a moron. its the new workflow. I 100% agree that the box for input should be located in the top left corner though

I am a recent big fan of Enso, i think this version will be a great change.

Bellow is a list of what i think could be changed:

1. Agree with patrick about the position of the new orange box.

2. 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?

3. Non English Keyboards don’t work (in the calculator, when i want to put a “+” it shows a “[”.

4. OPEN WITH it’s not working well: when i select a file and give this command, it focuses on the OPEN box and not on the WITH box, like it should.

5. The “(…) is not a command” message should fade by itself in 2 or 3 seconds. As it is, i have to press ESC.

For now, that’s all. Thanks again for this excellent software.

I’ve noticed a bit of a delay after using the open command that wasn’t there before. I really liked the responsiveness of Enso before this and I hope moving forward we don’t lose that.

I’d also like to add that I like the new keyboard workflow. (capslock > command > release capslock > target > enter) It seems very efficient and is a nice transition from the old version.

I don’t like orange box for two reason.
First: To open application now I must do two steps (caps + o, then name + Enter, instead of caps + typing ;))
Second: As others suggested orange box should be on the left (first time I didn’t realized that something is displayed on center od the screen)

I agree. I was not expecting the “open” in the upper left to disappear and an orange box with an “open” label to appear. When CAPS is released, the upper-left open should remain. The orange box (sans label) should pop up next to it.

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

Has this been implemented? I have tried to get Enso to learn that CAPS+C means “close,” not “Calculate.” Where will the configuration data for this functionality be stored?

Also, “open h” crashes Enso for me each time. (Luckily I still remember how to open the browser the old fashioned way.)

I’d like it to be both quasimodal and dialog-based — if I don’t release caps after typing “open” i should be able to continue typing the name.

With the pure quasimode format I can quickly switch between windows and I don’t like the dialog based method that much because I have to press [esc] to tell it that I don’t need it anymore.

That’s one of the reasons I used to install the then-trial version of Enso Launcher even though Launchy seemed a better offering for launching programs.

I like what I see. Its defiantly easier to use than before. The extra step for simple opens is worth it when it comes to the longer ones. Now instead of “open internet inf” to get to IIS its just “o” “inf”. At the moment its crashing alot, but I’m sure that will change. If you need any info about when it crashes, let me know. I think I agree with Patrick about placing the box in the upper left. I seems like it would be better there, but Its hard to tell without seeing it. Keep up the good work.

I’m not sure where I would want the orange box to appear, the upper left or in the middle of the screen.

After a few minutes I realized that I having the box appear in the center worked better for me. I was already focused on the center of the screen when I started my “open” command.

Also, it isn’t just “open h” that will crash Enso, “open o” will also cause a crash.

I think that second diaglog box (orange box as so many have named it) is APPROPRIATELY placed. There is no need to put it in a left corner of the screen.

Right now it seems quite unusual for me because I’ve used to be working with Enso in a sticky mode. However, considering current changes I’ve decided to give quasimode a second try and I’ve found it more practical than in the previous version.

I agree that users should be able to press either CAPSLOCK or enter when confirming their entries in the dialog box. Right now CAPSLOCK just has the same functionality as shift.

1. Agree with the center placement of dialog. After habituating (I hate that word btw) to commands, I will stop looking at the upper left at all.

2. I too would like to see an optional quasi-modal open, but I think there’s a major issue with it. It would be great if I kept holding down the caps lock, I stay on the same line as the open command, and when I release, it opens the selected app immediately, just like Enso 1.0. If I release caps after matching the open command, but not typing anything after it, open the argument dialog. But, I’d only like that if the matching worked like the prototype, with the fuzzy matching and learning algs (mffox should match “mozilla firefox”). The big problem is that if I’ve type my way into the quasimodal mode, then decide I want to cancel, I have the mash a lot more characters on the keyboard to not match anything.

3. Suggesting for the calc command: display the answer in the argument box as I type. I use Launchy for quick calculations, and I like that it shows the result on-the-fly. Your current prototype requires I paste the answer somewhere before I can see it, which is especially inefficient if I want to quickly do a series of calculations.

4. In the open argument dialog, the suggestion list requires the use of the down arrow key. The down arrow is usually not conveniently located for fingers on the home-row of the keyboard. It would be great if there were an alternate key for clicking down the list, like tab, shift or something.

5. When navigating to a file: Accept forward or backslash. The backslash is way out of the way from the home row. This is one of the minor things which make the unix command line so much more typist friendly than the windows command line. If you just allow use of either the forward or backslash when typing paths, it would be great, and wouldn’t disturb life-long windows users who are used to the backslash.

6. Also when completing file paths, when doing shift-enter to auto-complete, if the selection is a directory, add a ‘\’ after the folder name. It helps visually indicate that the selected item is a folder rather than a file, and saves an extra key when typing out a long path.

I’d be overjoyed to have a way to type out paths which is as good as bash’s command line. I’ve never encountered any path-typing solution on windows which was anywhere near as efficient and user friendly as the bash command line approach. Mostly because it lets me use forward slashes, fills in slashes for me when it auto completes directories, and has a really clean way to display suggestions for auto-complete.

I second Russ Egan’s point 4. Due to poor keyboard design, reaching for the arrow keys is inefficient and breaks one’s focus. Tab and Shift-tab would be excellent replacements for picking from the list.

Also, the auto-complete list is great. The go command always felt too award before. With the drop-down list, it is much improved.

I think that the new interface gives better flexibility and I like where it is going. But personally I don’t like the Orange box appearing in the middle of the screen. Whilst typing in the command (verb) you are focused on the left upper part of the screen, then you have to switch to the middle, it seems cluncky to use. It would better if the Enso interface was in one place.
The entering of paths is very nice, could we have network paths too please?

OH NO! More complexity!

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.

I prefer having the option of a one-step process rather than having to go through a two-step process every time I want to open something.

go desktop

The go command should always include a “desktop” item. Enso should habitual-learn for command and argument. g (for go) d (for desktop).

First, I agree with Leafy that you should be able to keep caps down and have it remain quasi-modal if you so choose. Also, just to weigh in on this, I like the input box in the center of the screen.

Anyway, my real comment is about the implementation of commands run on highlighted text. I took it that the whole point of Enso was that it doesn’t break your train of thought any more than necessary. That being said, I think it’s a mistake to paste highlighted text into the input box and make us hit enter again. If I highlight a URL and hit caps+open, I can’t imagine not being sure I want to visit that site. This is especially true with calculations; if I highlight “4+5″ and type caps+calculate, the great thing about the previous version of Enso was that it immediately replaced the text with “9.” Pasting that text into the input box and making me hit enter again isn’t much better than popping up a dialogue box to ask whether I’m *sure* I want to perform that calculation.

“5. The “(…) is not a command” message should fade by itself in 2 or 3 seconds. As it is, i have to press ESC.”

Move the mouse or press a key. It’s the same as it has always been for me - dismissed by any user action.

“I have tried to get Enso to learn that CAPS+C means “close,” not “Calculate.””

I think it might only be implimented for arguments.

I like it appearing in the middle of the screen, but then I hardly ever look at the top left anymore because I’ve become so used to typing “open”.

What about an option to allow you to use the space key to confirm a highlighted command (instead of TAB) then enter in the parameter?

I’m on a laptop most of the time and if I am holding down the CAPS key it is a bit of a pain to have to hit the TAB key to confirm the command.

I agree with Leafy that it would be great to be able to stay in the quasimodal mode if I have not let go of the CAPS key.

Another issue: In the old version of Enso, the difference between a highlighted command vs. an entered command was taken care of

(sorry, I accidentally posted that before it was finished)

To continue: When you entered a command in the old Enso, if you put parameters after the command, it wouldn’t have to go looking for something highlighted, so if i typed caps+”open mozilla firefox” Enso knew not to look for something I had highlighted to open. In this new version, it appears that what happens is this: I type caps+open and the input box appears on my screen. What I do not see is that Enso sends a ctrl+c (copy) to my OS and then pastes into that input box. That way, if I highlighted something, it will appear in the box and, if not, I’ll get an empty box I can type a command into. The problem with this is that the ctrl+c that gets sent to my OS can do things other than copy. So, for example, if my Pidgin buddy list has focus, when I hit caps+open I get, in addition to my Enso input box, a “Join a Chat” dialogue (since ctrl+c opens that dialogue for Pidgin). If this new Enso with the input box is going to function properly, there needs to be a way for Enso to tell whether something is highlighted independently of just attempting to copy and paste. This is also relevant to my earlier comment; if Enso isn’t actuall differentiating between when something is highlighted or not (and is just doing the copy/paste hack) then it will not be possible to remove the need for confirmation (assuming others agree that would be a good thing).

On a couple of Russ Egan’s comments:

On the issue about the calculator (3): At least for me, if I run the calc command without somewhere for it to be pasted, it pops up an onscreen message and a mini-message containing the solution. 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. (Speaking of mini-messages: Are they supposed to remain there forever unless you run the “hide mini messages” command? Because that is extremely irritating.)

On the issue about needing to mash the keys to not match any autocompletes (2): If I correctly understand your complaint, you can get rid of your commands by hitting escape (without releasing the caps key). That way you don’t have to take time trying to mash out something that’s unmatched.

“I’m on a laptop most of the time and if I am holding down the CAPS key it is a bit of a pain to have to hit the TAB key to confirm the command.”

I might be misunderstanding you, but just let go of the Caps Key. You don’t have to complete the command.

“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.”

The problem with that is that it destroys what’s in the clipboard. Maybe a new command called “Paste Result” would do.

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.

@Amorphovs, [ICR]:

“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.”

The “put” command might be helpful.

Andreas,

Good point. I had completely forgotten about that command, and using that is certainly preferable to the destruction of clipboad information.

[ICR],

As to the WM_COPY fix: I am not a coder, so I am doing a bit of shooting in the dark here, but how would Enso know if WM_COPY “fails?” It would seem that either

(a) Enso would have a way of telling whether or not something was highlighted (but not copied), in which case the hack would be unnecessary and Enso could just not try to copy at all unless it sees that something is highlighted or

(b) Enso would check to see if something is on the clipboard after sending the WM_COPY and then send the ctrl+c if the clipboard is empty. But, of course, the clipboard might have something on it from before the command was issued.

Again, since I don’t really know the nitty-gritty here, I could just be missing something. Does WM_COPY send out something to “say” whether or not it succeeded that Enso can read? Or (this would be both a solution and a new problem) does WM_COPY destroy clipboard data regardless of success?

So I have a small request for the Humanized staff, would you kindly remove (or fix) the “Left Control” activation preference. Currently setting Enso to listen for Left Control causes the cut, copy, and paste functions to fail in interesting and confusing ways.

Namely, attempting to use copy fails to copy any text and opens up the calculate tool, attempting to use cut causes Enso to say “x is not a command. Did you mean unmaximize”, and attempting to use paste causes Enso to say “v is not a command”.

You already disallow the selection of left shift so this wouldn’t be particularly odd.

Alternatively, you could attempt to always send the opposing control keysym when one of the control options is selected. But that would only work if Windows applications always treat both controls identically (which is something I am not qualified to comment on).

Thank you for working to make the Windows experience more pleasant, keep up the good work.

[ICR]

“I might be misunderstanding you, but just let go of the Caps Key. You don’t have to complete the command.”

I was referring to the possibility (hope?) that we might have a mode in the future of being able to complete a command along with parameters without using the modal window.

Thank you very much for this wonderful piece of software! I really cannot live without ENSO!
However, I have a request to do. In my work, I have to change constantly from Capslock ON to Capslock OFF and viceversa. When I start typing the order to ENSO, “caps…”, the first choice is always Capslock OFF, so if I have already disabled it, I have to use the arrow keys to select the Capslock ON choice. I think it would be great if you could detect the actual state of the Capslock and show the opposite as the first choice.

Thank you for allowing the feedback from the user! Keep working like this and making us enjoy with great new features for ENSO!

@Antoniosan
Making the capslock change would make Enso more modal. One needs to know the state of the machine in order to know the proper keystroke. Since Enso does not change behavior based on state, you now know that “cap” always means “capslock off” and “cap [up-arrow]” always means “capslock on.” You can habitualize to this without first needing to know the machine state. The statefullness of the capslock key is the main reasons many hate this key.

However, before Enso 2 ships, I would expect the capslock command to be consistent with the open command. If it were to popup the orange box for the argument, you could change states with fewer keystrokes. (caps for the command “o” or “f” for the argument.)

diogo has an interesting idea:
2. 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 Enter to launch the command is traditional, but Enter has the negative attribute of being statefull. Sometimes it means new-line; sometimes it means execute. If Capslock not only started the command, but also ended the command, Enter could be used for multiline arguments. Consider the body-text of an email command.

If you do an “open” command with a large selection you’ll overtype the content of your selection before the Enso argument window gets focus. I know that’s not intended behavior, but it HAS to be fixed.

It also shows why adding complexity to the system is a Bad Idea. If bad design doesn’t get you, entropy will.

> It also shows why adding complexity to the system is a Bad Idea. If bad design doesn’t get you, entropy will.

Very true. And sounds like a Larry Wall quote. :-D

1. I also agree with Leafy -> “I’d like it to be both quasimodal and dialog-based — if I don’t release caps after typing “open” i should be able to continue typing the name.”

I’d like to expand this a bit.
If I press caps, type “open” and press space automatically open dialog so I can continue to type. Or I could type “o” and press tab to autocomplete the command -> open commands dialog so I can continue to type.

After I’m done typeing the argument and release caps > execute my command.
This sounds logical to me.

2. “go” command should recognize open programs in systray. It does not now. E.g. I have thunderbird, skype and winamp and they are always in systray. Since I need them very often it would be great to be able to activate them with “go” command.

3. When in “open” dialog I should be able to expand it to “open with” dialog with e.g. right shift or something and turn it back to “open” pressing right shift again.
This could be used for all commands that have that have sibblings with more/less arguments.
When I think about it, right shift is actually the best solution for this. It just sits there since you cannot write uppercase letters anyway.

4. Sometimes Enso gets confused and turns my caps on after executing command (any command). I have to turn it off manually then (not just prototype but stabile 1.0 v also).

And 5. - prototype is reeeeeally buggy and it keeps crashing every 2nd-3rd time I issue a command. Doesn’t matter what command (open, go, .. ).

The memory footprint is HUGE. while I may use this 5 times/day it can’t justify the waste of 50MB.
~ Mike

“2. “go” command should recognize open programs in systray. It does not now. E.g. I have thunderbird, skype and winamp and they are always in systray. Since I need them very often it would be great to be able to activate them with “go” command.”

The trouble is that the systray is a complete mess. There is no real way of telling what systray icons are associated with a program or how to open them.
Currently I just have to put up with “opening” them again - almost all of my systray icons are one instance programs that will pop out of the systray if the main program is opened again.

First of all: ENSO rocks.

After reading all the comments I find one thing missing. The open file path is a great addition, but file paths often gets very long. A solution could be to allow the use of learn as open commands in a file path.

Example
If I run: ‘C:\Windows\System32′ learn as open ’sys32′.
Then I should be able to use something like: open ’sys32/drivers/’.

It is properly necessary to hit a key for ENSO to recognize ’sys32′ as a shortcut and not a folder, but it would still be faster than typing the whole thing.

A Linux version would be incredible. Yes, another Linux guy harassing you for free software… I will try ENSO out on my Vista box soon. Thank you.

I love Enso period. That said, the new prototype, while the extra functionality is cool, i find it clumsy compared to the old method of type…. It adds another kink to things that gets rid the fluidity present in the older versions. Just my two cents…

Thanks!

First off: Enso blows the competition right out of the water.

Secondly, I must agree with Dylan. I feel the 2.0 prototype to be a step diagonally, not forwards. The input box method is clumsy and doesn’t suit the sleek, easy to use and convenient style of the rest of Enso. That is why I am now back to 1.0

I propose that you keep all the standard functions as they are currently, but, let the user decide which interface s/he wants to use.

Essentially, if the user types “o”, then raise the input box when the hotkey is released, otherwise “open target” should still be a command.

The same applies to calculate (which should be renamed as it now takes more than four functions). If the user merely types “c” (or whatever abbreviation you see fit), the input box should open, otherwise it should function as per usual.

This could in essence be applied to all input box commands. Also, I appreciate “put” tremendously.

For me, half the beauty of Enso is the shear simplicity and beauty of the big, roundish font that appears in the top of the screen, the input box kills this entirely.

Finally, my last bone to pick would be that of memory footprint (as was mentioned by Michael). I am a tuning freak (I disable services such as printspooler because I want my precious 3kb’s or whatever back), thus, it pains me to see that 30 odd mb’s sitting in task manager, sometimes dwarfing Firefox (3 Beta 4).

I will moan about other things as I see fit

Tslil