Mark Shuttleworth has recently announced plans to rock the Linux user experience (yes, I know I’m a week late; I’ve been on vacation and am just now catching up).

I’ve been an avid Linux user for about a dozen years, first on Red Hat, then Fedora, and lately Ubuntu, and I’ve had my share of frustrations with the OS, so I’m thrilled to hear about this initiative.

And I have a piece of advice: don’t be afraid to cross (and dissolve) boundaries between layers of functionality and give developers the authority to fix problems no matter where they reside, even at the risk of ruffling feathers (as did ZFS with its “damn the software stack, full speed ahead to the desired outcome” approach).

I say this because my small window into the GNOME development process (bugs 482354 and 162726) suggests its developers spend way too much time trying to figure out which of the many layers of functionality in the Linux desktop is responsible for an issue (and thus who is responsible for fixing it).

Mozilla isn’t perfect in this regard either, but when it works well, it’s because developers take responsibility for making the user experience great no matter what part of the code needs to be touched (like the recent progress being made in bug 248970 by Ehsan Akhgari in collaboration with others on a private browsing mode for Firefox).

If you want to rock the Linux user experience, be willing to rock its boat as well.

Recently some folks have been blogging about Ctrl+Tab. It’s great to see that shortcut getting love, and it reminds me that there’s another one for navigating between pages that could use similar attention: Alt/Cmd+Left/RightArrow for going backwards and forwards through history within a tab.

Like the old Ctrl+Tab implementation, Alt/Cmd+Left/RightArrow only lets you move one page at a time, and you can’t see where you’re going until you get there. And sometimes you land on a page that is the product of a POST request, which you don’t know until you are forced by a modal dialog to decide whether or not to resubmit data that you don’t get to see when making the decision.

We could enable multi-page moves by making the shortcuts work similarly to Alt+Tab in operating systems: holding down the Alt key and pressing a horizontal arrow key would bring up a list of icons representing the pages in the history (perhaps formatted like Alt+Tab in operating systems or via the 3D effect Jono suggested for Ctrl+Tab).

Each icon would be a screenshot of the page as it was when you left it, and the adjacent page to the current page would be selected by default. But as long as you held down the Alt key, the list of pages would stay on the screen, and pressing the arrow keys would let you travel back and forth through it. Once you let go of the Alt key, Firefox would switch to the page that was selected at the time.

This behavior might also reduce frustrating clicks on posted pages, although the better solution, as Dan Mills recently pointed out in a conversation, would be to stop forcing users to reload pages just to go back (or forward) to them, even if they were the result of a POST.

But if we can’t do that for some important technical reason, we could at least display a non-interactive and suitably-dressed snapshot of the page and drop down a non-modal notification bar at the top of the tab explaining why we can’t provide the page itself and allowing the user to see what they are potentially going to reload.

And the list of pages could itself indicate which of its pages are POSTed, thus providing the user two levels of useful indication of what will happen when they try to go back to that page.

Of course, there’s more to history than the past and future of each individual tab, and pan-tabscape history navigation affordances would also be useful to think through. But there’s still a place for a tab-specific interface, given that many such trails represent a specific path through the web with relevance and meaning to the user, so it’d be good to improve the way Alt/Cmd+Left/RightArrow works (or invent even better tab history traversal).

Thoughts?

A couple weeks ago I blogged about my priorities for the next version of Snowl. I’ve just uploaded a preview release of the next version to addons.mozilla.org with an initial implementation of a view optimized for short messages and recent updates:

The view is implemented as a sidebar that shows short messages (such as from Twitter) in their entirety and displays the subjects of long messages with links to their content. Messages are sorted in the order received, with the most recent ones on top, to make it easy to see the newest stuff at a glance.

Plans

There’s still plenty of functionality yet to be implemented in the sidebar, including:

• grouping messages by time period (this morning, yesterday, last week, etc.);
• making it possible to see some of the content of long messages;
• an easier way to open and close the sidebar (f.e. a button that toggles it on and off).

I also want to improve elements of the visual design. In particular, I’d like to add a subtle but noticeable visual cue that messages have arrived (f.e. making messages slide into place from the top of the sidebar).

And I’m still working on implementing message sending and conversations as first-class objects for version 0.2. This preview release is just a taste of the first of several upcoming features.

