[openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon

Thai Q Tran tqtran at us.ibm.com
Tue Dec 2 16:30:58 UTC 2014


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.




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/
[2] 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141202/cd99cec0/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/20141202/cd99cec0/attachment.gif>


More information about the OpenStack-dev mailing list