Here is the video of our Design Lunch session from last week, in which we discussed ideas for identity management in the browser.

The video is almost an hour long, so I don’t know if you have the patience to watch the whole thing… but it does open with me wearing a funny hat and narrating an imaginary legal drama. Then it proceeds to the showing off of screen mockups, followed by vigorous discussion of what the right thing is for Firefox to do in various tricky situations.

This is the first time I tried recording a design lunch using fancy cinematography techniques such as “pointing the camera at the person who’s talking”. I hope it makes it easier to follow.

You may also want to check out Aza’s blog post, which shows the mockups of potential interface designs. They should be easier to read there than they are in the video. You can also find out more at the Mozilla wiki page on the Identity project.


Last week I recorded this video for the students at a university in India, who requested an update on Mozilla Labs projects.

It’s about 20 minutes of me showing screens and talking about Ubiquity, Weave, Jetpack, and Test Pilot. Jetpack and Test Pilot are relatively new so I explain what they’re all about; for older projects Weave and Ubiquity I just highlight a couple of new features.

Thanks to Asa Dotzler for doing the video recording and editing.

You can watch the video on Air Mozilla in either Ogg or mp4 format:

I’d like to thank my readers for their comments on my previous post about bookmarks. It was very useful for me to hear about the bookmark use cases that I had overlooked (for instance, I didn’t realize how important the bookmark-all-in-folder / open-folder-in-tabs feature was to so many of you.)

Now I have a follow-up question for you readers. I’m trying to understand how bookmark usage patterns differ on mobile web browsing platforms. This issue has serious implications for the design of the bookmark UI in Fennec. It also affects the design of Weave. What should be the default Weave behavior when syncing bookmarks between desktop and mobile clients? The current behavior is to simply merge the two lists, so you have the same bookmarks in both places. But if there is a big difference between the bookmarks you want on one side and the bookmarks you want on the other side, then maybe pushing everything into one big pile isn’t the best approach.

I must admit that I very rarely do any mobile web-browsing. I have an old, crummy cell phone that I barely use. I take my laptop everywhere and do my web browsing on that. (I know, I’m behind the times.) In fact, the browsing I’ve done on my Nokia N810 in order to develop and test Weave on Fennec is about the most that I’ve done. That means that I have not developed the personal experience or intuition to guide design decisions about mobile browsing. Instead, I have to rely on data, input, and stories from others who do use the mobile web.

Picture of me cursing my cell phone

That’s why, if you are a mobile web user, I am especially interested in your answers to the following questions:

  1. Do you use bookmarks when browsing on a cell phone or other mobile device?
  2. If so, how does your bookmark use on mobile differ from your bookmark use on a desktop or laptop machine?
  3. If you don’t use bookmarks in mobile browsing, why not? Is it because of a poor interface, because your needs are different, or some other reason?
  4. Finally, is there a difference between the set of bookmarks you commonly use on the desktop, and the set of bookmarks you commonly use (or think you would use) on a mobile gadget? Do you think there’s a case for keeping these two lists of bookmarks separate?

Thanks very much for your feedback!

A CNet article about Fennec mentions Weave as the killer advantage that mobile Firefox will have over other mobile browsers. Yay! Thanks to Jay (who demoed Weave to the reporter) for the link. It made my day!

(Now, we just have to make sure the actual product lives up to the hype…)

Fennec Beta 1 was released yesterday! And there was great rejoicing!

To go with it, we’ve released Milestone 5 of Weave, including a lot of bug fixes and UI polish improvements to the Fennec version, and an improvement to the caching algorithm that makes syncing up to 3x faster. Weave is now hosted on, so you can get it there.

Anyway, I noticed that a lot of people have been linking to my previous post, with its embarassingly ugly proto-UI for selecting a tab to open. I wanted to show you the new and greatly improved UI, with a more informative display, selectable sort order and much larger click targets:


I wrote up a tutorial explaining how to install Fennec on an N810, and how to install, configure, and use Weave on Fennec, in case you’re interested in helping us test it out.

March 9, 2010 Update: This post is over a year old and extremely out of date! If you want the latest information about syncing your data between desktop and mobile Firefox, check out this post on the official Weave site instead.

The latest version of Weave now syncs your open tabs — and it can sync them between Firefox on the desktop and Fennec on a pocket-sized gadget.

“Syncing tabs”, by the way, doesn’t mean that we force all your browser instances to have the same set of tabs open. That’s not what anybody wants! Instead, it means that every browser has the ability to access the tabs that are open on other synced browsers, and to locally open copies of those tabs.

Here’s how it looks on Fennec. Keep in mind that this UI is a work in progress, and I’m well aware that it needs work, polish, and testing. But I’d like to let you see how it’s coming along and get your feedback on it.


On the left sidebar of Fennec, where your tabs appear, is a new Weave button. (This assumes that everyone recognizes “Rectangular Celtic knot” to mean “see my tabs from other computers”. Not a good assumption, so consider this a placeholder.)


Clicking the button slides the screen further to the left for a full-screen view of tabs from other computers. If you have more than two browsers being synced, each remote browser will have its own column here. Each column is identified with the client name. Eventually we’d like to display thumbnails of the tabs, but since we’re not syncing thumbnail data yet, we make do for now with titles and favicons.


A click on one of the remote tabs opens a local copy of it, which adds it to the tab bar, as you can see here.


(Addendum: Here’s Madhava’s proposal for how the tab sync UI ought to work when it’s finished.)

(Addendum 2: Here’s the new and greatly improved version of the UI shown above.)

For the past few Thursdays we’ve been doing something called an “Open Design Lunch” at Moz. We’ll pick a design problem that somebody’s working on and brainstorm it informally while munching pizza and burritos. Asa has been broadcasting these events on

At today’s Open Design Lunch I brought up the question of how bookmarks should be accessed in Fennec. Bookmark management on Fennec gets extra tricky when you have hundreds (or thousands) of bookmarks from your desktop computer getting synced onto your mobile phone; so this problem is closely related to the UI design of Weave. My previous attempts to design a bookmarks UI haven’t solved these problems to my satisfaction.

The conversation didn’t conclusively settle anything (of course) but it brought up a lot of good ideas that deserve further investigation. Here’s the video:

(Note: These videos use the cutting-edge <video> tag from HTML 5, so they may not work for you unless you have the latest version of Firefox or another standards-compliant browser.)


We talk a lot about Ubiquity being easy to extend, what with the ease of writing your own commands and so on.

But did you know that Weave is also built to be extended?

Weave uses a generic syncing algorithm which uses plug-ins called Engines to handle different data types. The following engines are built into Weave:

  • Bookmarks (fully functional)
  • History (fully functional)
  • Stored Passwords (currently being revamped for 0.3)
  • Tabs (being revamped)
  • Form Field Entries (being revamped)
  • Cookies (being revamped)

But since the syncing algorithm is fully generic, it will work with any data you give it. Therefore, you can write a sync engine to synchronize any data you want, as long as that data is accessible from Mozilla extension javascript. Your sync engine just has to extend some existing Javascript prototypes and add some logic for reading, writing, and updating your data type. The Weave core will do the rest.

It’s more work than writing a Ubiquity command, but not as much as writing a whole new extension.

Last night I finished writing the Weave client-side API documentation that describes, in excruciating detail, how to write your own sync engine.

I hope having this API documented will inspire some people to try their hand at weaving together their own data types!

(If there’s any part of the documentation that doesn’t make sense, leave a comment or visit #weave on and let us know how it could be made clearer.)

Aza interviews me about Ubiquity and Weave. I do a bad Frank Zappa impersonation and some air guitar.