Photon landing strategy

Justin Dolske dolske at mozilla.com
Fri Mar 31 21:30:10 UTC 2017


At a high level, sure. Using the themes mechanisms as a way of "preffing"
Photon isn't something I would outright object to.

But a few concerns/notes:

* I think the alternative is not a project branch (which I don't hear
anyone advocating for, so let's consider that Not An Option), but rather
options like ifdefs, jar.mn hacks, prefs, etc.

* I'm wary of the optics and lurking technical issues that may come up as
we move towards removing support for complete themes for 57. I'd hate to
footgun ourselves by relying on a mechanism that we're actively working to
deprecate.

* I don't think ease of enabling/disabling for users is a goal -- Photon
bits, as they land, should be enabled for Nightly 55, 56, and the 57 train.
Testing on not-Nightly 55/56 isn't interesting, as that work will rapidly
become out of date. Any UX/UR testing will need to happen with Nightly
builds. But that does raise an interesting point, in that some parts of the
Photon work may want to temporarily land in a disabled state, until they're
up to Nightly quality. For example, the menu/structure work is pretty big
and complex, and I can see there being a period of time where it's starting
to land but not ready for even Nightly users to start using. I don't think
we'd want to further fork the theme just to do that.

* In lieu of a clear best-approach at the outset, I'd suggest starting
simple (i.e. ifdefs), and only move to more involved schemes if we find
that's becoming unmanageable. Unless it's blindly obvious to everyone else
that this will quickly fall apart, in which case let's talk more. :) I'm
assuming ifdefs will be ugly but tolerable, we might need to carefully fork
a few files, but that a full-on theme fork is overkill.

Justin

On Thu, Mar 30, 2017 at 6:33 AM, Mike Conley <mconley at mozilla.com> wrote:

> 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.
>
> 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).
>
> 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.
>
> 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/20170331/e160a7d1/attachment-0001.html>


More information about the Photon-dev mailing list