Partager via

There's no such thing as a simple feature

  • Article

Whenever I think about designing seemingly simple features, I reflect back on this to remind myself how nothing is as simple as it seems: For Exchange 2000 Service Pack 2, I was tasked with speccing out a feature - type-down search. In Outlook and Windows Explorer, this is the feature whereby you can sort on a column and then start typing, and Outlook/Explorer will automatically scroll down and auto-select the first item that matches the characters you type.

We brainstormed the ways this could be implemented, came up with a few, and narrowed it down to two:

  1. Work just like Outlook - sort on a column, then start typing
  2. When you click on a column to sort, a little box would show up that you could type your search into. This would then sort and select. To do a sort without a type-down, you could just press enter after clicking on the column heading and the box would go away, and the sort would be performed.

You might ask why we wouldn't automatically go with the model that Outlook and Windows had chosen. There was a few reasons, each one required some additional investigation:

  • Performance: For every search you do of a folder (which happens on folder load, or when you resort by a column), you incur a performance hit. #1 above means that for every type-down search you do, you perform two searches. With #2, you could keep it at one search.
  • International support: While the model makes sense for English and other languages that use ascii, what about other keyboards, such as the ones where typing 'a gives you an accented a - would the browser interpret this as the accented a and sort in the right way, or would it look for the literal string 'a?
  • We aren't the same as outlook/windows in other ways: with Outlook and Windows, there's no 'paging', i.e. everything is accessible by scrolling down. With OWA, you have to go through pages of items (25 items at the time, but in Exchange 2003 it supports up to 100 per page, another seemingly simple feature that we spent a fair amount of time on[1]). Would users get confused between the paging model, the scrolling within a page, and type-down?

So we spun off efforts to investigate the performance & international side of things, and set about doing usability studies for both methods. We weren't sure how users would react: on the one hand, with method #1, there's no indication to the user that type-down search exists - would users think to try it? With method #2, there's an indication to the user about what to do once the user sorts on a column, but it adds a step to the process of sorting by a column, which could be annoying.

We printed out screenshots of both options and did a paper usability test. The first complexity was to find the users for the test - we wanted a sampling of: some people who had used OWA before, some who had used hotmail and other web-based mail systems, and some who had never used web mail at all. The great folks on the usability team did all this work for us. Then once we had them in, we showed them the printout of a basic OWA window and asked them fairly generic questions around the scenario, i.e. “Here's a screenshot of your mailbox, how would you go about finding the mail from Gary?“ We noted what their first reaction was, and also ran the drop-down UI by them to see if it was intuitive.

 

I was fairly surprised by the results - almost everyone knew how to use type-down search in windows explorer. Almost all of them considered it an obvious feature. So the model of doing what Outlook/Windows did was absolutely fine. Of course, here's the trick: While myself and the usability engineer were fussing around with the usability study, the dev got bored and just implemented model #1 above. And it worked beautifully with all sorts of keyboards/characters. And of course, the secondary assumed sort is by the field with the date in it, such as the “Received“ date in the default view. And this was just one part of the thought process we go through when working on features.

 

[1] Some examples of the decisions we had to work through: What is the performance impact of increasing the number of items returned? What should be the max or min? Is it admin customizable? If so, how? What should the default values be on the options page to select how many items you want to show per page? What increments should we count up in? What about users with small devices that want to only display 5 items at a time, are they the most important, or is the user with the large monitor who wants to display 75 items at a top more important? Will the listbox on the options page fit in 800x600 when expanded?... all to let you choose how many items to display on a page.

Comments

  • Anonymous
    January 01, 2003
    Any new feature which does not serve a large percentage of users is essentially stealing valuable resources that could be spent implementing features, fixing bugs or looking for security vulnerabilities that DO impact the lives of millions of people.
  • Anonymous
    January 01, 2003
    Take Outs for 11 May 2004
  • Anonymous
    January 01, 2003
    PingBack from http://pschmid.net/blog/2006/08/17/38
  • Anonymous
    January 01, 2003
    Decision-Making Skills
  • Anonymous
    January 01, 2003
    Writing the code is the easy part.
  • Anonymous
    May 11, 2004
    Well, under locales where typing 'a gives you accented a your application will never know that the user typed in 'a, you'll only get a notification as if the user typed in accented a.