Last modified: 2012-06-07 09:42:55 UTC
When using the #ask parser function, one can specify the limit parameter. This parameter defines how many results to display. If the number of actual results exceeds this value, a link appears called "further results". One can click this link and see the "semantic Search" page, with a listing of all the results. This "further results" page receives the limit parameter from the initial #ask query, and the results on the "Semantic Search" page are also limited by this value. To view more per page, the user is required to select a value at the top of the page, like 100 or 500. A valuable enhancement would be the ability to specify two limit values: one for the initial display, and one for the "further results" page. This way, the user isn't required to make an extra click; the administrator can set the default value to a large number, while keeping the initial #ask query limited. In some situations where the number of results is large, it can be preferable to display a very limited amount of them on the page of the #ask query, but display all of them at once on the "further results" page. In this situation it is a better experience for the user to not have to look for the "# to display per page" values, and simply be presented with all the results.
Agreed, would be nice to have.
While it is understandable to aim for the least impact on a user when choosing some options, I'm not sure that "further results" limit is one them since it would allow to set high limits that might cause incalculable database selects for result sets that are not being used nor actively sought for. Aiming for a large result set to be displayed does not make to search faster nor does the convenience level increase because the fundamental problem still persists for the user to break down his/her search results. I think, it would be rather more efficient to wait on the ability to reuse data via ajax and let the user decide how for (how many elements) he/she wants results to be displayed as on the contrary to allow large results to be pre-selected without any user interaction. Finding the "right" result is not paramount with a large result set and other things should be considered first: * better formats * general ajax support * query caching * search interface etc. Improvements should generally increase interactivity for the user and not increase potential performance pitfalls.
