Make Your Pull Requests Visual
For Front-End Changes ✨
If you’re a front-end dev like me, you’ll often find yourself making pull requests that have visual changes. I wanted to share something that I’ve started doing at work that has been helpful in getting my pull requests approved.
The idea is simple, but I will add a few tips and tricks to help you take it to the next level!
The basic idea is to add screenshots and screen recordings for any visual changes. They make the job for the reviewers much easier since they can visually see what’s been changed instantly.
- Jing — for static screenshots (With Chrome 59, you can now take a full-page screenshot.)
- Recordit — for animated GIFs (other alternatives: GIPHY Capture or Kap)
I like to show the before and after visual diffs.
Take a screenshot of the before and after, and add it to your PR like so:
Jing has a capture hotkey that you can set to launch the capture mode using keyboard shortcuts. Use the hotkey, and your co-workers will be asking how you capture things so fast!
Then, add some arrows to point out the differences or areas to focus on. You can even use the text tool to add some quick notes.
To show UI interaction, I like to use Recordit to record an animated GIF. And if the component you’re building has various states, record all the variations!
Right after you record a video, Recordit will take a few seconds to process, and you’ll see a toast message/notification in the top right corner that looks like this:
Click on it to get the animated GIF. If you missed the toast message/notification, you can also get the link to the GIF from the settings menu:
But instead of adding a link to the GIF in your PR, I’d recommend downloading the animated GIF and adding it so that it shows up inline. It’s so nice when someone can see the animation right away without having to click.
Get your visuals in front of your reviewers’ faces right away always!
I even go as far as using screenshots to show console warnings if I have a PR that remove those warnings. You can get visual in many ways.
I know what you’re thinking. This is too time consuming. However, I can’t tell you how many times I’ve been trying to screen record my “finished” work and caught bugs alongs the way. Why? Because trying to capture what you’ve done, including all the various states, will slow you down and make you QA your work indirectly.
Another great thing: in case someone else comes along and breaks something, you have proof of the way it worked before as a reference!
At Grovo, we add our designers to pull requests for front-end changes. They can often spot visual quirks, as well as typos, earlier in the process thanks to our screenshots and screen recordings.
- Add screenshots with a before and after diff;
- Call out areas of focus with arrows and text boxes;
- Add screen recordings (animated GIFs) to show UI interaction of all the various states;
- Have your visuals inline, so they can be viewed instantly.
Try it out, and let me know how it goes!