In the specification for HTML5 several methods for storing data locally are outlined including localStorage and manifests. While building out the offline storage for Animatic Builder, I attempted to keep the stored data dead simple; as in the case of the shot information which is stored as one long JSON string. In this way the shot data can be pulled into any other use by reading the string. Keeping the images stored proved more difficult due to the number, potentially hundreds, and their format as many separate files. As well as making sure the storage is universal on mobile and full client systems. « Read the rest of this entry

The Animatic Builder timeline.
For this update I am going to give an overview of a new online application I have developed over he past couple of weeks to aid in pre-production, Animatic Builder. If you are unfamiliar with storyboards or animatics there are overviews here. Essentially where storyboards are the first visual organization of a film idea, an animatic is the next step adding a duration to each storyboard so the pacing of a film can be developed. Animatic Builder is designed to make creating storyboard and animatic sequences easier by keeping a sequence and it’s associated content in a central location accessible from virtually anywhere within an intuitive user interface.
The core idea of Animatic Builder is that a sequence can be timed out, played back and updated from a web browser without the need for movie compression, emailing large files and maintaining timeline files. With a concept and a set of images, a timed out sequence can be arranged and played back in just a few minutes. Animatic Builder is not meant to replace a non-linear editor such as Final Cut Pro but for planning out a scene or short movie during pre-production. The functionality of the app will be focused on building sequences with only pre-production information, keeping the app lightweight and accessible from any modern browser. Animatic Builder keeps a sequence and it’s necessary files contained for easy access.
« Read the rest of this entry
I decided to go ahead replace the Flash header at the top with the Kwicks JavaScript version after I ironed out the kinks. The menu now works in IE and the whole width of the menu tabs is clickable.
The whole thing validates and is smaller than the original Flash version.
Depreciated, the header was for my old site. An example will be added soon.
For the most part people tend to use a mix of JavaScript and Flash to construct visual site effects CSS and HTML can’t provide alone. However, with the advent of JavaScript libraries allowing easy access to JS based effects, the playing field has tipped to using one method or another. JS libraries are not without detractors; for example, “Why JavaScript libraries stink” points out that “1. Most libraries are bloated. The user may load a full library for effect, but in many cases the effect could be achieved in a few lines of code.” A valid point and I’ll leave the libraries debate open for now but remember that the Flash browser plug-in is not a built in component of any browser and cannot be customized to load only what is needed. All major browsers support JS natively and in recent months there has been a push to claim the JavaScript speed crown. Another reason to consider using only JS? The emerging mobile phone market. Even my now discontinued SGH-A717 runs JS.
« Read the rest of this entry