Blog

I’m still in the midst of wrapping up a 6 month Flex 1.5 project. It had about 3 phases, and currently am doing bug fixes and enhancements. It’s hard to balance because I’m now doing a full-time Flash gig up in Detroit and there is a lot going on. Most of my roles in the past, salaried or contract, have been coding muscle. A lot were more specialist; server-side developers & designers abound, but a Flash coder? Dude, you’re hired.

This role in particular is quite challenging. First off, it’s Flash 7, not Flex 1.5. Second, it’s deadline driven first, design driven after that. Anyone who’s been in this industry awhile knows software is never released on time. Programming is an art, not a science, and thus placing deadlines to it is more for team morale & focus, not actual delivery dates.

So, right off the bat, I’ve got a problem. Suddenly, there is an extreme emphasis on feature destruction and time identification. Assuming all time estimations on a specific feature are correct, you then identify what feature can be waxed, to what level, and how much time & resources that removed feature gives you. You then extrapolate on if you sacrifice 2 smaller features, how does that affect the main big one you still really need?

Furthermore, these features are design driven, not Database or business driven. If it enhances the Ford brand, it’s a good thing. My job is merely to identify time, cost, and effort levels. In my eyes, I’ll relay those datapoints to project managers to make those decisions with the IA & Designers. There is a positive in everything, and in this case, there is no “negotiating” scope in a feature. It is done in a certain time frame, and has a resource cost. One might say risk as well as level at which it could be implemented. In this case, no, they would be wrong.

First, know the premise of super-accurate time estimations for programming are flawed to begin with and never accurate. Second, risk IS time. With a deadline driven project, anything you do detracts from the most important resources; time. You don’t have “time” to experiement and make prototypes / tracer bullets like you do in larger projects. Things you would take for granted are no longer even available in this type of project.

The design & wireframes aren’t presentable yet, but I’ve got a pretty good idea of what’s in store. Furthermore, with the mantra of “Abandon all OOP ye who enter here”, it makes all the shortcuts, hacks, and smoke & mirror techniques I’ve learned over the years that much more valuable. A lot unfortunately started to go the way of the Do-Do bird. My last manager on my Flex project is a purist, and Architect with a lot of experience, and a damn good reason for every rule he asks us to code by. He’s still open minded, but this type of development is a huge abrupt 180 degrees from the Flex 1.5 work. When you work with a company that never misses a deadline, and the project is driven by design, maintainability is the last thing you think about. Encapsulation is still good, but re-usability is not. If you are coding something to be re-usable, you’re probably taking too much time.

If you made it through that last paragraph, you can see how hard of a perspective change it is. Going from a programming environemnt to a design one. Going from a business driven development to a deadline one. Going from programming for encapsulation & re-usability to coding as fast as possible, as much as possible that uses as little bandwidth as possible.

That last part is the worst. Having to deal with the fact of SWF size is a requirement I’ve never had to deal with in the past. The majority of my work has been multimedia, CD-ROM, kiosk, or intranet based. I know all about asset optimization, but with code, there is only 3 things you can do. Remote SharedLibraries are too much of a management nightmare; while they work great, they don’t work with deadline driven development. LZW compression on your bytecode is kind of fixed; all you can really do is pray. I’ve heard of obfustactors that shrink size, but I think #3 is the only avenue of approach here. The final thing you can do is use loadMovie. The former framework actually loads a 40k SWF so a multitude of sections throughout the website can utilize this main code base. I haven’t figured out how much code is duplicated through each section since I see no specific use of intrinsic for some of the classes, but my gues is very little. It’s the first framework I’ve seen that was specifically developed to utilize loaded SWF’s. When perceived download speed counts, this is a 100% viable use case, ease of coding be damned. Anyone know of any others?

On another note, in preparing for all my talks, I’ve noticed quite an interesting parallel between Flex & Flash. As I start to transition to this new fulltime Flash job, I’m reminded of one of the reasons I left Flash for application development in the first place. There is, however, one undeniable truth. Flash does design well. And you can code it.

Flex on the other hand does coding well. And you can design it. See the priorities? I’ve spent what little free time I’ve had in the past 4 months throwing every kind of weird design challenge at Flex 2. I’ve gotten some real challenges in my Flash days, so I figured the quickest way to learn Flex’ strengths & limitations was to attempt implementations of some of the more common Flash design needs. The tests are really hard to do. First off, by their very nature, Flex 2 & Flash are used in different markets. My last project was larger in scope, and long in deadline, with copious amounts of framework, OOP, refactoring, and other programming specific challenges.

In this case, the deadline is extremely shorter, the project is for marketing purposes, and the challenges will be getting a brand new team up to speed, and quickly. Quick enough to work in parallel on a technology that doesn’t really foster parallel development under an already extreme time crunch.

So, those typical types of work frame your point of reference, and influence what you deem “acceptable”. For example, when I implement a design in Flash, I do my best to implement it in such a way that if it doesn’t need to be programmed, it isn’t. I make full use of the timeline, library, etc. Most of the the time the designers on my team still can’t really work on the file alone, but they CAN make changes quickly if we work together. Because the progaramming is what in the end makes the project work, you have to basically give responsibility to the developer to make it happen. They are responsible for making the file work. A working file, however, is not success. A good looking file that sells whatever your Flash work is selling is a success, and that is mostly accomplished by the design you are coding. Thus, it’s still in your best interest to make the design you’ve coded it as to be easily modified. Flex, different story. You have the developer’s best interests at heart.

Are those accurate assumptions? Probably. Being pragmatic, the products were made for different markets, so forcing Flash to do enterprise application developement is not the best thing, nor is making Flex work in a marketing firm.

That said, even with those perceptions, you still hit the wall pretty hard on the fuzzy side. The only thing that really defines a “point of no return on time investment” is project type, and thus, the market that you’d use Flex & Flash in.

For example, application development can be done in Flash. I’ve done it and was successful with using it as a technology. However, if I had the chance to do it again, I would have used Flex instead. The projects didn’t have a strong need for design, animation, sound, and video. So, it’s pretty easy for me to identify when Flash isn’t the best tool for the job, even if I know it’s talents could give it an edge. You just ask the client questions, and you can pretty easily figure it out.

Flex? Same story. If the whole point of your app is to have marketing impact, (selling a brand, product, service,etc.) and you make no use of any of the programming features of Flex 2 (not Flash Player 9 – 2 different things), then Flash is clearly a better choice. That question is never asked, though. Designers & marketing studios already know this, and thus they use Flash, and have done so for a long time. On the flip-side, a lot of other software shops and companies are looking into Flex recently, and adopting it for a lot of their web application work. There is no software shop that does strictly marketing work; they build software, not Flash websites. The design shops that ask abouut Flex are only doing so because of the past marketing confusion Macromedia & Adobe spawned. Aral went into this awhile ago.

There ARE some people doing a lot of amazing things with Flash applications, but I’d argue they are not Enterprise size, and if they were, it’s because they employ some supreme bad asses. Those people are in a unique position, and from a business case, do not factor in. They are unique in a good way, but can answer their own questions.

So, in the end, I’ve always found it hard to do good coding practices in Flash. You have to make a lot of allowances to have the overall app work. Since the designs tend to be non-conversative, you can make some allowances in code. Sometimes, like in my case, bandwidth is a consideration, and you suddenly have multiple SWF’s. Yes, you can still write classes, but your logic isn’t centralized, and the project can be in flux because of stakeholder decisions, thus ruining any well thought out programming plan.

The opposite for Flex 1.5. There really is no good layout or design tool for Flex 1.5. FlexBuilder 1.5 was really slow and not always pixel accurate. Layout was more orienated at getting things semi-accurately laid out, with the assumption the built-in layout engine would take care of the rest of the details. Flex 2 changes that with a really good preview of what your app will really look like when compiled, pixel perfect layout and snapping of objects, as well as built-in understanding of most styles. Combined with states & transitions, and you have a LOT more design control than you had in the past. What point does that take you to? Even with states being built on the DisplayList, allowing things to be moved and removed while still retinaing all code listeners, it doesn’t offer the level of design integration that Flash does. Granted, if you’ve ever tried to animate a button, and when it’s done add an event listener, you’ll love states & transitions in Flex 2. All the timing based coding you wrote, customized each time for a new design element that was a pain in the neck to maintain is now gone and replaced with a wonderul, declarative based state. The transitions still give you animation & layout control, while not being meshed with your state more than necessary.

Still, I’m “in a mold”. When things start to take too long, you end up doing what you do when trying to code something; you just use the timeline. The same holds true for Flex. If there is some specific design element that feels forced in code, or you spend too much time coding in Flex 2, you’re probably better off using Flash for that particular part, in this case loading the SWF.

