July 16th 2010
Let’s be honest, Flash’s trace functionality is pretty substandard. It provides no useful information besides what you’ve asked it to output. Unlike something like HaXe, you cannot extend it or extract anything from it that really helps you debug your code and when you’ve got a lot of traces in your application or project, it becomes messy and incredibly hard to manage. A while back I created and we’ve since been using a utility class that makes tracing much more user friendly and provides some additional information and functionality that would seem obvious to have in the first place. Additionally, it was important to me to have something that is lightweight and easy to use, with no need to install anything extra – just a class/swc for inclusion in your project, and no additional dependencies.
Firstly, you are able to toggle all of your traces on or off in a single line of code – no need for additional compiler settings. Secondly, the traces that are output include both the name of the class that has made the trace call as well as the line number it happened. This is hugely beneficial, particularly when you are working on a big project with a lot of traces dotted throughout your code. You’ll immediately be able to distinguish your different trace statements and can head to the exact line that you made the call, and if you want to remove the trace statement, you know exactly where to find it. Third, it provides the option of adding in a timestamp to your traces. This aids in keeping track of when things happen and what amount of time has elapsed between different calls to the trace function. Lastly, the traces can be toggled on and off at runtime, which can be very useful when you need to deploy a debug version to a live environment, but don’t want your traces showing up to inspectors like Flash Tracer and the like, unless you’ve specified it to do so.
The class is very easy to use. To initialise it, simply call its static function “init” (most likely in your document or preloader class), and specify whether you want traces on/off, an optional timestamp flag, and optionally set the stage for keyboard capture:
Tracer.init(true, true, stage);
After this, you can just make calls to the static method ‘out’ to output trace statements:
Tracer.out("This is a trace");
If you have specified the third parameter, stage, in the init function, you can toggle the debug mode on and off by pressing the keys of the word “debug”.
Source code and SWC can be got here.
March 8th 2010
Getting the correct workflow for your agency is a complex and non-trivial task. We are constantly trying to streamline the way we work, to improve on our processes and establish ways in which we can produce our work in the most effective and satisfactory manner, both for ourselves and our clients. Dealing with projects both small and large begs so many questions about what the correct ways are to roll it out, about what would be cost-effective for the agency as well as our clients, and end up making everybody happy. One of the biggest areas of trouble during any project is when there is a breakdown of communication of some sorts. This can happen very easily between the agency and the client, but very often is prevalent internally as well. The creation of a web site involves many players and thus successful communication between all involved is critical to the success of the job. Internally, project managers need to communicate with the production team, and the production team itself needs to have a clear avenue of communication and understanding with the various team members. If, at some point, someone fails to understand clearly how they are supposed to design or develop something, there can often be quite serious repercussions, considering the time it takes to fix mistakes is usually the longest. So I want to briefly put some thoughts down on why I find prototyping to be a valuable part of a project’s lifecycle.
Planning out a project properly is an essential aspect to its success. This can involve as simple things as basic sketches, through proper wireframing, to comprehensive modelling and documentation. However, if communication has broken down at some point, then one might spend a lot of time planning and documenting an incorrect job. Additionally, comprehensive documentation and planning can take up a lot of time of a project before anyone, especially the client, has even seen anything. Once this is done, the documentation might be put up for review, either internally or to the client, and if issues come up, the ripple effect can be substantial. Quinlan (http://www.appcelerant.com/get-rich-quick-ria-prototyping.html) talks about a project he worked on where, as “the project progressed and I saw the size of the document balloon from 50 pages to more than 200 pages, I had the realization that this document would never be read by ANYONE from beginning to end. The business owners who were responsible for ensuring that the requirements fit their actual business needs were completely overwhelmed by the document’s size and complexity. Six months later the business users were given their shiny new software and they were disappointed that the software didn’t match their expectations.” Proper documentation like this is no doubt still preferable to no planning and producing a product that is unsatisfactory which then has to be mended in order to satisfy the business needs, ending up consuming a lot of your budget and creating a general state of unhappiness in and between the people involved. But there is a way to streamline the process even more during the planning and initial development phases, and this involves the effective use of prototyping.
Prototyping really comes into life when you are developing RIAs, as wireframing, simple planning, and other forms of documentation rarely captures the feel of what you are developing. With complicated interfaces that include a lot of animations and conceptual aspects to deliver the message of the brand, static documentation is almost always ineffective in providing a clear understanding of what the project will be like when it is completed. And this is where communication starts to break down. But, as Staley (http://www.adobe.com/devnet/flex/articles/planning_ria/planning_ria.pdf) mentions in his article ‘Planning for RIA success’, “a key consideration is that a prototype can help establish expectations on design, functionality, and the resulting requirements of an application. This is particularly relevant to RIAs, because in many cases, the team will be venturing into unfamiliar terrain. Because of this uncertainty, traditional software development project techniques can be difficult to apply. A certain amount of discovery is required in the RIA process. Put another way, user experience design is of particular importance in an RIA, and it is often difficult to predict the outcome of an iterative design process.” In order to give everyone a sense of what you are creating, it is much easier and clearer when you can actually show them what you have in mind.
It is important to strike a good balance when doing this, as you wouldn’t want to create something twice, so prototyping should be a quick process meant to illustrate your point, hence the term rapid-prototyping. When you have something in mind for a particular project it can often save a lot of time and trouble if you are able to show the relevant parties something early on. This will help project managers, designers and developers work together more closely and effectively, provide clients with the means to understand what you are proposing (rather than a stale presentation filled with conceptual discussions on the merits of a fade, transition, or user experience), as well as catching usability issues early on. As discussed on A List Apart, (http://www.alistapart.com/articles/sketchingincode/) “Prototypes can help you sell a decision that is fundamentally or radically different from the client’s current solution or application. The traditional approach is to create a compelling story and a riveting PowerPoint presentation, and spend a day arguing for the wisdom of your approach. Instead, sit a stakeholder down in front of a working prototype and show him or her why your approach is compelling.”
Once you have created a prototype of some aspect of your project, it is always easy to spot the areas which don’t work, and identify the things that need to be changed or improved upon. Very importantly as well, once you have worked out where your prototype works and where it doesn’t, creating proper planning documentation and rolling out the final product takes a very short amount of time, and is usually spot on in terms of the business requirements. In this way, effective use of prototyping manages to clear up the avenues of communication, as management can quickly establish whether production has understood their tasks and clients can quickly see whether the agency has understood the brief. If not, adapting the prototype is not as serious a matter as rewriting your comprehensive set of documentation or redeveloping major aspects of a site where the effects of a simple problem can undermine the rest of your project to such a large extent that it ends up destroying your budget, team morale and client agency relationships.
Ideas in a creative environment are often very conceptual, and one person’s idea might be completely different to that of another’s. In turn, clients have particular visions for their products, project managers have their own, creative directors have theirs, and the production team have their own. These ideas aren’t always easy to put down on paper, but with the proper use of prototyping, those ideas can be married much more effectively and the overall success of a project is much more certain. Making good use of prototypes during the development of your project opens up communication and helps to ensure the success of your project.
Marc Newson’s concept design for Ford. A car that never saw the light of day due to the negative feedback this prototype received.
Getting the correct workflow for your agency is a complex and non-trivial task. We are constantly trying to streamline the way we work, to improve on our processes and establish ways in which we can produce our work in the most effective and satisfactory manner, both for ourselves and our clients. Dealing with projects both small and large begs so many questions about what the correct ways are to roll it out, about what would be cost-effective for the agency as well as our clients, and end up making everybody happy. One of the biggest areas of trouble during any project is when there is a breakdown of communication of some sorts. This can happen very easily between the agency and the client, but very often is prevalent internally as well. The creation of a web site involves many players and thus successful communication between all involved is critical to the success of the job. Internally, project managers need to communicate with the production team, and the production team itself needs to have a clear avenue of communication and understanding with the various team members. If, at some point, someone fails to understand clearly how they are supposed to design or develop something, there can often be quite serious repercussions, considering the time it takes to fix mistakes is usually the longest. So I want to briefly put some thoughts down on why I find prototyping to be a valuable part of a project’s lifecycle.
Planning out a project properly is an essential aspect to its success. This can involve as simple things as basic sketches, through proper wireframing, to comprehensive modelling and documentation. However, if communication has broken down at some point, then one might spend a lot of time planning and documenting an incorrect job. Additionally, comprehensive documentation and planning can take up a lot of time of a project before anyone, especially the client, has even seen anything. Once this is done, the documentation might be put up for review, either internally or to the client, and if issues come up, the ripple effect can be substantial.Quinlan talks about a project he worked on where, as “the project progressed and I saw the size of the document balloon from 50 pages to more than 200 pages, I had the realization that this document would never be read by ANYONE from beginning to end. The business owners who were responsible for ensuring that the requirements fit their actual business needs were completely overwhelmed by the document’s size and complexity. Six months later the business users were given their shiny new software and they were disappointed that the software didn’t match their expectations.” Proper documentation like this is no doubt still preferable to no planning and producing a product that is unsatisfactory which then has to be mended in order to satisfy the business needs, ending up consuming a lot of your budget and creating a general state of unhappiness in and between the people involved. But there is a way to streamline the process even more during the planning and initial development phases, and this involves the effective use of prototyping.
Prototyping really comes into life when you are developing RIAs, as wireframing, simple planning, and other forms of documentation rarely captures the feel of what you are developing. With complicated interfaces that include a lot of animations and conceptual aspects to deliver the message of the brand, static documentation is almost always ineffective in providing a clear understanding of what the project will be like when it is completed. And this is where communication starts to break down. But, as Staley mentions in his article ‘Planning for RIA success’, “a key consideration is that a prototype can help establish expectations on design, functionality, and the resulting requirements of an application. This is particularly relevant to RIAs, because in many cases, the team will be venturing into unfamiliar terrain. Because of this uncertainty, traditional software development project techniques can be difficult to apply. A certain amount of discovery is required in the RIA process. Put another way, user experience design is of particular importance in an RIA, and it is often difficult to predict the outcome of an iterative design process.” In order to give everyone a sense of what you are creating, it is much easier and clearer when you can actually show them what you have in mind.
It is important to strike a good balance when doing this, as you wouldn’t want to create something twice, so prototyping should be a quick process meant to illustrate your point, hence the term rapid-prototyping. When you have something in mind for a particular project it can often save a lot of time and trouble if you are able to show the relevant parties something early on. This will help project managers, designers and developers work together more closely and effectively, provide clients with the means to understand what you are proposing (rather than a stale presentation filled with conceptual discussions on the merits of a fade, transition, or user experience), as well as catching usability issues early on. As discussed on A List Apart, “Prototypes can help you sell a decision that is fundamentally or radically different from the client’s current solution or application. The traditional approach is to create a compelling story and a riveting PowerPoint presentation, and spend a day arguing for the wisdom of your approach. Instead, sit a stakeholder down in front of a working prototype and show him or her why your approach is compelling.”
Once you have created a prototype of some aspect of your project, it is always easy to spot the areas which don’t work, and identify the things that need to be changed or improved upon. Very importantly as well, once you have worked out where your prototype works and where it doesn’t, creating proper planning documentation and rolling out the final product takes a very short amount of time, and is usually spot on in terms of the business requirements. In this way, effective use of prototyping manages to clear up the avenues of communication, as management can quickly establish whether production has understood their tasks and clients can quickly see whether the agency has understood the brief. If not, adapting the prototype is not as serious a matter as rewriting your comprehensive set of documentation or redeveloping major aspects of a site where the effects of a simple problem can undermine the rest of your project to such a large extent that it ends up destroying your budget, team morale and client agency relationships.
Ideas in a creative environment are often very conceptual, and one person’s idea might be completely different to that of another’s. In turn, clients have particular visions for their products, project managers have their own, creative directors have theirs, and the production team have their own. These ideas aren’t always easy to put down on paper, but with the proper use of prototyping, those ideas can be married much more effectively and the overall success of a project is much more certain. Making good use of prototypes during the development of your project opens up communication and helps to ensure the success of your project.
February 4th 2010
Flash has always had its naysayers. I have been a developer for many years now with a strong focus on flash, and have repeatedly had to defend myself against the onslaught of anti-flash sentiments. Many have been valid, and many have been based on an expression of other things entirely. With the history of flash starting in the timeline and silly gotoAndPlay scripts that were used to make some incredible shockers, it’s no wonder that it had such a bad rep to shake off. These days, however, the language is robust and its features are many, the community is huge, the spread is wide and the results are truly amazing. But still we have to fight, and after the recent developments over at Apple, really even more so now than ever. But the question is not really about fighting for flash, it’s about why we should have to fight for flash.
Apple’s non-Flash stance has been around for a while, but most people were convinced that they would one day open up full support for Flash. With the release of the IPad and it’s demonstration displaying huge craters of non-Flash bits of web (http://bits.blogs.nytimes.com/2010/01/31/why-the-ipad-web-demo-was-full-of-holes/), it has become pretty clear that this is not to be. Steve Jobs has made his position pretty clear (http://www.wired.com/epicenter/2010/01/googles-dont-be-evil-mantra-is-bullshit-adobe-is-lazy-apples-steve-jobs/) and developers and digital agencies are left with some serious decisions to make. Strictly speaking, whether Flash is dying or not shouldn’t be much of a concern. Many users aren’t interested in what technology they view their content on, as long as it delivers it well and in an interesting way. As far as I’m concerned, bar a few ideological points it is not important for me whether I need to develop in ruby, php, Flash, silverlight, html5, objective-c or whatever else. I have some preferences about some languages, but often find I like some languages for certain aspects. Because of this, if Flash were truly dying, it would be a simple matter – move on to the next thing.
The major issue in the current climate is that Flash isn’t dying, or at least it isn’t doing so any time soon. Previously, with the fight between Silverlight and Flash, there wasn’t too much going on, because it was simply a matter of installing the right plugin and you could view your content on either platform, so if an agency focused on Silverlight, no problem, if they focused on Flash, no problem, if they focused on Unity, no problem. The user experience would be much the same. And as it stands right now, Adobe’s CEO Kevin Lynch, mentions that Flash’s latest player will deploy to many devices including “Google’s Android, RIM’s Blackberry, Nokia, Palm Pre and many others across form factors including not only smartphones but also tablets, netbooks, and internet-connected TVs”, and its lack of presence on Apple devices is because Adobe has “not had the required cooperation from Apple to make this happen”, but they “are ready to enable Flash in the browser on these devices if and when Apple chooses to allow that for its users”. With Apple’s active stance against Flash-support, the situation is now different to before. Agencies cannot ignore the fact that the content they deliver to their client’s userbase might not be viewable if they focus on a single target. This isn’t entirely new, and agencies have often had fallbacks in the event of their content not being viewable in a particular way, but the impetus for this has been raised quite a bit now.
The way I see it, it is just a great big pain that we are now forced into specific platforms. With Flash still going very strong, and with its much superior capabilities to HTML5 as well as being a much nicer language than something like Javascript, it still offers some of the best ways for us to deliver content to users. So we will keep using it. But with its blatant ommission from certain platforms like the IPhone and the IPad, we are now forced to duplicate our development practices simply so we can satisfy a market that predominantly doesn’t care or know whether they view their content on Flash or not. And this is all because Apple is following in the footsteps of Microsoft and closing the doors to everything else. I find this utterly annoying. The unfortunate outcome of this is that it will cost more to have your content delivered to your user base, because it needs to be developed and targeted to multiple platforms.
As it goes, though, I am still very excited to be developing for new platforms and in new languages. I just wish Apple didn’t compromise their users and complicate developers’ lives by preventing certain things from working on their devices – it just doesn’t feel great. But their choices won’t be affecting things too much for quite some time. Flash still dominates and is a remarkable, certainly among the best, tool for delivering rich interactive experiences, whilst Apple’s devices are not ubiquitous enough to be a true Flashkiller, as quite a few have ventured to say. Many markets in the world have hardly any Apple devices, so for now, Flash development can carry on as per usual.
Flash has always had its naysayers. I have been a developer for many years now with a strong focus on flash, and have repeatedly had to defend myself against the onslaught of anti-flash sentiments. Many have been valid, and many have been based on an expression of other things entirely. With the history of flash starting in the animation timeline and silly gotoAndPlay scripts that were used to make some incredible shockers, it’s no wonder that it had such a bad rep to shake off. These days, however, the language is robust and its features are many, the community is huge, the spread is wide and the results are truly amazing. But still we have to fight, and after the recent developments over at Apple, even more so now than ever. But the question is not really about fighting for Flash, it’s about why we should have to fight for Flash.
Apple’s non-Flash stance has been around for a while, but most people were convinced that they would one day open up full support for Flash. With the release of the IPad and it’s demonstration displaying huge craters of non-Flash bits of web, it has become pretty clear that this is not to be. Steve Jobs has made his position pretty clear and developers and digital agencies are left with some serious decisions to make. Strictly speaking, whether Flash is dying or not shouldn’t be much of a concern. Many users aren’t interested in what technology they view their content on, as long as it delivers it well and in an interesting way. As far as I’m concerned, bar a few ideological points it is not important for me whether I need to develop in Ruby, PHP, Flash, Silverlight, HTML5, Objective-C or whatever else. I have some preferences about some languages, but often find I like some languages for certain aspects. Because of this, if Flash were truly dying, it would be a simple matter – move on to the next thing.
The major issue in the current climate is that Flash isn’t dying, or at least it isn’t doing so any time soon. Previously, with the fight between Silverlight and Flash, there wasn’t too much going on, because it was simply a matter of installing the right plugin and you could view your content on either platform, so if an agency focused on Silverlight, no problem, if they focused on Flash, no problem, if they focused on Unity, no problem. The user experience would be much the same. And as it stands right now, Adobe’s CTO Kevin Lynch, mentions that Flash’s latest player will deploy to many devices including “Google’s Android, RIM’s Blackberry, Nokia, Palm Pre and many others across form factors including not only smartphones but also tablets, netbooks, and internet-connected TVs”, and its lack of presence on Apple devices is because Adobe has “not had the required cooperation from Apple to make this happen”, but they “are ready to enable Flash in the browser on these devices if and when Apple chooses to allow that for its users”. With Apple’s active stance against Flash-support, the situation is now different to before. Agencies cannot ignore the fact that the content they deliver to their client’s userbase might not be viewable if they focus on a single target. This isn’t entirely new, and agencies have often had fallbacks in the event of their content not being viewable in a particular way, but the impetus for this has been raised quite a bit now.
The way I see it, it is just a great big pain that we are now forced into specific platforms. With Flash still going very strong, and with its much superior capabilities to HTML5 as well as being a much nicer language than something like Javascript, it still offers some of the best ways for us to deliver content to users. So we will keep using it. But with its blatant ommission from certain platforms like the IPhone and the IPad, we are now forced to duplicate our development practices simply so we can satisfy a market that predominantly doesn’t care or know whether they view their content on Flash or not. And this is all because Apple is following in the footsteps of Microsoft and closing the doors to everything else. I find this utterly annoying. The unfortunate outcome of this is that it will cost more to have your content delivered to your user base, because it needs to be developed and targeted to multiple platforms.
As it goes, though, I am still very excited to be developing for new platforms and in new languages. I just wish Apple didn’t compromise their users and complicate developers’ lives by preventing certain things from working on their devices – it just doesn’t feel great. But their choices won’t be affecting things too much for quite some time. Flash still dominates and is a remarkable, certainly among the best, tool for delivering rich interactive experiences, whilst Apple’s devices are not ubiquitous enough to be a true Flashkiller, as quite a few have ventured to say. Many markets in the world have hardly any Apple devices, so for now, Flash development can carry on as per usual.
