Closed Bug 555098 Opened 14 years ago Closed 14 years ago

design new version of Firefox first run page

Categories

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

Product:
www.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jslater, Assigned: sgarrity)

References

(
URL
)

Details

Attachments

(6 files)

Firstrun - Option 1
338.79 KB, image/png
Details
Firstrun - Option 2
394.75 KB, image/png
Details
Firstrun - Blade 1 - Personas
478.25 KB, image/jpeg
Details
Firstrun - Blade 2 - Add-ons
492.36 KB, image/jpeg
Details
Firstrun - Blade 3 - SUMO
438.57 KB, image/jpeg
Details
scroll bar in personas blade
318.87 KB, image/png
Details 
Hi Sean. I know we've already talked about this, but I figured I should follow the right process and make it official by filing a bug.

The goal is to create an updated First Run page that incorporates the best elements and/or functionality from the winning test referenced in bug 554655 with a more polished design and content that's more consistent with what's on the current live page.

Once we have that, the plan will be to implement a new version and then continue testing various refinements to increase the success of the page.

Also, just for the sake of getting it on the record, here's the email I sent Sean on Monday with additional content & design direction:

"In terms of both the visuals and content, you can start from the current live version and then integrate details and/or functionality from the test (to varying degrees). The whole task-based element of the test works well, I think, as it makes things like adding personas or add-ons feel like the logical next step now that you've installed Firefox rather than promotional items, but of course there are more elegant visual ways to do it than what we have now. 

