User-friendly concurrency handling in occasionally disconnected systems

Recently i was in a hurry to grab some reading material and i accidently pulled out a book I’ve mentioned previously. David Platt’s “Why Software Sucks” is full of thoughts on how software could be made more user-friendly. One of his points is that users should not have to understand the internal workings of a computer or the particular piece of software, they are trying to use.

Reading this again made me absolutely sure we had come to the right decision in a recent discussion on how to deal with concurrency in an “occasionally disconnected” client / server system.

One of the basic problems of the client / server relationship and database level replication, is that data may change while the client does not have access to it or while an application is holding a copy in memory. As a result it is unavoidable that, the user will sometimes be working with stale data. When a connection is restored and new user data is submitted or when reference data is suddenly no longer in the database, this in turn may result I conflict or violation of integrity.

As a concrete example we based our discussion on a questionnaire with multiple questions, which would themselves have multiple predefined answers. What would happen if an answer that the user had previously selected was removed before the user submitted her questionnaire? Should we double check the questionnaire and alert the user? Initially this was our thought. But going back to David Platt, this is exactly the thing he advises against: making the user understand what is going on internally in the application. Telling the user that a choice she made earlier has resulted in a conflict and her entire questionnaire cannot be accepted, because somebody else decided to make a change to some data stored on some server, is not exactly user-friendly.
The user would be forced to understand all the mechanics that was put in place in the first place to give her the ability to work seamlessly even in the face of “occasional disconnects”. On top of that, when the user originally answered the question, she picked a valid option that WE presented her with. In fact the error isn’t at all on her part – so why should she be made to deal with it?

The answer is simple – she should not!

The guy who implemented the feature should! Or maybe the guy who removed one of the predefined answers, without having demanded an implementation that would deal with this appropriately should.

So what would be an appropriate action? We ended up settling on two things: If the user returns to the previously answered question (resulting in the predefined answers being reloaded from the database), and the currently selected answer is nowhere to be found, we’ll just ask her to select a new one. If on the other hand, she completes the questionnaire without ever looking back, we’ll accept her submission no questions asked and deal with it.

“Dealing with it” may entail a number of things. We could have a mechanism that would automatically map the invalid answer to a valid one. We might flag the submission for later review by whoever is going to process the data. If there was no other way, we could even send a message back to the user, asking her to answer the question again. All though hardly recommendable, there’s a key difference here. The choice to do so is no longer the result of an architectural decision, it’s a business decision. And also we would be able to send some information along presenting the user with our sincerest apologies.

Tags: , , , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: