Archive for February, 2010

Towards a Cleaner Firefox Startup

Notifications when Starting Firefox

What should happen when you start up Firefox?

Nothing. No notifications, no updates; nothing but a clean window ready to browse. This simple startup has been a goal for the Firefox user experience team for awhile (Faaborg has outlined our plan for eliminating startup dialogs here). As add-ons manager updates are among the worst current offenders, moving these notifications away from the startup process has been one of my goals in its redesign.

Why is it so important to make Firefox’s startup clean? The obvious reason is speed. Notifications and updates appearing and then requiring dismissal wastes valuable seconds. But there’s also interaction drawbacks when windows pop up. If a user is launching Firefox, he probably has a goal in mind, and that goal is unlikely to be updating his add-ons. By seeing an update notification, the user is being distracted from the task he wanted to achieve and forced to give some of his attention to a new task: dealing with or closing the notification.

Crashing Without Session Restore

However, what if we took this one step further, and didn’t try to automatically restore a user’s session after a crash? What if instead there was just one window, ready to go, with a link to restore the previous session?

Currently, if Firefox crashes once, the session restores when Firefox is reopened. If Firefox crashes twice in a short space of time, it’s assumed to be because of bad content from the session. That’s when Firefox throws its famous “Well, this is embarrassing” screen, and gives the option to restore the full or partial session.

This is fine in the expected case of the user crashing because of bad content and wanting to restore their session and get back to work. The problem is that forcing Firefox to quit, or deliberately crashing it, are increasingly becoming alternatives to quitting. Since websites often throw warnings before they close and stalling sites can mean waiting until a command can go through, it can be much faster to crash than quit normally. Here’s a couple ways this can go wrong:

Scenario 1:

Sally has 15 windows open, each with lots of tabs. A few websites she opened are starting to stall. Sally could wait until those pages resolve their issues, but her session is getting bloated and she really just wants to start over with a fresh session. Rather than wait for the stalling pages, Sally forces Firefox to quit. However, when she reopens Firefox, it tries to restore the session she doesn’t want. Sally quickly forces Firefox to quit a second time. Now she has the new session she wanted, because Firefox assumed her two crashes were due to bad content bringing down the browser.

Scenario 2:

Oliver’s first date with Annah is going great, and she’s come back to his apartment. Oliver knows the way to win her over is to show her that hilarious video with a cat falling down stairs. Annah sits down with Oliver at the computer, and Oliver goes to open Firefox. But, he hesitates. The last time he used Firefox, did he quit the browser normally, or did he force a quit, or did he crash, or did he turn his computer off? If it’s any of the last three, his last browser session will automatically display in front of his innocent date. Oliver isn’t sure he wants that. He opens Chrome instead.

If we give a link to restore a session rather than restore it automatically, Sally can use crashing the browser as a way to get a new session and Oliver can ignore his last session and watch his video.  When someone actually crashes they only need to click once, and they’re back where they started.