Why planning your on-line development is important 1
Methods for breaking down and capturing your content requirements 2
What is a storyboard? 2
Developing a storyboard – storyboard templates 3
A typical storyboard template and how you would use it 4
The storyboard Code column 4
The storyboard Unit Title column 5
The Content Type column (for VLE specific storyboards) 6
The storyboard Text column 7
The storyboard Notes column 8
Storyboards – I’m still not convinced! 8
Alternative storyboarding options (not Word) 9
Which planning method to choose? 10
Why we chose Microsoft Word for storyboard template purposes 10
Closing out the storyboard phase 10
Developing content introduction 12
Resource gathering 12
Student access considerations 12
Using your storyboard to pinpoint viable development techniques 14
The Pros and Cons of VLE Content Items vs CMS stored content 15
Navigation Considerations 17
User Interface Considerations 18
Future proofing 19
Development Summary 20
Scripts for voice talents 21
Why planning your on-line development is important
Although there are many things to consider initially, a good way of focussing the tasks ahead is to begin breaking down your content requirements into smaller, more manageable units. This serves a number of purposes, particularly when developing online materials:
It starts to clearly identify the scope of the project and thus what you are potentially looking at in terms of development timescale and input requirements
It begins to shape the content into more online friendly ‘units’ and thus also begins to suggest how your resources might be structured or made navigable/accessible
It provides focus towards establishing illustrative media requirements
Provides means of establishing where additional value might be added in terms of targeting key message areas for richer media delivery or more interactive/engaging learner involvement
Enables you to pre-identify any potential difficulties likely to be faced along with the basic developmental tasks required
Creates a workable framework to better enable controlled contributions from colleagues (if the project isn’t being developed by you alone)
Provide a means to Q/A the project down to, particularly for medium or large sized projects, checking that everything required has indeed been developed
Can help to suggest where the learning experience ‘blend’ will lie if such issues have not been completely resolved (between online materials, “live”, collaborative etc)
Breaking down your content in this way is of particular value if you are providing a body of reference material that is unlikely to be “consumed”, in its entirety, at any one time. With this kind of access, and in other situations such as access expected in a non-linear fashion, the need for units of content that make sense in isolation as well as in the context of the whole is extremely important.
The simple process of breaking down and clearly documenting precisely what you intend to communicate to your target audience and how you intend to do it can also really free you from some of the more basic concerns and allow you to fully identify and attack the core of your learning message more creatively.
Methods for breaking down and capturing your content requirements
Although there are a number of ways you can break down and plan your content development we will concentrate on “storyboarding” as a proven method for the realisation of bespoke e-learning and e-learning related projects as it is of use (and can be readily adapted to) a wide variety of planning scenarios.
Even if your project scope is small and the content doesn’t need to be heavily broken down, storyboarding can still be a worthwhile pre-development process helping to ensure that your goals are not only described and identified but also achievable.
What is a storyboard?
A storyboard is, very broadly and within our e-learning frame of reference, a document (digital or otherwise) describing as clearly as possible what you eventually intend to have up “on-screen” in the digital environment but which can also include the necessary “hook” information for how you relate online materials to class based learning
NOTE: Pedagogic models for delivering blended learning are considered more specifically and more thoroughly in the Blended Learning Workshop and its associated workshop materials (have a look at Yorkshare HQ (http://vlesupport.york.ac.uk) on the Training tab).
Storyboarding of digital projects is not dissimilar to storyboarding in the world of film and TV and effectively serves the same purpose. In the cinematic world, a complex scene or shot can be difficult to shoot and usually requires the coordination of a number of people; if it has been planned using a storyboard the potential for problems to occur (technical, time, safety, confusion or cost etc) can be significantly mitigated.
At all stages of development it is important to think of the storyboard as a “working” document; as such the storyboard should be regarded as a strong, though not absolute guideline to attaining the desired end result.
To further clarify, situations will arise where attempting implementation of what was originally thought to be a sound way of getting across a message might not work (for pedagogic or technical reasons for example) or, in a more positive vein, the attempted development of the unit might throw up an even more creative way of communicating the message. In these circumstances you should, of course, adjust your production to reflect these findings rather than sticking slavishly to the storyboard.
Developing a storyboard – storyboard templates
A storyboard will usually include a number of codifying elements. These are commonly (but not limited to):
A unique identifying code for each content unit
A title for each unit (a ‘readable’ identifier)
The body of text, narrative transcription or message that forms the “backbone” of the unit
A notes section for each unit. This is generally used for production notes such as pointers to reference sources or messages/queries to other collaborators etc.
This may sound obvious but it is important to note that the template you use to storyboard your project should reflect the needs of your project (see further above, the illustration showing a page from two different storyboards).
Don’t try and shoe-horn your content break-down into a storyboarding template that doesn’t quite work for how you are thinking about the structure and resources needed to complete your project. Doing so could result in an awkward or unintuitive content delivery for your students at the end of the day.
A typical storyboard template and how you would use it
The storyboard Code column
What do I use it for?
The Code column is used to create a unique identifier for the units of your project.
Creating a unique “code” for a module is a basic practical consideration and is broadly the easiest way of ensuring that everybody involved in a project (including you) can immediately track developed materials back to the correct unit of the storyboard.
“Why not use the readable title for this?” is the obvious question you are asking. One of the main uses the unique code can be put to is the prefixing of files pertaining to a unit as they are developed (including the development folders you might employ to construct each content unit within).
It’s with this use in mind that we might include an abbreviation in the code as it forms a useful cue to you (and your team) as to what project and where in a project a file might have originated from (such as PAM in the Pure and Applied Microbiology example).
TIP: Always number your projects by inclusion of a leading zero (or zeroes) for lower numbers to ensure alpha-numeric file lists are in the right order; for example 01-01 rather than 1-1. You’ll be thankful of this advice later, particularly if you end up developing a project that incorporates a large number of separate files.
If your project is small scale or the level of new resource development not expansive then you might not need such an identifier and could dispense with this element in a storyboard.
A clear advantage (along with traceability and readability) of this kind of identification measure is that it makes it much more difficult to inadvertently generate duplicate filenames and also allows collaborators to seamlessly integrate their materials in the overall project without fear of materials being overwritten (assuming that you clearly assign development tasks, perhaps by having people contribute to different units of the project as delineated in the storyboard).
Perhaps the most significant advantage of using an identifier in file names is that this kind of naming structure renders the project files transparent to all collaborators making it very easy for all contributors to find and perhaps amend or replace files that they may not be the originator of.
The Unit Title column is used, as the name would suggest, for the readable title of the content unit and is likely to be the title that you will employ within the finished project.
Aside from this obvious use, particularly if your delivery uses a reasonable amount of text content, the titles of your content units can often be used for helping to decide navigation and you can copy and paste text directly from the storyboard for titling items in your VLE (Yorkshare) module.
The Content Type column (for VLE specific storyboards)
What do I use it for?
The Content Type column is used as an indication of the type of content or tool that you think the item will be best made available as. To keep the column narrow it can be a good idea to use an abbreviation pertaining directly to the VLE. A suggested set of VLE specific abbreviations are:
Key to CT (Content Type) abbreviations:
Left Menu Item
Sentient Resource List
Thinking about Content Type at an early stage can be a good way of beginning to get a handle on your actual file development requirements. For example: Are you going to put information directly into VLE Content Items or link to Word or PDF files instead? Developing a storyboard forces you to ask yourself these questions and consider the pros and cons of each as you move forward.
It can also be an indicator for where you might need to up-skill on particular aspects of VLE or software use and thus allow you to target training before your project gets going.
NOTE: If you don’t want to remember a series of abbreviations just use the full name of the content type or tool you think might be the best choice.
If a content unit is going to be delivered as a Word file then just put Word or DOC in the Content Type column for example.
The storyboard Text column
What do I use it for?
The Text column is used for the actual text/narrative/description of the information you intend to communicate via the unit.
If your unit does involve a lot of textual content then this part of the storyboard is, of course, fairly self explanatory. It should be noted, however, that highly interactive content or even simulation will still require on-screen information even if it is only for the purposes of indicating what the end-user has to do. In the case of interactive content it might be that information is only released dependent on user driven events. In all circumstances it is a good idea to have these text/informational requirements identified and written down.
Even if you intend to make use of audio you will still need a text transcript of this for use by a voice-talent and also for accessibility reasons.
The text of your storyboard can, importantly, be copied and pasted into the VLE or content itself so you aren’t duplicating or typing out text unnecessarily.
The storyboard Notes column
What do I use it for?
The Notes column is for explanatory notes, production comments and other associated information.
This part of the storyboard is of particular use when working on a collaborative project and can be employed to further explain thought processes, logic or ideas pertaining to a unit as well as indicating where links to class based learning can be made and explored.
It can also be employed when indicating responsibilities for specific content units (by inclusion of contributor’s names for instance) and is perfect for team members to enter feedback or observations within during storyboard development, perhaps on each others entries or amendments.
Other uses can be the inclusion of reference pointers such as web-sites or books etc and also suggestions as to delivery technologies.
Storyboards – I’m still not convinced!
On the surface of it, developing a storyboard might seem like a lot of unnecessary work and, for small projects or projects that are possibly already in a form reminiscent of a storyboard, this might actually be the case. It’s up to you to make that kind of judgement call.
When you are considering such a call, however, you should keep in mind that even for small projects, particularly ones involving a team of collaborators, a storyboard can help prevent a chaotic and uncontrolled content development process. Indeed, speaking from past experience, at least some form of working storyboard is really a “must have” to ensure the development of a successful deployment, in a controlled manner with clearly defined development milestones and achievable deliverables.
If you are new to the development of online resources and thus unfamiliar with the difficulties that can be faced during the development process it can’t be stressed enough how useful the storyboard process can be in focussing your thoughts while providing you with a logical and practical start point for your project.
For those new to the development of a VLE module a storyboard can, for some of the hidden pit falls commonly faced by less experienced developers, help prevent:
Unconsidered use of content areas and tools
Poor module structure and an unintuitive student view
An unsustainable or chaotic CMS hierarchy
Re-work or re-structuring of the module or module content through developing yourself into a corner
Unconsidered blend with class based learning
Over ambitious development goals
Leaving certain tasks until too late (copyright permissions, training etc)
This is only a limited list of the problems that could be averted by even a small amount of planning.
Alternative storyboarding options (not Word)
Although we are suggesting that storyboarding is a useful way forward when developing an online project you don’t, of course, have to stick to a Microsoft Word template for creation of your storyboard.
If you are more comfortable writing and/or sketching your ideas it can be useful to create a blank page template, print it out and then photocopy your print as a master page before using the blank pages to actually write and sketch on for the purposes of creating a working storyboard document.
It is, in fact, often a good idea to actually print out an entirely digitally developed storyboard; particularly when running it by colleagues for comment, proofing or approval. Collaborators can easily contribute to the development by simply writing their thoughts on the storyboard document (using the Notes column for example) rather than perhaps amending a protected version of the document.
Often people find marking up/reading printed materials a more natural process than editing digital documents.
Another software based alternative to the Microsoft Word template is to use Microsoft PowerPoint for storyboard creation and, for text and image based projects in particular, it can provide more of a “what you see is what you get” or WYSIWYG (WizzyWig as it’s known) storyboard.
You can use the following PowerPoint features to cover storyboarding areas:
The Slide Numbers can act as your unique identifier for each unit
The Slide Title field can be used as your readable title for the unit
The Slide Notes area can be used for your main text or narrative transcript.
The actual slide area itself can be used for pasting in reference or for using bullets to describe what you intend to implement in the deployed online course.
You can also configure print-out of PowerPoint files to include a representation of the slide and also the notes field.
Which planning method to choose?
The most important thing is to use a technique for pre-production outline and scoping of your project that you (and your team) are most comfortable with.
If you do go down the route of using a storyboard then also do this in a fashion you are most comfortable with. If you prefer getting out a pencil then print off blank template sheets and then fill it in by hand. If you have no problem developing your storyboard digitally then use a method which works best for you be it Word, PowerPoint, Microsoft Project, Excel or otherwise.
If you choose NOT to create a storyboard then try and make sure you DO fully consider the practicalities of expediting your project in order to keep control of the development and to ensure that you do achieve your goals. Don’t underestimate the need to do at least a small amount of planning; developing an online aspect to your teaching WILL take more time than you think to do it well.
Why we chose Microsoft Word for storyboard template purposes
There are a number of reasons we have chosen Word for our Storyboard template (over perhaps PowerPoint for instance) and these are broadly as follows:
Word is widely available within the University
It is fairly easy to get to grips with and start using immediately
Provides in-built change tracking and comments features
Has in-built grammar and spell checking
Has in-built style creation and management and styles can be used that correspond directly to HTML styles (for controlled direct extraction of text from the storyboard for pasting into the VLE)
Closing out the storyboard phase
Once you have developed your storyboard, run it by all your collaborators and received and integrated all relevant feedback and amendments you should be in possession of a document that adequately defines the intended scope of work as a theoretic realisation of what you intend to deliver.
From this it is a much easier task to achieve the following through analysis of the storyboard document:
If in a team you can more easily agree responsibilities for different content units
Provides a platform for enabling consistent input from all contributors in terms of style and formatting for resources
You can identify development milestones based on the time-frame allowed for the project and also actually ascertain whether the project is indeed achievable and, if not, where the storyboard can be “reigned in” to make the project deliverable within time-frame/cost limitations
You can action any third party providers where required (such as for video, audio or document digitisation)
You can begin processes required for specialised content identified by the storyboard (such as gaining permissions for copyright protected material or purchasing of content licenses)
..and finally you can, of course, begin the development phase of your project in earnest
With an “agreed” working storyboard in hand you should be able to much more confidently move into full development of your module and with a degree more efficiency than if you simply started developing ad-hoc.
Although we can’t possibly cover all the potential techniques or issues that will come into play during full production of your content we will try and, at least briefly, cover issues you will need to take into consideration when moving into the production phase of your project.
We will also, again fairly briefly for scope reasons, cover some of the tools that are widely available to you (through use of University hardware and software) for the creation of online deliverable content and what to bear in mind when using them.
Taking the above into account we can, however, cover an area of known commodity in a little more detail; developing content in the VLE.
If you have established or identified the need to use some existing materials within your storyboard or planning it thus follows that you can immediately begin gathering any identified pre-existent resources together (resources that do not need creating from scratch). This process might involve:
Sourcing printed media for the purpose of scanning (books, magazines, journals etc)
Sourcing any pre-existing visual media that you may need to scan (traditionally printed photographs, hand illustrated content)
Sourcing the master tapes for any analogue recorded video footage that you may want to use digitally (or video files if the existing footage was shot digitally)
For any pre-existing audio you will need to source as good a quality master as you can to create digital clips from
If you are using a voice talent for audio narration you will need to extrapolate and format a “reading” script from your storyboard and perhaps source a third party vendor for the purposes of recording the voice (especially if you require professional sounding results).
Locate/source any pre-existent digital materials that you wish to use in your deployment
Note that some of the above tasks may need to involve engagement of a third party such as for digitisation services (for video, scanning, audio etc.).
IMPORTANT NOTE: You must be aware that you cannot deploy copyrighted or licensed materials without first clarifying whether you are allowed to use the material and, in using it, how the material needs to be credited or even paid for. You cannot, for example, find a suitable image on the internet, save it and then employ it in your project without first establishing whether the image is in the public domain and subsequently, in the likely case that it isn’t, obtaining permission from the copyright owner to use the image.
A guide to copyright issues, incorporating a checklist approach to identifying concerns, is provided at Yorkshare HQ (http://vlesupport.york.ac.uk) on the Training tab..
Student access considerations
The way in which your deployment is accessed should be analysed thoroughly before you begin development in order to avoid the potential for limiting its usability or accessibility for some of your target audience.
The key question to adequately answer, and one that can be pivotal when considering what techniques you intend to employ during production, is; what is the lowest common denominator, in terms of access, for your target audience?
This question will need answering by profiling your students to establish where, when and through what kind of hardware and software people are likely to access your resource. This will need to take into account:
Connection speed. Will everybody be using a 1MB or greater connection or are some people likely to connect with a 56K modem.
Hardware/Software limitations. Will there be people using older and slower computers? Will people be using a variety of operating systems?
Browsers. Will everyone be connecting to the VLE with Internet Explorer or will people be using other browsers (Netscape, Opera, Firefox, Safari etc)?
Will any special browser plug-ins or applications be required for an end-user to engage with content and if so could it potentially limit access for some users.
NOTE: To offset some of these considerations you could take a specific stance and assume or assert that access is going to be entirely from campus machines and then warn students during their induction that some materials (if you are deploying bandwidth hungry rich media such as video clips) won’t be suitable for consumption using 56K modem dial-up internet access.
In taking such a stance you should know that evidence thus far has been that students WILL access VLE modules off-campus because they can and it is convenient. Take into account that, at York, students are likely to be on-campus in their first year but not thereafter.
Also note that module usability, even on fast connections, can be significantly improved by properly considering how you are going to deploy such things as video clips. Ask yourself such questions as “Can my lengthy video clip be broken down into a number of smaller discrete sections?” . Chunking video in such a way would make its access friendlier to everybody and not just those on slower connections.
Other issues such as the time-zone of students may also need to be taken into consideration, particularly if a part of your module site plans to take advantage of synchronous collaboration and you are delivering distance learning.
Once the answers to these issues have been distilled down to a lowest common denominator you can use the resultant findings to better inform your choices for production. For example:
Users on slow connections are unlikely to receive a good learning experience if use of bandwidth heavy media types is employed or even if the content is divided up in such a way that a lot of smaller media needs to download simultaneously for one content item.
Older computers might be slow to process real-time data; simulations or complex Flash animations for example.
Content delivery you might be able to achieve with Internet Explorer may not be rendered similarly in Firefox, Safari, Netscape or Opera etc.
When considering how to approach these issues you don’t necessarily need to compromise the learning experience for all of your users, in terms of its “richness”, in favour of catering for what might be a minority; because we are in the digital realm you can provide alternatives for those with access limitations (which might include those with personal disability). Considering providing alternatives can result in all of your users receiving the right delivery for them rather than a compromise that works for all but not as well.
It might be that time constraints will mean alternative deliveries can’t realistically be produced. In this scenario, understanding the potential access limitations of your target audience will help you establish a solution for developing an achievable and successful module that is fit for purpose across the widest cross section of student needs possible.
Using your storyboard to pinpoint viable development techniques
Although because you will most likely intend to upload content in to the Content Management System (CMS) of the VLE, it might seem that your choice of delivery formats is an obvious one (i.e. HTML web-pages or PDFs etc.) there are still issues to keep in mind and questions to ask yourself when deciding on your base format and how to develop your resource. Again, analysis of a thorough storyboard will suggest or at least help throw into light suitable ways forward in terms of development techniques.
When ready to start development ask yourself some of the following questions:
Could somebody else within your Department or the University have already developed something similar?
Is there a possibility you could use other existing resource rather than having to develop new-build materials? Could you re-purpose existing class-based hand-outs for example?
You should note that pre-existing materials, especially those originally meant for print, WILL nearly always need to be re-purposed for online consumption rather than used “as is”. Don’t fall into the trap of digitally providing unsuitable resource simply because it is the easiest thing to do.
For example, PowerPoint files out with the context of a lecture can often be abstract or even confusing particularly if they are lengthy (15 slides plus). If you intend to make PowerPoint files available as part of your digital delivery then consider splitting up your presentations into discrete sections and adding Slide Notes into the presentations to provide the missing context of you not being present.
Can you use VLE survey/test functionality to achieve results you thought to try and achieve with Macromedia Flash?
Rather than script or code a complex layered release of content could it be handled more simply and more quickly by a series of VLE controlled assignments using adaptive release functionality?
What form does the main body of your content actually take?
For example: If your content is text heavy with static illustrative images then straight forward authoring of HTML pages might suggest itself (using Dreamweaver or Frontpage for example). Do you need to go that far however? What about using the VLE’s built in Content Items or Learning Units to develop the information or simply doing it in Word and linking to the Word file stored in the CMS?
There are, of course, many more issues to consider when choosing development techniques but the important message here is to properly analyse what you are trying to achieve and to make sure you chose the most efficient and fit for purpose way forward in realisation of these goals. The temptation is to jump right in and start work, you should indeed do this but from a considered platform; you don’t want to end up working yourself into a corner and thus be forced to re-develop completed materials to solve the problem.
At all times, when considering your approach to developing digital resource, you should be aware that you must make your content as accessible as possible to all. This consideration is a requirement of ANY resource you develop for online deployment. Making your content accessible might range from making alternative materials available through to making sure your developed files can be interpreted by assistive software.
A self-paced accessibility module is available for you to study as well as guides and other accessibility information. These are available at Yorkshare HQ (http://vlesupport.york.ac.uk) on the Guides tab and, when logged in to Yorkshare, on your Programme tab for the “Creating Accessible Learning Materials” self paced learning module).
It’s worth noting that, a great deal of the time, your content requirements will actually make a lot of the development decisions for you and the main part of the task will be to simply do the work and efficiently manage the process.
The Pros and Cons of VLE Content Items vs CMS stored content
Because there are so many software applications for developing digital content it is not realistic to cover them in any significant way. It is possible, however, to illustrate one of the key ways the VLE provides for content development or for directing students to developed content; the Content Item.
The VLE Content Item is a versatile tool for information delivery and can be deployed in two distinct ways (or a combination of the two distinct ways). It is worth taking note of these modes of use.
The Content Item as a resource:
You can use a Content Item to actually impart information to your students and, to this end, the VLE provides a set of tools for formatting and illustrating your “message” if made with the Content Item directly.
The Content Item as a placeholder:
You can use a Content Item as a means of directing students to content you have developed by other means such as Word, PDF or PowerPoint files for example.
When using Content Items it is worth thinking of the information you put into them as being the equivalent of what you have said if you were there to direct your student to the resource and explain its use (the “talking-head” concept).
This table explores the pros and cons of using a Content Item as a resource itself rather than as a placeholder to direct students to other Content Management System stored resources.
Requires little HTML knowledge to input content
Not as flexible. The information is in one place only and would need to be duplicated to be used elsewhere
Users see the information immediately (no additional clicks are required)
Less control over how the content can be printed out (compared to PDF, Word etc.)
Has form based configuration for insertion of some media types (images, audio, video etc) that can link to content stored in the CMS. These options write the HTML for you
Content is limited to what the VLE will allow to be embedded in terms of HTML and media (can’t use Style-sheets or XML easily for example).
Has access to the HTML code if required
Content is less easy to migrate to another system (if you wanted it in an externally facing website for example)
Anyone with the appropriate privileges can edit the content without having to find and download a file locally, edit it and re-upload it
Best for content that is “talking-head” type material rather than for discrete learning content (this is in keeping with the whole reasoning behind use of the CMS)
NOTE: The formatting tools associated with a Content Item are only fully supported when using certain browsers; Internet Explorer and Firefox.
As with your choice of production technique, your content and its requirements in terms of getting across the learning message should go a great deal of the way in suggesting how the content will need to be navigated by your learners.
A good idea when considering navigation (and interface) is to simply extract (copy out) the “Section Title” column of your storyboard (or your storyboards table of contents) and consider it holistically in context of your whole project. You could print this out and then sketch on the list just to establish how content units are likely to be linked (if at all) and how they thus then might need to be presented in terms of the whole.
When you have a loose mental image of how you think the various units of your module need to interrelate you will find that navigation techniques begin to suggest themselves to you.
User Interface Considerations
As with your choice of navigation technique, the interface you present to your learners for the purposes of navigation and message containment, if you need one over and above the VLE interface, should be driven by the requirements of your content.
Take a look at the VLE itself in terms of interface; you can see that it is broken into three distinct areas: the overarching navigation bar along the top taking the form of graphic “tabs”, the module specific navigation down the left and the main content frame with its breadcrumb navigation trail. This works for the VLE in terms of its far reaching delivery requirements but does mean that you should carefully consider the use of further navigational controls within your own content.
Limit the cognitive load on your students; make the interface as intuitive and simple as possible for your students to use. Don’t duplicate navigation and provide clear and concise instructions if there are additional interface controls you are introducing within your content.
A part of pre-planning or storyboarding your project involves, you will have noticed, spending some time up-front. It should be noted that this will inevitably save time later on.
For example, another area of development you need to consider is how the content will break down in terms of actual resource creation (rather than the break down of the content body itself).
Once again the needs of your content and its message should drive this decision mitigated by some key practical, technical or organisational considerations:
How big (in terms of file size) are the resources used in my content units likely to be (whether embedded in a HTML page, PDF or otherwise) and how are my end-users likely to access this content?
For example: If a number of your content units need to embed fairly high resolution images or use video clips it is likely you will want each unit identified in your storyboard to be a single Content Item/file rather than in a combined “block”, especially if you anticipate users on slower connections.
If a single content unit is “layered” or highly interactive you might need to develop multiple files just for the one unit, especially if there is a heavy use of bandwidth hungry media and you have users potentially on slower connections.
If the content is heavily text based with sporadic use of media elements or you are sure all your users are going to be on a fast connection and they may need to print out the material you could group storyboard units together and simply make the file available as a single PDF.
How flexible does the structure of your module need to be?
If your delivery is made up of content units that are likely to be refined or changed over time then you might want to build your module with this in mind so that, when you later amend the content (perhaps for the next cohort), you can easily switch out the changing units only without impacting the rest of the module (in terms of navigational links etc).
This flexibility can, of course, be required within a unit itself. You may be developing a module that isn’t “consumed” in a linear fashion or requires access to repeat information from various parts of the module. In these circumstances your content units may need to be discreet at the file level to provide the required access flexibility while avoiding duplication.
If you have a team working on the module how will the file break-down impact team contributions?
This is a similar consideration to flexibility, especially if you expect people to work on content units individually. As such a solution needs to be established before everyone gets down to work in order to be able to adequately control development and ultimately bring all the disparate elements together into a cohesive whole.
As is the case with many other areas of development, the content itself will help to determine the best way it can be broken down in terms of the actual digital material produced and don’t underestimate basic common sense; if you expect information to be printed, for example, then common sense would dictate that you choose to develop that information in a format that is as easy to print as possible (PDF or Word for instance).
The information here serves as a broad overview of development considerations and has been written in a manner designed to give you an appreciation for some of the key questions you need to be asking yourself when planning and subsequently developing your module (rather than as a “stepped guide to successful production” which, as you will have realised, simply doesn’t exist).
Although it all sounds very daunting, and there are indeed a lot of things to bear in mind, it is worth noting that you will have already been sub-consciously making a lot of development decisions when first considering the content and then, as you developed your storyboard, mentally refining your way forward – another key reason for developing a storyboard in the first place.
A lot of production decisions do, in fact, boil down to common sense and the simple practicality of a solution and, because ultimately your deployment is about communicating your message, that message will go a long way to making the delivery decisions transparent to you.
Scripts for voice talents
A voice-script is distinct from a storyboard. A storyboard might largely contain the text used in a voice-script but the script itself should ONLY contain text that needs to be recorded along with any language clarification/direction and organisational information needed to help facilitate the recording session.
A script to be put to a voice-talent or even to be recorded by you or a team member will thus need to be in a format that makes it easy to clearly read aloud.
There are a few issues to consider when using voice narration and when formatting a voice-script. These are broadly as follows:
Divide the narration into manageable chunks and make sure the resultant individual audio files are named in accordance with your storyboard.
The easiest way to do this is to match your narration chunks to your storyboard content units and prefix their name using your content unit code. The reasons for doing this are three-fold; dividing the audio into smaller clips makes the audio easier to handle and sequence, it helps to start limiting the download footprint for material that contains (or is) audio and it makes it easier to relate your audio files back to the appropriate visual content (in both naming and narrative scope).
Make sure that any use of abbreviations, numbers or words that are uncommon or could be pronounced in more than one way are clarified before the text chunk in which they occur
Common sense should dictate what you highlight for clarification but look out for the following:
Dates written with slashes/hyphens (eg 20/08/05) – clarify how you want them said aloud or make sure they are written in full in your script
Abbreviations that can actually be pronounced (eg JISC). You will need to inform the voice-talent as to whether it should be said letter by letter or as a word
Words not in the native language of the voice-talent, colloquialisms, names or jargon may need to be clarified in terms of pronunciation. For example, the Scottish place name written Garioch is actual pronounced “Gear-ee”. You will need to highlight such words and write them phonetically somewhere on your script (the best place is usually directly before the chunk in which they occur)
Certain number orientated phrases such as “£2.10” are better written in full in the script to ensure they are uttered as anticipated (you could, for instance, get “two pounds and ten pence” or “two pounds ten” without including clarification)
Finally and particularly if you are going to use a third party vendor for audio services, you will need to state how and in what format you want to receive the audio. Most studios can provide you with the actual digital audio files already cut up into the sections you have delineated in your script and will name them to your specification (rather than provide you with a raw audio source such as a CD or DAT); all that remains is for you to specify a preferred format for the files.
A suggested format (that will provide you with good flexibility and a good quality for voice delivery) is to ask for master files to be provided to you in the following way:
Saved as 16 bit WAVs at 44,000 hz in Mono.
Although it is unlikely that you will deploy the audio in this form (you are more likely to use MP3) it is good to have master files that are high definition and uncompressed to maximise your options for their later compression and deployment without having any loss of quality. There are also a number of free or shareware applications available for the editing of WAV files.