Open ronaldtse opened 5 years ago
Here it shows "invalid date". However, if the date is invalid, don't let the user create the record.
The optimization described in this issue is designed to address legacy issue data entry, but is targeting a screen that is intended first and foremost for ITU OB authors. During normal workflow, ITU OB authors are not going to enter data by copy-pasting from a Word deliverable, since that deliverable would not exist at the point of data entry.
This is an excellent opportunity to test the actual, normal ITU OB authoring workflow. If volunteers use the app the way ITU OB authors would, then we can squash any bugs in that workflow, and ITU OB authors later on will be more satisfied from the beginning.
Polished app UI may be important, since actual ITU OB authors are used to Word and adopting another app is already a barrier to them; making them adopt a buggy app may turn out impossible.
Yes, this means slower migration process. It’s great that we have volunteers!
If we really want to optimize data migration and copy-paste things, I strongly recommend to implement an automated parser that directly generates itu-ob-data YAML, and have human volunteers review the results of that automated process. We have the beginnings of that in another issue
Alternatively, we may do one-time data entry optimizations on a dedicated screen if we have the resources later.
This also ties the way the data is entered to the way the data looks. I want to actively keep those distinct, so that it’s obvious that it’s a date and not a string, and to avoid an extra obstacle to improving presentation & editing UIs.
The recommendation version pretty much always equals the month and year of current OB edition, so recommendation versions will likely be prefilled and may never even be manually edited.
For the times where it has to be edited, the most intuitive way to alter year/month combination—assuming recommendation versions are always like that—may be a dropdown/calendar or a stepper button.
@strogonoff for new issues, the editors will STILL copy and paste because the information is given by other departments via email. They will copy and paste information into the new OB issue.
For recommendation versions, as I wrote above, the values are unlikely to be edited at all in 99% of cases, so a win from allowing copy paste would be negligible regardless.
In other instances, the feedback about convenient entry formats would have to come from ITU OB, not the volunteer team, as they deal with different data sources.
On 15 Sep 2019, at 7:51 AM, Ronald Tse notifications@github.com wrote:
@strogonoff for new issues, the editors will STILL copy and paste because the information is given by other departments via email. They will copy and paste information into the new OB issue.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
In ITU OB issues, the dates for approved recommendations are in "MM/YYYY" format. We should support this type of entry so the user can just copy and paste.