Suppose you want to add a feature to your app that will restore windows that were open in the previous session. Several browsers do that to varying degrees, for instance.

The model isn’t a big deal. As long as you have a way to uniquely identify the window’s contents, you’re good to go with the most relevant piece of information. Could be a URI, could be a local file path, could even be additional data from the session. OmniWeb, I believe, actually stores unsaved/unsubmitted form data in addition to the mere URLs. Or you could store previous history items so back/forward buttons continue to work. Storing window location and size is a plus, too.

Likewise, you don’t have much to think about when it comes to the controller. You could do it the lazy way and save this data when exiting the app, but then you don’t have the worst case (and ironically the one where this feature would help the very most) covered: that of your app crashing, thereby not exiting safely. So instead, you could store this (asynchronously, please: wouldn’t want to annoy the user with such mundane tasks!) as windows get opened, closed, moved around or resized. At any given time would you have an up-to-date data structure.

But then you get to the view. How does the user interact with such a feature? Does every user want such a feature?

In the simplest case, we’d just turn it on for everyone, whether they like it or not. Quit the app (or crash it, or have the computer go down from a power outage), then launch it again later on, and boom, all windows are back. Nice, huh? But that can get annoying fast. What if Joe just wanted to pull up some contact real quick, without having to wait for twenty other windows to come up just because he had them up the last time? Having to deal with launch time at all is bad enough; having several seconds added on top of it adds insult to injury.

Oh, I know what you’re thinking: suppress the ‘reopen the windows from my last session’ feature by holding the shift key (or some other modifier) when launching. Sure. For the computer-obsessed like us, that’s a perfectly fine way of asking the application to diverge from the default behavior. Unfortunately, even if everyone were to learn about such a non-obvious feature, they still wouldn’t think about it when a phone call comes, they’re stressed, almost panicking, having to look up something as fast as possible because they were technically supposed to know it before the call even took place. They would not remember to hold shift, I assure you.

Next up? “Make it an option!” Of course. Just add a checkbox “Always Reopen All Windows From Previous Session” checkbox to your already-bloated Preferences window — there’s no better way to ensure that 95% of your users will never opt against the default behavior, and, should they dislike said defaults, they’ll be annoyed and hate your app, rather than even considering the possibility that they can change them. That is, if you default to leaving this off, most won’t even know the feature exists to begin with. If you default to turning it on, most will assume that’s the way your app works, no alternatives. Consider Safari 3. As Gruber puts it:

I love Firefox’s auto-restoration of tabs and windows. Quit Firefox, relaunch it, and your previously-open tabs and windows are restored. Safari 3 has this feature, but makes you do it manually via the “Reopen All Windows From Last Session” command in the History menu. I’m sure most Safari users have no idea this feature even exists. At least as a preference, Safari should offer the ability to do this automatically.

That last sentence, however, somewhat clashes with the previous one: such a preference would only be of benefit for those who do know about the feature’s existence in the first place.

Then there’s Firefox 3’s way: when you quit while tabs are open, you get a dialog:

Do you want Firefox to save your tabs for the next time it starts?

In addition to the well-labeled buttons “Save and Quit”, “Quit” and “Cancel”, there’s also a “Do not ask next time” checkbox, thus informing any average guy that yes, this feature does exist. And when quit unsafely, you get the following upon next relaunch:

Your last Firefox session closed unexpectedly. You can restore the tabs and windows from your previous session, or start a new session if you think the problem was related to a page you were viewing.

The button labels “Restore Previous Session” and “Start New Session” are a bit lengthy, but clear enough.

But the trouble is, quitting safely is not the point in time you typically know whether you do in fact want those windows open again. The next launch is.

That’s presumably why Safari’s developers instead opted not to have any dialog at all — neither when quitting nor when launching — , because both of those get in the way of your normal workflow. Rather, there’s a menu item underneath “History”: “Reopen All Windows From Last Session”. Which brings us back to lack of discoverability.

To recap so far:
A typical application does not sport such a feature. Therefore, a user does not expect it to exist unless they are inadvertently exposed to it, at which point it is likely to annoy them. A preference would not be discoverable, and leaving the preference out would require a default, which some users would inevitably dislike (and assume to be unchangeable). Moreover and needless to say, any added preference needlessly obscures the potentially more relevant existing preferences.
Asking on quit or on launch gets in the way. Whether quitting or launching, the user probably wanted to accomplish something swiftly without being interrupted. Asking on quit also doesn’t handle the crash case, which is why Firefox gives special treatment to that one — something to be avoided as well.

And yet, I look at Firefox 3 for the solution. When you’ve entered a password, it features a new, non-modal panel asking whether you’d like it remembered. It doesn’t get in the way of your regular workflow; you can dismiss it but don’t have to in order to proceed.

That, I think is what’s needed here as well: a bar, a portion of the status bar, or perhaps even so little as an icon, to inform you that you could restore windows from your previous session if you were so inclined. An offer. One that you have plenty of time to think over and don’t have to deal with now, or even at all. This also allows another addition to the feature: a popup menu letting you choose particular windows to restore, one by one. Just have an “All Windows” option in bold as the default, a separator, and then one menu item per previously stored and now recoverable window. On Windows, bonus points for decorating each menu item with the respective window’s icon. On Mac OS, not so much.

The bad news is that implementing it this way takes a ton of time. Such a UI control, while increasingly commonplace, still doesn’t come standard with most frameworks. But on the upside, you have just implemented this in a way that, even if arguably not right¹, you put a ton of thought in, and only a fool wouldn’t applaud you for that.

1. UI design is hard. Getting UI design right for everyone is virtually impossible. ↩