Blog

  • Can Flex be Design Driven?

    I met up with Kenny Bunch, his wife, his brother Phillip, and Dave Buhler yesterday after work. Our goal was to hang out, and talk tech. Kenny’s pretty well known down here in Atlanta, mainly because of his Turner & CNN contacts. His programmer background also adds a unique perspective on things since he’s worked in a few different types of environments. He now does his own thing.

    One interesting point he brought up was in explaining how parts of Turner (Cartoon Network) work in regards to Flash Development. He was describing how projects are design driven, stemming from the fact they are in the entertainment industry. As such, designers typically have the final say on how things are made, and the design drives the project. I understood what he was saying, as my first job in the industry was with one such type of firm.

    What I didn’t think about was how he described it. Design Driven projects don’t really mean much to designers; they are designing things, duh. To programmers, however, it means a lot. I’ve gone the opposite direction. As my projects grew in scope, so to did the driving forces behind them. More and more became business driven, and finally database driven. Where I am at today is a total 180 degrees from where I was 6 years ago.

    Before it was, “PSD ownz ju!”; the design comp is the end all be all. You build what’s in the design. Now, most of my projects “work” based on how the database is designed, directly correlated to whatever business we’re building things for. The design is from signed off mockups. These mockups, however, don’t drive the project per say. You can sign off on mockups, and say that the “application needs to work like what’s designed in the mockups”, but you don’t CODE to the mockups; you code to the whatever the server-side developers and you the client developer work out. This, of course, all stems from how the database is designed. Granted, there is tons of leeway, and things you can do on the middle tier, and client to help simplify things, but bottom line, the db is the driver.

    Client’s, however, don’t see db, middle tier, or even some client level programming changes. They either see a new bug, working functionality, or a design change. Thus, it’s easier for them to equate progress with visual changes which unfortunately is in direct contention with how db driven projects are made. It’s easier in Rich Internet Applications because we have more of a design presence than Visual Basic or .NET applications for example. Visual changes are more apparent, contribute to good experiences, and have immediate, and a visually, recognizable presence.

    It made me wonder if Flex could ever be used in a design driven environment. For example, I’ve seen some mention of Flash Developers who have entertained the idea of utilizing Flex Builder 2 as their primary coding tool for ActionScript, but will use Flash primarily for the actual building of the application. It makes sense once Flash 9 is released since Flash 8 only supports ActionScript 3 and Flex Builder 2 only supports ActionScript 3 (unless you go download Blaze, the Flash 8 update that has AS3 support in an alpha format).

    Back in the day, we’d all use Flash MX 2004 to compile a SWF with our components in it. We’d then spend the rest of our development in Eclipse using a FAME setup. This was really desirable, mainly because of the speeds which incremental compiling gave us (1 second vs. 1 minute and a half for 1 line of code being changed) and better code debugging tools. Flex Builder 2 has the same thing, so it’s only natural to want those things. You can use Flash Development Tool now, no doubt.

    At the time, we did have a pretty much design driven project. It was still equally driven by DB, backend, and other functional needs to, so in retrospect, I’d say we were all on equal footing pretty much stemming from the fact that all matter, and have equal relevance in product development.

    Anyway, I just thought it curious. I know Flex 2’s main goal is adoption; getting traditional developers involved via the low barrier of entry. The flipside is seeing if traditional Flash Developers coming from design driven environments can somehow adopt Flex into their workflow.

    In building a prototype game, it’s really not too bad. You still have to use 2 tools, using Flash for the actual design & animation, but since assets can now be mapped to classes, it’s cake to get ’em into ActionScript only projects (no Flex components or MXML). Furthermore, you can use an ANT script to ensure the latest compiled SWF assets are copied to your various directories for embedding into other SWF’s, or for use at runtime.

    This comes back to the fact that the perceptions of the Flex developer community will take awhile. When they look at it, they see a lot less things to worry about: no memory pointer crap, no browser or OS related issues, and the ability to talk to ANY backend all simultaneously.

    When a designer looks at it, they see the ability for their designs to look as intended. Their fonts, transparency, and layout all exact on any browser and any platform. They don’t have to design for the lowest common denominator like they do with web design, and this prevents compromising their vision.

    The latter is one of the great facets of the Rich in Rich Internet Application that I fear will be a long while before traditional development shops recognize what they are ALSO getting in addition to a ubiquitous, predictable, and lightweight runtime engine.

    I think Flex developer shops (aka former Java dev shops, w00t!) will perceive this as not a problem. Most designs in my experience are conservative, and done with minimalist implementation in supporting to not even acknowledging the customer’s brand.

    This is total opposite from how traditional design work is done. A disturbing parallel is how a lot of people interpret Interaction Design, Information Architecture, and Designers as the same role. If you are a smaller company, that makes total sense, but that doesn’t make it ok.

    Maybe the aforementioned benefits, ubiquity, predictability, and lightweight are in fact “good enough” in a pragmatic sense for traditional developers coming to Flex. While I feel I can clearly convey the benefits of good design to those I work with and the clients I have, to them, they are more interested in functionality vs. presentation. Again, this stems from the fact that they are NOT in the entertainment industry. I still think there is room for serious growth, and designer integration. Gamers’ would get it…

    Obviously, I don’t think X-Men: The Last Stand design style should be implemented into Enterprise applications. Maybe 2Advanced, though, their new design is off the hook! The point here is that you DO have those kind of design capabilities, in addition to all the other developer benefits of the Flash Player. I say you should take advantage of them. Use them to beat your competition. If you don’t have qualified designers on staff, contract them out and/or hire them and involve them in your development process (in the initial spec stages, not the implementation ones).

    Microsoft’s Expression is going to have the same problem, only worse so. At least Adobe‘s products work in both markets. Your designer can use Photoshop and Flash whilst your developer can use Flash and Flex. Some of these apps have serious seniority, placement, and strong designer / developer followings. Expression (Sparkle and Acrylic), have neither, although, again they both stem from (now) the same company.

    The only catalyst I can see for change is Breeze, the ultimate Rich Internet Application. Good design, good functionality, and extremely useful to boot. Frankly, I think the bar can, and should, be set higher on the design front. We have capabilities others don’t; let’s all use them to a competitive advantage.

  • Flex Chronicles #20: DataTips & CellRenderers

    A data tip is a tooltip that shows for text in a datagrid column that does not fit. So, if you have a “Name” column in your datagrid, and the person’s name is “Pimp Double-G Booty-licious Birdman”, but the column is only 20 pixels wide, the text will clip. If showDataTips is true on the datagrid’s column, it’ll show a tooltip when you hover over that row. It only shows for cells where the text is too big.

    Windows XP does this for example when the folder name is too small to fit into Explorer. You can hover your cursor over the folder, and it’ll show the full folder name.

    The problem is, the DataGridRow class specifically does NOT implement dataTips if the DataGridColumn has a cellRenderer. The fix is to set the cellRenderer’s toolTip value in it’s setValue function.

    I’m not sure how this is handled for itemRenderer’s in Flex 2, but I’m sure it’s similiar as is the fix if needed.

  • Flex 2 Released – Flex 4 Teh W1n!!!

    To skip the nostalgia:

    I’ve been thinking for the past week how I’d announce Flex 2 on my blog. As someone who is aggregated in a variety of high traffic aggregators, it is my responsibility as a blogger to not post a “me too” post. If I am to post anything, it must be something of value to the reader.

    In one sentence, I’m writing what I think should be said, not what needs to be said.

    What needs to said is warm, technically accurate, and concise descriptions on what Flex 2 is from the author’s perspective to give context and corroboration. This allows people both in the know, and those reading for the first time a fair chance at understanding and having a valuable take away.

    Good, honest marketing, written with passion behind it.

    What I think should be said is entirely different. As a member of the Flash & Flex community, it is my duty to write SOMETHING, so here goes.

    The difference now, however, is the sheer mass of appeal that Flex 2 has spawned without even existing. In all fairness, I’ve seen Vista do the same thing. Some people who think XAML is dumb can easily be countered by the enthusiastic and elated posts I’ve found discussing it on the net. Flex 2 is released, though, hehe. I felt I had to post about the release about Flex 1.5, with proper time taken post release, to ensure the audience clearly understood from the first reading of my entry why they should care, why it is cool, and where they can easily find more relevant information. Flash 8 was easier because I had no agenda. I just love the prog, so it was easy to just go, “Yah, this is cool… they’ve already showed this at various conferences, but now you can play with it yourself!”.

    Flex 2 is different. The word “different” needs to be judiciously defended and backed up with quantitative reasons vs. qualitative passions that a lot of developers apply to the word. “This framework is different.” I’ve seen that written for CakePHP, Ruby on Rails, and various other software products, services, and web applications.

    With that said, something needed to give. Walls had to come down. Things needed to change.

    One thing the Flash community has had is a strong community. While there are many facets that don’t always communicate as frequently, I think the people in it are a special demographic. That special trait is also what set us apart in a bad way. While bringing a unique talent to the table is great, from an application development perspective, it’s not so hot. You need available resources, and good technology. Flash application development has had a serious problem with qualified, available resources for the past 4 years. The dot bomb crash healed for me in 6 months. When I say healed, I mean the following Spring, available work exploded. I advised my friends & colleagues in any facet of Flash, especially development, to take risks. Now is the time to venture out, this is confirmation that the technology path you have chose is the right one, one that you can and will be successful with.

    Things didn’t slow down. Things didn’t improve, either, to keep pace. The scope of the projects got bigger. While improving my skills helped, it wasn’t enough. The IDE, the platform, and the community could not respond positively to the demand.

    Enter Flex 2004. After “getting it” my 2nd attempt, I recognized, at least for the IDE part, this was my future, and hopefully for others in a similar boat. As time went on, things continued to get worse from a project scope, system resource shrinking envelope, and developer demand.

    The problems were clear. The current IDE does not support large to mid-size scoped application development projects. The current IDE has too high of a barrier of entry for existing developers. Rich Internet Applications created via Flash are great! Hell, we invented the term, why can’t we share this with the rest of the world, and get them involved?

    Because it’s hard. It’s weird. It takes a unique person, and unfortunately, while that uniqueness is great, it doesn’t translate to wide adoption and spreading of the love. Giving JavaScript programmers a reminder that they’ve had an unused function for 7 years suddenly sparked a reminder that people DO want to create. People DO want to make things better. You just need to empower them. How do you do that?

    FlexBuilder 2 & ActionScript 3. Eclipse, a command line compiler, and a strongly-typed language.

    The masses are now empowered. The existing community can add the above tools to their existing toolset.

    Solving the IDE, Adobe fixed the next problem. Performance and resource usage. The influx of the hundreds of AJAX development frameworks has been somewhat of a boom for public perception. For example, I’ve seen homepages of some of these new web applications that take 7 seconds to load. I’ve got an almost year-old code base with at least over a quarter-of-a-million lines of code loading in 4.

    Still, that’s not enough. You need to drastically increase performance, reduce memory consumption, and expose lower level display capabilities for the developer.

    Flash Player 9 which has AVM+ and the DisplayList.

    We have a brand new ActionScript Virtual Machine+ scripting engine over 2 years in the making, optimized for speed via the Just In Time compiler (JIT) which uses machine code targeted at the specific processor for serious speed punch. The DisplayList removes the restrictions of having your GUI being tied to it’s initialization; you’re no longer punished in system resources for “creating” visual elements.

    They solved the IDE by making FlexBuilder familiar. They solved the performance by making the Flash Player 10 times faster. All that’s left is getting adoption.

    Adoption doesn’t refer to the Flash Player 9 installation. History has proven that we WILL get adopted, and quickly. Quick enough.

    Adoption refers to getting those who are capable to use our tools. I say, our, because I feel like I’m finally getting a better opportunity to share the RIA love with the greater development community. It’s hard when you have a seasoned back-end Java developer and you attempt to explain how code & graphics mesh on a timeline. Now, however, they’re answering MY architecture questions. THEY are the ones who will start pushing the limits, not the designers, not the alpha-hybrids, but the developers who have just been crippled by past dogma, walls to entry, and a forest for the tree’s mentality towards the web browser.

    We’ll always have the designers and alpha-hybrids continuing to lay the funk, no doubt. But over the course of the next year, I see a more realistic influx of a wide array of talent from a diverse developer camp.

    The free framework and compiler will hopefully attract the open source crowd. I think MTASC and hAxe proved there was something special there.

    The IDE & ActionScript 3 will attract not just the existing developers but those who understand what the Flash Platform handles for them. They’ll never want to go back.

    The large Enterprises who are already bought in will continue to get the new innovations to in turn help them innovate. New ones can clearly see the opportunities to join in. A flexible, rich client with a configurable back-end I KNOW is something most Java devs I’ve worked with will absolutely love.

    I think the existing Flash community will be halved. Based on their work and those who have a clear picture of what Flex 2 offers will adopt it. Some won’t.

    All of this influx of people from a wide-array of backgrounds will really give us an edge against what traditional web development and AJAX has: available resources.

    People CAN do this. Adobe has given you the tools to do so. To do things a better way than they have been done in the past. This isn’t like it was for Flash Developers 3 years ago. This is an opportunity for EVERYONE.

    That’s just off the hook.

    On the flipside, I’ve been in contact with, and personally met more than a few members of the Flex development team. While I think a few (*cough* Matt Chotin) are a little to humble of what they have done for the Eclipse community, one thing is abundantly clear: they care and have passion. I’ve seen their incestuous questioning of the community from a variety of angles over the past 2 years on mailing lists, public forums, and blogs. I met and discussed the business ramifications with those who could explain them. I’ve debated the public relation & marketing strategies both good and bad with them & colleagues.

    Bottom line, they are a talented team, have a pragmatic mindset towards the product, and I think that’ll show when you use the products. Great job Adobe Flex team, I know you all worked extremely hard, and I know it’ll pay off.

    In the end, I’m a little sad. I think it’ll take a year for things to really take off. While I’m sure the momentum the next few months will be huge, I think we’ll start seeing ROI which will become cyclical as well as broader adoption by then via stakeholders that have good capability.

    That’s great!

    What I’m sad about is something I wanted so bad to happen finally has. That is that the greater Flash Development community has embraced Flex. I was a judge for the Flex Derby, and it blew me away the amount of entries, and the quality of the ones I saw. Even more unexpected was the amount of server-side developers that got involved. You’d get a plethora of ColdFusion, Java, and C++ developers. Some of my favorite comments were, “This is my first Flex application.” Hell yeah! They are so impressed with what they build, they put it into a contest! I LOVE IT!!!

    Still… it’s the end of an era. It’s definitely not as black and white as my Director to Flash transference. To me, you only survived there because you were stubborn, or found one of those impenetrable, niche market that Director owns. I pretty much gave up full-time Director development to go into Flash development.

    With Flex, it’s a little different. Granted, I do Flex 8 hours a day, 40 hours a week now like I always wanted to, but I don’t see myself doing as much Flash anymore. The difference here is that Flash cannot fall by the wayside. There are too many things I can do with it that I can’t do well, or at all, with Flex. Flash Lite, highly branded applications, and basically anything artistic that combines animation, audio, and video. I think I’ll be forever using Flex & Flash in tandem.

    I don’t mean to get nostalgic, but in writing the history of how we got here, it’s almost like, while this new journey will be extremely awesome, I wish the first would never end.

    Regardless, today is a day for celebrating. A new era for web applications will be borne because the developers are now empowered in greater numbers. There is strength in numbers. There is power in the collective conscience. I so can’t wait.

    I invite you to take a look at the various features and facets that make up Flex 2. I know you’ll love what you see, and you’re fingers will twitch when you think of the possibilities of what you can create!

    http://www.adobe.com/devnet/flex/

    For resources to learn and connect with the Flex community, go to Flex.org.

    http://www.flex.org

    If you have anything you wish to have added or bugs to report, go the wish form.

    http://www.adobe.com/go/wish

    Welcome to Flex.

    ———————————

    Mark “Zorn” Anders goes over pricing and bare minimum details.

    Ted Patrick discusses why Flash Player 9 will change everything, and what the purpose behind Flex.org is.

  • Customer Expectations

    This is more applicable to service work than product work I think. I had a discussion last week that greatly changed the way I work. I learned the customer’s expectations.

    One of the reasons’ people have problems in personal relationships is that they do not communication expectations to the other party. This builds up frustration with the other party when he/she/they fail to meet the unsaid expectations. This is unfair to the other party who is unknowingly making the person angry without knowing it.

    On the flip-side, I’ve found I usually am better off asking what are the other person’s expectations up front to ensure we’re all the same page. In understanding how to best work with others, this is probably the single most important question to ask at any level.

    The reason I bring it up here in this context of relating to work is that my style of work is adopted based on the client’s expectations. They want to see something to develop trust? I build something simple out quickly that works with no intention of updating the code base. They want to see continual progress and constantly change things? I build based on iterations. They want it perfect? I hunker down and test the heck out of it.

    Those may seem obvious or relatively non-important, but I think they deserve to be re-iterated. In smaller teams there is more transparency, so even designers & developers on a team shielded by management are still privy to what the customer expects. On larger teams, or in ones where client communication is small to nil, without a clear communication of expectations, false impressions can not only sprout, but get entrenched into an attitude of development.

    I’m not sure of the signs, but I know if you do recognize them, it is paramount to quickly clearly communicate, again if need be, the expectations. Why?

    If you are a contractor and someone hires you for a small project to “see what you can do”, while the temptation may be to blow them away, I suggest you meet the expectations first, and if you have time, do the additions ONLY when you’ve met the original expectations. If you’re on time but didn’t get to add the extra things, feel free to share “what you wanted to add”. Better to build trust than to over promise and never deliver. I recognize that it may take less time to build the extra’s in initially, but I have failed time and time again when taking risks here, and I refuse to do so again… unless the risk is reasonably calculated, hehe!

    If you are a developer under the impression you can “shoot the client an early build” when they signed off on mockups they expect to be perfect and working 100% as designed, you will fail, give the client a negative impression, and feel frustrated with your efforts being discounted since you aren’t getting the type of feedback you wanted.

    If you are under the impression it needs to be 100% perfect and tested, and the client hasn’t seen anything for weeks or even months, you’ll be extremely frustrated and defensive when they return lackluster feedback and want changes. If the client is open to a more iterative style of development, or you get the impression they are untrusting or shifty in “what they really want”, it’s best to adjust your development style towards that type of development.

    A former executive of General Electric encouraged companies to have a set of company rules, edicts, or ethics that the entire company, every employee, could use in their decision making process. Their wording, order, and amount all had significant impacts on the company. What the company stood for and how they go about accomplishing what they do is held in this list. The point, though, is that they are the “expectations” of how you do business in the company as an employee. This ethical guide leaves no room for questioning on how to approach problems from an ethical point of view, leaves little to no room for doubt on what is most important if written well, and serves as an overall guide for your company.

    This empowering of clear focus is exactly what clearly articulated expectations do. They allow you to be successful, and remove all obstacles, leaving most of it up to your team’s collective skill set leaving your problem solving ability to be focused on algorithms and software bugs instead of customer bad feelings.

    The reason for this post is I was recently in a situation where I assumed the client knew about the benefits to iterative development and agile development and was clearly mistaken. This lead me to develop in a fashion that focused on getting initial functionality down with bugs or not-so-finished functionality into a working build that I assumed I could get user feedback on early. This was a polar opposite of what the client was expecting, made my team, and me in particular, look bad, and was setting me up to fail. After a discussion of the client’s expectations and some context as to why they were like that, I realized my attitude was wrong, my style of development had to change, and I could now be successful my decision making process vs. always defaulting to wrong. The downside was this wasn’t early in the development cycle, so the damage in time spent had already been done. I also learned that you can’t always change these expectations either and just have to deal with it.

    Bottom line:

    • Don’t assume people recognize that even though you didn’t deliver on time, you were going to add all this cool extra stuff.
    • Don’t assume every client knows what Agile or Iterative development is, nor cares.

    Ask the other party what their expectations are, and confirm you can meet those expectations with the understanding you’ll do your best to exceed those expectations time allowing.