YouTube Videos for Online Help

Replacing user manuals with online video tutorials

Recently I’ve been investigating the pros and cons of using online video tutorials instead of traditional written user manuals. The main driving force behind this exploration is reducing the amount of time spent creating documentation.

As an example, this is a demonstration video I created for a new component to my CMS:

http://www.youtube.com/watch?v=LYRn9-zhyhk

The voice you hear in the video isn’t mine, it was produced using text-to-speech software called TextAloud. The screen recording was made with CamStudio (SnapZ is a good choice for Mac users). And finally, Microsoft MovieMaker was used to insert the audio track into the video.

Before making the screen recording, I created a script to feed to the text-to-speech software, this took about 30 minutes to prepare. Using a script as opposed to just ‘winging it’ has the potential to save a lot of time since the recording doesn’t need to be restarted when there are spoken errors (e.g. umms and ahhs).

The majority of this article is taken up by two large bullet lists. The first describes what’s good about using YouTube for video help, and as you would expect, the second list points out the short-comings of hosting your demo videos on YouTube.

The advantages of using online tutorial videos:

• It's faster than writing a user manual (which many people don’t read anyway).
• It appeals to peoples’ inherent laziness. You simply can't make it any easier for a person, they just sit back, relax, and watch.
• It can communicate some ideas more effectively than written documentation. As the saying goes, a picture is worth a thousand words.
• It’s quick to update. A new video can easily be uploaded if the software changes.
• No hosting or disk space is required since the video resides on YouTube’s server.
• YouTube streams video very fast.
• It doesn't require that a user have a particular CODEC installed on their computer (e.g. DivX, XviD, RealMedia, etc).
• There is a degree of familiarity. People are comfortable with YouTube, they know how it works (nb. this is known as affordance in usability circles).
• YouTube now supports high definition video. Previously, videos were so compressed you couldn't make out text or UI elements (nb. adding &fmt=18 at the end of a YouTube URL will trigger high quality video playback).
• On projects with tight budgets or looming deadlines, very little time may be allocated towards user documentation. Video tutorials can be a real life-saver here.
• Great for introductions (i.e. to quickly show a new user how something looks or works).
• Video is better at conveying GUI interactions compared to written documentation (e.g. in video, the mouse would just move to a save button and click it vs a document saying something like ‘click the save button at the bottom of the screen when ready’).
• Many people prefer video tutorials to written documentation.
• Video tutorials are great for ‘how-to’ type demonstrations
• Using a script with text-to-speech software can be very helpful for those who have English as a second language.
• In a video demonstration, steps in a process can’t be missed (i.e. if the author forgets something, it will be apparent very quickly).
• There are no spelling or grammar errors.
• You don't need a second person for proof reading.
• Spoken word can convey subtle nuances which are missing in written documentation (e.g. tone of voice can communicate things such as enthusiasm, etc)

The disadvantages of using online tutorial videos:

• Video is not as effective for explaining detailed usage (e.g. coding syntax).
• You can’t skip pages or jump to a particular section you may be interested in.
• You can’t copy and paste code snippets or text from a video.
• You can’t slowly re-read something until you ‘get it’.
• Unlike a user manual in PDF, video cannot be printed.
• Hosting videos on YouTube may be viewed as unprofessional or have a ‘hobby’ feel to it.
• Using text-to-speech software vs a human voice may sound boring to a user.
• The YouTube website may be blocked at some companies if its viewed as an entertainment website.
• Some people believe a written manual is somehow more serious then a video (i.e. video is ancillary or a gimmick).
• Most people lack the ability to produce videos with credible production values.
• We generally have far better written skills then video production ability.
• YouTube is starting to display ads at the beginning of some videos.
• Many people like written documentation in addition to video tutorials (i.e. they wont accept videos as a substitute for a user manual).
• You can’t search through a video for a keyword like you can with a PDF.
• YouTube videos cannot easily be downloaded. This can be an issue for people with slow internet connections (legend has it some people are still using dial-up!)
• Making training videos publically accessible may pose intellectual property rights issues.
• Accessibility - deaf people can’t hear the audio track of a video.
• Poorly spoken dialogue can severely tarnish the perceived quality of a video.
• Dialogue which is spoken too slowly can be annoying to a viewer.

One of the biggest dangers of using video for online help is producing something which is amateurish. The screen recording isn’t the problem, it’s the audio track. Assuming text-to-speech software isn’t being used, multiple takes will probably be necessary, as well as some adjustments in a sound editing software like CoolEdit to remove umms and ahhs.

As good as YouTube is for hosting videos, it does have some drawbacks (e.g. ads). This can be avoided by using alternate services like Vimeo or Screencast, embedding the YouTube video on your own website, or using a Flash video player like JW FLV Media Player. However, the time savings gained by using video tutorials instead of writing a document can quickly be wasted by fiddling with technology.

