Re: Firefox front-end features, time-to-market, and coordination.

classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Blair McBride (Unfocused)
On 30/07/2011 5:11 a.m., Dietrich Ayala wrote:
> We've learned through experience with Sync, Personas, Account Manager,
> Panorama and F1 that front-end features developed outside of the
> Firefox team require massive refactorings/rewrites and long
> development cycles to transition from an add-on experiment to a
> feature in the core, and sometimes the feature doesn't land at all.
> Also, there can be friction between groups as issues of performance,
> quality, ownership, conflicting timelines and mismatched expectations
> crop up during these transitions.

In all of those cases, they started out as experiments and prototypes
that added something on top of Firefox, and tried to directly transition
to a production-ready feature. Shipping prototype code doesn't work.
Jetpack is great, and it should be in Firefox - but it's not going to
make prototypes shippable.

- Blair
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Robert Kaiser
Ehsan Akhgari schrieb:
> There were a bunch of problems
> that we faced during the integration phase

All of which would IMHO not have been too different if you would have
been based on Jetpack.
All of those are important points I have seen with a lot of things that
have been prototyped in some way, usually as add-ons, and then later
integrated. Even Firefox itself suffered a lot from a number of those
points in its early stage, before it became a mainline project.
IMHO, those are all points of both culture and rapid prototyping, and
independent of the technology.

> If I have to share the lessons that I learned from this efforts, I can
> summarize them as:
>
> 1. Getting feedback from users/developers early on is valuable.  [...]
>
> 2. Code quality should never be an after-thought.  [...]

Good lessons for all of us, right.
I for myself spent a lot of time writing automated tests for my Tahoe
Data Manager add-on, and that tremendously helped code quality by
finding a number of bugs I probably would not have seen else, and it (in
addition to following common Mozilla code style from the beginning)
surely made the integration into SeaMonkey smoother.

And I think those things are more to the core of getting stuff
integrated into mainline code more easily. Of course, spending a lot of
time writing tests and writing your code to be clean and possibly even
performant from the beginning may conflict with rapid prototyping, but
you always need to keep in mind that you need to get there some time
anyhow if your target is to include the feature in the mainline.

Those things are independent of the technology though, no matter if we
have Jetpack in the mainline or not, you can prototype fast without
tests and with ugly hacks and later rewrite or start off a bit slower
but with tests and clean code from the beginning. Your choice as a
developer - just don't complain afterwards that you haven't been warned. ;-)

Robert Kaiser

--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Ron Hunter
On 8/1/2011 8:36 AM, Robert Kaiser wrote:

> Ehsan Akhgari schrieb:
>> There were a bunch of problems
>> that we faced during the integration phase
>
> All of which would IMHO not have been too different if you would have
> been based on Jetpack.
> All of those are important points I have seen with a lot of things that
> have been prototyped in some way, usually as add-ons, and then later
> integrated. Even Firefox itself suffered a lot from a number of those
> points in its early stage, before it became a mainline project.
> IMHO, those are all points of both culture and rapid prototyping, and
> independent of the technology.
>
>> If I have to share the lessons that I learned from this efforts, I can
>> summarize them as:
>>
>> 1. Getting feedback from users/developers early on is valuable. [...]
>>
>> 2. Code quality should never be an after-thought. [...]
>
> Good lessons for all of us, right.
> I for myself spent a lot of time writing automated tests for my Tahoe
> Data Manager add-on, and that tremendously helped code quality by
> finding a number of bugs I probably would not have seen else, and it (in
> addition to following common Mozilla code style from the beginning)
> surely made the integration into SeaMonkey smoother.
>
> And I think those things are more to the core of getting stuff
> integrated into mainline code more easily. Of course, spending a lot of
> time writing tests and writing your code to be clean and possibly even
> performant from the beginning may conflict with rapid prototyping, but
> you always need to keep in mind that you need to get there some time
> anyhow if your target is to include the feature in the mainline.
>
> Those things are independent of the technology though, no matter if we
> have Jetpack in the mainline or not, you can prototype fast without
> tests and with ugly hacks and later rewrite or start off a bit slower
> but with tests and clean code from the beginning. Your choice as a
> developer - just don't complain afterwards that you haven't been warned.
> ;-)
>
> Robert Kaiser
>
I am going to stick my 'user oar' into this discussion.

