Labs/Ubiquity/Roadmap - Revision history

Bpung at 16:30, 20 July 2009

2009-07-20T16:30:17Z

← Older revision		Revision as of 16:30, 20 July 2009
Line 63:		Line 63:

	== 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		Beginning of Q3, 2009

Jdicarlo: /* Ubiquity 0.7: The Web-of-Trust Security Model */

2009-06-25T21:44:48Z

Ubiquity 0.7: The Web-of-Trust Security Model

← Older revision		Revision as of 21:44, 25 June 2009
Line 117:		Line 117:
	* The web-of trust: Ubiquity becomes aware of your friends and includes a system for giving feedback on commands.		* 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.		* 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		* More locales supported, more and better built-in commands

Jdicarlo: /* Ubiquity 0.6: Push for more End-User Benefits */

2009-06-25T21:41:18Z

Ubiquity 0.6: Push for more End-User Benefits

← Older revision		Revision as of 21:41, 25 June 2009
Line 75:		Line 75:
	Mid Q3, 2009		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 for better stability and functionality, plus expanding the range of commands available, and attempting to expand the size of our user base.		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 82:		Line 82:
	* 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.
	* ~~Localization gets wider and deeper: More locales supported; make~~ nountypes localizable~~; look into distributing localization so that a command feed can be localized independently from its creator~~.		* User-defined command synonyms/aliases.
			* Make nountypes localizable.
	* Suggestion memory improved to cover noun suggestions		* Suggestion memory improved to cover noun suggestions
	* Experiment with doing noun recognition in the cloud		* Experiment with doing noun recognition in the cloud

Jdicarlo: /* Ubiquity 0.7: The Web-of-Trust Security Model */

2009-06-25T21:36:21Z

Ubiquity 0.7: The Web-of-Trust Security Model

← Older revision		Revision as of 21:36, 25 June 2009
Line 116:		Line 116:
	* The web-of trust: Ubiquity becomes aware of your friends and includes a system for giving feedback on commands.		* 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.		* The security layer: commands get access to third-party XHRs, XPCOM components, etc. only through security-aware proxy object.
	* User-defined command aliases
	* More locales supported, more and better built-in commands		* More locales supported, more and better built-in commands

Endolith: /* Ubiquity 0.7: The Web-of-Trust Security Model */

2009-06-25T18:37:31Z

Ubiquity 0.7: The Web-of-Trust Security Model

← Older revision		Revision as of 18:37, 25 June 2009
Line 108:		Line 108:
	Late Q3, 2009		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 "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.		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."		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."

Jdicarlo: /* Community Building after 0.6 */

2009-06-25T18:25:35Z

Community Building after 0.6

← Older revision		Revision as of 18:25, 25 June 2009
Line 92:		Line 92:
	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, ~~swag~~, and ~~possible uplift~~ into standard feeds to be ~~included by default with future versions~~.		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 ==

Jdicarlo: /* Planned Upcoming Releases */

2009-06-25T18:07:36Z

Planned Upcoming Releases

← Older revision		Revision as of 18:07, 25 June 2009
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 ==

			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:

Jdicarlo: /* Ubiquity 0.6: Push for more End-User Benefits */

2009-06-22T00:00:15Z

Ubiquity 0.6: Push for more End-User Benefits

← Older revision		Revision as of 00:00, 22 June 2009
Line 61:		Line 61:
	== Ubiquity 0.6: Push for more End-User Benefits ==		== Ubiquity 0.6: Push for more End-User Benefits ==

	~~Early~~ Q3		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 for better stability and functionality, plus expanding the range of commands available, and attempting to expand the size of our user base.		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.

Jdicarlo: /* Ubiquity 1.0: A product ready for mainstream use */

2009-06-21T23:59:37Z

Ubiquity 1.0: A product ready for mainstream use

← Older revision		Revision as of 23:59, 21 June 2009
Line 122:		Line 122:
	== Ubiquity 1.0: A product ready for mainstream use ==		== Ubiquity 1.0: A product ready for mainstream use ==

	~~Early~~ 2010		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.		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.

Jdicarlo: /* Ubiquity 0.8: User-interface experimentation */

2009-06-21T23:59:20Z

Ubiquity 0.8: User-interface experimentation

← Older revision		Revision as of 23:59, 21 June 2009
Line 107:		Line 107:
	== Ubiquity 0.8: User-interface experimentation ==		== Ubiquity 0.8: User-interface experimentation ==

	~~Late~~ Q4, 2009		Q4, 2009

	This release will focus on opening up the Ubiquity user-interface to more experimentation.		This release will focus on opening up the Ubiquity user-interface to more experimentation.