Closed Bug 560507 Opened 11 years ago Closed 7 years ago

[Meta] Adjust new tabs to match mockups

Categories

(Firefox :: Theme, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: Terepin, Unassigned)

References

Details

(Keywords: meta)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100420 Minefield/3.7a5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100420 Minefield/3.7a5pre

Several aspects of appearance should be changed to match mockups:
1. Tab's width to 210px
2. Tab's height should be smaller
3. Curve that connects tabs with main window should be wider
4. Make gap between tabs bigger
5. Use light white shadow for text in background tabs
6. Make favicons on background tabs a bit matt
7. Change "plus" icon on new tab tab
8. Use soft black shadow at the bottom of tab bar

Reproducible: Always
Blocks: 549061
Attached image Current tabs
Forgot to mention that new tab button is cut of from the right side.
Remove 3D look when Aero is used.
I think this should block the release of Firefox.next, as the tabs in their current forms, while looking good (but are a bit too high), aren't close to what the mock-ups show.
This looks like a good list. Thanks!

I can't analyze it too much without Glass being active so it's hard to tell exactly what needs to be tweaked.
After 8 months of bugtesting of Strata40 my eyes are well trained to spot even smallest differences :)
The Aero 3D look may not be a valid, since I'm using CSS style for enabling Aero.
Aditional changes:
10. Make background tabs dark (I'm a bit confused here, 'cause official mockups have dark background tabs, but new ones on Stephen's blog have white background tabs)
11. Make favicons on loading background tabs colorless and matt (not sure if this belongs here or in PL bug)
12. Add fade-in effect when pointing to background tabs ( isn't on any mockup, but it would fit well to rest animations)
13. When tabs are on top, they are sharing same style as nav bar
(In reply to comment #0)
> 4. Make gap between tabs bigger

Can I object to this one. I really don't feel that we need tabs to be so far apart and in fact that was the thing that bugged me about the mock-ups, the current gap width is in fact perfect IMO.
14. The left and right borders on the tab need to be lighter in shade.
15. The rightmost tabs/new tab button have an odd border (@bottom)...it is left hanging without a proper curve. The curve at the bottom should exist on both - left and right borders.
(In reply to comment #8)
> (In reply to comment #0)
> > 4. Make gap between tabs bigger
> 
> Can I object to this one. I really don't feel that we need tabs to be so far
> apart and in fact that was the thing that bugged me about the mock-ups, the
> current gap width is in fact perfect IMO.

It needs to be a bit farther apart. It's about 1px off from the mockups, and I agree with Peter it needs to be farther apart.
(In reply to comment #9)
> 14. The left and right borders on the tab need to be lighter in shade.
As far as I can tell, they are as they suppose to be.
> 15. The rightmost tabs/new tab button have an odd border (@bottom)...it is left
> hanging without a proper curve. The curve at the bottom should exist on both -
> left and right borders.
The curve does exist on both borders.
But,
16. Curves shouldn't connect at the bottom. Left curve is slightly behind the previous one and right curve is slightly above the next one.
(In reply to comment #10)
> (In reply to comment #8)
> > (In reply to comment #0)
> > > 4. Make gap between tabs bigger
> > 
> > Can I object to this one. I really don't feel that we need tabs to be so far
> > apart and in fact that was the thing that bugged me about the mock-ups, the
> > current gap width is in fact perfect IMO.
> 
> It needs to be a bit farther apart. It's about 1px off from the mockups, and I
> agree with Peter it needs to be farther apart.

What is the benefit of the additional pixel other than the accumulation of more horizontal dead space? For someone like me that usually has around fifteen tabs open at any one time, that space is better served in-tab, rather than on tab separation. The beauty of Firefox 3.7/4.0 is that it's getting memory issues under control, thus everyone should be comfortable leaving masses of tabs open. It would be pointless to the undermine such progression by dedicating thirteen additional pixels to tab separation rather than to usable, click-able content.
Their too close at the moment. I like there to be some spacing in between tabs. I don't want a mess of tabs all right next to each other. It makes it look cluttered.
(In reply to comment #12)
> (In reply to comment #10)
> > (In reply to comment #8)
> > > (In reply to comment #0)
> > > > 4. Make gap between tabs bigger
> > > 
> > > Can I object to this one. I really don't feel that we need tabs to be so far
> > > apart and in fact that was the thing that bugged me about the mock-ups, the
> > > current gap width is in fact perfect IMO.
> > 
> > It needs to be a bit farther apart. It's about 1px off from the mockups, and I
> > agree with Peter it needs to be farther apart.
> 
> What is the benefit of the additional pixel other than the accumulation of more
> horizontal dead space? For someone like me that usually has around fifteen tabs
> open at any one time, that space is better served in-tab, rather than on tab
> separation. The beauty of Firefox 3.7/4.0 is that it's getting memory issues
> under control, thus everyone should be comfortable leaving masses of tabs open.
> It would be pointless to the undermine such progression by dedicating thirteen
> additional pixels to tab separation rather than to usable, click-able content.

Well, for once, tabs will be shorter about 40px per each one. So that makes 600px of free space compare to today's situation. Not enough? Plus, If we don't make gap bigger, we can forget about number 3 and because of that also about number 16. So yes, they are gonna be further appart.
(In reply to comment #14)
> (In reply to comment #12)
> > (In reply to comment #10)
> > > (In reply to comment #8)
> > > > (In reply to comment #0)
> > > > > 4. Make gap between tabs bigger
> > > > 
> > > > Can I object to this one. I really don't feel that we need tabs to be so far
> > > > apart and in fact that was the thing that bugged me about the mock-ups, the
> > > > current gap width is in fact perfect IMO.
> > > 
> > > It needs to be a bit farther apart. It's about 1px off from the mockups, and I
> > > agree with Peter it needs to be farther apart.
> > 
> > What is the benefit of the additional pixel other than the accumulation of more
> > horizontal dead space? For someone like me that usually has around fifteen tabs
> > open at any one time, that space is better served in-tab, rather than on tab
> > separation. The beauty of Firefox 3.7/4.0 is that it's getting memory issues
> > under control, thus everyone should be comfortable leaving masses of tabs open.
> > It would be pointless to the undermine such progression by dedicating thirteen
> > additional pixels to tab separation rather than to usable, click-able content.
> 
> Well, for once, tabs will be shorter about 40px per each one. So that makes
> 600px of free space compare to today's situation. Not enough? Plus, If we don't
> make gap bigger, we can forget about number 3 and because of that also about
> number 16. So yes, they are gonna be further appart.

With the removal of the title bar, is it really wise to put such a short max length of tabs? After all, that'll primarily be where we get our information regarding what page we're on from.

I do hear your gripes regarding the fact that you want the tabs to overlap rather than connect, but practicality should take precedence over aesthetics and you're basically asking that the size of a favicon be surrendered to this. Personally I believe it can be done within the current 3px space available or should at least be attempted.

I'd also like to suggest perhaps having it so as that when there are few tabs, the tabs are further separated than if there are more tabs. So if a user has enough tabs to fit the width of his monitor then the gab shrinks down to 1px, otherwise it's 2px as proposed in the mock-ups?
Yes it's wise to shorten the max length of the tab. In Firefox 3.6 it's way too wide and not needed at all. Looks much cleaner with a shorter length like the ones in the mockup.
When will be this "fixed"?
(In reply to comment #17)
> When will be this "fixed"?

IIRC I read Horlander say he'd wait until Aero Glass re-lands so he can see the tab work as intended and adjust accordingly in a real usage environment.
Attached image Tab Adjustments
I condensed the things that need to be adjusted in this bug and created a numbered illustration. I will file specific bugs for a few other things.

Tabs-on-top Tweaks:
1. Tab Corners should be softer
2. Curve that connects tab to navBar/contentArea should be more curved, gradual, smoother and have more overlap on background tabs
3. activeTab + navBar should have a softer shadow; at 3px gradation from most opaque to least opaque
4. activeTab + navBar texture should be a cohesive gradient
5. backgroundTab shadow/outline should be softer
6. backgroundTab bottom curve should be smoother and overlap other backgroundTabs more
7. newTab "tab" is missing outer curve
8. navBar needs shadow and edge highlight that matches the activeTab and slightly rounded corners; also a slight gradient shadow on the tabStrip

Tabs-on-bottom Tweaks:
(in addition to applicable changes from "Tabs-on-top Tweaks")
9. activeTab should go from light to translucent; like a vertically shrunken activeTab + navBar texture
10. activeTab needs darker bottom border between tab and page

Dimensions:
Tabs-on-top:
- navBar needs 3px vertical padding against large back button
- navBar should be 38px on inside of outline/shadow
- Tabs should be 22px high

Tabs-on-bottom:
- Need 3px spacing between toolbarButtons and tabs based on shadow edge or 6px based on hard outline

Other:
- Posted these design files to SVN based against the current lavender toolbar shade
  - http://svn.mozilla.org/design/projects/newtheme/strata/i06/Firefox-4-Mockup-i06-(Win7)-(Lavender)-(TabsBottom)-(BookmarksBar).psd
  - http://svn.mozilla.org/design/projects/newtheme/strata/i06/Firefox-4-Mockup-i06-(Win7)-(Lavender)-(TabsBottom)-(Default).psd
  - http://svn.mozilla.org/design/projects/newtheme/strata/i06/Firefox-4-Mockup-i06-(Win7)-(Lavender)-(TabsTop)-(BookmarksBar).psd
  - http://svn.mozilla.org/design/projects/newtheme/strata/i06/Firefox-4-Mockup-i06-(Win7)-(Lavender)-(TabsTop)-(Default).psd

I compared these against the current purple background color and these changes should largely apply to XP but might need some tweaks against Glass once it is reenabled. Specifically color and opacity changes.
So, Aero re-landed and the 3D look described in bug 560514 is valid.

Requesting block for beta1+.
blocking2.0: --- → ?
(In reply to comment #19)
> Created an attachment (id=446549) [details]
> 7. newTab "tab" is missing outer curve

It's fixed! I don't know how, when or what have fixed it, but it IS fixed.

I just love software development. :D
Keywords: meta
Summary: Adjust new tabs to match mockups → [Meta] Adjust new tabs to match mockups
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 569255
Well, it ain't fixed. Not sure why I saw it fixed (and I checked it several times to be sure). Perhaps some special circumstance happened. I have no idea.

By the way, is this blocking beta1+ or not?
No longer blocks: 569255
Depends on: 569255
Hopefully tabs will be fixed before beta. Still don't seem to have a big enough gap like the mockups do.
Depends on: 569850
Blocks: 575056
No longer blocks: 575056
Depends on: 575056
Looks like tabs will stay how they are now. Unfortunately.
So nobody's gonna handle restyling the tabs? Wow. =(
And I would think it'd be important to the beta.
I thought that too, but obviously Beta 1 Requirements here: https://wiki.mozilla.org/Firefox/Projects/New_Theme/Timeline are just for fun. Otherweise I can't explain such disinterest.
Depends on: 577067
(In reply to comment #26)
> I thought that too, but obviously Beta 1 Requirements here:
> https://wiki.mozilla.org/Firefox/Projects/New_Theme/Timeline are just for fun.
> Otherweise I can't explain such disinterest.

Who handed the last tab redesign for the current style?
Dao.
(In reply to comment #28)
> Dao.

You really should stop being so pushy around here. Sorry but things do not happen at blazingly fast speeds especially when you constantly spam bugs like this is a forum. Doing so in every single bug that has recently had anything to do with the ui has only added to the time needed to fix said bugs because the developers have to read yet more comments. Please take all your future suggestions and evangelism to the newsgroups and stop "bumping" bugs because the devs know exactly what stilll needs to be fixed and you're not helping. Please don't feel the need to reply and further spam this developer tool.
First of, I din't bump this bug, taz did. Second, I just answered the question. And third, your reply is OT.
unfortunately meta bugs can't by themselves block (since then people could add more bugs to the meta bug and they wouldn't pass through the triage process).  However, these bugs should be considered as a group, can someone nominate each individual bug and include a note that they should be considered as a group?  Kind of tedious, but helps to keep the blocker list organized.
blocking2.0: ? → ---
Depends on: 588473
Blocks: 577039
No longer blocks: 577039
And I'm sure shorlander is marking the appropriate dependencies for blocking.
Depends on: 591835
Depends on: 594824
This bug also applies to other platforms than Windows 7, for instance to Mac OSX (and maybe also to Linux?).
With respect to that, you should adjust "Platform: x86 Windows 7" to at least "Platform: x86 Windows 7 Mac OSX" or to "Platform: x86 All" in the bug's information.
Dao should change that. I'm not entirely sure if it is true, because new tabs were implemented separately.
(In reply to comment #34)
> Dao should change that. I'm not entirely sure if it is true, because new tabs
> were implemented separately.

See also https://wiki.mozilla.org/Firefox/Projects/New_Theme/Timeline .
That page should also be adjusted with respect to this bug and reflecting the outstanding bugs on Mac platform an Linux platform.
For instance only the [Windows] Theme Requirements (in order of priority) incl. screenshots mentions Bug 570279 and Bug 570282, although these two bugs also do apply on Mac OSX an Linux as well concerning "Tabs on Top" (Tabs on Bottom are curved, Tabs on Top are not curved) -- compare 1st screenshot (Tabs on Top) with 2nd screenshot (Tabs on Bottom) of either platform.
Contact Stephen for that, this isn't place for it.
(In reply to comment #36)
> Contact Stephen for that, this isn't place for it.

He is in the CC of this bug as far as I can see, so I think he should get a copy of this message anyway, shouldn't he?
Whiteboard: [softblocker]
Whiteboard: [softblocker]
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.