Dialogs

[dontpanicgr]

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.
#7 (comment)

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:

1. Properly inform users on the outcome of an action (e.g. uncompleted work that is not saved and might be lost if navigating away from a component or page in the application.
2. Provide easy to undestand navigation to confirm or dismiss a proposed action.

Example

Editor: Tab for navigating away from unsaved plural string

Transifex says
You have untranslated plural forms.
Your work will be lost. Are you sure you want to navigate away from this string?
[ Cancel ] [ OK ]

Action	Behaviour	Keyboard Key	Result
Cancel	Stay on this page	Esc	Work not lost
OK	Leave this page	Enter/Return	Work lost

---

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:

Dialog title
You have {{unsaved_work}}.
Your work will be lost. Are you sure you want to {{user_action}}?
[ Cancel ] [ OK ]

Action	Behaviour	Keyboard Key	Result
Cancel	Stay on this page	Esc	Work not lost
OK	Leave this page	Enter/Return	Work lost
Save *	Stay on this page	...	Save work

* 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

[mikegianno]

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.