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

Smooth out the block switcher animation #9468

Conversation

chrisvanpatten
Copy link
Member

@chrisvanpatten chrisvanpatten commented Aug 30, 2018

This PR tries a slightly smoother block switcher hover animation.

The switcher still moves, but as the icons move they fade in or out (the "incoming" icon fades from transparent to opaque, and the "outgoing" icon fades from opaque to transparent).

It also changes the animation speed of the movement to 0.2s instead of 0.1s.

Because GIFs compress the heck out of the animation, I made a video you can watch instead if you don't want to try it out directly. It's a split screen: the left shows the animation in master, and the right shows the animation in this branch.

https://www.dropbox.com/s/q18q0cug1x8it8s/demo.mov?dl=0

Overall the effect is very subtle, but I think it makes the motion feel a bit less aggressive than it currently does.

@chrisvanpatten chrisvanpatten added the [Type] Enhancement A suggestion for improvement. label Aug 30, 2018
@jasmussen
Copy link
Contributor

GIF:

smoother

This is very very nice. I like it.

Perhaps it's just me, though, but I'm always leaning towards faster is better when it comes to this type of animation. It could be a quirk of my personality, but whenever use an interface that animates and I have to wait for the animation to finish to do a thing, I find it exceptionally frustrating. For that reason I always go fast when I can.

But I do definitely see your point here, and it's worth mentioning that you don't have to wait for an animation to finish, you can actually click instantly — that's important to note. But we still don't want users to think they have to wait.

One rule of thumb I have, though, is that an interface animation should never take longer than .2s. So perhaps all is good if you change the opacity to .2s instead of .3s.

Possibly try .1 for opacity also? But if that feels too subtle then 👍 👍 to .2s :)

I know ☝️ got a little off track, but thanks so much for your contribution! You continue to impress me with your attention to detail, and your follow-through. 👏

@chrisvanpatten
Copy link
Member Author

One rule of thumb I have, though, is that an interface animation should never take longer than .2s. So perhaps all is good if you change the opacity to .2s instead of .3s.

Possibly try .1 for opacity also? But if that feels too subtle then 👍 👍 to .2s :)

Did you try this locally? I originally had it that way, but it didn't feel great to me — the opacity change was almost completely unnoticeable.

I think that's because the opacity transition on the incoming icon hits its midpoint (and thus 50% opacity) when the icon is only halfway into view. That means the 50%–100% transition is the most "visible", but because the icon is moving so quickly it's hard to notice.

By making the opacity transition slightly longer, it shifts the midpoint of the opacity animation further into the motion transition, which means you see the icon enter into view at a lower opacity, so the opacity change is more visible.

All that to say…

  1. Definitely try it locally if you haven't
  2. This might be solvable by just tweaking the easing setting; I'll play with that
  3. Thank you for your very kind and generous words 😄

@chrisvanpatten
Copy link
Member Author

Okay, changing the easing settings definitely helps. I'll get this updated :)

@chrisvanpatten
Copy link
Member Author

icon

I tweaked the easing settings so both transitions could be 0.2s. I think this is pretty good!

@chrisvanpatten
Copy link
Member Author

The Travis failures look unrelated. Yet again, Travis is grumpy :) I know it's late in the game but it would be awesome if this could get in with 3.7, if the test can pass…

@jasmussen
Copy link
Contributor

Sorry I had to step to the side for a bit.

I dig this, and thanks again for the work (and yes I tried locally). Like I noted, I'm super cautious about animations, and this is our first noticable animation. That's another guiding principle for me: if you do things right, people won't notice you've done anything at all. (I stole that from Futurama.)

In this case, what's in master is something you don't notice necessarily, because it's so fast. Which feels like a good first way to add animation to the interface. We can then get some additional @karmatosed eyes on this, and then get this in for 3.8 instead.

One of the things next on our list is "micro interactions": #8029 — this is specifically one of those. I imagine we could also look at animating popout menus and sidebars appearing. When this happens, it becomes important that we have a "vocabulary" for animations — a consistent set of animations that all feel related. It could be in speed and easing, or in type and direction. Or a combination of those.

I imagine that this PR could be a good first step in refining animations after 3.7, and could help start that vocabulary. What do you think?

@chrisvanpatten
Copy link
Member Author

@jasmussen I would quibble a bit with this: "what's in master is something you don't notice necessarily, because it's so fast" — it might just be my (admittedly bad) vision but it feels almost too noticeable. But that said, I think it's totally fair to let this marinate and pop it in during the next cycle alongside some other animation PRs!

@karmatosed
Copy link
Member

I am on team 🐢and would like it slower 😄

@shaunandrews
Copy link
Contributor

I really dislike the animation here — not only does it feel like the current block icon is running away from my cursor (get back here, I want to click you!) but once I open the popover, the current block icon is no where to be found.

I feel like the block icon should be consistent and not run away and hide when I'm trying to change it.

Maybe something like this:

alternate switcher animation

@shaunandrews
Copy link
Contributor

The more I look at this, the more I wonder why we have the double-arrow icon at all? Whats the significance of it showing on hover? What problem does it (attempt to) solve?

@chrisvanpatten
Copy link
Member Author

@shaunandrews Basically people were not finding this option… there's a lot of discussion in #9127.

@chrisvanpatten
Copy link
Member Author

As much as I'd love to smooth this out I think for now there are other priorities so I'm closing this out and hopefully we can revisit in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants