Change animation

[waldyrious]

The current animation of sliding content in and out laterally is visually interesting, but I wonder if it would be more semantically suggestive to use a folding/accordion animation, whereas deleted code is vertically compressed out of existence, and new code expands out in the opposite way.

For lines that are changed, I'd envision this to produce an effect similar to a slot machine or a cube rolling back.

Not sure if I'm describing the effect in a clear way. Does the above make any sense?

[JCJutson]

For a line that is changed, it could do the same thing, just horizontally. Accordion new characters, squish old ones.

[waldyrious]

Yes, if only part of a line is changed, that makes more sense, agreed. I see you've created #26 to track that case.

On the other hand, if a line is completely replaced, or the hunk spans more than one line, I think the vertical approach probably makes more sense, even if some portion of the lines remains unchanged.

[pomber]

Ok, I created #27 and #28 to try new animations (for lines).

See:
https://deploy-preview-27--github-history.netlify.com/babel/babel/blob/master/packages/babel-core/test/browserify.js
https://deploy-preview-28--github-history.netlify.com/babel/babel/blob/master/packages/babel-core/test/browserify.js

I think I like more the lines coming from the sides because it gives a sense of time direction.

[waldyrious]

Thanks for trying this out so quickly! The demos are great, but indeed the effect doesn't work out in all cases out of the box, especially when multiple lines are involved. Perhaps with some tweaks it would work better (e.g. highlighting the lines added / removed / changed with the usual diff colors, and the portions within them that changed)?

That said, I understand if you still think the sideways sliding animation works better.

[JonnyKelso]

I think neither animations work. You need to see both versions of a change line at the same time

[katrinleinweber]

Also my impression: seeing the diff is sooo useful in sooo many situations, that git-history should IMHO include (or some variant of) the diff visual to remain useful in the long-term. I noticed myself <--->-arrow-key-ing back-and-forth quickly in all of the demos.

"change blindness" may be a relevant scientific keyword here: the longer the delay between the different end states (i.e. the duration of the change animation), the more likely it becomes that a change is overlooked.

[pomber]

The current visualization is more for browsing different versions of a file rather than viewing the diff between two versions. I want to keep that, but I agree that people usually want to see a diff after browsing the history.
I'm thinking on adding some way to activate a "diff mode" that animates between diffs, as you change the "left" and/or the "right" version of a file.