Other Changes

This release also fixes a number of bugs and makes some improvements to the architecture (there seems to be a neverending supply of such infrastructure work, but it’s all necessary to prototype features on top of). And it improves access to Snowl’s features via some conventional extension integration points: an item in the Tools menu, an icon on the statusbar.

Get Snowl for Firefox

Get the initial prototype: Snowl for Firefox.

Warning: the initial prototype is a primitive implementation with many bugs, and subsequent versions will include changes that break functionality and delete all your messages, making you start over from scratch.

Get Involved

Let us know what you think by posting in the forum, reporting bugs, or conversing with us in the #labs channel on irc.mozilla.org. Or check out the source and submit your bug fixes and enhancements.

Last weekend I updated my Content Preferences extension to work with Firefox 3.

Along the way, I finished up an additional feature for it: pref widgets you can add to your browser toolbars. The widgets let you set page zoom, page style, and character encoding directly from visible browser chrome, and you use them by customizing your toolbars to include them via the View > Toolbars > Customize command.

Here’s the page style widget in the menubar on Linux:

Here are all three widgets on their own toolbar on Mac:

As with page zoom in Firefox 3, these widgets are site-specific and persist across browsing sessions. And as with earlier versions of the extension, they’re also available in a sidebar that follows you as you browse around the web and also lets you set global defaults:

UI like this has three possible futures:

1. If it’s useful to a broad range of users a significant percentage of the time, it belongs in the default chrome.

   The page zoom widget is a candidate for this placement. Among other indications, a number of popular sites, like CBS News, provide a version of it to their users within the default “chrome” of their content pages:

   

2. Otherwise, if it’s useful enough to enough users (a fuzzy definition, to be sure), it belongs in optional chrome, either via an extension or in well-concealed parts of the core product (hidden preferences, the browser toolbar palette, etc.).

   The character encoding widget perhaps satisfies these conditions, as it might be very useful in certain parts of the world where automatic charset specification and detection is not yet up to snuff.

3. Otherwise, it doesn’t belong in the chrome at all.

   I wonder if that’s the case for the page style widget, since browser UI for website skinning has never caught on.

   But there’s a chicken and egg problem here, since sites don’t have impetus to provide multiple skins without useful browser UI for applying them, while browsers don’t feel pressure to implement good UI when so few sites take advantage of it. Maybe a persistent site-specific page style widget is just the ticket to change that.

I’m not happy with the widgets, though. The page style and charset widgets simply mirror the functional but archaic menu-based UI in the View menu, and while the page zoom widget tries something new, and it’s easy enough to understand, it’s difficult and frustrating to use, since it requires precise manual dexterity to set a specific zoom level.

It could be improved in a variety of ways–indicators of which direction does what, markers and snap anchors at specific zoom levels, etc. But maybe there’s something even better. Two big buttons for zooming in and out?

A set of sticky buttons that each represent a zoom level?

As for page style, perhaps it could display a set of screenshots showing the appearance of the page with each alternative style applied. And the charset widget could show you what the text would look like if you applied each encoding.

Thoughts?

Last month I blogged about Snowl, an experiment with messaging in the browser.  Two weeks ago I presented it at the Firefox+ Summit.  And last Wednesday I released an initial prototype.

I’ve been getting tons of feedback since then from a variety of sources, including discussion at the summit, comments on the announcement, AMO reviews, discussion in the forum, news and commentary (TechCrunch, ReadWriteWeb, ZDNet, Computerworld, Ars Technica, Slashdot, Digg, etc.), blog posts, and bug reports.

Some opinions I’ve seen expressed more than once:

• the river view feels like it fits into Firefox
• the list view doesn’t mix well with general web browsing
• “I’d rather use a standalone application.”
• “I’d like even more integration with Firefox.”
• many of the prototype’s features should be part of Thunderbird
• it lacks a number of useful features (f.e. sharing)
• it contains a number of bugs
• it has lots of potential

Overall, there’s a lot of interest in Snowl, in browser/messaging integration, and in messaging innovation generally.  There’s plenty more to explore here, and I’d like to see Snowl experiment with the following features in particular:

• simple web search engine-like attribute-based search
• a message view optimized for short, simple messages (Twitter, IM, SMS)
• an experimental message view that uses color, size, graphics, word clouds, animation, or other techniques to help users make sense of their flood of messages
• support for sending messages, including responding to tweets and posting comments to blogs
• easy access to feeds from frecent (frequent+recent) sites, sites you are currently browsing, live bookmarks, and feed items you’ve commented on
• conversations (i.e. threads) as first-class objects
• better support for people as first-class objects
• email, IM, and other message sources
• user-initiated and automated message grouping (Home/Work, Important/Unimportant, Today/Yesterday/Last Week, etc.)

Of those, I’ll be focusing on a short message view, message sending, and conversations as first-class objects for the next iteration.

If you have a burning desire to see something else on this list (or something else entirely) happen sooner than later, your contributions are welcome!  Discuss ideas and post mockups to the discussion forum, pick up the source code from the code repository, and submit patches in bug reports.

Last week I got a new MacBook Pro to replace my (two year) old one.  Among the problems with the old machine was a perennial lack of space on the hard drive.  I kept having to compress, archive, and throw away files to keep myself (barely) in the black.

The new machine’s drive is twice as big, and that means plenty of space to build updated packages of Thunderbird 2 with my tabs patch based on the just-released Thunderbird 2.0.0.16.  The packages are available for Mac OS X, Linux, and Windows.

If you are the adventurous type, however, check out the Thunderbird team’s 3.0 alpha releases, which have tabs built-in by default.  And note the discussion on an experimental message view that aims to come up with an even better approach to opening multiple messages.

Incidentally, I’m standing on the shoulders of giants here.  The only reason I can build these at all is because Mozilla’s build/release team puts hard work into maintaining a build system and toolchain that makes it relatively easy to compile this several-year-old codebase even on new hardware running recent versions of all three operating systems.  Kudos and many thanks to them.

Last August, after Mitchell blogged about the future of email and penned an email call to action, I posted some thoughts about what a next-generation conversations app might look like.  I’ve kept thinking about it since then, and several months ago I proposed a labs experiment to build a Firefox extension that tries out some of those ideas.

Lots of users use desktop applications like Thunderbird and Apple Mail to converse with each other online, while many others use web apps, including not only webmail but also social networks, web discussion forums, and other site/service-specific tools.  Is there a role for Firefox in this mix?

That’s the key question I’m trying to answer.

I’ve been hacking on a prototype on and off since then.  It’s not quite usable yet, but it’s getting there.  It currently has basic support for subscribing to, searching, and browsing messages from feeds via two views: a list view similar to a three-pane email application’s interface and a variant of the “river of news” view described by Dave Winer.

I plan to have a 0.1 version of the prototype ready by the Mozilla Summit in two weeks, where I’ve proposed a session to present and discuss the experiment.  In the meantime, adventurous readers are welcome to check out the source and send me feedback via comments on this blog post, email, IRC, Facebook, your own blog post that references this one, etcetera, etcetera, and so forth.

I’ve been using Mozdev for almost eight years, ever since it started hosting Forumzilla, my project to build a Mozilla-based web forum reader (which eventually became a Thunderbird extension and then Thunderbird’s built-in feed reading feature).

Mozdev plays the critical role in the Mozilla community of hosting Mozilla-related projects that aren’t considered core enough to the Mozilla mission to host on official community infrastructure.  It’s a great adjunct to AMO, which distributes many of the projects that Mozdev hosts.

Over the years, I’ve been happy to host a number of such projects there, including the aforementioned Forumzilla plus Bugxula (defunct), Tinderstatus, and revision control/bug tracking for the Labs project Personas.

Although there have always been alternatives, they have been unpalatable: SourceForge has a cumbersome and unfamiliar interface, and hosting on my own server would have meant doing all my own systems administration.  I use Mozdev because I want to focus on my projects, not on the infrastructure for developing them.

Over the last couple of years, Google Code has become an option.  Although it provides much less functionality than Mozdev (and limits how many projects you can create), it does have a simpler interface and a more modern revision control system.

The folks who run Mozdev (which includes me) want simplicity and modern services (without sacrificing power) for Mozdev too, and we’ve identified three priorities in that regard: adding Mercurial for revision control, implementing WYSIWYG content editing, and automating project creation and management.

So I’m thrilled to read Mozdev developer Doug Warner‘s announcement today, via a post to the project owners mailing list, that he has landed Mercurial support.  Now you can get all the goodness of Hg hosted on your behalf for any of your Mozilla-related projects.

