*If* the technical issue of showing aero glass in the background of the tab view in Windows is possible (bug 586679), we will need to determine (a) whether it is wise to do so and (b) what that should look like. Here's a mockup of what this might look like: http://www.stephenhorlander.com/images/blog-posts/incontent-ui/win7-tabcandy-glass.jpg and a mockup of what it could look like if we choose not to show glass: http://www.stephenhorlander.com/images/blog-posts/incontent-ui/win7-tabcandy-textured.jpg

Requesting blocking.

Since it was shown to be possible to show glass (bug 586679), I'll take a stab at implementing Michael's mockup, see how it works out in practice.

Thanks, Oliver. That is super useful! Let us know when you've got something. I'd love to be able to release Panorama with glass. Point of clarification, those mockups were made by the gifted Stephen Horlander.

Well I've been told those mockups are outdated and their concepts already tried and rejected, so progress has stalled on that front. I don't know of any more recent a mockup.

Told by whom? What parts of the mockups are outdated? News to me.

I was informed by Michael and The_8192 on the TC IRC channel that the orphanage bar had been prototyped previously and then discarded as less usable than the current pseudo-group-orphan-tabs approach. With that out, the main difference I see in the UI is the tab icon (favicon, not the thumb) has a transparent background while clipping the thumb. Since the canvas element seems to have zero support for stenciling of any kind, I have no idea how to implement this. PS: Looking closely at the mockup, it looks like the background is not transparent when the tab items are in a stack configuration. Is intended, or a mistake?

The main intent of this bug is to determine whether making the Panorama background glass is indeed a good idea, or if tweaks like making it less translucent, or more textured, etc., would make it look better. This bug was created as a response to such discussion on bug 586679, just for your reference. The new tab group at the bottom being reconsidered since that mockup was created is immaterial for this discussion here.

Mitcho is exactly right.

Can't block on "determine." If the tabcandy + ux team determines that change IS needed here, this bug should morph to spec that change, and should be renominated for blocking.

Just tried enabling transparency and this is the result on Win7 with a fairly translucent Win7 theme. Since we're not writing anything directly onto the background without a container I don't see any problems with legibility and design-wise it seems a good deal better than the current situation. Ignore the still visible navbar, that's related to another bug. Option #2 looks nice as well, but it seems a little late to try implementing it since it may not be so trivial given that the we would have to overwrite the frame and return it to normal when leaving TabCandy. I simply added these lines to tabcandy.css html, body, #bg{ background:transparent; } #bg{ display:none; }

This is now pretty much BLOCKING Bug #585689, which has issues with platforms that can't do a drawWindow on a window without returning a transparent image. The problem is that we can't capture and lateron draw a "INSERT AERO SHADING HERE" color, so we can't cover the TabCandy BG. If that BG is transparent that's not much of an issue, but if it is there's little to be done since adjusting the margins surround the TabCandy iFrame would be too slow. The only thing left then would be to draw the whole TabCandy iframe into a Canvas for fast clipping.

Oops, wrong Bug, Bug #597713

OK, we chose another route, so this isn't as urgent anymore (the navbar becomes part of the thumbnail).

Olivier, do you still plan/want to work on this? I can take it otherwise. The only change needed follows. (The rest of the patch is just trailing whitespace removal.) -#bg { +#bg:not(:-moz-system-metric(windows-compositor)) { background: url("chrome://browser/skin/tabview/grain.png") repeat scroll center top, -moz-linear-gradient(center top , #CCD9EA, #C7D5E7) repeat scroll 0 0 transparent; } The screenshot also experiments with changing the tab group background color to white when glassed, but that isn't included in the patch.

I would like us to try this out in the nightly builds for awhile. It really helps to visually establish the difference between the browser level and the tab level. With this approach it Tab view feels considerably more like a place in between places. There is a downside in that the glass will allow the background complexity to bleed through. But this also has the effect of making the product feel lighter.

