Are Adaptive Interfaces the Answer?

UI Design Fundamentals

Once upon a time, Microsoft had an idea: Why not have the most-often used menu items rise to the top of the menu, and have seldom-used items hide below a fold. In one fell swoop, Microsoft provided a solution to the problem of a single interface needing to meet the needs of many different users, from many different walks of life.

Great idea, right?

Wrong!

The idea hasn’t worked out so well in practice. Many users turn off adaptive menus in Office because they find the feature extremely frustrating. Even Microsoft’s own designers have admitted that adaptive menus didn’t work out the way they hoped. The feature has been removed quietly from the latest versions of Microsoft Office.

What was the problem? Adaptive interfaces have several drawbacks, and the big one is that they’re intrinsically hard to learn. If you’re trying to learn an adaptive interface, you have to chase after a moving target: “Where did that menu item go? It was here yesterday…”. Even a user experienced with the interface will have a hard time habituating to it, since the locations of commands are not consistent. It’s an interface that moves in the night.

Adaptive interfaces are a strange and awkward dance: a computer program trying to adapt to a human’s behavior, while the human tries to adapt to the computer program’s behavior. Of the two, which one do you think is better equipped for the job? Until we have an artificial intelligence good enough to read the user’s mind, the human is always going to be better at learning. A computer that’s clever–but not clever enough–is simply dumb. Even if it works 75% of the time, its going to really throw you a quarter of the times you try to use it. So rather than trying to make the interface more clever at outguessing humans, we’d prefer to put our effort into making the interface easier for humans to learn.

Having said that, the adaptive interface idea is not without merit. If there is a certain subset of commands that a particular user needs most often, it does make sense to improve the information-theoretic efficiency of the interface by letting the user access that subset with fewer clicks or keystrokes. But what subset the user needs most often is a hard thing to define precisely or compute accurately. And doing it wrong is worse than not doing it at all. For the foreseeable future it’s probably better to let the user choose which commands should be more accessible: with user-defined shortcuts, for instance.

The reason I wanted to bring this topic up is because many of our users have been asking us, “Why don’t you have Enso learn which commands are used most often, and autocomplete to those commands first?” While this is a tempting idea, we’ve decided not to implement it because we think it would create the same problems as Microsoft’s adaptive menus did. For instance, suppose you had been using Enso for a while and learned that typing “OPEN WOR” will take you to the WordPad application, while “OPEN MIC” takes you to Microsoft Word. But suppose that after you had opened Microsoft Word several times in a row, Enso decided that Microsoft Word should take preference in the autocompletions. The next time you do “OPEN WOR” and release caps lock, surprise!! You’re taken to Microsoft Word instead of WordPad. Enso’s behavior has changed without warning. The old habit that you learned has been violated.

So instead of that, we prefer to have Enso’s behavior change only when the user tells it to change. Remember that you can “UNLEARN” any Open command — even Open commands that Enso found in your Start menu. This lets you customize any Open command. So for instance, if you don’t like typing “Open Microsoft Word”, you can do “Unlearn Open Microsoft Word”, and then “Learn As Open Word” or even “Learn As Open W”.

We think this is a better solution, but our ways are not set in stone. We’re willing to consider any new interface idea, if it’s a good one. Do you have an idea for how to capture the benefits of adaptive interfaces without the drawbacks? Then leave a comment below. Let’s get some more good discussion going!

I’d like to comment on that. In my experience adaptive interfaces fall short not because they are intrinsically bad interfaces, but because they move around stuff. Where the user expect something to be spatially arranged in a certain way and the interface suddenly isn’t the same anymore, that is when adaptive interfaces fall short.

Enso is roughly 99% free of spatial arrangements and therefore the “where” argument no longer apply. I believe you could do well letting Enso be adaptive and be able to learn explicitly.

Longer comment here: Adaptive Interfaces

I agree whole-heartedly.

