Ubiquity In the Firefox: Round 2
We’ve been iterating hard on ideas to bring the power of Ubiquity to Firefox main. The two places it makes sense to surface Ubiquity-like power are (a) in situ with content when we are trying to manipulate, and (b) in the location bar, where we already type to perform navigation tasks. This post focuses on the second use case.
The three design goals, in shorten form, from round 1 were:
(1) Don’t force new work flows.
(2) It must be localizable.
(3) It should feel like Firefox.
We’ve added a new design goal, as a subset of not forcing new work flows: discoverability. The interfaces we design should be self-learnable. In this case, that doesn’t mean ever piece of functionality is immediately obvious, but that over time the system can teach you — step by step — how to use more and more of itself.
Note that all of these mockups are sketches. They don’t imply anything about the final visual style. From an interaction standpoint, they focus on tight feedback loops, as well as putting contextual autocomplete as close to the text being entered as possible.
Mockup 1
The Ubiquity-esque actions appear in the Awesome Bar results, and are subject to the same ranking algorithms as everything else.
The inset image on the right is an alternative way of accessing verbs: instead of having them appear in the awesome bar results, they appear as autocorrect-style text above what you’ve typed. The benefit is that you can always hit tab to quickly get to the action you want (as opposed to using the arrow keys for navigating the awesome bar results). It can also be unified with methods of structured modifiers (see later mockups). The detriment is that it is yet another mechanism and is visually noisy.
Other thoughts: The background of the url bar can change colors to add a visual key that an action is taking place. We can also unify the keyword mechanism, so that if you type “g ” it automatically gets expanded to a “Google” action.
Mockup 2
This is a take on how we can handle modifiers. In this case, we treat them like forms with defaults.
Pros: Modifiers are discoverable and obvious. We can also construct more proscriptively natural language-y sentences.
Cons: There’s more interaction required to use these systems; you can’t just type. You are also more closely bound to a particular modifier order. That is, it’s harder to do “translate from Japanese to English” and “translate to English from Japanese”.
Mockup 3
This design focuses how modifiers could be made visible. You can (1) type one of the options, in which case an autocorrect-style suggestion helps you to get to the correct modifier, or (2) select the appropriate modifier with the keyboard or mouse.
Mockup 4: Putting it all together
Mockup 5
Actions don’t need to take place inside of the awesome bar. After the action has been selected, the rest of entry can happen anywhere. This mockup is just one place for that entry to take place.
Pro: The same interface can be used for Ubiquity proper and actions in the awesome bar. And visually, it is less cramped.
Con: It doesn’t feel as “Firefoxy”.
Conclusion
We’re looking for harsh constructive criticism and more mockups. Bring ‘em!
About this entry
You’re currently reading “Ubiquity In the Firefox: Round 2,” an entry on Aza’s Thoughts
- Published:
- 2.19.09 / 2pm
- Category:
- Commentary, Fun, Life Hack, WEBLOG
22 Comments
Jump to comment form | comments rss [?]