The Microsummaries feature I proposed a few months ago in this blog–and have been developing since then–has landed in time to make Firefox 2.0 alpha2.  Or rather, an initial version of it has landed.  UI and other elements are still undergoing refinement.

But there’s something to play with now, so play, and let me know what you think!  To use the feature, you first have to install some microsummary generators, which are the things that extract microsummaries from their pages.  Get started with this page of sample generators.

To install a generator from that page, just click its link (f.e. the Yahoo! Finance Stock Quote link), click OK when Firefox asks you if you want to add the generator, go to a page to which the generator applies (f.e. the Yahoo! Finance Stock Quote for Apple Computer), and then select Bookmark This Page… from the Bookmarks menu.

In the Add Bookmark dialog, select the microsummary from the Summary drop-down menu, then select the Bookmarks Toolbar from the Create in drop-down menu.  Press the Add button to add the bookmark.  A bookmark to the page should appear on your bookmarks toolbar (or its “chevron” overflow menu, if you’re out of space on the toolbar proper) with the microsummary you selected as its label.

If you’re having trouble, see this set of unit tests, which take you through step-by-step instructions for testing the feature.  If you want to create your own microsummary generators, see this tutorial on the subject.

Up next: bug fixes, UI brainstorming, a presentation Wednesday at XTech, and perhaps a pre-alpha microsummary builder extension if I can get to it.

I frequently fall behind on nightly trunk updates, usually because I brush off pending updates and then go for days before restarting Firefox.  Occasionally it’s because I’m away from my computer on vacation.

Once I’m behind, it’s painful to catch up, since the app update service feeds updates to Firefox one day at a time, so I have to Check for Updates, wait for Firefox to find and download the next one, restart the app to apply the update, and then repeat the process over and over again until I’m finally up-to-date.

Bug 306864 is about fixing this on the server side by making the app update service hand nightlies a single update to the latest nightly build, but it doesn’t have much traction, so I hacked up a dumb but effective client-side fix in the form of an extension that checks for updates, downloads them, applies them, and then repeats the process until Firefox is fully updated.

Using the extension is simple: just select Make Me Up-To-Date from the Help menu, and the extension will do its thing.  Warning: it doesn’t prompt you before restarting Firefox to apply an update, and it doesn’t tell you what it’s doing (except on the console).  So make sure you know what you’re doing before you use it (i.e. finish filling out and submitting web forms, save tabs you want to access afterwards, start Firefox with a console, etc.).

I’ve tested it with various Linux nightlies from the last couple months, and it worked as expected except when the app update service or client was busted.  Since it uses the same backend components as the regular updater, if Check for Updates doesn’t work, then Make Me Up-To-Date won’t work either.

If you try it out, post a comment with your results, and include your starting and ending builds plus what platform you’re on so I can get a sense of where it is and isn’t working.  And, of course, back things up in case this horks your build, since it’s new, untested code, and it may well be buggy.

Install Make Me Up-To-Date 0.1

Using Firefox’s password saving functionality is a frustrating experience for me, and I suspect it’s frustrating for other users too. It has several problems:

Problem #1: when Firefox remembers more than one password (or, more accurately, both a password and a username) for a given site, it doesn’t autofill the login form or give me any clue what the usernames/passwords are until I correctly guess the first letter of one of the usernames.

Although I only have multiple accounts at a couple sites (principally those of two utility companies which made me create new accounts when I moved), I regularly enter my login info incorrectly and then mistakenly tell Firefox to remember it, so I now have invalid remembered passwords at a number of sites, and Firefox no longer autofills their login forms.

Problem #2: Firefox asks me whether it should remember usernames/passwords the moment I submit a login form, and it does so via a modal dialog, so I can’t wait to see if my login attempt succeeded before deciding to save the info.

Problem #3: Deleting passwords is hard. It’s only possible via the password manager, and every time I open the manager I have to rediscover how its list is sorted. Unfortunately the list turns out to be sorted by raw URL, so http://example.com/, http://www.example.com/, and https://www.example.com/ are all in different places on the list, and I have to hunt them all down to find the one(s) I’m looking for.

Fortunately, fixing these problems seems relatively straightforward.

First, when a user loads a login page for which Firefox remembers multiple username/password combos, the browser should display a non-modal status bar (similar to the popup blocker status bar) which lists the usernames and prompts the user to select one. When the user does so, Firefox should fill in the form and perhaps also automatically submit it. Here’s a mockup of how it might look:

Second, when a user submits a login form with an unfamiliar username, Firefox should ask if the user wants to remember the info via another non-modal status bar, something like this:

Third, the password manager should support filtering, just as the cookie manager does, via a “Search” field that restricts the list to matching entries.

With these changes:

• users will be able to see and pick between multiple remembered username/password combos for a given site;
• users won’t have to decide in advance whether to save that info; they’ll be able to do so after seeing if their login attempts have succeeded;
• users deleting passwords using the password manager will be able to filter the list to find just the passwords they want to delete.

As a beneficial side-effect, users will be able to ignore the “save this password?” question instead of being forced to answer it every time. And to make deleting passwords even easier, we might include UI for doing so right from the “pick an account ” bar (f.e. a context menu item).