Hasn't it always been the plan to incorporate only those features into
the base code of Firefox that would be used by the majority of users?
Is this no longer the policy?  I surely don't want to see Firefox become
another ADA which was designed by a large committee, and they put in
everything anyone suggested.  How many 'users' would ever use the
Jetpack code?  I already have to tote the load for all of the 3% of
users who find the incorporation of Tab Candy into the mainline code.
What's next?
Back to lurking.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Alex Limi
In reply to this post by Blair McBride (Unfocused)
On Sat, Jul 30, 2011 at 7:35 AM, Dietrich Ayala <[hidden email]> wrote:

>  I'd love to hear other visions
> of what it could look like to build Firefox (desktop, mobile, and
> wherever else we go) in 2-3 years.
>

The #1 thing I'd like to see from the UX side of things over the next years
is dropping (or minimizing the use of) XUL if possible.

If contributors could hack something like straight-up HTML5 & CSS, our
contributions (and quality!) would increase, and I suspect our time to
implement front-end improvements and designs would be reduced greatly. Have
a part of our stack that works the same way as the web.

(and yes, I'm sure there are millions of details and dependencies here)

The other thing I'd like us to seriously look in to is hosting in a system
like Github. The amount of visibility and developer engagement, willingness
to hack, etc this brings us shouldn't be underestimated.

Hopefully this isn't too off-topic, I'm passionately interested in lowering
the barrier to getting involved with Firefox.

--
Alex Limi · Firefox UX Team · +limi <http://profiles.google.com/limi> ·
@limi <http://twitter.com/limi/> · limi.net
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Dao-6
In reply to this post by Ron Hunter
On 01.08.2011 17:30, Ron Hunter wrote:
> How many 'users' would ever use the Jetpack code?

None. Jetpack is not a user-facing feature, it's a framework for add-ons.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Boris Zbarsky
In reply to this post by Ron Hunter
On 8/1/11 11:30 AM, Ron Hunter wrote:
> How many 'users' would ever use the Jetpack code?

About as many as ever use the XPI installer code.  Way more than ever
use the MathML code or probably the SVG code.

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Daniel Veditz-2
On 8/1/11 10:51 AM, Boris Zbarsky wrote:
> On 8/1/11 11:30 AM, Ron Hunter wrote:
>> How many 'users' would ever use the Jetpack code?
>
> About as many as ever use the XPI installer code.

Way more if we eventually develop core Firefox features on top of
it. Maybe a big "if" but that's how Jetpack came into this thread in
the first place.

-Dan Veditz
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Daniel Veditz-2
In reply to this post by Blair McBride (Unfocused)
On 7/29/11 12:08 PM, Robert Kaiser wrote:
> Removing markup [...] and making everything JS does surely
> incredibly slow down any somewhat larger UI [....] You also
> don't write large websites as one large JS script that builds the
> DOM and styles all dynamically, right?

Facebook and Twitter do ;-)

-Dan Veditz
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Daniel Veditz-2
In reply to this post by Blair McBride (Unfocused)
On 7/31/11 7:26 PM, Blair McBride wrote:
> Shipping prototype code doesn't work. Jetpack is great, and it
> should be in Firefox - but it's not going to make prototypes
> shippable.

"Build one to throw away" is still true.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Axel Hecht
In reply to this post by Blair McBride (Unfocused)
On 01.08.11 18:38, Alex Limi wrote:

