Problem/Motivation
With an initial draft of the Events recipe available, we should start to document potential UX improvements for the overall experience of working with dates and times.
Proposed resolution
It would be useful to get design and usability feedback on the overall layout and organization of the fields and the individual inputs that make them up. For example, consider the event creation interface after applying the current state of the Events recipe:

(Desktop)

(Mobile)
Compare this, for example, to the interface for popular calendar applications.

(Google Calendar, initial state)

(Google Calendar, focus on date and time widget)

(Google Calendar, focus on end time)

(Apple Calendar, initial state)

(Apple Calendar, focus on date and time section)

(Apple Calendar, focus on end time)
A couple of things jump out. For both, the initial display of the date and time widget is simplified, but expands to show additional inputs when it receives focus. For Apple, this is part of a broader strategy of input sections that expand on focus.
Both Google and Apple interfaces have a concept of duration and populate the end time automatically based on a default duration, but neither shows the duration options as a separate element. Instead, the options (and the end times that would result) are shown as options listed below the end time input when it receives focus.
These are both patterns that could be implemented for the Events recipe (likely as updates to the Smart Date module), but we also need to consider accessibility, get real user input, and so on.
Remaining tasks
TBC
User interface changes
TBC
| Comment | File | Size | Author |
|---|---|---|---|
| Screenshot 2024-08-19 at 3.56.39 AM.png | 182.35 KB | mandclu | |
| Screenshot 2024-08-19 at 3.52.47 AM.png | 121.05 KB | mandclu | |
| Screenshot 2024-08-19 at 3.52.30 AM.png | 79.9 KB | mandclu | |
| Screenshot 2024-08-19 at 3.57.20 AM.png | 161.53 KB | mandclu | |
| Screenshot 2024-08-19 at 3.54.21 AM.png | 123.6 KB | mandclu |
Comments
Comment #2
mandclu commentedComment #3
jonathanshawSounds like a good addition to the core form #states API. Accessibility would be an important consideration.
Comment #4
jonathanshawI think this is an important UX win. The separate duration field is significantly confusing.
Comment #5
mandclu commentedFYI an issue to implement the duration options in an overlay has been posted at #3472863: Show duration options in an overlay and now has an MR that is ready for review. It could definitely use some design input, and likely will need some accessibility input as well.
Comment #6
pameeela commentedAs noted in the IS, these changes would be made in Smart Date so moving it there.
Comment #7
mandclu commentedThese changes were implemented and merged in as part of #3472863: Show duration options in an overlay.