Improve Date/Time selector to be more intuitive.

[SebastianKrupinski]

One of the recommendations during the brain storming sessions was the improvement of the time selector. This was one of the top requested items.

Currently,
Clicking the Date/Time selector always brings up the time picker if the event is not all day. The time picking part of the selector is also ticky to understand.

Possible Improvements,

1. Leaving the current selection box as is but showing a different drop down depending on if the user clicks the date or time.

2. Splitting the Date and Time selector in to two parts like the tasks app dose.

3. Also improving the look of the date/time selector to be more understandable. Maybe something like the material design date and time pickers.

[ChristophWurst]

This might actually be a duplicate of #6324

[ChristophWurst]

There is also #4626

Before we spend too much time on redesigning the current picker we should re-evaluate if it can actually be made accessible. The last time we checked it was not. Many apps and components switched to a native time picker. We might want to do the same for Calendar.

[SebastianKrupinski]

The native date/time picker is an option but there are some down side, they can't really be styled and the styling varies between browsers, and the native time pickers are horrible.

You can test them on here...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local

There are some options for javascript based accessible date/time picker.

https://www.digitala11y.com/accessible-date-pickers-roundup/

The Duet Date picker seems to be a good alternative.

Accessibility guide lines.

https://axesslab.com/accessible-datepickers/
https://whatsock.com/

[ChristophWurst]

See nextcloud-libraries/nextcloud-vue#1666 as well. We evaluated some pickers in the past.

[GVodyanov]

My proposal is using PrimeVue's components https://primevue.org/datepicker/#time. There is support for time and date, but not timezone, unfortunately. It's also under the MIT license. My only doubt would be the accessibility as I don't really know how to test for that.

[SebastianKrupinski]

@GVodyanov that is a great find, they're stylish and very functional, even has keyboard support. It also supports accessibility according to the link you posted (bottom of the page).

You can test it with a screen reader program. There is a short list here...

https://usabilitygeek.com/10-free-screen-reader-blind-visually-impaired-users/

[GVodyanov]

@GVodyanov that is a great find, they're stylish and very functional, even has keyboard support. It also supports accessibility according to the link you posted (bottom of the page).

You can test it with a screen reader program. There is a short list here...

https://usabilitygeek.com/10-free-screen-reader-blind-visually-impaired-users/

Just tested it with Pericles screen reader, and it seems to be able to read everything properly. Not sure what being fully accessible means, though: for instance, it didn't tell me about the arrows I could use to change month.

[SebastianKrupinski]

Just tested it with Pericles screen reader, and it seems to be able to read everything properly. Not sure what being fully accessible means, though: for instance, it didn't tell me about the arrows I could use to change month.

From what I have read, I don't think there is a defined standard of what full accessible means, its more just guidelines of best practices. Found a guide that has a summary.

https://blog.hubspot.com/website/web-accessibility-guidelines?hubs_content=blog.hubspot.com/website/web-accessibility&hubs_content-cta=complete%20web%20accessibility%20checklist

Most of the points in the guide are best practices in general. The ones that really apply to accessibility I think are,

• 1. Provide alternatives for non-text content. (use text instead of images when possible for visual impaired)
• 2. Provide different options for viewing media content.
• 4. Make content easy to hear and see. (high contrast color schemes for color blindness)
• 5. Make all functions keyboard accessible. (for visual and motor impaired)
• 6. Allow users to adjust timing. (for cognitive and motor impaired)
• 9. Accommodate various input options. (for visual and motor impaired)

[GVodyanov]

Thanks a lot for your research @SebastianKrupinski!

@nimishavijay What is your reckoning about the PrimeVue component? Do you approve and if so, how much would you like to redesign it?

[nimishavijay]

Nice! The PrimeVue component visually looks super slick. My main concern is the lack of an option to view a bunch of times at once (to change by even 5 mins you have to click 5 times. To change by half an hour you have to click a LOT). Here's a short competitor review of what the time pickers in the most popular calendar apps + UI kits look like:

GCal, Outlook, Proton calendar, iOS, Calendly, MUI, and Ant Design

Google Calendar

Outlook calendar

Proton Calendar

iOS: Couldn't get a screenshot in this computer but it's basically only possible to type your time in, there is no visual selector

Calendly

MUI

Ant Design

So it seems like the industry standard for picking times in a calendar is just a simple list of times rising incrementally, with some smart defaults (if you select a time directly show ± 4 hours of that time, if you select a day, show ± 4 hours of the current time, etc). So for NC that would mean an action menu with some times. That would look a bit like this:

Another option is to stick with the current time picker (it shows up in MUI and Ant Design, so definitely a UI pattern) and make some improvements:

• get rid of the "Pick a date" and the date button on top
• Show the selected time at the bottom left on the same row as the "OK" button
• "OK" --> "Done" or "Save"
• Reduce the width of each column
• Use regular font size
• Use rounded corners and a light bg for the selected times
• Use a shadow

Those changes would look something like this:

Regardless of which approach is taken for the time picker itself, it makes sense to also make some changes in the event popup

• > Splitting the Date and Time selector in to two parts like the tasks app dose: This is great! Also seems like the best idea also for accessibility
• Show the time zone picker separately and show only one time zone picker

Something like this:

IMHO I like the second approach (tweaking what we have rn) better even though most calendar apps have list of times (if anything). Many of the complaints about the unintuitive time picker were about the date on top and the lack of a direct entry point into the time picker, so we can try and mitigate those problems. What are your thoughts? @GVodyanov @SebastianKrupinski @ChristophWurst (and @Hyeyoung346 @marcoambrosini )

[GVodyanov]