Example: SQLServer comes with loads of programs that I never need. When I type “open sql” the program I want is ALWAYS the last one. At first I thought Enso would “learn” and bump it to first place next time I typed “open sql”. So what did I do the next time? I typed, and I waited. I expected the program to change things behind my back, so I slowed myself down, when in reality Enso did no such thing.

Now I know that the full command is “open sql [up-arrow-key]” and it works everytime :D

As one of the many users who have asked for the adaptive behavior, I guess I’ll join in with my perspective.

I agree that the MS adaptive menus are a failure, and turned mine off long ago. However, I also agree with Niklas, in that the spatial organization of things (especially when you’re using icons) is generally something you don’t want to mess with, and that this doesn’t really apply to Enso, except insofar as Alejandro expects hitting the up-arrow key to get the right command.

True, you don’t want the behavior of the program to change unexpectedly. Such “modal ambushes” do occur in the case of Enso, but only when you install new software. For example, to use a variant of Jono’s example, say you only had WordPad installed and got used to typing “open wor” to launch it, and then you installed MS Word, only to find that “open wor” now launched *that*. Luckily, in this case you can “unlearn” one, and we’re told that soon we’ll be able to create a different alias, which is great.

Meanwhile, as Jono points out, using frequency information could lead to recurring modal ambushes depending on your patterns of use. Is there a simple way to avoid this? How about this: Use the non-frequency data to show the top item in the list (the one that’s in a bigger font size), but use frequency data to sort the rest of them. That is, if you type “open wo”, you get “open woio reference” (whatever the heck that is–it’s what comes up on my computer) at the top (for alphabetical or similar reasons), but then you get the most frequent command that is compatible with what you’ve typed, not the second-in-line alphabetically. All this means is that you know that if you type something and hit down-arrow, you’ll get the most-frequently used command that matches what you’ve typed. But as long as you keep your finger off the down-arrow, the old rules apply. (I mean, how many people would rather hit down-arrow four times to get to something far down the list instead of typing another letter to bring it to the top?)

All this makes me realize that I don’t understand the ordering Enso uses for the lists it displays while you’re typing. What’s the story, guys? It’s not really alphabetical, and we know it’s not by frequency. Is it in the order of traversal of the Start menu or something? If so, I would suggest that that is not buying you anything, and you might want to choose something more, well, humane.

May I suggest that if you have to press the down arrow that you either have too much similaly named software on your machine or you just need to press an extra key.
If word 2007 appears 3th on the list (as it does on my machine) then just type “open word 2″. This has proved faster for me than using arrows as Word is now Word 2 in my brain (within the context of launching) and ” 2″ requires less movement of the hands.
There has been occasions where installing new software means having to learn to extend my commands. I can no longer launch textpad using “open tex” as it would now launch texnicenter. But it didn’t take long to learn to type “open text” instead.

In terms of starting software on your computer I deeply recommend the open source software Launchy. It “learns” through time frequently used programs and speeds up the program starting process. Superb for laptop use…

There?s a lot to be said for stupid UIs. Simple, consistent rules for making commands makes for a learnable, therefore predictable, and therefore controllable app. ?Intelligent? apps vary their responses based on subtle differences in user behavior (e.g., pass command frequency). They are often unpredictable because the user can?t learn all the rules easily. The result is a user that doesn?t so much command the computer as try to persuade it. I don?t believe that?s a problem that can be completely remedied by sufficiently intelligence algorithms. Interfacing with a perfectly intelligent human has a very similar limitation.

But that doesn?t mean all automation is bad. The biggest problem with Word?s Adaptive Menus was that the degree of automation was too high. The automation had full authority. It didn?t suggest to the user a way to re-arrange the menus, it didn?t allow the user to override the re-arrangement, it didn?t even tell the user it had re-arranged things ?the user had to figure it out. Automation for this sort of situation works better if the user has more control, such as executing only after the user gives explicit acceptance. Ideally, the automated action is over-ridden by the user simply doing nothing and proceeding manually. The user needs to control the interaction with the automation as well as the automation itself.

