Enable direct jumping to specific dates in the timeslider

[jeffreyameyer]

What's your idea for a cool feature that would help you use OHM better.

I'd like to be able to jump directly to a date by editing the current date of the map.

I'd like to do this by clicking on that nice, huge, big ol' date in the middle of the editor that's just crying out to be clicked on and entering the target date of the map.

Current workarounds

Right now, the workflow for getting to a specific date seems a little cumbersome & not intuitive.

If the current time window includes the date you'd like to jump to, you need to move the slider along, but it may not be able to land directly on the date you'd like, so you have to go fiddle with parameters or change the window start date or end date, thus preventing you from going before or after the limit date you've just entered.

If the current time window does not include the date you'd like to jump to, you could enter that specific date as the window start or end date, but that has problems, as identified above.

[danrademacher]

An invisible "click me" functionality on the date itself to enable editing will not comply with accessibility standards.

In previous design, we had this treatment:

1. Distinct link to open date for editing

2. Lightbox where I can change the date

In the process of developing the final design, we dropped that functionality, and this is how it's been since we finalized design in March and then built the v2 timeslider in April/May. This is a launch blocker now?

[danrademacher]

One thing we learned on our side in doing better at complying with accessibility standards is that we don't have labels that are also input fields. You can see that in the evolution from v1 TS where every label is also an input field, to V2 where inputs are clearly noted as such.

How can we de-escalate this from "blocker" to "very important near-term enhancement"?

[jeffreyameyer]

I realize that making this a blocker is a bit harsh, but it's the A-number-1 use case: I want to show a specific time on the map

Not sure we can ship if we aren't doing "the most important thing".

