Forms with change history

WARNING: This plugin is "new technology": it adds something to webforms which changes the way we think about forms. Traditionally, there is only one kind of user data: data which matches the current form. This plugin alters this: the user data is in transition towards the expectations of the latest form. People will need to get used to this extra visual help.

What has changed?
Fill-in your email address to receive our monthly mailing with stories about rare animals.
Specify the endangered spieces you want to support.
What has changed?
Fill-in your email address to receive our monthly mailing with stories about rare animals.
Specify the endangered spieces you want to support.

Only when the user did not visit this form after the "email address"-field got added, then this special mark gets shown. Otherwise, it will stay hidden. Have a look at the Bootstrap page for more examples.

Rationale

Immediately after a form gets implemented, it enters the "maintenance" phase: every once-in-a-while, the form needs to get updated. Adding fields, removing fields, changing fields. In common practice, the users of the form is not informed about those changes. However, that may not be the optimal experience, both from the form owner and from the form user's perspective.

A few examples where it would really help to display the changes since the last visit of the user:

Over time, small changes to the form are made. How do you communicate them clearly to a user? This based on the knowledge: when did the user visit the form last?

Recording changes

The key idea behind this plugin, is that the form developer records the changes which were made to the form. Based on the knowledge of the last visit of the user to that form page, this plugin translates those change records into minimal visual hints to that user. With these hints, the user can better adapt the submitted information than without help.

The form change record is added to the HTML in divs. What has changed and when is encoded in class attributes and data attributes. When the form is loaded, it is informed about the version of the form when the user clicked "Save" last. All the form changes since that moment will get visualized.

Form and data version

To be able to see the changes, you need to track the version of the form which the user filled-in. This is not the version of the form on the moment the user submits, but the version the user saw in the browser. Typically, your form starts like this:

<form action="/submit.cgi" id="my-form">
  <input type="hidden" id="form-version" name="version" value="20260616" />
  <input type="hidden" id="data-version" value="20240101" />
  ...
</form>

The version MUST be strictly alphabetically ordered. A date with or without time will do. Versions like '2.8.12' will not work.

When the server accepts the form data, it shall implement something like:

sub accept_form($form) {
   my %data;  # ... validate and collect fields
   $data{version} = $form->{version};
   $database->save($user, \%data);
}

Translate this to your own server language and web-framework. (I will include your solutions as examples, if you contribute them.)

Future developments

License and Contact

The code is licensed MIT, the docs CC BY 3.0.
You can find the repository on GitHub.
Please contact the author Mark Overmeer when anything is unclear, with new ideas, or code contributions.
Financial contributions to support development and maintenance are welcomed.