How I Set Up VSCode For Recording a Screencast

In the spring of 2020, I joined egghead as an instructor where I publish video lessons on various front-end web development topics. This short tutorial is focused on my setup process of recording a coding screencast.

Egghead has a particular method of recording screencasts which you should also check out for some very good tips if you're brand new to screencasting.

VSCode Settings

There are a few parts to setting up VSCode. To make it easier from one lesson to the next, I recommend creating a base project that you re-use. The main reason is that we'll be creating workspace settings, including disabling certain extensions.

VSCode Workspace Settings

An important part of setting up for a screencast is ensuring viewers can easily see what you're typing!

If you don't have a workspace settings file already created, you can add one at the root of your project by creating the directory .vscode and the file settings.json.

Here are my recommended essential settings for screencasts:

{
  "editor.fontSize": 14,
  "editor.lineHeight": 22,
  "window.zoomLevel": 4,
  "editor.formatOnSave": false,
  "editor.lineNumbers":"off",
  "editor.quickSuggestionsDelay": 1500,
  "editor.hover.enabled": false,
  "gitlens.mode.active": "zen",
  "breadcrumbs.enabled": false,
  "workbench.activityBar.visible": false,
  "workbench.statusBar.visible": false,
}

The first three work together to adjust the font size. You may choose to set a higher value for fontSize and lineHeight and perhaps not set the zoomLevel. The reason I am setting all three is because zoomLevel also impacts the panel text, such as the Folders, and occasionally I need to show how that is setup as well.

Here is a screenshot to show relative sizing with these settings:

Pit stop to say my current theme is Apollo Midnight. While we all have our preferences, for screencasting it is recommended to choose a high-contrast theme in consideration of accessibility.

Next, if you typically use a code formatted like Prettier, you may wish to turn this off, which is the "editor.formatOnSave": false. There are two reasons I turn it off:

1. Tutorials are usually very focused on small blocks of code that aren't too difficult to keep formatted
2. When this is off, I can force certain blocks out of view to better focus on the in-progress block.

Following that, I remove line numbers just to extra reduce clutter. If I want to call attention to a line or block of code, I'll use my mouse to draw the eye, or temporarily highlight it.

While I love Intellisense in my normal code flow, it can be very distracting during tutorials (and it took me awhile to figure out how to dismiss it, so you'll see it interfering in my earlier lessons!). There are several options of how to handle hiding these popups.

My preference of setting "editor.quickSuggestionsDelay": 1500 essentially means that at my normal typing speed, Intellisense and other types of suggestion popups are not likely to appear. But, the one type I occasionally want is Emmet. So with this setting, if I wait 1500ms (1.5 seconds) I can still have Emmet access.

If you'd rather completely disable all suggestion popups, you can instead set "editor.quickSuggestions": false.

I also then disable the "hover" information popups that can be blocking for content and particularly annoying if you are doing live coding. That hover behavior is disabled with "editor.hover.enabled": false.

The next one may not be needed, but it took me a while to find the right setting so I wanted to include it. If you are a GitLens user and don't want to have to disable it for your workspace just to hide the line-by-line blame info, the setting you want is "gitlens.mode.active": "zen".

The final three settings help hide workspace clutter. If you were not familiar with the names, the activityBar is the side icon menu, and the statusBar is the message panel that by default displays across the bottom of VSCode.

If you don't normally have word wrapping turned on, you may also want to add "editor.wordWrap": "on" for your lessons to prevent line-lengths exceeding the editor width, which is reduced from the increased font size.

Additional Workspace Cleanup

One item you are not able to control via settings.json is what's visible in the sidebar. But, you can change it by clicking the "three dots" menu next to the "Explorer" title.

I tend to hide all but the "Folders" during a lesson:

And while you also can't hide the sidebar in your settings, I recommend learning the keyboard shortcut to quickly toggle it as you move through your lesson. You can also hide it via the menu under View > Appearance > Show Side Bar (click to toggle it).

Recommended Extension: Explorer Exclude

Usually there are extra files - or perhaps sensitive files - you don't want to display during your lessons.

Examples include:

• node_modules
• .gitignore
• .env
• .vscode

To allow clean up of those, install the extension Explorer Exclude which will create an additional "Hidden Items" Explorer panel where you can add files, file types, and directories to hide.

Adjust Invasive Extension Settings

There are some other extensions that may add additional clutter that you'll want remove from your lesson view. To do this, find and select the extension, and then select the dropdown next to "Disable" to select "Workspace".

For myself, I disable GitLens and stylelint.

Screen Display Settings

Now that VSCode is set up, you'll want to prepare your screen for recording.

First, it's helpful to adjust your screen resolution to a 16x9 ratio. Egghead recommends either 1280x720 or 1920x1080.

If you're on a Mac, you may need to find a utility to help make that adjustment. I use SwitchResX (small one-time purchase).

Next, I set VSCode to fullscreen. If I need the browser as well, I position it to share the minimum amount of space it needs to show the content to allow the code as much room as possible most of the time. This tends to flex both between and even during lessons since I tend to share responsive design techniques.

If I need Terminal, I only allow it into view when I'm actively using it to explain a lesson concept. And when in use, I (try to remember to) drag it up to about halfway just to help it take focus vs. the code.

Remember: The best part of screencasting is you can edit your mistakes! You can also edit transitions if you need to flip between desktops to check your reference code and notes (if you usually use only a laptop screen, like me).

I like to set up my virtual desktops on my Mac so that my reference code and notes are to the right of my main recording screen. Being consistent helps me stay in the flow as I move through my lesson but always have quick access to the reference material.

---

I hope these tips help you feel prepared to record your screencast. Drop a comment if you have other tips, or additional questions!

Be sure to check out my front-end lessons on egghead, and follow @5t3ph on Twitter for front-end web development tips and tutorials.

Comments

[devopspeedrun]

Excellent article, thanks.
May I suggest, when doing a live presentations (e.g., Zoom) it really helps to have a second computer logged in as an audience member, so you can see what your audience is seeing. Presenter view often have significant differences from what the audience is seeing.

[fiaz]

What app to take screenvideo you use?

[Stephanie Eckles]

I use Screenflow which is a little pricy but worth it if you are planning to really get into doing videos. If you're just starting and have a Mac, you can use QuickTime and edit in iMovie, which I used for my early videos.