Thoughts?

After receiving some positive feedback on my “son of live bookmarks” idea, I wrote up a more comprehensive description and proposal for a Firefox feature that supports the display and updating of microsummaries of web page content (tip o’ the hat to Mike Shaver for the term “microsummaries”).

And then, since it’s easier to understand a proposal with some working sample code, I hacked up a prototype in the form of an extension you can install into a Places-enabled build (milestone 2 or newer).

The prototype comes with built-in support for three kinds of microsummaries: eBay auction items, Yahoo! Finance stock quotes, and Merriam-Webster’s Word of the Day. Just throw a link to one of those pages onto your bookmarks toolbar, and the prototype will start updating it regularly with pertinent information (the price/time left in the auction, stock symbol/price, and word of the day, respectively).

Thanks to Brian Slesinsky, who graciously trilicensed XPath Checker code, the prototype also supports user-defined microsummaries. Just context-click on some text in a page, then select “Watch [the text]” from the context menu. The prototype will add a bookmark to your bookmarks toolbar whose title is the text you clicked on, then it’ll update it regularly.

Here’s a screenshot which demonstrates microsummaries for the three built-in types plus a user-defined microsummary (the number of lines changed in a Bonsai query for “Places checkins in the last day”):

Note that this is an early prototype. It has limited functionality, lots of bugs, and relies on the rapidly evolving Places code (so is susceptible to bustage). Don’t rely on it or expect any eventual Firefox feature to work like it. It’s just a proof of concept.

Also note that it’ll take up to 15 seconds for a bookmark you add to the toolbar to start showing a microsummary. After that, the extension will update the microsummary every 30 minutes.

Finally, note that Places mucks with your profile, migrating history and bookmarks to new databases. Make sure you know what you’re doing (or are using a fresh profile) when you try out a Places-enabled build.

If I haven’t scared you away yet, then give it a try, and let me know what you think.

Microsummarizer 0.1

I recently came to the realization that I don’t have the time to function as an effective UI module owner for Bugzilla, so I have resigned that position.

Bugzilla’s UI module owner needs to encourage good usability improvements, deflect misguided changes and unintentional regressions, and keep usability central to the development process.

Although coding can be involved, the role isn’t primarily about writing code. It’s about examining and intuiting user needs and behavior, determining how well the current UI meets those needs and supports that behavior, proposing and evaluating beneficial changes, and engaging the development community with reviews and discussion.

I wanted to do a lot of usability work in the last year, but for a variety of reasons I ended up doing only a small amount, and I expect to have very little time to do this work in the future. I’ll continue to contribute where I can, of course, and I wish the project the best of luck with its UI development efforts.

If you’re interested in helping out with Bugzilla UI development, watch the ui@bugzilla.bugs user on bugzilla.mozilla.org and join the conversations on the mozilla.dev.apps.bugzilla newsgroup and the developers@bugzilla.org mailing list.

I buy about a dozen items per year on eBay, and when I’m bidding on an item, I add its bookmark to my personal toolbar, then I click that bookmark repeatedly for the duration of the auction just to find out two simple pieces of information: the current bid and the time left.

Instead of making me click the link over and over to get that information, Firefox should automatically check the auction periodically on my behalf and add its status to the bookmark label.  Then I could keep track of the auction just by glancing at my personal toolbar.

Auctions may be my personal itch, but I reckon there are other auctioneers with the same itch, and a feature like this could be handy elsewhere, too.  A bookmark to an Amazon product could display the product’s current price, for example, while a bookmark to a news site could show its latest headline.  Basically, any page with important and regularly-updated but short summary information is a candidate for this feature.

It might even be useful to display these summaries in other places–like tabs and window title bars–where the browser currently displays page titles.  And it might make sense to define a simple microformat to let the pages themselves specify which of their content represents summary information and how often to update it, although we’d want to allow users to override that where appropriate, just as we let them choose their own bookmark labels.

This feature extends a concept that live bookmarks introduced: that bookmarks can display much more than just static links to locations, they can display regularly-updated summaries of those sites.  So I’ll call this “son of live bookmarks,” for lack of a better name, and in homage to the same cheesy horror flicks from which Mozilla derived its name.

Would you use this feature if it was available?  Can you think of other kinds of pages for which the feature would come in handy?  Got a better name for it?  Comments welcome.

I updated my patch for tabbed message browsing in Thunderbird to work on the trunk, and I built trunk test builds for Windows, Mac, and Linux. For folks who want to try out the feature but don’t want to ride the cutting edge, I also built 1.5 branch builds for Windows, Mac, and Linux.

If you haven’t tried message tabs before, using them is simple. Just right-click a message header and select “Open Message in New Tab” from the context menu. You can also make the Enter key open messages in tabs by setting the Preferences -> Advanced -> Open new messages in preference to A new message tab.

Tabs work much like they do in Firefox: you can close them with Ctrl/Cmd-w, reorder them with drag-and-drop, etc. Next time you want to save some messages to read a little later, or you want to work with several messages at once, but they aren’t all consecutive in the same folder, try opening the messages in tabs. I reckon you’ll find them easier to use than windows.

Thunderbird users may have only a handful of accounts, but they have numerous discrete serial sources of information, including mailing lists, individual newsgroups, and feeds.  With filters, the global Inbox, and Forumzilla’s arbitrary feed->folder mappings, users have a great deal of flexibility about where they put their messages.  But the more source->folder mappings they add, the harder it is for them to remember which mail goes where, and adding mappings is challenging for ordinary users.

Thunderbird’s UI for source->folder mappings is scattered across multiple Account Preferences pages and Filters dialogs.  Forumzilla adds yet another dialog for managing feed subscriptions.  Users need a better way to view these mappings and change them.

I suggest we add a “sources” pane to the left of the Thunderbird folder pane.  The pane, when displayed, would feature a list of sources with arrows pointing from them to their folders.  Users would be able to drag arrows to different folders to change where sources write their messages.  And they’d be able to double-click a source to get more detailed configuration options, which could be just the existing account, filter, and feed preferences dialogs.

Changing a source->folder mapping for a feed means changing its “target folder” preference.  For a mailing list it might mean creating or updating a filter.  But these are backend differences; to the user, it’s the same action, and it should work the same for all sources.

Yesterday I made Forumzilla index items in its datastore by ID rather than URL. I did it to fix bug 12132, which causes Forumzilla to ignore multiple items with the same URL in feeds like the wiki.mozilla.org Recent Changes feed.

This is a pretty significant change to be taking on the stable 0.5 branch, but I’m doing so because I think it’s the necessary minimal fix for important feeds. Since not all feeds provide unique IDs for their items, I generate them if necessary by taking the SHA-1 digest of each item’s URL, date, title, and description.

To get SHA-1 digest functionality, I converted Paul Johnston’s JavaScript implementation of the SHA-1 algorithm to a JavaScript XPCOM component which implements the nsISHA1Service interface. I might have used his implementation of the MD5 algorithm instead, but its BSD license comes with an advertising clause (I think because he’s reusing some code that includes such a clause), while his SHA-1 implementation’s BSD license contains no such clause.

To prevent Forumzilla from redownloading already downloaded items, I wrote some code that checks to see if new items are actually old items that were previously indexed by URL. If so, I just convert the old record to a new, ID-indexed one and don’t redownload the item.

With the changes, the aforementioned wiki feed now works, and my regular subscriptions all seem to work, too, but the changes will need more testing to make sure I haven’t regressed any feeds in the process, so I built an 0.5 branch development package you can use to test the changes. I’ve tested it in Thunderbird 1.0, Thunderbird 1.5 (release candidates), and Mozilla 1.7 on Linux. Give it a try in your own favorite compatible mail client, and let me know how it works for you.

Users participate in discussions and receive announcements via a variety of delivery methods, including mailing lists, newsgroups, and feeds. Although these methods are all technologically different, users interact with them in roughly the same ways. They subscribe to and unsubscribe from a source of discussion/announcements, collect its messages into folders, sometimes save those messages indefinitely, and other times periodically delete old messages.

Users don’t care about the technology providing communication, they care about the communication itself. So the UI of a messaging client like Thunderbird shouldn’t arbitrarily differentiate between delivery methods but rather focus on what users actually want to do with the messages they receive. Thunderbird’s UI should include the following features:

• ways of subscribing to sources (in this one regard, the UI may vary noticably between methods, since users tend to stumble upon them in different ways, and it may be difficult to hide some details of the subscription process);
• when a user subscribes to a source, the client automatically creates a collection (a.k.a. “folder”) in which to store the source’s messages;
• global and per-source options (with sensible defaults) for receiving messages in the Inbox, in a collection, or in both places;
• readily-available contextual options (f.e. toolbar buttons, context menu items, buttons embedded into the message display, etc.) for managing sources (i.e. unsubscribing from them, changing their settings);
• when a user receives a message from a discussion/announcement to which he isn’t subscribed, readily-available contextual options for subscribing to it;
• global and per-source options for deleting messages after a certain amount of time, a certain number of messages, or a certain amount of storage space;
• a way to browse the list of all subscriptions and manage them;
• a distinction between turning off message reception (either temporarily or permanently) and removing the source and its messages completely (not sure which should be called “unsubscribing”; probably the former);

Note that unsubscribing from a mailing list is technically very different from unsubscribing from a feed, since mailing list subscriptions are stored on a list server. But from the user’s perspective, it’s irrelevant where or how the subscription is stored, since either way she wants the same thing: to stop receiving the messages. Users shouldn’t have to learn two different UIs for doing the same thing just because the technology behind their behavior differs, just like they shouldn’t have to learn different ways of accelerating depending on whether their car has a carburetor or fuel injection; Thunderbird should handle those details under the hood.

For feeds, that means no longer polling the feed. For mailing lists, it means interacting with the server to cancel the subscription. And even though there’s no standard way to unsubscribe from a mailing list, most lists are run by one of a small set of list server packages which are identifiable from the headers they add to messages, so it’s possible to implement a few package-specific handlers that can automate unsubscribing from 99% of lists.