Ubiquity: Failed Mouse-Based Interface #1

Advertisement:

POWERED by FUSION

We often only display to the world a final, finished product design. That’s sort of like releasing only the last 10 minutes of a movie: it doesn’t show all of the mis-starts and dead-ends that to make the final ending meaningful. I’d like to explain one of the first sketches we did of the Ubiquity mouse-based interface, and why we didn’t stick with it.

Usage:

Step one: Make a selection. The Ubiquity action button appears.
Step two: Clicking the action button opens a context menu with suggested actions.
Step three: Hovering over an action shows its preview.
Step four: Clicking executes the action.
Step five: If the action you want isn’t available, click for more actions.

Critique:

Step one: I like this part. One of the largest problems with the current workflow of Ubiquity is that it requires you to remember to change it. That requires you to break your existing habits — I still sometimes catch myself doing a keyword search instead of using Ubiquity, despite the later being faster. By having a visual affordance that appears at the exact moment you need it (when you make a selection), the speed and convenience of Ubiquity is injected smoothly into your existing workflow. No need to stop and think.

The idea isn’t new. The trick, though, is making it not annoying. The New York Times has a good implementation.

Step two: Clicking is okay, but that’s mostly where the okay stops. The mockup shows a spruced up linear context menu. Instead of doing just a big list, there’s some preliminary information architecture — they are split between the Ubiquity-recommended actions as well as your most common actions. The reason we didn’t want to combine them were two fold: (1) The items in the menu would shift so often that habituation would be nigh impossible, and (2) detection of what kind of thing you’ve selected isn’t a perfect indicator of the action you want to take.

The big problem with a linear context menu is that it just isn’t very scalable. After you’ve got more than roughly 15 items in there, it’s just a big jumble. Especially if it’s listed in anything other than alphabetical. You can add submenus based on logical groupings, but given the number of Ubiquity commands available it quickly becomes an arduous trail of dexterity and memory.

Step three: Hovering is a nice, light interaction. But, if we are near the corner of the screen, where does the preview get put?

Step four: Just fine.

Step five: The mark of a bad design is needing to switch or invent mechanisms to accommodate common edge-cases. There’s no “obvious” thing to do with the “more actions” option — we’d have to invent an entirely new interface to cope. Not good.

Next

It’s clear that this isn’t the right interface for a mouse-based Ubiquity. We’ve got another couple on the drawing board, but we’d love to hear ideas and see sketches of other ideas!