Photon landing strategy

Dão Gottwald dgottwald at mozilla.com
Thu Mar 30 15:47:44 UTC 2017


2017-03-30 15:33 GMT+02:00 Mike Conley <mconley at mozilla.com>:

> Maybe I'm missing something, but I see the following advantages of this
> approach over using a project branch:
>
> 1) Easy one: we don't have to maintain a project branch! No periodic
> merging. Presumably less probability of having to deal with merge
> conflicts due to changes in mozilla-central. No having to watch multiple
> trees.
>

We'd still have to synchronize the fork with the backup and deal with
conflicts, no matter whether they both live in on branch or in two separate
ones.
That is unless you freeze the backup, but you could do that with a project
branch as well.

I'm not actually a fan of project branches. I think they can be quite
painful. I'm just not sure this is better.

jaws and I maintained the Holly backout branch during the development of
> the Australis theme, and I remember that being a bit of a pain.
>
> 2) Easy to manually turn on and off. Among other things, it will be
> easier for volunteer contributors to participate and try the new theme
> while it's being built, spot problems and file bugs against it (since
> they won't have to run a separate executable that updates on a different
> schedule).
>

Forking the theme into a second folder is one thing; making it so that it's
a theme that can be downloaded and installed is definitely not something I
want to deal with. It's overhead we don't need. As I understand it, we're
only talking about roughly six weeks here (the 56 cycle, since we'll
probably spend the rest of the 55 cycle on prep work), so I think we should
keep it simple.


> 3) Probably easy to programmatically turn on and off. I know that UR and
> UX is interested in doing experiments and science with the changes that
> we're making to ensure that we're actually making the browser experience
> better. Shipping it as a separate theme gives us the potential of
> turning it on temporarily for some subset of our user population to do
> A/B testing.
>

For this to work we'd have to maintain this cumbersome development model
through the 57 cycle, which sounds like a very undesirable side effect to
me. I'd rather we used 56 vs. 57 for A/B testing.

dao


> I'm not wholly against a project branch, but I think there are some nice
> advantages of writing it as a separate built-in theme that we should
> consider as well.
>
> But I'm also pretty easy going. Do what works. :)
>
> -Mike
>
> On 2017-03-30 4:42 AM, Dão Gottwald wrote:
> > It's quite possible. Could just be a different theme folder with a
> > build-time switch. However, I don't see how that's better than a project
> > branch. It seems like a different way to fork stuff with roughly the
> > same overhead due to having to synchronize it.
> >
> > 2017-03-30 0:04 GMT+02:00 Mike Conley <mconley at mozilla.com
> > <mailto:mconley at mozilla.com>>:
> >
> >     Hey folks,
> >
> >     Not sure if my suggestion got lost in the shuffle, or if it's
> >     malodourous / obvious enough that it didn't prompt reply, but would
> >     landing the appearance changes as a new complete theme be out of the
> >     question? I know we're tearing out the support for that stuff, at
> >     least for third-party extensions, but for this kind of theme
> >     development, it seems quite well suited.
> >
> >     Or am I wrong?
> >
> >     -Mike
> >
> >     On 29 March 2017 at 08:37, Dão Gottwald <dgottwald at mozilla.com
> >     <mailto:dgottwald at mozilla.com>> wrote:
> >
> >         2017-03-29 14:18 GMT+02:00 Gijs Kruitbosch
> >         <gkruitbosch at mozilla.com <mailto:gkruitbosch at mozilla.com>>:
> >
> >             On 29/03/2017 11:42, Dão Gottwald wrote:
> >>             2017-03-28 14:22 GMT+02:00 Gijs Kruitbosch
> >>             <gkruitbosch at mozilla.com <mailto:gkruitbosch at mozilla.com>>:
> >>
> >>                 On 28/03/2017 08:06, Chris Peterson wrote:
> >>
> >>                     It seems like some of the smaller visible UI
> >>                     changes could probably ship in 55/56 without
> >>                     needing a pref. Users probably won't notice some
> >>                     of the UI polish features until everything is into
> >>                     place in 57. Shipping these smaller bits in 55/56
> >>                     would give us more testing.
> >>
> >>                 Can you elaborate on this? What are "small visible UI
> >>                 changes" that users "won't notice"? I'm skeptical
> >>                 these even exists, looking at (for instance) things
> >>                 like
> >>                 https://bugzilla.mozilla.org/show_bug.cgi?id=1345989
> >>                 <https://bugzilla.mozilla.org/show_bug.cgi?id=1345989>
> >>                 . https://xkcd.com/1172/ comes to mind... And yes, of
> >>                 course these are extreme examples, but I'm also
> >>                 looking at the mockups I've seen and thinking I don't
> >>                 see anything that falls in the "small polish" category
> >>                 in our main theming & structural changes.
> >>
> >>
> >>
> >>             You're reading Chris too literally.
> >             I fail to understand what is "literal" about my reading and
> >             how yours is less so, and I'm disappointed that you're
> >             turning an honest question into "you're (reading it) wrong".
> >
> >
> >
> >         No need to take it personally, I was just trying to answer your
> >         question. Clearly, there is no UI change that is guaranteed to
> >         go unnoticed with every single user. Reworded as "most users
> >         won't notice", are you still skeptical that such changes exist?
> >
> >
> >>             We're not trying to make it look like there were no
> >>             changes at all between 54, 55 and 56, but the changes
> >>             shouldn't particularly stand out and take away from Photon.
> >>
> >>             <snip>
> >>             For the visual refresh, I'm trying to be smart and divide
> >>             the work into parts that can be tackled early and parts
> >>             that should wait. Nihanth is going to start with
> >>             integrating our new SVG toolbar button icons in bug
> >>             1347543 -- this should land when it's ready (I've checked
> >>             with shorlander, he's fine with this)
> >
> >             I wouldn't have thought that changing the icons over to the
> >             Photon icon set would be something we'd do before 57, as
> >             that's pretty noticeable.
> >
> >             (To be clear, I'm not arguing that we shouldn't do this
> >             stuff prior to 57 if people are on board with it, but to me
> >             this is a surprising example of "small changes".)
> >
> >
> >
> >         From what I've seen the icons are a bit sharper and thinner, but
> >         in the grand scheme of things it's a rather subtle and
> >         incremental change.
> >
> >         dao
> >
> >         _______________________________________________
> >         Photon-dev mailing list
> >         Photon-dev at mozilla.org <mailto:Photon-dev at mozilla.org>
> >         https://mail.mozilla.org/listinfo/photon-dev
> >         <https://mail.mozilla.org/listinfo/photon-dev>
> >
> >
> >
> >
> >
> > _______________________________________________
> > Photon-dev mailing list
> > Photon-dev at mozilla.org
> > https://mail.mozilla.org/listinfo/photon-dev
> >
> _______________________________________________
> Photon-dev mailing list
> Photon-dev at mozilla.org
> https://mail.mozilla.org/listinfo/photon-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/photon-dev/attachments/20170330/9a5360cd/attachment-0001.html>


More information about the Photon-dev mailing list