3

I have a grid that auto updates every 30 seconds. Each row has a checkbox in the first column where the user can select multiple rows and apply an action to it. They can also apply an action to an individual row. While the user is interacting with items or hovered over the grid, I'm planning on stopping the auto-update so they don't end up selecting a row they didn't intend to if it happens to update the second before they click. Any suggestions on best UX or sites that do something similar to this?

  • Does the system have locking semantics. i.e. If one user is changing a row, then another is prevented from making updates? – Jason A. Feb 5 '14 at 22:19
  • No locking semantics but statuses and once an item gets to certain statuses they can't go back. So if a user tried to update a row to an illegal state they would get an error, but this is very unlikely. – aheuermann Feb 6 '14 at 5:33
2

I've struggled with a similar problem and fought against the auto update feature simply due to development cost and potential confusion for the users. When the user is hovering are there updates being queued up? When they un-hover will all of the updates happen at once?

What I see most in live update situations is an indicator showing the number of updates that are queued up for a user, perhaps row by row, and allowing them to choose when to show them by clicking an update button. Twitters "20 New tweets" is the only example I could think of off the top of my head. Facebook does it as well I believe.

enter image description here

0

You have a choice in strength of UX vs. cost of implementation

As @Benny Skogberg said a near seamless solution would be an in-grid update. Take a look at Google sheets as an example - it hints what fields other users will change. You could animate changes coming into the grid. Providing rows are independent you would only need to freeze data per row. You could also flag rows that have become out of date.

A lower cost solution is to show user when the next refresh will happen. e.g. countdown or progress bar. This will also be used to show when data updates are paused - which is critical. The user will quickly learn to avoid blocking data updates and selecting exactly on an update.

About cheapest implementation is if the full grid reload is a reasonably disruptive visual event. Assuming that rows are reasonably distinct for the user, then it will be sufficient that when a row is selected the data does not update after that. In the unlikely event of miss-selection, a user will be able to see when they have not selected the expected initial row, they can simply change selection. Similarly for a single row interaction should clearly show the state of data that actually started working with.

0

I like stopping the auto-update on hover/interaction. You could add an "AUTO-UPDATES PAUSED" notification, perhaps with a count of the number of new rows that will be added once updating resumes.

Where you put that depends on the specifics of your site.

I like this idea because it gives clear feedback that the updates have paused and people will quickly figure out why (though perhaps the messaging could be specific about the hover to drive the point home). It would be a bummer to sit there waiting for things to update and not know that your mouse position is preventing it.

Thinking on this more, you could have a place where you say explicitly "AUTO UPDATING" (maybe with a lil' spinner). Then change to "AUTO UPDATING PAUSED". That way you're clearly communicating the two states at hand.

0

It seems, you are trying to apply non-real-time interaction style (selecting and then applying) to a near-to-real-time events system. The issue is at the the bad compatibility between the both styles.

Still, I interpret checkboxes as Apply buttons, as semantically they are equivalent. At the moment of checking, a user is agreed with the current row's value:
enter image description here

So probably changing checkboxes with Apply buttons could solve the problem. This solution doesn't require auto-update stopping. The overall interaction will remain the same, though undo (uncheck) action is impossible (but could be implemented with a bit tricky logic).

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.