This paper (written in the 90’s) suggests a really cool idea (that I have recently been exploring): interfaces are the same as a distributed system, and between multiple users it’s actually a concurrency control problem. The authors suggests how some ideas could be borrowed (locking and serialization) and how the vanilla idea wouldn’t just work directly. It also explores the semantics of the interface to reason about how relaxed the system could be.
- I really enjoyed the section “Serialization can lead to strange interaction behaviors” (we don’t want to copy-paste ideas). The example used in Figure 4 showed this very well, where the user perceives the UI flashing between two different user states — while this is perfectly “atomic” on the execution layer, it’s very confusing for the users. I’m probably wrong but I think it’s because there is a lot of “inertia” in users so any intermediate states must change smoothly.
- Degrees of optimism
- Human, All Too Human (continuing the Nietzsche theme of this blog…): the authors emphasize that unlike distribute systems’ consistency semantics, we need to consider the human factor, which is a lot more nuanced. A few examples:
- When the pixels are inconsistent (Figure 3), no real user actually complained about it since it’s so tiny and unnoticeable.
- Users self regulate to avoid conflicts: if you see your friend editing a line you will probably avoid it, but issues still arise if you see their cursor too late.
- “We conclude that there is no superior method, but that each has its merits and problems” — this echoes with our experience as well. Ultimately the winner is to make the application developer (or even user) express this is a simple manner.
- Practical finding
- “We now realize that different objects and operations in a single application may require different concurrency control methods.”
“A lock layer allows a developer to attach either non-optimistic or semi-optimistic locks to objects, as well as a callback procedure that is executed whenever the lock state is changed. The system then tracks all requests to the lock, changes the state of the lock as appropriate, and triggers the callback so that the application can handle it. It is up to the developer to take the appropriate action i.e., to show feedback of state, and to undo operations if necessary.”
- It’s amazing again that this was written in 1994, way before collaborative editing tools like Google Docs and Quip existed (hell the internet was still young back then).
- Again, relating to my current research agenda, reasoning about consistency actually applies to single user use cases too! This happens when the back-end requests comes back out of order!
- They could have explored the definition of a “transaction” a lot more! As we currently think, this is the key to being able to use this idea properly.
- The paper really motivates research from Human Computer Interaction to communicate how feedback to this “pending” state should be handled. As far as I know this is still not researched, and should be! Given all the shitty UX I have with “frozen” web pages.
- This is a really well written paper that motivates the problem well, proposes both high level insights and technical details which they learnt through trials and errors with building a real system. Very readable and leaves the reader with food for thought 20 years later.
- The biggest weakness in my opinion is the lack of discussion of what a “transaction” is. I think this captures a lot of semantics and might help improve the mapping of concurrency in systems to UIs.
- I will be writing up a summary on TARDiS (SIGMOD 2016), and it would be fun to compare the two papers.