1

In one legacy UI application on which I am working currently, has a Main List which is used to display all records stored in elastic in paginated way. Elastic may have more than 1 million records.

The problem arises when I added a functionality of loading next page of records when scroll touches bottom (no direct pagination widget).

In the introduced functionality of scroll load, user can scroll infinitely. for each "scroll at the bottom" event, data loads from 0 to pageNo*pageSize records. I set page size as small as 50 records. So, for example,

  • Page 1 will load 50
  • Page 2 - 100 records
  • Page 3 - 150 records
  • Page 4 - 200 records

and so on..

I want to acknowledge user after a certain page number like 20 pages(1000 records loaded on browser) that Don't go further otherwise application will become slow, use search with keywords instead.

Actually, I am doing so by putting simple auto hide alert which will start appearing from 20 pages onward and will display in interval of 5 pages like 20, 25,30 etc.

Is there any better way to acknowledge user that he is exploiting functionality because we are allowing him to do so?

I know this type of data loading sounds crazy but this is what we have to do. I need help on letting user know that application will be slow after a certain period of time.

Following is the sketch of Web application portal I am talking about. enter image description here

Thanks in advance.

  • How good is your search? This behaviour is logical and to be expected if "find in page" is better than anything you can offer (perhaps taking the results of your search on one field, and searching for an exact key phrase (a related example from today: I needed to find mentions of "Google Calendar", not "Google" and/or "Calendar", but the search interface didn't support quoted phrases) – Chris H Sep 23 at 12:30
  • Users that "exploit functionality" should be a flag for the designer that something interesting is going on. Don't ignore it or shut it down. You should dig deeper to figure out what the underlying need is and solve that. – Bowen Sep 23 at 15:03
2

After a decided limit, stop automatically fetching more records and switch to a pagination style navigation.

So perhaps you decide that you'll stop the infinite scroll at 500 items, then start paginating after that, with 100 items per page. The bottom of your (non-)infinite scroll section will show a View more items → button, and land the user on page 6, showing items 501-600. From here on, the user sees only the paginated navigation, so their device doesn't get overwhelmed with endless DOM elements.

Also, take this opportunity to ensure your search tools are easily discoverable and not hidden away where they can't be found.

Anecdotally, my bank does something similar to what you hinted at: after clicking to load more transactions for the third time, it suggests that I use the search tools instead, but still allows me to dismiss the tip and continue clicking for more. However, I haven't tried to see how long it'll let me continue with that.

| improve this answer | |
  • Yes, that is a good idea but as I said button for pagination is something "Mole on the UI" for clients due to their previous experiences.That's why I asked for the message type. And yes, I did the same pop up message which is auto hide after 15 sec and (x) button enabled. User can dismiss it anytime. Search Tools are Right in front of their eyes just above the data grid as a toolbar. – Moksh Sep 19 at 17:57
0

In your case, I would try to include both options, pagination, and infinity scroll. The following is an example.

enter image description here

| improve this answer | |
  • Thanks for the idea. But User does not want to have pagination because this is extra action to do (they are too lazy). If I was allowed to introduce pagination, I would have implemented both option. But I can't. – Moksh Sep 19 at 17:50
  • 1
    @Moksh Then I hope they have the GB of RAM needed for thousands and thousands of records in memory. I would recommend doing some calculations and incorporating those in the documentation (browser Z v. 2.5 needs X MB of RAM per Y records). Your client is going to get its browser killed in order to free memory, and will be blaming you... – Ángel Sep 21 at 22:40
0

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).

  1. Are users complaining about the performance hit of 1000+ records?
  2. 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?

  1. 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.
  2. 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).
  3. 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?
  4. 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?
  5. 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.
  6. 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.

| improve this answer | |
  • Thanks for the descriptive answer. Actually, the case is No for 1 and Yes of 2. Users are skipping narrowing search and how it will affect application. I updated the question with screenshot. Searches are easily accessible and to the point on the fields as per my understanding. I just introduced current implementation what explained in question because before that Buffered Rendering was in place which was causing load on server by just navigating scroll bar. Actually, users were playing with scroll bar which causes heavy search load on servers. So. I rescued servers by this approach. – Moksh Sep 21 at 18:05
  • It seems your users don’t mind the slowness. Forget about the message. A perfect message is not going to work, because the users don’t care about your poor servers. Do more user research to find out why the users end up with 1000+ record. I can’t believe they like it. It’s something they feel stuck with. Redesign the app so users can accomplish their goals without loading 1000+. I’ve added a few more design examples to “The Real Solution.” – Michael Zuschlag Sep 22 at 1:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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