Open jlegind opened 1 year ago
@jlegind made a mockup DaSSCo MASS Digitization app I think it it should be adapted to a more web based design maybe also conform to some UX design principles
The initial mock up attempt is here: https://github.com/NHMDenmark/Digi_app_version2-web_based?tab=readme-ov-file
I need a brief rundown of where the version 2 breaks with version 1. In most versioning schemas there are three placeholders for the numbers, so version 1.0.0 is the first production version. The last position is incremented when a patch is released to address a bug. The middle position indicates a minor version update or change that has 'non-breaking' features included. I would say that introducing the NHMA alternative identifier is a feature catering to a special case and will not be noticeable for most users and would qualify as a minor update. The first position signifies a major update. It is sometimes described as a change that breaks the API. It will break projects built on previous versions and is a downstream killer. Major/minor semantics are to a degree subjective and reflects the culture and history of that specific company/organization.
I imagine major version 2 or 3 of the app has a pipeline where each time a record is saved, that record is submitted to Specify through an API call over the internet. This relieves the digitizer from having to muck about with the embedded data base. It is a major change in the daily business of the digitizer. Depending on the record in process being a novel record or if we are talking about a change to an existing record, the API call would trigger an insert in the case of a new record or an update in case of changes to an existing record.
A minor version upgrade of the app could be something the users don't see or feel at all like rolling all of the post processing into the app code OR preparing the inputted data for future API calls straight into Specify.
Version 2
Since we are working towards this: I wish to see two or three major upgrades described that justify moving to a new major version.
Suggested tasks for version 2
133 for actions like "Send daily work to such-and-such repo." Similar to #159 and #189
270 Installing new version of the App begins with a warning to backup the existing database in case there is un-exported work remaining. This ties into #184 where auto-backup is suggested.
353 Only have one instance running at the time per workstation.
189 Though only creates the export file automatically. Upload to N drive is still manual.
375 Handling empty taxonomic name field.