Jetpack/Roadmap

	Jetpack 2012 Roadmap
	Owner: David Mason	Updated: 2011-12-19
	The Roadmap for Jetpack in 2012 shifts focus to Deep-integrators. Top priorities are: Mobile Prefs API, Mobile Add-on Tab API, Chrome-mods, CType Helper Util, Places API, Crypto API, l10n, and moving Add-on's from lower add-on bar to the top of the browser.

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

The State of Jetpack

The Jetpack project had a very successful year in 2011. We have created a set of APIs and tools which present an excellent platform in which to create Firefox add-ons. We have answered a good number of use-cases for the audience we initially set out to address and we have joined Firefox in the train-release cycle to good effect. At this stage of the life of the project, it is time to step-back and assess where we are and who we are developing for.

Changing Focus

The Jetpack project had a desire from the beginning to make the creation of Firefox add-ons easier than using the existing, traditional toolset. To that end, we also had the goal of trying to bring in new developers by utilizing the tools of web development (javascript, css).

Who Develops Add-ons?

As the Jetpack project is into its second year of existence, defining exactly who develops add-ons for Firefox has become more apparent as we see who chooses the Add-on SDK and who chooses the traditional toolset. In our observations there tend to be four types of add-on developer: the Greasemonkey Scripter, the Shallow-integrator, the Cross-Browser developer, and the Deep-integrator.

Shallow Integrators

We started the jouney of developing the Add-on SDK with the Greasemonkey Scripter and Shallow-Integrator in mind. The Add-on SDK has allowed for minimal changes to the browser, but a powerful set of APIs to create certain categories of add-ons. We have mostly been successful at fulfilling the needs of these developers who we can call "Shallow-integrators" as their add-ons don't have a need to integrate as tightly with Firefox as many traditional add-ons. However, with the approach of open web apps, we expect that the shallow-integrators will be slowly moving away from add-on development as apps will answer many of their development needs and provide an even wider distribution. If this is to be true, we need to expand the SDK to include a different, and now wider, audience.

Greasemonkey Scripters

Another audience we tried to include in the Jetpack project up till now has been the "Greasemonkey scripter". These are people who simply want to make modifications to web pages and easily distribute those changes with anyone. While we have an answer for this audience, we feel like it is far too heavy and difficult to properly answer the needs of these people. While we won't be altering the work we have done here, there are better ways to fulfill this audience which are likely to be outside of the scope of the Jetpack team's 2012 work[fn:1].

Cross-Browser Developers

A good number of developers that span all of the other three categories are Cross-browser developers who need to develop for any and all browsers. We have not had much focus on these developers and we are unlikely to anytime soon. The challenge is a tough one and is answered in small part by us making sure it is easy to develop for Firefox. Certainly its not a full answer, but for time and resources, is the best we can do for now.

Deep Integrators - A Proposal

With shallow-integrators having better options coming in the form of apps, and the Jetpack project never really satisfying the Greasemonkey-scripters properly, we are proposing that we now turn our focus to the "Deep-Integrators".

Deep-integrators are the backbone of Firefox's add-on community. They are the developers who have made Firefox unique among browsers. While the SDK is still useful to them in its current state, we can make it an excellent toolset for them that offers a better platform than the traditional tools have. This shift does not abandon the goal of making add-on development easier, but it does expand the scope of the toolset to include APIs and tools which will appeal more to these deep-integrators.

This roadmap reflects this change in audience and the work we are proposing to do in 2012 should align better with the deep-integrators.

The Roadmap

DRAFT - at this stage the items in this roadmap are simple notes and will be more full-featured explanations as I get to them!

Top Priorities

The top priorities for the Add-on SDK in 2012 are: Continuation of Mobile work, new APIs, continuation of l10n work, and moving the add-ons from the add-on bar to the top of Firefox.

Mobile

We must continue our work on making the development of add-ons for Firefox mobile easy and familiar using the same APIs and tools used to create desktop add-ons. We still have a good deal of scope to figure out with mobile add-ons as there have been so few created to this point, and a small amount of usage. To that end, we are unsure which use-cases are the most desired for mobile add-ons.

Because of this lack of scope, we have decided to pick a couple of APIs which seem important to tackle early, get them running and see how people use them and what they ask for in addition to these. As we already have page-mods working, the two additional APIs we have decided to look at are:

Preferences API

This allows developers to add simple preferences to their add-on. We have just landed this for Desktop and need to make sure it works in Mobile. The initial scope suggests looking at the native android preferences screen as the UI, though that may change as we investigate.

Add-on Tab API

This is represented in the feature page for adding the add-on tab to Desktop Firefox, we simply need to port this over to mobile.

P1 APIs

Chrome-mods

