Closed Bug 502029 Opened 11 years ago Closed 10 years ago

Update the new start page template from bug 492536

Categories

(support.mozilla.org :: General, defect)

defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: paulc, Assigned: paulc)

References

()

Details

(Whiteboard: sumo_only)

Attachments

(2 files)

Now that the test for the start page template has passed, we need to make a few changes to the current template and push it out on SUMO as the new start page.

This is a tracking bug for the various other bugs related to the update.
Depends on: 494083
Depends on: 502025
Blocks: 499160
An interesting fix to note here, if we want rounded corners for the buttons, here's a cross-browser way of doing it:
http://thecssblog.com/tutorials/creating-rounded-corners-the-deviant-arts-way/

I believe our current implementation only shows rounded corners for Gecko-based browsers.
Depends on: 507509
It doesn't look like we're going to get this in as a landing page before School of Firefox...
The two big things that we need to figure out:

* Currently, the New to Firefox box is part of the wiki body of the page itself, making it very trivial to update it. This new template has it as part of the template (not the wiki body), making things more complicated for e.g. localizers. Can we make this part of the wiki body and still have it in the sidebar with some CSS magic?

* The example search terms under the search box. Ideally, this would be automatically updated based on the most common search terms in Omniture, but that will no doubt be very complicated in the short term. How can we make it relatively simple to update? Would a dynamic content block do the trick? The question would then be how that would work with localization. Maybe having a dynamic content block where localizers need to translate the suggested search terms manually would be an acceptable solution if we can aim for a more automatic long-term solution in the future.
(In reply to comment #3)
> The two big things that we need to figure out:
> 
> * Currently, the New to Firefox box is part of the wiki body of the page
> itself, making it very trivial to update it. This new template has it as part
> of the template (not the wiki body), making things more complicated for e.g.
> localizers. Can we make this part of the wiki body and still have it in the
> sidebar with some CSS magic?
We can. I'm not sure how hard that would be yet, but I'll look into it.
> 
> * The example search terms under the search box. Ideally, this would be
> automatically updated based on the most common search terms in Omniture, but
> that will no doubt be very complicated in the short term. How can we make it
> relatively simple to update? Would a dynamic content block do the trick? The
> question would then be how that would work with localization. Maybe having a
> dynamic content block where localizers need to translate the suggested search
> terms manually would be an acceptable solution if we can aim for a more
> automatic long-term solution in the future.
Dynamic content blocks are localizable. This needs to be tested - but I think that each locale can have their own content block to replace the english one, and put whatever they want in it. So it would have to be manually updated for a while.
The Firefox+Help+4 page was removed, and copy on support-stage erased by a recent sync with prod. I managed to find another copy of it on prod: <https://support.mozilla.com/en-US/kb/bug+502025+test>
Chris, can you attach the wikimarkup for it to this bug?
Oh, so the fancy boxes etc are done in the template?  How are they localized?
We may change that... Right now they could be localized because the strings are passed through {tr}, but it's not the best way for localizers...
(In reply to comment #9)
> We may change that... Right now they could be localized because the strings are
> passed through {tr}, but it's not the best way for localizers...

The "New to Firefox" (also known as the "generic blurb box") on the right should definitely be part of the wiki body. This is what's needed before we can roll out the new start page.
Target Milestone: 1.4 → 1.5
Target Milestone: 1.5 → 1.4.2
Attached patch v1Splinter Review
This patch makes the search terms configurable PER LOCALE with a content label. English is the backup if no search terms are set for that locale.

To test this, create the content label named "HomeSearchTerms" and add programmed content to it in the format of one search term per line.


David, making "New to Firefox" part of the wiki page poses difficult problems. I wasn't sure how to do it, so I asked James, and he'll be more than willing to explain why we should try to find other approaches instead.

I believe that with this patch we are ready to make the start page go live. I'll take a look at the IE6/7 layout issue as well.
Attachment #406541 - Flags: review?(james)
Can you explain how to go about localizing the search terms?
When creating a content label, you have the option of selecting a language for it (defaults to English). Note the "Language" field at tiki-list_contents.php
Depends on: 522618
Attachment #406541 - Flags: review?(james) → review+
Comment on attachment 406541 [details] [diff] [review]
v1

Works for me, though I'm not really thrilled about the extra queries in the worst-case, which I think will be fairly common.
(In reply to comment #4)
> > * Currently, the New to Firefox box is part of the wiki body of the page
> > itself, making it very trivial to update it. This new template has it as part
> > of the template (not the wiki body), making things more complicated for e.g.
> > localizers. Can we make this part of the wiki body and still have it in the
> > sidebar with some CSS magic?
> We can. I'm not sure how hard that would be yet, but I'll look into it.

Since Paul passed the ball off to me in comment 11: This really isn't possible. You can't use CSS to take a block (the "New to Firefox" section) and move it from it's parent block (the wiki content) into the flow of another block (the sidebar). It could be absolutely positioned, but any change to the content would probably require a CSS change (and thus a push) anyway.
(In reply to comment #14)
> Works for me, though I'm not really thrilled about the extra queries in the
> worst-case, which I think will be fairly common.
Is it possible to ORDER BY in SQL somehow to put english last? I'm thinking we could get English + current_locale, have at most 2 rows in the result but only look at the first - which would be that locale when available, and English otherwise. James?
It should be possible in a single query/row with an IF statement.
Can a module contain a content block?
(In reply to comment #18)
> Can a module contain a content block?
Say, a sidebar module like the small search? I believe it can, yes.
(In reply to comment #15)
> Since Paul passed the ball off to me in comment 11: This really isn't possible.
> You can't use CSS to take a block (the "New to Firefox" section) and move it
> from it's parent block (the wiki content) into the flow of another block (the
> sidebar). It could be absolutely positioned, but any change to the content
> would probably require a CSS change (and thus a push) anyway.

Understood about the CSS limitations, but the purpose of that "New to Firefox" box was to be able to customize it depending on e.g. where people are coming from, by setting up different versions of the start page. For example:

* A "New to Firefox" box for the generic start page
* A "Popular Windows 7 topics" for people recently installing Firefox from the browser ballot (I'm making this up)
* ...and son on

So, how can we still make sure this box isn't a static list of stuff, because we really don't want that. Making it a content block solves the problem of not being able to change the contents of _one_ hardcoded "New to Firefox" box, but how can we make sure we can point to an entirely different content block for another start page? Will we have to set up separate templates for each start page version?
Sort of inspired by Chris' question, we can use different content labels for each of those situations, and decide in the template which content label gets displayed. E.g. from your comment 20, this decision would initially be based on OS (which we can find in the UA string).
But that's still hardwired and requires a push to change, which isn't ideal. Anyway, it's definitely more important to get this new start page out now rather than waiting for the perfect solution, but it would be nice if we could figure out a better solution for the future.

For the record, I can only really think of a few start page scenarios:

* Normal start page (show "New to Firefox?")
* in-product start page (show something else?)
* Windows ballot start pages (show windows specific info?)

So even if it boils down to having to hardcode specific content blocks to specific templates, I guess we could live with it. It just wouldn't be as flexible as one would want (especially considering p12n).
r54606 (trunk)

Chris, you can create the content label named HomeSearchTerms now. Make sure to set it to English language.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Verified, FIXED.
Verified on:
- Win XP:
    IE 6
    IE 7
    Fx 2.0,3.0
- Win Vista
    IE 8.0
- Mac 10.5
    Fx 3.5
    Safari 4
- Linux
   Fx 3.5
Status: RESOLVED → VERIFIED
r54789 (prod), r54790 (fennec)
Just want to make sure I have my info correct: We're switching to this for both the inproduct start page and the website start page, right?
(In reply to comment #26)
> Just want to make sure I have my info correct: We're switching to this for both
> the inproduct start page and the website start page, right?

Good question: https://support-stage.mozilla.org/en-US/kb/New+Home+Page?style_mode=inproduct looks good, too.
Should I create a content block for "New to Firefox", or leave the module as is for now? I've been wanting to test it on stage, but https://support-stage.mozilla.org/tiki-admin_modules.php?um_edit=promotebox has been timing out every time I try for the past 2 hours.
If I turn on interactive translation, I see a small circle after the heading "New to Firefox?". Does that mean the heading isn't part of the content block?
I'm pretty sure that a content block is not currently being used in the "New to Firefox" module. (The version on prod isn't.) We can make text in modules translatable by putting {tr} tags around them.
Whiteboard: update start pages after push
Whiteboard: update start pages after push → update start pages after push, update contributor docs
Switched on prod!!
Whiteboard: update start pages after push, update contributor docs → sumo_only
You need to log in before you can comment on or make changes to this bug.