Personal tools

Labs/Ubiquity/0.2 Roadmap Proposals

From MozillaWiki

Jump to: navigation, search

Contents

The Road to Ubiquity 0.2

Ubiquity 0.2 can feature innovation in any number of areas, but we need to narrow our focus. The following sections identify potential areas that we can innovate or improve upon, with motivations for their inclusion.

Note also that the final road map doesn't dictate what won't happen: it only dictates what we're focusing on. If, for instance, we decide that we're focusing on UI innovation and you really want to work on the Herd, you're welcome to do that and we will certainly review patches for it.

Linguistics

Motivation: allowing a broader audience to use Ubiquity's current interface with ease.
  • Improving the natural language parsing capabilities of Ubiquity so that it understands a wider range of inputs.
  • Fully internationalizing and localizing the parser.
  • Creating a set of command-naming guidelines, and implementing them consistently in first-party commands, to encourage consistency across all commands, which will make the system as a whole easier to learn and use.
  • Standing on the shoulders of giants, third-party frameworks? Evaluation of these tools?

User Interface

Motivation: innovating the user experience to allow non-technical users to do things in humane ways that they hadn't considered before.
  • Taking the Ubiquity context menu from tech-demo quality to production quality. For the majority users who didn't grow up on command lines, the context menu is likely to be the more widely used interface, but development on it has lagged far behind. The context menu needs:
  • Fewer and better suggestions, based on analysis of the possible meanings of the selection.
  • Ranking of suggestions in a way that makes the user's most often-used commands easy to find (without causing confusion by frequently re-ordering the list).
  • A way to understand what the result of choosing a command will be -- something like the preview feature of the command-line UI.
  • Making Ubiquity's UI "pluggable", so that different Firefox extensions or command scripts can easily access its functionality; this can help allow developers and/or designers to innovate the UI in new directions, e.g. by:
  • adding pie menus,
  • integrating with the Awesomebar,
  • providing access for blind users,
  • building a unique interface for a website.
  • Making Ubiquity's UI not only pluggable but streamable too, allowing new usability features to be streamed in rather than manually updated.
  • Note that adding streaming built-in command feed functionality in 0.1.2 took quite a bit longer than we thought; there's a decent chance that this could be nontrivial to implement too.
  • Statistical data gathering
  • Combined with the streaming UI this allows us to quickly and cheaply test changes on large samples of users as pioneered most powerfully by Netflix but embraced by every major web company.
  • Understand feature usage, errors, and stickiness
  • Triage context menu versus command line priority

Community

Motivation: exploring social mechanisms of trust, communication and collaboration that may augment their technical counterparts.
  • Making it available on addons.mozilla.org (as experimental to begin with)
  • Adding a social trust network to the Herd.
  • Adding comments with user voting to command feeds.
  • Adding collaborative code review/annotation capabilities to command feeds.
  • Adding wiki-like functionality to the herd and/or ubiquity.mozilla.com.
  • Creating a "featured command feeds" page/site similar to addons.mozilla.org.
  • Creating a planet-like aggregator for Ubiquity-related content on the web.
  • Adding a well-documented public API to the Herd, allowing anyone to create applications and other web content that draws from its information.

Thunderbird

Motivation: exploring Ubiquity's philosophy in an entirely different, and perhaps even more useful context than the web.
  • Provides a vehicle for exploration of new e-mail management functionality, to experiment with new ways to battle the email deluge, to make email management more humane, and to extend Thunderbird in ways that provide compelling advantages over webmail.
  • Demonstrates that Mozilla Labs projects can be for Thunderbird, not just Firefox
  • Also opens up the prospect of cross-application functionality (i.e. ubiquity in Mozilla and ubiquity in Thunderbird talk to each other, command feed subscriptions can be shared, and each command can execute in whichever application handles it best.)

Desktop Integration

Motivation: "breaking the walls" and bringing the web outside of the browser allows for truly seamless, ubiquitous access to the web's functionality.
  • Allowing Ubiquity to be used by third-party desktop-wide graphical CLIs such as Quicksilver and Enso via inter-process mechanisms like JSBridge.

Firefox 3.2 Integration

Motivation: getting Ubiquity functionality into FF 3.2 will allow the rest of the world to experience some subset of Ubiquity-like functionality now.
  • The context menu and the Awesomebar integration seem like the two most likely UI for putting Ubiquity commands into Firefox 3.2.
  • Due to the security dangers of giving chrome privileges to arbitrary javascript, the functionality that gets into Firefox 3.2 should not include subscription to third-party commands.

Inter-process Sandboxed Security

Motivation: Exploring the execution of end-user code in a separate process using a technology like the recently open-sourced GreenBorder can help protect end-user machines and also serve as a useful "guinea pig" for applying a similar kind of mechanism to Firefox.
  • GreenBorder's source code appears to be here. Understandably, it seems to be tightly coupled to the Windows operating system.
  • Using a separate process means we'd probably have to implement some kind of robust, cross-platform IPC mechanism; there may already exist code in Chromium to help us do this. Dan Mosedale also knows of some work that was done a few years ago to help Thunderbird and Firefox exchange information better; the code never ended up being used, but it's still in the trunk.

Stabilization of Current Feature Set

Motivation: ... without some core stability I think the user base will lose interest and we'll be left with an interesting toy for a handful of people, but no wide-spread adoption. —Gary Hodgson
  • Improving performance
  • Restoring functionality lost in 0.1.2 (Context menu, noun-first suggestion, suggestions for missing arguments)
  • Exploring and implementing technical security mechanisms such as sandboxing
  • Making debugging easier
  • Getting Ubiquity to the point that it's secure and stable enough to be featured on AMO

Group Documentation

  • Adoption (goals)