Preparing for Updates

Hi All,

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.

Anyone have a good system for dealing with this?

Thanks

6 Replies
Chris Fletcher

I use a folder structure that's a bit like this:

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.


C

Jeanette Brooks

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.

Steve Flowers

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.