When using video tutorials, its important to consider peoples’ learning preferences; some people learn better via visual and auditory cues, others absorb information more effectively by reading. This hurdle can be overcome by providing a transcript of the video. The transcript can also be used to produce sub-titles which solve a number of problems (e.g. helpful to listeners who are hearing impaired or struggle understanding spoken English).

Video tutorials are simply another way of conveying information. They have some advantages over written text, but its a trade-off between such things as being able to cut and paste from a digital file (which you can’t do with a regular book anyway), vs communicating information with sight and sound.

Creating Storyboards for Flash Animations

Fleshing out the sequence of an animation using a storyboard and MS Word.

Why would a project manager or business analyst need to know how to create a storyboard for a Flash animation? You could argue that this is the dominion of a graphic designer or animator, and you would be right. But using storyboards is an effective method for determining the cost of an animation, and certainly budgeting considerations are a responsibility of a project manager.

To begin with, we should have some kind of definition of what a storyboard is. At the most basic level, a storyboard is a series of pictures which map out the sequence of a movie or animation. It’s widely accepted that a functional specification should be produced before any coding occurs, so why wouldn’t you use some form of planning process prior to creating a Flash animation?

Before you say “but I can’t draw. Last time I drew a stick figure, people thought it was a potato”, you need not worry. Artistic skill isn’t as important as you may think, sequence is of greater significance (e.g. first, many camera flashes go off, then the limousine drives up, etc).

The format I use for a storyboard is very basic. This is intentional since it needs to be understood by both graphic designers and clients.

The structure is as follows:

Document Purpose - this is for the benefit of anyone picking up the document for the first time. It’s a brief statement of what the document is about. For example; this document presents a storyboard for the animation appearing on the Blue Widgets website. The idea is to present a series of illustrations in order to help visualize the sequence of the interactive animation.

The Animation - this is where you say what is going to happen in the animation, and in what order. It’s also where the ‘illustration panels’ appear, nothing fancy is required, its enough to put in labeled squares or circles (e.g. a circle with 'client logo' in it, the text 'tag-line', a box with 'button 1' in it, etc).

Below the illustration panel will be a series of bullet points. These describe what is happening in this particular portion of the animation. This is why you label the shapes in the panel, so you have something to refer back to, for instance; ‘the client logo will fade-in gradually’, or ‘the bouncy ball will move across the screen from left to right’.



The bullet points are where the real detail goes, hence why artistic skills aren’t such a big requirement for this style of storyboard (leave the artistic stuff to the experts). The more detail that goes in here the better. You want to make statements about what happens when the user interacts with particular elements of the animation (e.g. when the user places their mouse over the client logo, a yellow glow appears around it and a pleasant chime sound plays once). Timing, or saying how long things will go for is important here (e.g. the slogan text will fade-in over a period of 1.5 seconds). This is also a good place to specify what images, URLs or text will be used on the panel (e.g. when the user clicks the client logo, they will be taken to index.aspx).

As the saying goes, ‘the devil is in the detail’, and this is where the bullet points come in handy, they serve as an important tool for clarifying what the animation is really meant to be. The bullet points are designed to generate discussion (e.g. client: “we don’t want a male model in our banner, our target market is female, they’re the ones that tend to buy our lipstick”).

Don’t forget to say what the state of the animation will be when it first loads up, will there be a progress metre because the animation is expected to be large? What will the initial banner image be? Will any buttons be highlighted by default?

Appendix - this is the last section of the storyboard document. It can contain anything else which you think needs to be documented (e.g. screenshots, mockups, JPEGs to be used for reference purposes, etc). The two standard sections I place in the Appendix are: Support Files, and Technical Notes / Non-requirements. The Support Files section is actually a ZIP archive embedded within the MS Word document. The ZIP file contains any relevant graphics files intended to be used with the animation. The benefit of packaging these files together is that the most up-to-date graphics travel with the storyboard document itself. This is especially helpful when the document needs to be emailed to off-site contractors. Of course, this only works if the ZIP archive is below 2-3 MB in size.

The Technical Notes / Non-requirements section is where you say what you’re not going to do. For instance; there will be no sound-effects or music used with the animation, no special effects will be used within the animation other then fade-in/fade-out, the animation will run for no longer then 30 seconds. In addition, you may want to give specific instructions which are relevant only to the Flash developer, such as: the completed animation should be no more then 1 MB in size, all text appearing in the animation should be retrieved from a XML file, etc.

A big part of creating a storyboard is helping a client translate what’s in their head into something more tangible. Failing to do so could result in an iterative cycle which is not only costly, but unnecessarily time consuming.