By Mary Word
OK, we have discussed the importance of reviewing and organizing your course before starting development. Make those organizational documents to help uncover not only errors like the duplicate IDs, but also identify pages with similar interactions that can be developed as repeatable code, and to show you the boundary conditions. This phrase should be familiar to programmers, and goes back to my IBM OS programming days.
Boundary conditions are the biggest image you need to display, or the page with the most amount of text. They are the outliers, the pages you have to design the whole course for. If you establish a page design with a layout you want to maintain, then hit a page or pages which just don’t fit, you have a few choices. Change the layout for that page, which may make it stand out in the course, and not in a good way. It can look like what it is, shoehorned in for too tight a fit. Go back and redesign/layout all the other pages – lots of pain and wasted time there. Or you can cut the amount of information, or make 2 pages out of one – that sometimes works. If you have any hard page numbering, that creates its own pain.
Make those pages first, even if just as a mockup. Also develop pages that have repeatable actions, so you can use them as a template for similar pages. Working the bugs out on that one page is another pain-saver. Then test those pages on every target delivery platform you are contracted to provide the training for. One very common issue is text spread. Browsers display text slightly differently, and sometimes that makes the text wrap to another line, which can wreak havoc with your whole page. I.E. seems to spread the most among the browsers, and if you are also developing for the iPad – that one really makes the text display bigger. There are other iPad challenges, but that is one you may not think of early on, one that can affect your whole project.
Multiple audio can be very useful, triggering events in one audio file, then having events trigger another audio to play. When you mix in page controls like play, pause, and restart, you have to have a way to make sure the right audio is pausing, playing again, or starting over.
This is a great example of repeatable code. In Lectora you use actions in conjunction with objects, and can group these together. If you make action groups that will handle the audio, and use variables to keep track of which audio should be playing at any given time, those action groups can be copied to any page and modified easily to fit the specific files you are using.
Use this concept of repeatable code throughout your project. Find interactions, page designs, anything you can save as a template, reuse and modify. Reviewing the entire project as you organize it allows you to identify and mark areas for this purpose.
Another one of the challenges I will touch on here is long scrolling images. This course was based on a website with long scrolling pages of information and interactions. The screen captures made for use in the lessons could be taller than 2000 pixels. If you try to put an image larger than the display size onto a Lectora page, it automatically shrinks to fit. Since out images needed to be consistent and readable, this was a big problem for me. Based on the comments I received after the talk, it was a problem for many other people, too. I thought about using a magnifier somehow – not practical. The only scheme that I kept coming back to was scrolling – how to make an image scroll?
If an image won’t scroll, how about something that does? A text box, for example. I tried to put a long image into a text box with a scrollbar, but it simply did not work. The same height limitation applied. I was finally able to devise a procedure to cut the image into several pieces, none larger than the page, and make them appear to be one seamless image inside of a scrolling text box. I believe that one technique got me the most positive comments after the presentation.
Next time: Anatomy of a Presentation – How Did I Do That, Again?