1

We have a list page where users see a list of data and can select one to edit. The data opens up in an editable form.

Here is the scenario:
User 1: Loads the list of data and selects to edit form 'ABC'
User 2: Loads the list of data and hangs out for a bit
User 1: Updates form 'ABC' to be 'CDE' and submits their update
User 2: Clicks to edit form 'ABC' as it was displayed on the list - but the form is now 'CDE' and opens as such.

The question is should I let the user know that the form they are about to edit was recently changed?
Is this more confusing than it is helpful? Will expecting to load 'ABC' and actually loading 'CDE' confuse the user? What happens if it wasn't a re-name of the form but a deletion of the form? Then what should load?

  • 1
    One thing springs to mind: Have a status next to each form, either: 'Last updated on (date)' or 'Currently being updated' - the latter of which prevents simultaneous editing. – user43251 May 22 '14 at 8:17
1
(ring, ring)
"Hi Liz"
"Oh, hey Emma"
"Listen, I'm at the pub on Kingsland Road, but I can't find you or anyone else"
"Oh... sorry Emma, forgot to tell you, the party has moved to the other side of town"

How things should really work

There's a famous concept in programming called MVC, which stands for Model-View-Controller. The controller is irrelevant now, so I'll omit it, only discussing model and views:

An illustration showing a model and 3 views

There's always one model which represents the data or what needs to be persisted (stored). Then there are views - what the user see. Sometimes a user sees two views of the same data (think of a list of bars next to pins on a map), sometimes many users see each a view of the same model.

We assume that a user can edit the view, and the role of the MVC framework is ensure that once 1 view is updated all other views update as well.

With websites, there are quite a lot of layers between the model (which is stored and served by the server) and the view (which the user sees on their client browser), so it took us quite a few decades that get this update mechanism working on the web.

Early internet technology was based on the pull model - users had to perform an action, which would send a request to the server that holds the data and the server would respond with the data. So to get updates, users had to press or do something.

Nowadays, the need for a push model (the server pushes data the the clients, without them asking for it) is in high demand, and modern web technologies accommodate such need. One example is you may be looking at a question on this site, and suddenly get a notification that someone left a comment to one of your answers to another question - the notification just shows, even if you were just looking.

My point is, that with correct implementation using modern technology, whenever item X has changed, anyone watching it should be notified. One common problem in UX is that people got so used to dated technology that they take bad usability and how things work (or how things don't work) as a norm.

Should you show it to the users.

I honestly can't think of a single argument why not.

The most obvious reason to show it to users is that status of the system should be obvious to users. If something changes, and it doesn't reflect on the screen somehow, than the system status is no longer communicated to the user correctly.

Just consider someone spending 10 minutes to edit a form, only to get a message it was already deleted by the time they finish. It's a bit like the following phone conversation at the top of this post.

To summarise - you should always let the user know that the version they are looking at is no longer up-to-date. How you handle the various scenario (edited or deleted, for example) has to do with the business logic and the system in question.

To give one example, it happens sometimes that whilst you answer a question on this site, the original or the moderators delete it. Immediately you get a notification saying "This post has been delete, no answers will be accepted" and the "Answer" button becomes disabled. As no one has an idea what you'd like to do next, they keep you on the screen, but you can't do much on it other than going elsewhere.

Not all systems work that way. In many systems deleting an entity doesn't actually deletes it - it simply marks it as deleted and doesn't show anywhere; this open doors to alternative handling option.

  • 1
    In addition things you can convey to the user, 1.) Show other people who are editing the form (using images , short names or simply the number of people) 2.) List edits - Clicking on these edits will allow users to compare changes with the last version. 3.) When another user is editing the same data and have saved it, prompt the other users editing it to get an update informing the file has been changed. 4.) And as for deleting I think deletion should not be allowed if other users are working on the file. – nuwa May 22 '14 at 13:51
0

Assuming that both users cannot work in collaboration at the same time on the same form:

Case I: User 1 is editing the form ABC - On the forms list, User 2 gets an indication that form ABC is in edit mode right now. - If User 2 opens form ABC, it will open in read-only mode. He cannot make any changes. - User 2 can only see the updated version when he closes and opens the new version of the form again.

Case II: User 1 has deleted/moved form ABC - User 2 just opens the form ABC, and he gets a notification at the same time that the action cannot be completed as the selected item has already deleted/moved.

  • The first pattern is commonly used, however, it doesn't work well in the web, where users may start editing, then abandon their changes. An example for the first pattern is SharePoint and an example for the second pattern is the StackExchange network (including this site). – Danny Varod Jun 21 '14 at 8:33

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.