1

I have a list view of students for a selected class 7a.

When I open the "Manage classes"-dialog and Delete class 7a should I do an instant refresh in the background or would it be better to do the action inside the dialog, close the dialog and then reload the whole state/page?

While this works well with deleting a class, closing dialog and refereshing the state, this does not work for the 2nd case:

A student(s) is selected and the "Manage subjects"-dialog is opened. A subject checkbox is set and the attach button is pressed. The dialog is closed and the state/page is reloaded!

The ui state of the selected students is gone.

I guess I am atm too much into detail so I ask my question again:

What is the benefit of giving the user direct ui feedback by refreshing the data beneath the modal dialog?

enter image description here

|improve this question
0

There usually isn't a need to refresh the data beneath a modal window while it is open. If real-time updates are needed (e.g. moving sliders to see a varying result), a different paradigm may be more useful.

However, changes should be reflected in the source list as soon as the modal window is closed.

A student(s) is selected and the "Manage subjects"-dialog is opened. A subject checkbox is set and the attach button is pressed. The dialog is closed and the state/page is reloaded!

The ui state of the selected students is gone.

That's the problem. The UI should update, but existing state (such as search/sort/selection) should be preserved.

Without delving into implementation details, I'd suggest merging the changes into the list instead of reloading the whole thing. If you must perform a full reload, then you need to consider restoring the state of the UI.

What is the benefit of giving the user direct ui feedback by refreshing the data beneath the modal dialog?

The user shouldn't have to wonder if the change happened (or worse, interact with stale data).

A quick scenario to illustrate these points. Let's say I need to update several students in a class.

  1. I start by applying a filter.
  2. I open each record and ensure that change ABC is made.
  3. I close the modal dialog.
  4. The associated item in the list updates, perhaps briefly changing color to indicate that it has changed (small, instant changes are easy to miss).
  5. I can now easily see which item I need to edit next, rather than relying on memory to keep my place.

In this scenario, seeing the update is useful and losing state would be counterproductive. I should not have to reapply my filter(s) after every update and (possibly) scroll back to my previous location within the list.

|improve this answer
  • I agree with your opinion. Ok then I have to keep a list for the schoolclasses and subjects on each dialog and when the dialog is closed I fire that data back and merge it with the list etc.. just tried and it works. – Pascal Jan 26 '16 at 20:10
  • On the other side: " a different paradigm may be more useful..." What do you think of? Putting the schoolclasses/subjects dialog on the list view page without dialog? I had that before and the SE people told me thats too much UI at once ;-) – Pascal Jan 26 '16 at 20:35
  • I think the dialog is a good paradigm for your situation. It lets the user focus on one task at a time which is my preference for this type of application unless a large number of changes are needed. If your users need to do a large number of changes at once, perhaps a "bulk management" screen could be useful. – Tim Medora Jan 26 '16 at 20:39
  • Yes a large number of changes is of course done one time at the beginning of the school year/semester. After there are just minor changes. – Pascal Jan 26 '16 at 21:47
  • btw. what is a "bulk management" screen in your opinion? A screen with everything on it? – Pascal Jan 27 '16 at 19:25

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.