Closed
Bug 494927
Opened 16 years ago
Closed 15 years ago
toolbarbutton image transparency/anti-aliasing should accommodate different background colors
Categories
(Firefox :: Theme, defect)
Tracking
()
RESOLVED
FIXED
Firefox 3.7a1
Tracking | Status | |
---|---|---|
status1.9.2 | --- | beta1-fixed |
People
(Reporter: myk, Assigned: shorlander)
References
Details
Attachments
(4 files, 3 obsolete files)
17.87 KB,
image/png
|
Details | |
173.92 KB,
image/png
|
Details | |
7.97 KB,
image/png
|
Details | |
34.44 KB,
image/png
|
beltzner
:
approval1.9.2+
|
Details |
Personas ships its own version of all the standard toolbarbutton images in order to make them look good when a persona is selected and the background behind the images is a different color than the standard Mac grey.
Those transparency/anti-aliasing changes can be done in a way that doesn't compromise the appearance of the images when the standard Mac grey is the background color, and we should apply those changes to the core images, so Personas doesn't have to ship its own version of the images, and they still look good when it (or any other extension) changes the background color of the toolbars.
Comment 1•16 years ago
|
||
So would attachment 379755 [details] look identical to the current Toolbar.png on the Mac grey, or is there more work to be done?
Comment 2•16 years ago
|
||
The latest toolbar PNGs I have created for OSX are now pretty much spot on to the default buttons when over the default grey. Their transparency was chosen to accomodate many variants of background colors (extreme light and extreme dark being major tests) and must remain flexible in that way.
That said, they are very close to the originals.
Comment 3•16 years ago
|
||
Attachment 79755 [details] isn't ready, unfortunately. Some icons incorrectly shift down in the hit state.
Comment 4•16 years ago
|
||
Assignee | ||
Comment 5•16 years ago
|
||
I actually do not think we should be doing this.
The toolbar buttons for OS X are designed specifically to match the default toolbar buttons found in Leopard. We vary our shape by making them rounded but the styling remains the unifying factor.
The button gradient is supposed to be solid from #fefefe to #a9a9a9. If they are transparent the color will shift based on where the toolbar is located or weather or not small or large icon mode is enabled.
Also these appear to have a raised appearance. Highlighted edge?
We also have another bug 504160 that touches on this and the inactive appearance.
Comment 6•16 years ago
|
||
(In reply to comment #5)
> The button gradient is supposed to be solid from #fefefe to #a9a9a9. If they
> are transparent the color will shift based on where the toolbar is located or
> weather or not small or large icon mode is enabled.
The discrepancy that your sceenshot shows is unnecessarily big. If done properly, this shouldn't really be noticeable, as the toolbar gradient is very flat.
Assignee | ||
Comment 7•16 years ago
|
||
(In reply to comment #6)
> The discrepancy that your sceenshot shows is unnecessarily big. If done
> properly, this shouldn't really be noticeable, as the toolbar gradient is very
> flat.
I agree you can probably get "close enough" for it to not be terribly noticeable.
I think what you will run into is that you have to make it so opaque(white at 95% on the top, white at ~30% on the bottom) that you can't really see anything(or a lot) through it anyway.
I guess it depends on how much of the background Persona it would be ideal to show through.
Comment 8•16 years ago
|
||
I also don't understand why we'd want this. What's wrong with Personas shipping its own icon set?
Comment 9•16 years ago
|
||
It creates extra work every time we touch Toolbar.png.
It's the wrong thing to do for third-party themes.
Comment 10•16 years ago
|
||
The extra work isn't great, but now that we have Stephen working on this stuff full time.. :)
I'm not sure we are going to be able to create buttons that work perfectly both for the default theme, and for a wide range of personas. So I think this might be a case where the extra work is actually worth it, since we don't want to compromise either the default or personas appearance.
Assignee | ||
Comment 11•16 years ago
|
||
I don't necessarily think the right thing to do is degrade appearance to avoid shipping two(or more) toolbar images.
Could we maybe streamline how we build the toolbar buttons so that it is less work to maintain? Build a default button mostly out of one image or with border-radius, border-image, box-shadow and css gradients and overlay the glyphs on top of that?
Alex is right that we have more resources available now as well :)
Comment 12•16 years ago
|
||
We don't want to reduce the work this requires in the Personas team; it shouldn't require extra work at all. Personas should not (have to) mess with the theme like this. It doesn't know which theme is in use, and it shouldn't act like it does. It's the wrong approach.
Assignee | ||
Comment 13•16 years ago
|
||
I understand why you think it is wrong, but I have to disagree.
We are already designing around the aesthetic constraints set by the OS. In this case OS X which has a fairly solid and established style. The default theme is designed to look good within these constraints. It's not realistic to expect the design to retain its integrity when the background changes underneath it and the colors change around it. The foundation upon which it is built suddenly becomes unstable.
We could certainly compromise the design and make it kind of(or even mostly) work well in either situation. Or we could design specifically for each situation and get a better looking and more cohesive result. My opinion is that we shouldn't have to compromise the design so that Personas can remain unaware of its surroundings.
If Personas really must remain indifferent to the theme I think we should just leave the theme as is with opaque buttons and Personas can display around them.
Working on the Windows Theme Revamp I have kept this in mind. Partially out of necessity for Windows variable UI elements and partially for Personas. I can get something that works "ok" in lots of situations but I could get something that is actually good if the interface could change based on what was behind it. These are things I think we should consider.
I think if we are bringing Personas into Firefox then we must consider about how it affects the look of the overall product. That is, after all, what it is for. Not "should the default theme play nice with Personas" but "should Personas play nice with the default theme".
Comment 14•16 years ago
|
||
We're losing focus. We already agreed that the default toolbar appearance shouldn't be degraded, and that it doesn't have to be. Can we continue from there, i.e. comment 7? Anything that maintains the default appearance while at the same time allowing more flexibility in the background will be a step forward. The ideal solution might include two or more Toolbar.png versions (which will be part of the theme and not of Personas, though). But right now that small step forward is what I'm interested in.
Comment 15•16 years ago
|
||
Comment 7 sound to me as if the compromise that doesn't degrade the look won't work as well for Personas as their existing image used to.
> The ideal solution might include two or more Toolbar.png versions
> (which will be part of the theme and not of Personas, though).
I think that's the way to go. How about this?
- Introduce an attribute called custombackground="true" that is set when a
custom Persona is in use.
- Make the default theme use a transparent toolbar image only when this
attribute is set.
- Encourage other theme developers to build background-aware toolbar icon sets
and to make use of that attribute.
I think that solution satisfies all the requirements we've worked out in the previous comments, which are
- Personas shouldn't hack around the default theme.
- Ideally, Personas should work with 3rd-party themes as well.
- Personas wants transparent toolbarbuttons.
- The default theme doesn't want them.
Comment 16•16 years ago
|
||
(In reply to comment #15)
> Comment 7 sound to me as if the compromise that doesn't degrade the look won't
> work as well for Personas as their existing image used to.
What's that assumption based on?
Attachment 379755 [details] deviates from the standard button appearance, according to comment 5.
Attachment 392494 [details] does look good to me. Was that meant to be a negative example?
Comment 17•16 years ago
|
||
(In reply to comment #16)
> Attachment 392494 [details] does look good to me.
OK, if that's fine with the Personas guys, we can use that.
> Was that meant to be a negative example?
That's how I interpreted
> I think what you will run into is that you have to make it so opaque [...]
> that you can't really see anything(or a lot) through it anyway.
Comment 18•16 years ago
|
||
Myk and/or Sean (I don't really know who's responsible), does attachment 392494 [details] look like such a Toolbar.png would satisfy your needs?
Assignee | ||
Comment 19•16 years ago
|
||
(In reply to comment #16)
> Attachment 392494 [details] does look good to me. Was that meant to be a negative
> example?
Sort of negative. What I was trying to get at was that the current icons in Personas look great with Personas. They don't match the defaults. The more they do match the defaults the less they will look good with Personas.
Comment 20•16 years ago
|
||
(In reply to comment #19)
> What I was trying to get at was that the current icons in
> Personas look great with Personas. They don't match the defaults.
That's somewhat contradictory, as external consistency should be part of the evaluation. Attachment 392486 [details] surely is suboptimal, even with a Personas background, so I wouldn't consider it great. Personas intentionally deviates from the OS standards, of course, but it seems to me that more consistency is possible and desirable.
Comment 21•16 years ago
|
||
Dao/Stephen,
Yes, that does work - fairly similar to what is currently in Personas 1.2.1 for OSX. It appears to have more of an opaque back gradient and translucent bordering over the current toolbar.png I created. Looks good. My test is usually seeing what they look like on pure white or pure black backgrounds to see them in extreme situations. Could we see that?
Assignee | ||
Comment 22•16 years ago
|
||
(In reply to comment #21)
> My test is usually seeing what they look like on pure white or pure black
> backgrounds to see them in extreme situations. Could we see that?
I tweaked it a little more and these look almost identical to what we have on the default toolbar gradient. Get like a ~10 point color shift between lightest and darkest colors.
Definitely more opaque though. So you lose some of the Personas background. Ends up being a little bit more of a subtle hint of the background.
Attachment #392494 -
Attachment is obsolete: true
Comment 23•16 years ago
|
||
(In reply to comment #22)
> Translucent on Various Backgrounds - 002
Would you please create Toolbar.png and Toolbar-rtl.png based on that?
(The subtle hint of the background is exactly what we should always have aimed for, fwiw. But again, this isn't set in stone, and we can re-evaluate later if we should have a separate set of images for Personas.)
Comment 24•16 years ago
|
||
>Created an attachment (id=392738) [details]
>Translucent on Various Backgrounds - 002
This doesn't really feel right to me, it seems to be as much about the OS X button aesthetic as it is about the background. Ideally the personas UI should be sort of pure glass, so the functionality is there but the background can really shine through. For instance, on the pink background I keep hearing this conversation:
Toolbar: "PINK!"
Button: "Platform Native!"
Toolbar: "No.. PINK!"
I'm personally far more interested in our overall objective being pixel perfect and having the best possible appearance in each situation (at the cost of work, extra code, and extra images).
Every time we cut corners to create a single solution that is simpler or universally compatible, or based on OS resource extraction, we get slammed for not having any design sense. And I think to some extent this is fair, because instead of designing exactly what we want, we create a compromise.
Comment 25•16 years ago
|
||
(In reply to comment #24)
> Ideally the personas UI should
> be sort of pure glass, so the functionality is there but the background can
> really shine through.
The more domination of the background over individual controls, the less usability (depending on the background of course, which we can't control).
Comment 26•16 years ago
|
||
>The more domination of the background over individual controls, the less
>usability (depending on the background of course, which we can't control).
I agree, but I think the lower mockup in attachment 392552 [details] works well. The buttons and glyphs have a strong black and white outline (considerably stronger than we would consider useing for a normal theme) so they remain well defined on a range of backgrounds, and the center areas are clear enough to let the hot pink (or whatever) still dominate the design.
Comment 27•16 years ago
|
||
Actually looking at it again I would probably lighten the inside of the buttons a little, but the edges and glyphs look good.
Comment 28•16 years ago
|
||
I've filed bug 508761.
Now let's move forward with fixing this bug, replacing the existing Toolbar.png with a more flexible one without compromising the default appearance. This is a wise thing to do even without the Personas context, because other extensions could do something similar as mentioned in comment 0.
Comment 29•16 years ago
|
||
I agree with Alex in comment #26 about the glass with the light/dark edges. Those edges are key in maintaining the UI structure. Similar to where I was going with my pure CSS mockups: http://mozilla.seanmartell.com/personas/testing/. If we went for a pure glass look for the elements, it still comes down to faith in the end user to create a useable design.
As for the buttons, I like the latest set shown, but I'm a bit concerned with how opaque the background gradient is. Having the interior of the button somewhat opaque is fine, and pretty much necessary really for the range of artwork. I think the main issue is we're trying to match the gradient of the buttons to their current/default state. They weren't designed with "transparency on multiple backgrounds" in mind and I don't think we'll get to an ideal solution unless we either have two versions of the UI graphics or revisit the default look entirely (as in the vista/win7 mockups).
Regardless of what we do, there will be many designs that break the legibility of the UI in some form.
That said, we're going to be looking into creating an online tool where you can upload your Personas and test them by toggling the different UI over top of the image so you can get a sense of how it will play prior to submitting it.
Comment 30•16 years ago
|
||
A nice thing to do would be to use pure glass and then blur the toolbar background that's directly behind the toolbar buttons. We can do that with SVG filters once we have access to the BackgroundImage, bug 437554.
Comment 31•16 years ago
|
||
(In reply to comment #29)
> If we went for a pure glass
> look for the elements, it still comes down to faith in the end user to create a
> useable design.
That's bound to fail. Also, these comments belong to bug 508761.
Assignee | ||
Comment 32•15 years ago
|
||
Here is the ever so slightly translucent Toolbar.png. Required quite a bit of graphical acrobatics to accommodate each state. I feel moderately good about how it meshes on the default background. Not so good about how it looks with Personas. Bug 508761 is going to be required to get the best results.
I added a new row of inactive state buttons for bug 504160. This moved the toggle state for the bookmarks and history sidebars buttons down.
Also added buttons for fullscreen enter and restore for bug 505699.
We don't actually use the conjoined Refresh/Stop graphic anywhere do we?
Comment 33•15 years ago
|
||
(In reply to comment #32)
> We don't actually use the conjoined Refresh/Stop graphic anywhere do we?
Nope.
Comment 34•15 years ago
|
||
Attachment #394335 -
Attachment is obsolete: true
Comment 35•15 years ago
|
||
Assignee: nobody → stephen
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7
Comment 36•15 years ago
|
||
(In reply to comment #32)
> I added a new row of inactive state buttons for bug 504160. This moved the
> toggle state for the bookmarks and history sidebars buttons down.
Uh, I think Dão forgot about this when he landed it. Anyway, I'll fix it in bug 504160.
Comment 37•15 years ago
|
||
Backed out, we've got a 2.5% Mac Txul regression.
http://hg.mozilla.org/mozilla-central/rev/6c04c1cdedcb
http://hg.mozilla.org/mozilla-central/rev/c2eafac4f910
So the possible reasons are:
- more transparency (unlikely that it's the cause)
- bigger size (36KB -> 58KB) (very likely IMO)
- different compression (?)
- something else?
Comment 38•15 years ago
|
||
(In reply to comment #36)
> (In reply to comment #32)
> > I added a new row of inactive state buttons for bug 504160. This moved the
> > toggle state for the bookmarks and history sidebars buttons down.
>
> Uh, I think Dão forgot about this when he landed it.
Sorry, I completely missed that you had also changed the regions.
Updated•15 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 39•15 years ago
|
||
Attachment #394375 -
Attachment is obsolete: true
Comment 40•15 years ago
|
||
Landed the optimized version:
http://hg.mozilla.org/mozilla-central/rev/777517eea188
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
Attachment #394473 -
Flags: approval1.9.2?
Comment 41•15 years ago
|
||
Comment on attachment 394473 [details]
with unused stuff removed and file size optimization
a192=beltzner
Attachment #394473 -
Flags: approval1.9.2? → approval1.9.2+
Updated•15 years ago
|
Keywords: checkin-needed
Comment 42•15 years ago
|
||
status1.9.2:
--- → beta1-fixed
Updated•15 years ago
|
Keywords: checkin-needed
Updated•15 years ago
|
Target Milestone: Firefox 3.7 → Firefox 3.7a1
You need to log in
before you can comment on or make changes to this bug.
Description
•