Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow closing VS do NOT close modals by clicking outside on the background #5395

Open
imfx77 opened this issue Dec 26, 2023 · 3 comments
Open

Comments

@imfx77
Copy link
Contributor

imfx77 commented Dec 26, 2023

Configuration

  • Kanboard version: 1.2.33
  • Database type and version: sqlite 3.41.2
  • PHP version: 8.2.10
  • OS: Linux 4.4.302+ x86_64 (docker image on Synology)
  • Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0

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 :

  • 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 🙇

@imfx77 imfx77 added the bug label Dec 26, 2023
@fguillot fguillot added ui/ux issues and removed bug labels Jan 14, 2024
@nekohayo
Copy link
Contributor

nekohayo commented Jan 14, 2024

Your complaint sounds like https://imgs.xkcd.com/comics/workflow.png

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/

@rautamiekka
Copy link

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.

@tomeli5n
Copy link

Hello, I want to add a user-case for working with emojis using MarkdownPlus.

  • New Task modal
  • user write Description text
  • user write :
  • emoji selector pops up
  • user press [ESC] key

expected behaviour: close emoji selector

actual behaviour: the New Task modal is gone

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

5 participants