User-friendly locks for Goleko.com| A Technical Article

Editing task bodies in most project management tools is done without locks making task overriding a common thing when collaborating. I don’t want this for Goleko when many people work on a project. Let’s go through the technical aspects of what we’ve done to get the right balance between usability and reliability.

I want to create a user-friendly tool that:

• Optimistically works
• Does not override task bodies even when users go offline
• Works as expected when people go offline without overriding people's content.

The Normal Case

We optimistically lock to prevent anyone from overriding the task body while we edit. The task body is the vital area that we want to protect. The tags and titles aren’t a crucial focus as they can be easily corrected. This also prevents anyone who loses their internet connection from permanently locking the task. This is the normal case.

How this Works.

You acquire a lock for 30 seconds and receive a lock ID. The lock prevents the overriding of the task body. It is put in a temporary state within the working tab, preventing it from interfering with other open tabs.

The lock API also returns the newest text, which we use as the edit text instead of what we cached. The browser and server might have versions of the texts. Every 20 seconds, the lock is renewed using the lock ID. This lock works for 30 seconds. Once this 30-second period has elapsed, the lock ceases functioning to prevent the locking of tasks caused by lost connectivity.

When the user saves their work, we use the lock ID to save the text and release the lock simultaneously. We also release the lock if the user decides to cancel their work.

Lock Renewal Fail Flow

A lock can fail due to network problems. There are measures to mitigate this scenario.

How this Works.

We display a warning to the user. The warning reads “Lost Connection, cannot save, please be advised.”

We try to renew the lock every 5 seconds.

If the connection is re-established, three things can happen.

Case 1. No other people acquired a lock

We proceed as detailed in the normal case if no one else acquired the lock and from the third step.

Case 2. Another person has already saved.

We show a split screen with the title Conflict. This split screen has two columns. One column reads “Servers Version” and the other “Your Version.”

It will be displayed on the screen for you to choose the one you want to use.

Case 3. Another Person Acquired a Lock

We cannot resolve this conflict because the other person has a lock.

In this scenario, we display that it can’t be updated due to another lock in place. You have to save locally.

Conclusion

I tried to find a middle ground between usability and safety. In most cases, our system will allow for smooth locking/unlocking, and in the rare cases of lost internet connection + another edition we show straightforward options.

Would you like to share with me how you balanced usability and reliability? Do write to me at martin@martinbaun.com