Open Stack

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 <mailto: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
>>     <mailto: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
>>>     <mailto: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  <mailto: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
>     <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141204/a6d45de9/attachment.html>