Need for data version support in forms

[markov2]

Prerequisites

• I have searched for duplicate or closed feature requests
• I have read the contributing guidelines

Proposal

Forms are not static things: they do develop over time. When you get a new version of Android installed on your phone, it will show orange dots where new features were added. I do need a feature like that for forms: show where the user has different options since the last time that the user came to that form.

In the usual set-up, the form gets filled with data from a database. When the form sees a change, for instance an extra option to a select, the database rules gets modified. But how does the user know that there is a new option? How does the user see that a new field appeared since the last time that form was visited.

Examples:

• the gender field first only had male, and female, hence some people were forced to pick one of these options, but where unhappy. Later, the database was made to support other. The form gets option other. For some reason, the user comes back to its profile but does not see the new and preferred option.
• the ISP first supported login-names by self-chosen nickname, but wants people to force people into using an email-address as login.
• the form informs the user that the home address information is removed due to privacy concerns.

So: there is a large diversity in messages about the development of the form over time. Current solutions are really sloppy: some forms print a message somewhere for some time, for every one to see. Most changes happen without notice, even when they are worth to notice.

See 'motivation' why I developed an abstraction for this in my application. It works conveniently, however it could be designed in a more generic way. It has similarities with alert. The version needs to be any sortable, for instance a date YYYYMMDD. Most of the implementation is simply "remove elements when no match"

I think visit is a nice name for this feature: very distinctive. You must think "last visit of the user of the form".

First, my idea for the introduction message of the form:

<form version="20260212" visit-version="{formdata.version}">
   <div class="visit-explain visit-info" visit-before="20260101">
      Since Jan 1st, we are not allowed to register your address anymore.  We have removed
      it from our administration.
  </div>
  <div class="visit-explain visit-success" visit-after="20250101" visit-before="20260212">
     Welcome back. loyal customer.  You get an award.
  </div>

In my implementation, I put these wrapped in fieldsets... which is a quite heavy.

Now, an complex example showing some of the power.

<div>
   <label for="need" class="form-label">Valentine present</label>
   <select name="need" id="need" class="form-select" aria-describedby="need_explain">
   <option value="opt" visit-before="20200112" disabled>Optional
   <option value="yes">Yes
   <option value="req">Required
   </select>
   <div id="need_explain" class="form-text">
      Do you need to buy a valentine present for your girl?
      <div class="visit visit-danger" visit-before="20200112">
          Presents are not optional anymore.
      </div>
   </div>
</div>

The basic implementation is simple: after form load, delete all dom elements with "visit-before" smaller than form."visit-version", and remove all with "visit-after" before form."visit-version".

It would be nice to provide a generic way how to visualize the changes. The simplest is to inline them. But it might be useful to support a tooltip display over a question-mark icon, or a display within the form-leading "visit-explain".

Main disadvantage: you throw away stuff which was first generated. For larger structures a waste of time.

When this feature is accepted, then I can show more design for visualizations. Like orange dots.

Motivation and context

Of course you can implement above in the code which runs your template. However, this proposal makes the templates much, much cleaner. Form data versioning evolves from an ad-hoc trick into a first class citizen.

Most forms speak with servers where the data is in a simple database. When the database changes, then the form changes in sync. I have two applications: one where the user data is signed. The server cannot modify the data to keep it in sync with the form's needs without breaking the signature. (Public distributed data store, like Solid)

The other application uses a huge object store which makes instantaneous global form-data changes too expensive. So, in both cases I have to be able to handle many versions of possible source data: upgrade it to become compatible with the newest expectations on "some moment" in the future, often with need for user assistance.