This weekend I decided to make a bacon persona. It was really easy to do; I just made a couple of JPEGs and submitted them to the getpersonas.com site. Result:

If you want to try it out, just:

1. Install Personas from getpersonas.com.
2. Select “Bacon” from the Personas directory. It’s under the “Other” category. (At the moment, it’s also at the top of the “Recent” subsection.

Mmm, bacon.

Just for fun, I thought I’d convert my favorite Firefox Flicks video to the APNG format….

The compression algorithms in APNG and AGIF are not really suited for straight conversions from video; doing so tends to result in large files (this one has about 340 frames at 86×75, weighing in at 990KB). Similarly, some images are better suited to JPEG or SVG… One just needs to use the right tool for the job. Hmm, <video> tag, anyone? :-)

I also made a full-resolution (but still cropped) 230×200 version, although it’s a wee bit large (pun intended). So I’ll just link to it.

The conversion itself was a fairly simple process… I basically used “mplayer -vo png wheee.mov” to convert the QuickTime video to a pile of PNG images, dragged them into my APNG Edit window, and let it chew through them.

This version adds the ability to color tabs based on the site’s favicon. (This is off by default; you can enable it in the extension’s preferences.]

Here’s what it looks like with a few select sites:

It’s just averaging the pixels in the favicon, which is why Flickr’s color is purple (a blend of the pinkish-red and blue in the icon). It would probably be better to build up a histogram, and then select the most prominent color… But averaging works fairly well and is easy. :-) The code is smart enough to ignore pixels that are almost white or black, which would otherwise pollute the average color. I’ve noticed that a surprising number of sites have black-and-white site icons (eg BBC), so Chromatabs will fall-back to the old method of picking a color for the site in such cases. [Grayscale confuses it sometimes, though.]

I’ve found that using the favicon to determine colors for tabs seems more useful, because the color actually has some relevance to the site. Of course, for sites without an favicon it doesn’t help at all.

Oh, and one more thing (as Steve Jobs is wont to say)…

I’ve been thinking about some ideas to improve the visibility of the foreground tab, which is sometimes hard to pick out (especially with colored tabs, although I think even the default theme is too non-distinct). Here’s a mockup of what I’m currently thinking about — subtle gradients on either side, vaguely as if the neighboring tabs are curving into darkness.

(*cough* I just noticed I styled the wrong tab in the mockup, as the URL bar clearly says “www.blogspot.com” and not “www.flickr.com.” Oh well, no one is prefect! [sic :)])

The Mozilla offices have been humming with activity this week, with the influx of folks arriving for the Firefox Summit. We’ve been having some fascinating discussions on a variety of topics and ideas for the future. On that note, a few weeks ago I wrote up some thoughts I had for an evolution of Firefox 2’s Live Titles (aka “microsummaries”), in the form of adding graphics to a traditionally text-based feature. [Wonder Twin powers activate.]

Here’s a mockup of what Graphical Microsummaries might look like:

What’s this thing do?

This was a little surprising to hear at first, but it makes sense. Even though we’re just coloring tabs, unless you already know what’s going on it probably seems like the tabs are being randomly colored. This would be a significant issue if this was a default feature that shipped with Firefox. [As an extension, probably not so much.]

It’s hard to determine which tab is active.

I think this originates with the default theme itself, in that it can be hard to find the active tab even when they’re not colored. However, colorizing the tabs clearly makes things worse. You have to pick out somewhat-subtle brightness differences between different colors, and the myriad of colors is visually distracting.

I had been thinking that simply changing the tab’s luminance would be enough to make it look active, but I don’t think that’s enough. Some other cue needs to be provided. Maybe add a border, or design a stronger 3D look? The difference in luminance could be increased, but then tabs would seem to change color when they become active.

The colors of site X and site Y are too similar.

The extension generates hundreds of different colors, but the reality is that anything more than, say, a couple dozen is going to be too subtle. You can usually see the difference with close inspection, but at a glance the hues can look the same.

Is there a good solution to this? I’m not sure, but trying to give millions of web sites unique and differentiable colors doesn’t seem like the way to do it… A tweak that might help is to only color a tab when a site is open in at least one other tab. But I think this would probably end up being confusing to some users, and it still doesn’t address the problem of two sites having nearly identical colors. [Well, it might help a little in that you wouldn't see the problem as often -- on average -- until you open 2 tabs for each site.]

Future directions…

Instead, for future work, a cleaner problem to tackle might be to give groups of tabs (eg, those showing same site) a unique color. The color wouldn’t be persistent, so the same group might get a different color the next time you open them. The point is that you could always pick a unique new color up until you have a few dozen tabs open. And even then, you could still distinguish groups spatially (”the red group on the left is Yahoo tabs, and the red group waaaaaaaaay on the right is Google tabs”).

I think this is actually closer to the original problem I wanted to solve, which was having a bunch of Bugzilla and LXR tabs open… I want to tell the difference between the two, but don’t really care what the exact color is.

This would also be an opportunity to use a color palette that’s more esthetically pleasing than random colors.

Other suggestions for Chromatabs included making it work with Tab Mix Plus, choosing the color from the favicon, and coloring the menu entries for bookmarks, history, and the tab list. Using Munsell palettes also seems like a great idea.
Other extensions

We mentioned the first two of these in the original labs.mozilla.org post, and readers brought the last two to our attention:

• Colorful Tabs
• Aging Tabs
• PageStyle2Tab
• HashColoredTabs

I thought I’d write a bit more here about how it’s implemented, because it’s doing a few interesting things under the hood…

My first proof-of-concept at colorizing tabs was to just set a background color on the tab, and adjust the tab’s opacity to allow the color to show though. This early result was, well, crap:

The positioning of the elements that comprise the tab’s internal structure caused some white lines, the opacity affected the text and favicon (they got colorized too), and the background color was visible around the tab’s curved borders. I could probably have worked around the first few issues, but the tab’s curves were an interesting problem… In Firefox 2, the default theme uses chrome images to make the tabs look nice and stylish (curved ends, and a bit of a shiny vertical gradient). You can simulate coloring an image by lowering its opacity and allowing a background color to bleed-though — but if the image already has transparent regions the background color comes through at full-strength.

So, to make a colored tab look nice that approach won’t work. Drat. It would be really easy to colorize a tab with Photoshop, but you can’t do that in the browser. …or can you? The thought struck me that the <canvas> tag, which Firefox supports, gives you a pixel region upon which you can draw things, and it has a compositing mode that allows you to draw only on regions that already have content (ie, that are not transparent). So, that’s what Chromatabs is doing. It dynamically renders new colorized chrome images for each tab. First, it uses the tab’s original chrome image to produce solid-color version via compositing, and then blends it back into the original chrome image by overdrawing with reduced opacity (ie, partial transparency). And it’s all driven by Javascript!

This might also be an interesting technique for themes to use. Currently, if a theme wants to have versions with different colors, the author must create each as separate themes. If the theme could colorize itself at runtime, you’d just need one version of the theme. Plus, the user would be able to pick the exact shade of color they want. Everyone wins.