Comment on attachment 497963 [details] [diff] [review] patch What's the effect of this on lightweight themes?

(In reply to comment #15) > Created attachment 497957 [details] > updated screenshot of glassed panorama on win7 Would we want to increase the shadow on groups and tabs here too?

Will this have an adverse effect on perf? Also, will it work with the "impostor" technique Sean is using in bug 617454?

Comment on attachment 497963 [details] [diff] [review] patch I haven't actually seen it, but I think this is going to look quite unreasonable with a lightweight theme applied, so you'll need to set a background in that case. I'm also somewhat concerned about performance, but roc will know more about that.

It's hard to predict perf impact. It might well be OK. Just have to measure it.

>What's the effect of this on lightweight themes? lightweight themes should eventually be special cased so that they cover the entire window frame. However, I don't think we are anywhere near being ready for that yet (I believe all of them are currently 3000px x 200px)

This change may make bug 613606 considerably more noticeable.

(In reply to comment #23) > >What's the effect of this on lightweight themes? > > lightweight themes should eventually be special cased so that they cover the > entire window frame. However, I don't think we are anywhere near being ready > for that yet Exactly.

This addresses personas quite elegantly. I'll attach a screenshot shortly.

Looking good!

Comment on attachment 506115 [details] screenshot with personas can we remove the hard edge at the top of the gradient for a smoother transition? Overall this looks great.

(In reply to comment #27) > Created attachment 506115 [details] > screenshot with personas Just to be clear: as far as I can tell from this screenshot, there's no actual glass action here... it's just a patch to fix the interaction with the personas? Or is the background actually slightly translucent?

(In reply to comment #30) > (In reply to comment #27) > > Created attachment 506115 [details] > > screenshot with personas > > Just to be clear: as far as I can tell from this screenshot, there's no actual > glass action here... it's just a patch to fix the interaction with the > personas? Or is the background actually slightly translucent? In which case, this patch is actually a win-specific patch for bug 593388 (which would wontfix bug 590378).

>#bg:not(:-moz-system-metric(windows-compositor)) I think this line applies the styling if glass has been disabled, but I'm not entirely sure.

(In reply to comment #30) > (In reply to comment #27) > > Created attachment 506115 [details] > > screenshot with personas > > Just to be clear: as far as I can tell from this screenshot, there's no actual > glass action here... it's just a patch to fix the interaction with the > personas? Or is the background actually slightly translucent? When a persona is enabled, we don't use glass when in tab view, since it's too difficult to make the persona fade out. (In reply to comment #29) > Comment on attachment 506115 [details] > screenshot with personas > > can we remove the hard edge at the top of the gradient for a smoother > transition? Overall this looks great. I tried, but we'd have to remove the grain texture of the tab view background, and the bottom of the gradient would have to be well above the bottom of the persona, since I couldn't get the background to align perfectly with the top of the persona.

Comment on attachment 506114 [details] [diff] [review] patch v2 >+ -moz-linear-gradient(center top, rgba(255,255,255,0), #CCD9EA 200px, #C7D5E7); Why rgba(255,255,255,0) rather than #CCD9EA with an alpha value of 0? Where does the 200px number come from? Is this the height that submitted persona headers need to have at a minimum?

(In reply to comment #34) > Comment on attachment 506114 [details] [diff] [review] > patch v2 > > >+ -moz-linear-gradient(center top, rgba(255,255,255,0), #CCD9EA 200px, #C7D5E7); > > Why rgba(255,255,255,0) rather than #CCD9EA with an alpha value of 0? To avoid more gray transition than necessary when the persona is primarily of a color complementary to #CCD9EA, but I'm fine with changing it, if using #CCD9EA with an alpha of 0 actually looks better. > Where does the 200px number come from? Is this the height that submitted > persona headers need to have at a minimum? AUIU, yes. http://www.getpersonas.com/demo_create

(In reply to comment #35) > > Where does the 200px number come from? Is this the height that submitted > > persona headers need to have at a minimum? > > AUIU, yes. http://www.getpersonas.com/demo_create It says "should be 3000px wide x 200px high", which is vague, but it goes on to say rather clearly that "images over 3000px x 200px will not be approved" (although I suspect a higher but not nearly as wide image would be approved).

(In reply to comment #36) > It says "should be 3000px wide x 200px high", which is vague, but it goes on to > say rather clearly that "images over 3000px x 200px will not be approved" > (although I suspect a higher but not nearly as wide image would be approved). Yeah, that does seem to occur. However, since the guideline is to provide a 3000px x 200px image, I don't think we need to guarantee that the transition works perfectly with personas of any shorter height.

Depends on how effective the guideline is. Did you take a shot at wading through the gallery?

(In reply to comment #38) > Depends on how effective the guideline is. Did you take a shot at wading > through the gallery? I tried a dozen personas in each of the "Up & Coming", "Popular", "Just Added", and "All Personas" sections of getpersonas.com, and all the header images were exactly 200px in height, except one that was over 200px in height.

Comment on attachment 506114 [details] [diff] [review] patch v2 >+ -moz-linear-gradient(center top, rgba(255,255,255,0), #CCD9EA 200px, #C7D5E7); "center top" seems redundant.

Frank, can you post a quick screenshot of a profile without a persona, akin to the first screenshot attached over the windows logo?

(In reply to comment #40) > Comment on attachment 506114 [details] [diff] [review] > patch v2 > > >+ -moz-linear-gradient(center top, rgba(255,255,255,0), #CCD9EA 200px, #C7D5E7); > > "center top" seems redundant. Addressed in v3, and that's the only change made from v2. (In reply to comment #41) > Frank, can you post a quick screenshot of a profile without a persona, akin to > the first screenshot attached over the windows logo? Created attachment 506247 [details] screenshot without personas The screenshot was taken while dragging the cursor to create a new tab group. If you want to change the borders of the action button container while glassed, that can be addressed in a separate bug.

(In reply to comment #42) > Created attachment 506247 [details] > screenshot without personas Oh I just noticed that the screenshot is actually of a glitch of the action button container's right border being visible. Uploading correct screenshot now.

>approval2.0? Note that I would really like this to land so that we can take some screen captures for a panorama video. While this bug (and the video itself) doesn't block, I think this visual change is significant enough that it really impacts how sleek and modern panorama feels on Windows. Also makes for some really fantastic press shots (sans windows logo of course :)

Oh, and improves the conceptual model as well (not to lead with a marketing objective over a UX one)

(In reply to comment #45) > Created attachment 506250 [details] > screenshot without personas I'm slightly concerned that the non-personas version here may be too transparent... previously when we discussed this aero glass option, an idea that was floated was to keep the panorama background but to make it 50% opacity or so... Alex, what do you think? The concern is that if there are a bunch of other windows below Panorama, not the Windows desktop, that Panorama itself would look cluttered and confusing.

(In reply to comment #48) > The concern is that if there are a bunch of other windows below Panorama, not > the Windows desktop, that Panorama itself would look cluttered and confusing. I once tried this via userchrome.css. I thought that it was fine while the window was restored, but it did become confusing when the window was maximised. I think it would be helpful if it did have a 50% opaque background when maximised.

I just tried to test the maximized view by pressing win+up to maximize the window, but it entered search mode upon pressing the [win] key. Why do we have [win] mapped to panorama search? (Filing a bug shortly if there isn't one already.)

(In reply to comment #50) > I just tried to test the maximized view by pressing win+up to maximize the > window, but it entered search mode upon pressing the [win] key. Why do we have > [win] mapped to panorama search? (Filing a bug shortly if there isn't one > already.) This is the first I've heard of that... please file. :/

(In reply to comment #51) Filed bug 628165.

Pushed. http://hg.mozilla.org/mozilla-central/rev/0fde0139fb6f Discuss any pixel tweaks as separate followup bugs, not as comments.