Adaptive UI vs. recognizable UI

Question

I'm reading a thesis which discusses Task-focused user interfaces. They discuss an application which adapts/filters views based on relevant items determined by an interaction history. They prove their interface (Eclipse Mylyn) results in higher productivity for programmers.

Although I don't doubt these results are correct I wonder whether such an adaptive user interface doesn't have any downsides as well. Personally, I rely a lot on knowing what to expect where in the interfaces I use. I wonder whether an interface which changes over time (hides/moves certain items) doesn't sometimes result in a downgraded user experience.

More particularly, I'm looking for studies which evaluate possible downsides to adaptive user interfaces.

Answer 1

Regarding Microsoft abandoning adaptive menus when creating Office 2007, have a look at this video with principal group program manager on the Microsoft Office UX team Jensen Harris:

• The Story of the Ribbon (at around 07:45)

Answer 2

Somewhere near the end of the thesis they reference a paper from 2004 which discusses this very subject. A comparison of static, adaptive, and adaptable menus.

abstract

Software applications continue to grow in terms of the number of features they offer, making personalization increasingly important. Research has shown that most users prefer the control afforded by an adaptable approach to personalization rather than a system-controlled adaptive approach. No study, however, has compared the efficiency of the two approaches. In a controlled lab study with 27 subjects we compared the measured and perceived efficiency of three menu conditions: static, adaptable and adaptive. Each was implemented as a split menu, in which the top four items remained static, were adaptable by the subject, or adapted according to the subject's frequently and recently used items. The static menu was found to be significantly faster than the adaptive menu, and the adaptable menu was found to be significantly faster than the adaptive menu under certain conditions. The majority of users preferred the adaptable menu overall. Implications for interface design are discussed.

---

Although the adaptable menu was preferred by the majority of subjects (55%), the adaptive menu did have support (30%). By contrast, only 15% of subjects wanted the static menu, even though it was the optimal split menu (based on measurements beforehand).

They suggest further research into combining both methods in a mixed-initiative design. E.g. have the system periodically suggest additions/deletions.

Answer 3

Disable (grey out) stuff that's not applicable, don't hide it...

Unless it is a security/user permission level (e.g., sysadmin vs programmer, manager vs. employee - same person sees same thing always).

This is assuming what you mean by 'over time' is that previous context causes the items to be applicable or not.

We ran across the exact issue and if entire 'screens' of content are only applicable at certain times (we use 'pages' in a 'wizard' style format), it's OK to add/remove them. But the image of the screen matches what the user remembers if stuff that's n/a is disabled. Otherwise there's subconscious confusion.

Don't auto-hide or show stuff based on program's decision.

You notice that in the office ribbon, as it's sized, stuff compresses rather than hides, and still works. Great tradeoff between space usage, looks, and usability. Rembmer the 'adaptive' menus of office XP and earlier that auto-showed/hid stuff? MAJOR SUCK.

Regarding Facebook. Facebook does some un-usable stuff. Why do they do it? Because they good for 100% look because it is all about user opinion. Why? Users don't know what they want. User polls/preferences DO return results that may favor less efficient (harder to use) approaches. When you can't find what you want to do in face book, you, and everybody else, blames themselves. Wrong. Facebook knows you're doing that. Usability is a red-headed stepchild to good looks.

bottom line

If you want good-looking apps that people will need to buy into to put supper on your table, go for looks first, usability second (people still have to be able to operate it). In otherwords, hide it if it looks good.

If you are writing for a company that is require uses to pick your line-of business apps and efficiency=$, go usability first. In other words, enable/disable, but almost never dynamically hide items on the screen.

Answer 4

From a simplicity design perspective, makes sense that the user behavior will simplify the interface and makes his life easier down the road (because all the options has been funneled down to only the useful ones). Recommended book: Simple and Usable by Gilles Colborne.

But, I agree on your concern, what if the adaption of the interface end up on a confusion for the user? I wonder if Facebook has run studies on the impact of their "never finished system" approach, where the users has to face important changes on the GUI at least once a year.

Answer 5

I'm surprised at these results - I would imagine that, as a user, I'd be confused when objects or functions disappeared from view. If the 'adaptation' isn't well signposted, I could confuse a 'rearrangement' for a change in state, user permissions or something else that 'locks me in' to a certain sort of behaviour. As a user, I would immediately assume I'd changed my app's "mode" in some way, and rather than seeking the hidden control, I'd look for the controls that effected this 'mode'.

As such, I would suggest that you only provide an adaptive UI with certain precautions, and with three specific caveats:

One: Ringfence the 'adaptive' part of your UI into its own widget or visually distinct control. Combine it with other 'context-sensitive' functions, so the user still trusts the rest of the application

As a user, I don't generally expect menus and the like to change. If things started moving around, I might stop trusting the rest of the application to remain static. If, however, the 'adaptation' was limited to its own visually distinct area (like a floating 'context' window), and its nature was well communicated (with a title like 'You might want to...', for example), I could reap the benefits of an adaptive UI without losing trust in the rest of the application.

Another advantage of this approach is that you can include other 'context-relevant' content beyond just controls and data. Imagine my 'You might want to...' window suggesting context-sensitive help articles, or articles on interesting effects and tips. Imagine it even crawling the web for relevant content! By distinguishing your 'experimental and amorphous' component from the 'rest' of the application, you can exploit 'context-sensitive' without losing your users trust, or creating an application that looks half-finished or unreliable.

Two: Make sure your 'relevance' algorithms are up to the job

If you're going to change a UI mid-use, you must make sure it actually does make the program more relevant and useful. If I repeatedly add headings then bullets, I don't want my bullet controls to disappear on the third heading, just because your app thinks "three headings = lots of document structuring = unlikely to add new bullet content". You should rely on empirical data and be able to spot quite complex patterns, else you risk letting your users down. Every time your adaptation frustrates your user, you lose far, far more goodwill than when it improves UI relevance.

Three: Let users turn it off!

Worst comes to the worst, at least let users switch adaptation off. Let them reset their usage history and go into 'non recorded' mode (so a friend taking over, or an unusual task don't 'mess up' the context-arranged controls). This way, even if your risky 'adaptive' UI doesn't pay off for certain groups, your risk is mitigated.