When dealing with a large data list, is it considered bad UX to make the user manually refresh to update the list?

Question

I am dealing with a large list of items right now. For the sake of this question, it will simply show whether a device is online or offline (there is a lot more data, but those items are more static so it doesn't matter as much).

So the user has a list of devices, of which they are either online or offline. Currently, the graph only updates when a user hits the refresh button. If the user uses the filter option, the results are not updated with the most recent data. It is not currently possible to have this list dynamically update, so we can:

• either update the list every time the user filters something or takes an action (takes much longer to call the backend server to get the most recently updated data) or
• have the user manually refresh the list when they want to update it (much quicker to sort through).

In an ideal world, we would be able to have this list update dynamically, but due to our limitations, is it ok to have the user click a refresh button whenever they want to update the list?

The reason why I don't want to update the list everytime there is an action, such as filter, is because each time we need to update the list, it takes about 5-10 seconds. Here is the bottom left portion of the list currently:

Answer 1

What you're dealing with is the normal tradeoffs of design.

Ideally, the list updates itself. So in that sense, we would want the user to not have to update.

That being said, we deal with limitations all the time.

Sometimes it's purely technical: the API simply won't return a piece of data, or we can't update when we want to. Sometimes it's a product reason: The PM has calculated that something is super low priority, and won't resource it.

If the call takes a long time, it seems like you could still try a refresh, but have a banner or some message telling the user the system is fetching the data, and could take a few seconds. If you tell the user what's happening, they at least know the status of the system.

See Jakob Nielsen's usability heuristics

Visibilty of system status: The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.

What you have now (the 'last updated')

If you can't get the dynamic (but slow) update, having the 'data freshness' labeled is very good. Users should know when the last update was. One option is to use relative time:

Last updated: 15 mins ago

This way the user doesn't have to do the mental calculation of reading the date and comparing to the current time. This can work if absolute accuracy is not important.

Answer 2

Auto-updating lists can cause plenty of annoying issues:

• updates can lose scroll bar position or shift the view port position in the list, forcing the user to search again for the item they had just found
• you click on an item, it disappears
• inserted/deleted items interact with multiple selection in all sorts of interesting ways
• etc

Since this is a list of connected devices, the worst case would be trying to find a device with a flakey connection. With a manual refresh button, you could enter the name of the device (or any other search criteria that can find it) in the search/filter settings, then spam "Refresh" until the device appears. Then you can click on it to see its properties. However, with an automatic refresh, the device with the flakey connection could then disappear from the list before you can click on it.

Auto-refresh is also a great way to generate lots of useless API calls on your server and bring it down.

Suggestions:

UI for enabling/disabling auto-refresh, with three settings: auto, disabled, and a third setting for which I have no inspiration to pick a name, but it'll just warn the user if there are updates without actually updating the list.

If queries take a while, server API should take a parameter indicating if this is an auto-refresh query or an interactive query, and prioritize the latter.

Along with results, server API should return a minimum auto-refresh timeout. Client must wait at least this time before issuing another auto-refresh. This can be used on the server side to limit the rate of auto-refresh queries depending on server load.

Then, if enabled, do auto-refresh queries in the background so the user doesn't have to wait.

This is all a lot more complicated than manual refresh, with more chances of bugs, of course.

Answer 3

The first idea that comes into my mind, if that fits your use case, is a kind of combination of both:

• Use a threshold for the bunch of currently visible items in the filter result [let's call this just result for brevity]. The threshold's proper size for an acceptable refresh time must be determined empirically. (The rule of thumb I'm used to: More than 3 seconds is too long for every day tasks or for those performed often within a short period of time.)

  • If it fits to your use case: Let the users define their individual threshold in the app settings, since refresh time might be different from location to location, e.g.:

    Auto-Refresh if filter result is less than   nnnn  │ ▼▲ items big.

• If result is below the threshold refresh automatically, otherwise don't.

• Tell the user what is up-to-date.

If I understood, thought everything correctly there are:

• 3 refresh states: 🟢 🟡 🔴 (always one of them assigned to / displayed for result) and
• 8 (▶) paths to come to them.

Which leads to:

A Filter is set or not:

1. ▶ Refresh (both automatic or manual) failed for whatever the reason was

   ➝ 🔴 Items not up-to-date

A filter is set:

2. ▶ Result is below threshold ➝ refresh result automatically ➝ 🟡 Result up-to-date

3. ▶ Result is above threshold ➝ don't refresh ➝ 🔴 Items not up-to-date

Supply manual refresh in addition, distinguish at refresh between:

No filter is set:

• ▶ Refresh All ➝ tell the user about possible longer delay, maybe with:

  4. OK ➝ refresh all ➝ 🟢 All items up-to-date

  5. Cancel ➝ don't refresh ➝ 🔴 Items not up-to-date

A filter is set:

6. ▶ Result is below threshold ➝ Refresh Result ➝ 🟡 Result up-to-date

• ▶ Result is above threshold ➝ Refresh Result ➝ tell the user about possible longer delay, maybe with:

  7. OK ➝ refresh result ➝ 🟡 Result up-to-date

  8. Cancel ➝ don't refresh ➝ 🔴 Items not up-to-date

Where the colours mean in detail:

• 🟢 ... all items are up-to-date
• 🟡 ... some items are up-to-date (those of result);
           it can't be said which of the others are up-to-date or not, some may, some may not
• 🔴 ... it can't be said if any of the items is up-to-date;
           some or even all may, some or even all may not

There could also be an info:

• absolute:
  • X of Y items up-to-date or
  • X / Y up-to-date or
  • Up-to-date: X / Y and
• a percentage of the overall items that are up-to-date

in addition to the color indicators.

To avoid misunderstandings:

The refresh state introduced in this answer must not be confused with the connected state (Online/Offline) mentioned in the question. They are different objects in different domains. E.g. in case the refresh state is 🟢 All items up-to-date the connected state of an item can be Offline and that can be absolutely correct. Since Offline is the actual current state of the item then.

PS: Mail with invoice follows. :)