'Add another' vs. 'Mark as changed'
Morgan
As I write the meta-data field requirements I wanted to make sure we are on the same page about the ''Add another' vs. 'Mark as changed' functionality.
Add another
This is very similar to using a multi-entry field, however should be used when a field has dependents. This will allow for multiple entries for one data field and allow you to capture the dependent data separately as well.
A good example would be Arbitrator. If there are multiple arbitrators you could create one field with dependents for Appointed by, Appointing Authority in the meta-fields list. Then, when inputting data you could hit 'add another' for the arbitrator field. This would create a new instance of Arbitrator with dependent fields for appointed by, appointing authority.
Mark as Changed
This would be used when there has been a change to the existing entry. This would allow you to record a change and keep a record of historical data. I think the UI needs refinement but this is the general concept.
If you select the icon (to be updated) for mark a change this would open up the dependent fields for that change (ie: reason for change, end date) and add new empty fields for the updated entry.
It's worth noting that the field data can be edited at any time for things like typos or errors.
Let me know if this all makes sense to you.
The "add another" requirements make sense.
The "mark as changed" requirements make sense as well, but I want to clarify the purpose and scope of this feature. Is this something that was created specifically for changing an arbitrator, or will it have wider applicability beyond that, because the "reason for change, end date" example is very specific to arbitrator changes? Alternatively, is this a feature meant to apply to all fields and will be used as a "track changes" feature for admin users that will allow reviewers to see what changes have been made by the analysts?
Thanks,
Morgan
My thinking was to broaden the scope of this feature to cover more than just arbitrator changes. The wireframe below demonstrates how this would work:
In this case changes would be something more than just editing data.
Edits to current field data would be captured separately as tracked changes and not as separate entries.
If this makes sense to you, I'll write up the requirements.
Mel
Thanks,
Morgan
Do you have some time today to go over some of the changes to the admin wireframes?
Mel
Morgan
I'll set up a gotomeeting so I can share my screen.
Mel