You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I looked at those issues ... and I laughed at first, then I was sad, and lately I was angry!
Switch on, switch off, enable, disable ... 👿 ???
The body of the problem
"Allow closing modals by clicking on the background" was introduced in 1.2.28, which I found very convenient.
It went through some modifications and bugfixes for several versions.
Then in 1.2.33 the feature got entirely disabled, as this appears to be the easiest solution to some specific issue.
Hence, my frustration on the matter and the entire investigation about it.
I tagged this issue as bug but it is more of a workflow approach indecisiveness.
I really don't mean to be rude, but you can't seriously run a software development like that !
That KILLS both the behavior consistency of the software and the user experience !
You know, UX especially is a highly subjective matter. With features like that it is always 50:50, half the users will like it - the other half will hate it. Or even: today they like it - tomorrow they hate it.
Thus, the wise approach in such situations is not to choose having it or not - but rather make it an option and let the users consider for themselves whether to use it or not.
Anyway, regarding the specific matter - I don't even think there is currently a generic problem with the feature - I just blame it on an unfortunate sequence of issues, requests and decisions.
My personal preference is to have the option to click outside of a modal form so to discard it. There are multiple reasons why I like this better - habits, working with other platforms that behave this way, convenience, easier not having to aim with mouse for the small 'x' button or to hit the Esc key, not to mention the mobile experience where keyboard shortcuts don't help at all.
As far as I understand, the guys who object this behavior don't really mind it but they rather face side d/effects it causes due to some bugs closing the modal inappropriately. What I see now is that :
The 'dirtyForm' mechanic prevents closing a modal when there are changes, which is perfectly fine and works OK.
The bugs about drag and select that end outside the modal and cause a fake 'click' event are now (almost) fixed.
I enabled locally for myself the 'overlayClickDestroy' option in all places in code and it seems to behave alright.
There is still a case when dragging from Tags field outside the Edit Task Modal form causes it to close inadequately.
But the point is - this is a bug - and bugs are to be fixed!
Masking bugs by disabling an entire feature is a BAD decision - especially when made authoritatively on the spot without any inquiry or discussion or gathering additional info. Removing something that works and was there for a while can't be expected to please the people who are already making use of it.
So, to wrap the whole thing:
Please, revive the mechanic to close modals by clicking outside - yet consider making it an UI option, and definitely do hunt and kill the related bugs.
I know this is an open source project, and mostly a one-man-army supported - yet, if you still aim at providing the best functionality and experience for the users - please don't sacrifice gathering different opinions and views in order to consider the best solution, rather than simply reacting on the fly to a particular request.
That being said, I am a long time user and fan of Kanboard ... and I don't wanna change that just now.
I really appreciate and THANK YOU for your continuous efforts, so please, take all the above on a good note!
Regards 🙇
The text was updated successfully, but these errors were encountered:
What is the difficulty with clicking the "Save" or "Cancel" (or "Close") buttons, really? Or pressing the Esc key?
In my view, the previous approach was just unexpected and downright dangerous. If you really must have a shortcut to avoid clicking the Cancel / close button, then… you can already use the convenience Esc keyboard shortcut to dismiss modals, instead of any click outside doing that. Less risk of accidents (because yes, accidental clicks or touch presses happen, all the time, for many users).
consider making it an UI option
I wouldn't recommend this approach. Adding an "option" for this is non-design, that just complexifies the code and testing matrix, like the examples in https://www.joelonsoftware.com/2000/04/12/choices/
Less risk of accidents (because yes, accidental clicks or touch presses happen, all the time, for many users).
I can attest to that. Especially bad on Android and if the computer can't process the browser in a reasonable time, something, for ex, my Orange Pi 800 can't do with Firefox.
Configuration
Related Issues (not in specific order and probably not a complete list):
#3791
#5288
#5363
#5226
#5258
#5239
#4895
#2153
I looked at those issues ... and I laughed at first, then I was sad, and lately I was angry!
Switch on, switch off, enable, disable ... 👿 ???
The body of the problem
"Allow closing modals by clicking on the background" was introduced in 1.2.28, which I found very convenient.
It went through some modifications and bugfixes for several versions.
Then in 1.2.33 the feature got entirely disabled, as this appears to be the easiest solution to some specific issue.
Hence, my frustration on the matter and the entire investigation about it.
I tagged this issue as bug but it is more of a workflow approach indecisiveness.
I really don't mean to be rude, but you can't seriously run a software development like that !
That KILLS both the behavior consistency of the software and the user experience !
You know, UX especially is a highly subjective matter. With features like that it is always 50:50, half the users will like it - the other half will hate it. Or even: today they like it - tomorrow they hate it.
Thus, the wise approach in such situations is not to choose having it or not - but rather make it an option and let the users consider for themselves whether to use it or not.
Anyway, regarding the specific matter - I don't even think there is currently a generic problem with the feature - I just blame it on an unfortunate sequence of issues, requests and decisions.
My personal preference is to have the option to click outside of a modal form so to discard it. There are multiple reasons why I like this better - habits, working with other platforms that behave this way, convenience, easier not having to aim with mouse for the small 'x' button or to hit the Esc key, not to mention the mobile experience where keyboard shortcuts don't help at all.
As far as I understand, the guys who object this behavior don't really mind it but they rather face side d/effects it causes due to some bugs closing the modal inappropriately. What I see now is that :
I enabled locally for myself the 'overlayClickDestroy' option in all places in code and it seems to behave alright.
There is still a case when dragging from Tags field outside the Edit Task Modal form causes it to close inadequately.
But the point is - this is a bug - and bugs are to be fixed!
Masking bugs by disabling an entire feature is a BAD decision - especially when made authoritatively on the spot without any inquiry or discussion or gathering additional info. Removing something that works and was there for a while can't be expected to please the people who are already making use of it.
So, to wrap the whole thing:
That being said, I am a long time user and fan of Kanboard ... and I don't wanna change that just now.
I really appreciate and THANK YOU for your continuous efforts, so please, take all the above on a good note!
Regards 🙇
The text was updated successfully, but these errors were encountered: