search

USEPA / EPA_Non-geo_Metadata_Editor

3 stars 0 forks source link

Date Elements Punchlist #87

Closed torrin47 closed 5 years ago

torrin47 commented 5 years ago

The calendar widget doesn't work in IE. If there are barriers to getting it working in IE, it would be acceptable to fall back to a field that simply accepts manually entered in a consistent format (and validates).

Can we relax the validation to permit YYYY or YYYY-MM as valid entries instead of requiring YYYY-MM-DD?

aergul commented 5 years ago

After checking out several calendar widgets I decided to go with simple input fields with enough cues and validation for the user. Each widget had some kind of functional or visual issue in IE, including supporting the year and year/month only format.

Ready for QA.

jzichichi commented 5 years ago

@aergul - the implementation looks good to me; I will pass along to see what @torrin47 has to say.

torrin47 commented 5 years ago

I love the Occam's Razor approach. Dates aren't that tough to type in, and in this workflow, a calendar widget might often be more work the further the relevant dates get from "today". The cues for optional month and day are clear to me, but might be a little obscure to an end user - I think we'll want to add a sentence to the guidance for each date field spelling this out. I have a vague memory of tidying up this language, but now I can't find it anywhere, even in the "before" version of the tech spec, so I must just be getting old. One minor validation bug, I was able to get "Last Update" to show as valid with any character. I know this validation is complicating by its coupling with "Update Frequency" but if we can get it to require a full YYYY, it'd help. Thanks!

aergul commented 5 years ago

We now enforce that the last update value is a valid date

jzichichi commented 5 years ago

@aergul @torrin47 - last update validation appears correct to me.

torrin47 commented 5 years ago

Solid.