|
|
| (21 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| __NOTOC__
| | {{outdated}} |
| | |
| | __FORCETOC__ |
|
| |
|
| <section begin=summary />{{RoadmapSummary | | <section begin=summary />{{RoadmapSummary |
| |icon=Jetpackicon.png | | |icon=Jetpackicon.png |
| |pagelocation=Labs/Jetpack/Roadmap | | |pagelocation=Labs/Jetpack/Roadmap |
| |pagetitle=Jetpack 2012 Roadmap | | |pagetitle=Jetpack Product Roadmaps |
| |owner=David Mason | | |owner=Jeff Griffiths |
| |updated=December 2011 | | |updated=Oct 2012 |
| |status=Draft | | |status=Draft |
| |description=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.}}<section end=summary /> | | |description=Roadmaps for Jetpack}}<section end=summary /> |
| | |
| {{draft| Detail will be added in the coming days}}
| |
| | |
| = 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.
| |
| | |
| ===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
| |
| [https://wiki.mozilla.org/Features/Jetpack/Add-onTab-API 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.
| |
| | |
| ====[https://wiki.mozilla.org/AddonSDKCryptoAPI Crypto API]====
| |
| The crypto API will give SDK developers simple key/pair functionality
| |
| to sign and verify data.
| |
| | |
| ===[https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK_Localization_API_and_Service 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
| |
| [https://etherpad.mozilla.org/background-window 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.
| |
| | |
| ===Land APIs & Loader in Firefox===
| |
| | |
| | |
| ===P2 APIs===
| |
| | |
| ====Intercept Network requests====
| |
| ====Add-on Menu====
| |
| | |
| = Tertiary Priorities =
| |
| | |
| ===Extend Functionality in existing APIs===
| |
| ===Subclassing===
| |
| ===Test add-ons without restarting Firefox===
| |
| | |
| == P3 APIs ==
| |
| ====Awesome Bar API====
| |
| ====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
| | =Under construction= |
| 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 = | | === Future === |
| | * [https://wiki.mozilla.org/Jetpack/Roadmap/2013 2013 Roadmap] [DRAFT] |
|
| |
|
| [fn:1] We can make Greasemonkey scripting far easier than either
| | === Archive === |
| 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 =
| | * [https://wiki.mozilla.org/Jetpack/Roadmap/2012 2012 Roadmap] |
| [https://wiki.mozilla.org/Jetpack/Goals/2012-Goals 2012 Goals By Quarter] | | * [https://wiki.mozilla.org/Jetpack/Roadmap-2011 2011 Roadmap] |
