MozillaWiki

Jetpack/Roadmap: Difference between revisions

Page Discussion

Jetpack/Roadmap (view source)

Revision as of 18:43, 19 December 2011

9,480 bytes added ,  19 December 2011
no edit summary
No edit summary
No edit summary
Line 13: Line 13:


= 2012 Jetpack Roadmap =
= 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 =
= Changing Focus =


The Jetpack project had a desire from the beginning to make the creation of an add-on easier than the existing, traditional toolset allowed. To that end, we also had the goal of trying to bring in brand new developers by utilizing the tools of web development. This approach was designed to allow the creation of add-ons that fullfilled the use-cases of shallow-integrators - meaning, developers who didn't wish to make sweeping changes to the browser, but had simpler ambitions for their add-ons. For this audience, we have been successful in answering most of their needs. In addition, we also had a desire to answer the needs of an even lower level which might be described as Greasemonkey scripters - developers who wanted to write simple modifications to web pages. For this audience, the SDK is still too complicated and heavy for their needs. Their needs might be best answered in an even easier-to-use tool which is proposed in the addendum.
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".


With the advent of web apps the world of add-ons will find that a good number of shallow-integrators will be moving their work to the app world. The Apps space will provide these developers with a platform in which they can simply take their web development toolset and reach an even wider audience than they could with an add-on. This is powerful for the shallow-integrators and could mean a fairly big shift in our audience. With that shift we must evaluate where we are and who our audience will be with this shift. To that end, this roadmap proposes a move towards answering the needs of a different audience, 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.  


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 roadmap reflects a change to address the needs of deep-integrators and make it easier for them to accomplish what they have been doing with the traditional tools.
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 =
= 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 =
= Top Priorities =


The top priorities for the Add-on SDK in 2012 are:
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
* Mobile
** Prefs API
 
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
** 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).


* P1 APIs
** Chrome-mods
** Simpler Ctype API
** 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
** Places API
** Crypto API
The Places API will allow developers access to the bookmarks menu,
bookmarks tool, and possibly more. This needs more scope.


* Continue Localization Work
** [https://wiki.mozilla.org/AddonSDKCryptoAPI Crypto API]
* Move Add-ons to top of browser
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 =
= Secondary Priorities =
* Improve XPCOM Access
* 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
* Hidden window
* SDK as an Add-on
We currently provide a good deal of functionality by hiding a window
* Landing SDK in AMO
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
* Land APIs & Loader in Firefox
* P2 APIs
 
** Intercept Network requests
 
** Add-on Menu
== P2 APIs ==
 
* Intercept Network requests
* Add-on Menu  




= Tertiary Priorities =
= Tertiary Priorities =
* Extend Functionality in existing APIs
* Extend Functionality in existing APIs
* Subclassing
* Subclassing
* Test add-ons without restarting Firefox
* Test add-ons without restarting Firefox
* P3 APIs
** Awesome Bar API
** Integration with JS Debugging


== 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
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 =
= Goals =
[https://wiki.mozilla.org/Jetpack/Goals/2012-Goals 2012 Goals By Quarter]
[https://wiki.mozilla.org/Jetpack/Goals/2012-Goals 2012 Goals By Quarter]
Dcm-moz
canmove, Confirmed users
548

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/380014"