An important piece of the SDK to-date has been the ability to simply alter web pages with the Page-mod API. We wish to allow the same functionality to developers to alter chrome with a simple script and CSS. The scope of this work also calls for the ability to revert those changes (and possibly to add that same reverting function to page-mods).

Simpler Ctype API

The initial scope of this is to add a untility that will help add-on developers who are working with binaries to be able to automatically scope thier binary and include the proper headers, instantly, to their add-on. There may be greater scope once this is complete. In addition, we need to document how binaries can be used with the SDK.

Places API

The Places API will allow developers access to the bookmarks menu, bookmarks tool, and possibly more. This needs more scope.

Crypto API

The crypto API will give SDK developers simple key/pair functionality to sign and verify data.

Continue Localization Work

We still have a great deal to do to provide the best localization answer to add-on developers and those who localize add-ons. The scope of what's left includes answering the html localizing question, starting the shared-string-translation service, connecting to that service, and making sure it all integrates with AMO.

Move Add-ons to top of browser

For a while we have talked about moving the widgets and panels the SDK provides to the top of the browser and away from the small add-on bar at the bar. The UX team agrees with this move and has given us some guidance to go ahead and make this move.

Secondary Priorities

Improve XPCOM Access

We currently allow developers access to XPCOM when developing add-ons with the SDK, but this could be vastly improved. The scope of that improvement is still being worked on.

Hidden window

We currently provide a good deal of functionality by hiding a window and doing things like parsing a DOM in that window. This is rather hacky and there have often been calls for Firefox to provide a window to do such things that is not tied to the OS. We want to do this platform work and provide that window. The scope of use-cases is still being worked on though some of this is provided in this etherpad.

SDK as an Add-on

Landing SDK in AMO only

There is a great deal of work that is scheduled to happen to make the SDK an add-on, including the removal of our python code at some stage. However, the first focus should be the investigation of simply using AMO as a distribution of the SDK while leaving the SDK exactly as it is now. If this is possible we could get the benefits of distribution from AMO earlier than if we waited till the full scope is reached.

Non-Goals

Apps

Mozilla, other browser vendors, and other industry participants havebeen defining standards, UX affordances, and distribution channels for the next generation of web apps. But apps differ from add-ons, even if they sometimes bundle themselves as such for lack of better distribution channels.

Mozilla Labs' Open Web Applications project is kicking ass here and is much better positioned to identify and address the exposure and distribution needs of apps, while Mozilla's developer tools team headed by Kevin Dangoor is the right locus for activity around tools for web developers.

Although we can see future work where we can make some of our APIs available for App developers who wish to have some integration with Firefox when rnu there, the Jetpack project will not focus on building tools for app development and distribution in 2012.

 Note that the absence of a goal from the priorities list, or its
 presence on the anti-list, does not mean we won't accept code that
 achieves it. To the contrary, provided such contributions don't work
 at cross-purposes to the core goals of the project, we couldn't be
 more thrilled to see our technologies get used by the Mozilla and
 broader open source communities.
 So if you're a Thunderbird developer, a web dev tools hacker, a
 XULRunner appmeister, or anyone else who wants to see Add-on SDK and
 Builder (or their component parts) better support your own particular
 use cases (or get repurposed into your own new products), know that we
 want to see that too! So please don't hesitate to dream about how the
 project can help you, talk about your ideas with us, and make them
 happen. Besides code to see some of these things happen, we also
 desire a commitment to supporting that code through our train release
 process which we cannot afford at this time.

Persistant Goals

There are goals we shall strive to achieve in the Jetpack project that may or may not be explicitly written in this Roadmap or in our Quarterly goals. However, these things will always be goals for the project and any products which we create:

• Performance

We must always measure our preformance and be thoughtful of how the Add-on SDK affects the performance of Firefox.

• Footprint

We should try to make sure that everything we create is as small as it can be while still providing the functionality we think is necessary.

• Security

We must ensure the security of all our users and make sure that we are consistently reviewing, with the help of security experts, our code to be as secure as we can make it.

• Simplicity

We should strive to provide the simplest structure to our APIs and tools to make sure the Jetpack experience is easy to use. In addition we should keep the codebase clean and simple to ease and encourage contributions.

• Memory Consumption

We should strive to keep memory consumption of an add-on built with our high-level APIs as small as possible.

• Stability

We will strive to make the Add-on SDK as stable as possible and respond to issues as quickly as possible to make sure that users can trust the SDK for their development.

Footnotes

[fn:1] We can make Greasemonkey scripting far easier than either Jetpack or Greasemonkey has done by creating a tool that rides on top of our devtools and allows a page-modification to happen with the click of a button. The proposal for such a tool can be found in its own feature page that is not specifically assigned to the Jetpack project.

Goals

2012 Goals By Quarter