I wanted to get this down for posterity, I've been saying this for months, but dont have an early record of it and as I watch it happen exactly as I predicted it, I should get it down, I think.
Branchout today is a "linkedin" killer that is growing up inside facebook. Instagram grew up inside facebook and was perceived as such a threat by facebook that they bought it for 1Billion.
The new market is this mysterious mountain thats always been there, I call it the "human interaction mountain" that up to recently has been something a lot of people saw value in, but only a few managed to begin to wrap their heads around it.
Google and Wikipedia were early adaptors, building the roads and trails to it, and documenting how it got their, and describing it, and they've built their fortunes on that defining process.
Facebook went in and cut off all the trees, and managed to "harvest" all the wood products and that has led to a trillion dollar IPO possibly.
Apple has built the cars and infrastructure to navigate it. Instagram and Hipstamatic and Twitter obviously found value in areas where facebook wasnt, but its still as I'd consider on the surface of this giant mountain of data. This is because all of these services allow for sharing and consuming of what is essentially 1 way non interactive content.
I would lump gaming in here too, because while it is interactive, the relationship between the user and the content simply loops, and ultimately the user is going through a series of pre-programmed motions and the game scope is not effected by individual users.
Branchout and Linkedin have begun to scratch that surface and go a little deeper, and content through programs like that, which enable new content to literally form out of relationships between the users. Facebook has some of this concept in "pages" and "groups" but it is all still very generic, beginning stages.
I think the real deep market that exists and represents a much lower hype, longer lifespan market that will be resistant to commoditization is this deeper "mining" of the mountain.
This means more sophisticated product offerings, more complex models that literally discover and mine various kinds of data models that are for now largely unknown, but thanks to the Googles, the Facebooks, the Apples, these new models are more discoverable than ever.
on a somewhat related note:
If this interests you, there is more down this rabbit hole. The "giant data mountain" that is essentially made of human interaction and information itself, is not only abstract, but quickly merging with the physical world, which is one reason why its particularly important. Right now, using any 3d printing system, we can convert pure data into physical objects. These can be artistic expressions, physical tools or parts of tools, and even human organs (kidneys, bladders and other organs have already been successfully implanted for years)
The "word became flesh" is more true than ever. This kind of merging of physical and data is where we are headed, and these interactions will more and more rapidly be indistinguishable from our physical world as "we" become the data we create and interact with.
This is why, to me, the understanding of the relationship of content and human interaction is crucial and a massive investment/market opportunity. Soon it will "be" the market, literally. The most valuable product will not be a physical commodity, it will be ideas, connections, algorithms, virtual systems. We're literally witnessing the dawning of an entirely new reality, and the market leading visionaries are capitalizing on it now so they can be positioned to be the custodians of this new reality as it continues to evolve.
Thursday, April 19, 2012
Monday, December 26, 2011
in defence of the flash IDE.
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.
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.
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.
Tuesday, October 19, 2010
Samples of a windows-like scrolling window and collapsing animatable tree class in actionscript 3
http://www.northeastmagic.com/as3examples/
Everything in this example is 100% pure actionscript 3 made in FlashDevelop. I was struggling to find a real object oriented component that was editable at a very low level so I made this from scratch myself. I may add it to google code as an open source project for others to improve upon.
There are a ton of controls. The individual shapes for every part of every interface element are all classes written from scratch in AS3.
If you are interested in this class let me know at ryan @t northeastmagic dot c0m.
Everything in this example is 100% pure actionscript 3 made in FlashDevelop. I was struggling to find a real object oriented component that was editable at a very low level so I made this from scratch myself. I may add it to google code as an open source project for others to improve upon.
There are a ton of controls. The individual shapes for every part of every interface element are all classes written from scratch in AS3.
If you are interested in this class let me know at ryan @t northeastmagic dot c0m.
Thursday, September 30, 2010
Helpful hints in creating a custom facebook FBML page
Five Helpful hints when making an FBML facebook page. Hopefully this will save you some time in creating your own custom fan landing page.
Facebook page Icons: 200x200 pixels in size max. Different sizes get cropped unexpectedly so trial and error is the only way to determine what to do.
1. When the tiny icon is made, a 200x200 image gets cropped to around 165x165 then shrunk to the icon size. If you want a border around your subject, you need to make the subject smaller than 160x160 to preserve it.
2. Image artifacting. Any background color but black and white seems to cause artifacts around detailed edges. If you have text or fine
detailed vector graphics on a background, keep the background either black or white..or really busy so the artifacts look like part of the image. It also seems to preserve smoothing, so you can really blur the image if you want by setting smoothing to 8 (photoshop/fireworks)
3. a bunch of weird crap happens with IE that isnt testable outside of facebook:
-stylesheets have to be external or IE wont read them (use <link rel="stylesheet" href="http://www.mywebsite.com/myStyles.css?v=1.0" type="text/css"/>[/code] at the top of the facebook page)
-div tags cause spacing problems in tables, so if you create a table use span tags, not div tags. For some reason the div spacing issues cant be overcome with setting padding/margin/border to zero. Technically divs add a linefeed and spans dont...so perhaps thats it. Divs work fine in IE, Chrome, Safari, and Firefox outside of facebook, but not in a facebook page.
4. You cant link directly to a youtube .flv anymore (easily) so to embed youtube videos you need to link to the .swf file.
<span class="videoWindow">
<table width="240" height="145" border="0" cellpadding="0" cellspacing="0">
<tr> <td><fb:swf swfbgcolor="000000" imgstyle="border-width:0px;" swfsrc='http://www.youtube.com/v/VIDEO_ID_GOES_HERE?autoplay=1&egm=0&border=0&showsearch=0&showinfo=0&iv_load_policy=3&rel=0&color1=0x111111&color2=0x000000' imgsrc='http://www.mySite.com/images/videoLanchGraphic.png' width='240' height='145' /></td> </tr>
</table>
</span>
This will provide a simple youtube player. There are arguments you can pass are documented here:
http://code.google.com/apis/youtube/player_parameters.html#ExampleUsage
To hide the annotations and stuff, rel=0 is the most important, some of the other ones like iv_load_policy dont work without that.
4. as with all style sheets, make absolutely sure the final semi colon is at the end, any code written after it will be ignored
<style>
.myRef1{
}
.myRef2{
};
.myRef3{
}
</style>
In this case myRef3 class is ignored.
5. In the page editor, sometimes if you have code that exceeds the size of the browser window (unavoidable) after a save the window gets small and there are no scroll bars to get to the rest of your code. in firefox you can press Ctrl+a to select all and this enlarges the window to accomodate all your code.
Facebook page Icons: 200x200 pixels in size max. Different sizes get cropped unexpectedly so trial and error is the only way to determine what to do.
1. When the tiny icon is made, a 200x200 image gets cropped to around 165x165 then shrunk to the icon size. If you want a border around your subject, you need to make the subject smaller than 160x160 to preserve it.
2. Image artifacting. Any background color but black and white seems to cause artifacts around detailed edges. If you have text or fine
detailed vector graphics on a background, keep the background either black or white..or really busy so the artifacts look like part of the image. It also seems to preserve smoothing, so you can really blur the image if you want by setting smoothing to 8 (photoshop/fireworks)
3. a bunch of weird crap happens with IE that isnt testable outside of facebook:
-stylesheets have to be external or IE wont read them (use <link rel="stylesheet" href="http://www.mywebsite.com/myStyles.css?v=1.0" type="text/css"/>[/code] at the top of the facebook page)
-div tags cause spacing problems in tables, so if you create a table use span tags, not div tags. For some reason the div spacing issues cant be overcome with setting padding/margin/border to zero. Technically divs add a linefeed and spans dont...so perhaps thats it. Divs work fine in IE, Chrome, Safari, and Firefox outside of facebook, but not in a facebook page.
4. You cant link directly to a youtube .flv anymore (easily) so to embed youtube videos you need to link to the .swf file.
<span class="videoWindow">
<table width="240" height="145" border="0" cellpadding="0" cellspacing="0">
<tr> <td><fb:swf swfbgcolor="000000" imgstyle="border-width:0px;" swfsrc='http://www.youtube.com/v/VIDEO_ID_GOES_HERE?autoplay=1&egm=0&border=0&showsearch=0&showinfo=0&iv_load_policy=3&rel=0&color1=0x111111&color2=0x000000' imgsrc='http://www.mySite.com/images/videoLanchGraphic.png' width='240' height='145' /></td> </tr>
</table>
</span>
This will provide a simple youtube player. There are arguments you can pass are documented here:
http://code.google.com/apis/youtube/player_parameters.html#ExampleUsage
To hide the annotations and stuff, rel=0 is the most important, some of the other ones like iv_load_policy dont work without that.
4. as with all style sheets, make absolutely sure the final semi colon is at the end, any code written after it will be ignored
<style>
.myRef1{
}
.myRef2{
};
.myRef3{
}
</style>
In this case myRef3 class is ignored.
5. In the page editor, sometimes if you have code that exceeds the size of the browser window (unavoidable) after a save the window gets small and there are no scroll bars to get to the rest of your code. in firefox you can press Ctrl+a to select all and this enlarges the window to accomodate all your code.
Monday, September 20, 2010
Moble internet has sent us back to the stone age
Up until about 2006 when internet technology was advancing extremely fast in terms of what an RIA was capable of, we were introduced to what I would characterize as several speedbumps.
1. Facebook (in a big way, not its actual inception)
2. the iPod touch/apps/iPhone etc.
3. Google
These two massive developments effectively ended the progression towards faster, better, more elaborate technologies and set us back about 10 years in terms of what one could do with modern technology and the internet.
Facebook represented a highly simplistic html based interface with technology that had been around for 20 or 30 years. In terms of capabilities, it was not much more advanced than, say, compuserve or AOL was in 1995. Sure, the standard FBML was more open to developers, and it introduced more user friendly tools, but it fundamentally wasnt much different.
On the other hand, up to the real boom of facebook, online gaming technology like World of Warcraft, and before that Myst URU Live, and of course Second Life were pushing the boundaries of both the display engines, physics simulations, reality engines, and really appeared to be the next logical step from the 2d but fast paced and impressive flash revolution.
When HTML dominated the internet, it was largely text, tabs, scrolling, and hyperlinks. Eventually people could interact with databases via HTML form pages, and the simple form/submit/variables were born. Some java apps enabled more elaborate connectivity, but when Flash came along, eventually the graphic designer was able to directly make use of the power of database connectivity without forcing an "install" procedure. A person could simply navigate to a flash application and start "playing" then could leave, and wouldnt have to "uninstall" the specific app thanks to the flash player.
Flash took the web from simple text and static graphics to a new era of video, animation, games and sophisticated RIA's for business that could replace boring, ugly apps developed by nerds with no graphic experience or animation expertise. The visuals now took front seat while the functionality often became a side note (much to the chagrin of tech purists like Jakob Nielson, who saw technology exclusively a pragmatic object, and not a creative expression.
The flash revolution completely changed the way people saw the web.
Then Google came along, and since google was designed primarily around the idea of "webpages" which was a throwback to the flash generation which instead was developing a world of sophisticated, intelligent apps in place of "webpages", google could not understand them. The concept of websites got a breath of fresh air, and became revitalized and we saw resurgence of CSS and HTML, and the HTML format was again considered the "permanent grand master" and flash was seen again as a small quirky, strange thing often warned against with misinformation and mistrust, similar to "witchcraft" in medieval times.
Then along came facebook, which looked old fashioned and grossly simplistic to the creative developers at the time (myself included) who dismissed it at first. The hook, however, which proved to be more important than pragmatism OR creative expression was the end users ability to assert themselves. Up to the facebook revolution, creative and technological elitists had reserved the right to produce content for large audiences much like television broadcasters had reserved that right for themselves in the channel. The "broadcast" world became the "conversation world", and the "audience" became far more interested in each other than the content being shoveled at them by anonymous "experts".
This perplexed both the google/html experts and the flash experts, and to survive, both had to learn to play facebook's way or be left behind. Google continues to struggle with this and may actually be forced to completely change, reinvent itself, or simply become obselete as facebook search replaces it entirely - relegating it to a plugin for wikipedia and other large information repositories.
Up to this point, both facebook and google's technology pushed the state of the art backwards in terms of sophisticated application development...google with its HTML dependent design, and facebook with its proprietary but largely HTML centric design. Savvy flash developers have managed to integrate the technology into facebook in things like Farmville, but flash is not really being taken advantage of or pushed to new levels, its actually working to be compatible with legacy, dated technologies offered by Facebook and Google.
Enter Second Life. When Second Life came along, as a flash developer, I was honestly intimidated. It seemed that it could run circles around flash by simulating not only 2d animation, but 3d animation, sophisticated artwork, creativity, and reality engines. The true state of the art exhibited previously in stand along video games now in an open engine, available to developers. Things like HTML and Flash on a prim surface made those two technologies seem laughable, and its API put it in the next logical step toward the "holodeck" along with its interchangeable physics engine, developer tools, and scripting engine.
At the time of Second Life's peak, it was in the news almost daily, and one could fart in second life and it would make front page of CNN. It seemed unchallenged and unbeatable in terms of potentially taking the RIA to the next level.
(I'm ignoring the concept of cloud computing here because the concept, while important as a fundamental shift in app management, is grossly overhyped - its important like the standard voltage of electricity in homes is important, but not really worthy of news or discussion per se as its not particularly innovative anymore, its just a natural progression)
Then along comes the iPod touch. These tiny devices were extremely revolutionary ONLY in that they made what was already technically available more "inviting" and popular thanks to Apple's branding and clever marketing. They are the coca cola of technology. Fizzy sugar water had been around for many years prior to coca cola, but coke packaged it and made it viable into what is still one of the most popular non-nutritionally valuable foods ever.
The iPod touch was particularly important because it took available processor capabilities at a small size, stripped off all the least popular features on hand held PC's, and made the interface elegant and easy to use. This changed everything, and because technologies like flash and second life were not capable of displaying on such low-power devices, they took a second seat to the "revolution" of the mobile app.
Mobile apps, in truth, are grossly inferior to the state of the art of the RIA on a desktop or laptop computer, but are more popular largely due to the fact that they are available on the terms of the consumer rather than the content distributor.
I dont, for example, want to play internet checkers while I'm sitting at my desktop, but I do when I'm about to go to bed, or riding in a long bus or cab ride to help pass the time.
I would love to play second life in that time, but it just isn't feasable. The display is too small, cant handle the processor speeds, and is too hard to manipulate while I'm holding the little thing.
So in effect, between facebook, google and Apple, the entire move towards progress in display technology has been put on hold while a new "revolution" of getting people to integrate these devices and platforms into their lives occurs.
The future prediction that follows is once the public is on board with these devices and rather simple technology, content will become king once more as consumers become "bored" with facebook, google, and iPhones/ipads/ipods etc. That, you can count on.
1. Facebook (in a big way, not its actual inception)
2. the iPod touch/apps/iPhone etc.
3. Google
These two massive developments effectively ended the progression towards faster, better, more elaborate technologies and set us back about 10 years in terms of what one could do with modern technology and the internet.
Facebook represented a highly simplistic html based interface with technology that had been around for 20 or 30 years. In terms of capabilities, it was not much more advanced than, say, compuserve or AOL was in 1995. Sure, the standard FBML was more open to developers, and it introduced more user friendly tools, but it fundamentally wasnt much different.
On the other hand, up to the real boom of facebook, online gaming technology like World of Warcraft, and before that Myst URU Live, and of course Second Life were pushing the boundaries of both the display engines, physics simulations, reality engines, and really appeared to be the next logical step from the 2d but fast paced and impressive flash revolution.
When HTML dominated the internet, it was largely text, tabs, scrolling, and hyperlinks. Eventually people could interact with databases via HTML form pages, and the simple form/submit/variables were born. Some java apps enabled more elaborate connectivity, but when Flash came along, eventually the graphic designer was able to directly make use of the power of database connectivity without forcing an "install" procedure. A person could simply navigate to a flash application and start "playing" then could leave, and wouldnt have to "uninstall" the specific app thanks to the flash player.
Flash took the web from simple text and static graphics to a new era of video, animation, games and sophisticated RIA's for business that could replace boring, ugly apps developed by nerds with no graphic experience or animation expertise. The visuals now took front seat while the functionality often became a side note (much to the chagrin of tech purists like Jakob Nielson, who saw technology exclusively a pragmatic object, and not a creative expression.
The flash revolution completely changed the way people saw the web.
Then Google came along, and since google was designed primarily around the idea of "webpages" which was a throwback to the flash generation which instead was developing a world of sophisticated, intelligent apps in place of "webpages", google could not understand them. The concept of websites got a breath of fresh air, and became revitalized and we saw resurgence of CSS and HTML, and the HTML format was again considered the "permanent grand master" and flash was seen again as a small quirky, strange thing often warned against with misinformation and mistrust, similar to "witchcraft" in medieval times.
Then along came facebook, which looked old fashioned and grossly simplistic to the creative developers at the time (myself included) who dismissed it at first. The hook, however, which proved to be more important than pragmatism OR creative expression was the end users ability to assert themselves. Up to the facebook revolution, creative and technological elitists had reserved the right to produce content for large audiences much like television broadcasters had reserved that right for themselves in the channel. The "broadcast" world became the "conversation world", and the "audience" became far more interested in each other than the content being shoveled at them by anonymous "experts".
This perplexed both the google/html experts and the flash experts, and to survive, both had to learn to play facebook's way or be left behind. Google continues to struggle with this and may actually be forced to completely change, reinvent itself, or simply become obselete as facebook search replaces it entirely - relegating it to a plugin for wikipedia and other large information repositories.
Up to this point, both facebook and google's technology pushed the state of the art backwards in terms of sophisticated application development...google with its HTML dependent design, and facebook with its proprietary but largely HTML centric design. Savvy flash developers have managed to integrate the technology into facebook in things like Farmville, but flash is not really being taken advantage of or pushed to new levels, its actually working to be compatible with legacy, dated technologies offered by Facebook and Google.
Enter Second Life. When Second Life came along, as a flash developer, I was honestly intimidated. It seemed that it could run circles around flash by simulating not only 2d animation, but 3d animation, sophisticated artwork, creativity, and reality engines. The true state of the art exhibited previously in stand along video games now in an open engine, available to developers. Things like HTML and Flash on a prim surface made those two technologies seem laughable, and its API put it in the next logical step toward the "holodeck" along with its interchangeable physics engine, developer tools, and scripting engine.
At the time of Second Life's peak, it was in the news almost daily, and one could fart in second life and it would make front page of CNN. It seemed unchallenged and unbeatable in terms of potentially taking the RIA to the next level.
(I'm ignoring the concept of cloud computing here because the concept, while important as a fundamental shift in app management, is grossly overhyped - its important like the standard voltage of electricity in homes is important, but not really worthy of news or discussion per se as its not particularly innovative anymore, its just a natural progression)
Then along comes the iPod touch. These tiny devices were extremely revolutionary ONLY in that they made what was already technically available more "inviting" and popular thanks to Apple's branding and clever marketing. They are the coca cola of technology. Fizzy sugar water had been around for many years prior to coca cola, but coke packaged it and made it viable into what is still one of the most popular non-nutritionally valuable foods ever.
The iPod touch was particularly important because it took available processor capabilities at a small size, stripped off all the least popular features on hand held PC's, and made the interface elegant and easy to use. This changed everything, and because technologies like flash and second life were not capable of displaying on such low-power devices, they took a second seat to the "revolution" of the mobile app.
Mobile apps, in truth, are grossly inferior to the state of the art of the RIA on a desktop or laptop computer, but are more popular largely due to the fact that they are available on the terms of the consumer rather than the content distributor.
I dont, for example, want to play internet checkers while I'm sitting at my desktop, but I do when I'm about to go to bed, or riding in a long bus or cab ride to help pass the time.
I would love to play second life in that time, but it just isn't feasable. The display is too small, cant handle the processor speeds, and is too hard to manipulate while I'm holding the little thing.
So in effect, between facebook, google and Apple, the entire move towards progress in display technology has been put on hold while a new "revolution" of getting people to integrate these devices and platforms into their lives occurs.
The future prediction that follows is once the public is on board with these devices and rather simple technology, content will become king once more as consumers become "bored" with facebook, google, and iPhones/ipads/ipods etc. That, you can count on.
Subscribe to:
Posts (Atom)
