The Jeeves Test

What is a browser for? What should it do, or not do? What should it be?

People within the Mozilla project have been recently discussing the user value of some new features in Firefox. I think a person’s view of questions of this nature will depend on their view of the role of the browser. One option is the “featureless window on the web” view – the browser is nothing, the site is everything. But as one participant said, this leads to all the value-add and features being provided by the sites, which is not a recipe for user control, or for using the browser to advance the Mozilla mission.

I think the best vision for Firefox is as your “Internet butler” – quiet and refined, highly capable, provides what you need even before you know you need it, who gently guides you out of trouble but generally does his thing without you needing to think about him or provide explicit direction or management.

Bertie using an early voice interface prototype

So I’d like to propose the “Jeeves Test” for evaluating feature proposals for Firefox. It works like this: imagine Bertie Wooster, relaxing in an armchair in his apartment, with a cigarette, a gin and tonic, and a tablet computer. Then take the user value proposition of an idea, write it in appropriately deferential language, and see if you can imagine Jeeves whispering it into his ear. If you can’t, perhaps it’s not something we want to do.

To make that a bit more concrete, here are some examples of things that might pass: “Here’s an English translation of this Serbian page, sir”, or “For your safety, sir, access to this malware page has been blocked”. And here are some which might not: “For your convenience, sir, I’ve exempted from your popup blocker”, or “You’ll be pleased to find, sir, that the user interface has been substantially rearranged”.

There may be occasions where we’d want to do something which doesn’t obviously pass the Jeeves Test, if the effects on the broader web ecosystem of making the change are significantly positive. Some of the things we do to improve web security but which have a short-term compatibility impact might fall into that category. “Let me ensure this site doesn’t load for you, sir” generally doesn’t go down well, after all. But in those cases, that longer-term or broader value has to be clearly articulated – before we make the change – if we are to avoid an exasperated “Dash it, Jeeves… why?” from our userbase.

11 thoughts on “The Jeeves Test

    • Perhaps “the Clippy Test” is the antithesis of the Jeeves Test? If you can imagine Clippy saying something… don’t do it :-)

  1. “You’ll be pleased to find, sir, that the user interface has been substantially rearranged”

    I’m not very pleased to hear that most of the time. Unless there’s measured extreme gains in productivity, it’s better to just make incremental changes UI-wise.

  2. Well, except that generally the plot of Jeeves and Wooster follows the following template:
    * Jeeves disapproves of Bertie in some way
    * A crisis of some sort emerges, which Bertie proposes to fix in some implausible way
    * Bertie’s fix fails
    * Jeeves exploits Bertie’s nativity and manipulates him into solving the crisis in some other (usually also implausible) way that often causes personal humiliation.
    * Despite this Bertie is so pleased that the situation is resolved that he desists with whatever behaviour was causing Jeeves irritation in the first place.

    I’m not sure that’s exactly the model I have for how I’d like my browser to treat me (and, for the record, I love Wodehouse, so this shouldn’t be read as a criticism of the books :)

  3. Bad test. Whether a feature passes is all about how you formulate its description. If you write, “You’ll be pleased to find, sir, that the user interface has been substantially rearranged,” then it sounds bad. If you write, “You’ll be pleased to find, sir, that the user interface is substantially clearer,” then it’s an obvious win. The same can be done with your other negative example: “For your convenience, sir, I’ve made work as intended.”

    Thus your test simply turns the debate over whether a feature is good into a debate over how to phrase the description so that it’s clearly good. That’s really the same debate. No clarity has been added.

    • To some degree; but I’d say that if the user has a popup blocker, claiming that exempting is “making it work as intended” doesn’t pass the smell test, because if you are doing that, why not make all sites “work as intended” and disable the blocker entirely?

      • Sure, and that debate isn’t any easier or different than the one you’d have without this test.

        My argument isn’t so much that it’s impossible to make these sorts of decisions, as that the test you propose doesn’t make them easier or clearer to make.

  4. I still like to think of the browser under its formal name – the “user agent”. As a user, your browser is the agent you employ to go forth to the other computers on the internet to do your bidding. To retrive the resources you want it to retrieve (and no more than those), and to transform and display them in a manner that benefits you the most. Even if you weren’t sure exactly what those resources are, or what that manner would be.

  5. How timely, given that I just had to go mucking around in about:config to disable two more “improvements” that Firefox has had shoved up its… codebase. Pocket, Reader, and (from a while ago) whatever the Skype knockoff is called are all things that should have been add-ons at most.

    And that’s to say nothing of the permission-creep going on with the mobile version. I’m on (and staying on) the last version before you guys decided that I was too stupid to know whether I wanted to be on whatever random wifi network I happen to be in range of. Thanks, but no.

    It’d be nice if we had the option to download a stripped-down, not-all-singing-all-dancing browser. Maybe we can just name it after the repository it lives in, or a mythical creature of some sort. The kind that rises from the ashes of its predecessor, perhaps.