I develop online learning experiences for users. These tend to involve some kind of interactive UI that enables the user to view content and interact with it in the form of simulations, tests and assessments of some kind, and tracking/session management stuff aka bookmarking.
These experiences are generally one time experiences with little repeating. They sometimes want to be reused extensively, but to me the quality of learning tends to go down with extensive reuse even though it does save some money. I have had the fortune of working on projects that really push the envelope and make memorable and intriguing first impressions for the learners and have a proven rate of retention and ROI for my customers. My latest opportunity at SweetRush as CTO is no exception, and Ive been able to work with some of the best folks in my career on designing and developing training content for some very impressive and demanding clients.
Although I can certainly build these projects using non-Adobe Flash IDE (Integrated developer environment), I really enjoy working inside the flash IDE because its where I started, and creatively its a wonderful tool to use. I tend to write all my code inside the flash IDE on projects where I'm the sole programmer/creative and decouple the scripts from the artwork using simple includes on projects where I'm the sole programmer but not the artist. I find this approach enables me to work very fast, and build projects that function reliably with few if any bugs out the gate.
My type A approach is fairly simple. I use the timeline as a logical flow line (a hold over from my initial training in authorware) Starting with the first few frames as preload/init frames, then dividing the user experience into what I call "action points" where some code gets executed to display some content, provide a small game or what have you. Then users can visit the AP's in any order, loop through them incrementing a value (like using 1 AP to display a question, but using another AP as a count incrementing element that just loops back to the question display AP until all the questions are done, at which point it then moves to the next logical AP).
Then by the AP's , I can set bookmarking logic to each of them as well as garbage collection, necessary inits and component/class instantiation. This allows me to use the timeline to visually layout the user experience and enables an animator who is unfamiliar with code but knows how to move keyframes around to have the ability to change the logical flow without editing code. The flash IDE provides all the objects, the library of components, and types of symbols I can provide the animator to tweak, change or even discover how programming essentially works in an environment that is familiar to them.
As a general rule of thumb, if a segment of code in a particular AP becomes more than a few hundred lines, or that code is getting reused in other spots, it becomes clear I need to move that code to the first frame where I put all my globals. I tend to have all the global variables, functions, and common data defining/parsing logic there. I also like to push all dynamic text and content URI's out to an external XML file that always gets loaded as a global to be used anywhere in the application.
I find the flash IDE endlessly flexible in this regard. I can visually represent objects as movie clips each of which can be visual or not, and can carry out functions, or just hold functions for use by other movie clips or the main timeline. Being able to make any code anywhere behave as a visual object definitely has its advantages.
Of course, one can write endlessly messy code that is nearly impossible for others to navigate in the flash IDE, so its important to be very consistent in keeping the library neat, the main timeline reserved only for logical flow and any artwork/animation to be encapsulated and contained to a specific and well labelled layer with instance names that allow it to be controlled externally.
Other advantages are the integration of the compiler in that you don't have to jump through several file settings or create elaborate folder structures with strict names on the computer to work, you can do it all inside the highly optimized work environment of the flash IDE. No need to find compilers, and moving/renaming MC's or "classes" is all monitored and tracked by the IDE so there is no need to update paths.
All this makes for very rapid application development. Provided a disciplined approach is taken, I have found one can use the flash IDE to make very flexible, very reusable and very powerful applications all with the built in power of handing the file to non-programmers to tweak art/animation/sound aspects within the same working context.
I think a primary perceived disadvantage is the reliance on the IDE vs being able to pull out the code and edit it using a text editor or source code editor of choice. While there are hundreds of thousands of flash coders like myself who feel completely comfortable implementing what could be considered "valid design patterns" inside the flash IDE, I think there are also a lot of detractors who feel that the flash IDE represents a step backward or is a tool that does not have the capabilities of a tool like Flex, for example.
I would challenge anyone to building something in Flex that I couldn't build in the flash IDE, and have it work equally as reliably, and be equally as flexible and scalable, provided other coders had access to the IDE as well for the bits that were non xml or external script.
That said, I can clearly see a few issues / disadvantages to the IDE.
1. The IDE is too permissive, in that you can use untyped variables, haphazardly scope variables and functions, and put code anywhere making it difficult to find.
- all of these are true, but they are not the rule. Any disciplined coder can write bad code in any environment. I think the need for discipline and neatness becomes heightened in the flash IDE, but I also think visually the ability to lay out an application clearly is greatly enhanced in a visual programming environment like flash. Its not as literal as author ware where you had a literal vertical line and you could drop logical objects on the line with visual loops, visual branching all iconically represented, but its similar in power.
I think of it as the difference between looking at pages and pages of VRML textually representing a 3d model, or the 3d model itself. If you can "see" the 3d model when looking at the code, wow, good for you...but you can't argue that actually seeing the 3d model itself fully rendered gives you a different perspective and often illuminates problems that a human couldn't possibly perceive when looking just at text.
That, to me, is the main difference. I like to represent code iconically, and the flash IDE/timeline allows me to do that, and just as looking at a rendered model enables me to see the object as it is, so the IDE enables me to see what I'm doing as I'm doing it rather than furiously writing incredibly elegant looking code-all indented and outdented perfectly with inline class autofilling...I can actually see the end result, the user's experience, as I'm writing it. (not quite exactly...but certainly closer than when I'm writing an app in Flashdevelop or some equivalent).
As a career coder I think its important to know a little bit about all the approaches, and to not think one is necessarily better than others as long as the primary stated goals are met, and try to apply best practices wherever they may apply across languages. If I write in Ruby, Java, Python, C++ or what have you and can learn something from a timeline / visual developer then great...and vice versa.
So why so defensive? I think that flash has branched out to make its technology more palatable and familiar to those coming from a traditional OOP background, and created Flex/Flash builder for that very reason. The sense, however is that somehow meant that Adobe was "admitting" that the flash IDE was somehow a failure and that Flash Builder was the superior step in evolution of the product. If that was true, of course, the flash IDE would have been phased out or at least severely "dumbed down" in order to push developers towards FB. I certainly felt that way and it pushed me to learn to do strict OOP, embracing a class/inheritance/interface approach and writing some fairly sophisticated projects in flash builder. After really getting down that rabbit hole I came out the other side thinking that there was a lot of what I considered unnecessary complication with that approach, and that while I thought it certainly made sense for some kinds of projects like the one I was working on for example, I didn't think it necessarily was the be all, end all approach for all projects.
One very interesting development is the advent of the javascript/html animation tool Adobe Edge. Over the past couple of weeks I had to build a project using Edge with some serious tweaking and I found that even though the product is in beta, and its buggy, I really enjoyed using it and appreciated the ability to edit the source files and find most of my edits were retained in the IDE, with only a couple of minor exceptions. So far, Edge looks a lot like the flash IDE, the only notable difference being the timeline works in seconds rather than in frames. But, like the flash IDE, I can place code on a timeline or all in one place at the beginning, reference external code, and use the timeline to trigger/organize events that can also be manipulated by animators.
I think the Edge tool, either merged with flash IDE or kept as a separate tool will ultimately continue the legacy and impact of timeline coders, perhaps to the ire of OOP programmers but I certainly hope to see more interoperability among skillets and disciplines rather than an eventual monoculture of development.
Finally, on a creative level the IDE enables animators to "see" code, and coders to "see" artwork. I think if animators stick to tools like illustrator and photoshop, they will never get "rich media". I also think the same is true for programmers that wall themselves up in code. The flash IDE is the glasnost, the common ground where folks from an artistic background and those from a programming background are forced to literally work in the same environment and gain a very intimate understanding of each other's work. The best stuff I've seen in flash has been built by coders who were also amazing artists and animators, who really understood fluid motion dynamics, colour, font design, traditional animation technique, photography, bit mapping, sound editing and mixing, and of course were excellent programmers who really had a grasp of OOP. While these "one hit wonders" are tough to come by, I think the flash IDE provides the opportunity for a collective to "get inside each other's heads" and become that one mind that can then, collectively, become more than any individual team member can.
Monday, December 26, 2011
my first exposure to "Design Patterns"
After writing software on my own for almost 15 years, including dozens of applications that served tens of thousands of fortune 500 users and served up thousands of hours of content, along with user/content management and access control, content authoring tools and countless UI components, assessments, and API based system specifications...I've finally gotten to a place in my career where I've been introduced to the concept of Design Patterns.
Being largely self taught and mentored by self taught engineers, I eventually came up with methodologies and best practices that helped me produce applications quickly and cost-effectively while maintaining a high degree of reusability and flexibility. My software continues to generate revenue for past and current clients, and has invariably been successful in delivering its stated goals.
My latest work opportunity has put me in a position to work with some engineers with more formalized training than I have had, and I've observed that came with the benefit of the collective knowledge and experience of engineers across a variety of disciplines that I never really had, being almost always the "lone engineer" on projects, or being fairly separated from my team of engineers to focus on the business / strategic side of technology. My new team represents the best talent Ive worked with yet, so I wanted to take advantage of the opportunity and see what I could learn from them. The first thing they pointed me to was "Design Patterns".
In various capacities I had heard the terms "Model-View-Controller", "Singleton", and of course "prototype" bandied about, but was more busy writing code than thinking of how to describe what I was doing via inherent common sense. It always made sense to me to have major components of my systems decoupled, and my circumstances would have described this as Data/API/UI. In my way of thinking, all my apps were driven by some kind of data/content in one bucket, an API that knew where the content/data was and could be queried by any UI engine. I'd been using this approach long before "cloud server" came along, really since my first app, the "auto player software" followed by my various flash applications. Until I read about MVC, I practically felt like I invented it. (thats what happens when one essentially lives under a rock)
I felt this concept applied to every kind of software I built, from the big enterprise apps and systems I designed, to the smallest 2 minute entertainment interaction I built. There was always data, content, an interface, and view. I'm not sure how that precisely maps to "Model View Controller" but I'm not too concerned about it, because it always worked. By the end of developing hundreds of apps using a very specific set of best practices and designs, I had the system down to the point of being incredibly efficient and reliable, and exceptionally flexible. Once others learned my system they often copied and adapted it for their own use.
So as I begin to explore MVC and other design patterns, I am feeling a strong sense of vindication. That while I've been working away in a "dark cell all alone" I ultimately came to the same logical conclusions as the rest of the software community...only I use a different nomenclature.
To me, and most "old guys" I know, it doesn't really matter how you build something. Its whether or not it does the job and didn't cost too much in time/money/effort. If you build something too hastily it will cost you down the road in maintenance and fixes. If you build something too slowly, you'll end up making $0.02 an hour, and only 3 people on earth will appreciate the "elegance " of your work.
So this brings up an impression I'm getting now. In reading "Head First Design Patterns" I get the distinct impression of an almost zealous "my way or the highway" sense that reminds me of a religious fervour. They speak of their nomenclature as if its really the "only" enlightened approach to problem solving in OOP. I have to agree that a common nomenclature is helpful in a situation where code needs to be shared across a group, and am more than happy to embrace a common lexicon organizationally to improve interoperability and communication between engineers.
That said, I have to agree with Steve McConnell who said
"Moreover, shifting the code too far forcing it to look like a standard pattern unnecessarily increases complexity."
This does not constitute a justification for "shutting down" a design pattern approach, but it is more cautionary in struggling to attain a perfect score among programming buddies could potentially cloud the primary goal of making software that works for the user on time and under budget.
So I'll continue to study design patterns and post here periodically as my learning increases on the topic. So far just reading the terms and definitions has not only provided me with the feeling of "so that's what they call that thing Ive been doing for all these years", but also some of them provide ideas that will make my code more efficient, readable , and reusable going forward.
My next post will be on the flash IDE timeline based programming vs OOP and how they really aren't all that different, but it will relate to this one as a last word in that I'd go further to say that design patterns in OOP do not just apply to code written in standard scripts like AS3, C#, Java, Javascript etc., but also can apply to visual programming IDE's like the flash IDE, Authorware, Director, and customized frameworks.
Being largely self taught and mentored by self taught engineers, I eventually came up with methodologies and best practices that helped me produce applications quickly and cost-effectively while maintaining a high degree of reusability and flexibility. My software continues to generate revenue for past and current clients, and has invariably been successful in delivering its stated goals.
My latest work opportunity has put me in a position to work with some engineers with more formalized training than I have had, and I've observed that came with the benefit of the collective knowledge and experience of engineers across a variety of disciplines that I never really had, being almost always the "lone engineer" on projects, or being fairly separated from my team of engineers to focus on the business / strategic side of technology. My new team represents the best talent Ive worked with yet, so I wanted to take advantage of the opportunity and see what I could learn from them. The first thing they pointed me to was "Design Patterns".
In various capacities I had heard the terms "Model-View-Controller", "Singleton", and of course "prototype" bandied about, but was more busy writing code than thinking of how to describe what I was doing via inherent common sense. It always made sense to me to have major components of my systems decoupled, and my circumstances would have described this as Data/API/UI. In my way of thinking, all my apps were driven by some kind of data/content in one bucket, an API that knew where the content/data was and could be queried by any UI engine. I'd been using this approach long before "cloud server" came along, really since my first app, the "auto player software" followed by my various flash applications. Until I read about MVC, I practically felt like I invented it. (thats what happens when one essentially lives under a rock)
I felt this concept applied to every kind of software I built, from the big enterprise apps and systems I designed, to the smallest 2 minute entertainment interaction I built. There was always data, content, an interface, and view. I'm not sure how that precisely maps to "Model View Controller" but I'm not too concerned about it, because it always worked. By the end of developing hundreds of apps using a very specific set of best practices and designs, I had the system down to the point of being incredibly efficient and reliable, and exceptionally flexible. Once others learned my system they often copied and adapted it for their own use.
So as I begin to explore MVC and other design patterns, I am feeling a strong sense of vindication. That while I've been working away in a "dark cell all alone" I ultimately came to the same logical conclusions as the rest of the software community...only I use a different nomenclature.
To me, and most "old guys" I know, it doesn't really matter how you build something. Its whether or not it does the job and didn't cost too much in time/money/effort. If you build something too hastily it will cost you down the road in maintenance and fixes. If you build something too slowly, you'll end up making $0.02 an hour, and only 3 people on earth will appreciate the "elegance " of your work.
So this brings up an impression I'm getting now. In reading "Head First Design Patterns" I get the distinct impression of an almost zealous "my way or the highway" sense that reminds me of a religious fervour. They speak of their nomenclature as if its really the "only" enlightened approach to problem solving in OOP. I have to agree that a common nomenclature is helpful in a situation where code needs to be shared across a group, and am more than happy to embrace a common lexicon organizationally to improve interoperability and communication between engineers.
That said, I have to agree with Steve McConnell who said
"Moreover, shifting the code too far forcing it to look like a standard pattern unnecessarily increases complexity."
This does not constitute a justification for "shutting down" a design pattern approach, but it is more cautionary in struggling to attain a perfect score among programming buddies could potentially cloud the primary goal of making software that works for the user on time and under budget.
So I'll continue to study design patterns and post here periodically as my learning increases on the topic. So far just reading the terms and definitions has not only provided me with the feeling of "so that's what they call that thing Ive been doing for all these years", but also some of them provide ideas that will make my code more efficient, readable , and reusable going forward.
My next post will be on the flash IDE timeline based programming vs OOP and how they really aren't all that different, but it will relate to this one as a last word in that I'd go further to say that design patterns in OOP do not just apply to code written in standard scripts like AS3, C#, Java, Javascript etc., but also can apply to visual programming IDE's like the flash IDE, Authorware, Director, and customized frameworks.
Tuesday, December 13, 2011
Adobe Edge animation controlled by the scrollbar! its easy and fun.
How to make your animation controlled by the scrollbar in Adobe Edge Preview 3:
Adobe edge is a great HTML 5 editing tool, and with a few tweaks I think it will end up being the best html5/javascript/jquery tool on the market for professionals looking to create highly interactive non-flash interactive animations. I've been a flash programmer for 14 years now, and I actually enjoy working on the timeline so Adobe Edge is a lot more creatively satisfying than working with eclipse to make "interactive art", at least for me.
In this example I made an animation in Adobe Edge that the user "Scrubs through" with the scrollbar instead of it just playing automatically as is the default for Adobe Edge. I think its a good way to introduce the lay person to the concept of scrubbing a playhead through time, and would make a neat "popup book" for kids with a simple approach like this as it is a different use of a familiar UI element, the scrollbar. As a flash user, I've always hated scrollbars because I think information should be presented in one place using time/animation rather than making the user scroll through it, but I have built them from scratch in flash AS3 (see previous post) and this makes for an interesting continued experiment with the things.
Example (drag the scrollbar to advance the animation)
http://www.northeastmagic.com/adobeEdge/scrollbar_scrubber/test7.html
Allowing the user to scrub through your html5 animation created in Adobe Edge allows them to have a "popup book" feel of control over your work, making it interesting to play with. Scrolling is a familiar control interface but using it as a playhead scrubber opens up a new realm of possibility to the user unfamiliar with animation development. Note: the animation has to be wider than the users's viewport or this wont work - so you designers with huge monitors will have to shrink the window down a bit...
From an animator perspective, try to make your animation in segments that can be easily divided into the physical width of the artwork (or height if you are vertically scrolling). So for example a 4 second animation could be 2000px wide, and you basically do 1 scene inside 500px, bearing in mind that animation occurring in the left side will not be visible as the user scrolls through the piece. (Per second you allow 500px for that "second's" scene. Its a weird way to think about animation but hopefully thinking of it this way will help.
As of writing this article, Adobe Edge preview 3 is fairly buggy, for example trying to work with objects that go beyond the right side of the viewable area is problematic since the selection tools basically become unavailable when you scroll. My workaround for that was to do the animation in the viewable area first, then move the playback head to 0:00, then translate the x of the animated objects to the far right as far as I could without losing selection. Interestingly when you translate an object while the playhead is at 0, it affects all keyframes of the object, so this seemed to be a workaround for now. Hopefully adobe will address this, as well as adding the ability to set the width/height with percentages instead of px, and individually control the overflow handling of the vertical and horizontal scrollbars.
1. add a trigger to the beginning of the animaton this.stop();
2. add a "scroll" event to the stage top right. paste the following code in there
// insert code for scroll event here
var myCalc=this.element.scrollLeft/(this.element.scrollWidth-this.element.clientWidth);
this.stop(myCalc*this.getDuration());
3. make the animation etc. work at the full width. Make a note of the stage width you picked (2000px etc.) top left.
4. when finished save, leave edge and look in the files it created.
5. Open the one called "MYFILENAME_edge.js" in dreamweaver
6. do a find for "2000px" or whatever the width was that you picked. .... replace width value with "100%"
something like : id: "eid1", tween: [ "style", "${_stage}", "width", '100%',
is the important one. There should only be 1 _stage line. If there is more you've tweened the stage and you should remove them.
7. if you are scrolling horizontally you'll need to hide the vertical scroller like this:
one of the objects should have a stage object, add the overflow-x and overflow-y appropriately:
"${_stage}": [
["color", "background-color", 'rgba(12,12,13,1.00)'],
["style", "width", '500px'],
["style", "height", '400px'],
["style", "overflow-y", 'hidden'],
["style", "overflow-x", 'auto']
],
REALLY IMPORTANT, dont forget to make sure there are commas between each line and NOT one on the end of the last line
if you want to vertical scroll, use overflow-y auto and overflow-x hidden, and set the height to 100%. You can also set both height and width to 100% to push the scrollbar to the bottom of the frame.
I still think flash is far more advanced of a tool for animation and rich internet applications, but given the landscape of politics these days with iOS refusing to allow flash for their own inane reasons, we can learn to "build a ferrari with toothpicks" and use HTML 5 / javascript to appease the ignorant "flash haters" out there.
About the author:
Ryan Cameron is CTO of SweetRush inc., a SanFrancisco based e-learning and interactive technology development company. Ryan works virtually and lives in Nova Scotia, Canada.
Adobe edge is a great HTML 5 editing tool, and with a few tweaks I think it will end up being the best html5/javascript/jquery tool on the market for professionals looking to create highly interactive non-flash interactive animations. I've been a flash programmer for 14 years now, and I actually enjoy working on the timeline so Adobe Edge is a lot more creatively satisfying than working with eclipse to make "interactive art", at least for me.
In this example I made an animation in Adobe Edge that the user "Scrubs through" with the scrollbar instead of it just playing automatically as is the default for Adobe Edge. I think its a good way to introduce the lay person to the concept of scrubbing a playhead through time, and would make a neat "popup book" for kids with a simple approach like this as it is a different use of a familiar UI element, the scrollbar. As a flash user, I've always hated scrollbars because I think information should be presented in one place using time/animation rather than making the user scroll through it, but I have built them from scratch in flash AS3 (see previous post) and this makes for an interesting continued experiment with the things.
Example (drag the scrollbar to advance the animation)
http://www.northeastmagic.com/adobeEdge/scrollbar_scrubber/test7.html
Allowing the user to scrub through your html5 animation created in Adobe Edge allows them to have a "popup book" feel of control over your work, making it interesting to play with. Scrolling is a familiar control interface but using it as a playhead scrubber opens up a new realm of possibility to the user unfamiliar with animation development. Note: the animation has to be wider than the users's viewport or this wont work - so you designers with huge monitors will have to shrink the window down a bit...
From an animator perspective, try to make your animation in segments that can be easily divided into the physical width of the artwork (or height if you are vertically scrolling). So for example a 4 second animation could be 2000px wide, and you basically do 1 scene inside 500px, bearing in mind that animation occurring in the left side will not be visible as the user scrolls through the piece. (Per second you allow 500px for that "second's" scene. Its a weird way to think about animation but hopefully thinking of it this way will help.
As of writing this article, Adobe Edge preview 3 is fairly buggy, for example trying to work with objects that go beyond the right side of the viewable area is problematic since the selection tools basically become unavailable when you scroll. My workaround for that was to do the animation in the viewable area first, then move the playback head to 0:00, then translate the x of the animated objects to the far right as far as I could without losing selection. Interestingly when you translate an object while the playhead is at 0, it affects all keyframes of the object, so this seemed to be a workaround for now. Hopefully adobe will address this, as well as adding the ability to set the width/height with percentages instead of px, and individually control the overflow handling of the vertical and horizontal scrollbars.
1. add a trigger to the beginning of the animaton this.stop();
2. add a "scroll" event to the stage top right. paste the following code in there
// insert code for scroll event here
var myCalc=this.element.scrollLeft/(this.element.scrollWidth-this.element.clientWidth);
this.stop(myCalc*this.getDuration());
3. make the animation etc. work at the full width. Make a note of the stage width you picked (2000px etc.) top left.
4. when finished save, leave edge and look in the files it created.
5. Open the one called "MYFILENAME_edge.js" in dreamweaver
6. do a find for "2000px" or whatever the width was that you picked. .... replace width value with "100%"
something like : id: "eid1", tween: [ "style", "${_stage}", "width", '100%',
is the important one. There should only be 1 _stage line. If there is more you've tweened the stage and you should remove them.
7. if you are scrolling horizontally you'll need to hide the vertical scroller like this:
one of the objects should have a stage object, add the overflow-x and overflow-y appropriately:
"${_stage}": [
["color", "background-color", 'rgba(12,12,13,1.00)'],
["style", "width", '500px'],
["style", "height", '400px'],
["style", "overflow-y", 'hidden'],
["style", "overflow-x", 'auto']
],
REALLY IMPORTANT, dont forget to make sure there are commas between each line and NOT one on the end of the last line
if you want to vertical scroll, use overflow-y auto and overflow-x hidden, and set the height to 100%. You can also set both height and width to 100% to push the scrollbar to the bottom of the frame.
About the author:
Ryan Cameron is CTO of SweetRush inc., a SanFrancisco based e-learning and interactive technology development company. Ryan works virtually and lives in Nova Scotia, Canada.
Subscribe to:
Posts (Atom)
