By Mary Word
Part 2: Where do you take the first bite?
The first thing that came clear was that the entire project was complex, not just the programming within pages. The highest level of that was handled by our Instructional Designer, Linda, as she designed and wrote the storyboards. Fortunately, we had worked together long enough that she brought technical questions to me as she wrote, so I could either tell her yes, that will work, or no, that won’t work, or most often – let me try it and see. I had initial Lectora training from our Production Head, Jillian, when I came on board, and since then have learned by doing. I get a question or a storyboard, and figure out a way to make it work. Or sometimes not. (There are always screens that look easy on paper, but only reveal their tricky little issues when you actually start to build them.)
I put in a good bit of time figuring out specific interactions and bits of programming during the design process. That saves pain in the long run.
Remember that phrase: Saves Pain in the Long Run. It is a recurring theme and motivation for much of what I did. And do. When I talk about running multiple debug tests and checking boundary conditions and commenting your own code, that phrase is usually at the base of it. I will try not to be too repetitious, so just let it run in your mind as underpinning.
I decided to first show how to handle the overall complexity of the project, then drill down to the page elements that comprise the interactions. I like the big picture approach. It just works for me to build a framework first, then use it to organize the information in an understandable way. This is how I illustrated that concept for my talk:
Each piece of information was a leaf on the tree. That sort of thing, or a post office box analogy, helps bring order to chaos and let me feel I can actually find a place to start, a first bite of that elephant. If you can’t figure out where to take that first bite you can thrash around for a long time.
I am talking about a couple of first bites here, the one here about how to get started on the presentation, and within the presentation, how to do it on a project. When I get a storyboard, I don’t just start at the beginning and build each page as it comes. I look over the whole thing and organize it into manageable pieces for development. The support documents listed in the image are some of the ones I use for that with a project. I did a similar thing for the presentation. I started with a list of the key points I wanted to cover, and then stayed at that level to push them around and order them in an effective sequence. I made little notes here and there of details to remember to put in later, but resisted the temptation to get in the weeds too early.
Looking at my illustration, should I call the blog entry level a meta-level? But then I guess the presentation level would be, too – it is about the course, not the course itself. Wait, isn’t the course about the website? I have to stop now. This is getting too deep. Check out the urbandictionary.com entry on meta and you’ll see what I mean.
This top-down method of organizing isn’t new or uncommon, but it works for me. And it works at every level. I use the same technique on a complex page like the one I dissected in the presentation. That page had so many actions and objects and audio files all interrelated that even using groups and meaningful names and documentation it took me hours to come back to it months after I made it and figure out exactly how it worked. Because I had to show other people. Lots of other people. On a stage. Under lights. Recorded.
Next chapter: Anatomy of a Presentation, the Documents