For example, I haven?t used Enso?s UI, but would something like Excel?s auto-complete work? As you type ?Open Wo,? Enso auto-completes with the more frequent/recent command that matches that: ?Open Wordpad,? where the auto-completed letters are distinguished from the manually typed ones (Excel uses highlighting). Terminate the command there (release Caps Lock?) and the auto-completed executes. However (a big ?however?), you can also just keep typing (?Open Woodchipper?) and override the auto-completion.

That is indeed how Enso works. However, that still has the same problems. For an example, see the third to last paragraph. It’s less of a problem because it’s not adaptive, but it does become a problem when new software is installed. But I don’t think that’s really avoidable.

I think an adaptive UI will become very annoying when you have two apps that you use equally often. Sometimes app AA will be first and then app AB.

In all other cases it’s probably better to have adaptive auto-completion.

As has been said, the best solution is to define your own shortcuts for often-used applications.

An alternative that might be worth testing is to have automatically generated shortcuts depending on what the user typed. For example, if I run MS Word with “open Wo”+ then “open Wo” will from now on become the alias for MS Word. It’s probably not intuitive enough. This needs some testing. Well, maybe this could be used as a starting point for a new concept…

Hmm, in my last comment a word got deleted although your live preview didn’t indicate this. I repeat:

An alternative that might be worth testing is to have automatically generated shortcuts depending on what the user typed. For example, if I run MS Word with “open Wo”+arrow-keys then “open Wo” will from now on become the alias for MS Word. It’s probably not intuitive enough. This needs some testing. Well, maybe this could be used as a starting point for a new concept…

The interface of the future.

The interface of the future is a fully user customizable personal interface for personal use.

We have the personal computer.

Why not a personal interface.

The personal interface is a master interface that sits on top of all applications.

The personal interface can use gui, cli, and search all in one interface. google: inputexpert

This was not possible before because of the use of the stand-alone mouse and keyboard.

The interface of the future is possible because an advanced keyboard, the keyboard of the future, has been developed to give the user total control of the computer screen from the home row without moving one?s hand to a mouse to point.

The user can point, click, type, and scroll in any order simultaneously and instantly all from the home row.

Hot keying, finger gymnastics, short cut keying still can be used.

The keyboard of the future and interface of the future enhance and empower the users capabilities.

from the ?father of the perfect keyboard.?

Umm, I have nothing to say about “the interface of the future”. Somebody mod this guy down.

However, I do have a small point to make about customizable user interfaces. Which is this: their praises are often sung by hard-core users, the kind of users who do similar work, on a single machine, for years on end. Their work is focused, and even somewhat repetitive. What they love, above all things, are shortcuts.

But be aware that catering to one user clique may hurt you in a wider marketplace. A *lot* of people in the world use more than one computer in a day. Others have to take account of the fact that others will use their computer sometimes. And a third, very large, group of people don’t view computers as something to be customized, so they never go an inch down that road regardless of the rewards.

Customization — feathering one’s nest — only pleases the base. Does Enso allow you to create your own commands? I’d argue that in the end it’s completely unimportant. Let them eat emacs.

Conforming to the user, however — that is golden.

MSFT just did it wrong, as usual.

I don’t think that microsoft fking up on adaptive interfaces means that the entire technology should be written off. There’s already arguments here for and against adaptive interfaces that make a more compelling case.

Jonas S: Launchy is great and it takes up only 10mb of RAM compared to ENSO’s hefty 30mb. On the other hand, I really like ENSO’s use of the capslock key and the GO functionality. Launchy has a GO-y plugin but I can’t get it to work (time may be on our side there, the Launchy dev seems fairly active).

But back to ENSO: there’s a “learn as open” but no “learn as go”! Often my window names wind up being awkward and I’d like to create an alias for hopping to the right window. That would be a selling point for me. And worth mentioning since this blog update was about giving the power to change ENSO rather than have it adapt to people, heh.

