1) keep the logic simple and well planned in the trigger panel. The triggers should be consistently organized slide to slide.
2) create short variable names that have logical sequencing and numbering
3) create variables for slides and use these to display scene/slide name references during testing so testers are able to let you know specifically which slide they are referring too (i.e. scene 2, slide 12 could be called S2S12)
4) document consistently (the purpose of triggers, the reason for a layer, etc) as you'll find it really easy to workaround issues, make things work, then come back later and wonder why you did what you did. Document everything.
5) keep daily versions if you're working on things daily or weekly if it's upkeep (i.e. I use a naming system like projectname-v001, -v002, etc)
6) template slides by thoroughly setting up and testing slide functionality then saving that out as an individual project. You can then import the slide(s) into other projects or multiple times within a single project.
7) take the time to create a library of your commonly used layouts and/or functionality (as you build it and know you'll reuse 80% of it again) and then do that, reuse it instead of re-creating it (and adding more QA time into the dev process)
8) publish often and check on multiple monitors and resolutions, multiple systems to catch any functionality or design issues early in the process otherwise you'll have to apply changes to more slides/scenes later which will add to dev time and increasing risk of errors.
9) create a PowerPoint companion file as a style kit where you record fonts, colors, logos, image treatments, special graphics built in ppt and brought into storyline, design elements, etc.
10) know where the bugs are, document your workarounds, keep it simple.
Thanks guys I forgot to add that I also always get into the habit of naming all the objects of a slide. Tedious but it takes the confusion out of things when you have a lot of triggers and variables in action.
Great list! I hadn't thought about #4, documenting your work (but it makes perfect sense when you're building logic in).
Has anyone found a good method to do that? I was thinking that adding a text box off the slide would be one way to document, but would love to hear other ideas.
-Although layers seem to be a quick way of build up lots of content on one slide be wary of the time needed to configure settings e.g allow seeking/resume saved state to allow smooth playback through the module (not a lot of time but necessary nonetheless)
12 Replies
Hi there, here are some of my tips:
1) keep the logic simple and well planned in the trigger panel. The triggers should be consistently organized slide to slide.
2) create short variable names that have logical sequencing and numbering
3) create variables for slides and use these to display scene/slide name references during testing so testers are able to let you know specifically which slide they are referring too (i.e. scene 2, slide 12 could be called S2S12)
4) document consistently (the purpose of triggers, the reason for a layer, etc) as you'll find it really easy to workaround issues, make things work, then come back later and wonder why you did what you did. Document everything.
5) keep daily versions if you're working on things daily or weekly if it's upkeep (i.e. I use a naming system like projectname-v001, -v002, etc)
6) template slides by thoroughly setting up and testing slide functionality then saving that out as an individual project. You can then import the slide(s) into other projects or multiple times within a single project.
7) take the time to create a library of your commonly used layouts and/or functionality (as you build it and know you'll reuse 80% of it again) and then do that, reuse it instead of re-creating it (and adding more QA time into the dev process)
8) publish often and check on multiple monitors and resolutions, multiple systems to catch any functionality or design issues early in the process otherwise you'll have to apply changes to more slides/scenes later which will add to dev time and increasing risk of errors.
9) create a PowerPoint companion file as a style kit where you record fonts, colors, logos, image treatments, special graphics built in ppt and brought into storyline, design elements, etc.
10) know where the bugs are, document your workarounds, keep it simple.
Priceless advice.
Thanks for the reminder Stephanie...
Bruce
Very good list, Stephanie. Thanks!
Thanks guys I forgot to add that I also always get into the habit of naming all the objects of a slide. Tedious but it takes the confusion out of things when you have a lot of triggers and variables in action.
Great list Stephanie--I second your naming suggestion...sure makes the triggers, etc a LOT easier to troubleshoot or update!
Thank you for sharing this Stephanie. I found it very helpful.
Great list! I hadn't thought about #4, documenting your work (but it makes perfect sense when you're building logic in).
Has anyone found a good method to do that? I was thinking that adding a text box off the slide would be one way to document, but would love to hear other ideas.
Those last two points are particularly smart and useful.
Use "Fade In/Out" on Slow or Very Slow for better effect than leaving on the default "Medium".
Just a quick one to chime in with.
-Although layers seem to be a quick way of build up lots of content on one slide be wary of the time needed to configure settings e.g allow seeking/resume saved state to allow smooth playback through the module (not a lot of time but necessary nonetheless)
Thanks for sharing everyone
This discussion is closed. You can start a new discussion or contact Articulate Support.