nextcloud / calendar

📆 Calendar app for Nextcloud
https://apps.nextcloud.com/apps/calendar
GNU Affero General Public License v3.0
981 stars 241 forks source link

Implicit Action on Datetimepicker #2936

Closed newhinton closed 2 years ago

newhinton commented 3 years ago

Is your feature request related to a problem? Please describe. When editing an event, either combination of time&date, the dialog can only be closed by clicking outside the dialog.

Describe the solution you'd like I'd like to propose an intentional way of closing this dialog, via a save button.

Additional context I think a similar topic was discussed in #899 I agree that it is good to not discard changes when the user clicks somewhere else, but an action that changes something should always have an explicit trigger (like an OK button) Only having implicit triggers, like closing or clicking somewhere else, does not communicate to the user when something is going to happen. Imho, a clear way to save would be better, as to prevent confusion. (I find myself quite often switching between date&time because i expect a save button in the lower right)

newhinton commented 3 years ago

The contact's app uses the same picker for birthdays (except the date/time switching), and it has an OK button

major-mayer commented 2 years ago

This annoys me very often too. I like the idea of a separate "OK" button. There should be enough space in the picker window.

alexanderdd commented 2 years ago

What lead you to believe that this is what most users want/prefer? Did you do any usability testing? @ChristophWurst does this change really fit with Nextcloud design guidelines? (btw where can I find the guidelines? they are not linked from https://nextcloud.com/design/ )

I have used many calendar apps, and this is the first one that asks me to confirm a date with an ok button after I already clicked the day I want to select. Very confusing, especially in the navigation datepicker in the top left. And it introduces an additonal click, reducing productivity. I think this change should be reversed.

In the first post here the problem is described by "the dialog can only be closed by clicking outside the dialog." If closing it is the issue, the solution should not be "an intentional way of closing this dialog, via a save button" but an "x" at the top right of the popup.

ChristophWurst commented 2 years ago

does this change really fit with Nextcloud design guidelines?

@nimishavijay @jancborchardt could you please clarify?

newhinton commented 2 years ago

I guess i agree with the navigation datepicker, it probably should not ask for an okay there, since that directly results in an action and is therefore not implicit. That is not true for the date(time)-picker for the event-editor, that one does not close after selecting a date (and should not). Every other picker that i know of uses an 'ok'-button though, at least contacts&deck, so it is consistent (which doesn't mean correct)

raimund-schluessler commented 2 years ago

I have to say, I also find the OK button a bit annoying (especially after it was introduced, I had to select the date multiple times, until I got it). But with the combined date- and timepicker, I guess it makes sense to have it.

However, if we would use two separate pickers for date and time, no OK button would be necessary anymore. It would not create more clicks to set date and time. It would even reduce the effort to select a time only, since you can select it directly, without the detour to the datepicker. Have a look at the Tasks app, where it's done like this.

alexanderdd commented 2 years ago

I guess i agree with the navigation datepicker, it probably should not ask for an okay there, since that directly results in an action and is therefore not implicit.

YES!

Can someone please open a bug report for that?

alexanderdd commented 2 years ago

This discussion really needs a comment from Nextcloud design team... @jancborchardt ? @nimishavijay ?

newhinton commented 2 years ago

@alexanderdd No need, i created a PR which can be reviewed by the maintainers that removes the confirm-button only from the left top picker. It now defaults to "OK", but now any component using that picker can easily decide to override this.

This was an oversight on my part, but hopefully this solution will help everyone.