> On Sat, Jul 30, 2011 at 7:35 AM, Dietrich Ayala<[hidden email]>  wrote:
>
>>   I'd love to hear other visions
>> of what it could look like to build Firefox (desktop, mobile, and
>> wherever else we go) in 2-3 years.
>>
>
> The #1 thing I'd like to see from the UX side of things over the next years
> is dropping (or minimizing the use of) XUL if possible.
>
> If contributors could hack something like straight-up HTML5&  CSS, our
> contributions (and quality!) would increase, and I suspect our time to
> implement front-end improvements and designs would be reduced greatly. Have
> a part of our stack that works the same way as the web.
>
> (and yes, I'm sure there are millions of details and dependencies here)

Actually, I think this very thread is about the problems we have with
getting code that's straight-up HTML5 etc into a shippable product.

The "straight-up" piece is just not about writing something that's
localizable, accessible, RTL-ready, comes with tests etc, blends into
all platforms, etc

Once you have all those code-quality things on top of HTML, the bit of
markup differences may not be all that much of a difference.

> The other thing I'd like us to seriously look in to is hosting in a system
> like Github. The amount of visibility and developer engagement, willingness
> to hack, etc this brings us shouldn't be underestimated.

Do you think we have problems with any of these? I don't, really.

I do think we're bad at turning the willingness and engagement and ideas
that are there into try-server builds, and explaining what that is.
Becoming more of a hosting service to lower the barrier to those
systems, and figure out ways to make those discoverable would help a
ton, I guess. "discoverable" on both ways, as in, make it discoverable
that you can do a try server build, where they go etc from your repo.
And make it discoverable for mentors that there are new contributions
out to field, and maybe test results to help with or something.

> Hopefully this isn't too off-topic, I'm passionately interested in lowering
> the barrier to getting involved with Firefox.

I personally prefer to design the learning curve vs lowering the barrier
to entry. Like, I don't think there's a barrier of entry per se, but
there are a few points on your way to becoming a mozilla contributor
where you have to learn a whole lot, and you don't really understand why
you're learning that at that point.

If we get that to work for a handful of use cases, we'd probably win a lot.

Axel
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Robert Kaiser
In reply to this post by Blair McBride (Unfocused)
Daniel Veditz schrieb:
> On 7/29/11 12:08 PM, Robert Kaiser wrote:
>> Removing markup [...] and making everything JS does surely
>> incredibly slow down any somewhat larger UI [....] You also
>> don't write large websites as one large JS script that builds the
>> DOM and styles all dynamically, right?
>
> Facebook and Twitter do ;-)

And I thought the only thing that sucked about them was being
centralistic silos. Now I know anther reason why I would never think to
register with them. ;-)

Robert Kaiser


--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Robert Kaiser
In reply to this post by Blair McBride (Unfocused)
Alex Limi schrieb:
> The #1 thing I'd like to see from the UX side of things over the next years
> is dropping (or minimizing the use of) XUL if possible.

Why from a UX side? Right now, XUL excels at looking well UX-wise
(unless you design an alien-looking piece with it like the add-ons
manager, sorry to say that) while HTML sucks in terms of
cross-application consistency and positioning of UI elements, flexible
layout, and availability of easy UI controls (and I won't go into the
hell of using <input> for about a dozen completely different kinds of
controls). Also, being able to use overlays and defining new controls
(with XBL atm) are other things where XUL excels compared to HTML right now.

We need to put a ton of work into HTML to make it match XUL UX-wise. I'm
all for us doing that, and actually we've been holding back on doing
that a bit too long IMHO. We need to bring HTML up to speed there, and
with our ton of experience in XUL land we're in the best position on the
whole web planet to work on the new standards needed, to avoid mistakes
we made in XUL land, and to lead implementation-wise.

I agree on the long-term target, but we still have a *ton* of work to
get there - and I really don't understand the UX argument at this point.

Robert Kaiser

--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Alex Limi
On Tue, Aug 2, 2011 at 7:22 AM, Robert Kaiser <[hidden email]> wrote:

> Why from a UX side?


Because most of the people that would/could contribute (including people on
the UX team) have pretty deep knowledge of HTML/CSS — and occasionally JS —
but XUL is too narrow in its focus, so it's unlikely that they'll ever pick
that up, since it isn't a reusable skill.

Also, the browser should be written in the language of the web.

PS: If you think the add-ons manager is alien-looking, that really has
nothing to do with XUL vs. HTML. It's really not that hard to make a UI in
HTML/CSS that looks "native", whatever your definition of native is.
Performance, animations and effects are a different matter, and need to
improve — but we're getting there.

--
Alex Limi · Firefox UX Team · +limi <http://profiles.google.com/limi> ·
@limi <http://twitter.com/limi/> · limi.net
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Dan Mills-5
In reply to this post by Blair McBride (Unfocused)
Hey all,

