I'm Matthew Setter. I'm a security researcher, privacy advocate, and a software engineer. I’ve been developing software since 2000. This blog is focused on helping you write more secure software and protect your online privacy.
How To Prepare an Online Training EnvironmentScreencasting July 28th, 2015
Thinking of becoming a PluralSight Author? Considering creating online training videos and screencasts to share your experience with others? Make it easy on yourself by knowing how to setup a consistent environment.
Well, it’s safe to announce that, after passing the audition, I have a course proposal being reviewed and am looking, very much, forward to producing my first course for PluralSight, and becoming a PluralSight author.
Without giving too much away, if you’re at all interested in interacting with databases in a simple, effective, and manageable way – watch this space.
So today I thought it important to talk a bit about how to set up the training environment which I’ll use to produce the course. There’s a couple of reasons for that, with the prime one being efficiency.
It’s said on average that you can spend anywhere from 1 – 3 days per viewing hour. Now that might seem like a lot, but when you consider the following, it all really adds up.
- Designing the course; including mapping out all the modules, the order in which they’ll go, what should come before and after, how long you should and shouldn’t spend on each section
- What requirements and prerequisites the student will need
- What tools they’ll need
- Which tools I’ll need
I think at times all these little things get easily overlooked. Oh, and I’ve not yet covered actually creating the course, or post-production, which can take an eternity in itself.
Given that there’s so many moving parts, it’s important to have a production environment which is extremely conducive to creating content as quickly as possible, when the time comes to doing so.
So if you’re considering becoming a PluralSight author, or just producing a screencast, training video, even podcast on your own, today’s post should be a good stepping stone in the right direction as to what you’ll need to do to ensure you can do it and know that it will be consistent every time.
The worst thing that you want to encounter is inconsistency across your created content. It makes you look unprofessional or inattentive, and it can really put people off.
Whilst perhaps not always obviously, it can distract the viewer’s attention from the course content, to the intermittent changes going on in the environment.
My personal belief is that your tools and environment should be, almost, invisible. They, like an operating system. They shouldn’t be front and centre, unless they’re what’s being taught.
So today I’m going to show you the basics of how my environment’s setup for recording screencasts and courses for PluralSight (and others). In essence, there’s four key things to get right. These are:
- Everything full-screened
- Font size
Now this might not seem like a lot, but I focus on the essentials. Let’s start at the top.
No matter what operating system you use, whether it’s a Mac like myself, Linux, or Windows, having everything full-screened reduces the load on you, and makes it almost trivial to keep a consistent environment.
Sure, you can get tools such as Bartender for Mac, with which you can specify what appears in your toolbar. You can remove some or all icons. You can hide your name, the clock, the networking icon, speaker icon and so on.
But why do that when you don’t have to. What’s more, why show something which you don’t need. If you’re working in an application, to me, it makes sense to full-screen that application, so the user sees just what they need to.
OK, there are valid reasons to show more of your desktop. Perhaps your username is branded, or you want the user to be subtly reminded of your name.
To be fair, this would make it that bit harder to have your content ripped off and uploaded by someone else – which happened to me once on my Zend Framework course for Learnable.
But then you can also put a floating watermark across your content too, which helps alleviate that issue. OK, I’m a bit of a minimalist at heart (more so with each passing year). What’s more, I think I’m either a bit lazy, or just don’t like to do more than is necessary.
So to me, full-screening the app in use just makes sense. Let’s say you haven’t gone full screen and you have to do some editing, because you forgot something, or left something out.
Let’s say there was an icon present, such as Dropbox, and it was syncing. Or let’s say the clock was visible. Assuming that you have to edit content part way through, do you think it’s going to look strange if the clock time changes momentarily, or the Dropbox icon changes momentarily and then changes back?
Do you think someone might notice that, even if you haven’t? It’s little things like that which are important to me, which can make editing unnecessarily difficult. So don’t have them in the first place, and you don’t have the hassle of dealing with them.
Now let’s get to my favourite one – font size. When I first started creating screencasts, I totally overlooked this one. I created what I thought was great content, and people did give positive reviews about them.
However, whilst they enjoyed what they heard, on anything but a big desktop screen, say an iPhone or tablet, the commands and code became almost unreadable; especially if someone was on a bumpy train ride. So absolutely do not over look this!
Now I don’t have a hard an fast rule on what the best font size is. I’m no typography expert. And I believe that the best size does vary depending on the font you’re using. But at a minimum, if you do nothing else, make sure your font size is a minimum of 20pt.
Take a look at the code in the PHPStorm screenshot above, or the Mac Terminal screenshot further down. Are they easy to read, trivial even? Do you have to concentrate in any way to see what’s on the screen? Arguably, no!
So make sure the font size is at least 20 pt – but make sure to play around with it, based on what you’re doing, and find the right balance. Depending on the topic which you’re covering, it might be different each time, or it might be the same, if you and your viewers are happy with it.
Now fonts. There are so many and varied types. Some are beautiful, visually appealing, well spaced and balanced, dare I say even graceful. And some are just downright hideous, and should never have seen the light of day.
I’m not going to get in to a discussion about which is which. Suffice to say that it’s important when creating online content, that you pick a font which works, and which is easy to consume in that medium.
As I create technical content, I’ll stick to what I know. I’ll leave other topics to their respective subject matter experts. But for code, I encourage you to go with fonts which are commonly used by developers.
Partly because they’re the fonts they’re going to encounter and use most often. How many of us often change the default editor or IDE font? Secondly, they’re almost perfect for reading on a screen – hence why they’re chosen for the industry which spends so much time behind a screen.
The final point of the three is colour. Just like fonts, some colours work, and some don’t. Did you know that the majority of people have some form or level of eye deficiency? Did you know that people with “perfect” vision are actually in the minority?
No? Well you do now, and you should always keep that in mind. So when you’re choosing a colour palette for your editor or IDE, make sure it’s one which is easy to read.
These two, Railscasts especially, provide excellent contrast between foreground and background, as well as excellent colour choices for variables, keywords, constructs, and so on.
Your IDE likely has these two, amongst a range of others built-in and will make it easy to change between them. So take the time to have a look at the ones on offer and test them out.
If your IDE doesn’t come with them, then more than likely you can download them, likely from GitHub or somewhere else.
Environment Defaults & Custom Profiles
Now whether you’re using an editor, such as VIM, or a full-blown IDE, such as PHPStorm, take the time to either create a custom theme, or to customise an existing one.
You could even go so far as to create a specific user for content creation. I have, but have found some drawbacks with that approach, which I’ll detail another day.
As you’ll likely be creating screencasts in addition to your normal software development work, by creating a custom profile, you’ll be able to ensure that when the time comes to record content, that your environment is just like it was every other time.
It will also allow you to create code outside of screencast using a font which doesn’t make you want to sit on the other side of the room. You can see in the screenshot above, that I’ve customised the Solarized Dark theme, which I added to PHPStorm.
Most of the options are the same, but the font size is increased, as is the line spacing. When I go back to normal coding, I just change it back to the default Solarized Dark. No muss, no fuss.
PHPStorm or MacVim
Now that font sizing, colours and so on are out of the way, it’s time to look at tooling. For some time I’ve created content using VIM, specifically MacVIM. But recently I’ve been thinking that I should change to PHPStorm.
Perhaps I want a bit of hand holding whilst I’m coding, Perhaps it’s because it’s what I used for coding in PHP all the time. Perhaps it’s because of the intelli-sense support, so that I don’t have to remember as much.
Perhaps it’s that I’m just used to it, the keyboard shortcuts, and how it works, inside and out, that makes me so much more productive with it – which is often more important that anything else.
Whatever it is, I’ve pretty much decided to use it as my code editor. But what’s really cool about it is that it has an option called Presentation Mode, which you can find under the
When enabled, PHPStorm goes full-screen and you see nothing but glorious code – nothing else, with a modest amount of padding on either side. Using this mode, you know that absolutely nothing is going to distract from the main task of what’s being taught.
So all the functionality which it offers, along with a custom setup, and I’m ready to create content. What’s more, it’s got a built-in database plugin. A lot of the content which I create when using PHPStorm makes use of a database, so it’s damn handy not to have to change between too many tools.
What’s more, when you’re creating SQL examples, there’s some great intelli-sense style prompting for tables and columns, making SQL that much easier to write.
Now whilst PHPStorm’s great, I don’t use the terminal component much. It’s not that it’s bad, but I don’t feel that it’s a fully fleshed out terminal. So why use a tool that does a lot of what you’re after, but not everything? Especially when the Mac Terminal does it all.
Having said that, I’m considering switching to iTerm 2. Having a complete terminal makes it easy. There’s all kinds of reasons to use a terminal including:
- Displaying directories and directory trees
- Running commands
- Piping multiple commands one through another
- Grepping content
- Parsing files and more
So it makes sense to have the tool which is up to the task, and not have to mess around with multiple. Like PHPStorm, when I’m using it, it always goes full screen and it also has a customised theme.
You can see in the screenshot below that I’ve created a custom theme, which also uses the Solarized Dark theme. One point I’m pushing through the post here is consistency and lack of distraction.
As such, it makes sense to be as seamless for the viewer as possible. That’s why I use the same theme, as much as possible, across all applications I use.
I’m aiming to both reduce cognitive load and distraction for the user, so that they can focus as much as possible on learning. One or two things worth noting are that the cursor is a block, yet doesn’t blink.
I picked this up from Avdi Grimm’s Ruby Tapas screencasts. It caught my by surprise at first, but he does that as well. As well as making editing and post-production much simpler, it was a further step which reduced distraction in the content created.
And that’s the what, how, and why of my screencast setup, both for PluralSight, and for all the other content which I create.
I hope that you got something out of it and will create an environment for yourself which both minimises the effort involved to create and produce content, as well as reduces the distractions for the user, so that they both can learn as effortlessly as possible, as well as build up the perception of you as one of the best trainers around, an all-round consummate professional.
If you want any further information which I’ve not included, add a comment and I’ll do my best to get it to you.
Join the Email List
If you enjoyed this post, why not join the email list and get all future posts straight to your inbox? In addition, you'll get background information, extra research, and other content that's only available on the list. I promise I'll NEVER spam you. And you can unsubscribe at any time.