Ubiquity: Failed Mouse-Based Interface #1
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!
RT @azaaza Ubiquity: Failed Mouse-Based Interface #1 | Follow @azaaza on Twitter | All blog posts
JustinOpinion
You may already have considered this, but something like the firefox add-on “Radial Context” might work. The radial context system allows for many sub-categories and sub-sub-categories, so you could in principle put lots of Ubiquity commands in there.
Although this makes for a large parameter space for the user to navigate, the radial nesting of the menus means that for a particular action the user quickly learns, via motor memory, the correct sequence of mouse motions. It essentially becomes like mouse gestures (you can quickly activate a feature by drawing out a particular shape), but is discoverable because the radial menu shows the categories/options at each step (if you are navigating slowly…).
I would think that having the user drag the Ubiquity arrow through a series of radial menus might work. Downsides are that perhaps not all users are sufficiently dexterous for mouse gestures to feel natural, it’s sufficiently different that it might confuse some users, and it may interfere with mouse-gesture add-ons people already use.
Amr
This’s a bad idea, not because it’s a bad idea but because it’s already included in many Firefox extensions that basically hijack the interface when displaying the little box near the selected word.
here’s a good example (it’s really useful extension if you like this style)
https://addons.mozilla.org/en-US/firefox/addon/1941
However, having a mouse-based interface for Ubiquity is not a bad idea as some users are not so used to a common-line based interface especially average users and beginners.
Jethro Larson
I dislike the bubbles on selected text. IE8 is doing it for the web actions and I find it distracting. I tend to highlight text as I read as a means of keeping place so having things happen when I do just breaks focus.
A possible idea is to replace the context menu entirely. They’re all actions. I understand this may be a bit annoying for some people but I think that can be mitigated by pinning the common actions at the top of the list, and allowing people to drag/sort the items.
I’ve been wanting all the firefox actions to be made part of ubiquity since first trying it. Like opening dialogs(history,options,addons), bookmarking pages,print, etc.
So this may be a good way to work on both.
Greg
Hmmmm. I had to go back and re-read the vision of Ubiquity. The problem we are solving is disjointed information. We aren’t trying to ‘launch’ a command. We’re trying to connect two sites together. Right?
Wouldn’t a mouse driven UI could be much closer to Automator, or Yahoo pipes or even Lego bricks?
Simple scenarios like maps and Twitter are fine with menus but longer term vision is to move complex data (not just text selections) between sites that don’t know about each other.
Some more complex scenarios to consider:
Flickr Photo Set -> Ebay Posting -> Twitter when done
Craigslist search -> Google Map Results -> Send as Email
For each stock in my Etrade account -> Search CNN
These types of things won’t be possible with a traditional menu based approach.
Mohammad Addas
Not all people have the same needs and I think having a mouse-based interface for Ubiquity IN ADDITION to the current interface is a a great idea.
The main difference between FireFox and all other browsers is giving users the freedom of choice for how to do things and Ubiquity should be no different. As an example, I need fast access to the following actions when highlighting text:
Copy (with formatting, as text)
Search (in background tab, foreground tab)
Open as link (in background tab, foreground tab)
Translate
And since highlighting normally performed “using the mouse”, then I don’t want to switch to the keyboard to initiate any of those commands tens of times daily.
All current extensions that provide similar mouse-interface to the one you suggested lack the ability of either choosing what to appear in the list or the ability to create personal commands.
Ubiquity can do this much better by giving the user deep customization and the ability to disable the interface he/she doesn’t like. Some people might even add a command at the end of the pop-up list that opens the command-line interface and disable accessing it through the keyboard in use the key combination for something else.
Also, it would be more productive if the user is allowed to set some rules that are automatically performed. For example, if the selection is a regular text autocopy, if it looks like a link in a text format then open in new background tab, if it is a single word then translate into Xyz language, and if it is non-English text then translate to English.
In addition, some people don’t like having an icon appearing when selecting text. This can be dealt with through a gesture that tells Ubiquity when to engage (Double click on any empty space -> Ubiquity Activated -> make the selection -> Ubiquity shows the commands list).
Hope to see this happening in the near future.
roberto
I think this is a nice interaction don’t know if you can make it using this aproach:
http://g-majeur.nl/thesis/screencast.wmv
Regards,
Roberto
David King
Loving the concept, but agree with your crit already outlined so hey!
How about a menu similar to the one on DeviantArt? It’s “deep”, functional and pretty easy to use.
Rogier Schoenmaker
I like the first step, it is more visual for your users.
How about launching the screen you see when pressing ctrl+space if you click on the icon next to your selection?
Aza Raskin
@Rogier: Take a look at http://www.azarask.in/blog/post/can-ubiquity-be-used-only-with-the-mouse/
Carl
Here’s my 2c:
Get people used to the ubiquity interface regardless whether they begin the process with a mouse or keyboard. This maintains consistency and you only have one interface to receive feedback and work on.
So for mouse navigation, this is how I’d see it working : when you select text, the selected text flies (think maximizing window like effect) and becomes part of the normal ubiquity interface (just like you had made the selection and pressed the activation keys).
The difference is that now, a user only has to move the cursor over the action (say “email”) and rotate the scroll wheel for it to change to other alternatives. Maybe have an animation here too…like an old petrol pump…or something that makes it obvious that it is the motion of the scroll wheel that’s causing the change.
In addition, since it is mouse only, words like “to” will have to appear automatically (for example, in “email to”.
Finally, using the same example of emailing text to a contact, the user will be able to use the scroll wheel to move over the alternatives. If there are a lot of alternatives, like in email contacts, group them (there are several possibilities, but one obvious one would be by first inital…an index tab of sorts above the current contact.
This lets everyone get used to and improve on one interface, which is a good thing from the start. This will also be good from a touch screen point of view – using ubiquity on a smartphone or internet tablet, for example.
From my experience, people who use a mouse a lot, like to know what effect their clicks and scrolls are having. This is why it is important to show them whats going on.
Zayıflama Lida Fx15 Ve Biber Hapı Zlfvbh
You may already have considered this, but something like the firefox add-on “Radial Context” might work. The radial context system allows for many sub-categories and sub-sub-categories, so you could in principle put lots of Ubiquity commands in there.