Tracking the intent of an Edit (Correction vs Update)

Question

I am building a form-based application and plan to implement a history mechanism. It will operate similar to how the history feature works in Google Docs. The current and historical records will have reports run on them. Their accuracy is important.

My hope was that simply having a history would be enough for my customer, but they brought up a concern I didn't think about: How can we distinguish between a change made because the user was correcting an error and a change made because the user was updating information.

Now, to me, I don't see the value in this feature. It feels to me like there's no simple way to track a user's intent without cluttering their workflow.

But the customer insists that it's needed. So, I am wondering how to implement this in a graceful way. The form will be updated frequently, so I am wondering if there's a way to do this without prompting the user to explain why they're making a change every time they edit a field. That to me just seems insane and would grind their workflow to a halt.

Has any research been done on this subject? Has anyone else been faced with this problem and discovered a clever solution?

Answer 1

I believe it is very difficult to automatically differentiate between an edit and an update:

Before:

One apple

After:

Two apples

---

The user is the only one who knows if what he did is a correction or an update.

So the best way to keep track of it is that the user makes it explicit:

• User indicates update
• User indicates edit
• User indicates both

Depending on your case you might be interested in one or the other. Some ideas of how could this be indicated:

• User selects edit or update option before he starts typing. This could present different UI depending on edit or update.
• User selects edit or update option after he finished typing. This could be a checkbox, for example. The main problem with this one is the user needs to indicate this before closing the app. So you would need to force a "save edit" "save update" kind of interaction on close.

Answer 2

Both Confluence and Stack Exchange use a 'Reason for Edit' text-box to allow users to explain their reasons for editing a piece of text.

You would need to do some user testing to discover whether it works for you or becomes to onerous.

Perhaps you could implement something similar but provide pre-filled text, like this (I have no access to Sketch at the moment, so can't design it):

Reason for Edit [ Corrected mistake___ ]

In the box could be:

Correcting an Error

Updating Information

-- enter your own --

A bit like a hybrid drop down list seen on a few application. Whether it is mandatory becomes the big question and one that can only be answer by user testing,

Answer 3

The separation between corrections and updates could be useful to clean up the history: Assuming that error corrections are not interesting for the user, the history could hide them.

It would depend on your requirements if there is a feature to fade in the corrections or if they are not included in the history at all.

With this in mind, you could include a checkbox like this in the edit form:

[ ] Minor correction - do not include in history

This way you can reduce the additional effort for the user to a minimum - only one additional option is presented instead of two or more. The user could even ignore the option without bad consequences. Furthermore, if the purpose and the consequence of the option is clearly stated (include in history or not) the user probably will be more likely to be ready to think about the option.

Besides, I would not reverse the meaning of the checkbox: it could be annoying if the option is overlooked and surprisingly some entries are missing in the history.

Wikipedia is using this approach: https://en.wikipedia.org/wiki/Help:Editing