Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Don't focus close button on modal open/Try a modal appear animation #9900
This is the first in a series of tiny micro interaction animations I hope to add across the UI. It adds a "fade & appear" animation to any modal you open. It's fast, but it's smooth, and it's non intrusive.
Please try checking out the branch — the framerate of this GIF doesn't do it justice, so please don't give your animation feedback based solely on this GIF, please please try it first.
The animation includes movement, downwards up, because this helps suggest that the modal is a card that always exists at this elevation, it just sits outside the viewport, in this case below the screen and it's literally brought up when you ask for it.
However this animation also brings with us a challenge that needs solving — right now the "Close dialog" tooltip shows every time a modal is opened. This is a problem on its own because it sends mixed signals to the user: I just opened this dialog, should I close it again?
But specifically in this case, the tooltip appears mid-animation which means it's not correctly aligned.
How do we fix this? Here are some thoughts:
What other solutions can you think of? It really is a bad experience for sighted users as it is.
Have you considered something like this for the micro-animations? https://github.com/Automattic/wp-calypso/tree/master/client/components/animate
I have not, but I can probably refactor to use that for the modal here as a first.
The benefit is that it's easier to reuse the animations, and make them dedicated parts of the components themselves as opposed to "CSS sugar on top", correct?
This presumably still wouldn't fix the issue with tooltip appearing, though right?
This is looking good! I have one possibly weird suggestion: Have you tried slowing down the white overlay on the page?
The speed at which the modal appears feels great, but the slight white overlay transition felt a little jarring to me — I had the sense that something changed on the page, but I wasn't able to quite figure out what it was at first. Felt a little like a glitch to me. Slowing that down just a little bit might make the transition feel a little more relaxed.
(It's also possible I'm just reacting to the fact that the white overlay is very subtle in general — in which case this won't help.
Note that the animation is not visible in this GIF because Licecap doesn't have sufficient framerate to show the .1s animation, but it's there.
The modal itself now has a scrollable area that itself is focused when initially opened. Aside from solving the issue of the tooltip showing on open, this makes the scrollable region accessible to the keyboard (arrow keys, page up, page down).
Not sure it really "fixes" #9410 as discussion there is still ongoing. Not opposed to exploration though.
The main drawbacks I see in the current state of this PR are:
The second issue is actually related to the modal height, which I'd suggest to address separately in #8561. Not arguing, but this PR started with adding an animation and it is now touching several, not strictly related things that would be best to address separately, for better clarity and also for history.
Worth noting that to fix the modal height I was exploring something for #8561. Ideally, the modal height should be determined by its content and have a
referenced this pull request
Sep 17, 2018
I looked into adding an
Animate HOC like in Calypso, but in this case we want two animations and it doesn't really end up being an elegant refactor.
I think that kind of HOC might be neat but I see it best handled separately.
Otherwise I find this great. I've removed a redundant label as per @afercia's suggestion so there is no "Dialog Contents" label anymore. I think that makes this good to go.
The only issue is that the modal is focused even when there is no interaction inside the modal other than the ability to tab to the close button. This is unfortunate but improves the design of the modal in all cases and allows users to interact with larger modals (like the keyboard screen one) with the keyboard to scroll them when opened.
I think that's overall better so I'm going to approve this.