[openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon
Timur Sufiev
tsufiev at mirantis.com
Thu Dec 4 14:08:46 UTC 2014
Hi Aaron,
The only way to combine 2 aforementioned solutions I've been thinking of is
to implement David's solution as the 4th option (in addition to
true|false|static) on a per-form basis, leaving the possibility to change
the default value in configs. I guess this sort of combining would be as
simple as just putting both patches together (perhaps, changing a bit
David's js-code for catching 'click' event - to work only for the modal
forms with [data-modal-backdrop='confirm']).
On Thu, Dec 4, 2014 at 1:30 AM, Aaron Sahlin <asahlin at linux.vnet.ibm.com>
wrote:
> I would be happy with either the two proposed solutions (both
> improvements over the what we have now).
> Any thoughts on combining them? Only close if esc or 'x' is clicked, but
> also warn them if data was entered.
>
>
>
> On 12/3/2014 7:21 AM, Rob Cresswell (rcresswe) wrote:
>
> +1 to changing the behaviour to ‘static'. Modal inside a modal is
> potentially slightly more useful, but looks messy and inconsistent, which I
> think outweighs the functionality.
>
> Rob
>
>
> On 2 Dec 2014, at 12:21, Timur Sufiev <tsufiev at mirantis.com> wrote:
>
> 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
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://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
>
>
--
Timur Sufiev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141204/dd1bfca5/attachment.html>
More information about the OpenStack-dev
mailing list