2

I have a list of addresses on a mobile app. What is the best way to handle pagination and loading errors?

example:

  • The list is paginated by default. 5 items are shown, with a "Load more" button

  • what happens if user presses "Load more" and there is a server error?

  • should I maintain the 5 items that have already loaded and show a modal error?

  • should I show an empty state with error message instead of the whole list?

  • should I maintain the 5 items and show an error state below the items?

Thanks!

Improve this question
1
  • Please add some more detail for the use case: How many addresses fit onto a regular screen? Is the list sorted somehow, and how likely is it that the selected address is on the first page? Is there a sorting/filtering mechanism, and what to users sort/filter? As you can see on the internet, and in your list of questions, there are many different solutions. Some of them are simply better than others, but many of them are just more appropriate to the respective use case. As long as you are not clear on your use case, you might as well just pick any of the solutions. Commented Jan 11, 2024 at 8:39

2 Answers 2

Reset to default
1

I'm sorry to not address your question directly, but I recommend against "Load More" - to me, it feels like an offence.

  1. It does not show where in the entire list I am right now, like a decent scrollbar does.
  2. When I need to scroll down, clicking "more", waiting for the response, and clicking "more" again is much more cumbersome than grabbing the scrollbar and moving it down (even if it takes some time to load the next items).
  3. Should I need to get to the end of the list, I need to press "more" multiple times and wait every time for the response. With a decent scrollbar implementation, I can move the scrollbar to the approximate area I want to go without even loading the data that I scroll over. Think of a "random-access" list.
  4. Whatever page size you decide on (5, 10, 15), there will be a larger monitor somewhere, which will show unused whitespace or require more "paging" than the page actually requires.

This does not mean that all data must be loaded at once. "Lazy loading" allows to show the first entries and only load data as the user scrolls.

From your question, I infer that you are worried about the case when paging or lazy loading fails somewhere in the middle (which I've never seen, I admit). That should mean that it's an intermittent failure (because some data has already been retrieved). For that case, I'd recommend the following:

  • Keep all entries visible (and scrollable) which were loaded
  • Show "Loading failed" in the rows which could not be loaded
  • Offer a "Reload" function for these rows
  • The app might also retry automatically after a while.
Improve this answer
0

In the context you've described, specifically when the user clicks "load more" and the initial 5 items have already loaded, it's crucial to address the server error appropriately. Typically, server errors prevent the display of regular content, resulting in a blank screen accompanied by the server-generated error message.

Distinctions exist between errors originating from the application code base and those stemming from server issues. The behaviours of these two types of errors differ significantly.

If the "load more" action triggers a server error, my recommendation is to implement the following approach: "Display an empty state with an error message instead of presenting the entire list." On the other hand, if the error is not associated with the server but rather with the application itself, you should consider this alternative: "Maintain the display of the initial 5 items and showcase an error state below them."

I think this approach provides the users with clear and relevant feedback, ensuring a more user-friendly experience in response to different error scenarios.

Improve this answer
1
  • Hi, I'd be interested why you think a distinction is useful between server error and application error? I would argue that many users can't explain what the difference is and even less users (down to only the ones implementing the app) are interested in knowing where the error occurred... Commented Jul 28 at 15:39

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.