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.
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.
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?
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.
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.)
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.