Storyboard

sflowers
sflowers Community Member Posts: 106
So... I'm back. These are suggestions I've made before in one form or another. I, and my coworkers / teammates / organization by extension, personally need a few things to extend Lectora's Utility in our workflows to maximize the tool's value.The current object hierarchy would seem to make my first suggestion trivial easy. Tim L. may have been thinking that I was talking about MAJOR rework. Nope. Just a simple object extension to the structure that's ALREADY there.StoryboardA system that allows a user to add data to pre-established fields for a screen, or parent element. Fields would include Stbd number, audio script, screen text (which would be mirrored with a consistently named text object on the screen), Graphic description, Programming Notes / Interaction.Additionally, a screen layer container (similar to a group) would be available to contain visual descriptions of screen elements (freestyle). This would be easily globally toggled on / off / exclusive (just showing the planning container). This planning group could contain any of the available screen objects. Here's the kicker and the rub ---If we have these things we have a single place to store the CORE design planning elements RIGHT ALONGSIDE the development assembly source. Instant reference, tons of utility.To make this useful for reviews, a report function would have to be built to output the storyboard to something like a WORD DOC. A roundtrip format that enabled this same document to be sucked back in would be ideal, but that gets sticky hard with validation of format and the high chance that someone will monkey with the document.The output storyboard report could generate a table containing all of the screen level elements alongside a graphic shot of the planning group, and a tree graphic representing the structure.I'm talking about leveraging the object structure that's already there to extend Lectora into a planning and documentation assist tool.