Use Datepair.js and jquery-timepicker for selecting time ranges

[r-a-y]

Hi Stephen,

This PR replaces the existing time range selection solution, which uses jQuery UI Timepicker, with Datepair.js and jquery-timepicker.

Datepair.js automatically updates the end time when the start time is changed. This makes for a more user-friendly experience.

Here's a GIF showing what it looks like:

Both Datepair.js and jQuery-timepicker are licensed under the MIT:
https://github.com/jonthornton/Datepair.js
https://github.com/jonthornton/jquery-timepicker

The only question I have is lines 274-277 currently in event.js:
https://github.com/stephenharris/Event-Organiser/blob/develop/js/event.js#L274-L277

This part might need to be altered to work with the new JS.

Let me know if you have any questions!

[stephenharris]

Hi @r-a-y

Thanks for the PR. That looks like its a11y friendly, is definitely i18n-friendly and I agree - is generally a better UI.

I'll need to check this out and see how the time range logic handles long events (start and end date are on different dates). That is, by the way, what the snippets you refer to were doing: removing any restrictions on time selection when the event start and end date were on different dates.

One concern is that its harder to select a time for events which don't start and end on the hour or half hour. That could be mitigated by having 5, 10, 15 minute steps - but a balance would need to be struck between granularity and having to scroll through a long list of times. (You can of course manually edit times).

The other concern is that the FES extension uses this on the front-end. I'll need to check the implications of this change on FES and what workarounds are possible.

3.0.0 is already in its 5th beta stage, and while I'm anticipating an extended beta period for that release I think its best to mark this for 3.1.0

[r-a-y]

That is, by the way, what the snippets you refer to were doing: removing any restrictions on time selection when the event start and end date were on different dates.

Good call. This doesn't appear to work correctly in the current PR. If I change the end date to another day, the time duration doesn't update for the end time. I'll look into this.

One concern is that its harder to select a time for events which don't start and end on the hour or half hour.

Yeah for sure. That is probably the only hindrance from using this new UI.

Maybe we can let this be an admin option? Default to 30 mins.

The other concern is that the FES extension uses this on the front-end.

I tested this in BP Event Organiser, which also has a front-end posting component and it works there, but the code in BPEO uses the existing metabox functionality from the admin to generate that stuff.

If FES follows a similar guideline with enqueuing and registering scripts, then it should work, but you should know more than me ;)

I think its best to mark this for 3.1.0

I'm fine with whatever you decide!

[stephenharris]

I had a play with Google calendar and it seems that the duration only appears when it is less than 24 hours. So jQuery Time Picker correctly mimics this.

I'm not sure yet whether this is a design choice or there are technical difficulties in doing implementing this, but one reasonably common user error is to set the end date of a recurring event to the date they actually want the event to stop recurring. My hope is that displaying a duration might help disambiguate the label 'End'.

In any case, I'm thinking about including the duration in the event summary that appears below the date configuration.

[r-a-y]

Hi Stephen,

Do you have any other thoughts about this pull request and what else needs to be addressed?

[stephenharris]

Hi Ray,

Just to summarise some of the concerns I had, and where I think we're now at.

1. Duration is limited to pre-defined steps. This exists in the current UI, but is mitigated by the fact that the steps are 5 minute intervals. I'd be tempted to suggest either 15 or 30. As noted, the user can always manually edit the time. So this isn't a blocker. (I don't want to make this a configurable option, though a filter could be put in place).
2. The user shouldn't be able to select an end datetime before the start datetime. We'd need the to be able to prevent the user selecting such a time (keeping in mind that the dates maybe different for the start and end date time).
3. Compatibility with FES. This will require an update to FES. After consideration, I'm ok with this - it's a blocker in that I'd need to update FES before introducing this change. But it doesn't block this PR.

So I think if the PR can meet (1) and (2), then this would be good to merge in.