52
edits
Labs/Ubiquity/Roadmap: Difference between revisions
no edit summary
No edit summary |
|||
| (18 intermediate revisions by 2 users not shown) | |||
| Line 25: | Line 25: | ||
= Planned Upcoming Releases = | = Planned Upcoming Releases = | ||
== Ubiquity 0.5 == | == Ubiquity 0.5: The New Parser == | ||
The big news here is the new parser, which supports internationalization. We took everything we learned from writing the original parser and used it to create a much more robust and expandable basis for future development of multiple-language pseudo-natural-language input. | The big news here is the new parser, which supports internationalization. We took everything we learned from writing the original parser and used it to create a much more robust and expandable basis for future development of multiple-language pseudo-natural-language input. | ||
| Line 31: | Line 31: | ||
Second biggest news is the new interactive tutorial. User testing showed we had a desperate need for a better first-run experience, so we created a walkthrough that takes new users by the hand and teaches them the basic concepts along with a handful of the most useful commands. | Second biggest news is the new interactive tutorial. User testing showed we had a desperate need for a better first-run experience, so we created a walkthrough that takes new users by the hand and teaches them the basic concepts along with a handful of the most useful commands. | ||
Release date: June 22 (or 23rd if we're following the tuesday-publicity theory), timed to coincide with release of Firefox 3.5. | Release date: June 22 (or 23rd if we're following the tuesday-publicity theory), timed to coincide with release of Firefox 3.5. (Update: We released 0.5pre, a still-buggy preview edition, on June 22. We will release 0.5 for real, with no new features but lots of bug fixes, on June 30.) | ||
Must support both Firefox 3.0 and 3.5. | Must support both Firefox 3.0 and 3.5. | ||
| Line 51: | Line 51: | ||
* Human interface guidelines for command developers, to encourage consistency of interface between commands. | * Human interface guidelines for command developers, to encourage consistency of interface between commands. | ||
* Outreach to localization community, to solicit the help of localizers to get Ubiquity working in more languages. | * Outreach to localization community, to solicit the help of localizers to get Ubiquity working in more languages. | ||
== Server-Side Improvements == | |||
There are three server side components to Ubiquity: | |||
# The command search engine ("The Herd") | |||
# The bug-reporting system | |||
# The developer support infrastructure, e.g. Hg and Trac, that run on ubiquity.mozilla.com. | |||
All three of these have been experiencing major availability and/or performance problems. The lack of usable uptime is really starting to hold us back. As soon as 0.5 is released, we need to focus on making all three of these server-side components stable and reliable enough to support our plans for growth of the user and developer communities. | |||
== Ubiquity 0.5.1 == | == Ubiquity 0.5.1 == | ||
Less than 2 weeks after the release of 0.5 | |||
Fixing high priority bugs found by the release of Ubiquity 0.5. | |||
== Ubiquity 0.5.2 == | |||
Beginning of Q3, 2009 | |||
A few features that didn't make it into 0.5, along with fixes for whatever the biggest bugs are that we discover after 0.5. Notable features (which are almost done, but didn't get in to 0.5 before feature freeze) are: | A few features that didn't make it into 0.5, along with fixes for whatever the biggest bugs are that we discover after 0.5. Notable features (which are almost done, but didn't get in to 0.5 before feature freeze) are: | ||
| Line 59: | Line 77: | ||
* Suggestion memory in parser 2 | * Suggestion memory in parser 2 | ||
== Ubiquity 0.6 == | == Ubiquity 0.6: Push for more End-User Benefits == | ||
After the deep infrastructure work of 0.5, we need to focus on turning the new power of the platform into tangible benefits for the end-user. That means improving the implementation of the standard feed commands for better stability and functionality, plus expanding the range of commands available, and attempting to expand the size of our user base. | Mid Q3, 2009 | ||
After the deep infrastructure work of 0.5, we need to focus on turning the new power of the platform into tangible benefits for the end-user. That means improving the implementation of the standard feed commands (and, equally importantly, their nountypes) for better stability and functionality, plus expanding the range of commands available, and attempting to expand the size of our user base. | |||
Around this time, the Test Pilot project will have produced a usable set of policy guidelines for collecting data without compromising user privacy. These guidelines will be implemented in 0.6 so that we can start collecting usage data that we can use to scientifically improve the usability of Ubiquity from here on. | Around this time, the Test Pilot project will have produced a usable set of policy guidelines for collecting data without compromising user privacy. These guidelines will be implemented in 0.6 so that we can start collecting usage data that we can use to scientifically improve the usability of Ubiquity from here on. | ||
| Line 68: | Line 88: | ||
* Improvements to standard feed commands and their documentation; more new commands. | * Improvements to standard feed commands and their documentation; more new commands. | ||
* New and better default skin; Better graphics for user interface. | * New and better default skin; Better graphics for user interface. | ||
* | * User-defined command synonyms/aliases. | ||
* | * Make nountypes localizable. | ||
* Suggestion memory improved to cover noun suggestions | |||
* Experiment with doing noun recognition in the cloud | |||
=== Community Building after 0.6 === | === Community Building after 0.6 === | ||
| Line 77: | Line 99: | ||
Increasing our user base will increase our command developer base as well as our command subscriber base, and allow us to make more realistic explorations of the scaling effects that start to affect security and trust when the network grows past critical mass. For instance, I am not aware of anyone having yet attempted to write a malicious Ubiquity command. I'm sure this is mostly because the user base is too small to be worth targeting. As the user base grows, it becomes inevitable that someone will attempt to attack our users using a malicious command. Thus, growing the community is an opportunity to test out the web-of-trust security model. | Increasing our user base will increase our command developer base as well as our command subscriber base, and allow us to make more realistic explorations of the scaling effects that start to affect security and trust when the network grows past critical mass. For instance, I am not aware of anyone having yet attempted to write a malicious Ubiquity command. I'm sure this is mostly because the user base is too small to be worth targeting. As the user base grows, it becomes inevitable that someone will attempt to attack our users using a malicious command. Thus, growing the community is an opportunity to test out the web-of-trust security model. | ||
We should take a hint from the "Extend Firefox" contests and run a contest to write the best Ubiquity command -- the most useful, most innovative, and best implemented commands that conform to our human interface guidelines will be rewarded with publicity, | We should take a hint from the "Extend Firefox" contests and run a contest to write the best Ubiquity command -- the most useful, most innovative, and best implemented commands that conform to our security and human interface guidelines will be rewarded with publicity and swag. | ||
Separately from any contests, we should also have a spot on the Herd / command-search front page for "Featured Commands". This can be a short, rotating list of commands that we have reviewed for security and usability and found highly useful and worthy of recommendation. | |||
The Herd ought to offer a feature where users can give thumbs-up or thumbs-down to commands, and then view commands ranked by number of thumbs. | |||
Good, popular third-party commands can also be considered for inclusion into future versions of the standard feeds. (But inclusion in standard feeds will never be offered as a prize for any contest; that goes against Mozilla's policies.) | |||
== Ubiquity 0.6.1 == | == Ubiquity 0.6.1 == | ||
| Line 83: | Line 111: | ||
A few features that didn't make it into 0.6, along with fixes for whatever the biggest bugs are that we discover after 0.6. | A few features that didn't make it into 0.6, along with fixes for whatever the biggest bugs are that we discover after 0.6. | ||
== Ubiquity 0.7 == | == Ubiquity 0.7: The Web-of-Trust Security Model == | ||
Late Q3, 2009 | |||
Because of the growing user population, this release will need to focus on security. With the growing user population, sooner or later someone will start writing malicious Ubiquity commands. We will try to combat this by using the power of networked users for good instead of evil. Our longstanding plans for a "[[Labs/Ubiquity/TrustNetwork|web of trust]]" security model will require several improvements to the infrastructure of command subscription. First, Ubiquity will need to know who your friends are, so that it can see what commands your friends have recommended subscribing to, and what commands they've recommended avoiding. | |||
Second, commands will no longer be able to have direct access to third-party servers through XHRs, or to the XPCOM components in the Mozilla platform. Instead, they will have to make API calls through a security layer. This security layer will identify exactly what permissions a command is requesting, so that when a user subscribes to it, Ubiquity can tell that user in a plain, human-readable way exactly what is being requested: "This command wants permission to write to your filesystem", for instance, or "This command wants to contact the site www.sendmealotofspam.com." | |||
The security layer will make it so that users know what questions are being asked of them by a command install (which will be a big step up from the scary red screen with javascript source code); the web of trust, with recommendations from your friends, will help users decide sensible answers to these questions. | |||
* The web-of trust: Ubiquity becomes aware of your friends and includes a system for giving feedback on commands. | |||
* The security layer: commands get access to third-party XHRs, XPCOM components, etc. only through security-aware proxy object. | |||
* Distributed localization infrastructure: User A should be able to subscribe to User B's localization of User C's command feed, so that localizations don't need to be centralized (bottlenecked) in the Ubiquity team. | |||
* More locales supported, more and better built-in commands | |||
== Ubiquity 0.7.1 == | == Ubiquity 0.7.1 == | ||
| Line 89: | Line 130: | ||
A few features that didn't make it into 0.7, along with fixes for whatever the biggest bugs are that we discover after 0.7. | A few features that didn't make it into 0.7, along with fixes for whatever the biggest bugs are that we discover after 0.7. | ||
== Ubiquity 0.8: User-interface experimentation == | |||
Q4, 2009 | |||
This release will focus on opening up the Ubiquity user-interface to more experimentation. | |||
By rebuilding Ubiquity on top of Jetpack, so that Ubiquity and Jetpack share a common runtime, we will not only make debugging of Ubiquity much easier; we will also be able to expose the library of installed Ubiquity commands through a Jetpack API, so that others can write new interfaces to take advantage of these commands. | |||
* Ubiquity built to run on Jetpack | |||
* Commands exposed through Jetpack | |||
* Experimentation with different UI, such as always-on input field, or mouse-based UI. | |||
* Command chaining, AKA pipes between commands | |||
* Solve whatever are the most pressing usability problems discovered through Test Pilot data collection | |||
* More locales supported, more and better built-in commands | |||
== Ubiquity 1.0: A product ready for mainstream use == | |||
Q1, 2010 | |||
This release will focus on polish. It will not have any major new features beyond 0.8, but before a release is worthy of being called 1.0 it must be much more solid than any release we have made thus far. The built-in commands and nountypes, the security model, the user interface, and the parser must all be clean and reliable, and all remaining major bugs must be fixed. | |||
== Beyond 1.0: == | |||
Experiments in these areas can be done beyond 1.0 if there are sufficient developer resources, but they are outside the core project goals. | |||
* Weave integration | |||
* Thunderbird integration | |||
* Bespin integration | |||