545489 - Get the BYOB firstrun page up to date with new Fx versions

Status: RESOLVED FIXED

(Websites Graveyard :: byob.mozilla.com, defect, P2)

Description

[Les Orchard [:lorchard]]

The custom first run page hosted by BYOB is currently copied from the original Firefox 3.5 first run page.  This needs updating for Fx 3.6 - and beyond that, this will be a constant maintenance issue.  

Most of the BYOB version is identical to the mozilla.com version except for one of the promo spots and possibly one or two other tweaks.  I wonder if there's some better way to integrate the BYOB first run page with the original version on mozilla.com?

Rather than continuing to maintain a duplicate copy, it might be interesting to consider modifying the mozilla.com firstrun page itself to include BYOB customizations switched on via query params.

Might be hairy security-wise if done wrong, but maybe the mozilla.com page could load some JavaScript from BYOB and make greasemonkey-style alterations to the page on the fly.  That would make the modifications to mozilla.com minimal, and allow lots of flexibility on the BYOB side.

Comment 1

[Kev Needham [:kev]]

Adding Neilio and Ken for thoughts/concerns/ideas.

I like the idea of adding this to the default first-run page. It ensures that metrics captures all of the first-run page requests, and that there is sufficient infrastructure to handle requests across multiple geographies. I think risks can be mitigated, and we could also consider passing an argument of "collection=id" or similar which would load the appropriate UI.

Ken, for additional info, we use a custom first-run that highlights a collection as a user option. You can see an example at https://byob.mozilla.com/profiles/chofmann/browsers/MxNDc0NjQ4OA/firstrun

Comment 2

[ken kovash]

One potentially awkward issue...

There's a good chance that the firstrun page will continue to change/evolve over time, i.e., the look and feel could be dramatically different in a few months as we're continuously running a/b concept tests on it.  How would we handle those types of future changes within the BYOB framework?

Comment 3

[Kev Needham [:kev]]

We could have use a bouncer entry instead, which would pass the arguments and force a load/redirect to a non a/b page. I can think of a couple ways to skin it, but we have the technology. Alternatively, do a little extra design work and make them part of the AB tests. Are we doing dramatic changes, or just repositioning of elements? if the latter, would be interesting to see if we could be part of it.

the collections customization is essentially a single element (although something we'd like to make sure is called out/brought to the attention of the affinity group user), so I think we could work within that framework. if it doesn't work, then a bouncer redirect or a small js snippet in the page which detects the argument and forceloads the non a/b page should be sufficient.

Comment 4

[ken kovash]

Yeah, I was more specifically wondering... if the page does look dramatically different three months from now (i.e., not just repositioning of elements, but an entirely new concept of the page), and again six months after that, how would you want to handle that process?

Comment 5

[Kev Needham [:kev]]

We're looking at alternative ways to make the links to collections a little more "sticky", but if we're looking at moving to local chrome for things like start and firstrun, I want to make sure that customizations are part of the design process for that, too. definitely something we should take a holistic approach to.   

maybe focus on 3.6 here, and ensure we bring customization of newer releases into a more holistic discussion, because there are definite implications for customized distros at a few levels.

Comment 6

[Les Orchard [:lorchard]]

Since an ultimate solution for this seems to be a little ways off yet, I think I might just try cloning the Fx 3.6 first run so we have something for the end of Q2.

Comment 7

[Kev Needham [:kev]]

At this pointI think that's best, but I will be taking this up with marketing. I haven't heard anyone think it's a bad idea, it's just a question of who's ultimately responsible for saying "ok".

Les, if you could clone 3.6 that'd be awesome, and I'll see if I can't get this going in parallel.

Comment 8

[Les Orchard [:lorchard]]

Did a quick copy / clone of the Fx3.6 first-run page for r68129.  But, some issues occurred to me along the way...

First, I'm not sure whether the Collections URL makes much sense in the new page.  What I did is this: 

* If a Collection URL is supplied, the lower right-hand promo cycle box is swapped out for a single non-cycling promo linking to the Collection URL.

I'm inclined to say that the Add-on Collection URL should be pulled out of the wizard and the first-run page now that we've got the addon management tab (bug 560896).  But, I'm not sure what the purpose of the custom first-run page is if we yank out the collection promo.

Second, there's potentially a big issue with WOFF fonts used in the page:

* The new Fx3.6 first run page uses some licensed WOFF fonts (eg. *not* open or free).
* These licensed fonts can't be cross-linked into our page (see bug 540859)
* Since the fonts can't be cross-linked, we'd need to copy them into our code base and implement the same hotlink prevention from bug 540859
* But, even with hotlinking speed bumps, I'm not sure if Mozilla is licensed to spread these fonts around to other sites like BYOB, even though they're being used for basically the same purpose (IANAL)

Comment 9

[Les Orchard [:lorchard]]

Actually, I just remembered bug 511869 (Make "Collections" link sticky), which sounds like maybe the thing we want added to first-run here is a psuedo-infobar at the top mentioning the collection rather than a non-rotating promo?

Comment 10

[Kev Needham [:kev]]

wrt comment #8

I'd like to keep the collections promotion if possible. We're going to limit the number of add-ons that can be included, and I'd still like to be able to promote collections in some form, which can link to several add-ons that are installed at the behest of the user, which will (hopefully) help with add-on discoverability. I think the infobar idea works well here, as we can put a little additional messaging around it.

For the font licensing, I'm adding Slater to the bug, as he's responsible for all things Meta, which I believe is the only licensed font we have. My understanding is we have a multi-site license, and if we can use one of those slots while we get integrated then we're ok (and if we're not, we'll purchase a license :) ).

Comment 11

[Les Orchard [:lorchard]]

(In reply to comment #10)

> I'd like to keep the collections promotion if possible. We're going to limit
> the number of add-ons that can be included, and I'd still like to be able to
> promote collections in some form, which can link to several add-ons that are
> installed at the behest of the user, which will (hopefully) help with add-on
> discoverability. I think the infobar idea works well here, as we can put a
> little additional messaging around it.

I have a single promo for the collection URL in the first run page now, though it could probably use some additional finessing.  I can also look into throwing together the infobar in HTML

> For the font licensing, I'm adding Slater to the bug, as he's responsible for
> all things Meta, which I believe is the only licensed font we have. My
> understanding is we have a multi-site license, and if we can use one of those
> slots while we get integrated then we're ok (and if we're not, we'll purchase a
> license :) ).

Cool... If/when we're okay to use the Meta font, I should be able to just check it in, uncomment the CSS include, and make sure the htaccess rules to deter hotlinking I copied over from mozilla.com work.

Comment 12

[John Slater]

(In reply to comment #10)
> For the font licensing, I'm adding Slater to the bug, as he's responsible for
> all things Meta, which I believe is the only licensed font we have. My
> understanding is we have a multi-site license, and if we can use one of those
> slots while we get integrated then we're ok (and if we're not, we'll purchase a
> license :) ).

That's correct - we have a license to use Meta on any Mozilla site we want.

Also, for reference, we had a pretty long conversation about how to implement this font on the 3.6 first run page...I'd advise skimming through bug 540859 to get caught up there.

Comment 13

[Kev Needham [:kev]]

Thanks for the additional info, John, much appreciated :)

Comment 14

[Les Orchard [:lorchard]]

r68231 should see the first run page start using the Meta font, and the .htaccess should be deterring hotlinking ala bug 540859

Still looking into adding an infobar for bug 511869, but I may close this one and stick progress on the infobar into that bug