Hypercritical
The state of Mac web browsing
There are a lot of web browsers available for Mac OS X. They’re all pretty good, but most people have a favorite. Mine is Safari, although I also use Firefox as my “second browser.” Picking a favorite is pretty easy. It’s partially an emotional choice. Safari just feels right to me. But here’s a more interesting question to ask yourself: in which application do you spend the largest portion of your web browsing time?
That seems like the same question, and you’d think it’d have the same answer. But it’s not, and sometimes it doesn’t. In my case, the answer is not Safari. During the past year or so, most of my time spent reading web pages has taken place within NetNewsWire. I’m not talking about reading news feeds, which of course takes place within my favorite news reader. I’m talking about viewing actual web sites.
NetNewsWire version 2 introduced a WebKit-powered, tabbed web browser to the venerable new reader. Aside from the speed and features provided by WebKit, NetNewsWire is not a very good web browser. It has no stop or reload buttons, let alone a full-blown toolbar. It has no bookmark bar or menu, no search field, no “view source” feature, and no history whatsoever. Even the back/forward buttons are miniscule and hard to hit. So why in the world would I willingly spend any time, let alone the majority of it, reading web pages in NetNewsWire?
The answer comes down to one word: state. I wrote about this very issue over a year ago in my OmniWeb 5 beta review. You can follow one of the links to read about it, but I’ll summarize it again here. The idea is that time spent making changes to the state of an application (opening, closing, moving, and resizing windows, creating new tabs, etc.) is partially wasted if those changes are not retained across application launches.
This may not seem like a big deal, but for me, state retention is often a deal-breaker. There’s nothing more frustrating to me than repeating the same actions over and over, but that’s exactly what I find myself doing in most “normal” web browsers.
Every day I’d launch Safari, then immediately open at least three windows, then middle-click a specific bookmark-bar button to open a set of tabs in each window. Then I’d browse the web for an hour or two, spawning yet more windows and tabs. At some point, I’d go away from the computer. If I were to return, I’d find things as I left them. But that only works if I return to the same computer. If I pick up my laptop, all my windows and tabs are gone. Ditto if I’m at another location entirely.
Still, why NetNewsWire? Doesn’t OmniWeb 5 retain state across application launches and system restarts? Indeed it does, but NetNewsWire takes it one step further, supporting network-based synchronization. That’s the straw that finally broke Safari’s back. The state of “everything” in NetNewsWire can be synced to a server: either the execrable (but firewall-friendly) .Mac WebDAV servers, or an FTP server of my choice. Now no matter where I go, if I have a copy of NetNewsWire, I can pull up my most recent news-reading/web-browsing session as it existed when I last left it, no matter which computer I was on at the time.
NetNewsWire’s synchronization implementation is not perfect. Sometimes it gets confused when merging network and local state. It doesn’t retain all the little details like text selection and scroll bar position. It only really deals with the single, “main” window. (The download manager window retains no state at all, for example.) The tab overflow behavior apes Safari’s awful chevron "»" menu, and since I’m always in the middle of reading a ton of web pages, I’m constantly in “the overflow zone.” Finally, the actual NetNewsWire web browser really is anemic, and often frustrating to use. (For example, it doesn’t allow pop-up windows at all, even user-requested ones like the reply form in the Ars forum.)
But all of this is dwarfed by one great virtue: NetNewsWire shows that it values my time by remembering what I did in the past, and not forcing me, Frosty-like, to repeat my actions every single time the application launches. (“Happy birthday!”) It’s also a kick-ass news reader, which is the reason I started using it in the first place, of course. (Spacebar, down-arrow, k: that’s what it’s all about.)
State retention sounds like a Nerd Feature, but surprisingly few people, nerds or otherwise, seem to request it. It’s also a pain for developers to implement, blah blah, read all about it. But once someone experiences it, it’s hard go back. What’s rare is the unprompted desire for state retention, not the love of the actual feature in practice.
The endgame of personal computing is all about saved state. Eventually, it will be considered intolerable for your entire computing environment not to follow you around from place to place, completely intact. We’re a long way from that today, but every little step along the way makes me happier. In the end, it’s probably an operating system problem rather than an application problem. But even without explicit OS help, there’s a lot application developers can do today.
Perhaps uniquely among “boring” features, state retention engenders rabid user loyalty. Beyond the consideration that it shows for a user’s time, developers can also consider saved state as a form of benevolent lock-in. Retain enough state and users will be very hesitant to move to another application. It’s like living in a house for many years. “I’ve finally got every room just the way i want it! I’m not moving now!”
(And yes, not coincidentally, this does also tie back in with the Finder. Thanks to a fundamentally broken state retention design, nesting is effectively dead in the Mac OS X Finder—and I mean in the avian sense, not the hierarchical one. But I won’t belabor the point here…)
So, kudos to Brent and crew for going the extra mile to sync web browser state in addition to news-feed state in their news reader. And kudos to Omni for at least saving window and tab state locally (and in multiple workspaces, no less) plus doing network synchronization of bookmarks—so close!
What I’d like to see in all Mac OS X applications is total state retention and network synchronization via any available protocol: SSH, FTP, SFTP, WebDAV, SMB, the works. If someone’s looking for an interesting middleware opportunity (a la Growl), an application-agnostic state retention and synchronization framework is a nice idea. (Arguably, Apple’s already on that path with Sync Services, but a third-party framework could build on that.)
Yeesh, I knew I’d have trouble confining myself to “blog-length” posts. I’d better end this now. Remember, developers, when in doubt, save state! Show that you think my time is valuable! If a news reader can displace my favorite web browser thanks to network-synchronized saved state, just think of what your app can do to the competition within its own market segment.
This article originally appeared at Ars Technica. It is reproduced here with permission.