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 <[email protected]> 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 <[email protected]> > To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