@nimishavijay @ChristophWurst @marcoambrosini

So we just had a chat about this at the groupware meeting:

• The first most important thing IMO is that the current component being used for NcDateTimePicker is based on a third party component which isn't compatible with Vue 3, and therefore will eventually have to be replaced, so keeping the current implementation isn't really an option
• Another issue with the old component is the accessibility, however, this isn't super critical seeing as users always have the option to just type in the time and date, and well the rest of the calendar app isn't that accessible anyway.
• We need to have a timezone picker for both the start and end times, as per the RFC. What the best way to implement this without confusing the user too much is a bit of an issue. We thought of adding the little globe to the side of both of the time pickers (so have a third column), but that's up to you design guys.
• Dividing time and date is something everyone is super on board with

[GVodyanov]

@nimishavijay Forgot to mention that yeah, I guess the PrimeVue component not having the list of times is pretty bad, so that excludes it at least for time picking, but if we are going to be separating the two components for time and date anyway, maybe we could use PrimeVue for the date and something else for the time?

[nimishavijay]

Ah thanks for the clarification.

maybe we could use PrimeVue for the date and something else for the time?
Do you approve and if so, how much would you like to redesign it?

The date part of the PrimeVue component looks pretty sweet. Just wanted to confirm that it is possible to show a pre configured date with PrimeVue, right? I didn't see it in any of the examples, all of them were empty date fields, while in a calendar the date field should be prefilled with the date you clicked on to create the event.

As for visual design, there's #6324 anyway so trying to get as close as possible to that should work. Structurally it's pretty much the same, it's sizes and colors that are different. We could do a design review at the end to iron out any kinks.

Another issue with the old component is the accessibility, however, this isn't super critical seeing as users always have the option to just type in the time and date, and well the rest of the calendar app isn't that accessible anyway.

That's fair. I noticed that for Google and Outlook the expected way for people to enter the time regardless is by keyboard. When you click on the date field the entire text gets selected and a menu opens up with a list of times. Does that sound like something we could do? Otherwise there could be an icon on the side, and clicking on that would open the list of times while clicking on the time in the field would let you type the time.

Ref google for interaction.

Recording.2024-10-08.161422.mp4

We need to have a timezone picker for both the start and end times, as per the RFC. What the best way to implement this without confusing the user too much is a bit of an issue. We thought of adding the little globe to the side of both of the time pickers (so have a third column), but that's up to you design guys.

Oh I see, alright. I would vote for more visibility of which time zone is selected up front (for example, for people who travel frequently). so we could show it at the bottom and make it an extra step to edit the time zones.

Nice-to-have: the first time someone edits a time zone, the change is reflected across both the input fields (because it most likely that you want to change the timezone for both the start and end time)

Altogether it would look like:

20241009-0026-28.6655877.mp4

What do you think? :)

[SebastianKrupinski]

@nimishavijay It think that looks good and should be easy to make accessible also.

[GVodyanov]

@nimishavijay That looks amazing! Thanks a lot for your help :)

[marcoambrosini]

Hi @nimishavijay, wouldn't be enough to have only one timezone dropdown?
Maybe it could stay on a new line without making the dialog wider?

[nimishavijay]

@marcoambrosini that was my initial idea as well, but as @GVodyanov said

We need to have a timezone picker for both the start and end times, as per the RFC. What the best way to implement this without confusing the user too much is a bit of an issue.

Any ideas from your side for setting 2 separate time zones for start and end?
Gcal has a whole modal for setting the time zone (bit of an overkill IMO), and Outlook and Protonmail do it similar to the mockups.

[ChristophWurst]

Just tested it with Pericles screen reader, and it seems to be able to read everything properly. Not sure what being fully accessible means, though: for instance, it didn't tell me about the arrows I could use to change month.

From what I have read, I don't think there is a defined standard of what full accessible means, its more just guidelines of best practices. Found a guide that has a summary.

Nextcloud is following the German BITV standard v2.0: https://docs.nextcloud.com/server/latest/user_manual/en/universal_access.html#universal-access. Julia or Grigorii are candidates who could help you test what is considered accessible for this standard.

Another issue with the old component is the accessibility, however, this isn't super critical seeing as users always have the option to just type in the time and date, and well the rest of the calendar app isn't that accessible anyway.

If we are changing the time picker then we should definitely make sure it's accessible. Accessibility is not optional. The Calendar app will very likely have to be fully accessible at some point.

[ChristophWurst]

Please make sure to read nextcloud-libraries/nextcloud-vue#1666 and the earlier findings to avoid double research/work.

[ChristophWurst]

I talked with @jancborchardt about this and we think it's best to go with #4626 for now. The acceptable tradeoff is that Firefox does not have a time picker. Other browsers have one and this is a fully accessible solution.

[jancborchardt]

On the Firefox side, the bug about a time picker is tracked as https://bugzilla.mozilla.org/show_bug.cgi?id=1811581 and/or https://bugzilla.mozilla.org/show_bug.cgi?id=451832

So I would say we indeed just accept the tradeoff that Firefox does not have a visual time picker. The keyboard-only input is accessible at least, and then hopefully they will soon activate the visual timepicker.

And as written in the issue, they actually have a timepicker interface, but it unfortunately is hidden behind the about:config switch dom.forms.datetime.timepicker. If set to true, you see the picker, e.g. on https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time

[ostasevych]

I suggest to let edit the date or pick another date just by clicking the date itself, but not a special button to pick the date.

[GVodyanov]

I suggest to let edit the date or pick another date just by clicking the date itself, but not a special button to pick the date.

@ostasevych Yep, we are aware that this isn't great too. We won't have a picker like that when this gets done.