Is the message the problem?
I’m not clear what your problem is, except that you don’t seem to like your users or how they’re using your app (you call them “lazy” and say they’re “exploiting” (abusing?) a feature, but you “allow” them to do so).
- Are users complaining about the performance hit of 1000+ records?
- Are they ignorant that narrowing the search would speed things up?
If the answers are “no” and “no,” then maybe you don’t need a message at all. Just accept that users will use your app this way, probably for good reasons you don’t understand with the information you have right now.
If the answers are “yes” on 1 and “no” on 2, then a message is useless. It tells them something they already know. Instead, maybe you need to focus on your search tools UI. Perhaps the real problem with the app is that entering (additional) search criteria is so complicated, or time consuming, or has such unpredictable effects that users feel better off if they just keep scrolling.
More likely, adding a keyword means the users have to start all over again, and look through many of the same 1000 records they already rejected. They have a huge sunk cost re-doing the search. Meanwhile, the record they’re looking for could be just this one more page away, so let’s keep scrolling!
The Solution
But I’ll assume the answers are “yes” and “yes.”
That being the case, I would go with a modeless message that appears right beside the 1001st record:
Main List response slows with so many records. Add more keywords to speed it up.
Exact terms need to be consistent with the labels and captions in you app. Maybe give the message a turtle or snail icon to catch the users’ attention and link the message to the problem they’re experiencing. Put the message by the 1001st record because that’s where users will be looking –they look at the next record on the list when they’re scrolling and scanning for something. It also helps associate the message with the problem –so many records.
Position the message so it doesn’t overlap anything. Maybe move things out of the way if you have to. Let the message scroll with the 1001st record so it naturally goes out of view without the user explicitly dismissing it, but the user can find it again in case they didn’t read it carefully (they probably didn’t). I don’t think you need to show it again 5 pages later. That just gets annoying.
The Real Solution
All that said, I suspect you app has bigger usability problems than how exactly to show a message. Your users are scrolling through over 1000 records. That sounds like a lot of work that shouldn’t be necessary. What can you do to improve the design to make that very rarely needed?
- Is your search criteria problematic as described above so it’s literally better to scroll through 1000+ records than figure out the right keywords? Should you supplement key word search with structured? Including a few commonly used structured criteria fields (e.g., record creation date range) may help a lot by guiding the users on good criteria to enter, and allow users to completely eliminate whole swaths of records by a single attribute value.
- Can you tell the users how many results they'll get with the current criteria? Or how many results are reasonably relevant? If the number is 2600, maybe they'll refine their search before investing sunk costs into scrolling and scanning, and then discovering, oh crap, there's still more. (That's UX problem of infinite scroll --it gives the illusion there's not much to scan for).
- When the users refine a search, can you give them an option to suppress all the results they already looked at (and presumably processed or rejected)? Or remove the records that don't meet the new criteria, but keep the record order and current record unchanged? If you make it easy to refine the search without the users "losing their place," they may refine it long before they get to 1000. Do you make it easy to revert to a previous search results (taking them to where they left off in the list) if adding a keyword doesn’t work out?
- Is your sort order or relevance wrong so the right records aren’t appearing closer to the top of the list? Can you improve that? What can the users tell you they’re actually looking for when they go to 1000 records? Can you put that in an algorithm or field?
- Are they trying to do too much with one search? Your comment mentions users "playing" with the scrollbar, which sounds like they're scrolling up and down. Why are they doing that? I don't believe it's for fun. Are they comparing results from different parts of the list? If so, maybe they need multiple search windows or panes where each has overlapping but more narrow criteria to get two short lists to compare side by side, or maybe they need to mark some records as "candidates" that appear in a separate pane so they can see how later records compare when they refine the search.
- Another problem with infinite scrolling is there’s nothing to help the user decide when to stop. Are you showing insufficient information with the records to help users realize the trail has gone cold and there’s almost no chance of finding what they’re looking for? Maybe you can include a relevance field of two to five discrete values. When the “Match: VERY LOW” records appear, that’s the user’s cue to give up.
It’s possible that the users’ task simply requires that they look at 1000+ records sometimes. Maybe there just isn’t a way to narrow down the number of records in a smaller number (e.g., their job or situational incentives require that they do an exhaustive search, not a merely sufficing search). If that’s the case, then you need to accept that they will go beyond 1000 records and find a solution to the performance problem. What exactly is causing it, and what can you do about it? Is it just due to the raw number of records in the window?
Paging will solve that, but the users don’t like paging, and I happen to think they have a point on that. The thing is, infinite scrolling isn’t much better, really. You need to invent a new way to handle this many records. What if adding records to the bottom also removes the same number of records from the top? If the users are scanning or processing the records linearly from top to bottom, then they’re typically finished with the records above. So remove them if performance is slowing.
What if instead of a scroll bar, there were something more like a “super-thumbwheel” that the user can click and/or swipe so the user can selectively show one record at a time or a page-full at a time, or more.
What if you had a graphic display (maybe in the thumbwheel or beside it) that gives a representation of the entire list without scrolling? Can you show where the user is among all the records in the results? Could the graphic display give clues are where in the results the user should look first and allow them to jump there? Can they first work on the records at a higher level of abstraction, and then, with a click, drill down to small list of records they are specifically interested in?
As always the solution to usability problems often comes down to what the user is actually trying to do.
