Arrogance and approachability
By sch on Sep 28, 2005
Although I have been writing a lot lately—slides, draft policies and processes, and slews of email—none of it has managed to reach my blog.
I've been a Wall Street Journal subscriber since graduate school—skimming the paper in the morning is a habit I've maintained despite the hazard of having milk-sodden cereal hurled in my face by an unconciously ignored child. Last week, Walter Mossberg, in his Personal Technology column entitled "Yahoo Email Delivers That Desktop Feel Most Users Expect" [$$], reviewed Yahoo's forthcoming web mail implementation, which is currently in beta test. The review is positive, but at the end Mr Mossberg shares what, for him, are some key constraints on software improvements. These constraints—which I think are overly severe—are very relevant to our work in Approachability, in which we're reexamining some of the steps required to configure and operate a Solaris system.
The major aspect of the Yahoo Mail Beta appears to be the use of an increased amount of "AJAX" technologies in the implementation, such that the application pushes more logic local to an advanced client (like Mozilla Firefox or any of the "big" browsers) and thus appears to be more responsive. However, the final paragraphs in the column instead concern how Google Mail differs from Mossberg's assessment of typical mail interactions:
.... On several key issues, Google's engineers have decreed that familiar email practices are no longer useful, and have substituted approaches they prefer, arrogantly denying users any choice.
Gmail doesn't allow folders, only color-coded labels, as an organizing technique. It forces you to view all of your email in groups of related messages called "conversations," instead of viewing them individually as they arrive. Other email programs also allow such grouped views, but they permit users to choose. Not Gmail, where "option" is a term too rarely employed, except in reference to employee compensation.
This language is strong (and the closing sentence of the passage veers off into an ad hominem cornfield, since there was surely an internal user interface discussion behind this particular choice). The underlying request I believe is being expressed here is "justify your differences from convention". Now, technically speaking, the labelling mechanism (or "tagging") is a legitimate categorization offering that some users find superior to the implicit single category provided by the folder mechanism. If you've ever wanted to file an message in two folders, you know what I mean. (It's also pretty reasonable to say we're living in the Golden Age of Tagging and perhaps should try to enjoy it...) And, if you use one label per mail, you've reproduced the folder model via convention. So, while different, there's no doubt that this interface offers a capability that some users will prefer.
The second objection, to the absence of an individual message view, I can't get excited about, but I suspect that the UI discussion about this aspect concerned the deliberate elimination of various views. That discussion might have involved consistency of presentation (frame and window counts constant) or increased responsiveness (document model-based inbox with dynamic population). Software engineering rationale, like the maintenance costs of additional features may also have entered the discussion.
Mr Mossberg concludes by emphasizing his concern that Google will fail to meet certain users' needs for cultural reasons:
I'm sure Gmail will get better and better, and will eventually adopt the new programming techniques that allow desktop-like ease of use. But I'm not sure Google's arrogance will ever make room for user preferences on things like folders or ads, or how emails are grouped.
Yahoo's new email program would blow Gmail away if it were widely released today. That's partly due to its features, but also to its respect for user choice.
Again, strong words.
In Solaris Approachability, we're wrestling with similar issues: should we offer all envisionable configuration choices for each feature? Where's the sweet spot between too few choices and too many? We've been operating with a philosophy that the system should adjust itself dynamically, eliminating former tunables (or refusing to introduce new ones) in the interest of reduced management costs. The tradeoff is potentially a tax on performance or a loss in some notion of absolute flexibility.
The concern I have when I read a review like Mr Mossberg's is that he presents a critique of a software artifact without even a cursory mention of his applicable criteria, and sweeps all failures to meet those criteria to Google's engineering approach. What are those criteria? Under what circumstances would those criteria be invalid?
We're planning to make changes to Solaris: typically, we will solicit feedback on the proposal itself, as well as through the development cycle. (Feedback is much easier to solicit with the growing OpenSolaris community.) If those changes risk violating your implicit criteria, let us know; if we make questioned changes even after that notice, it's due to our drawing different conclusions from the available data, and not the result of doctrinal arrogance.