2

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?

Improve this question
  • Can you please provide the basic information architecture of your form as it would better help us understand the context of a correction vs update? – ikartik90 Jan 17 '17 at 5:16
  • 1
    @ikartik90 I'm not sure what you're asking for. "Information Architecture" is kinda a vague term. Would you like a workflow? A good context example is, say, an address. Imagine they accidentally entered "203 Sky Ln" but made a correction to "302 Sky Ln": that's a correction. An update is if they moved, and they change the address to their new address. – invot Jan 17 '17 at 15:55
  • I believe the answer lies in your own comment in that case. If you look at the nature of change for a correction, it would include minor difference with respect to the original information in the field. Whereas, in case of a change, for example in case of address, the content change would be significant. So you could simply define a meta score for the change undergone and set a flag based on it. And, if further need be, based on tests, ask the user to confirm your extrapolation before submission. – ikartik90 Jan 28 '17 at 8:43
2

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.
Improve this answer
  • 1
    I like the idea of the user going "someplace else" to input corrections as opposed to updates. It's clever and saves time. – invot Jan 17 '17 at 20:18
1

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,

Improve this answer
  • Like I mention in my description, adding a field to explain the reason for edit would be way too painful for the user. The form has over 100 fields and would likely take more than a half hour to fill out. I need to find a different solution. – invot Jan 17 '17 at 15:32
  • Default to the most used and allow users to update. Sometimes there's no magic bullet if you want to gather the information, or don't gather it. – DarrylGodden Jan 17 '17 at 16:47
0

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.