591652 - Make the tab view (Panorama) background transparent to reveal glass (if enabled) on Windows

Status: RESOLVED FIXED

(Firefox Graveyard :: Panorama, defect, P3)

Description

[Michael Yoshitaka Erlewine [:mitcho]]

*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

Comment 1

[Michael Yoshitaka Erlewine [:mitcho]]

Requesting blocking.

Comment 2

[Olivier Hamel]

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.

Comment 3

[Aza Raskin [:aza]]

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.

Comment 4

[Olivier Hamel]

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.

Comment 5

[Aza Raskin [:aza]]

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

Comment 6

[Olivier Hamel]

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?

Comment 7

[Michael Yoshitaka Erlewine [:mitcho]]

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.

Comment 8

[Aza Raskin [:aza]]

Mitcho is exactly right.

Comment 9

[Johnathan Nightingale [:johnath]]

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.

Comment 10

[Hans Schmucker]

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; }

Comment 11

[Hans Schmucker]

Attachment: Screenshot of translucent TabCandy window on Win7

Comment 12

[Hans Schmucker]

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.

Comment 13

[Hans Schmucker]

Oops, wrong Bug, Bug #597713

Comment 14

[Hans Schmucker]

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

Comment 15

[Frank Yan (:fryn)]

Attachment: updated screenshot of glassed panorama on win7

Comment 16

[Frank Yan (:fryn)]

Attachment: patch

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.

Comment 17

[Alex Faaborg [:faaborg] (Firefox UX)]

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 18

[Dão Gottwald [:dao]]

Comment on attachment 497963 [details] [diff] [review]
patch

What's the effect of this on lightweight themes?

Comment 19

[Michael Yoshitaka Erlewine [:mitcho]]

(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?

Comment 20

[Ian Gilman [:iangilman]]

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

Comment 21

[Dão Gottwald [:dao]]

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.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 23

[Alex Faaborg [:faaborg] (Firefox UX)]

>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)

Comment 24

[Alex Faaborg [:faaborg] (Firefox UX)]

This change may make bug 613606 considerably more noticeable.

Comment 25

[Dão Gottwald [:dao]]

(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.

Comment 26

[Frank Yan (:fryn)]

Attachment: patch v2

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

Comment 27

[Frank Yan (:fryn)]

Attachment: screenshot with personas

Comment 28

[Michael Yoshitaka Erlewine [:mitcho]]

Looking good!

Comment 29

[Alex Faaborg [:faaborg] (Firefox UX)]

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.

Comment 30

[Michael Yoshitaka Erlewine [:mitcho]]

(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?

Comment 31

[Michael Yoshitaka Erlewine [:mitcho]]

(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).

Comment 32

[Alex Faaborg [:faaborg] (Firefox UX)]

>#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.

Comment 33

[Frank Yan (:fryn)]

(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 34

[Dão Gottwald [:dao]]

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?

Comment 35

[Frank Yan (:fryn)]

(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

Comment 36

[Dão Gottwald [:dao]]

(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).

Comment 37

[Frank Yan (:fryn)]

(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.

Comment 38

[Dão Gottwald [:dao]]

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

Comment 39

[Frank Yan (:fryn)]

(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 40

[Dão Gottwald [:dao]]

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.

Comment 41

[Michael Yoshitaka Erlewine [:mitcho]]

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

Comment 42

[Frank Yan (:fryn)]

Attachment: screenshot without personas

Comment 43

[Frank Yan (:fryn)]

Attachment: patch v3 [r=dao ui-r=faaborg]

(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.

Comment 44

[Frank Yan (:fryn)]

(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.

Comment 45

[Frank Yan (:fryn)]

Attachment: screenshot without personas

Comment 46

[Alex Faaborg [:faaborg] (Firefox UX)]

>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 :)

Comment 47

[Alex Faaborg [:faaborg] (Firefox UX)]

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

Comment 48

[Michael Yoshitaka Erlewine [:mitcho]]

(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.

Comment 49

[Josh Tumath]

(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.

Comment 50

[Frank Yan (:fryn)]

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.)

Comment 51

[Michael Yoshitaka Erlewine [:mitcho]]

(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. :/

Comment 52

[Frank Yan (:fryn)]

(In reply to comment #51)

Filed bug 628165.

Comment 53

[Frank Yan (:fryn)]

Pushed.

http://hg.mozilla.org/mozilla-central/rev/0fde0139fb6f

Discuss any pixel tweaks as separate followup bugs, not as comments.