Closed Bug 627301 Opened 13 years ago Closed 13 years ago

Update Firefox Start Page design (with no string impact)

Categories

(Firefox :: General, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 4.0b11
Tracking Status
blocking2.0 --- final+

People

(Reporter: limi, Assigned: msucan)

References

(Depends on 1 open bug, )

Details

(Whiteboard: [hardblocker][fx4-fixed-bugday][about-home])

Attachments

(11 files, 8 obsolete files)

8.43 KB, text/html
Details
3.21 KB, image/png
Details
1.44 KB, image/png
Details
66.76 KB, image/png
Details
129.39 KB, image/png
Details
254.90 KB, image/png
Details
87.01 KB, image/png
Details
67.06 KB, image/png
Details
55.67 KB, image/png
Details
86.02 KB, image/png
Details
25.06 KB, patch
ehsan.akhgari
: review+
Details | Diff | Splinter Review
Stephen Horlander has created an about:home design that we'd like to include instead of the current design.

This has been in the works for a while, but in a bug that had to be confidential until we knew whether there were any contractual issues with the redesign — we now know that there shouldn't be any problems, hence this public bug. We apologize for it being visible only so late, but with no functional or string changes, this should be quick work, and hopefully not introduce any significant risk.

It's important that we do this update without any string changes, since it's so late in the cycle.

Attached is Stephen's latest HTML mock-ups — these will change a bit because of the requirement to not change any strings (the "Restore Previous Session" link is already in the History menu, so we have that string available to us).

Stephen, please attach the updated versions as soon as you can, so we can get this rolling.
Also requesting soft-blocking on this: If we can get it done in time, I think it should be allowed to land — if we don't, it won't hold the release.

This is high visibility (every time you open Firefox if you use the standard home page), low risk, and overall a big win if we can get it ready in time.
blocking2.0: - → ?
Whiteboard: [softblocker][d?]
ideally done with htlm5 markup and not html4 transitional like the mockups? :)
Also of note: the search engine switcher isn't in the plan for the 4.0 version, but may be added later.
The page must be valid xhtml since we use xml entities to translate, we cannot do the restore previous session thing, unless it's just a link to about:sessionrestore... maybe session restore could even inject values for windows and tabs, but the page being unpriviledged cannot launch any chrome priviledged function.
The design looks a bit "tall" especially for netbook screens, I don't have one to check if it causes scrollbars though.
I guess if button-like snippet should be done server side since we could not know if the snippet content wants it white/green/orange, we could make a generic white border though and most likely the snippets could change its colour with some css.
Overall, just taking the design part should not be hard or risky.
Is the copy on this page (particularly at the bottom) placeholder or proposed as final?
(In reply to comment #7)
> Is the copy on this page (particularly at the bottom) placeholder or proposed
> as final?

There won't be any string changes, so it won't have that part at all.

It's also showing Yahoo (since we wanted to show how switching search engines could work earlier in the process), but that's not going to happen either, it's going to stay as a Google page, similar to Firefox 3.6.

In other words, the elements and behavior will be exactly the same as the current page at http://google.com/firefox, minus the top bar (since we can't do that in a reliable way, AFAIK), and with updated graphics and layout.
Got it, thanks Limi.
(In reply to comment #6)
> do the restore previous session thing, unless it's just a link to
> about:sessionrestore...

I think that is what limi and zpao talked about happening?

> The design looks a bit "tall" especially for netbook screens, I don't have one
> to check if it causes scrollbars though.

Minus the footer it scales down to around 550px vertically and 330px horizontally. Whoever does the final implementation could probably make it scale more still.

> I guess if button-like snippet should be done server side since we could not
> know if the snippet content wants it white/green/orange, we could make a
> generic white border though and most likely the snippets could change its
> colour with some css.

That is what I was hoping we could do. Default white snippet with the option of customizing the color/style.
(In reply to comment #10)
> (In reply to comment #6)
> > do the restore previous session thing, unless it's just a link to
> > about:sessionrestore...
> 
> I think that is what limi and zpao talked about happening?

Yes, bug 593421, currently a soft blocker that Paul is working on.
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #6)
> > > do the restore previous session thing, unless it's just a link to
> > > about:sessionrestore...
> > 
> > I think that is what limi and zpao talked about happening?
> 
> Yes, bug 593421, currently a soft blocker that Paul is working on.

I sure hope he's not, as a softbocker with strings should be very, very low on the bugfix totem pole ;-)
FTR, we're also supporting yandex as first search engine in about:home, see http://mxr.mozilla.org/mozilla-central/source/browser/base/content/aboutHome.js#39. That's used for at least Russian, IIRC.
(In reply to comment #12)
> I sure hope he's not, as a softbocker with strings should be very, very low on
> the bugfix totem pole ;-)

Looks like we found a way to do it without introducing any new strings.
Attachment #505361 - Attachment is obsolete: true
Attachment #505362 - Attachment is obsolete: true
Comment on attachment 505584 [details]
Simplified version from Stephen, note that this has a base tag pointing to Stephen's server for the images

The font size for the search box is a bit small here, we should probably aim for the same size as the current google.com home page.

The snippet text also seems a bit small to me, but that's less important.
Where is the re-used string used currently? We should compare them in context to make there's really no strings impact.
history menu > restore previous session
OR
firefox button > history > restore previous session
(In reply to comment #17)
> Where is the re-used string used currently? We should compare them in context
> to make there's really no strings impact.

And it'll do the exact same thing as the menu item, so should be OK. (ie. we're not opening about:sessionrestore anymore, which was the earlier plan)
The latest design is missing the About Mozilla and Firefox Support links at the bottom of the page which should be kept.
The updated look of the page is a hardblocker, definitely. Adding the button to restore the previous session is being handled in bug 593421 (and is not a hard blocker) so please take that discussion over there.

Stephen/Assignee: please make sure that the CSS around the snippet content can flex, since we'll want to let arbitrarily sized content into that space.
blocking2.0: ? → final+
Whiteboard: [softblocker][d?] → [hardblocker]
Is someone already working on this bug?

If not, I can take it. The plan is to:

- replace aboutHome.xhtml with the code attached in this bug (attachment 505584 [details]).
  - update the markup to use valid XHTML and the DTD strings, without adding new new strings.
  - I shall not include the "restore previous session" button, because this will be included in bug 593421.
   - I shall add the About Mozilla link at the bottom of the page, like in the older example page, but without the slogan - only the link. (see attachment 505361 [details]).

- replace aboutHome.css with the style sheet in the attached page.
  - I shall make sure that the snippet content style is flexible, to let arbitrarily sized content into that space.

- update aboutHome.js to work with the new code.

Please let me know if the above needs corrections. Thanks!
Rather than doing a blind replacement of aboutHome.xhtml and aboutHome.css I'd talk about integrate the new design in the appropriate points of those files.
They also contain some useful stuff and wherever possible the ids should be  preserved to avoid useless changes.
Plus you'd have to check the page in RTL mode.
Apart these, the plan looks good.
Some question on the design.
Is it normal that the border of the "blue" bottom area on first load does not appear and it does appear when hovering the snippet (And stays so from then on)?
Why the snippet has a button behavior (mouseover and mousedown), is it expected?
We allow engines to have additional links, like "advanced search" on google, do we plan to drop these?
(In reply to comment #23)
> Rather than doing a blind replacement of aboutHome.xhtml and aboutHome.css I'd
> talk about integrate the new design in the appropriate points of those files.
> They also contain some useful stuff and wherever possible the ids should be 
> preserved to avoid useless changes.
> Plus you'd have to check the page in RTL mode.
> Apart these, the plan looks good.

Thanks! Will keep that in mind when updating the code. Indeed, simply overwriting the files is not a good approach.
Re the plan in comment #22, is it also possible to make the whole snippet button clickable?  Currently just the link in the snippet is clickable and I imagine we're losing out on traffic because of the small target and the image not being a link.
(In reply to comment #26)
> Re the plan in comment #22, is it also possible to make the whole snippet
> button clickable?  Currently just the link in the snippet is clickable and I
> imagine we're losing out on traffic because of the small target and the image
> not being a link.

I am not sure what is the plan with the snippets.

Default snippets are now just strings coming from the DTD, which can contain one link (one anchor). The anchor URL is set by the aboutHome.js script.

Snippets that are loaded from the server ... are scripts. They can do what they want.

For default snippets I can make sure that clicking the snippet button follows the link. Does this sound fine?
> For default snippets I can make sure that clicking the snippet button follows
> the link. Does this sound fine?

Sounds fine to me.
(In reply to comment #24)
> Some question on the design.
> Is it normal that the border of the "blue" bottom area on first load does not
> appear and it does appear when hovering the snippet (And stays so from then
> on)?

It looks like a redraw issue. Minimize/restore the window and the border goes away again.

> Why the snippet has a button behavior (mouseover and mousedown), is it
> expected?

It seems to be the case. As David has asked about this.

> We allow engines to have additional links, like "advanced search" on google, do
> we plan to drop these?

I haven't been involved in the design process, but looking at:

http://stephenhorlander.com/pages/firefox-start/

You can see v04 had Advanced search, and all subsequent iterations have dropped it. I presume no additional links are planned. (As a user, I'd prefer a cleaner look, with no such links.)
Mihai, when you pull out the parts that only apply to restore previous session, can you put that in bug 593421? I can take care of integrating it there, but it would make my life a lot easier to have it already separated. Thanks!
Assignee: nobody → mihai.sucan
Blocks: 593421
(In reply to comment #30)
> Mihai, when you pull out the parts that only apply to restore previous session,
> can you put that in bug 593421? I can take care of integrating it there, but it
> would make my life a lot easier to have it already separated. Thanks!

Sure, I will be able to submit a patch to that bug that adds the button (without the actual action - that would require more code spelunking), based on the code I'll submit here.
Attached patch WIP 1 (obsolete) — Splinter Review
Attaching Work In Progress patch 1. This is usable and can be tested. I am interested for comments to improve the patch, and if the direction things are going is fine. Thanks!

Things to do:

- Make the snippet button clickable - so it follows the link.

- The search engine logos are data URIs. Shouldn't they be image files?

- The Google search engine logo is missing the TM. I downloaded what was on the stephenhorlander.com server. Does it need a change?

- The russian search engine logo needs to be updated - new size (height 28px). Waiting for the updated file from Stephen.

- The search bar - with the input and the submit button - must be perfectly aligned. This is not always trivial, IIANM, because ems and pixels are not always friends. Shall I go for pixels instead of ems? At the moment render is fine (tested on Linux). Stephen's page used pixels only and rendered the input field at a different height than the search button...

- The Firefox/Minefield logos need to be updated (new height 173px). Waiting for the updated Minefield logo from Stephen.

- direction:rtl not tested yet. Shall the "logo, input, button" change their order? To "button, input, logo". Or is the current order fine?

- Add the "Advanced Search" and "Preferences" links. Based on IRC discussion these will be kept in the new UI. Waiting for an updated page from Stephen, to see where I shall put them.

- I also have to submit a patch for the "restore previous session" button to bug 593421.

That's all.
Attachment #505939 - Flags: feedback?(gavin.sharp)
(In reply to comment #32)
> - The search bar - with the input and the submit button - must be perfectly
> aligned. This is not always trivial, IIANM, because ems and pixels are not
> always friends. Shall I go for pixels instead of ems? At the moment render is
> fine (tested on Linux). Stephen's page used pixels only and rendered the input
> field at a different height than the search button...

I believe using px is fine, especially since FF scales things that are defined as px too. Since this isn't a design that has to work in IE6, I don't see any inherent problems with using px instead of em here. I agree that you can't really mix them and expect predictable results.
(In reply to comment #32)
> - The search engine logos are data URIs. Shouldn't they be image files?

the search engine image is injected by the js code

> - The Google search engine logo is missing the TM. I downloaded what was on the
> stephenhorlander.com server. Does it need a change?

there is already one injected by the js code, it should be updated to have a transparent bg though.

> - The russian search engine logo needs to be updated - new size (height 28px).
> Waiting for the updated file from Stephen.

yep, update in js please.

> always friends. Shall I go for pixels instead of ems? At the moment render is

no problem with px, just recall to check the page with the "high dpi" setting of the OS

> - The Firefox/Minefield logos need to be updated (new height 173px). Waiting
> for the updated Minefield logo from Stephen.

I think you don't want this, we use the logo from the branding folder, IIRC there should be a 256px image you can use (atm we use the 128 right?)
(In reply to comment #34)
> (In reply to comment #32)
> > - The search engine logos are data URIs. Shouldn't they be image files?
> 
> the search engine image is injected by the js code
> 
> > - The Google search engine logo is missing the TM. I downloaded what was on the
> > stephenhorlander.com server. Does it need a change?
> 
> there is already one injected by the js code, it should be updated to have a
> transparent bg though.
> 
> > - The russian search engine logo needs to be updated - new size (height 28px).
> > Waiting for the updated file from Stephen.
> 
> yep, update in js please.

Yeah, I saw the images as data URIs in the js file. I was only wondering if we still want to keep them there.

I will update both search engine logos once Stephen sends us the logos at the right sizes.


> > always friends. Shall I go for pixels instead of ems? At the moment render is
> 
> no problem with px, just recall to check the page with the "high dpi" setting
> of the OS

Good.

> > - The Firefox/Minefield logos need to be updated (new height 173px). Waiting
> > for the updated Minefield logo from Stephen.
> 
> I think you don't want this, we use the logo from the branding folder, IIRC
> there should be a 256px image you can use (atm we use the 128 right?)

Will try that, but 256px is too big. Unless we want to resize the logos with CSS? I'll do this, until I get the updated images from Stephen.

Thanks for your reply!
(In reply to comment #34)
> I think you don't want this, we use the logo from the branding folder, IIRC
> there should be a 256px image you can use (atm we use the 128 right?)

Hm, can't find the 256px image. The branding folder only has smaller icons, no 256px.
In the official branding I see a 256px icon called default256.png, but looks like this file is missing for nightly and unofficial.
Oh but we have about-logo.png that is 210px and looks good
(In reply to comment #38)
> Oh but we have about-logo.png that is 210px and looks good

Ok, thanks. I'll use about-logo.png.
Comment on attachment 505939 [details] [diff] [review]
WIP 1

>+#searchSubmit {
>+  background: -moz-linear-gradient(#f1f1f1, #dfdfdf);
>+  padding: 0 0.6em;
>+  height: 2.4em;
>+  border: 1px solid #ccc;
>+  border-color: #ccc #999 #999 #afafaf;
>+  box-shadow: 1px 1px 0 #e7e7e7,
>+              0 1px 0 #fcfcfc inset,
>+              0 -1px 0 #d7d7d7 inset;
>+  font-size: 0.95em;
>+}

This hardcodes a background color without a fitting foreground color.
Please make sure to design and implement with small screens in mind. "Restore Previous Session" is partly offscreen on my netbook.
(In reply to comment #41)
> Please make sure to design and implement with small screens in mind. "Restore
> Previous Session" is partly offscreen on my netbook.

That would most likely require changing the height of the header logo (the Firefox logo). How much smaller should it be? Or should it adjust automatically? (percentages of height)

What is the screen resolution on your netbook?
(In reply to comment #42)
> (In reply to comment #41)
> > Please make sure to design and implement with small screens in mind. "Restore
> > Previous Session" is partly offscreen on my netbook.
> 
> That would most likely require changing the height of the header logo (the
> Firefox logo). How much smaller should it be? Or should it adjust
> automatically? (percentages of height)

A height of 100px seems to work here, but it might be better to revise the spacing as a whole rather than just reducing the logo size.

By the way, on attachment 505584 [details], even if "Restore Previous Session" is on screen, the page still overflows.

> What is the screen resolution on your netbook?

1024*600. In the default XP configuration (menu bar visible, large icons, bookmarks bar hidden, add-on bar hidden, task bar not auto-hiding), the content area's height is 463 pixels.
Attached patch WIP 2 (obsolete) — Splinter Review
Updated patch. Thanks to everyone who commented on the code.

Changes:

- made the snippet button clickable, so it now follows the link.

- switched from ems to pixels for the styling.

- switched to use the about-logo.png image instead of icon128.png (as suggested by Marco). Still, I think we should get appropriate versions for the about:home page. (leaving this decision to Stephen or to who has decisional power :) )

- added the search engine links ("Advanced Search" and "Preferences"). This is just how I imagined it. Still pending UI from Stephen. ;)

- made the design work with rtl languages. This only reverses the order of the search bar. Please let me know if this is fine.

- fixed the #searchSubmit styling: added a foreground color, as suggested by Dão.

- did work on the layout "fluidity", to have it adapt to the page/screen size. It should now render fine on netbooks. Dão, please let me know if this addresses your concerns.

That's all for now.

Remaining work:

- get any further UI improvements that are needed from Stephen: search engine logos, Firefox/Minefield logos, and the UI for the search engine links.

- add the "Restore previous session" button and submit the patch to bug 593421.

- address any further review comments. ;)

Thanks!
Attachment #505939 - Attachment is obsolete: true
Attachment #506113 - Flags: feedback?(gavin.sharp)
Attachment #505939 - Flags: feedback?(gavin.sharp)
Both Google and Yandex have search suggestions feature, which is useful beyond question. Can we implement it into about:home page, like we did it with default search plugins?
(In reply to comment #45)
> Both Google and Yandex have search suggestions feature, which is useful beyond
> question. Can we implement it into about:home page, like we did it with default
> search plugins?

sure, but that's not the scope of this bug, see bug 612453 instead
Attached patch proposed patch (obsolete) — Splinter Review
Patch update for bug 593421. This includes the styling needed for the Restore Previous Session button.

This is pretty much ready for review, pending any further UI improvements from Stephen.
Attachment #506113 - Attachment is obsolete: true
Attachment #506503 - Flags: review?(gavin.sharp)
Attachment #506113 - Flags: feedback?(gavin.sharp)
Status: NEW → ASSIGNED
Whiteboard: [hardblocker] → [hardblocker][patchclean:0124]
(In reply to comment #47)
> This is pretty much ready for review, pending any further UI improvements from
> Stephen.

I have been running with this most of the day and it looks great! I have some feedback mostly in regards to layout scaling:

Icon:
- Scaling the icon is nice but maybe not optimal because of the way the scaling becomes blurry. It might be ok as long as there is a minimum and a maximum size. Probably 128px min and 256px max.

Search Field/Buttons/Links:
- The search field should also have a max-width of ~700px or else it gets too large on big screens. It should have a min-width as well.
- The left and right margins for the search-engine icon and the search button should probably get smaller as it shrinks to leave more room for the search field
- "Advanced Search" and "Preferences"  should be centered underneath the search field
- The search field font-size should be a little larger and have some starting padding

Snippets:
- The snippet should have a max-width also. Around 70% of the search field max-width looks pretty nice
- Snippets should stay narrower than the search field

Session Restore:
- We could use a smaller session restore icon to avoid scrolling on smaller screens. Would it be possible to scale that like the Firefox logo?

Links:
- Remove link underlines and just have them on hover

I am attaching the search engine graphics and some mockups of a layout on a smaller screen and of a layout on a larger screen.
Status: ASSIGNED → NEW
Quick drive-by comments: 

1. I don't think the Advanced/Preferences links should be under the search field — if they are, they should at least be in comfortable distance and/or smaller size.

   Currently, we place the Advanced/Preferences links in the exact same location where the Google front page has their "Search" and "I'm feeling lucky" buttons, which is probably not ideal if you're used to their page and switch to ours.

2. Also — and this is more idle thoughts — I was wondering if it makes sense to attach the Session restore to either top or bottom of the viewport, to reinforce the connection to the browser, not the search page. I do like the current treatment a lot too, so maybe I'm just needlessly obsessing about that. ;)

   Might be worth a quick experiment (slightly smaller icon, and band or corner placement of the Session Restore link) — I'll leave that to Stephen's discretion.
Also a drive by comment: I really like the current placement of the restore session control.  We should start to wrap users heads around this being an entirely chrome page, and attaching to the border seems odd if there isn't any scrolling.  Also, I think it would come off as unbalanced, while the current design has really good symmetry.
(In reply to comment #48)
> (In reply to comment #47)
> > This is pretty much ready for review, pending any further UI improvements from
> > Stephen.
> 
> I have been running with this most of the day and it looks great! I have some
> feedback mostly in regards to layout scaling:
> 
> Icon:
> - Scaling the icon is nice but maybe not optimal because of the way the scaling
> becomes blurry. It might be ok as long as there is a minimum and a maximum
> size. Probably 128px min and 256px max.

This sounds good. Maybe 128px is too high. We might have to go for lower, to fit 460px of available height.


> Search Field/Buttons/Links:
> - The search field should also have a max-width of ~700px or else it gets too
> large on big screens. It should have a min-width as well.
> - The left and right margins for the search-engine icon and the search button
> should probably get smaller as it shrinks to leave more room for the search
> field

Will look into this.

> - "Advanced Search" and "Preferences"  should be centered underneath the search
> field
> - The search field font-size should be a little larger and have some starting
> padding

I agree with Limi here, in some ways, but what is a "comfortable distance"?

I was thinking of placing the link under the search field, aligned to the right border. (not centered) Thoughts? Right below the field, not too much spacing.


> Snippets:
> - The snippet should have a max-width also. Around 70% of the search field
> max-width looks pretty nice
> - Snippets should stay narrower than the search field

Will do this.

> Session Restore:
> - We could use a smaller session restore icon to avoid scrolling on smaller
> screens. Would it be possible to scale that like the Firefox logo?

The session restore button scales down both in width and in height, including the icon. Please test the attached patch. It works/looks pretty much like in the "about:home small screen layout" attachment 506676 [details]. (or maybe you're referring to something different?)

No scrolling is needed on small screens (460px page height).


> Links:
> - Remove link underlines and just have them on hover

Will do.

> I am attaching the search engine graphics and some mockups of a layout on a
> smaller screen and of a layout on a larger screen.

Thanks for your comments and for the attachments!
(In reply to comment #54)
> Also a drive by comment: I really like the current placement of the restore
> session control.  We should start to wrap users heads around this being an
> entirely chrome page, and attaching to the border seems odd if there isn't any
> scrolling.  Also, I think it would come off as unbalanced, while the current
> design has really good symmetry.

Agreed. I also prefer the current placement of the restore session button.
Is it possible to actually have two or three sizes (for the most common screen resolutions assuming a maximized window) of the Firefox logo and snap to difference sizes as the window shrinks or expands? Browser scaling isn't quite as good as it could be and I'm concerned that a browser scaled Firefox logo will look less than perfect at certain screen sizes unless we've carefully scaled specific sizes from the original in a graphics program.
(In reply to comment #57)
> Is it possible to actually have two or three sizes (for the most common screen
> resolutions assuming a maximized window) of the Firefox logo and snap to
> difference sizes as the window shrinks or expands? Browser scaling isn't quite
> as good as it could be and I'm concerned that a browser scaled Firefox logo
> will look less than perfect at certain screen sizes unless we've carefully
> scaled specific sizes from the original in a graphics program.

I am concerned about this as well and snapping a few pre-defined sizes would be ideal. Although I am not sure if this could be easily accomplished?
guess media queries should work? http://dev.w3.org/csswg/css3-mediaqueries/#width
(In reply to comment #53)
> 1. I don't think the Advanced/Preferences links should be under the search
> field — if they are, they should at least be in comfortable distance and/or
> smaller size.
> 
>    Currently, we place the Advanced/Preferences links in the exact same
> location where the Google front page has their "Search" and "I'm feeling lucky"
> buttons, which is probably not ideal if you're used to their page and switch to
> ours.

Placing them off center or next to the Search button looks a little off. Although making them smaller and stacked next to the search button isn't bad. That said I don't think centering them underneath the field is a problem :)
(In reply to comment #60)
> Created attachment 506744 [details]
> Advanced/Preference Link Placement
>
> Placing them off center or next to the Search button looks a little off.
> Although making them smaller and stacked next to the search button isn't bad.

I think this works pretty well (just watch for alignment/centering, we might want to shrink the search field a tiny bit, since it gets very wide). 

It's never going to be optimally pretty, but this is much better than having them under the text field, IMO. And it feels like they "belong" to the Search box, but maybe that's just me being conservative and preferring what Google does/did. I guess that's not such a bad thing when it comes to income-generating UI. :)
(In reply to comment #60)
> Created attachment 506744 [details]
> Advanced/Preference Link Placement
> 
> (In reply to comment #53)
> > 1. I don't think the Advanced/Preferences links should be under the search
> > field — if they are, they should at least be in comfortable distance and/or
> > smaller size.
> > 
> >    Currently, we place the Advanced/Preferences links in the exact same
> > location where the Google front page has their "Search" and "I'm feeling lucky"
> > buttons, which is probably not ideal if you're used to their page and switch to
> > ours.
> 
> Placing them off center or next to the Search button looks a little off.
> Although making them smaller and stacked next to the search button isn't bad.
> That said I don't think centering them underneath the field is a problem :)

I like this proposal. Looks good. Will do it. Thanks!
Attached patch patch update 2 (obsolete) — Splinter Review
Updated the patch. Changes:

- made the logo to not resize smaller than 128px, and max height 256px.
- using percentages for the margins left/right (search bar).
- max-width 700px for the search field. min-width 150px
- search field font-size 13px
- search snippet smaller than search field.
- removed underlines for links. made it show on hover.
- updated the search engine logos.
- changed the placement of the search links, as in the latest proposal from Stephen. see attachment 506744 [details]

If you guys want specific Firefox/Minfield icons for different sizes, please attach them. I can use them with CSS 3 Media Queries.

Will attach screenshots.
Attachment #506503 - Attachment is obsolete: true
Attachment #506805 - Flags: review?(gavin.sharp)
Attachment #506503 - Flags: review?(gavin.sharp)
Current state of the UI, with bug 593421 included (the Restore Previous Session button).
Attached image current state - RTL
Status: NEW → ASSIGNED
Paul Rouget suggests these approaches for scaling the Firefox logo:

The elegant one: use SVG.
The other elegant one: use mediaQueries
  @media (max-width: 900px){div{background-image: ...;}}
  @media (max-width: 600px){div{background-image: ...;}}
  @media (max-width: 300px){div{background-image: ...;}}
Rendering complex SVG is still slow, and much slower than bitmaps by far.

Mihai is already using media queries to have preset sizes for the logo based on screen size.
Attached patch patch update 3 (obsolete) — Splinter Review
Updated the patch, based on comments from Stephen:

- made the Firefox logo min-height 92px (no longer 128px).
- made the spacing between the page border and the search engine logo and buttons to be smaller - the input is now wider on smaller resolutions.
- fixed the bug with the spacing between the search field and search button.
- added more spacing between the search field and the snippet box, on smaller resolutions (just better space usage).
- added max-width for the snippet box.
- made the snippet box wider on smaller screens.

Further comments are welcome. Thanks!

Screenshots:

- full screen: http://img.i7m.de/show/hih1u.png
- small screen: http://img.i7m.de/show/0sngb.png
Attachment #506805 - Attachment is obsolete: true
Attachment #507204 - Flags: review?(shorlander)
Attachment #506805 - Flags: review?(gavin.sharp)
Whiteboard: [hardblocker][patchclean:0124] → [hardblocker][patchclean:0126]
The present design doesn't have any scope of incorporating top sites feature in future. :(
Attachment #507204 - Flags: review?(shorlander) → review+
(In reply to comment #71)
> The present design doesn't have any scope of incorporating top sites feature in
> future. :(

Because we're not doing this for Firefox 4. Open a separate bug if you want to discuss such a thing. For Firefox 4, the focus was to make it locally hosted to make it load instantly, and to modernize the design a bit.

We have bigger plans for this page in the near future, but this is what we're doing for FF4.
Attachment #507204 - Flags: review+ → review?(gavin.sharp)
Comment on attachment 507204 [details] [diff] [review]
patch update 3

>diff --git a/browser/base/content/aboutHome.css b/browser/base/content/aboutHome.css

>+#brandStartText {
>+  display: none;

Just remove the element, and file a followup to remove the string?

>+#searchLogoContainer {
>+body[dir="rtl"] #searchLogoContainer {

> #searchEngineLogo {
>+body[dir="rtl"] #searchEngineLogo {

>+#searchButtons {
>+body[dir="rtl"] #searchButtons {

>+body[dir="rtl"] #searchEngineLinks {
>+  margin-left: 0;
>+  margin-right: 1.5%;
>+  text-align: right;
>+}

Did you get someone (Ehsan) to make sure RTL looks correct? I don't think it makes sense to change the text-align for RTL. And I think you should use -moz-margin-start rather than RTL-specific left/right values for these.

(1.5% seems like an odd value to use for a margin...)

> #aboutMozilla {
>   text-align: center;
> }

Is this needed, given that text-align: center is already set on the parent (bottomSection)?

>+#sessionRestoreContainer {

>+#restorePreviousSession {

Can you omit these style rules and include them in the patch for bug 593421?

>diff --git a/browser/base/jar.mn b/browser/base/jar.mn

>+        content/browser/aboutHome-restore-icon.png    (content/aboutHome-restore-icon.png)

Similarly, I think this is best landed in bug 593421.

r=me with those addressed.
Attachment #507204 - Flags: review?(gavin.sharp) → review+
(In reply to comment #73)
> >+body[dir="rtl"] #searchEngineLinks {
> >+  margin-left: 0;
> >+  margin-right: 1.5%;
> >+  text-align: right;
> >+}
> 
> Did you get someone (Ehsan) to make sure RTL looks correct? I don't think it
> makes sense to change the text-align for RTL. And I think you should use
> -moz-margin-start rather than RTL-specific left/right values for these.

There's text-align: start/end, too.
Attached patch patch update 4 (obsolete) — Splinter Review
Addressed review comments.

- removed the styling of the "Restore Previous Session" button, and the icon file. Will submit an updated patch to bug 593421.
- did the RTL changes requested.

Otherwise, the patch is pretty much ready to land. Asking for "RTL review" from Ehsan.

Thanks for your review+ Gavin!
Attachment #507204 - Attachment is obsolete: true
Attachment #507952 - Flags: review?(ehsan)
Whiteboard: [hardblocker][patchclean:0126] → [hardblocker][patchclean:0128]
Comment on attachment 507952 [details] [diff] [review]
patch update 4

>+#searchSubmit {
>+  background: -moz-linear-gradient(#f1f1f1, #dfdfdf);
>+  padding: 4px 8px;
>+  height: 32px;
>+  border: 1px solid #ccc;
>+  border-color: #ccc #999 #999 #afafaf;

This border-color property needs to be reversed for RTL mode.  Or better yet, split this into four properties: border-top-color, border-bottom-color, -moz-border-start-color, and -moz-border-end-color.

>+  box-shadow: 1px 1px 0 #e7e7e7,
>+              0 1px 0 #fcfcfc inset,
>+              0 -1px 0 #d7d7d7 inset;

The first shadow's x coordinate needs to be changed to -1px in RTL mode.  Unfortunately, the only way to do that is with a separate rule tailored for RTL pages.

>+#searchSubmit:active {
>+  background: -moz-linear-gradient(#c5c5c5, #c5c5c5);
>+  box-shadow: 1px 1px 0 #e7e7e7;

Ditto for box-shadow.


Also, the background image for the "Restore Previous Session" link should appear on its right, but I couldn't find where in this patch it's implemented!
Attachment #507952 - Flags: review?(ehsan) → review-
Attached patch patch update 5Splinter Review
More RTL fixes. Thanks Ehsan for your review!

The Restore Previous Session button code is in bug 593421. Will update the patch and ask you for review, once Stephen sends me the icon for RTL users.
Attachment #507952 - Attachment is obsolete: true
Attachment #507976 - Flags: review?(ehsan)
Comment on attachment 507976 [details] [diff] [review]
patch update 5

Looks great, thanks!
Attachment #507976 - Flags: review?(ehsan) → review+
Thanks Ehsan for the reviews!

This means the patch is done: checkin-needed! :)
Keywords: checkin-needed
The font size is still smaller than that on google.com
(In reply to comment #81)
> The font size is still smaller than that on google.com

I have noticed this under Windows.  The font size for the "advanced search", "Preferences" and "About Mozilla" are all too small.  I think they should be the same size as the "It's easy to customize ..." text.  It looks much better under Linux.
I was talking about search box font size
(In reply to comment #83)
> I was talking about search box font size

Oh i had not tried actually searching yet.  Either the vertical size of the searchbar needs to be smaller or it needs a bigger font.  It makes no sense to have a one line textbox this tall with a font that fills less than a third of the height.

This is another seems to be more Windows than Linux issue though.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [hardblocker][patchclean:0128] → [hardblocker]
Target Milestone: --- → Firefox 4.0b11
Depends on: 630066
I agree some text is too small. Has a bug been filed?
Text sizes should use relative rather than absolute pixel units, respecting the size setting in Options > Content > Fonts & Colors.
Depends on: 630059
Depends on: 631257
Verified fix on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11) Gecko/20100101 Firefox/4.0b11.  however, we need a RTL build to also test this on per comment 77.
Whiteboard: [hardblocker] → [hardblocker][fx4-fixed-bugday]
Looks good in Persian with Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110203 Firefox/4.0b12pre
Status: RESOLVED → VERIFIED
Depends on: 630170
Whiteboard: [hardblocker][fx4-fixed-bugday] → [hardblocker][fx4-fixed-bugday][about-home]
You need to log in before you can comment on or make changes to this bug.