Patterns for handling concurrent modifications to resources in web app

Question

While making an LMS web app, I was looking for a way to provide a nice UX while communicating the user that a resource they were trying to edit was already being worked on by another user. For example, two teachers could've ended up trying to edit the same lesson simultaneously. The way I decided to handle it was the following: when a user tries to edit a resource that's already being edited by someone else, an overlay covers the editor and shows "[user] is editing this resource". The user who arrived second can see the changes being made live and, as soon as the first user leaves, the overlay disappears.

(the screenshot here reads: "An edit to this exam is being made by Samuele Bonini. The editor will be unlocked as soon as the editing is done")

In order to see what similar applications were doing, in order to do some kind of pre-validation of this technique, I took a look at Google Classroom.

I was pretty surprised by what I found:

• no checks are made of concurrent modifications to resources
• while a teacher is editing a lesson, another teacher (or 20 other teachers) can access the same editor and make changes undisturbed; none of them are aware others are also editing the resources
• if a teacher submits a change to some material and another teacher does the same, the second edit will overwrite the first one
• if a teacher deletes a resource while another one has is editing it, when the second teacher saves their changes, the resource will automatically be un-deleted and will contain those changes.

It appears Google Classroom completely ignores the issue. Are there any arguments UX-wise for this? It sure is simpler to implement, but given the amount of resources Google has, I'm expecting some other argument for those choices.

Answer 1

While Google in general has a lot of resources, the individual teams working on certain products or certain aspects of a product don't always have. Stuff facing end users tends to be quite nice, while stuff facing smaller groups tends to be "good enough" to frustrating.

That said, the case you're describing is quite a rare case already. In general, students and teachers tend to edit resources at different times, and teachers tend to prepare stuff for just their own classes, so there's no reason for another teacher to ever touch it. Generally, there probably is just too few people involved for this to be a massive problem.

You've correctly identified that quietly overwriting a previous change isn't good, and locking probably is better. Better still may be some sort of conflict resolution á la git or Wikipedia, or live-editing in which you can see what the other person is up to. The latter probably is way overkill (again, I doubt congruent or even collaborative editing happens too often), but conflict resolution may be worth looking into.

Answer 2

This is really a Governance issue. You could look at Google Classroom's behaviour as a clear sign that the product does not intend to take on the burden of governance, it is simple and easy to reconcile with while allowing unorganised organisations to make a mess - the same could be said for a bunch of typewriters and reams of paper.

In terms of Security, though, I'd expect Google Classroom to provide detailed audit logs - and lo, it does:

https://support.google.com/a/answer/9725452

https://support.google.com/a/answer/4579579?hl=en

I think it is worthwhile to highlight here that it is very uncommon (almost unheard of) for a UX Team to consider non-functional requirements in this way, why it is essential that systems are architected with the involvement of Engineers.

Teachers hardly create the educational material that they dish out. These days, Educational Designers are tasked to work with staff to develop material and that material is used on repeat for years. That material is considered IP of the educational organisation, not of the teacher, and so it is typically developed with some planning, care, and approval processes before ever being utilised in a classroom.

I also think it is negligent for any educational staff to rely so heavily on a web app to deal with their disorganisation. Educational material should be developed offline, the interface for data entry is for data entry (not for conceiving content). Should an educational organisation have governance in place and implement it well on a day-to-day basis, they might task a single person the responsibility to perform data entry for a given Classroom rather than an open-ended group of uncoordinated staff members. There may even be a permissions/role system allowing the system admin to assign accounts to Classrooms to prevent any overwrites or uncoordinated edits.

Answer 3

Regarding Google Classroom, I agree that these are very big shortcomings on the part of the development team. As Straya said, it looks like the product doesn't want to take on the burden of management.

Now regarding the UX practices when creating a product with simultaneous editing. What do you need to remember?

1. Define participants

Who is working on the file now?

Who is online in general and is "watching"?

Who else has the right to edit/view this document?

Not all of these elements have to be prominently visible all the time, but it is nice to have this info easily accessible and transparent.

---

2. Changes log and selective undos

When collaborating on a document with multiple people, it can be difficult to keep track of all the changes being made simultaneously. To address this, it's helpful to have a "changes log" feature that allows users to review the history of the document and see how it has evolved over time, including the specific decisions made by contributors. Additionally, being able to view "snapshots" of the document in previous states, or even revert the entire document to an earlier version, can be useful in certain scenarios. For example, if new knowledge influences work being done, it may be necessary to undo all changes made in the past day.

---

3. Rights and permissions

When working with a shared document, multiple stakeholders may need to interact with it for various reasons. However, there may be situations where editing permissions need to be restricted for certain users, such as to prevent accidental changes or limit the document to being used for information sharing only. In such cases, it's important to implement access management that not only allows certain users to view and/or edit the document, but also enables them to grant permissions to others. Therefore, careful consideration should be given to the access rights structure that is best suited for the specific tool being designed.