Not sure how I missed this before. : (

[jeffreyameyer]

That said... if we can start moving on a fix and there's no quick solution, maybe it's fine for a little while.

[danrademacher]

Getting back to this after a long hiatus. We have a proposed design update with new Edit button off to the right:

And then a modal that opens like this:

Some challenges in implementing this:

1. The modal needs to be invoked by the timeslider but not contained inside the timeslider. Instead it needs to be a true modal that takes over the screen
2. We need to make sure this works on mobile as well as desktop, so we'll want to work out positioning etc

I wonder if this really should be a separate "Date Selection" module that talks to the timeslider, rather than part of the timeslider code itself. Maybe that would open up better options for blocking the screen and positioning the modal?

[gregallensworth]

• [x] button to open this date picker
  • [x] a pencil icon, floating right
  • [x] find a pencil icon and make it be inside this rectangle
  • [x] translations, es = Aplicar
  • [x] when timeslider is in collapse mode, also hide this button
• [x] modal
  • [x] create a modal thing from first principles
  • [x] title
  • [x] and Spanish translation
  • [x] close button
  • [x] closes the modal
  • [x] Spanish translation for ARIA label
  • [x] description text
  • [x] and Spanish translation
  • [x] number input
  • [x] placeholder of either mm/dd/yyyy or dd/mm/yyyy depending on locale/language setting; see formatDateShortPlaceHolder() and this._translations.dateformat
  • [x] "Set' (Aplicar) button; Cancel is redundant since it will have X, a simple "Set" in line with text input will follow existing UX
• [x] on open, set to the current date
  • [x] reformat as mm/dd/yyyy
  • [x] or dd/mm/yyyy depending on locale; see formatDateShortPlaceHolder() and this._translations.dateformat
  • [x] enter into the box
• [x] Set button cleans & applies the date
  • [x] check format as being mm/dd/yyyy or reasonably close as three numbers; format as proper ISO
  • [x] pad lengths so e.g. "9/5/2001" will be padded into 2001-09-05
  • [x] check negative numbers
  • [x] accept dates already in ISO, e.g. do not transform 2001-09-05 if given that way
  • [x] check whether date is out of slider range; if so, expand range to include this date
  • [x] apply the finished ISO date

[danrademacher]

There is a button shown in the design -- pencil icon over blue square on the right side of the date area

[gregallensworth]

There is a button shown in the design -- pencil icon over blue square on the right side of the date area

Sounds good. I didn't see it in the first mockup, and it is absent from the second mockup. The redlines really help with this part of the process.

[gregallensworth]

Here we go.

• pencil icon, opens modal
• current date is loaded, in either mm/dd/yyyy or dd/mm/yyyy format, depending on your language/locale; this will match the mm/dd/yyyy on the left & right of the slider
• parsed date can be any of
  • already ISO YYYY-MM-DD format
  • dd/mm/yyyy or dd/mm/yyyy whichever your language/locale uses
• X to close (click or spoace/enter, it's a button), or hit Esc while the text box or Set button are highlighted
• hit enter while date box focused = date updates on screen, but modal does not dismiss (this is a bug, as the intent was to apply & close, but it doesn't do that and in fact I like this behavior for quicker date-swapping without reopening the modal)
• uses all of the usual validations & API methods, so invalid dates will be handled as usual, and the slider will adjust to include the new date if it doesn't already

As to testing:

There is a new branch gin-datepicker-202212 at https://github.com/OpenHistoricalMap/leaflet-ohm-timeslider-v2/ Refer to pull request https://github.com/OpenHistoricalMap/leaflet-ohm-timeslider-v2/pull/3

clone https://github.com/OpenHistoricalMap/leaflet-ohm-timeslider-v2 and check out the appropriate branch See its README file for setup and starting a Python web server on http://localhost:9646/ On ohm-website, edit the header to use your localhost copy of the timeslider: Open app/views/layouts/_head.html.erb Comment-out the two tags for leaflet-ohm-timeslider.js and leaflet-ohm-timeslider.css Then copy-and-edit them, so it will load the timeslider from your localhost: script src="http://localhost:9646/leaflet-ohm-timeslider.js" link href="http://localhost:9646/leaflet-ohm-timeslider.css"

[danrademacher]

Good first pass!

A couple notes:

• I'd like to more closely match the design. Sorry I didn't take the time to redline this on the first round! Better late than never perhaps:

• In local testing, the modal placement and operation works great, on both large and small screens. But I think we need to handle bad data a bit more gracefully. I tried just entering "400" and naturally that didn't work, but the design didn't account for handling errors like that. It just won't submit.

Options to address that:

1. Expand the instruction text to specify acceptable formats. But then I guess we need to modify the instructions based on locale? Like this: "Dates must be formatted as either YYYY-MM-DD or [mm/dd/yyyy | dd/mm/yyyy]"
2. Do that AND report error back when a date is malformed to say, under the input field after submit "Unsupported date format. Please use YYYY-MM-DD or [mm/dd/yyyy | dd/mm/yyyy]"

[gregallensworth]

I have reworked to fit the style described, rather than my prior attempts to match to OSM/OHM panels, Xs, etc.

I have also added to datepickerSubmit() a check that the resulting yyyymmdd is valid-shaped. If not, it gives an alert. The text for this alert is the very same text as the sentence below the input box, though that could be changed.

[1ec5]

Does this design still support ISO 8601 or the user’s language’s date format, as in https://github.com/OpenHistoricalMap/issues/issues/408#issuecomment-1367466720? If so, the text below the textbox could mention the two options.

It’s a bit disorienting to see two different kinds of modal dialog boxes, one implemented as part of the webpage and the other implemented as a JavaScript alert. In general, stacking modals can be confusing. As an alternative, can we check validity on every change to the textbox, and if it’s invalid, disable the Update Date button?

[gregallensworth]

Yes, 8601 is still supported. If the given date is yyyy-mm-dd format, it is used as-is and is not "parsed on slashes."

• [x] I will expand the "Enter the date..." text to add 8601 as well.
• [x] I can add the onkeydown handler, which would constantly re-evaluate whether the Update Date button should be active
• [x] hitting Enter in the box, disabled button status should Do Nothing instead of even trying to parse the date; this may already work if the Enter just passes a click() to the button; check and test anyway
• [x] drop the alert

[1ec5]

we still need to bring attention to the invalid date so "nothing happened" is not confusing

A cheap affordance for client-side validation is to set the text field’s pattern property. But if all the target browsers support it, a more sophisticated option would be the date input type, which most browsers these days turn into a calendar picker control.

[danrademacher]

@1ec5 we have resisted standard calendar pickers for OHM because they always seem optimize for picking dates relatively close to "today" and it they force you to scroll through years, that can be difficult for picking 23 AD or something.

[gregallensworth]

Keystrokes now toggle the submit button, so there is active visual feedback as you type. This also corrected an issue where pressing Enter would still submit the date, even if the button were disabled - this is now fixed, and disabled button means disabled enter too.

As such, there is no way that one could hit the button or enter, and become confused when nothing happens. One would need to intentionally open the debugger and remove the disabled flag, a use case we don't need to worry about. ;)

Also, I have improved isValidDate() to detect actually-valid dates, so "12/34/2000" or "2/31/2000" are invalid and cannot be submitted.

[1ec5]

we have resisted standard calendar pickers for OHM because they always seem optimize for picking dates relatively close to "today" and it they force you to scroll through years, that can be difficult for picking 23 AD or something.

OK, that makes sense. I guess I’m used to Firefox’s implementation, which still provides a segmented text field for manual entry, but there’s no guarantee about that in other browsers.

[danrademacher]

Looking good!

Seems like we have a new bug for keyboard operation of the modal. Prior to today's changes, the pencil icon in the timeslider accepted keyboard focus and pressing return opened the modal, as expected.

Now, as shown in this screencap https://recordit.co/G1F6jhgPRK, hitting return on the pencil icon opens and I think instantly submits the modal before one can interact with it.

Ideally, hitting return there would open the modal and put focus on the date entry field in the modal

[gregallensworth]

a new bug for keyboard operation of the modal hitting return on the pencil icon opens and I think instantly submits the modal before one can interact with it

Bizarre! The underlying issue was that opening the modal then focuses the text box, but the enter-press somehow happens on that newly-focused text box, which of course submits the new date. The workaround is to set the focus in a timeout of a few milliseconds, thus the original enter event completes and the newly-focused element will not receive the event intended for the other button.

[danrademacher]

Tested and confirmed fixed. I also just merged this PR so the new feature is live! If only all our deploys were so easy