Nov 4, 2009
Roughly one year ago, I decided to sit down and write up some notes, and draft some wires, of where I thought the Flash IDE GUI could be improved to support improved workflow. As I'm sure any power-user of any tool feels, I have my own special beefs with the Flash IDE — some of which I know are silly, and some of which I assume would actually be valuable to a broader audience. But, as CTO/COO of a Flash Platform development shop, where my guys excel in the use of basically every SWF-generating tool there is, I have several opinions based on how I feel, from an operations perspective, the cross-tool Flash workflow should be supported by Adobe's own software.
After thinking over these ideas for a year, one of the suggestions in particular keeps coming back to me. The Library. I know that the Library panel itself in the Flash IDE has long been an issue that power-users cite — forcing Macromedia, and now Adobe, to rebuild that panel from scratch more than once. And yet, even today, how many users know that there are several columns in the Library (which you will see if you widen the panel sufficiently)?
While the Library has long been clunky, in recent versions (and especially CS4) it's been souped up and works a lot better than it used to. But it is still not well-suited for developers. Which is a problem on its own terms, but is even more of an issue, because Flash is the only IDE through which developers can interact with libraries and symbols — there is no way to open an FLA symbol library in any tool other than Flash.
So, one of the core suggestions I submitted represented a rebuild of the library, with two goals:
What I came up with was what I called the 'Developer Library View' (DLV) which I argued should be implemented both in the Flash IDE, as well as the Flash Builder IDE (nee Flex Builder). So, developers who work with Flash would have an easier time coding with library symbols, and developers who prefer Flash Builder would not have to leave that tool in order to execute normal types of developer tasks in the Library (essentially, assigning class linkages and export settings, but also component-related settings).
The DLV is intended to make it easier to work with the symbol linkages and other coding-specific settings of all library symbols. The DLV contains a three panel layout. On the left, in Panel 1 (the Library Items panel), there is a vertically-scrollable (and filterable) list of all library symbols. In the middle, in Panel 2 (the Library Symbol Settings panel), there is a horizontally- and vertically- scrollable data-grid of all item settings. Panel 1 and Panel 2 are tied together, like an Excel spreadsheet, with the top row and the first column frozen. On the right, Panel 3 (the Properties panel) functions like the Properties panel already in Flash CS4, but with the contents modified to be relevant to the properties a developer would be interested in when working with a library symbol.
All three panels are horizontally resizable. In Panel 2, the Library Symbol Settings panel, all columns are infinitely resizable (or at least really large — you need to be able to see and work with really long package and class names). I envision a series of keyboard and mouse interactions designed to facilitate the workflow. For example, when you mouse-over a class assignment, buttons could appear that would allow you to launch the class file, and re-assign the symbol to another class file through a file dialog — and when you click in the class name, you can manually type to change the value. In this wire, as a suggestion, the colors red, green and black are utilized to indicate class status (black = Adobe class; green = found custom class; red = missing custom class). While the basic layout of this information is quite helpful, these additional interactions would add significant efficiency to any developer working with this interface.
Many of the commonly-accessed settings that now require right-clicking on library symbols would be moved into the Properties panel on the right for rapid access. One new feature I recommend here is like a mini Movie Explorer panel — revealing the display list of that display object in a tree-list format. And, ideally, the display list view would introspect an indefinite number of levels of hierarchy (revealing n levels of the display list under the selected display object) — and possibly introspect across all frames (e.g., when rendering the display list of a 10-frame MovieClip, we would see all distinct instances across all 10 frames — not just whatever instances are on frame 1). I would also recommend that the main timeline appear as an unremovable symbol in the library so that developers can work with main timeline linkages in the same manner as all other symbols.
Ideally, this Developer View could be implemented with a project-wide scope, rather than just an FLA-specific scope. And again, what's really important, is that this view / workflow should be supported in both the Flash and Flash Builder IDEs — any developer working with Flash should have this option — the workflow should not be restricted to a single tool.
And, of course, once you have this view supported in both the Flash IDE and Flash Builder, the tools should support live round-tripping — developers should have the ability to have the same project open at the same time in both Flash and Flash Builder (just like Silverlighters can do with ExpressionStudio and VisualStudio). But I suppose that's a separate battle, and we should be happy if we get the Developer Library View.
In the long run — in one or two more versions — assuming Adobe implements the XML-based XFL file format to replace FLA, then these issues become less pressing. Once the source format for Flash is XML-based — and since it is possible to read and write local files of any type in both Flash Player 10+ and AIR — developers can write their own tools to support their own workflows. In fact, if XFL were fully implemented as of today, there would be nothing stopping a talented and motivated Flash developer from turning the 'Developer Library View' (defined above) into a standalone AIR application. Now that's a future worth looking forward to.
Share and enjoy!