I have a client/server system. A database table on the server can contain a million records. I need to present various filter criteria to the user. One filter needs to be a server-side filter, such as a date range, so that the server only sends a subset of the records to the client, say 1,000. Another filter, also a date range, will filter those 1,000 records only on the client. So, say the user chooses date range 1 to filter the 1,000 records into 500, then chooses date range 2 to filter the 1,000 records into 300. The client-side filter (500 or 300 records) does not require any interaction with the server.

How would you suggest naming the server-side filter vs. the client-side filter so that a novice user understands this?

All I can think of is using something like "Quicker Download", but I don't know if they would understand. Of course, we will have tool tips to add more information, but I'm hoping for very good UI labels. I do not have any icons for this and I really don't want any.

I am planning to use a filter panel similar to reed.co.uk, so I can have headings.

  • Welcome to the UX SE. Nice first post. Jan 4, 2013 at 3:43
  • I don't really see why the user would want two different date ranges where one is a sub-range of the other. Wouldn't it be faster for them to just give the smallest range, and more efficient for the database? On the client side, you could perhaps do some handling if they change the range, so that you don't download the same records again, though.
    – Sardtok
    Jan 4, 2013 at 14:49
  • @Sardtok - Thank you for your opinion. I am definitely listening to it. Jan 4, 2013 at 20:32

3 Answers 3


If possible, I would try to completely avoid showing the user the difference between server side and client side filtering.

Will your users care where the filtering is done? Unlikely. So don't give them this unnecessary info.

Better is to construct you UI in such a way that the first filter is always automaticaly server side then all subsequent filters are automaticaly client side.

  • I think I understand what you're saying, but they will care when a million records get downloaded into a report or not, don't you think? It could take a very long time to generate such a report! (We are going to offer scheduled reports at off-hours.) We're thinking we could default the server-side date range to the current month depending on the report. Are you suggesting only one date range and eventually the users will get a feel for the system behavior? Jan 4, 2013 at 3:34
  • Maybe you could make the first (server side) filter mandatory or (as you suggested) possibly automatic. Another option would be to just return the top n results. Without knowing a bit more about what your app does/reports it is difficult to tell. In any case, I am saying that where the filtering is done is not something you should be bothering the end user with.
    – Tims
    Jan 4, 2013 at 3:59
  • I found this quote which I think applies to this quite nicely (though it was originaly aimed at more general tech)..."The most profound technologies are those that disappear." - Mark Weiser (From The Computer for the 21st Century, 1991)
    – Tims
    Jan 4, 2013 at 4:03
  • I disagree with this statement, Tims : "Better is to construct you UI in such a way that the first filter is always automaticaly server side then all subsequent filters are automaticaly client side." --- if we're talking thousands of complex records - this is a really silly (im being gracious) approach and it should not be assumed that the enduser client (think wonky old pc) can handle that sort of memory burden without being a significant detriment to the user experience ----- sure it would work - but it wouldn't be "the best idea" Jan 4, 2013 at 6:07
  • As stated, the first subset of records sent to the client should be ~1000. Most computers (and smart phones) should be able to handle this.
    – Tims
    Jan 4, 2013 at 6:16

It seems like you're asking the user to optimize the download process - is your target audience going to understand this and be able to make reasonable sized requests?

Why not simply paginate the results (as does reed.co.uk, google.com and many sites)? Then the result list size doesn't matter (in all but extreme cases).

Another option is to not immediately download the result of the query/filter but to indicate the number or items found, and then the user could download and display the items or refine the filter to reduce the number of items.

  • Thank you for your thoughtful answer. While valid, I think I am forced to only select one. I am giving "the" answer to Tims because he was first, provided more information, and yours seems to be a subset of his. Jan 4, 2013 at 20:33
  • No problem, Tim's answer is a good one.
    – obelia
    Jan 4, 2013 at 20:48
  • @WildRumpus you can still up vote obelia's answer to give him some credit
    – icc97
    Jan 5, 2013 at 22:33

So the way that Reed works is that first you do a search for something and then you have a slider to move within the search.

So you can separate the forms with input buttons that will do Server side requests with more interactive javascript controls that do client side filtering.

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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