The Joy of Flex

Chuck Toporek, Senior Acquisitions Editor at Addison-Wesley Publishing, is working with Juan Sanchez and Andy McIntosh on a book to be titled Creating a Visual Experience in Flex. Chuck asked me to review the book proposal, and I thought it would be good to post my thoughts publicly. Chuck thought this was a fine idea, and he also encourages you to email him with your thoughts.

The proposal is for a book that will help a developer who does not have access to a designer to build an application that is still as well designed as possible under the circumstances. Developers desperately need this kind of help, but many are not aware of it. The awareness of the importance of design is growing among developers, but I see a couple of big challenges with selling this book. One challenge is to convince the potential buyer of something he doesn’t want to admit: that he is a lousy designer. The other is to overcome the reality that software design is harder than development, requires more experience, and tends to require different skills and talents than those of writing code. I.e., there’s a reason that a good software designer is in greater demand, is harder to find, and is paid more than a developer with the same number of years of experience.

The book has two main thrusts: one is to help the reader to start thinking like a designer, and the other is to help him/her use the Flex APIs to build the visual aspects of the application. For a developer who is expected to do their own designs, this could make the difference between an ugly, unusable application and one that is at least adequately attractive and usable.

At a high level, it seems like the emphasis is on building (264 pages) over designing (76 pages). There is a paradox here that is hard to overcome. On the one hand, designing is harder to learn from a book than building, so it’s really good to focus on what a book can most effectively provide, and therefore preferable to favor building over designing. On the other hand, design skills are more highly leveraged during the software development process — a day of design can take a week to build, and taking extra time to get the design right is a net savings – so more emphasis on good design in this book should make readers more effective. Overall, I think it would be better to make the balance between designing and building more equal, though probably still tilted toward building over designing.

There are a couple of points I would want to see very strongly emphasized, and it’s hard to tell from the table of contents how much weight they will get:

• If you have one developer who’s wearing both a designer hat and a coder hat, it’s important for him/her to do as much as possible to separate the roles. It’s worth it to write design documents even if the audience for them is just yourself (wearing the developer hat). Think of yourself as a team that has only one person right now but might have more in the future. On the coding side, do as much as possible to separate design and code. In particular, be sure to put all possible style information into CSS, even if you are the only person who is working on the design. (That might change in the future!)
• When it comes to all the neat visual aspects of the Flex APIs (states/transitions, skins, choreography, transparency, gradients, etc.) it’s really easy to go overboard. Less is more. It’s good to iterate between the designer and the developer in this area, so for example, once you put in a transition, go back and try it as a user and see how it works. Be ruthless about cutting stuff that looks neat but won’t work in practice. Try to parameterize the use of choreography so you can change it without a lot of rewriting code.

Given the two main thrusts — 1. think like a designer, 2. use the Flex APIs — it’s possible that the book might have three audiences: people who are interested in 1), people who are interested in 2), and people who are interested in both 1) and 2). This book should appeal to developers who already have a background in building user interfaces on other platforms (Java, C#, AJAX) and want to learn the Flex APIs for doing the same thing. It should also appeal to developers who have little experience in building user interfaces, and want to make a change in direction, because it gives them both some UI design perspective and some help in actually building the designs. However, it probably will not appeal to Flex developers who already understand the APIs but want to learn more about design, because from the outline it seems to me that the emphasis is on the Flex APIs, with a relatively shallow coverage of how to think like a designer. (I have my doubts about whether that can be adequately covered in a book that has more than one focus anyway.)

Technorati Tags: Flex, Book proposal