Below is the transcript from commentary from my interview in the book: Flash AS3 for Interactive Agencies,
An Insider Guide to Interactive Agency Flash Development by Randall W. Haws - Published 2009 by Haws Press
Strategies
Let's get into the zone and really talk about what it's like to be part of this thing they call Interactive/Digital. What are some of the strategies for Flash developers working at interactive agencies regarding program and software architecture?
I would say that the key would be having a game plan. With rapid development or prototyping it's really important to lay out your IA, user flow, test cases, and class structure. A lot of people may do IA, but they don't do class structure.
I see tons of projects where clearly they didn't have a plan for how they were going to structure their classes and things ended up being a complete mess.
Right, and the term you often see in books is referred to as a UML diagram, and you often see people's heads turn sideways with a look of, "Oh my gosh, what is a UML diagram?" That's the first sign that something is wrong in the strategy for their IA.
You often have someone constructing IA inside a PowerPoint presentation with boxes and lines that gets shipped off to the client and also to production. Then the developers look at it and don't see any error handling nor do they see the anticipation for the possible user flow and various interactions.
How do you think the IA and user flow needs to be strategized when you factor in class structures? Is this just a two stage or a multistage approach?
For me, I need the IA and user flow before I can think about the class structure. Of course, I have some general class structures and methods that I typically use, but I think you have to have the IA and user flow before you can effectively construct the class structures. With IA, what you are really talking about is all things functional and the class structure should reflect that.
So is the user flow constructed by the same people that do the IA or does it require additional passes by other people?
It depends. Sometimes it can be the same people. Like the project we worked on recently for a large telecom client, where we developed a 60 page user flow document that was not the IA.
It was huge.
Yes, I remember after we constructed the user flow (with the help of a seasoned IA/BA guy), we referred to this document as the 10,000 foot view, before we even reached any of the granular details.
Right, once you see that, then it gives you a clear indication on how you need to structure the classes and architecture of the framework for the program. For smaller projects, that's probably overkill. You may need a little bit of IA.
If you are doing a simple microsite in Flash, you may not need to write it down, but you certainly need to know how you are going to structure and develop it.
And that really has to be a strategy that is completed before production begins, right?
Absolutely, no doubt about it.
Okay, so we're always talking about having all of these rules. In the real world, for the interactive and digital agency, we always seem to have exceptions for these rules.
What are these common exceptions, why do we run into them, and why do we continually run into them?
I think part of the reason is because there is nothing that is going to be a "fit all" scenario, and I think that we have to be sharp enough to realize that there are going to be exceptions.
Sometimes, part of it is how much time you have. Maybe we only have a week and a half to get something produced? We have to build this whole thing inside of 10 days. Let's say we live in a perfect world and our comps are done... the designs are done, and everything is taken care of.
Still, for a relatively complex site, a week and a half isn't much time. So we may not be able to do much of a thorough IA and class structure as we'd like to. But, we still need to do something.
I think in some cases, particularly with budget and time constraints, we may decide to abandon doing anything class-based altogether, where we go with a more procedural/object-oriented hybrid approach.
I am not saying that we need to do some really ugly stuff where you have multiple functions defined in multiple nested movie clips. I hate that. You can't find anything. That's not what I'm talking about. We should certainly try to mimic some of the positive aspects of a class-based structure and it will make things a lot easier.
This is one of those exceptions. If it's easier, saves time, and a couple of code comments can convey what is going on and why, then it is absolutely okay when weighed against the timeline and production schedule.
We just have to be careful not to hack or shortcut stuff together without thinking and providing a clear strategy as to why we are doing that and determine if it really benefits the program as a whole.
So you are saying that we should not code ourselves into a corner, but if we must, we leave a roadmap and clear instructions as to what we are doing, right?
Exactly. You don't have to document everything completely. Try to be thorough and consistent when you have to make these exceptions. Define it, comment it, and call it good.
If it saves you two days of production and you're clear about what you did and why, then I think that's ok.
That reminds me of a project we worked on a while ago where the Flash was heavily integrated with Maya 3D rendered assets. We had to parallax different layers of rendered assets, and write a lot of custom code to facilitate that from the original concept.
Since the timeline was only about 4 weeks to complete the project, how is it that we created exceptions to these rules where we eventually pulled this thing off?
Actually, in that project, it was closer to three and a half weeks for creative and the development. We had no comps. All we had was a loose concept that was already sold and signed off on by the client (no discussion with creative or production at all).
Yes and there was a huge 3D element to the entire site's design that needed to be created before we could even deliver the comps.
Totally. We ended up going with 3D instead of illustrations because it was simply going to be easier. We both looked at it and thought, let's get some stock 3D assets, tweak them and render them into the comps. Then, if they come back with subtle changes or edits, like a fly through or a camera angle, we can easily do it, hit render, and send the new comps away just like that. That way, we didn't have to worry about a fleet of illustrators taking a few days to change a fly through. That's a few days we didn't have to spare.
So true. We quickly realized that this was also a time saver with pulling in the new assets and renders. We performed batch rendering in Maya to output to the various comps and source files. I remember, I literally wrote some MEL script, clicked a button, and you received all the applicable rendered images ready to go for the comps and for importation into Flash. It really was very easy for you to manage hundreds of 3D rendered image sequences I was batching out of Maya and Photoshop.
Absolutely. And, it really looked cool! At the time, there was not a lot of 3D stuff out there, and this looked really great. That was one of the reasons for our chosen strategy. We talked about the different workflows and advantages of the rendering the assets inside the 3D world and it just made sense for our timeline and budget.
One of the reasons I ended up going with a tab-based UI was to just make it a "no-brainer"... so the client would sign off right away. If we would have had to go through more rounds of additional UI revisions and comps, there was no way we'd hit the deadline. We approached the code the same way. We didn't even consider doing this class-based, as it would have just taken too long and we didn't have enough time to properly plan it out.
I remember we just ended up doing a majority of the animations on the timeline, sort of old school. We did it on the timeline because it was easy, fast, and we could get it done in minutes.
Right, we didn't have a team of developers working on this. It was just you and me. No one else was going to be touching my Maya 3D scenes and no one was going to be touching your Flash code. It just made sense that I was in charge of the 3D and you were in charge of the Flash. We both know each other's tasks, but we focused on what we needed to get done and who would actually do what.
And, we got it done! You really couldn't tell later that we used a lot of shortcuts and went a bit old school.
I agree, and that was the key to that project. We put it together inside of three and a half weeks, it looked really well. We made a heavy use of parallax, so it seemed very interactive. We ended up leveraging tween classes to handle the parallax layers integration.
Essentially, from a structural standpoint, we really went as fast as we could and still tried to follow some of the basic rules. We didn't do it class-based. We hacked together a lot of the behind the scenes stuff and broke a lot of the standard rules and guidelines long the way.
However, all the functions were in one place in the main FLA file on the first frame in the timeline. It was literally all right there.
Today, you could go back and take a look at that source file and you don't have to hunt for stuff to figure out what is going on.
So true. It was like we learned how to make this complex task extremely simple. It had some scalability for changes and revisions. It could have easily become overcomplicated. We wouldn't let that happen, because we wouldn't have made the deadline. We also knew about the development time and budget and the potential impact on the end user.
Absolutely. It involved taking into account the feedback from the client, project manager, and account team. We tried to develop something that accomplished most of what everyone wanted to see. We didn't agree to anything that would jeopardize the project deadline. This was a hard deadline for the client.
There was a large media buy that coincided with the deadline and there was a bunch of other factors involved where we just couldn't miss it. We realized what we needed to do, which was utilize the 3D to maximize our workflow and processes for meeting the deadline. We designed the overall code structure to be written in a way that was not overcomplicated. We knew where to spend the greatest amount of time and that was on the parallax integration.
It took several days to tweak the parallax coding. That doesn't sound like much, but when you only have two weeks of development time, a few days subtracted from that is a big chunk of time devoted just to the parallax coding. We needed to get the parallax just right because it was a huge part of the site and a huge impact on the end user's experience.
One of the things we always talk about is that while it's great to do cool stuff, if it's too complicated and time consuming, is there really a payoff? I have seen a number of cases where you are looking at user flow documents and, let's say the login portion is overly complicated to the point of being ridiculous. It could take you weeks just to do the login screen.
No one is ever going to look at such an overly complicated login routine and say, "That's the coolest login I have ever seen!"
Right, they just want to log in!
[laughs] Right! The end user has no desire to know how complicated it was for them to log in. Keep it simple and simply log them in! On the other hand, you could spend several days working on a cool special effect and if the end user says it was so cool, then it was worth it.
That brings me to my next point. We accepted that project on such a tight deadline because we both knew what we were developing and we knew how to develop it. Our combined expertise helped to really mesh this project together with minimal adversity. The things we stayed away from were using idolized developer code and other third-party stuff out there being used a lot of the time.
Yeah, there was no time for that whatsoever.
We also stayed away from the "learn as you go approach" as much as possible. We understood the workflow necessary to pull this thing off. What were some of the developmental integrations executed on that project that helped us eventually make the deadline with the highest quality possible?
I think because the deadline was so tight, we had to figure out a way to throw it together as fast as possible, while adhering to best practices and standards. We needed to get something up and working, even if that meant going back and cleaning up some stuff after the fact.
Say we delivered this on the last day, without anyone seeing it beforehand. The client could have said, "This is terrible!" We had to focus and develop what was absolutely crucial to the system as a whole, and get it to work first. We had to get the critical stuff done first, even without the 3D stuff and parallax so that the client can look at it and sign off on it. That ultimately was the key. It wasn't perfectly smooth and glossy at first and was not the most efficient way to code it initially. It would have been a nightmare to have finished and then have the client make a change that adversely affected the entire thing and we end up missing the deadline.
Right. Something else we did on this project was that we leveraged the open-source community for some of the Maya 3D assets as a starting point for creative and as a foundation for the concept. I remember working with the full-screen 3D rendered image sequences in Flash was a little problematic. We were constantly changing compression settings and render settings. I had to do a lot of R&D before even beginning the Maya workflow and rendering.
We had to worry about how we were going to manage file size in both the FLA source file and the published SWF file. And, we resisted the urge to show the client the skinned version of the project too prematurely. There was too much of a risk of spending too much time making it pretty and then not getting the coding finished. That could have led to even bigger problems.
When it looks rough, and we let the client know it, we can try and control what we need them to focus on. Because what we really needed was for them to review and sign off. Clients can sometimes have a tendency to pull apart the polished product instead of focusing on the critical review elements at hand.
That reminds me of yet another project where we had to create a complicated scoring matrix for a drag and drop game. Users had multiple game paths and could order 9 of 12 game icons for which they were being scored.
When I originally started working on the logic for this scoring matrix, I recall thinking, "Oh my gosh! How am I really going to create such a complicated scoring matrix in Flash?"
Yeah, this is a perfect example of us originally not thinking things all the way through and it coming back to bite us. We started off thinking this was only a couple hundred possible scoring combinations to work with in a matrix.
Then we really started looking at it and said, "Wait a minute! Oh crap! This is like over a million combinations of possible scoring scenarios! There is no possible way we are going to do this entirely in Flash!" We were forced to get innovative and creative. That's what we ended up doing.
Yeah, and we actually couldn't start production until we figured out the scoring matrix. We couldn't use backend technologies that could pick combinations out of a lotto-styled database table and send it back to Flash. We had to figure out a way to do that.
I ended up cracking open Excel and writing some VBA macros to help with the generation of the scoring matrix tables and actual ActionScript scoring table arrays.
Right, and that ended up being an enormous time saver too!
Yes. I couldn't think of any other way to do it other than hire some mathematician to come in and whiteboard out all the algorithms and matrices.
Absolutely, and if you think of that scoring matrix... it's pretty crazy. This matrix was complicated further by the fact that there were several different scenarios that changed how the game was presented, and how the 12 icons were organized. It was ridiculously complex.
We ended up coming up with the solution: a sort of zone-based cluster approach, where there was one "ultimate" icon and every icon farther away from this ultimate icon decremented the score proportionally.
It was a really clever solution that you came up with.
Right, looking back, it was more of a cluster analysis for various scoring combinations. We had these million or so combinations that the user's score could qualify for. Think of it like a huge database of every possible winning combination for a lottery... except these were possible score sets.
Instead of hard coding all the possible combinations, I came up with a way to "clusterize" them into a range of scoring blocks within the matrix. Now that I think about it, that scoring matrix issue was a huge bottleneck to production on that project.
Explain a bit more about some of the gaps and holes we had to fix within that project along with reevaluation of some of the creative and functional definitions.
Yeah, that was bound to happen because it was such an integrated process. We were on a timeline and had to factor that in there because of the complexity of the site. Stuff is going to happen sometimes!
It might be as extreme as this project, where everything came to a stop, because the entire game hinged on how it was going to be scored. If we had ignored that fact and just kept working, we would have had to change it later and potentially miss the deadline.
That's funny about things coming to a stop. I recently had that happen on a project last fall where I was building a guitar skinner application in Flash using Maya 3D rendered assets. Actually, it's the basis for my case study in this book. I had to stop and do some hard thinking about what the limitations are for Flash and the Photoshop composite. Then I had to discover what the limitations were in the Photoshop composite for the Maya 3D rendering workflows.
I also had to find the holes and gaps in between those three platforms and fill them with something meaningful and measurable that would not adversely impact the resulting Flash composite. I had to ask myself, "Can I achieve the look in Maya, via Photoshop and ultimately composited in Flash at runtime?"
I remember sitting there in my studio for a couple of days testing and retesting renders from Maya, to Photoshop, then to Flash, trying to figure out why the ending composite didn't look right and why it didn't rival the Maya composite. I kept troubleshooting what needed to be done to make it look it right and how I could make it look right reliably through repeatable testing and observation.
There was one point where I was getting worried that I might not be able to reconstruct the guitar composite to look as cool as it did in the Maya 3D renders. The problem was, since the guitar skinner application wasn't built yet, we had to show the client the Maya 3D renders and you just know they wouldn't accept anything less than that quality.
I was struggling to prove that I could recreate my Maya 3D composite in Flash by way of a massive Photoshop post-production pipeline.
I ended intentionally making the Maya 3D rendered comps look sort of tacky and mediocre. I was trying to buy some wiggle room for the potentially lowered expectations of my resulting Flash application.
Absolutely. Actually, that sort of sounds like the large telecom project we worked on. We weren't doing any of the 3D stuff and video in-house. It was a totally separate deal all together that required future integration.
In some cases, we couldn't tweak the 3D or video and we were stuck with what we had. It's done. We already had it. We couldn't change it.
That forced us to change the way the program functions, which is certainly something to avoid, but we couldn't.
Yes, I remember. That happened with some of the chroma-key video sequences where there the creatives wanted the person in the video to move here and do this or that.
The problem was we didn't actually have any video footage for that person to do what the creatives were asking. That affected a lot of what you ended up having to program and develop.
Yes, indeed. That was one of the few projects for a big agency that we actually ended up developing a prototype for. Originally it wasn't supposed to be a prototype, but that's really what it turned out to be.
That taught me a huge lesson: it's invaluable to develop a prototype.
We ended up having to rebuild the whole thing from scratch after we built the prototype, but developing that prototype was critical to avoiding future problem areas and functionality.
Yeah, I remember what set that whole thing up. I had to leave that project after the first couple of months and turned it over to you to pick up where I left off and finish.
One of the strategies I utilized on that project in the beginning was to avoid going at it from a class-based perspective.
I created a sort of a "pseudo" class-based approach using includes and segmenting out the various portions of the framework into different ActionScript files for the applicable developer that would eventually be coding it.
Yes, the way you structured it was about as close to class-based as you could have made it without actually having any real classes.
Right, and that ended being a strategic solution to the integration of the prototype and that it actually worked where we could build off it later from a minimalist approach.
Right, let's talk about that a bit further, because it ties into the strategy behind the program's architecture that you designed.
Once again, a class-based approach takes longer to prepare, develop, and ultimately complete.
For this project, there was not a lot of maintenance that was going to go on after it launched. I understand that the argument can be made that if you are doing some large RIA's and hardcore functionality that a class-based approach saves time in the long run and is more efficient within a team of collaborative developers.
Like, when you have a project that has eight phases to it, with a team of five people working on it, and your talent pool is nothing like the east or west coast.
Here in Dallas, Texas, we have a really hard time finding qualified and proficient class-based Flash developers. Forget about AS3, we are talking about AS2 here. There are so few solid class-based AS2 Flash developers in Dallas that finding an AS3 class-based Flash developer is next to impossible.
I mean there are some that do okay, but we have a much larger pool of talent by going pseudo class-based. That was a brilliant strategy on your part and it really paid off in the end.
We ended up simulating the class-based structures and patterns, but it just wasn't actually class-based. We didn't have to think or worry about scope. We didn't have to think about any of that sort of stuff.
That alone actually saved us and allowed us to acquire the right local talent to assist with the production of the project. It really ended up working great.
Yes it did. In fact, when you look back on that project now and say that we need to make this class-based, you just need to add a few things syntactically to wrap it up into a class with a few tweaks here and there and you probably could end up with a converted version that adheres strictly to the class-based structures.
Absolutely, I totally agree. In the end, it would have been just that easy to convert it all to a class-based structure.
Secrets
So we've talked about some of the strategies. Now let's talk about some of the secrets. I don't mean like "ooooo" the hidden and unknown secrets. I'm talking about the secrets to things you pick up after having done this for over 15 years.
Sure, one of the secrets, which seems to be an issue with just about every project I have ever worked on, is managing the scope of the project.
There are probably four key areas that we should talk about. One is estimating development hours. Two is scope creep. Three is the change orders. And lastly are the internal costs to the agency.
For me, it seems like the projection of the development hours is something that is just lacking. It comes across as a guessing game versus an estimation game and I have a hard time understanding why that is a nagging and persistent issue with the interactive and digital agencies. I mean, developers who have been in the trenches for years can look at something and say, "Oh my gosh, no one has thought about this or that." They can see the unforeseen issues and problems by virtue of their years of experience developing the most complicated and intricate solutions imaginable.
I feel at times that no one is willing to believe or give credit to the developer's estimation. I find it very interesting that this guessing game continues instead of rationally and logically estimating production hours.
Further, it seems the developer is less and less a part of the estimation process now. Why is that?
I think in a lot of cases that this is true for agencies. Some agencies have the right attitude about it: they track what hours were originally estimated and how many hours it actually took to develop given project.
Then they categorize the projects, so that the more they work on a given type of project the less they guess the work there is on future projects. They pad a few hours here and there for potential problems, but they're pretty much on track.
The problem is that this doesn't always happen.
Right, and the most important aspect is that they continue to bring the developers into the estimation discussions, instead of solely looking at historical charts, graphs, and figures to project future development estimates.
You're right. That's absolutely crucial.
Yeah, and another thing that usually gets missed in managing scope is QA processes. When QA gets the project, they have no idea what this is, and how it works. They generally don't have the detailed IA or process flows and don't expect something 3D to come shooting out at them when they click the submit button.
Nor should they, by the way!
[laughs] Yeah, I agree. The estimation process has forgotten about the QA process in relation to the complexity of the project and that the timeline needs to include the QA processes.
QA typically gets a bad rap. A lot of people get really upset with QA. It's important to remember that QA's job is to break it.
Exactly.
Then to break it again. And break it again. Our job is to figure out how they broke it and fix it. It's not a personal reflection on the developer or how it was developed. They're breaking it so that it can be fixed before the user ends up breaking it. That's what QA does and is supposed to do.
How true. I remember the first time I worked on a big project for a huge agency where I was added to their massive QA notification system where I received emails for various issues needing attention.
I come in one morning after a full day of QA and see over a hundred QA related emails in my inbox. I thought I was going to lose it! I remember saying to myself, "How can this be so broken and messed up?"
That's when it hit me that this is what the end user might experience and isn't it better to take care of that in QA instead of launching all those problems for the end user to experience.
I understood the fact that I had to go piece by piece and fix each issue in a methodical manner with the sole purpose of improving the end user's experience. Then QA would break it again and I'd have to find another solution. It went on and on like that for days.
When the project launched, there were no issues and the program was rock solid... all due to the QA process. I learned a valuable lesson on that one. Still, a lot of people don't get the QA process.
Sure, for a really complicated project, it could take weeks to QA. It's really important.
Right and it is part of the scope, that's the secret here. I wish more agencies would focus on QA and include those estimates with the scope and timeline. It's getting better, but as they move more towards an IT structure and perspective, they are going to have to get better or they will fall away.
Totally. If you don't have a QA person breaking it, then the end user is going to break it. The end user is not going to be as nice and friendly about it as the QA department is.
The next thing I want to talk about is scope creep.
[laughs] Geez.
You can probably explain this one better than I can. You have a lot more big agency experience than I do. Explain to people what scope creep is and what the secrets are to handling and avoiding it all together.
You have a project and it's supposed to do a certain amount of functional things. Sometimes scope creep is client driven and sometimes it's internal. Occasionally, it's both.
You have to be really careful with scope creep because the smallest, most innocuous change can snowball into this massive thing. That is not to say that we can't be flexible. But, it can be a delicate juggling act with regards to scope creep.
Let's say the client wants to change the way the buttons look. That's probably not scope creep. That's a typical tweaking of visuals or whatever.
Let's say the client wants to make that menu completely dynamic and adjust or adapt to any given user's experience within the site with 12 different layers of something instead of just one. That's scope creep.
So that's like "screeping" then? I think I just made up a new industry term!
[laughs] Exactly! You have to learn how to approach the first signs of scope creep. Sometimes you can say that it is out of scope. However, it is not impossible and of course it can be done. The fact that it is out of scope could jeopardize the project's deadline.
That's one of the most important things to keep in mind. Scope creep can not only jeopardize the profitability of a project, it can jeopardize getting the project done on time or getting it done at all.
True. One of the secrets to avoid scope creep is to bring in the developer on these types of conversations, or at the very least, consult with a developer prior to making any promises. Developers have this innate ability to offset hard tasks with easier tasks. Developers can simply give from here and take from there, minimize complexity over there, etc.
With developers helping to gauge the impact of the scope creep, we can often avoid it all together by providing an alternative while not having to worry about jeopardizing the project in any way.
I agree with that. I also think it's important to sometimes say "no" to scope creep. There are several reasons why to say "no" to scope creep. It may be completely impossible to do. It may be completely unrealistic financially to do, based upon the client's budget.
At other times though, it might be better to say that you can totally do that, despite it being scope creep. We may need to come up with a new project plan that will incorporate the scope creep and impact the timeline.
We might also have to bring in more people to work on the project to integrate the scope creep. Or, we can simply have a change order.
In all my experience, I think "yes" is being said too much. It seems like there is this mentality of having to say "yes" to everything. This is especially true with the bread and butter clients.
Often, there is no change order at all. There is no reevaluation of the project's deadline. There seems to be forgetfulness with respect to implementing a phased approach.
Why is that? Why is everyone saying "yes" while a lot of us are simultaneously saying "no" or are not prepared enough to say "yes" yet?
That has more to do with account people, sales people, or project managers. It might be different for the developer in a lot of situations. Saying "yes" to something without consulting the developer or giving a qualification can be dangerous territory.
They need to be checking with creative, development, or both before making ill-informed promises. That's the key. You have to check with the people who actually know about the project and know enough about the project to provide the right answers.
Now, we've both seen developers say "yes" and they end up being very sorry they did so. Part of it is dependent on the culture of the agency. But, it really depends on whether the agency is good at handling these sorts of problems.
Some agencies are dysfunctional and don't want to hear about it. If you are in one of the agencies where they don't want to hear "no", maybe you need to step up and be one of those black sheep.
From a developer side of things, one of the aspects I need to know is the true internal costs for me and my department. I need to know what some of the internal corporate billing standards and guidelines are for my department and team.
We need to sort of grasp those internal costs at a high level so we can estimate whether or not saying "yes" or "no" is better in any given situation.
I agree with that. I think it's important to take a look at the cost in relation to what type of client this is that we are talking about. Is this a $26 million dollar a year client? If so, then you might end up eating a couple of things on projects just to keep them happy. The agency may be more than happy to do that for such a high profile client.
You're right though. We can't operate the creative or development side of things outside of the internal cost structures in place.
Sure, we are here to do good work, but we're really here to make money for the agency and to be billable so everybody has a job and senior management is happy.
You are so right. Let's say we have a $100,000 project. We have three weeks to develop this with five developers. Then say five weeks of scope creep and change orders come in along with all the normal things that typically go wrong these days. Now we know how much that is really costing us.
What's interesting is that on the books and on paper, from an internal accounting perspective, it's clearly a different cost basis than what the actual internal costs are.
One of the typical corporate internal accounting factors is to take the salary of every employee and multiply it times 2.5 and add 12% to figure out that is how much it is costing.
Therefore, a lot of developers are operating under this huge pressure of every hour their team is working is supposedly costing the agency X amount of dollars, and in reality, it's just not true at all.
That's part of the great agency-hoax-myth perpetuated by fear and guilt along with a healthy dose of corporate manipulation from an accounting and internal cost structure perspective.
What have you seen over the years with regards to agencies and their perceived internal costs? Are they globalized?
Well, you're more savvy than I am when it comes to the accounting and financial side. However, I think it should be a key thing to any agency.
Look, no one likes tracking their hours. Everybody complains about it. Everybody has to do it.
I hate it.
Me, too.
It seems like every 15 minutes I have to figure out if what I was doing was billable or not. If I don't, I can be assured that my memory won't be accurate later on when I do get around to filling out my hours on my time tracking.
Not tracking billable hours correctly is a huge skew point for the accuracy of the books.
Right. It's an enormous pain. But it's crucial and we have to do it. Being billable is why you are there and why you have a job. If you aren't billable, you should be very concerned about your job.
I am not sure if a lot of the Flash developers are aware of the corporate side of the interactive and digital agency world... it's called the utilization rate.
If you are not in the 85%+ utilization range, you are at the top of the queue for being terminated.
You're exactly right. You could be the best Flash developer in the world and a really nice guy, but if you're not making the agency money, you're probably on your way out.
Sure, and it doesn't matter how much money you saved on that project back in 1999 either. Today is today, and that savings from 1999 has long been spent and will not justify your presence within the organization today.
There is no reason why we all cannot be 100% billable and not have to work those crazy hours you still hear about.
I agree.
And, working those crazy hours just to save on internal costs is crazy to me because it may not be accurate that the unpaid overtime is actually saving the agency on internal costs.
Working your Flash developers, or anyone for that matter, 70 hours a week decreases performance and production on a grand scale and actually costs more money in the long run.
Very true. It's interesting to look at some of the agencies that work crazy hours, even for the advertising world. You hear stories about working at one of these large agencies or agencies that have a reputation for doing that.
I have come across a couple of agencies that worked this way and I was really intrigued by it. It showed me that some of these employers don't realize that their employees have actual lives outside of work.
Now, there are a lot of agencies that don't work their employees to death. Typically, they seem to be more in the medium sized agency range. Maybe they don't have the sexiest clients, but they have solid clients, do good work, and make money. Management takes a look at the department hours.
Lets' say the baseline work week is 45 hours per person. If three months go by and there are over 50 hours or more for each of the three months, they realize they need to hire another individual. It's at that point they bring in another creative or another developer.
Right, that is done instead of overworking the top key players within the team who truly get things done and outperform their peers. This stops the cycle of working people on nights, weekends, and holidays or essentially any time
when the office is officially closed.
I don't know about you, but I personally would rather not work when my employer is officially closed.
Absolutely. And, as a manager of a department, it's important to keep that in mind and track it yourself if it's not being tracked. If you come up with documentation, a spreadsheet with a nice little graph and say, "Look, for the last 3 months, my department has been working more than 60 hours overtime over the standard. We need to hire on another person." I think that would carry a lot more weight when going to senior management with a case stated for hiring a new team member.
You bring up an interesting topic about managing the team. A lot of the team members don't feel like they have an ownership stake in this thing. People want to feel needed and want to feel utilized by their employers. They want to feel value-added. They may not always seek outward recognition, but they want to know that what they are doing and the hours they are putting in mean something somewhere, right?
Yeah. Giving people ownership is just a good management technique. People want to feel trusted and that they have ownership of something within the organization. Because of that, they are going to do a better job.
They really will appreciate the fact that they have ownership in the organizational structure. That's part of being a good manager. You have to be able to give part of your team ownership of the important things.
Totally. We've both been senior professionals now for many years. We have each had the pleasure of directing big and small teams alike. We have both made mistakes in the past, as everyone has. My mistakes are probably a bit bigger than yours, but you get what I'm saying.
[laughs] Oh, sure.
We've all had to take one for the team. We've all had to take ownership for mistakes by our team members. We've all had to drop our pride and give credit where credit was due.
I don't think that most Flash developers understand what it is really like to be part of a team, especially when mistakes are made and someone has to be held accountable for both the successes and the failures.
Explain a little bit about the interactive and digital agency today and why it is so important for the Flash developer to be part of the team.
If you are a manager, I think it's important that you stand up for your team.
If somebody does some really sloppy code and hacks something together and didn't check it before they left and it's broke, then it's your responsibility as the manager to take the hit... take one for the team.
That doesn't mean you can't go to that person and call them out and say, "I took the hit for you, but you have to fix this." That's part of being a good manager.
Conversely, part of being a good team member is stepping up when you screw something up and saying, "It was me, I made the mistake and I'm going to fix it."
Everybody is going to appreciate that, including the manager.
Also, when you are a manager you may be privy to more information than a team member. So it may be a little bit easier to make those decisions to take one for the team.
If you're a team member, I think it's a little bit harder because the farther you go up the corporate organizational structure, the more information a given individual has. As a team member, you have to realize that you are only seeing a small part of the "bigger" picture.
Right, and sometimes it's okay to expose certain team members to the bigger picture. We've both worked at agencies where they are afraid to let hints of the big picture trickle back down the corporate ladder and let people know what's really going on.
This affects performance, quality, production, and affects the morale of the entire lower part of the organization.
Yeah, and people know that.
Right. They're aware more than their management gives them credit for.
With the latest economic downturn and with the dot com crash, I've seen circumstances where the senior management tried to hide the horrible financial situations and the fact that there were going to be big layoffs.
But everybody already knew and it would have been much better if senior management would have stepped up and said that they don't want to do this, but they may have to do this to keep everyone informed.
That doesn't mean they have to tell them every little dirty secret. Just keep them informed. It's the right thing to do.
Yes, totally agreed. I want to touch on another secret, from an insider perspective, and that is part of the reason for this chapter in the book. There are ways to deliver a project within the impossible deadline. We have both worked together on several projects over the years that would qualify as impossible projects under the timelines we were given.
I would like to go through some of the projects and provide some of the secretive back information about how we actually delivered these projects under impossible deadlines and circumstances.
Let's start with the big telecom project from last year and summarize what it was that enabled us to deliver that project.
Sure. I'll give a little background first to help readers understand where we are coming from. When the project started, it was already over budget well into the six figures. This was before production was even started.
Right, we were that far under the gun before development was even consulted on the project!
It was crazy! That's how it started. Then we took a look at the project plan and clearly developers were not consulted because the deadlines were absolutely unrealistic.
The original deadlines were so far removed from reality that we could have a team of 50 people and still not get it done in that timeline.
As a consequence, that kind of set the tone for the project. There was a lot of pushback, and we were driving that. There were a lot of battles that had to be fought over stuff that was really important because it could not be done even with a revised timeline.
Yes, I remember, that project was crazy insane!
One other project, where we only had three and half weeks, there were a couple of meetings that we had where we were going to split the difference on the 3D models and retexture and model some of the open-source 3D assets.
As soon as I started building the 3D environment, they wanted to start adding this and changing that. We pushed back and won the battle rather easily.
The secret here was we had to say "no" and we meant it. We said "no" by means of a strategic discussion proving any of the well thought out alternatives would force us to miss our deadline.
As a benefit of saying "no", we were able to address some of the other concerns that wouldn't impact our deadline and everyone felt like a winner - that they were able to get something out of their requests.
Interestingly, later on in that project, when this became an ongoing theme, what we ended up doing was creating a big list. We had this enormous prioritized list of issues and things needing to get done. We identified the must haves, can't stands, and great to haves.
It was a winning prioritization scenario where we were not making all of the decisions. It was a great way to say, "It's on the list, we haven't forgotten about it, but there are 50 other things on the list in front it that must be done first."
Right, and the problems that we encountered were nothing really development related nor were they 3D related.
They problems were more related to the integration and implementation of the back end and server side of the equation.
At that point, we knew we were safe from a catastrophe.
Yeah, totally.
What about this game where we had this huge scoring matrix issue? Remember how the timeline was really tough on that project? If I am not mistaken, you interviewed several developers before me.
I remember I had the "ah ha" moment in the actual interview where I said, "Actually, that is really complicated." I remember I had to stop right there to pause and think more about it.
That's exactly what got you the gig!
[laughs] Yeah, I instantly recognized that we needed to figure out how we were going to do that.
I think that people have a tendency to underestimate the complexity of games. The users are getting really savvy in what they're expecting out of a game.
With this game in particular, it was exceptionally complex. It was one of those highly complex games that didn't seem complex to the end user. It seemed to be a simple drag and drop game. Even a lot of the other developers didn't get it.
I interviewed tons of developers, and a lot of them were pretty good developers, but there wasn't even an "ah ha" moment afterwards. A lot of them were just like, "Oh yeah, that's easy." And it wasn't.
Yeah, and those developers who thought it was easy would have ended up coding themselves into a corner once they realized the monumental nature of the possible scoring combinations they had to account for while creating robust scoring routines.
I can see them one day finally realizing that they cannot factor a solution on that many combinations without rethinking their entire programming and logic.
Yeah, I actually think it would have been a situation where it wouldn't have gotten done on time and maybe not at all. The scoring matrix was so integral to what was going on in the game. They would have had to scrap it completely and start over.
Agreed. I actually go into more detail in one of the chapters in this book about how I leveraged and utilized Excel as a companion tool in factoring a solution to the scoring matrix problem.
I created a mini macro program with VBA in Excel to help build and devise a system for building the scoring matrix and ActionScript arrays.
So as the client was reviewing the scoring and wanted to make changes, both mathematical and logical, the scoring matrix had to be tweaked and updated on the fly to facilitate new generated ActionScript output for the various relational arrays.
Even as the client was hitting the various game paths and seeing the wide variableness to the scoring results, it became evident rather quickly that had I not had devised such a smart and automated scoring matrix legend generator in Excel, I might not have been able to keep up or even make the deadline.
I remember the technical director of the agency was a little freaked out by all of the scoring matrix changes. I explained how the program I wrote in Excel could regenerate the entire scoring matrix arrays with a few clicks of the mouse and copy/paste that to Flash and republish it in less than five minutes.
I remember the team's "ah ha" moment when they saw me execute such a workflow with ease and reliability, not to mention the mathematical accuracy I was able to achieve with Excel. The technical director commented, "Wow, that is really handy, we can use that in the future."
The secret to the success of that project was I leveraged other technologies, software, and skills to create a streamlined, standardized, reliable, and accurate workflow for my Flash development with regards to the scoring matrix integration.
I recall our conversations after the project went live that we literally could not see how any other developers could have achieved what we achieved in such a ridiculously short timeline.
Precisely. The overall code was not particularly complex, but the way that it was structured and the way that it had to be architected was extremely complex.
What we were doing with dragging, dropping, and calculating a score was not all that hard. Putting together the backbone of the scoring matrix and the algorithms to use and leverage that matrix to generate scores across all the various game paths and possible combinations was the complex part.
That's why it was so hard for me to find a developer who understood that.
Yeah, I know. To this day, I sort of hope I never get another scoring matrix as complicated as that again because I certainly will have to go back and learn what I did and leverage that historical knowledge and wisdom again today, but likely at a higher and even more complex level.
Yeah, I think that we learn a little bit of everything from the different projects we work on. I would nip that in the bud rather quickly the next time around.
Right. I remember one of the interview examples you mentioned was to equate the complexity of this to creating an ActionScript Sudoku puzzle solver application.
At first glance, most developers think no problem at all. But in actuality, it is very problematic and intense once you start thinking about the logic behind solving such a Sudoku puzzle with recursion and previously solved benchmarks.
Absolutely. I'd come up with these technical problems for shuffling cards or solving a Sudoku puzzle just to see how people's thoughts are arranged and how they would factor a solution. It wasn't that the solutions were so completely abstract. A lot of them related to exactly what we were doing. But if they didn't understand these, then they're probably not going to be able to handle the project.
Yeah, if they can't even hypothesize about a factored solution at the discussion level, go to the whiteboard and at least mark up some humanly readable logic, then it's generally not a good sign.
[laughs] Exactly. The thing we were looking for in the Sudoku puzzle was pretty basic. What we were looking for was someone to get that the key to solving it was that it would have to be recursive. And, we even told a couple of them and they still didn't get it.
Yeah, setting benchmarks for what portions of the puzzle have already been solved so that on future recursive solving passes we are not wasting effort on previously solved puzzle portions.
[laughs] Yeah, few people even got that far!
That brings us back to the big telecom project. You were not involved until about three months after I started on it.
Originally, I remember the team talking about making this project an AS3 project and leveraging a third party 3D engine (Papervision) as the main component for exploring the 3D world mixed with videos. I was the black sheep and the senior lead on the project and had to put a stop that nonsense.
The only way I convinced them was to go ahead and build a mini prototype of parallaxing a 3D layered scene, incorporating the Papervision engine, and streaming videos and other interactive elements. The frames per second never rose above 11 frames per second. Then, factor in the class-based approach in AS3, and I quickly realized we were heading in the wrong direction entirely.
I suggested and made the decision to go back to AS2, dump the third party 3D engine, and rethink the entire project's framework. I ended up leaving that project and brought you in to take over and lead it.
I believe we spent upwards of six weeks working out all the 10,000 foot view process flows and developing the pseudo class-based approach for the AS2 development framework.
I want you to talk about when I brought you in on this project and how after the first 6 weeks you were up to speed and ready to run with it.
Explain how you took the project from there and pursued the unrealistic deadline that was right around the corner 4 weeks later.
Well, part of it was that we ended up doing a prototype first, which was totally invaluable. There were some miscommunications between the client, project management, and the account people.
I am still not sure who ultimately was responsible for that, but I am sure that the client was completely out of line.
There was some stuff in the contract and the statement of work that client didn't either want to read, didn't want to understand or whatever, and they threw a complete fit about it.
We ended up having to do an all hands on deck, pulling in every freelancer we could find, and over a 3 day weekend, work 24 hour days to knock the prototype out for the following Monday's client review.
What we really ended up doing was one of those situations where we got good people. We knew who they were and that they were really good developers.
I knew most of them personally because I had worked with them before, and we just said, "Look, here's what it has to do, here's your five or ten pages of the IA and process flows, just make it do this, and I really don't care how you end up making it do it - except that the only rule is, the way it has to be structured is that is sort of self contained and does not reference anything else but itself."
That's how we ended up getting the prototype done.
After that, the client looked at it and said, "That's not what we had in mind at all." So we ended up working for the next 6 months to get it the way the client wanted it. Keep in mind that it was 6 or 7 total months of production and it was all over budget.
I remember you talking about that crazy three-day weekend. You mentioned how that weekend seemed to change the tone of the entire project going forward.
Absolutely, it did.
So explain how it actually did end up taking over 6 months, like I originally projected it would 8 months earlier, when originally they expected only one month for completion of the project.
It wasn't just insane, it simply wasn't possible, literally.
[laughs] Yeah, I didn't think that the outsourced 3D and video work could be done inside of one month to begin with, and that was so close to the deadline.
So are you saying that at the time, I said it was impossible, yet we built a prototype in those three days? Is that what you are asking?
[laughs] Yes, it is. That is the secret looking back that you got it done somehow.
Well, when the client threw a fit, a client who was worth millions and millions of dollars to the agency, they came to me and said we have to get this done somehow and it has to be done by Monday and that was like on a Thursday.
First, I was of the attitude that is just can't be done. Then I realized, that is not exactly true... we can do something here. The only way to get this done was to make it production and development driven, which means we make the calls, we say what gets done, and if we don't, we are in big trouble.
That's not to say that we didn't work with creatives, account people, or the project manager. We had to be in charge of making production and
development decisions that rested solely on the ability to get something done by the following Monday, 72 hours later. We ended up having tons of people work over the weekend, all weekend long, staying in hotels and sleeping in conference rooms, etc.
True, and you ended up having to make some sacrifices along the way that weekend.
The developers had to realize that they were not messing with anyone else's code, but that it would eventually be all integrated together somehow and that the system as a whole needed to just work.
Yes, and I told the developers that if they could do something on the timeline and avoid making anything programmatic or dynamic, then do it. I didn't really care as long as it looked okay. We were on too much of deadline and I could care less so long as it got done and it looked good and worked okay.
Right, it's all about keeping the smooth movement of integration flowing, right?
Right. We also pulled out a ton of the proposed functionality. This project was originally completely driven by web services stuff, based on user specific preferences, and other configurables. That was completely removed from the prototype. It wasn't in there at all.
Yeah, I remember, it was nothing but static and hard coded content, right?
Yes, there was no login either. I didn't want to see XML files or anything dynamic. Just stick it in the file and get it done without overcomplicating it.
Wow, and you actually ended up getting it delivered and presentable to the client!
Yes, like I said, the client was pretty mad about the whole situation. I looked at the situation and realized after that weekend happened, the client was impressed with what we were able to get done.
Granted, it wasn't what they wanted. It looked good and it worked fundamentally and functioned pretty well.
The key was that I stopped and took a look at things and pulled the team together and talked about what we had just learned. I talked about what we needed to do then and how we needed to approach it. I literally said we are going to start over anew and not even touch the prototype file. I explained we would be starting over and here is what we are going to do.
Some of the prototype stuff worked and we could pull it in and tweak some stuff, but everything else was started from scratch. That was a changing point for me on that project.
On projects like this, that are extremely complicated, I cannot recommend strongly enough how valuable it is to build a prototype. I'm not saying you need to find a ton of developers to work 72 hours straight, but you should
leave enough time to do some prototyping in an isolated environment.
Try just getting an extra week to arrange some prototyping production. You don't have to ultimately use it, but you're going to learn a lot about what you are trying to do and how to efficiently do it.
I couldn't agree more. One of the other secrets a lot of Flash developers are not aware of is that they can actually start some of the preliminary and preemptive prototype development much earlier than they think they can. I'm talking about a non-skinned, ugly, yet functional level.
Well, talk about your guitar skinner application that you did last fall. You did exactly that!
Oh yeah! [laughs] I know, it was a risky venture, but it paid off with huge dividends. That was one of the projects last falls for a huge game launch where I created a custom guitar skinner application, which incorporated the Maya 3D rendered guitar pieces and parts that I also was in charge of creating and rendering.
I remember thinking that I only have five weeks to do this entire project. I knew the Maya 3D alone could take that long, not to mention the same for the Flash development.
I somehow managed to talk the team and creatives into allowing me to head up the entire pipeline for the guitar skinner application portion of the promotion. This was done in a modular fashion while the rest of the site ran its normal course.
That risk of building the guitar skinner application independently from the rest of the site actually ended up giving me vast amounts of additional time to complete the project.
All through the creative process I was cranking out the Maya 3D stuff and working on the logistical problems from Maya to Photoshop to Flash for my eventual workflow.
All the while I was performing simultaneous R&D on how to apply decals to the guitar, modify various guitar geometry and write a UI that allowed extensive customization for various pieces and parts.
I quickly learned about the various dependencies related to the guitar's geometry and 3D rendered assets. Not having the time to do that would have ensure that I wouldn't have been able to complete the guitar skinner application in conjunction with the 6 other modules of the site, which in themselves were extremely complicated and involved.
I recall once the creative process was finished, I literally hit render in Maya and sent the images over to the graphics team and they integrated into the main comps and the client signed off. Right then and there I had all my preliminary Maya and Photoshop workflow refined and ready to go to development and integration with Flash. I could not have done it any other way.
Yes, that guitar skinner application was so customizable and intricate that it had to be integrated into the entire process.
Absolutely. I learned so much on that project. I really took things to the next level and dived deep into the MEL scripting language for Maya. I figured out a way to distribute the rendering load and write batch scripts in MEL to render out all the various guitar pieces and elements.
I would literally set up my batch render at the end of the day, which is 4:30pm by the way, and when I was walking out, hit the enter key and knew that by morning I'd have a freshly rendered batch of new guitar assets to integrate into Photoshop and then into Flash.
I could then perform some quick tests composites and customizations to find out what needed to be tweaked throughout the workflow and pipeline and then repeated that process for a few days until I got it just right.
I really took scripting, batching, and automation to the next level in my workflow to streamline the process to arrive a fully integrated solution much faster than normal. A lot of people don't feel that was beneficial, but it was.
I let the automated processes do the hard work while I was home sleeping, and during my normal work day, I concentrated on development.
It was a seamless blend of innovation, technology, and imaginative thinking with regards to increasing my productivity and workflows.
What you are talking about here is sort of this sexy game launch promotion with this cool guitar skinner application module. What about the same principals and techniques for something more form based or a typical sweepstakes microsite?
Absolutely. A lot of times, if you have access to good IA and process flows, and you can get your hands on an early copy that is signed off on by the client, yeah, then we can build that entire form, and make it fully functional without ever having to see the creative or get assets imported. There is plenty of time to skin it later and integrate the design comps.
Often, for me, this is the preferred approach. What developer wouldn't want to have stuff functional and operating and then take a few relaxed days of integrating design comps and assets? All this stuff can be done early. The back end stuff can be done early. Just having stuff trace out is sufficient enough to know that in the future, when it really counts, I can integrate quickly because I already know the hierarchical structure of the data coming back from the back end.
A lot of this stuff can absolutely be completed before you do anything with the design comps. I can comment my code or add a note here about upcoming integration and keep the smooth movement of my current integration flowing freely.
That really is a secret now that I think about it. There is no excuse for having to wait to start production if five weeks earlier you have completed IA and process flows detailing all of the granular structural framework you have to build. When those comps are handed off, I'm mostly done with the base API and framework for the system already. That's the way to do it, in the real world.
A lot of agencies are afraid to have their developers try this. I don't get it at all. It's like we are doing mini prototypes four weeks early before the designs are done. Who cannot see the value of that? I used to think this was not a worthy and rewarding developmental technique.
Now I'm convinced that doing otherwise is mere foolishness. Sure, no one wants to build this huge guitar skinner application incorporating 3D and then have to abandon it and start over.
With proper preparation and planning, that won't ever happen, and when it does, there is a change order attached to it and everyone wins because you just became that much more billable and utilized.
Right. And that's where we get back to what we were talking about previously regarding planning and architecture. It is not a matter of chance. It's all part of the grand plan.
Exactly!
Okay, so you talked about the form based stuff, but what about actual application development in AIR or a Flash projector, something that is stand-alone and application based?
Yeah, the same principles apply, with a few variations. I have actually been developing a stand-alone Flash application for a touch screen PC for an upcoming event for a major computer manufacturer.
I am actually creating a Windows installer application that deploys the Flash application and all applicable source files to these touch screen PCs. So it's sort of a quiz application where users answer multiple choice questions and ultimately have to print an event badge from the Flash application to a wireless printer connected to the touch screen PC, in which the printed badge gives them access to the various parts of the event.
The great thing about this application that I'm writing is that I'm doing everything from start to finish. I'm writing the database and server sided scripting to talk to these 20 or so touch screen PC's at this event. I'm collecting the form data and various metrics regarding the event, including tracking each machine by its own id number.
I incorporated a lot of programming and visual extras that leverage and utilize the power of the touch screen PC's. I can do some things that normally would bring a browser based Flash site to a screeching halt.
It's very cool and I'm super thrilled to be able to build the Windows installer package that can be deployed online and the IT guys at the event can literally install with a couple of clicks and fire up the application and everything from there is on auto-pilot.
Not only was it challenging to build this Flash application and deliver it with a Windows installer deployment, it was also challenging to promote and highlight the capabilities of this touch screen PC and its wireless printing capabilities.
So I'm running real-time reflections on various media like videos and images in addition to bitmap caching previously loaded images and videos and playing them back from memory to optimize and free up resources.
This is one of the first projects where I was completely in charge of everything and I could finally integrate a project without worry of doing things wrong. I knew exactly what I needed to get done, and the final product that I showed the client last week had minimal changes, mostly copy edits, and I again exceeded the client's expectations of what was possible for their new touch screen PC.
It is really nice when things finally come together and a project works as intended and ends up being cooler than originally planned.
Remember, I only had three weeks to pull this project off from start to finish. I actually completed it a couple of days early due to my innovative workflow.
So why didn't you use AIR for that originally?
I originally started the project as an AIR project. However, I ran into issues publishing AIR 1.0 files on the touch screen PC which has the AIR 1.5 runtime. Also, some of the operating system quirks and features of the touch screen PC did not play well with the published AIR file at runtime.
So I ended up having to make a Flash projector and then write a Windows installer program in Visual Basic .NET that would install all the files and packages along with assigning proper permissions and so on.
It really was an interesting and new approach to mixing different technologies and software to deliver a robust stand-alone application to run on these touch screen PC's.
I should note that this application didn't require a mouse and keyboard either. That was another of the many challenges in writing a touch screen application. Right off the mark, you can eliminate all hover and rollover events. That alone made me rethink how I approached the design and coding of the user interface.
That's really cool.
Thanks. I really was able to draw upon all the mistakes over the years and not make them here on this one. There was no room for any errors on this one.
One of the benefits of being in charge and able to make choices, is making the right choices and seeing them through to the end where successes are achieved.
I realize this is a rare situation for a Flash developer, but I'm not just a Flash developer. I do so much more than Flash and the secret is carving out my niche that uses varying levels of my expertise, some as solitary and some as combined technical feats.
Yes. And because you planned it so carefully and were able to architect it correctly, the payoff in the end was huge for you and the client.
Yeah, for that I'm very thankful. It's probably while I'm still employed!
[laughs]
Insights
Okay, so we've talked about the strategies and secrets.
The last thing I want to talk about, which is probably the most important, are the insights that you and I have discovered from our careers, not only in the interactive and digital space, but in the agency world of marketing, advertising, promotions, and online in general.
What are some of the insights that you feel like sharing with the reader?
As you know, my skill set is a little bit unique. I am a designer and art director who also does development. Because of that, it gives me a slightly different perspective on how things should work together.
For me, that's a big deal, because I constantly see creatives getting really frustrated with developers and developers getting frustrated with the creatives. A lot of times it is really just miscommunication.
At other times, I also think that people lose track of the fact that being a creative attracts a certain type of personality type. Being a developer attracts a different type of personality than with the creative type. Sometimes those two personality types can clash.
You're exactly right. Like with us, we share some of the same expertise, but we also have our separate areas of focus.
My area tends to incorporate more design and creative with motion graphics, 3D, audio/visual production along with the hardcore programming and development.
Your area tends to be more with the conceptual, strategy, creative, traditional and interactive design, and art direction along with the similar portions of intense programming and development.
We are able to get together and talk over coffee because we are not just a creative or just a developer.
We are actually both part of each other's worlds of expertise, but with varying levels and we can understand and talk the common ground and simply work collaboratively to get things done and done right.
You're absolutely correct.
We are both left and right brain individuals who are able to get together and talk about things and work things out... even over coffee or lunch.
If you go back a little bit further than that, one of the problems, in general, is that a lot of technical people really have no design experience at all.
They may be aware of what the creative process is, but they're really not completely aware of the daily problems and solutions that the creative people have to come up with and what they actually do.
It's the same with creatives. They typically don't understand what the developer has to go through and the solutions they come up with on a daily basis. When the creatives hear a developer say that something isn't possible, they don't know what the developers really mean by that.
Take for example the Barbarian group, where a lot of the designers and art directors learn HTML, CSS, AJAX, and JavaScript. That is great, because none of that is very hard to learn at a fundamental level. Anyone who understands 6th grade math can do it.
I'm not saying that will make you the best and most brilliant front-end developer in the world, but it will make you a much better designer or art director. You are going to be able to leverage the technology instead of trying to work around it.
Conversely, as a developer, the Barbarian group has a lot of their developers develop in Processing (http://www.processing.org), which is a visual, motion graphic based development environment. The visual development makes the developers think in a different way. They learn to recognize what the creatives are talking about and where they're coming from.
So true, and for people like us, who have lived and worked in the trenches on both sides of the equation dating back to the mid 90's, we sort of forget to switch modes sometimes to effectively talk to the other side.
Often, we have to leave the develop side of us at the door in a strictly creative meeting and vice versa. Now that is not to say that the developer side doesn't flare up when appropriate regarding developmental issues, but for the most part, we turn on the other side of the brain for a while so we can work in their world and think like they do. It's difficult for the developer, who does not know all things creative, to be effective in a creative discussion.
It works the same way for the creative who is in the middle of a developmental discussion and they have no idea what is being discussed. That is the perfect example of how "yes" and "no" are spoken and completely out of line and incorrect.
So talk more about how development and creative is paralleled yet segmented in the agency world.
The thing about lot of interactive and digital media is that creative and development are very tightly integrated. I think the absolute best work is when it is all woven together in a seamless blend of design, technology and functionality... where it's really hard to separate design and development.
The creatives and developers work seamlessly together. It is becoming a bit more common, but it's still really hard to find. I think that you can only get that from creatives who understand the various limitations for the development side of the equation and with developers who understand the creative side.
It may seem that the creative changes are a stupid little technical detail, but that's the type of detail that's important to design. It works the same way for the developer. So it's very important that the creatives and developers understand both of those concepts and work together.
When the project is finished and the developer looks at it and says that it is fantastic, rock solid, and functions exactly as it was intended, and then creative looks at it and says that it is exactly the concept and visual they wanted, and then IA looks at it and says that it is architected properly and easy to use, then that ultimately is the perfect integration for a project.
Yes. Let's take it one step farther and say that something like that is possible when everyone involved basically got along and worked out all of the issues, whether technical, creative, logistical, client facing, etc.
They learned to work in the system as a whole, not for personal gain or recognition, but for supporting the system as a whole. They dropped their pride and emotional outbursts for sacrificed project elements. Each side knew their contribution level and the boundaries to operate within. That really is a rare combination these days.
You can't help but ask yourself and wonder if this sort of perfect integration process happened on all of those awesome projects than with site of the year award, right?
Right, I know. Way back in the day the agencies used to have something called a design technologist.
Yes, and I recall a term "DTC", or design and technical coordinator as well.
Yeah, totally. All those types of people were just integrators. They are sort of people like us, but maybe they don't actually do everything we do, but they know about what we do, on both sides.
These people were able to go to creative brainstorming meetings and meaningfully contribute with regards to the technical limitations or other developmental issues.
Then in the development meetings, these people would know how to present the development issues and limitations back to the creatives and provide the necessary and possible strategic alternatives. They were great at interacting with the two sides and to help facilitate the integration between them.
Yes, I remember that back in the late 90's. The design and technical coordinator pretty much held all the power, but held it in a way that was fluent and flexible for both sides. It was an "improve" rather than "approve" type of approach to the integration movements.
A lot of teams have been plagued by the "just approve" mentality over the years. They just integrate to get it out the door, get approval, and forget to improve along the way. That mentality of just getting it off your plate and out the door hurt a lot of integration movements over the years. What almost always happened was that the animation concepts were just "approved" instead of "improved".
When was the last time you heard the creatives going nuts over the killer animation or visuals after the development team improved them along the way instead of just approving the original lame concept and getting it out the door as fast as possible?
Absolutely. And take a look at something that has heavy duty motion graphics in it. To get that to work the process has to be seamless between the creative and technical. You can't do it any other way. With seamless integration there are many chances to "improve" instead of "approve".
Yes, and a lot of Flash projects try to simulate motion graphics because it was not part of the budget or workflow and developers just run in to all sorts of problems and limitations trying to replicate full blown motion graphics workflows and results from within Flash.
A lot of creatives and art directors are not aware that what they see online is not Flash, it is full blown motion graphics and 3D production that ends up being a video that plays in Flash. They get confused just because it is delivered in Flash, they think that the Flash developer has the power to recreate that.
What ultimately is insightful about all of this is that if the creatives and developers can just get along and trust each other to work things out on a collaborative and collective level, all the while "improving" instead of "approving" along the way, more and more top notch work would be produced and delivered through the seamless integration of smooth physical movements.
One of the other insights we have discovered is what third party tools and open-source frameworks we should or should not leverage and utilize on any given project.
What are some of the third party classes and open-source frameworks that we should or should not be using and why?
I think a lot of it comes down to strictly how you use the third party tool or framework. It reminds me of what a friend of mine once said to me when I was lamenting about something I had done and people were misusing it.
He said it's like you go down to your basement because a water pipe is leaking. You call the plumber, he comes out and start hitting your pipes with a rock. You tell him no, that's not the right way to do it and you show them the pipe wrench, how to use it to open a pipe fitting, remove the clog, turn the bolt on the pipe and tighten it up. They say, oh yeah, and fix it and move on their way.
Then the leak in the pipe returns a week later. You call the plumber back out and he goes right back to beating on the pipe, but this time with the pipe wrench. The pipe wrench is just a tool. It's how you use it that largely determines what you can do with it. How you use third party classes and frameworks are really crucial to how effective they are.
Right, we're not saying that third party classes and open-source frameworks are a bad thing here, right?
No, not at all. They are great and they can save you an enormous amount of time and effort. Think of something like Papervision. It is misused by a lot of agencies and developers. They end up using them for things that really don't even require what it was originally intended for.
It's often used as a crutch to do easy things that could otherwise be done without all the overhead and performance hits associated with it. That's just a lazy way to develop and it's ugly and sloppy.
Nine times out of ten you end up with a ton of overhead. You could have done it yourself: the results would have been better and more optimized.
I hear what you are saying, and I agree. I think overall, Papervision is fantastic, if used correctly. The problem, like you stated, is that it's being misused much more often.
Right, but not all of the time. We've seen some recent implementations of Papervision where they used it in a remarkably clever way. It was extremely effective and the performance of the site was outstanding.
But we're not just praising and picking on Papervision here. There are a ton of third party classes and open-source frameworks that get properly used and misused by developers all around the country.
Right. And I highlight one of the best third party tweening engines in Chapter 13, the GreenSock Tweening Engine (TweenLite/Max) authored by Jack Doyle.
Recently, Jack moved his entire platform over to a plugin-based type of architecture. It was a brilliant and timely move that has made his tweening engine the premier tweening engine in the country, if not the entire world.
While Jack's tweening is very powerful and effective, it is sometimes misused, and used for the wrong reasons and purposes. That's what we are talking about here, right?
Absolutely. The TweenLite/Max classes are awesome. They are amazing and work fantastic for most anything. But, if you misuse them, it can screw up your project's performance, overhead, functionality, and overall integration.
The problem is, people misuse it and then blame Jack for it. That's completely wrong and out of line. They're the ones misusing it. It's their fault, not Jack's.
Exactly. A lot of times, Flash developers hang on to these bits and pieces of idolized developer code instead of learning how to do it right, and stop relying on them as a crutch to get them through their integration processes.
Look, I'm not saying these idolized developers are not great or smart. I'm saying that too many Flash developers hang on their every keystroke because of their professional status within the industry and they are getting left behind because they don't know how to factor and write their own solutions, which often is easier and less time consuming in the end.
Too much of this stuff gets cranked out the door without proper testing, debugging, and for identifying possible adverse implications to the project.
I think for the most part... well, a lot of it, is just laziness on the part of the developers. Actually, it might be laziness or it might be ignorance.
We've both seen developers who probably couldn't architect something all by themselves without using other peoples work. So they have their top 5 frameworks and third party classes they work with, and they are stuck and completely dependent upon them. If they can't get it done with them, then they simply can't do it. That's all they do.
They never, ever do a project outside of those frameworks and third party classes. I guess that's fair enough, but I don't want someone like that working on my team or project.
They never, ever do a project outside of those frameworks and third party classes and that's all they are really good for and are able to do due to their extreme limitation.
I guess that's fair enough, but I don't want someone like that working on my team or project.
Me either. No way. Never!
Look, both of us have huge clients and have worked on massive projects over the past 15 years, and I might add, we are extremely thankful for that, but they didn't hire us and pay us good money to go off and download third party classes and open-source frameworks and schlock the stuff together for their projects that are full of hacks, bugs, and untested code.
It's nothing against these idolized developers that create this stuff... those guys are incredible and smart. It's just that our clients, and most clients for that matter, don't want their stuff hacked together with third party classes and open-source frameworks as being the sole foundation for their project's structure.
That's completely idiotic to think that it is okay to do that, right?
Right, totally. Sometimes it's completely overkill to do something like that. You may be able to bring in some open-source framework, but it may be way too robust and complicated for what you need to really do. I see this all of the time.
You only need to do this one tiny, little, cool thing, and they end up bringing in this massive framework of classes. That is completely overkill. Really, just sit down, do it yourself, and spend a couple of hours working it out.
Right, but we may be sounding hypocritical here, right? We're talking about third party classes and open-source frameworks and yet my whole book is based around the AS3_CORE Flash Template.
How are we not completely pointing the finger right now back at ourselves here?
Because, the AS3_CORE Flash Template is nothing more than a very robust and thoroughly configurable tool. Just like with TweenLite/Max. The tool is only as good as the person who is using it. Use it wrong, it won't work. Use it right, and it's fantastic and you save time and money. It's that simple.
Well, you bring up an interesting point. The AS3_CORE Flash Template actually leverages TweenLite/Max as its sole tweening engine because of the power and flexibility that Jack Doyle implemented in his plugin architecture.
They work together seamlessly, but were written by several different key open-source developers within our community. It really is an amazing accomplishment if you think about it.
The best thing is, you do not have to use it! You can turn it off and use any other of the tweening engines out there, including the built in Adobe tween engine.
Yeah, I think the Adobe tween classes and some of the other tweening engines get a bad rap. A lot of the time, they are just used incorrectly.
Granted, for more complicated and heavily integrated programmatic tweening, it makes sense to leverage something that will do what you need it to do.
Right, I agree. I personally don't use the Adobe tween classes anymore now that TweenLite/Max are so much more robust and optimized.
The thing to remember is we are generally talking about Flash applications and sites, not banners and restrictive rich media units. Programmatic tweening is part of every project we work on and has been for some time now.
Oh sure, there are definitely some times when we still need to do some timeline animation, especially when it's so crazy and complex that taking the time to do it programmatically is really just unnecessary.
But, you're right. I cannot remember the last project I developed that didn't use some sort of a tweening engine.
Right and the AS3_CORE Flash Template is made up of several frameworks and third party classes from the open-source community all around the world. We've plucked the best of the best and assembled a rock solid core and partner API to the AS3_CORE's framework. It's tested, sound, and highly configurable for any number of project types. It's integrated in a way where you are not forced to use most of it. That's the beauty of such a framework.
Look, over 17 projects to date, for huge clients and brands, have been built around the AS3_CORE Flash Template. It has endured a full production environment over the past 3 years and proved to be invaluable in increasing productivity, quality, performance, and providing a base framework for which just about any interactive Flash project can utilize at some level.
Part of my concern over the past three years has been whether or not the AS3_CORE Flash Template would hold up to the demands and pressures the developers were placing on it. It has held up rather well and in fact, has been the key to delivering several major projects for major clients under extremely tight deadlines.
Clearly, the AS3_CORE Flash Template does what it needs to because of the way it is being used and leveraged or integrated. It is incredibly robust yet at the same time you can do the really simple stuff and it's pretty easy to use.
Yeah, and the base minimum template SWF size is under 50Kb. That's nothing for the typical online Flash site today. Now of course, that's banners excluded here. The AS3_CORE Flash Template is not for banners or rich media units. It never has nor will it be geared toward banners or rich media units.
The great thing about the AS3_CORE Flash Template is that the developer has a rich set of tools to literally handle just about anything fundamental to any interactive project.
I have found that weeks or more can be reduced off of my development schedule by properly leveraging the AS3_CORE Flash Template. With each new project, it seems I gain even more time savings.
In my book we create a guitar customizer from scratch using the AS3_CORE Flash Template. It also leverages TweenLite.
I want to shift gears now and talk about the career of the interactive Flash developer. What is this career really all about?
I think there are a couple of things that any interactive professional should do. One: keep your skills up to date. Two: stay up to date on what the technology and industry trends are. That includes going to the latest cool websites and reading up on what's new in technology and for the industry.
Find out what the big promotional sites are doing at this time, what the big brands are doing in the industry, what and who is winning all of the awards and so on.
The other side is that you have to stay up to date with what industry folks are up to in general. You just have to stay abreast of what's really going on all over the world. I also think you need to be up to date on what's going on with the technology for your particular area of expertise.
You don't want to end up being a dinosaur programmer who is using coding techniques from Flash 5 or Flash 6 in the year 2009 and beyond.
But do we really know how to implement the proper coding techniques and design patterns today? Are Flash developers doing things the right way? Do we even know what we are integrating and what pattern it subscribes too?
Well, it's interesting. I picked up a new computer recently. The initial registration for the PC's manufacturer was incredibly impressive. It was really well thought out. It was super intuitive and it looked very slick. It was really easy to use. I just said, "Wow, I'm going to make a mental note of that and use some of those techniques".
Clearly, it was incredibly well thought out. I have never seen a series of forms so easy to fill out and so user friendly. It actually made it sort of fun to fill out all of this stupid information just so I could register my computer and actually get it running.
So you don't necessarily have to stick with Flash to do something like this. They didn't use Flash in this case. You can do this kind of stuff literally anywhere the technology allows it.
So you're saying the key here is to find out what is the best implementation, experience it and make notes about what was so cool about it. Maybe research more about it, download a sample?
Yes, absolutely.
So how important are new skills and techniques to the interactive and digital career?
Again, this is sort of a double-sided coin. Interactive and digital moves so fast these days that you have to stay up to date. It's imperative to see where things are going, where the problems are, and what people are doing. You also need to see where people are pushing it and who is doing the pushing.
The other side is, there are still some agencies developing in AS2, which could be a legitimate and strategic business decision. Sometimes it's a matter of not finding the right talent to move forward with the industry. Other times, they just don't see it as necessary to make the switch.
In most cases, that might be okay. But don't be an ostrich and bury your head in the sand and hope change goes away. It doesn't work like that.
Right, I totally agree. We need to be open to new ideas. I mean, like every 18 months something big and huge is coming out. It's very difficult to keep up with all of this exponentially forward progression and movement.
An example would be full Flash support for mobile devices that is probably coming out by mid 2009. That is simply huge.
Right, and don't forget about Silverlight.
Indeed, and that might be a redefining moment as well. We're talking about a whole new era where what we currently do online will have the ability to be structured for mobile devices using the same technological platform of Flash or Silverlight, just on a smaller performance and scale.
Right. As far as Flash goes, you will have to be even more careful of how you architect it and structure it for mobile devices. It takes us back to the integration of creative and technology. That's super important because on mobile devices we are not dealing with a lot of processing power and available memory.
Right, we can't have a 7Mb home page load on people's mobile devices.
Exactly. And how much of that is loaded on-demand, how much is vector vs. bitmap. We're going to have to rethink things to try not to slow things down and bog down the bandwidth channels for delivering interactive content to mobile devices. It will be extremely challenging but at the same time remarkably exciting.
In my opinion, mobile is exciting because it is so challenging.
Totally. Challenging on many fronts, like optimization, leveraging the various platforms and devices... the list goes on and on. In the next five years we will be seeing an entirely new mobile landscape. There will be a lot of Flash developers who won't be able to switch to mobile. They are going to try, but most will fail miserably because they won't be able to adapt and learn, and frankly, change their wicked ways and bad habits.
Their resistance to learning new skills and technology will be their ultimate stumbling block when they attempt to gear up on mobile development.
I highly doubt the mobile to market development will be successful for most Flash developers who attempt to ride the trend and mobile wave. There are going to be a lot of lifeguards out there rescuing sinking Flash developers who thought they were ready for the mobile pipeline.
Still, to know that full support for Flash on mobile devices is coming around the corner is one of the most exciting and challenging times yet in our long careers.
It's not just mobile you know. You have to really keep up or get left behind.
What is then, your biggest insight from all of your years in the industry?
I think that you really have to know what you're doing. You have to be confident in your skills. Actually, it might be more important to know what you don't know.
You have to be able to say that you don't know something and be willing to bring somebody in who does. Or learn more about it, so you can make an informed decision.
So your greatest insight is in knowing what your weaknesses are, and therein lies your greatest strength?
Absolutely.
How often do you actually think that creatives and developers know their weaknesses?
And can admit it?
Yes. It's rare, right?
Somewhat. It's interesting. It's probably most rare in the agency world than in the IT world. I'm not saying that it doesn't exist in the IT world, but I think that the IT area just has a different vibe about it.
Whereas in the agency world, some people just don't want to admit it sometimes because they think it's a form of weakness or that it would demean their professional status.
The fact is that nobody can be everything. You have to realize where your strengths start and stop and ultimately know your weaknesses in order to gain the most strength.
I totally agree. Knowing what you can't do keeps you from being set up for a big failure in your career. You don't want to be known as someone who said they could deliver and then didn't. Companies generally do not buy into not delivering on their promises.
What about you, what's your greatest insight from the past 15 plus years?
Well, from all of my years of doing so many different things, and maybe not doing things the best, but getting things done and never missing a deadline in almost 16 years, I would have to say that increasing my knowledge and wisdom has been the key to my success.
I have refused to reach a level of stagnation where forward momentum and integration movement ceases. You'll hear me talk about my smooth movement of integration all the time. When something jeopardizes my smooth movement of integration, there is going to be trouble.
I have asked myself daily for countless years now, does it impact my income? I call it the "DIMI" affect. If it impacts my income, it's worth dealing with, and dealing with immediately. Sometimes that means increasing my knowledge and wisdom in order to deal with it so the impact to my income is positive and not negative.
Increased knowledge and wisdom is highly integral to keeping the smooth movement of integration on track and positively impacting your income. Not only that, but expanding your skill set.
Learn new things. Could learning something new, regardless if you like it or not, directly impact your income? Will it increase your knowledge? Will you become wise by learning something new?
For me, if it directly impacts my income and I can gain increased knowledge and wisdom by learning something new, there is no need to ask me any more questions.
That's the reason why I have enjoyed so many years of success. I caught a few lucky breaks, and I was helped along the way, but in the end, I chose to willfully evolve my mind and increase my knowledge and wisdom to a point where learning directly impacted my income as well as the income for those I have worked for.
That is what is most insightful from all my years in the industry.
|
I am a 
