I'm trying to think of a good way to record all the tips and tricks of a sophisticated course, so that in a year when someone else has to update it, they can understand the branching, design, player template, post-publish modifications, etc. If I have to update it myself, I'm assuming I'll forget, so good to record the process someway in any event.
It's called putting your project, including your storyboards in a folder, burning to a DVD and giving to the client or storing the project on the network in some sort of archive.
Root folder (usually the training name) containing:
PPTX and PPTA files
Images folder
Flash folder (for any flash built files)
Interactions folder (for Engage and Quizmaker files)
Captivate folder (for all captivate files)
Published folder (where I put the version controlled published articulate modules)
This has helped me immensely as then at a glance you can access all your source files, and everything is very apparent from the word go. It also stops that uncomfortable moment where you can't remember where you put something... I kjnow the ppta compresses everything used in the training for you, but this helps me to remember exactly where I find things. In the older versions of articulate, this kind of organisation was more necessary, but I promise you its a good habit to get into!!
I guess as far as the other bits are concerned, you could always add an extra slide at the beginning with a list of things like the template etc on it, and hide it or just a readme.txt file.
Great discussion topic, A @OSPI! I second Robert's suggestions regarding using Screenr to do a quick verbal & visual walk-through of any unusual or complex development notes. The other suggestions above regarding documenting everything via storyboards & project files is super-helpful too (and for some projects, that's all that's needed, if everything is pretty straightforward for anyone who might unpack the files in the future). But in some situations you might be able to save yourself a little time by recording a screencast rather than writing out all the minutae in a document.
I like the Screenr idea as well to document the tricky assembly details (how you made pattern X work) as well as any post processing tricks / surgery you had to perform to get things integrated. For things that are easy to screw up, I also like to write up a quick job aid. The job aids I build really aren't formal (example attached). But I think they are helpful. I add these job aids into my project structure.
My structure is pretty simple.
alignment documents, contracts, analysis reports in the base directory
Planning - all my planning and storyboard docs in this folder
Production - all my source and production artifacts in here
-- Articulate
-- Flash
-- Fireworks
-- Stock Photos
-- Job Aids
-- Published
I set up my publish paths to minimize cross pollution (no mixing source materials and published outputs). I think quick job aids and screen captures illustrate *gotchas* better than extensive documentation.
6 Replies
It's called putting your project, including your storyboards in a folder, burning to a DVD and giving to the client or storing the project on the network in some sort of archive.
Screenr maybe? Record all the tips in your screenr account and the vids will all be there for download later.
I save everything in it's own project folder and I also have a notebook that has tabs for each project with style sheets and defaults in it.
I use a folder structure that's a bit like this:
Root folder (usually the training name) containing:
This has helped me immensely as then at a glance you can access all your source files, and everything is very apparent from the word go. It also stops that uncomfortable moment where you can't remember where you put something... I kjnow the ppta compresses everything used in the training for you, but this helps me to remember exactly where I find things. In the older versions of articulate, this kind of organisation was more necessary, but I promise you its a good habit to get into!!
I guess as far as the other bits are concerned, you could always add an extra slide at the beginning with a list of things like the template etc on it, and hide it or just a readme.txt file.
C
Great discussion topic, A @OSPI! I second Robert's suggestions regarding using Screenr to do a quick verbal & visual walk-through of any unusual or complex development notes. The other suggestions above regarding documenting everything via storyboards & project files is super-helpful too (and for some projects, that's all that's needed, if everything is pretty straightforward for anyone who might unpack the files in the future). But in some situations you might be able to save yourself a little time by recording a screencast rather than writing out all the minutae in a document.
I like the Screenr idea as well to document the tricky assembly details (how you made pattern X work) as well as any post processing tricks / surgery you had to perform to get things integrated. For things that are easy to screw up, I also like to write up a quick job aid. The job aids I build really aren't formal (example attached). But I think they are helpful. I add these job aids into my project structure.
My structure is pretty simple.
I set up my publish paths to minimize cross pollution (no mixing source materials and published outputs). I think quick job aids and screen captures illustrate *gotchas* better than extensive documentation.
This discussion is closed. You can start a new discussion or contact Articulate Support.