Jumping late into this thread (and sorry if it doesn't thread right, I
had some mailing list fail and the headers aren't right).

Thanks for kicking off this discussion. I've been talking with Ragavan
about this and want to give you our $.02 from the Identity & Apps POV.

First, I'm happy to see Jetpack being considered as a possible vehicle
for feature integration. We (the Identity and Apps teams) have been
able to iterate unbelievably quickly using Jetpack, while there are
certainly areas for improvement I can't overstate how valuable it has
been to us so far.

I wanted to take the discussion a step further, though, and talk about
a couple of things we'd like to see from the platform. I don't mean to
negate the pain points discussed before (like l10n tools,
perf/automated testing, etc)--those will certainly need to be worked
on. But I think you need to think bigger:

* We want to "dial up" feature deployment

We'd like to be able to progressively deploy features based on
criteria such as geographic area, language, or just to a percentage of
users (e.g., have a knob where we can say "12% of users in France" and
roll features out progressively).

Using such a system we could also maintain regional sets of features
on a permanent or semi-permanent basis. For example, the China team's
Firefox build with bundled add-ons could be rolled out/maintained in
this way.

Websites do this all the time, and it's a huge advantage that we
currently don't have.

* We need to iterate independently, on an ongoing basis

Something that seems to get ignored is iteration *after* landing a
feature. I don't mean maintenance, rather already-planned changes
(further milestones or new sub-features), or just response to user
feedback. We need the ability to iterate quickly, ship, then iterate
quickly some more.

Note that I don't mean we want to ship sub-par quality code earlier
and fix it later. I'm talking about shipping a kernel of a feature
which grows/changes over time.

Hope this gives you an idea of the direction we'd like to go in. I
think that Jetpack has the best potential for giving us features like
these, and that's why we're rooting for it.

Dan

> We've learned through experience with Sync, Personas, Account Manager,
> Panorama and F1 that front-end features developed outside of the
> Firefox team require massive refactorings/rewrites and long
> development cycles to transition from an add-on experiment to a
> feature in the core, and sometimes the feature doesn't land at all.
> Also, there can be friction between groups as issues of performance,
> quality, ownership, conflicting timelines and mismatched expectations
> crop up during these transitions.
>
> We need to reduce the friction and time that it takes to get these
> types of projects into Firefox.
>
> Currently both the Apps and Identity teams are using Jetpack as their
> development platform. Jetpack is fantastic for rapid prototyping but
> is targeted at lightweight add-on development, not ship-quality
> browser core features. It's also not in Firefox.
>
> The product road map for Apps and Identity is not specific about
> timeline, but says they're included in what the Web looks like in 24 -
> 36 months. Given the competitive atmosphere and the historical
> evidence for adding many months onto the schedule to get projects like
> these shipping in Firefox, I think we need to look at ways to reduce
> the time-to-integration for these kinds of projects.
>
> Maybe this means immediately putting resources behind embedding
> Jetpack in Firefox such that we can write core features on top of it.
> Maybe it means we ship new features as add-ons that are included with
> the release (killswitch, anyone?). Maybe it means we move these
> projects off of Jetpack and into the core at the earliest possible
> stage.
>
> But no matter when the code lands in core, we're still hampered by a
> fragile ecosystem: The mix of XUL/XPCOM/XBL/JS/CSS that we currently
> use for core feature development is powerful yet extremely
> regression-prone, and painstaking to develop against. Writing
> shippable code is only possible by specialists with experiential
> knowledge of a ton of undocumented code and a host of implicit
> behaviors that are impossible to predict.
>
> My vote is for embedding Jetpack inside of Firefox for use for
> developing core front-end features. Having a stable and sane pure-JS
> API layer to build new features against would:
>
> * make it easier to share code between desktop and mobile
> * ease integration of projects developed by external teams (and allow
> possible code-sharing there too)
> * ease contribution by volunteer developers, and ramp-up by new employees
> * allow e10s-ification of core features using the same mechanisms and
> patterns as add-ons
> * strengthen Jetpack by ensuring it's APIs are up to the level of
> stability and performance required to be in the core
>
> Sure, it wouldn't work for everything - we'd still have to dive under
> the covers for a bunch of things. Sure, we'll have to figure out a
> host of issues around the interplay between shipped-SDK and
> embedded-SDK. But I think it will allow front-end development to move
> faster and more effectively in the long term.
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Mike Shaver
In reply to this post by Blair McBride (Unfocused)
On Fri, Jul 29, 2011 at 1:11 PM, Dietrich Ayala <[hidden email]> wrote:
> We've learned through experience with Sync, Personas, Account Manager,
> Panorama and F1 that front-end features developed outside of the
> Firefox team require massive refactorings/rewrites and long
> development cycles to transition from an add-on experiment to a
> feature in the core, and sometimes the feature doesn't land at all.
> Also, there can be friction between groups as issues of performance,
> quality, ownership, conflicting timelines and mismatched expectations
> crop up during these transitions.

Sorry for not quoting the things I agree with or am directly
referencing; this thread got away from me.

We need to build on the platform that we tell others they should build
on.  That means HTML and it means Jetpack.  It will take time and
platform improvements to get there, but if it were easy everyone would
be doing it.  If HTML applications can't be localized well (which
would seem odd, since I see lots of localized web sites), then we just
need to fix that.  If you can't use a Jetpack to write the download
manager, we just need to fix that.  Every time someone writes XUL
instead of HTML, they're throwing away some leverage against our
mission (and against some of our other projects, like the services
we're developing and B2G).  Sometimes the right thing is to throw away
some leverage for the sake of expediency, but we need to change our
default mode from "XUL unless someone decides otherwise".

Prototypes are like writing a paper, not like writing the first chunk
of a product.  You learn things in the context of the paper's research
and then you figure out how to use those lessons in production code.
The things that make prototyping a good way to learn -- cutting
corners, solving only the problems that answer questions, simplifying
assumptions about security/scalability/etc. -- make them exactly the
wrong way to build towards a product.  Taking prototype code as the
basis of a product is a terribly false economy and we need to stop
doing it, IMO.

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Robert Kaiser
In reply to this post by Robert Kaiser
Alex Limi schrieb:
> On Tue, Aug 2, 2011 at 7:22 AM, Robert Kaiser<[hidden email]>  wrote:
>
>> Why from a UX side?
>
> Because most of the people that would/could contribute (including people on
> the UX team) have pretty deep knowledge of HTML/CSS — and occasionally JS —
> but XUL is too narrow in its focus, so it's unlikely that they'll ever pick
> that up, since it isn't a reusable skill.

OK, sounds good, still we need to do a lot of work to get HTML be really
in a usable state for that.

> PS: If you think the add-ons manager is alien-looking, that really has
> nothing to do with XUL vs. HTML. It's really not that hard to make a UI in
> HTML/CSS that looks "native", whatever your definition of native is.
> Performance, animations and effects are a different matter, and need to
> improve — but we're getting there.

Well, I know it has nothing to do with XUL vs. HTML, as it actually is
XUL and still looks like a amateur website to me instead of like
professional browser UI in a lot of pieces. I even have read comments
from a number of people who thought it was a website and therefore
didn't really trust what it said.

Robert Kaiser

--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Robert Kaiser
In reply to this post by Blair McBride (Unfocused)
Mike Shaver schrieb:
> We need to build on the platform that we tell others they should build
> on.  That means HTML and it means Jetpack.  It will take time and
> platform improvements to get there, but if it were easy everyone would
> be doing it.

I agree and we need to start working on it (actually I think we're even
late in some of it), but we're unfortunately not there yet. Should not
stop us to get there, though!

> Prototypes are like writing a paper, not like writing the first chunk
> of a product.

True, even though a good number of comments here sounded like they want
to make it easier for us to ship prototypes as products and quickly make
them into it.

Robert Kaiser

--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Dietrich Ayala
In reply to this post by Dan Mills-5
> First, I'm happy to see Jetpack being considered as a possible vehicle
> for feature integration. We (the Identity and Apps teams) have been
> able to iterate unbelievably quickly using Jetpack, while there are
> certainly areas for improvement I can't overstate how valuable it has
> been to us so far.

Can you talk about why this is? What characteristics of the framework
itself, or the development flow are so useful? Whether we bundle
add-ons, or embed Jetpack or do nothing revolutionary at all, this
would be really good to know.

> * We want to "dial up" feature deployment
>
> We'd like to be able to progressively deploy features based on
> criteria such as geographic area, language, or just to a percentage of
> users (e.g., have a knob where we can say "12% of users in France" and
> roll features out progressively).
>
> Using such a system we could also maintain regional sets of features
> on a permanent or semi-permanent basis. For example, the China team's
> Firefox build with bundled add-ons could be rolled out/maintained in
> this way.
>
> Websites do this all the time, and it's a huge advantage that we
> currently don't have.

In the short term, the idea of shipping a bunch of versions of Firefox
that are different from each other probably scares the living
daylights out of a lot of people. But the reality is that add-on
install numbers show that the Firefox that most people *have* is *not*
the one we shipped. And that's a reality we need to embrace.

However, I think this need is pretty far outside the scope of this
thread (which is overbroad already!). For now, what you want could be
done inside an add-on, or at least prototyped that way. Maybe spin up
a labs project around this idea? And get the conversation started with
a blog post or something that'll get project-wide input from all the
affected groups (QA, Support, RelEng, Automation, L10n, etc). An
all-hands session on this might not be a bad idea.

> * We need to iterate independently, on an ongoing basis
>
> Something that seems to get ignored is iteration *after* landing a
> feature. I don't mean maintenance, rather already-planned changes
> (further milestones or new sub-features), or just response to user
> feedback. We need the ability to iterate quickly, ship, then iterate
> quickly some more.
>
> Note that I don't mean we want to ship sub-par quality code earlier
> and fix it later. I'm talking about shipping a kernel of a feature
> which grows/changes over time.

We've done this to some extent with Personas and Panorama for example.
The add-ons manager is another example of a major feature that changed
pretty significantly over time.

However, there are very high costs to small changes to the core
product when your user-base is a half billion people. Talk to SUMO for
more information about this :)

