Open Stack

The confirmation modal on the top of the other modal is weird and
cumbersome. I think disabling clicking outside space (staic backdrop) is
the right way to go.

Anton

On Tue, Dec 2, 2014 at 8:30 PM, Thai Q Tran <tqtran at us.ibm.com> wrote:

> I like David's approach, but having two modals (one for the form, one for
> the confirmation) on top of each other is a bit weird and would require
> constant checks for input.
> We already have three ways to close the dialog today: via the cancel
> button, X button, and ESC key. It's more important to me that I don't lose
> work by accidentally clicking outside. So from this perspective, I think
> that having a static behavior is the way to go. Regardless of what approach
> we pick, its an improvement over what we have today.
>
>
> [image: Inactive hide details for Timur Sufiev ---12/02/2014 04:22:00
> AM---Hello, Horizoneers and UX-ers! The default behavior of modal]Timur
> Sufiev ---12/02/2014 04:22:00 AM---Hello, Horizoneers and UX-ers! The
> default behavior of modals in Horizon (defined in turn by Bootstr
>
> From: Timur Sufiev <tsufiev at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: 12/02/2014 04:22 AM
> Subject: [openstack-dev] [horizon] [ux] Changing how the modals are
> closed in Horizon
> ------------------------------
>
>
>
> Hello, Horizoneers and UX-ers!
>
> The default behavior of modals in Horizon (defined in turn by Bootstrap
> defaults) regarding their closing is to simply close the modal once user
> clicks somewhere outside of it (on the backdrop element below and around
> the modal). This is not very convenient for the modal forms containing a
> lot of input - when it is closed without a warning all the data the user
> has already provided is lost. Keeping this in mind, I've made a patch [1]
> changing default Bootstrap 'modal_backdrop' parameter to 'static', which
> means that forms are not closed once the user clicks on a backdrop, while
> it's still possible to close them by pressing 'Esc' or clicking on the 'X'
> link at the top right border of the form. Also the patch [1] allows to
> customize this behavior (between 'true'-current one/'false' - no backdrop
> element/'static') on a per-form basis.
>
> What I didn't know at the moment I was uploading my patch is that David
> Lyle had been working on a similar solution [2] some time ago. It's a bit
> more elaborate than mine: if the user has already filled some some inputs
> in the form, then a confirmation dialog is shown, otherwise the form is
> silently dismissed as it happens now.
>
> The whole point of writing about this in the ML is to gather opinions
> which approach is better:
> * stick to the current behavior;
> * change the default behavior to 'static';
> * use the David's solution with confirmation dialog (once it'll be rebased
> to the current codebase).
>
> What do you think?
>
> [1] *https://review.openstack.org/#/c/113206/*
> <https://review.openstack.org/#/c/113206/>
> [2] *https://review.openstack.org/#/c/23037/*
> <https://review.openstack.org/#/c/23037/>
>
> P.S. I remember that I promised to write this email a week ago, but better
> late than never :).
>
> --
> Timur Sufiev_______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141203/2515206c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141203/2515206c/attachment.gif>