Also, can anyone tell me if ENSO will switch between jEdit buffers as easily as it does firefox tabs? My trial for ENSO has run out even though I used it for only a few days over a month ago. Alas.

And one last funny from the ENSO faq, classic say one thing then say exactly the opposite thing at the end of the paragraph: When you purchase a license for an Enso product you get free access to all future updates, new features, and bug fixes … We must note that we do reserve the right that?if we make a mind-bogglingly huge update (say to Enso 2.0)?we might charge something.

I think this is the way to go….

All the fors and cons in these comments are indicative of the need for a personal choice in this regards.

Begin incorporating “adaptive” algorithms/methodology into ENSO based on best practices and ideas - some of which may be listed here. Make it optional - “adaptive on” “adaptive off” but defaulting to “off” on first startup until , if ever, it should prove itself otherwise. Now ENSO can have the best/worst of both worlds. Power user and non-power user will now be more satisfied and, importantly, it will allow ENSO to innovate and imporove based on user feedback in both of these equally important areas into the future.

Completely agree with Jink. Personal choice, in my opinion, is the way to go!

I switched off my ‘Personalized menu’ option in Windows very shortly after it (annoyingly) started sorting my menus. However, I know enough people who claim they cannot live without it.

‘Enso is Dead Simple to Use’ and it shouldn’t be simple for just the basic users or the advanced users. Imho, the only way to achieve this is by allowing for customization and personal choice.

I found the adaptive menus in Office irritating but the adaptive system in QuickSilver is a large part of what makes it work so well for me. I’d definitley expect Enso to have the same capability, though you could make it optional.

I’m a technical writer. I once worked on an application that let users move features from menu to menu, and even to have them appear on multiple menus. That was interesting. But users kept complaining b/c they couldn’t remember where they had put things. My (crazy) boss kept getting on my case b/c I insisted on documenting the as-shiped state and the ability to change the menus. He thought I should figure out a way to document the as-altered state.

When you consider adaptive interface design, you should take into account whether the design is intuitive enough to eliminate the need for any documentation, which can be complicated in adaptive interfaces. Consider: you (the user) have moved Feature X to another menu than the one it shipped on. What do you search the help on? “Feature X”, but all the help can say is that “Feature X shipped on the Y Menu, but maybe you moved it. Good Luck, (you idiot).”

That was 10 years ago. Maybe by now the help would be smart enough to tell you where you moved it.

The user needs to control the interaction with the automation as well as the automation itself.

The humane solution, which is also what Quicsilver does, is to have auto-completion adapt for individual shortcuts, and not in general.

I don’t know what Enso does, but in Quicksilver, if you’ve been using “OPEN WOR” for a while for WordPad, and “OPEN WORD” for Word (which you use more), it will always remain that way…

I wasn’t clear (and maybe Enso already does this), but what I mean is that:
- Shortcuts the user has *used* take first precedence (so you don’t have any surprises from the interface adapting)
- For shortcuts the user has never used yet, the interface adapts so that more used programs come first. (So it is possible that after a while the user notices that a shorter shortcut (like “W”) will work and “adapt” to it, but the old ones still work.)

Applying the same idea to menus would give us that menus that have been ever clicked on stay in their place, but the other “slots” can change. This is a bit hairy, (because the user often “sees” the menus even when not using them), but the idea works well for auto-completion.

hmmmm…very interesting!
Thanks google

Me love Intellisense in Visual Studio =) Would be nice with something smart like that in enso. not sure if it is possible though.. kind of different worlds… but still =)

Why not both? Make two different commands. Use “open” for the normal alphabetical list and use “opened” for an adaptive one. Simple.

side effects of imitrex

XRumer 4.085 Platinum - is MOST powerful software for MASS posting into forums, blogs, guestbooks, boards, etc.