2

I'm developing a reporting application where a user can make some searches on our database against an extremely large data set and display them in a table on a web page. One of the searches has the potential to display way too much data for the web page to reasonably display in HTML on a single page. Pagination and "Load More"/infinite scrolling models aren't possible as the user needs the option to print or sort this whole result set. Exporting the data to a non-HTML format is possible.

I need to inform the user that their search can't be completed (as normal, at least), but how? Should I show the partial output with a message like "please narrow your search" or should I refuse to display too much data?

Displaying the large data set on the page results in very slow load time (>30 seconds), and they're going to have to run the search again to get a "full" data set. At the same time I'm afraid a "please narrow your search" message may be too vague. It is possible for me to tell them how many possible rows their search would have pulled, and how many rows I am displaying, but I'm not sure how to word this.

How can I tell a user that their search has been canceled?
The user has specifically said they don't want the data paginated except for print, all results need to be continuous.

Improve this question
2
  • 2
    if not pagination, what about Continuous Scrolling?
    – Erics
    Nov 12, 2011 at 4:52
  • @Erics they're reports (I should have been more clear) so if they don't all show up together it's a big problem.
    – Ben Brocka
    Nov 12, 2011 at 17:14

7 Answers 7

Reset to default
1

Don't give them the chance to create an invalid user interface state.

For instance, you could disable the submit button by default until they input parameters that are valid. You'll have to be communicative about how to achieve that, but it would help them up front instead of after the fact. A lot of travel websites work this way. Here's one we made a few years ago: Vacanceselect.nl - take a look at the big search widget on the homepage for an example of what I'm talking about

Improve this answer
3

Tell them that the search was stopped, but explain why (too many results). As the user has instructed the system not to paginate the data, I would present it as an option again.

But the user may not be able to narrow their search, so I'd prefer to show partial output. And in addition, give them the option to grab the rest in a different format like CSV. Salesforce does this with their search: it presents you with up to 2,000 results, and to get the rest (or all of it), you need to export it to Excel/CSV.

The spreadsheet (CSV format in particular) should be less resource intensive than a large HTML table.

Improve this answer
3
  • This is a system in which there are a great number of ways to limit the search, it's a very specific interface. Good point about the CSV though (assuming my data is free of comments...) I might bring that up. Since I have basically one (and two backup) users I'm not as concerned with my particular solution as how to approach this problem in general.
    – Ben Brocka
    Nov 12, 2011 at 0:20
  • I've used a fair number of systems that would show a banner at the top of search results in this style: "Found 10,345 matching records, showing top 100." You could do this, allowing interactive use of the top 100, but also provide Print All and Export All options.
    – Bevan
    Nov 13, 2011 at 3:14
  • Is it possible to make certain fields required (I'd imagine a high-level "category")? Or perhaps make minimum X of fields required though I won't recommend either (esp. w/out more context); just a thought. I could see the latter in a fantasy league roster interface.
    – andrewthong
    Nov 13, 2011 at 4:09
1

It depends what the "strains on your hardware" involve. Is this simply that generating the number of results in one go is an issue? Or generating this number at all would be a problem? Or is the strain of running the search at all is too much of a strain - the width of the search is too great? Or that displaying this quantity of data on the clients will be an issue? Each of these has a different solution. There are three options that I would suggest:

  1. Continuous pagination, where the first 10/100/1000 entries are produced first time, and then produce the next 10/100/1000 to add to this list when ready, and so on until the entire result set is displayed.

  2. Limiting the search parameters dynamically to reasonable searches. This depends on whether it is possible to do this.

  3. Limit the searches to 2000 records - make this clear at the start, and always restrict searches to this limit ( which could be any number ). If there are more, then stick a message to say "More than 2000 records were found. Please restrict your search further"

And I think "Restrict your search/selection" is better than "Narrow your search".

Improve this answer
1
  • Generating the count of results is trivial, and catching all results isn't that bad from the database, but presenting them on the webpage isn't feasible. 3 is the option I'm considering, 1 is interesting but a big part of this is print; it has to all show up at once or it's useless. That's where I'm considering CSV.
    – Ben Brocka
    Nov 12, 2011 at 17:13
1

Some SQL / Data Warehouse clients have to deal with this problem. One way to solve it is to allow users the option to preview their search before they execute it. The workflow is:

  1. the user designs the search by specifying the parameters and query
  2. user selects the 'Preview Search' option
  3. System displays search preview - this could contain result set size, first xx results and estimated execution time
  4. the user can fine tune the query, when they are happy they select the 'Execute Search' option which, as @andrewthong hints on, provides options for format (web page, CSV, Excel)

If you follow this model, you should never have to tell a user that they cannot perform a search, you just set an expectation of the cost to run it.

Lastly, it might help you to think about this as a 'report' problem rather than a 'search' problem. Many webapps I use on a daily basis have report functions (Rally, JIRA, Salesforce, CODA, Oracle Discoverer) - I expect that some you use may have too. Play around with them, you might get some good ideas.

Improve this answer
0

@Erics has an excellent point (and should make it an answer). You can display the first X results, and have a button saying something like "load 100 more results", the way they do it on the iPhone sometimes, and in other places.

Improve this answer
0

If your page is served with Transfer-Encoding:chunked with multiple flashes, the browser will start rendering the page before it is downloaded completely.

http://www.phpied.com/progressive-rendering-via-multiple-flushes/ talks about the technique in details.

Improve this answer
0

@Vitaly - do you mean ContinuousScrolling? http://ui-patterns.com/patterns/ContinuousScrolling

Improve this answer

Your Answer

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

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