Use a dialog for custom date form instead of including it in the action menu
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 2.2k
- Forks
- 587
- Avg merge
- 18h 27m
- Merged PRs (30d)
- 333
Description
Including baby forms within action menus is a recurring pattern in Nextcloud and it's one that I think we should break. We shouldn't include forms, especially if they involve multi-selects and pickers, into tiny action menus.
When there's the need of a form we can add an action button that brings up a dialog or opens the form somewhere else.
Having a text input with an inline submit button is probably ok but still not ideal IMO.
In this particular case we have a baby form with a submit button that looks exactly like an action buttons above, creating visual confusion and usability issues. For example here there's no way to guarantee that the picker itself won't block the button to submit the form itself once you've chosen the date. (see screenshot)
This came up in a recent design call and there was some consensus on that we should probably even deprecate these complex action input elements. What do you think @nextcloud/designers ??
Originally posted by @marcoambrosini in https://github.com/nextcloud/spreed/issues/10105#issuecomment-1670928740
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review the discussion in issue 10105 and the attached screenshot first, since this issue has no file or test entry point. Confirm the current design decision before locating the custom date form and its action-menu integration. Done means the form is opened through a dedicated dialog or separate form flow rather than embedded in the action menu.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- design, frontend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100