Eight years later, I think Mozdev remains the best place to host my projects, and it’s just getting better.  I can’t wait to see what’s next (and I have some ideas about what simple WYSIWYG editing could look like, about which more soon).

[Update: see Merging with Mercurial 1.0 and Meld for more up-to-date info on the experience with Mercurial 1.0, which comes with Ubuntu 8.10.]

When confronted with a merge conflict, Mercurial 0.9.5 (the version that comes with Ubuntu 8.04) uses its hgmerge script to call meld in a way that displays your version of the file on the left, the other version on the right, and hg’s attempt to merge them in the middle, with conflict markers where it was unable to do so.

Here’s meld handling the Merging conflicting changes example from the hg book:

You’re supposed to fix the one in the middle, resolving the conflicts between the ones on either side, and then save the middle one (which will get saved to your working directory, from where you can commit your merge).

The following patch hacks hgmerge to display the base version (the one from which your version and the other version originated) on the left, the other version on the right, and your version in the middle.

--- hgmerge.orig        2008-06-01 13:51:10.000000000 -0700<br />+++ hgmerge     2008-06-01 14:35:46.000000000 -0700<br />@@ -158,13 +158,12 @@<br />        conflicts_or_success<br />    fi<br /><br />    if [ -n "$MELD" ]; then<br />+        cp "$BACKUP" "$LOCAL"<br />        cp "$BACKUP" "$CHGTEST"<br />        # protect our feet - meld allows us to save to the left file<br />-        cp "$BACKUP" "$LOCAL.tmp.$RAND"<br />-        # Meld doesn't have automatic merging, so to reduce intervention<br />-        # use the file with conflicts<br />+        cp "$BASE" "$LOCAL.tmp.$RAND"<br />        $MELD "$LOCAL.tmp.$RAND" "$LOCAL" "$OTHER" || failure<br />        # Also it doesn't return good error code<br />        $TEST "$LOCAL" -nt "$CHGTEST" && conflicts_or_success || ask_if_merged<br />    fi<br />

Here again you’re supposed to fix and save the file in the middle, which gets saved to your working directory.

Here’s what the example looks like using the hacked version of hgmerge:

After trying both versions of the script on several test and real merges (a few of which I screwed up), it’s still not clear to me which approach is better (or if there’s something better still). David Baron pointed out in a conversation that it can be useful to see the base version, but it’s also useful to distinguish between your version and the version that ultimately results from the merge (which is presumably why kdiff3, which is shown in the book, displays all four: base, yours, other, and final).

Thoughts?

(Note: Devmo’s Mercurial basics says to use Mercurial version 1.0 or later, although I hear that doesn’t even include hgmerge, leaving configuration of a merge tool entirely up to each user, so the question is even more significant there.)

I’ve been using JavaScript 1.8 expression closures lately, but ActiveState Komodo‘s JS syntax checker, which is just SpiderMonkey 1.7, doesn’t recognize them, so it treats them as a syntax error and stops checking the file:

Fortunately, the fix turns out to be pretty simple. Komodo ships with SpiderMonkey 1.7 as an executable, so I first built SpiderMonkey 1.8 (on Linux) using the SpiderMonkey build instructions:

cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -l mozilla/js/src mozilla/js/src/config mozilla/js/src/editline mozilla/js/src/fdlibm<br />cd mozilla/js/src<br />BUILD_OPT=1 make -f Makefile.ref<br />

Then I backed up Komodo’s version and replaced it with the one I built:

cp Linux_All_OPT.OBJ/js ~/Applications/Komodo-IDE-4/lib/mozilla/js18<br />cd ~/Applications/Komodo-IDE-4/lib/mozilla<br />mv js js17<br />ln -s js18 js<br />

Voila! Syntax checking works for expression closures:

In theory I might have just horked some part of Komodo that depends on JS 1.7, although the New in JavaScript 1.8 doc doesn’t mention breaking changes between the two versions, and so far Komodo seems to be working fine.

If it does create problems, however, then a more contained fix, as ActiveState’s Todd Whiteman points out on the Komodo Discuss mailing list, would be to update koXPCShellLinter.py’s jsInterp variable to point to the 1.8 executable.