Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I'm creating a e-commerce site that will have different experiences for consumers and business owners. We're designing the business interface to allow them to quickly research existing and future trends. We're currently thinking a table would be familiar to the user, and would allow them to print and export to Excel. There's 9 criteria that could be filtered or sorted.

Are there any best practices or rules of thumb when deciding what to filter and what to sort? Or to allow both?

share|improve this question
add comment

3 Answers

up vote 13 down vote accepted

When your values are on a nominal scale (names without an inherent order except alphabetical - e.g. "phones; appliances; laptops"), it makes more sense to filter, because sorting is basically meaningless - they have no real order. The exception to this is when you have a very large number of different values, which aren't repetitive, e.g. Names. In that case filtering is just not helpful, since in order to choose a value to filter you need to go through the same long list of values as you'd have if you wanted to locate that value in the table itself.

Numerical values with a meaningful order can be both sorted and filtered, it depends on the data. For example, an "exact price" column should be sorted, not filtered - because if you're interested in items that cost $200, then you're probably equally interested in those costing $190-$210, the 200 is just an anchor, and you wouldn't want to hide those similar products. Another good example is a "file size" column. But a column like "price range" could be both sorted and filtered - if you're interested in items costing $200-$300, then you may or may not want to see items in the $100-$200 and $300-$400 categories.

Columns where the user is likely to look for the minimum or maximum value are sorted, because then you get your answer with one or two clicks, and filtering would take as much work as locating the answer manually.

Columns containing a few broad categories (movie ratings on 1-5 scale on a large set) make more sense filtered, because if you have a hundred movies for each rating, then most of the time you'll be looking within category in any case, and only in the beginning or the end of the category will you see its neighbors on one side. So sorting doesn't help you, and it just makes it harder to locate the category you're looking for.

In short, the more different values you have, the more sense it makes to sort.

share|improve this answer
    
+1 for the straight conclusion in the last sentence –  Martin Schlagnitweit Aug 13 '11 at 18:37
    
This is perfect. I think I can apply this thinking to solve the issue at hand. Thank you, Vitaly! –  cowcat Aug 13 '11 at 19:00
add comment

The use cases for each are different.

Filtering:

Use this when you have a large result set and you want to narrow it down by some criteria. Example: Show me all laptops between $500 - $700; Hide all products containing peanuts.

Sorting:

This is when you may not want to narrow your search criteria but simply sort it. Example: Sort by most recent on top; Sort by company; Sort in alphabetical order.

Regards,

share|improve this answer
2  
I think that cowcat knows what filtering and sorting are, and is asking, say, when to provide the ability to filter laptops by price ranges and when to provide the ability to sort laptops by the price. –  Tsuyoshi Ito Aug 13 '11 at 14:22
    
Thanks for summation! Tsuyoshi is correct, however. I've nailed down the filter/sort issues with the consumer side, which is a straight-forward e-commerce style (Yelp, eBay, Amazon, etc.) Good advice, thanks! –  cowcat Aug 13 '11 at 19:00
add comment

TL;DR summary: cowcat needs to decide between/among filter and sort as UI elements. Instead of trying to pick cowcat's brain to try to ask the right questions, I outline a simple process model for figuring out UI requirements while using an iterative/agile design methodology to create the final product. As the process is explained, anything directly addressing cowcat's question hs been marked "cowcat:" and Italics the so they are easy to search on.


Well, I think the rule and best practice (IMO, not claiming any sort of official sanction to the statement.) can't be defined any better than: take the solution which gets the final interface as close to the ideal ("ideal" being what would best satisfy the customer's needs and wants [not necessarily equal to what they think they want, and anyway what they want will change over time!]) interface as is possible while comfortably working within our constraints.

