[openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon
Solly Ross
sross at redhat.com
Thu Dec 4 17:22:21 UTC 2014
Just throwing in my two cents:
Multiple times, I've lost typed in data in Horizon because I've accidentally pressed escape without thinking (I use Vim, so pressing escape when I'm done typing is second nature). While clicking the 'x' button is often deliberate, pressing escape can be accidental (either through habit or through accidentally pressing the key).
Best Regards,
Solly Ross
----- Original Message -----
> From: "Aaron Sahlin" <asahlin at linux.vnet.ibm.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Thursday, December 4, 2014 12:00:13 PM
> Subject: Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon
>
> The more I think on it. I agree with Rob Cresswell comment "While clicking
> off the modal is relatively easy to do my accident, hitting Esc or ‘X’ are
> fairly distinct actions."
>
> While there is nothing wrong with warning the user that they will lose data
> after they clicked the 'x' / 'esc'... That was a deliberate action by them.
> So might be over engineering this.
>
> My vote is to just keep it simple and go with changing the default behavior
> to 'static'.
>
>
> On 12/4/2014 8:08 AM, Timur Sufiev wrote:
>
>
>
> 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 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
>
>
>
>
> --
> 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
>
More information about the OpenStack-dev
mailing list