4

We are developing an enterprise web based application where users can select / mark individual records in tables / lists (to perform some bulk actions on them). Much like in Gmail where you can select individual e-mails by ticking the checkbox to to the left of the record.

There will be a button for manual refresh of the entire grid. Additionally, on some screens an auto refresh feature may kick in. When the screen refreshes new records may appear, or some records may disappear, which will result in users having to reorient themselves

So my question is as follows - what would be better UX:

  1. Should the user's selection be retained after the screen refreshes (either as a result of manual request or the automatic process)?

  2. Should the user's selection be removed after the screen refreshes?

  3. Should we adopt a different approach and block the manual / auto refreshes altogether if user selects at least one record from the list. And if user deselects all records, the manual / auto refresh should be available/operational once again - this is the way gmail are handling this currently.

We are leaning towards Option 1 (retaining the selection) as we had signals from users of our other app that losing the selection after the screen refresh (esp. the automatic one) is very annoying.

2
  • 1
    You already have the main supporting evidence for your decisions: user feedback.
    – dnbrv
    Commented Feb 17, 2015 at 14:21
  • 1
    Ok, thanks for all the suggestions and help. For the time being we decided not to implement an auto refresh (due to time constraints). We'll cross that bridge later I guess. As far as the manual refresh is concerned, we'll be retaining user selection and approximate positioning after manual refresh (so still Option 1 :)). That should work fine, as the expectation is that the records will be added / removed from the tables rather infrequently. As a result the screen shifts should be minimal. We'll see how that works in practice and maybe add warnings or "fade out" notifications afterwards.
    – Odie
    Commented Feb 19, 2015 at 13:00

4 Answers 4

4

If the user is in a "view" / "read-only" mode, then an un-intrusive auto-refresh while maintaining the user's place in the items is the best option.

If the user is in an "edit" or "action" mode with potential changes to the item(s), auto-refresh should be temporarily disabled, and the user may be given the option to perform a manual refresh. However, the user should be notified if the manual refresh has the potential to discard his / her changes.

Having only two distinct modes or scenarios also reduces the users cognitive load, and makes it easier for the user to detect which mode the application is in (based off of whether or not they are making edits) and therefore, how the refresh is behaving.

3

It can be incredibly disruptive to have a screen auto-refresh while the user is midway through an interaction, so this is usually something you really want to avoid unless it is absolutely necessary. Unless carefully designed, it can leave users feeling disoriented or angry about the perceived loss of control over their working environment.

If you need the user to be aware of new content available for load, a common approach nowadays is to have a snackbar or toast fade-in (or blink in if it needs to be more noticeable) indicating something like "New records added (click to view)".

Then when the user clicks on it, the table slides down to show the new content added / other records disappear.

There are some applications (e.g. stock trading UX) where tables really need to change in real time and the toast approach can't be used. For these applications:

  • It can be useful to add an animated cue (e.g. a slowly pulsing dot or a periodically spinning wheel) near or in the table to remind the user that the table is "alive" and may change.
  • Strongly consider animating the changes to the table to make them smooth, and pay attention to the pace and easings of the animations, because a sudden auto-refresh of a page is very disruptive. An animated Ajax update of the table should feel smoother and less annoying to users.
1
  • I'd elaborate on your "stock trading" example: you should consider updating individual field data in place, rather than approaching it a "refresh the html <table> element" problem. The downside of this from UX is that if the decision to perform the bulk action is highly dependent on the value of a field that can change at any time, the user may not be able to keep up and perform actions they wouldn't necessarily want to perform otherwise. It's hard to give general advice here since it's so specific to the type of application, domain, and specific user expectations.
    – gregmac
    Commented Feb 21, 2015 at 4:29
2

My suggested approach is to be little more smart:

Auto Refresh:

  • If the current page is auto-refresh, then please don't make the user lose their current position. Instead every time when there are new items coming in, show them a small message saying See new items. Clicking on which you directly take the user showing him the newly loaded items (by scrolling at top/bottom)

Example: Quora & Twitter

Bottom line: Auto refresh shouldn't be intrusive. You may load the new items but show it to user on when user wants it to see.

Manual Refresh:

  • If user is trying to perform some action on the items, then you might want to give the UX in such a way that all available options are only focused on those selected items. Which essentially means hiding the refresh button. Which also means that even if the page is auto refreshed, you should neither show the newly loaded items nor the notification saying new items loaded.

Example: Gmail

Bottom line: Manual refresh should only be an option when user is simply browsing through all your items. But if he wishes to refresh the page while doing some critical activity, then it is sensible to show him a warning saying that 'Current action might be aborted'

1

Besides agreeing with Jigar, it also depends on the reason why objects are appearing/disappearing in the list: will they still be available after selection if, in the meanwhile, they could have been removed (this happens, for example, in a shopping cart if someone bought an article you selected a couple of minutes before completing your purchase, or in a document management system if more users are working on the same list of objects)? If this is not the case, then I'd go for sure on the gmail solution: disable refreshing, both automatic and manual, while selecting objects and taking actions.

Otherwise, telling the user one object he selected is no more available could be by far more frustrating than seeing it disappear after refreshing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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