[cowcat: this is a fairly generic post, so to address your question as to how decide what to filter and what to sort, all the paragraphs that go directly towards answering your question are mostly italicized, and all labeled with 'cowcat:]

So, the ideal interface can best be determined by eliciting the needs of the Customer, through a process similar to this:

  • try to get a good idea of what the customer will do with the product, and why (have them step you through how they would typically use it in the course of their day)
  • get the initial customer desires and wants, however detailed or vague
  • come up with mockups (good) or active prototypes (better) of one or more options that meet their needs as you've determined based on the information gathered from the customer
  • take the customer feedback (far better if generated interactively in the previous step) and incorporate that into a consolidated mockup/prototype.
  • once again get feedback, preferably interactively with the customer, to refine the idea

Repeat the refine/feedback process throughout your development; it's best that you get to a point as quickly as possible to provide a functional working prototype, since customers actually working with the application will be far better at eliciting issues than mockups or semi-working active prototypes.

The process as described and elucidated here is a lot of text, but keep in mind that I am providing an abstract process, and once you narrow it down based on your actual needs, any particular implementation is likely simple.

cowcat: unless there's something I am not aware of, I imagine that this is especially true in your specific case, unless there's more to deal with than just sorting on a couple of things.

Constraints

Interface development will tend to be constrained on two main axes:

  • Customer Access: How much access you going to have to the customer while working on the project.
  • Project Constraints: Things affecting how much you can actually accomplish: some of the more important ones in this case are Time, Manpower, and Platform Constraints, each of which will limit how many different possibilities can be evaluated.

cowcat: I am not sure your Customer Access constraints from your question, but dealing with anything between no access and full access should not limit the process much in your case.

Customer Access

  • The amount of access you have will range from full access whenever you want, to no access at all.
  • In the process, there is a refine/feedback loop which requires access to the customer to provide feedback on changes that are made to the design from the very beginning through beta testing to finalize the UI.
  • Depending on the complexity of the application, your iteration time will vary, but the lower your iteration time, the closer you can approximate the ideal UI.
  • The ideal process will require customer interaction at every iteration in order to determine the desired refinements in the next.
  • This factor is, however, orthogonal to the rest of the development concerns, and lack of access is dealt with by simply using a proxy customer
    • For iterations in which you have full access to the customer, there is no need to proxy.
    • For iterations in which you have no access to the customer, you will need to choose a proxy to completely take over the role of customer.
    • For iterations in which you may have only partial access to the customer (e.g. if you are only able to send a set of mockups and get written responses) you will use a proxy as much as is necessary to determine the set of refinements for the next iteration.
  • I assume this is fairly obvious but: the closer the proxy customer is to being able to understand things like the real customer, the closer you will be able to come to the ideal.
    • If you choose a proxy that doesn't understand things like the customer and doesn't use the interface like the customer would, then they will probably lead the design away from the idea instead of towards it.
    • In the case that you can not find an appropriate proxy customer for an iteration, you are far better off freezing the interface design for that iteration and either working on other known issues, or simply dedicating your efforts towards something else. Even if it seems that you aren't making progress, you actually are making relative progress to the negative progress you would make by trying to update the design to match something further away from the ideal.

cowcat: In your specific case, I would assume you have a fairly good handle on what the customer needs would be, both consumer and owner. If you have and desire access to your potential customers, then, from experience I can say that you're still better off getting at least some feedback from actual customers on most iterations. But if that is not a possibility, then as long as you can really put yourself in the role of the consumer, or the role of the business owner, then you will still get good results. The important things to understand are the Domain and the likely manner of usage of the application.

cowcat: As to whether spreadsheet is a good idea, it just depends on whether you feel that the customers will all be fairly comfortable with that way of viewing things, that the application can be adequately modeled by a spreadsheet, or perhaps slightly modified spreadsheet. This strikes me as a decent idea from an experience I had, however I don't know enough about your domain to proxy for your customers. The experience was: I once developed an in-house requirements management application that almost failed because it wasn't a spreadsheet. I ended up just implementing round-trip to Excel so the users would use it.

cowcat: You should also consider whether there are other options, e.g., perhaps your owners would like a spreadsheet, but the consumers would be more comfortable with e.g., a search-engine-type interface with property windows. If there's the possibility and resources to cover trying out different options, then that's not a bad idea. If you are time constrained you can always focus on perhaps one model at first, with plans to implement another option in the future. As long as you are thinking in that direction, you can be flexible enough with your development to allow for both. (e.g. Perhaps you could write unit test cases that test the basics of the secondary interface, but only stub them in.)

Project Constraints

So, now that we have come up with a way to ensure customer access throughout the development process; that leaves how to deal with the Project Constraints.

It is not likely that you will ever have enough resources and time to do everything you want, and it is also unlikely (more likely, but still unlikely) that you will have so few resources and so little time that you can only pray to your chosen Goddess, God, or other deity that you will be able to hack it all together in time. But I think a good way to find a strategy for dealing with the Project Constraints is by looking at what the 'natural' strategy would be for the extremes.

Case 1 - aka:"Superman reversed time, do you think that would work?." You may find yourself in this situation due to being very tight on one or more of the various Project Constraints, but as we'll see, they can be viewed as very much the same issue when it comes to how to handle the development.

  • Looming Deadline: Unfortunately, things are taking longer than planned, or your bid on the project was too low, or you lost resources, or you had a crash and lost weeks of work, or you were stalled by another project, and the amount of time you have left is, at best, barely sufficient to finish based on current (hopefully improved) estimates.
  • Hard Platform: It turns out your ability to develop for the platform was overestimated, because the platform you are using is harder to develop for than expected, or the machine it is going to run on is much slower than you thought, or once you got to a certain level of complexity you touched the edge of a resource constraint, or found that the framework you were using started to turn into mush at the complexity level of your application.
  • Insufficient Resources: Somehow, you were not allocated the number of people you needed, or you could only afford two developer licenses for four developers, or you had a small bus number and you had developers come down with mono (not to be confused with a developer having Mono which might actually be a good thing.) For whatever reason you don't have enough manpower or other resources to do what you need to do.

This is a good idea of the different possibilities, it isn't comprehensive by any means, but the important thing to recognize isn't their differences anyway, it's what they all have in common. The differences may affect your mitigation of the problem, but at root they all are Schedule Issues. In other words, all the problems that you can do something about at heart are going to involve mitigating the schedule issues; de-scoping the work to be done, speeding up the process, getting new people, etc.

To be fair, there can be an special-case issue with Hard Platform, which is that it may not be possible at all to implement a certain desired interface or other feature. However, the only possible mitigation in that case will be a de-scope, and there's really no need to cover that here. The more likely case is that it just turns out to be a lot harder to implement a feature than expected, in which case we're back to the main line; the schedule did not have enough time allocated for that feature.

Case 2 - aka:"Hey did we remember to divide our estimates by eight and costs by 100 before we got this schedule approved?"

So, this case is not complex like the first. Yet. You have no significant constraints. You have far more time than you need, plenty of resources, and a platform that has no bugs and does everything almost without effort. And you have little green pigs flying around the office bringing everyone whatever they need throughout the 5 hour workday. (oink oink)

There are a few dangers here, but they all lead us back to Case 1. The dangers are:

  • Goldplating Without harsh deadlines, developers put their noses down and strive for perfection in everything they do. Every option is tried, every product evaluated, every algorithm timed, and the developers doing their best to respect the newly incremented and elevated "Eleventh Law of the Duke of Greenspun"--by implementing an ad hoc, unspecified, completely broken, megaslow, and appropriately helpful and worshipful version of at least three quarters of Common Lisp that was programmed to help create the "Nine Missing Laws" that weren't.... Well, you get the picture.
  • Wrong Order Because there is so much time to do everything, few of the developers are going to want to do the hard things like: well, talk to the customer to get feedback on the interface mockups, or create the mockups in the first place, or revise anything once they do have the feedback. You know, really, do any design work on the interface at all. Instead they will pick the "cool" stuff. Or the "quick" stuff. Or the "easy" stuff. Or, y'know, they'll go to look up something on wikipedia and end up with a tree of subjects for which they will have needed to actual implementing a custom tree structure in their own brain. (Ha ha, only serious!)
    And all of a sudden there will come a time that everyone gets this sinking feeling in the pit of their stomach because, well, the only stuff left now is the hard stuff, and drudgery, and worst of all you'll be trying to tack on the interface work at the very end, without time to properly iterate with the customer, or any reasonable proxy customer, because things just have to get done. Well, my friend, welcome back to Case 1.

Again, there are other issues, but they will all bring things back to where we started.

Strategies

So, we detailed the cases in order to determine the best strategy not just to enjoy a little bit of nervous laughter with each other as we recognized that we are all just sliding toward Case 1. (Seriously, maybe if we could a flux capacitor?)

So let's look again at the steps and see what we'll do and try to come up with a way that lets us customize them based on where we are on the scale between the extremes.

Initial Phase

  • try to get a good idea of what the customer will do with the product, and why (have them step you through how they would typically use it in the course of the day)
  • get the initial customer desires and wants, however detailed or vague
  • come up with mockups (good) or active prototypes (better) of one or more options that meet their needs as you've determined based on the information gathered from the customer

Case 2 Strategy: So, the closer you are to Case 2, the more time you will have for this phase. However, do not take this as a reason to spend more time than is warranted. At most you will want to schedule adequate time to come up with active (but at this point not necessarily working) prototypes of the bulk of the possibly desired interfaces. Ideally you will come up with at least two options for each different feature. It's not necessary to have everything integrated as a whole here, although it would be nice. Just allocate a reasonable amount of time and get what you can in that timeframe. Also, by doing active prototypes here, you will be doing some early vetting to make sure you didn't inadvertently end up with a case of Hard Platform, and if you did, it will be early enough int the process to adjust the schedule.

Case 1 Strategy: Strategy The closer you are to Case 1, the less time you will have for this phase. It's important to be as efficient as possible here. Instead of doing working prototypes, do simple slide mockups, or just draw them on paper, design them on a form designer, whatever it takes to do it quickly and with a minimum of fuss.

Now, if you have only partial access to the actual customer, go ahead and get whatever feedback you can and have whatever interaction you can. Then with either customer or proxy customer (ideally more than one person) actually walk yourself through the mockups or active prototypes. If you have mockups, print the slides out on paper so you can press buttons and use pencils to mark up your layout and make notes on what seems to work and what-not. Make sure you find out here, if you hadn't decided already, whether you are going to need more than one level of interface.

cowcat: So, if you're closer to Case 1, have a focus group of customers or proxy customers, and go through the flow of what they are going to do with your app. Try to pick the minimal set of filtering and sorting capabilities that satisfy the needs. (e.g. "well, we definitely need to sort on last name, first name, date, but we could probably do without (x/y/z). and we have to have filtering on city, state." etc.) Make sure those "minimal" needs will fit into your constraints, or do a de-scoping iteration by having a customer or proxy choose between several different feature-sets that you could deliver within the constraints you have.

cowcat: If you're closer to Case 2, it's probably advisable to come up with a few different options for sorting and filtering, and then create a couple of prototype solutions to demonstrate the basics of the features. Don't spend much time trying to compose this into a coherent application, you just want to be able to give a little study to the different options. The "ideal" solution would be to implement "everything" with easy config to switch between all possible options, but don't fall into the Goldplating trap. Set a deadline and stick with it, if it's not possible to do all you wanted, just accept it and de-scope, if you're slipping by as much as a week or so, I would say you've likely hit Goldplating or Hard Platform. The important thing here is just to have something that can be genuinely evaluated from a customer perspective. And for that matter, a development perspective. If one particular option is taking 80% of the development time, that might be the cue that it's not a good option, and to throw it away or replace it with something simple. DTSTTCPW.

Iteration Phase

It's time to iterate again! As you repeat this process you will come closer and closer to the ideal solution. Whoa, Deja Vu.

(Fade In) If I had ever been here before on another time around the wheel I would probably know just how to deal. (We have all been here before. (repeat lots)) (Fade Out)

  • take the customer feedback (far better if generated interactively in the previous step) and incorporate that into a consolidated mockup/prototype.
  • once again get feedback, preferably interactively with the customer, to refine the idea

This is actually basically the same step as the previous one, except these iterations will likely be smaller and smaller as you approach the ideal solution. Everything is the same, except the goal is (this isn't necessarily the number of iterations, there may be more than one for each stage, or there may be combined stages, depending on the scope of the project): (mockups/active prototypes)->(working prototype of app interface)->(working prototype of app)->(alpha)->(beta)->(party!).

And that's it! You created an interface that is as close to the ideal interface as the constraints allowed. (As opposed to a "Star Trek" interface. Hey does anyone know what this unlabeled red blinking button does? Hmm, or is it an indicator. Oh, nevermind, someone was just playing aroundwith their phaser set to 'cat').

Your customer is happy, you were successful, and you'll be ready to take on the next job. Pat yourself on the back and have a beverage!


Final Thoughts

For doing sorting possibilities, I recommend using/creating a good multi-sort table that's not clunky with 9 column sorting, e.g. can easily deselect/change sort fields, not one based on clicking columns in order with nothing else. e.g. Dojo has a nice multi-column-select table, if you're doing JS, but even if you're not you can go to the Dojo website and find a demo some different tables and how they work. If you're feeling fancy you could even do some of your active prototypes in a fiddle. I would recommend looking first at whats available to you off-the-shelf (or in-the-open-source) for your platform and making sure it can handle what you need to do.

But if you're on a platform that is going to require you to roll-your-own anyway just do the best you can do within your constraints to create an easy-to-work-with sort mechanism. Incremental evolutionary design works wonders. Ideally you would choose at least two fairly different but usable methods, in case the customers turn out to have a preference; obviously the closer you are to Case 1., the fewer the options you will be able to offer. Once you do have chosen or implemented your table, there are probably a fair number of simple options available to enable/disable features of the table or a specific column.*

For filtering, I recommend lookat at some of the ideas you can glean from actual working sites, and/or see if there are any off-the-shelf/in-the-open-source products that suffice for your needs. For instance, newegg's hardware selector has three good ideas that work with that type of data, and that could probably be reworked for your app: "guided", "advanced", and "power". Once a filter is applied you can easily remove individual terms from a list that's displayed, like "Home > Computer Hardware > Motherboards > Motherboard / CPU / VGA Combo (x) > Combo Type : Motherboard/CPU Combo (x) > Price : $100 - $200 (x) > Useful Links : Discount Item (x) (1-20 of 21 Results)" from which you can remove terms from anywhere in the filter chain. There are also nice features you might see along the way during building a guided filter, e.g, in parens is a count of the number of items left if you choose that filter.

Anyway, the point is there are lots of good ideas out there, and you may or may not have to modify them somewhat to match the spreadsheet model, but if you have a few choices, then you are more likely to come close to the ideal interface. If you are in a Case 1 type situation, I advise narrowing it down to a reasonable list of choices (needless to say, ones that would be doable within your constraints) and doing a focus group using mockups or slides or whatever to walk customers or proxy customers through, in order to find which is most likely to meet their needs.

So, that sums up how I think you should do this. I know it was a whole lot of words, but, from my previous experience building almost exactly the type of interface you are talking about, it didn't take long. I had fewer options, but mine took about three feedback conferences with the customer, a few emails, and somewhere around 4 other iterations, half of which were to fix just a single issue. Overall time spent was on the order of 40 hours, including beta deployment and the bug fixes. It really comes down to striking a balance of how much of the time budget you can you can afford for each step, based on how close to being in a Case 1 predicament you are.

['Design->Schedule->Rescope->Demo->Enquire->Evaluate->Revise->']+


A/B Testing

This article by Lara Swanson goes over a type of test that can be a very useful part of a UI testing strategy, A/B testing:

What is an A/B test?

In an A/B test, you compare two versions of a page element for a length of time to see which performs better. Users will see one version or the other, and you’ll measure conversions from each set of users. A/B tests help designers compare content such as different headlines, call to action text, or length of body copy. Design and style choices can be tested, too; for example, you could test where to place a sign-in button or how big it should be. A/B tests can even help you measure changes in functionality, such as how and when error messages are shown.

She goes through some of her testing, and suggests some tools for recording and measuring the results, for instance two metrics tested against in the article were 'conversion rate' and 'bounce rate'. She also talks a little about the tools she uses, and gives a link to whichtestwon.com, which has real-life A/B testing samples and commentary, as well as other resources, like this list of testing tools.

share|improve this answer
4  
could you summarize as a tweet...? –  Roger Attrill Aug 13 '11 at 17:13
1  
> Instead of trying to pick cowcat's brain to try to ask the right questions, I outline a simple process model for figuring out UI requirements while using an iterative/agile design methodology to create the final product. So basically you could post this as answer to any other question on UX.SE. –  Vitaly Mijiritsky Aug 13 '11 at 18:28
    
I very much appreciate this response! I'm definitely in a case 1 type situation right now, with limited resources. Additionally, it's more a waterfall process at this time, with the project becoming agile at a certain point. Again, definitely appreciated and comment saved for later! –  cowcat Aug 13 '11 at 18:58
    
@Vitaly only if that question deals with how to determine the proper UI for a particular customer... –  shelleybutterfly Aug 13 '11 at 20:54
1  
tweet version: if you want to do a good UI you need to do back and forth with either your customer or someone that can adequately represent your customer and iterate until it's as close as you can get to the evolving desires and goals within the constraints you face in your project –  shelleybutterfly Aug 13 '11 at 20:55
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.