By Mary Word
OK, I had my initial lists, and as I said, the overall concept of how to organize a complex project, or page, or presentation. So I made another list.
This one was my presentation sequence document, about four pages, where I started fleshing out the content of the talk. I started by listing challenges. This would be the hook. Present the challenges that course confronted me with, then show the end results of how I met those challenges.
The challenges were organizational and technical. The course had 66 pages spread over 4 lessons. It used some very large graphics based on long scrolling web pages. Many pages used multiple audio files. There were complex interaction/simulations. And it had to run on multiple browsers and platforms and be accessible. Whew! For my target audience of Lectora developers most of these items represent difficult development tasks.
So I went top down. I showed examples of the support documents I developed to corral the course content into manageable development tasks. There were page ID cross-references, menu navigation layouts, abbreviated tables for each lesson with a line for each page identifying page type and any special handling required, and how to utilize features in the storyboard, such as event markers in synched audio, as organizational keys in programming the page. These documents all evolved to serve a need.
One screen in a lesson could take up to 4 pages in a storyboard, and I had storyboards with as many as 60 pages. Flipping through all those pages to find a particular thing, or to organize page types so I could design reproducible elements, was driving me crazy. I also like to develop a lesson top down – create pages and name them, even if they are just placeholders, get initial content in, then start on other phases. I like to work in passes as much as I can, like inserting all of the audio when it comes in. I find it more efficient. Having a single page to keep track of where you are is a huge help.
Speaking of the audio – I mentioned page ID cross-references. We use unique page IDs to be able to identify pages more easily for reviews and fixes. At this time they were random (we since have gone to sequential). Making a table with page IDs in one column and module/lesson page in another made it so much easier to find where to go to fix a review comment on 5678. You can sort the table by the ID column to find where to go. Sorting by that column also revealed a few duplicate IDs. This course had several lessons in chapters within one Lectora file. That file has all images for the course in one folder, all media in another – and we named our audio narration files with the page ID. So duplicate IDs were not only a problem for page identification during reviews, but as the audio files for each lesson came in, those were imported into the one folder. A duplicate would overwrite the previous file, which may already have several event triggers programmed into it. Lots of work lost.
Remember that Saves Work in the Long Run phrase? Here is one example of how spending the time upfront to make good support documents can prevent time-consuming errors from showing up later.
And as we all should know by now, the earlier you find an error, the cheaper it is to fix.
Next time: Anatomy of a Presentation, Development Challenges