2

Traditionally, a rule of thumb for designing a responsive UI is that the UI should never lock up. However, with some record editing patterns, allowing the user to edit what's on screen is pointless when the record is saving.

Example:

  • User edits record

  • User hits save

  • Concurrent

    • Server modifies record on server side (Network is very slow so save takes 10 seconds)
    • User edits record on screen (after hitting save)

  • Record returns from server

  • Record on screen is overwritten with record from server

In the scenario above, the editing of the record is redundant because no matter what the user does, the record on screen will be overwritten by the record coming back from the server. So, it only makes sense to lock up the UI while the server is processing the save action.

On top of this, we need to disable navigation at the menu level because the user cannot be allowed to navigate away from the screen until they are given a success or error notification. If they have navigated away from the record, the error message will get lost, and they will have lost their changes.

My question is what is best practice for dealing with this? Should we make the entire app disabled? Should we plaster a busy indicator over the top of the entire screen with an animated progress indicator? Any other tips to make this experience less intrusive for the user?

Improve this question

2 Answers 2

Reset to default
1

Just disable the relevant actions

You don't have to disable everything, just the controls that the user might use to make conflicting saves.

If it's really going to take up to 10 seconds, you might also accompany this disabling with a tooltip near affected controls that explains that some actions are unavailable while the server does its thing.

You should of course test it out wit users, but for the most part this temporary disabling of some buttons (because users presumably don't just go through the UI hitting different save buttons in quick succession) will probably go unnoticed.

Improve this answer
1
  • This makes sense. But literally all controls are useless. The user can only edit one record at a time, so nothing they edit on screen is of any use. It will all get overwritten when the record comes back. I don't expect it to take ten seconds. That's worst case scenario to explain how it could be an issue. Commented Mar 7, 2018 at 4:11
1

User's Input Should Never Be Wasted

Considering the fact that the component's data will be overridden after a response from the server, it should definitely not be allowed to override user's input, therefore the component should be locked.

Narrow Down a Locked Region

The whole application should not be disabled for the process of handling a save request. It's right to strive to reduce the amount of locked components, locking as less as possible.

Avoid Lock's Fragmentation

The lock region should be narrow, though responsible. It should not cause a confusion being too fragmented. It's best to lock a single common block of controls, that are about to be overwritten with a record from the server.

If a Lock Can Be Avoided, Then Do It

The process of genuine saving doesn't imply a lock.

If a new data should be written, after an operation, thus it's not only saving but some kind of a calculation. There is no other way to save a user from data loss while processing a request in this case.

Otherwise, if the only operation that is done at the server is saving user's entered data, the process of overwriting user controls is redundant, and it's elimination (if possible due to technical constraints & budget) should be considered first, prior to any locks introduction.

Improve this answer
4
  • This answer is very similar to the one above. You are both saying that the locked area should be limited. But, the whole screen is taken up by the record. There is no ability to edit anything other than the record. So, literally everything on the screen is useless while the record is in transit. Commented Mar 7, 2018 at 4:12
  • I have added a point navigation must also be disabled so that error messages are not lost. Commented Mar 7, 2018 at 4:14
  • @MelbourneDeveloper, that makes the whole screen the most narrowest region to lock due to such technical constrains. Although, to provide a better user experience, I would advice to consider elimination of such constraint if possible and narrow down the region to lock, providing a possibility for a user to operate the application without delays for saving. Commented Mar 7, 2018 at 4:33
  • you are right, but I don't really see any way of eliminating this constraint. It's basically for technical reasons that the whole record needs to be sent to the server, and the server may make changes to the record before returning it to the client. For example, if a user fills in a given date, the server may change the status of the record to "In Progress". The app uses a Save button, and the screen is all single document interface. So, there's not really anything the user can do while the record is saving. I realize this breaks design principles so I'm wondering what to do. Commented Mar 7, 2018 at 4:55

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.