I'd also love to play around with a version that's a little more plain and simple than the live one (b/c again, even though it's not my personal style I think the directness of the test version probably helped it do well) while still making it modern and beautiful. Chris even suggested keeping the current page exactly as is but testing it with slight modifications like removing the colorful background from the personas section.

That's the basic gist of it. I know you have ideas too, so definitely feel free to run with those. I can definitely find time for a conversation tomorrow if you want to talk about it or ask questions live. In the meantime, here are some other thoughts that Chris and I discussed:

- as noted above, the content on the current page is the best starting point. For example, for a version that keeps the discoverable add-ons section like we have in the test would be cool, but we should be promoting the same add-ons that are being rotated on the live page (fwiw, the test version was created before we started the add-ons rotation).

- engagement buttons or links (to FB or Twitter at a minimum) are really important and should be on all test versions. As we continue to tweak this page, we'll probably want more of this sort of thing rather than less.

- as an option on one of the versions, we could try a "no thanks, just take me to the web" button that directs people straight to the start page. (the button doesn't have to be front & center, but it'd be interesting to see how it does.)

- speaking of the start page, we shouldn't have any links that promote changing it (like we do on the test).

- the current live page probably has too many links...how can we simplify?"
Attached image Firstrun - Option 1 — 
- I brought the promo into the last blade, we can style it up however we'd like in there - almost a mini landing page if we wanted.
- the 3rd blade could be totally randomized, the top 2 blades housing the top 2 browser features we want to showcase.
- support now has a full promo
- social networks back at top
- Personas section revisited
- removing the promo from the right and graduating support cleans up that side quite a bit - overall this looks much, much cleaner than the current implementation.
- 3 focused sections now ( featured content blades / social networking / support )
Attached image Firstrun - Option 2 — 

    
    

    
  
Awesome, thanks Sean. I think option 1 is looking particularly good...my vote is to finalize the content on that and then roll it out.

A few thoughts on finalizing the content:
- we'll need to work through what goes on the add-ons panel. Maybe change the copy too? (at the very least, we may want to test alternate lines instead of "more ways to personalize")
- similarly, we'll need to work through what goes on the 'sync bookmarks and more' panel. Blake, based on the tests do you have any insights as to what would be the most useful and/or compelling there?
- also, I'd like to try a test where we have the rotating AMO promos back in the right column and put the "need help?" in the panel/blade area.

Other thoughts? Unless there are any major objections, I'd like to work with Sean to get the content finalized here and then get the page built.

    
    

    
  
John -- perhaps you, Sean, and Blake should meet to talk through the new page and ensure that we'll still capture some of the benefits discovered with our original insights.

    
    

    
  
Oh, and is this content for the whatsnew page or firstrun page?  Have we had a chance to figure out our goals for the two distinct user experiences?  And if not, can we do so before pushing any new content live?

    
    

    
  
Very nice, I really like option 1 too.

Since SUMO has a permanent spot in this design, does that mean we could get rid of our special case for Browser Choice builds?  

(aiui, we added these pages so that we could have a SUMO promo for those builds, bug 546525)

e.g.
http://www.mozilla.com/en-GB/firefox/3.6/firstrun/eu/

    
    

    
  
(In reply to comment #4)
> John -- perhaps you, Sean, and Blake should meet to talk through the new page
> and ensure that we'll still capture some of the benefits discovered with our
> original insights.

Definitely. I'll set something up, although I'd also like to note for the
record that this page was designed with the goal of capturing those benefits.
So, hopefully it's not too off the mark there.

(In reply to comment #5)
> Oh, and is this content for the whatsnew page or firstrun page?  

We've been talking about this wrt to the first run page in particular, but when
we talk with Blake we'll discuss what's new as well. 

> Have we had a
> chance to figure out our goals for the two distinct user experiences?  And if
> not, can we do so before pushing any new content live?

No, that's a longer and more complex discussion, especially given that we'll
soon be able to serve what's new content in a variety of ways depending on the
release (such as a ribbon at the top of the screen instead of a full page, for
example). That's an important discussion to have, but I don't think it needs to
hold up any improvements we can make in the short term. Let's just keep
iterating.

(In reply to comment #6)
> Since SUMO has a permanent spot in this design, does that mean we could get rid
> of our special case for Browser Choice builds?  

That sounds like a good idea to me, but I'd advise seeing how this page performs before making that final call. We should also loop Patrick & Tenser into the discussion.

    
    

    
  
Hey Sean (and all). As a quick update, Blake and I met this morning about making sure this page is incorporating as many of the positive factors from the tested version as possible. We'll probably want to make a few more tweaks early next week when you're in MV (such as adding a search field to the SUMO promo, and finalizing the other main panels as discussed), but we're pretty close. No sweeping changes at this point.

Thanks again for the good work, and we'll talk more when you're out here.

    
    

    
  
After talking with Sean yesterday, he hopes to get to work on this stuff on Wednesday so that we'd have something for the end of the week.

    
    

    
  
Why is that not in the mozilla.com component?

    
    

    
  
(In reply to comment #10)
> Why is that not in the mozilla.com component?

Probably because it was a task for Sean, technically a Labs designer.  I agree, it does make more sense in the mozilla.com component, moving.
Component: Design → www.mozilla.com
OS: Mac OS X → All
Product: Mozilla Labs → Websites
QA Contact: design → www-mozilla-com
Hardware: x86 → All
Target Milestone: -- → ---

    
    

    
  

      
      
      
      

        Attached image
          
        Firstrun - Blade 1 - Personas
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached image
          
        Firstrun - Blade 2 - Add-ons
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached image
          
        Firstrun - Blade 3 - SUMO
        — 
      

    


  

    
    

    
  
Above 3 attachments based on feedback over the past weeks, blending blade menu system + support links with current Firstrun design layout.

    
    

    
  
Thanks Sean!  Re-assigning to Steven G. to get this built.
Assignee: smartell → steven

    
    

    
  
(In reply to comment #15)
> Above 3 attachments based on feedback over the past weeks, blending blade menu
> system + support links with current Firstrun design layout.

Thanks Sean - looks great! Could you also post the PSD here? I'm sure Steven will need that in order to build the page.

Steven, one other note - although the mockups show the StumbleUpon promo in the lower right, that area is the same as what's on the live site now...several promos rotating (so no changes to that area, in other words).

    
    

    
  
(In reply to comment #7)
> > Since SUMO has a permanent spot in this design, does that mean we could get rid
> > of our special case for Browser Choice builds?  
> 
> That sounds like a good idea to me, but I'd advise seeing how this page
> performs before making that final call. We should also loop Patrick & Tenser
> into the discussion.

Remember that the EU ballot page links to a different start page customized for Windows users: https://support.mozilla.com/en-US/kb/Windows+start+page. 

Based on my limited understanding of these tests, I agree that it'd be a good idea to incorporate all the improvements proposed here for the EU build page as well, but we need to make sure that the EU page's support link still points to the Windows start page and not the normal SUMO start page.

(Thanks Stephen for cc'ing me to this bug!)

    
    

    
  
What's the interaction like for these pages? They look good statically, but I fear we're all making some assumptions about how they react to mouseOvers, clicks, etc.

For example, I'd rather that we reduce the requirement for user-clicks, so if possible, I'd love the "blades" to expand/collapse on mouseIn and mouseOut.

    
    

    
  
Hey Mike:  

The page design and interaction comes from the A/B testing we did on some concept pages last quarter.  This interaction performed the best, even beating out the current page design.  Blake can give more details if you'd like.

    
    

    
  
I know where the design comes from, yes. There is no interaction described in this bug, in any of the mockups, or in bug 553655 - just static mockups. 

http://www.mozilla.com/en-US/firefox/3.6/firstrun/d/ requires that users click to expand/collapse a blade - are you saying that is the only interaction design we're going to consider? Did we test alternatives like auto-expansion?

Further, bug 553655 comment 0 is a little unclear - interaction increased, but how are we measuring interaction? If by click-count, I'd expect it to increase, since you need to click to expand the sections. I'd expect any kind of interaction with the page to increase, as we've increased the surface for interaction (added sections, reduced visual complexity, etc).

I think the visual design is fine, as is the reduction of complexity. I think that we haven't really thought about the interaction between user and content, though.

    
    

    
  
Mike, I can't speak to the metrics used to measure 'interaction' (or even whether 'interaction' is something worthwhile on a page like this). However, I don't think an auto-expanding (on mouseover) interaction would work in this case.

If you wanted to see the contents of the third "blade" (awesome word, will use henceforth) and your cursor was at the top of the page, in trying to move toward the third blade, you would traverse the first two, causing a moving-target situation.

That said, I'm all for improving the interaction in any way possible.

The design that Sean has created (slick, as always) will be relatively easy to implement given the infrastructure we have in place (we've got the JS to do the open/close elements), and since it's a first-run page, we can rely heavily on CSS3 for corners, gradients, and shadows - so we can really cut down on the number of images used. So, it is probably worth building this out and seeing how it works.

Measuring/testing different interaction schemes on a page like this would probably require more than A/B testing - perhaps live user-testing.

    
    

    
  
(In reply to comment #22)
> Mike, I can't speak to the metrics used to measure 'interaction' (or even
> whether 'interaction' is something worthwhile on a page like this). However, I

Well, an increased amount of "interaction" was the metric by which a page design was declared a winner in bug 553655, so I'd hope that it's considered to be worthwhile.

> If you wanted to see the contents of the third "blade" (awesome word, will use
> henceforth) and your cursor was at the top of the page, in trying to move
> toward the third blade, you would traverse the first two, causing a
> moving-target situation.

There are accordion UIs that surmount these problems, but we don't need to debate it here, I don't think. The question I asked was whether or not we tested these alternative interaction mechanisms, and it's been answered: we haven't.

> open/close elements), and since it's a first-run page, we can rely heavily on
> CSS3 for corners, gradients, and shadows - so we can really cut down on the
> number of images used. So, it is probably worth building this out and seeing
> how it works.

Yes, agreed; nothing I've asked should stop the development of the page. Everything I've asked about is JS event processing which we can layer on top of the actual HTML/CSS.

    
    

    
  
The plan for these pages is to always be testing variants of whatever the current design is, whether those variants involve content, layout, interaction, etc. So testing some alternate interaction methods would be great...Blake, can you work that into the plan?

I don't think it's really accurate to say that interaction wasn't even considered as part of this process, but don't see much point in debating that. For now, let's get this page implemented and continue testing on it.

    
    

    
  
(In reply to comment #24)
> I don't think it's really accurate to say that interaction wasn't even
> considered as part of this process, but don't see much point in debating that.
> For now, let's get this page implemented and continue testing on it.

I asked if it was considered, and so far, nobody's answered me. You're implying that it was considered, which is an answer of sorts, I suppose.

I'm not sure why there are defensive reactions here. I'm trying to help improve this page, and am asking specific questions:

 - what user interactions have been considered aside from "click-to-expand"?
 - how did we measure "interaction" as referenced in bug 553655 comment 0?

    
    

    
  
> 
>  - what user interactions have been considered aside from "click-to-expand"?

Mike, here were the pages we tested:
http://www-trunk.stage.mozilla.com/en-US/firefox/3.6/firstrun/a/
http://www-trunk.stage.mozilla.com/en-US/firefox/3.6/firstrun/b/
http://www-trunk.stage.mozilla.com/en-US/firefox/3.6/firstrun/c/
http://www-trunk.stage.mozilla.com/en-US/firefox/3.6/firstrun/d/ (optimized version of A).

All of these versions have some sort of click interaction. 

I think, and Blake please correct me if I'm wrong, we wanted to test for page interaction (and call increased interaction a success) because there was a hypothesis that people bounce quite quickly off the page without actually taking in any of the information displayed.  The idea was that asking users to click through the page elements might result in more engagement with the information (ie, actually reading and understanding what we're promoting as opposed to just glancing and clicking through.)

The other reason for using these kind of  interactions was necessary for us to understand what kinds of content people are interested in (for the page). We found it difficult to measure interest in content without the click events, and having those click troughs gives us a better understanding of what people want to learn about as they got to the page. 



>  - how did we measure "interaction" as referenced in bug 553655 comment 0?

    
    

    
  
Final PSD version can be found here: http://mozilla.seanmartell.com/firstrun/firstrun_3x_revised_final.psd

Enjoy!

    
    

    
  
Should this page be implement in place over the existing first-run page, or should it be setup as a new page to be tested along-side the existing page?

    
    

    
  
It should replace the current First-Run Page.

    
    

    
  
Note that if this replaces the firstrun page and you want that to be localized, that means several weeks to have all of our 75 locales, I see there addon boxes in blade 2, if we have to localize that I expect some localizers to want to choose the add-ons that appear there for add-ons that are localized themselves in their languages and that they think is valuable to their audience (-> productization work).

    
    

    
  
You can hold off l10n on this page for now...I'd like to see how it does in en-US before committing to that level of work.

    
    

    
  
(In reply to comment #25)
>  - what user interactions have been considered aside from "click-to-expand"?

Afaik, none.  
Can we try this in a future test?  
What would you like try?  (expand on mouseover, auto-open on time interval?, ?)

How do we measure which works better?  Tracking which sections were opened?  For how long?  Whether they interacted with the blade content (e.g. previewed persona, installed add-on, etc) ?

>  - how did we measure "interaction" as referenced in bug 553655 comment 0?

Blake?  This would be a good thing to document when the test is designed.  We measured how many clicked on a persona image (roll-over was disabled in the tests), and what else?

    
    

    
  
Sorry for the delayed response here.  Given that we were never able to nail down concrete goals for the First Run page, we evaluated success by the following metrics:

Variation vs. Control
---------------------------
Average time on site: 17.5% higher 
Personas previews & gallery views: 22% higher (8.3% vs. 6.7%)
Add-on downloads: 122% higher (1% vs. 0.45%)
Bounce Rate: 2.8% lower (88.7% vs. 91.3%)
Support articles & search: (1.1% vs. 0.1%)
Video: (0.2% vs. 0.3%)
Social media: (N/A vs. 0.9%)
Tab interactions: (8.2% vs. N/A)
Interactions per user (excluding tabs): 15.5% higher

In nearly every metrics (expect social media, which we neglected to include), the task oriented variation performed significantly better.  Again, these numbers do not tell the full story.  But, taken together, they point to a winner.  I'll be sure to communicate our experiment findings more clearly in the future.  

For our next experiments, it would still be helpful to more precisely define what we're looking for (i.e. what is the relative value of social media integration vs. Personas previews vs. Add-on installs).

    
    

    
  
Should the first section be open by default, or should all three be closed by default?

    
    

    
  
The first section should be open by default. Thanks!

    
  
Depends on: 561821

    
    

    
  
Quick update: I've got this page mostly implemented. Should be ready for review later today (tomorrow at the latest).

    
    

    
  
I've committed this new page implementation in trunk (r66533). The persona previews don't look right yet (scroll bar, incorrect wrapping, styles), but that'll be fixed with bug 561821.

A few notes on the implementation:

1. The design included a change in font size of the blade titles between closed and open states. This caused an unpleasant jump in practice. I've used a single font size, somewhere in between the open/closed sizes from the mockup. Feedback is welcome on this.

2. I kept the footer links ("More Firefox 3.6 Features" and "Firefox Support") that were in the current firstrun page, but not this mockup. Let me know if these should go.

3. Since this page is targeted at Firefox 3.6 only, I've relied heavily on CSS3 for button/box styles to avoid the overhead of extra images.

4. For those elements that did require images, I've used the data URI scheme to embed the smaller images directly in the CSS file to further reduce HTTP requests.

Preview here: http://www-trunk.stage.mozilla.com/en-US/firefox/3.6/firstrun/

    
    

    
  
(In reply to comment #38)
> 1. The design included a change in font size of the blade titles between closed
> and open states. This caused an unpleasant jump in practice. I've used a single
> font size, somewhere in between the open/closed sizes from the mockup. Feedback
> is welcome on this.

Font size looks OK to me. The single use of a serif'd font on the page (in the Thunderbird callout) ends up looking out of place, though.

> 2. I kept the footer links ("More Firefox 3.6 Features" and "Firefox Support")
> that were in the current firstrun page, but not this mockup. Let me know if
> these should go.

I think that they can and should go; this page is already a little bit noisier than the one that won the test bakeoff, and I believe that we should be reducing click targets to focus interaction on the areas that we want people to interact with.

> 3. Since this page is targeted at Firefox 3.6 only, I've relied heavily on CSS3
> for button/box styles to avoid the overhead of extra images.
>
> 4. For those elements that did require images, I've used the data URI scheme to
> embed the smaller images directly in the CSS file to further reduce HTTP
> requests.
> 
> Preview here: http://www-trunk.stage.mozilla.com/en-US/firefox/3.6/firstrun/

Check your assumptions there - not sure that CSS renders quicker than images. Have you tested?

    
    

    
  
(In reply to comment #39)
> Font size looks OK to me. The single use of a serif'd font on the page (in the
> Thunderbird callout) ends up looking out of place, though.

Turns out this is a sans-serif font in the mockup - I just missed it (that feature was re-used from the previous firstrun page. Will fix.

> Check your assumptions there - not sure that CSS renders quicker than images.
> Have you tested?

I have not done any format testing - I'll see what I can do. That said, HTTP requests are generally the biggest killer for us.

    
    

    
  
Georgia font cleaned up in r66535.

    
    

    
  
> 1. The design included a change in font size of the blade titles between closed
> and open states. This caused an unpleasant jump in practice. I've used a single
> font size, somewhere in between the open/closed sizes from the mockup. Feedback
> is welcome on this.

When designing the blade system, I was under the assumption that when you clicked on another blade, the current one would collapse so that you only saw one open at a time.  As is now, it looks odd that the open blades have drop shadowing at the top and bottom edges when they aren't bordered by the elevated white blades. If they were to collapse, that would solve the drop shadow issue as well as the text sizing concerns.

    
    

    
  

      
      
      
      

        Attached image
          
        scroll bar in personas blade
        — 
      

    


  
A few thoughts from me:
- I agree with Sean (comment #42) that we should only have one blade open at a time. 
- I agree with Mike (comment #39) that the features & support links in the footer can go (particularly b/c we have a full support blade now).
- I'm not sure if it's just me, but I'm seeing a vertical scroll bar in the personas blade. We should definitely fix this...surely there's a way to show all 6 personas without having to scroll, right? In case it is just me, I've attached a screenshot so you can see what it looks like.

Thanks Steven!

    
    

    
  
Are we considering performance at all?  As is, this page will load very slowly and could give users a poor first impression of Firefox.

    
    

    
  
Some stats from webpagetest.org (using IE 7 w/DSL connection):

Load time: 8.850s
Start render: 4.611s
Video: http://www.webpagetest.org/video/view.php?id=100428_8452.3.0
URL: http://www-trunk.stage.mozilla.com/en...

    
    

    
  
I've been careful to implement the page with performance considerations in mind. Further improvements could be made, but they'd be the same type of improvements we need to make across the entire site.

Though I haven't done any comprehensive testing, this page does have fewer HTTP requests and a small overall file size than the page it is replacing.

    
    

    
  
We've got the expanders opening one-at-a-time now (r66598) and a few style tweaks in r66603. The resizing of the title fonts still causes a bit of a wacky jump on even when only one blade is open at a time (I can show that if anyone is interested), so the title fonts are the same size for now.

We're still waiting on the iframe updates to get pushed to production on getpersonas.com (Bug 561821).

I presume we'll be applying this design to the whatsnew page too? If so, I'll file a bug to track that.

    
    

    
  
(In reply to comment #47)
> 
> I presume we'll be applying this design to the whatsnew page too? If so, I'll
> file a bug to track that.

That is correct, and it would be very helpful if you could file that bug. Thanks!

    
    

    
  
Filed Bug 562686 for the whatsnew version.

    
    

    
  
As Bug 561821 is closed, the persona previews are now working as they should (thanks Ryan).

    
    

    
  
I think we're ready for QA on this page.

    
    

    
  
(In reply to comment #51)
> I think we're ready for QA on this page.

The vertical scrollbars in the Personas "blade" (comment 43) still isn't fixed.

    
    

    
  
(In reply to comment #52)
> The vertical scrollbars in the Personas "blade" (comment 43) still isn't fixed.

Sorry about that - I missed a commit - r66864 fixes the persona preview scrollbars/styles and the one-at-a-time expanders.

    
    

    
  
I've tested:

* Links
* Doctype validation
* Personas
* Promo rotation

The only thing I think that could use a tweak is the "Visit our help website"; shouldn't that be "Visit our Support website" (not sure about casing, but I think that's right).  David?

    
    

    
  
(In reply to comment #54)
> The only thing I think that could use a tweak is the "Visit our help website";
> shouldn't that be "Visit our Support website" (not sure about casing, but I
> think that's right).  David?

Done in trunk in r66910.

    
    

    
  
I noticed one more super-minor thing, and that's that if you leave the pre-populated term "search" in the textfield and hit the > button, it'll search for "search"; definitely not a big deal at all, but we've fixed this with other pages.

(It should just search the empty set.)

Other than that, this is ready to go from a QA perspective.

    
    

    
  
Stephen, do you recall another specific page or bug where this empty-search issue was addressed? It would be nice to use the same fix here.

    
    

    
  
(In reply to comment #57)
> Stephen, do you recall another specific page or bug where this empty-search
> issue was addressed? It would be nice to use the same fix here.

Not the particular bug, no, but I found where you added a generic JS function to at least populate/clear it, from bug 534653: r58011.

    
    

    
  
So the search function is the last thing we need to fix here?

    
    

    
  
Actually, before we sign off, we'd like to change the three featured Add-Ons to:

MiniMap- https://addons.mozilla.org/en-US/firefox/addon/5203/
Screengrab- https://addons.mozilla.org/en-US/firefox/addon/1146/
Morning Coffee- https://addons.mozilla.org/en-US/firefox/addon/2677/

Last change!

Thanks!

    
    

    
  
Couple of minor requests from me:

* Can we link the add-on names? If someone wants to learn more about the add-on they'll probably try to click that. 'Add to Firefox' buttons usually start the install, so anyone used to that will be hesitant to click them to learn more.

* Can we add ?src=fxfirstrun to all links to AMO on this page, including the individual add-ons and the the 'Browse more' and rotating promo links.

And then some totally ignorable style feedback:

Using the bold font for everything on this page was pretty jarring to me when I loaded it. Looking at Sean's mockup, it looks like a number of places the bold font should be a lighter gray color than the black currently used.

    
    

    
  
1) One last change to the three featured add-ons: 

Morning Coffee- https://addons.mozilla.org/en-US/firefox/addon/2677/
Invisible Hand- https://addons.mozilla.org/en-US/firefox/addon/11377/
Screengrab- https://addons.mozilla.org/en-US/firefox/addon/1146/

2) Please change the copy for the Rock Your Firefox module to read: 
* Tagline: Discover new add-ons to brighten your day.
* Button: View Featured Add-ons 

Thanks!

    
    

    
  
Search entry should no longer submit placeholder text in browsers that don't support the placeholder attribute. See r67129. Placeholder support was also re-written to use jQuery. See Bug #562372.

    
    

    
  
(In reply to comment #63)
> Search entry should no longer submit placeholder text in browsers that don't
> support the placeholder attribute. See r67129. Placeholder support was also
> re-written to use jQuery. See Bug #562372.

awesome, jquery++ thank you.


fwiw, there was another library doing the same thing
http://svn.mozilla.org/projects/mozilla.com/trunk/js/input-placeholder.js

we should nuke that one, but that's another bug

    
    

    
  
Featured add-ons are updated (and titles linked), Rock Your Firefox text is updated, and ?src tracking added to links in r67148.

Minor color tweak based on comment #61 in r67149.

    
    

    
  
Some of the changes from comment #65 are also in r67150.

    
    

    
  
The Rock Your Firefox text in the rotating promo is linked, but none of the other promos are; we should be consistent.

Also, I don't see the tracking codes implemented in the rotating promo modules (see comment 61).

    
    

    
  
(In reply to comment #67)
> The Rock Your Firefox text in the rotating promo is linked, but none of the
> other promos are; we should be consistent.

People only see one of these promos each time the page loads (usually only once?), so I don't think the consistency between them is critical. Also, I think the Rock Your Firefox promo differs a bit in that it is a collect of add-ons, rather than a single installable addon. I think it's ok as-is - let me know if I should change it anyhow.

> Also, I don't see the tracking codes implemented in the rotating promo modules
> (see comment 61).

The rotating promo modules link to promo pages on mozilla.com - I don't think we need the tracking codes for those links (do we?).

    
    

    
  
(In reply to comment #68)
> The rotating promo modules link to promo pages on mozilla.com - I don't think
> we need the tracking codes for those links (do we?).

They're good as-is. Thanks!

    
    

    
  
Page looks great, Steven.

It looks like all the requested changes were made--all thats left to do here is a QA sign off and a push, correct?

    
    

    
  
(In reply to comment #70)
> It looks like all the requested changes were made--all thats left to do here is
> a QA sign off and a push, correct?

I think so, yes. I'd recommend pushing this with the whatsnew page at the same time (Bug 562686).

    
    

    
  
I've taken another look at both this page and the What's New page over in bug 562686, and it looks good (validated doctype, checked links, Persona hovers, etc.)

    
    

    
  
Cool, thanks Steven. Are the r67315 files mentioned in comment #73 the only ones I need to push?

    
    

    
  
(In reply to comment #74)
> Cool, thanks Steven. Are the r67315 files mentioned in comment #73 the only
> ones I need to push?
Yes, that's it.

    
    

    
  
Pushed the files - should be live soon. Thanks all!
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Component: www.mozilla.org/firefox → www.mozilla.org
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: