Jetpack/Roadmap/2012
 |
Jetpack 2012 Roadmap | |
| Owner: David Mason | Updated: 2012-10-31 | |
| 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. |
2012 Jetpack Roadmap
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.
1) 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:
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.
We have long wanted an easy way for developers to share modules with each other to make development of add-ons even easier. In addition, we can keep the core SDK APIs small and light while developers still have access to a great deal of functionality. We want to create a system that allows for easy sharing, discovery, and implementation of modules so that the community of development can grow.
P1 APIs
1) Chrome-mods
Firefox has always presented itself to developers as a browser that allows customization. While this can often be painful from the point of view of user experience, it also provides great power in extensibility and innovation. Jetpack has always embraced the idea of modification and extension but only for shallow integrators where we felt some responsibility to help direct better user experience guidelines through offering only elements that would lend themseleves to that better experience. While that does a great deal to help keep the experience clean, it also frustrates those who want to integrate more deeply into the browser. With a new focus on Deep Integrators we want to take the modification idea to Firefox Chrome (user interface) in a similar manner in which we answered the modification question with web pages.
Chrome mods will allow the developer to easily alter Firefox chrome in a manner that is very similar to page-mods with the exception that the chrome being altered must first be properly identified before the developer can alter that element.
2) Simpler Ctype API
The initial scope of this is to add a utility that will help add-on developers who are working with binaries to be able to automatically scope their 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.
3) Places API
The Places API will allow developers access to the bookmarks menu, bookmarks tool, and possibly more. This needs more scope.
4) Crypto API
The crypto API will give SDK developers simple key/pair functionality to sign and verify data.
We have developed a solution to localize strings within the code elements of jetpack add-ons, but many of them include text within HTML elements. We must ensure that we can also localize these HTML elements to have a more complete localization answer. In addition, the Mozilla platform supports the localization of XUL and XHTML via their DTDs and entity references, but there is no support for localizing HTML. We have the opportunity to change this and make localization better.
The next step for us in developing a better l10n experience is to add localizing static and dynamic text in HTML elements.
6) 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
1) 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.
2) 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.
We currently ship the Add-on SDK as a zip file or source code through github. This may not be the best way for us to distribute the SDK. First, we have a built-in automated update mechanism with AMO which also provides support for stable and beta distribution channels. Second, if we can get the SDK to package itself we have a chance for SDK developers to "eat their own dogfood" - testing the packaging and perfomance everyday. Finally, possibly building upon the original prototype as well as Alexandre Poirot's work of porting the SDK to an add-on we can start to offload some of the Builder's time-consuming functions to the client while also avoiding difficult dependencies for Add-on SDK users.
4) Land APIs & Loader in Firefox
For quite a while, we have discussed landing the Add-on SDK APIs and Loader into Firefox itself. There are multiple benefits to this including either making repacks less frequent or altogether obsolete (in other words, ensuring add-ons using these high-level APIs would always remain compatible through different versions of Firefox), making add-ons built with the SDK much smaller, and possibly improving add-ons performance even more. In addition, this would give the SDK codebase even more legitimacy which could help us gain more developers using it to create add-ons.
We do have a few requirements for landing into Firefox though:
- The Existing Jetpack team should continue to maintain this code
- The code should be able to remain in github for development
- Our current code reviewers should maintain that power to review
P2 APIs
1) Intercept Network requests
2) Add-on Menu
Tertiary Priorities
1) Extend Functionality in existing APIs
2) Subclassing
3) Test add-ons without restarting Firefox
P3 APIs
1) Awesome Bar API
2) Integration with JS Debugging
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.
Engagement
We also have a roadmap for community engagement
Goals
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.
