@github's got a fun new sign-up flow that includes this little world-building octocat I made earlier this year. Almost worth making a new account just to see her live :)

RT @satyanadella: Today we’re releasing GitHub Spark — a new tool in Copilot that turns your ideas into full-stack apps, entirely in natura….

RT @zenangst: Learned two things today, one. there is a hidden gem inside the GitHub app on iOS. Two. I really suck at Flappy Bird. htt….

S/O to @deanblacc for wrangling the code on this. The GitHub Copilot design engineering team is killing it with this kind of attention to delightful details. I’m super excited to see more polish like this as the product matures. Thanks for following along!

This Director/Actor setup allows for a separation of concerns, making it easy to extend and add new animations, while also allowing us to maintain full control of timings and transitions, creating an interactive Copilot experience - fun to watch and easy to maintain!.

Once the Director knows which animation should be playing, it delegates the execution of this animation to the Actor. The Actor is a smaller and much more simple state machine that breaks each animation into 4 stages: 1) Idle, 2) Starting, 3) Running, 4) Ending

The Director calls the shots. It evaluates conditions like if there’s an error, if copilot is 'thinking' and even if there will be strong positive or negative sentiment in Copilots reply. The Director is driven by 3 main components: AnimationType, OnFinish, and loopAnimation.

Playback is then controlled with javascript via 2 state machines. The first controls which animation to play and when. You can think of this as this state machine as the ‘Director’. The second controls how the animation is played. You can think of this piece as the ‘Actor’.

Making them into SVG sprite sheets meant we could style them for color mode support and animate them entirely with pure CSS. Lightweight, flexible, universally supported, and fast!

But video files, gifs, or third-party js libraries are all too heavy and limiting for the product, so we took a page from old school game design and converted each animation into image sequences, autotraced them into SVGs in Illustrator, and laid them out into sprite sheets.

To make the animations themselves, I modeled a 3D version of the Copilot icon in Blender and animated them in After Effects, to build out a video library of potential responses:

If you’ve used GitHub Copilot chat on recently, you may have noticed some new life breathed into the Copilot chat avatar with interactive 3D character animations. Let's do a deep dive 🧵on how we hacked it together for the front end 🤓’s out there…

RT @mariorod1: Next wave …. coming soon.

Big thanks to @dylanatsmith for helping me think through the problem and for shoehorning it into GitHub's codebase so that it would support all color modes. And thanks to the copilot team for putting up with our shenanigans tied to zero OKRs for the sake of a bit of delight!❤️.

With that, I just copied and pasted copilots answer in the appropriate places and we had our animation, ready to drop into the product! Check out this codepen if you want to poke around at the actual CSS:

Now this is where it get's a little meta. I had my lil friend Copilot there to do the thinking for me! Let Copilot animate himself! I literally just asked Copilot exactly what I was looking for, and it wrote out all the keyframes for me.

The problem here is that keyframing with CSS is a nightmare of percentages and fractions of seconds and doing that by hand would have been a nightmare. .

The basic concept for how we drove the animation is to place the sprite sheet into a <div> set to the size of a single sprite with it's overflow property set to hidden and then translate the sheet's position to move each sprite into the "window" of the div one by one.

So, I took the sprite sheet I had exported and ran it through Illustrator's autotrace feature which spit out a SVG sprite sheet, ready to code up with CSS. I was worried that autotrace would be a little too funky to work but it ended up doing the trick!.

After a conversation with a more knowledgeable designer, we came around to the fact that SVG would be the ideal format, because we could pass a color variable into that at runtime and support all the themes in one go, assuming the SVG was comparable in size to a PNG (it was!).

However, using a raster image for this is problematic because GitHub supports a handful of color themes, and we'd need to create separate sprite sheets for all of those themes by hand and users would have to load them all. Not great!.