I’m in Detroit for another 7 weeks or so. My flight was cancelled so I’m in the hotel attempting to get ColdFusion setup on this laptop so I can work remotely on other stuff. After giving my presentation to the Adobe User Group of Atlanta, I found some holes in my presentation I’ll need to fix this week for New York next Monday. A lof the designers want to see proof in the pudding; they want to see a complex Flash design implemented in Flex. The developers want to see how much coding is involved to make those Flash elements work. I have very little time to attack those weakneses in my already overwhelmed schedule, but I’ll do what I can as I recognize them as important. You can talk about the methods of HOW to implement Flash designs into Flex to allow it to have a design driven aspect to a project, but without a real, working design, it’s all busllshit. The latter, however, is easy. The amount of coding to get Flash elements into Flex is elementary AS3 that I’d argue a lot of hybrid Flash designers could actually do themselves.

Either way a lot of unchartered teritory here, and being back in a Flash project really helps me see both markets as well as both technologies intimately in a short timeframe. I had a few more things I wanted to blog about but I’m exhausted; all this travelling back and forth between Atlanta, Detroit, home, hotel is really draining. Add that I’m no longer just a coder, but someone who needs to identify resources, and lead my team to ultimate victory is rough. I’m really good at pointing out things that don’t work, like the feel good speeches, and the working weekends to make up for lack of forethought about research, and all the other project from hell experiences. Apparently this is where those lessons learned pay off. They don’t necessarely point out the RIGHT way of doing things, but I’m going with my gut; it’s always worked in the past.

It’s 7:50 pm on Sunday, and I’m still working. I figured I’d share why I’m debugging like crazy instead of relaxing.

Bindings.

For those of who know of Flex 2, Adobe’s tool for programmers to create Rich Internet Applications, it has this one feature that sets it apart from Flash, and incidentally, it’s brother Spry shares. It allows you to put a variable surrounded by curly brackets, and at runtime, anytime that variable changes, it’ll update whatever variable is being set to it. So, for a TextField, you can bind a global text property to the TextField’s text property, like so:

<mx:Label text="{message}" />

And when you update the message variable, the Label’s text property will automatically be updated. Utilizing Cairngorm, a lightweight MVC application architecture for Flex, you can take this concept a step further using ModelLocator. This is basically a global (static) class that holds global data. You can have your Views’ (your visible forms) bind to these variables. Anyone who updates the ModelLocator (in this case the Model) has suddenly updated the entire app. Nice!

…that is, until something goes wrong. These bitches are hard as nuts to debug. It’s even worse when you are binding to a nested property, or a set of forms and their children all bind to the same thing. Through copious refactoring, the parent view is the only one who actually binds to the ModelLocactor. The rest using public getter / setters, and use their internal private variable (Flex 1.5 only has public / private, not protected like Flex 2) for the binding. This makes it easier to debug, but not awesome. You know you’re in deep shit when you’re forms start getting updates, 1 frame later mind you, and have a COPY, not a reference of a ValueObject. Yes, that’s right, I said a COPY, not a reference. Array’s and Objects in general are always passed around in Flash by ref, so naturally I’m freaking out.

Anyway, what I have learned from this? Two things. Common literary rule is to ensure all lists have at least 3 entries, but I’m using 2 I feel they are important.

1. Make the top level View use ModelLocator for binding; all children can propagate internal copies. If you have a View that uses ModelLocator, and his parent uses ModelLocator also, your code sucks, fix it. Refactor it into a binding tag, binding to a getter / setter, or a public property. You’ll thank me when you go to debug and you KNOW who’s setting who, and when.
2. Handle null. If you’re View can’t handle null, it sucks. The old saying is a good acid test for your View; Garbage In, Garbage Out. If you throw a ValueObject at a form for example to edit it, and bind to the changes, fine. If it takes a null, and disables itself, fantastic. If you’re View can’t take a null, you know what you have to refactor.

On a lighter note, in the free milliseconds I’ve had in the past month to play with states & transitions in Flex has taught me another 2 things:

• States and Transitions are the bomb. It makes your View’s much more flexible, allows you better control over user eye tracking (look here sucka), and good integration with event handling.
• Flex without Flash blows – Flash & Flex together can make some phat interfaces. AS3 & Component powah, Flash funk; good stuff.

I’ll be showing some of the cool stuff you can do with the above August 3rd here in the ATL, August 14th in New York City, and October 23rd (ish) at MAX in Vegas. Hope to see you at one of ’em and make you go, “Awww… hell yeah!”.

…and back to the mutha-fD)($Ring grind.