Maybe what you want here is a world where we ship with these types of
add-ons pre-installed (Jetpack or not is irrelevant) and those add-ons
can iterate independently of the core browser.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Dietrich Ayala
In reply to this post by Blair McBride (Unfocused)
On Sun, Jul 31, 2011 at 7:26 PM, Blair McBride <[hidden email]> wrote:

> On 30/07/2011 5:11 a.m., Dietrich Ayala wrote:
>>
>> We've learned through experience with Sync, Personas, Account Manager,
>> Panorama and F1 that front-end features developed outside of the
>> Firefox team require massive refactorings/rewrites and long
>> development cycles to transition from an add-on experiment to a
>> feature in the core, and sometimes the feature doesn't land at all.
>> Also, there can be friction between groups as issues of performance,
>> quality, ownership, conflicting timelines and mismatched expectations
>> crop up during these transitions.
>
> In all of those cases, they started out as experiments and prototypes that
> added something on top of Firefox, and tried to directly transition to a
> production-ready feature. Shipping prototype code doesn't work. Jetpack is
> great, and it should be in Firefox - but it's not going to make prototypes
> shippable.

While the "ship my prototype" scenario has occurred, some of the teams
above were targeting Firefox directly, and definitely did not think of
their code as prototype code.

But the prototype scenario is peripheral to my main point. We need to
make Firefox development faster and less fragile for people in Firefox
team and outside of it.

The Identity team are developing a core Firefox feature, not a
prototype. We need to allow that kind of work to happen at web-speed.
Part of the solution is having them oriented around our shipping
requirements WRT performance, review, tests, etc. But another part is
making Firefox development not suck. Jetpack is a potential route to
the latter.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Firefox front-end features, time-to-market, and coordination.

Steve Wendt
In reply to this post by Dan Mills-5
On 8/8/2011 5:30 PM, Dietrich Ayala wrote:

> Maybe what you want here is a world where we ship with these types of
> add-ons pre-installed (Jetpack or not is irrelevant) and those add-ons
> can iterate independently of the core browser.

Note that this already happens with SeaMonkey.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
123