Figure out the scope of the Quick Add event creation popover widget vs full Event Editor dialog, and if they should be merged
The quick-add-popover
event creation popover was introduced in 2016, in commits 11070f1d and 7c0e3776. It seems it was intended as a way to mainly create all-day events, and to use natural language parsing (#3, #665) to handle time-based events and other details (#704).
Its read-only counterpart, the event-popover
, was introduced in 2021 in !175 (merged).
This ticket is mainly about the quick-add-popover
, though it is hard to dissociate it from its read-only counterpart.
Executive summary
Problem statement
When you consider this old annoyance and consider the possibility of flattening the calendars list directly into the quick-add popover (if acceptable ?), then aren't we on the slippery slope of "But how far are we from just eliminating that thing and using the event editor dialog directly?!"
I (and many others, when asking around) have a 50:50 love & hate the quick event creation popover at the same time:
…its simplicity vs its limitations and redundancy (since we don't have natural language parsing (and its related simpler ideas like this and that) makes it a bit of a disappointment. Historically, I don't think we even know why we have that popover widget as an intermediate step; to me it only makes sense if we were to have natural language parsing (which I'm not sure if it will happen at this point), otherwise if we were to directly use the full event editor dialog we wouldn't need natural language parsing at all.
When using the quick add event creation popover widget, in practice,
- 100% of the time I need to do extra clicks to pick the desired target calendar (issue #90),
- 60-80% of the time I need to click the "Edit Details…" button to create a time-based event anyway
…as a result, I regularly wonder why the popover thing exists vs just opening the event editor dialog directly to begin with (or replacing the event editor dialog by "do everything in a shapeshifting editable adaptable* popover"), even if we presume the full "Event Editor dialog" may currently feel a bit clunky/dated on its own:
I would like the overall problem presented here to be evaluated as part of the design process at Teams/Design/app-mockups#83 and for us to have either a decision to merge the two widgets (popover and dialog) into one do-it-all simple-but-flexible widget, or to have a clearer definition of the quick-add popover widget's intended scope now and in the future.
Possible new approaches to leverage widescreens
For one thing, I'd think nowadays we ought to have really adaptive layouts that consider whether you're in portrait or landscape, and to avoid scrolling by somehow exposing some of the contents (like longer lists of calendars; I have 15+ and some users have more than 25) in a columns layout that properly utilizes available screen real estate... I dunno if that's technically possible today already?
In other words, I'd like the event details dialog and/or popover to be truly screen-adaptive, rquiring no scrolling in the majority of cases, instead of always a skyscraper-like portrait-oriented widget.