Enhance Calendar Component (events)

[Tiiinky]

First I want to say thanks for adding the calendar and datepicker components (especially the button-only mode really helped me)
However, I'd love to see more functionality on the calendar component.

Is your feature request related to a problem? Please describe...

I need to create a calendar widget that is capable of displaying events

Describe the solution you'd like

I imagine a solution pretty much like the calendar component provided by vuetify

• It should be possible to add events to the calendar using name, start, end as properties.
• Switching between daily, weekly and monthly view would be great
• Option to show popover/tooltip when Click/Hover an event

What do you think?

[tmorehouse]

We are currently working on additions to b-calendar, specifically to the date-info-fn function, that will allow specifying events for a particular date.

The big hurdle we have now is dealing with accessibility (specifically for screen reader users) of the event information.

Vuetify, while its event system for calendars visually looks nice, severely lacks accessibility (mainly because it is difficult), and screen reader users do not know that a particular date has an event (for example, enable ChromeVox in chrome or enable VoiceOver on MAC/IOS, and you will hear that the presence of events are not communicated to screen reader users).

Once we have it figured out, events will be configurable via the date-info-fn prop of <b-calendar>

[tmorehouse]

Popovers and tooltips for certain dates/events will be difficult, due to the grid nature (role=application) of the calendar grid. which would further complicate the accessibility features of calendar.

View style (day, week, month) is on the roadmap... but as with other features, requires additional accessibility handling to make sure the component is usable by all users.... and currently is a low priority due to the complexities needed to make it accessible (while trying to keep the component lightweight JS-wise)

[phil-w]

I need the hover text thing on a per-date basis, so I can show values which are specific to each date. It's not for mobile users so the accessibility thing isn't an issue. A slot which I can fill with whatever I want would be ideal.

[tmorehouse]

@phil-w accessibility means more than just mobile... keyboard only users (i.e. tab/arrow keys) can't trigger a hover, neither can screen reader users.

[m-demydiuk]

It would be great to improve navigation. For now, there are only options prev month/year and next month/year. But what if I need to select date of birth, say, 31-10-1965? Do I need to click 55 times previous year button? So, need a button to show years, and button to show months.

[tmorehouse]

@m-demydiuk calendar supports keyboard navigation and repeating keys, which is a quick way of navigating through years.

[m-demydiuk]

@tmorehouse but it is not obvious for users, and not user friendly.

[tmorehouse]

That is why there is the note that keyboard navigation is at the bottom of the calendar.

[m-demydiuk]

@tmorehouse I just noticed this note. I tried to use it, but navigation with the keyboard is also bad. Just try to navigate to 1965 year with keyboard, and you will understand the pain that our old clients will feel. Of course, it is up to you what functionality should be implemented and I just want to suggest. For reference, you can take a look for other libraries, and maybe you will understand that this is really important :)

[m-demydiuk]

https://vuetifyjs.com/en/components/date-pickers/#date-month-pickers
You just click on the date and you got pad with months. Click again and you got scroll with years.
https://www.jqueryscript.net/demo/Super-Tiny-jQuery-HTML5-Date-Picker-Plugin/
Something similar.

[tmorehouse]

Press and hold alt + PageUp. (which is standard for grid navigation in apps, and compliant web pages): https://bootstrap-vue.org/docs/components/calendar#accessibility

Note: Vuetify's calendar is NOT accessible to screen reader users, nor does it support standard keyboard navigation, nor are any of the buttons properly labeled (prev/next month are just icons, no labels)... so it is not really a good comparison. it may look pretty, but if you are a non-sighted user you are screwed. There is a reason they haven't added accessibility to it, as adding in that support with the current interface cannot easily be done.

[m-demydiuk]

Your calendar looks good! :)
I am just trying to say, that older people may don't know about alt+PageUp. Actually, I don't know about alt+PageUp, maybe, because I do not have problems with accessibility. Just imagine that you are a regular user that fills the form, you don't mind about keyboard shortcuts and other "hacks". All you want is to select a date which is 06-05-1965 (my dad's bday), and you want to do it with a mouse. You need to click about 55 times prev year. It is insane for the user.
Another variant, maybe much better, is to make the input field not readonly, so you can type in the date. I know I can do it with input group and button-only, but in that case, I need to write additional code to sync input field with datepicker and converting values. And I have a bug with it that I described here
#4999
But I think this bug is more related to vee validate library. So for now, I have input field and date picker that are not synced with the same value.

[Tiiinky]

@tmorehouse I understand that a fancy implementation like vuetifyjs is no option, but I also believe that keyboard control on a web ui is rather uncommon.
How about an optional year dropdown list. Or is it possible to add a custom dropdown list to the component and bind the v-model?

