Open dontpanicgr opened 6 years ago
The existing dialogue is managed by the browser (if you open a different browser, and replicate actions to preview this dialogue you might see something different).
In that sense, I don't think any work can be done on this dialogue other than the copywriting. We cannot control any aspects of that.
My personal opinion is that this is a typical validation modal that should be totally managed by our system and not the browser. In other instances we have already implemented validation in our system (TM entry deletion in the editor, project deletion, org deletion) AND also revisited from the design perspective. I believe we should simply sanitize those cases whenever we find them and not introduce more as we are increasing our design debt.
Dialogs
Dialogs inform users about a task and can contain critical information, require decisions, or involve multiple tasks. Also in this thread some early discussion took place about dialogs and system feedback overall. https://github.com/transifex/txds/issues/7#issuecomment-387725767
This issue is posted due to recent ticket about navigating away from a plural string in the editor.
With this txds issue we will try to understand and find an appropriate, modular way to:
Example
Editor: Tab for navigating away from unsaved plural string
Esc
Enter/Return
Component
Based on the above examples, we can discuss on the behaviour and structure of the dialog component which could look and work as follows:
Esc
Enter/Return
...
* optional
Screens:
Further reading:
https://material.io/design/components/dialogs.html#actions https://ux.stackexchange.com/questions/83535/should-an-unsaved-changes-dialog-in-a-web-app-contain-a-save-option http://designsystem.morningstar.com/components/dialogs.html https://medium.com/ux-power-tools/design-a-reusable-system-modal-e358985cfeb6