Overview

Over the past few years the Firefox team has put a significant amount of effort into creating icon libraries for each of the major desktop platforms. The purpose of this project is to organize, refactor, and upstream these resources into the Mozilla platform to streamline the workflow of Firefox developers, extension authors, themers, and the broader Mozilla community.

Goals

Benefit to Firefox Developers and UX team

• Make it easier to review all current and new artwork for flaws
• Make it easier to quickly source artwork for a new platform or OS theme. We theoretically can land the same file a design firm delivers, avoiding problems like chopping/naming/recombining by hand and version ambiguity.
• Better control over the integrity of the resources, in the event that someone introduces any embedded color profile, compression artifacts, or some other type of regression

Benefit to the Mozilla Community

• Allow any Mozilla based app to leverage a comprehensive icon library for easy cross platform visual integration
• Reduce the significant amount of redundancy in the currently checked in files by centralizing all of our icon resources. Toolkit currently contains a ridiculous amount of redundancy since icons are always packaged directly alongside the code that uses them.

Benefit to Firefox Extension/Jetpack Authors

• Cross platform visual integration by default
• Easy browsing of available icons by navigating to about:icons (just copy the moz-icon://iconname url and you’re done!)
• Ability to leverage the ongoing investment and effort that Firefox puts into the creation of standard icons for each platform (icons are actually kind of expensive)

Benefit to Themers

• Similar to personas, the ability to drastically change the appearance of Firefox (and other mozilla based applications) without any knowledge of CSS, RDF, Guids, xpi's etc. [however changing aspects like icon size, layout, padding, etc will still require these skills]
• The ability to do slightly more advanced things that you can’t do with personas, like have a different appearance for active and inactive tabs.
• The ability to create artwork that effects not just Firefox but any extensions leveraging it (assuming they want to create a full stencil of icons)
• Ability to create artwork that can be very easily adapted for new versions of Firefox (just need to add a few extra icons to the sheet, perhaps delete a few, tools to help with updating are described below)
• Ability to create artwork that will fail gracefully in future versions: missing resources default to the style of the platform

Potential Changes

Stencil files

• These are very large png files that contain every icon for a particular OS or OS theme arranged in a grid, likely with some surrounding explanatory text (perhaps as a separate photoshop layer to reduce the size of the final file). These large files are created by themers and design firms, and are (possibly) directly checked in. The Mozilla platform has a stencil file displaying all of the standard icons available to everyone, and each app can provide an additional stencil file for the few extremely specific icons that they provide in addition.
• File names would likely be [Scope]-[OS]-[OS theme] for example mozilla1-9-2-osx-aqua.png, Firefox4-windows-xp-luna.png

Icon manifest

• This maps moz-icon:// urls to a particular a moz-image-region in a the appropriate stencil file.
• moz-icon URLs should be short and descriptive, but will need to define if they are part of the platform or app specific, so for instance moz-icon://star-16 is available to any app built on the mozilla platform, while moz-icon://firefox/masquerademask-32 is specific to Firefox using the format [optional scope]-[literal name]-[size]-[optional special state]

Performance magic (very much to be determined)

• There are a lot of ways we could do this, but essentially we take in a stencil file and a manifest file and do something along the lines of:
  • Prior to check in automatically generate a series of images similar to the current toolbar.png using a second manifest that knows which files are commonly loaded together
  • At build time automatically generate grouped images based on actual metrics of which files are loaded together
  • At run time intelligently cache icons in memory, stream in parts of the stencil file without loading the entire thing, and only access the file once per group of icons that need to be loaded
• We could start with one approach and then over time adjust to a more automated approach. Theoretically returning images to calls with moz-icon urls could have even better performance than our current approach since we often load the same image (different files) multiple times, and I believe don't cache any common files in memory, but load them over and over again.
• Having a moz-icon protocol for access is key, all of the future performance enhancements to loading icons build on some form of existing intermediary description of the file

Literal naming

• Every moz-icon:// URL should use a very literal name of what is actually pictured, so for instance moz-icon://puzzlepiece-32 instead of "extension-32" or moz-icon://star-16 instead of "bookmark-16" (Firefox uses stars for bookmarks, while thunderbird for staring emails, etc).

about:icons

• Content area page accessible in Firefox to view all of the available standard icons of the Mozilla platform, and any extra icons that are very Firefox specific

Err on the side of uplifting to a centralized stencil file in toolkit

• Currently icons are packaged based on the code that uses them, and they are checked in based on the most logical place for that code to live. For instance, the star icon (despite being very general purpose) lives in browser instead of toolkit because Firefox uses it to represent a bookmark. With this new system icons would be added to toolkit based on if they are themselves general purpose (common symbols, metaphors, etc.)

Compatibility fall back

• If a third party stencil only defines a limited number of icons. For instance the stencil might define all of the Firefox 3 icons, but not the 3.5 set which added private browsing mode, or all of the Mozilla platform standard icons, but none of the Firefox specific ones. In this case the icons that are provided are still used, but the theme falls back to the platform native icons for anything that isn’t defined.

Random crazy ideas

Stencil tag

• A small 2d barcode in the corner of the stencil that specifies which version of the Mozilla platform’s manifest file should be used. The great thing about personas is that they are just an image file, they aren’t packed into an xpi with a lot of extra implementation level cruft.

Stencil upgrade kit

• This is a simple web app or Firefox extension that takes a stencil for one version of the Mozilla platform, and outputs a file that contains all of the same artwork but positioned for the next version of the Mozilla platform (using the two manifest files), with whitespace for the new icons that need to be created.

Stencil diff

• Dolske was mentioning to me that dbaron wrote a really cool tool that inspects two image files and uses SVG to highlight the differences for interpreting ref test failures. Since mxr is always going to show that all of the icons for a particular platform or OS theme were changed with each check in (they are all contained in the same stencil file), we could repurpose the tool to display what changed.

Easy stencils

• This is a really simple stencil (paired with an equally short manifest) that only contains the icons shown in the main window of a particular application, and the background surfaces. For instance, the easy stencil could contain the default Firefox window containing the common main window icons, an active tab and an inactive tab, etc. Or the default Thunderbird window. The themer basically draws their new appearance right on top, and (combined with compatibility fall back) they can very easily alter the appearance of the application (but depending on what the easy stencil defines, probably not other mozilla platform apps). Sort of a personas+, in that they can specify the appearance of particular elements (like the active tab), but are otherwise just creating a picture of the application they would like to use.

Example Scenarios