[tmorehouse]

A year dropdown might be possible.... But the question is... how many entries should it display? 10? 20? +/-100? (the bigger the dropdown, the longer it takes to read out the options to a screen reader user). Or perhaps a number input for the year (with a go button)?

[Tiiinky]

why not make a configurable range?

[tmorehouse]

Should it be a range relative to the current displayed year (+/- XX), or a min-max range?

[Tiiinky]

I'd prefer min-max, since it gives most control, but both options would work.

[tmorehouse]

Perhaps if min/max constraints are not set, then it switches to a +/- approach... that way one could jump back a few years, then open the select and jump back even more.

The other option is to add skip +/-10 year (decade) buttons (at either end of the current date navigation button toolbar)

[tmorehouse]

And just a note that WAI-ARIA compliant datepickers are keyboard navigable (we've followed the standard almost to a T). Even most native date pickers are keyboard navigable (and some aren't... and can't be used by screen reader or keyboard-only users)

[Tiiinky]

I think I like the decade button most. Huge dropdown lists are not very user friendly and a common DoB can be set with a few clicks.

I am not saying that its not a good idea to make date pickers keyboard navigable, it's just that i believe the majority of users does not know about it and/or is not used to use anything else than their mouse :)

[tmorehouse]

OK... will see about adding in the decade buttons.. hopefully the 7 buttons total won't be too cramped... and will need to pick out some icons (perhaps the chevron-bar ones).

[m-demydiuk]

Hello @tmorehouse , is it possible somehow to set defaults globally? I need to change the calendar week start day globally to Monday. Is it possible?

[mariusa]

We will be adding skip back/forward by decade (+/-10 years) in the date navigation toolbar section.

Please, if this decision is already taken, at least make this optional. We wouldn't like to clutter the control with additional visual options.
People can and want to use the keyboard, we don't need limiting controls for everything. If I'd like to enter the date 18.04.1602, I can easily copy-paste or type it. Do we need a century back/forward control?

Please, consider the problem being tackled, instead of focusing on a poor solution:

It would be great to improve navigation. For now, there are only options prev month/year and next month/year. But what if I need to select date of birth, say, 31-10-1965?

What's the best way to do this? Use the keyboard to type "31-10-1965". Others need to copy-paste that from another page.

Related note:
https://bootstrap-vue.org/docs/components/form-timepicker/
we find it unusable compared to the native input type="time"
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_time

1. no visual clutter
2. one can simply enter the time AND use the small non-intrusive up/down controls to change hour/minute/AM
   The current time picker doesn't even allow typing a time, say 14:40.

[tmorehouse]

We have made an option where you can use your own input, and handle the parsing of date strings (see https://bootstrap-vue.org/docs/components/form-datepicker#button-only-mode).

[mariusa]

Thanks, but that's cumbersome, compared to
<b-form-input v-model="item.dob" type="date"> </b-form-input>

It also loses the current nice display of a date, once chosen (in b-form-datepicker control, which can show weekday name etc.)

A nice solution would be #5087 . I'll also stop commenting on this thread, we can agree to disagree :)

[tmorehouse]

One can use the context event to get the formatted value of the date (the context event is there for that reason, amoungst others).

Parsing dates is not easy without bringing in a third party time library (as a dependency for BootstrapVue) like moment.js or similar. The native Date.parse() method is unreliable across platforms/browsers and doesn't support all the formats supported by Intl.DateTimeFormatter. The parser would need to match the locale resolved by the date picker.

Replacing the header with an input, as suggested, would remove the fancy formatted date string

Also, the order of the YYYY-MM-DD also is dependent upon locale selected (i.e. MM-DD-YYYY, DD-MM-YYYY, etc, and separators used i.e. / or - etc), which cannot be extracted easily from the Intl object unfortunately.

[mariusa]

Replacing the header with an input, as suggested, would remove the fancy formatted date string

Only while editing the date. While users view the initial form (which might already have a date set) and after choosing the date, the fancy formatted date will be shown in b-form-datepicker:

Parsing dates is not easy

Agreed! But, leaving technical details aside, would you agree that having a free-form input available during date editing (per screenshot in #5087) would be a better user experience (UX) than decade back/forward controls?

If so, I'll research some solutions on the technical issues that you raised, which make sense.
It also makes sense to compromise on UX if no feasible technical solutions are found.

[tmorehouse]

The solution also has to be accessible, and not increasing the complexity it for screen reader users, the fancier it gets, the more difficult for accessibility.

Then there would be the validation of the user date input (and the myriads of formats that could be typed). Seeing on formatted version but requiring a different format for entry is another issue.