UX optimizations to Date and Time entry fields for Events Recipe

Created on 19 August 2024, 5 months ago
Updated 9 September 2024, 4 months ago

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

🌱 Plan
Status

Active

Component

Track: Event

Created by

🇨🇦Canada mandclu

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @mandclu
  • 🇬🇧United Kingdom jonathanshaw Stroud, UK

    the initial display of the date and time widget is simplified, but expands to show additional inputs when it receives focus

    Sounds like a good addition to the core form #states API. Accessibility would be an important consideration.

  • 🇬🇧United Kingdom jonathanshaw Stroud, UK

    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.

    I think this is an important UX win. The separate duration field is significantly confusing.

  • 🇨🇦Canada mandclu

    FYI an issue to implement the duration options in an overlay has been posted at Show duration options in an overlay Needs review 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.

Production build 0.71.5 2024