If you’re like me and still do manual versioning of files during a project (I do for spiking or prototyping), … and a bunch of the legacy versions of the file in your open project still give you annoying warnings or errors and you don’t want them to appear in the Problems view, you don’t have to close the project or move any files. Just remove them from the Flex Applications list under [project] > Properties > Flex Applications, and Clean your project.
The annoying warnings or errors for the undesirable files should then go away in the Problems view.
A few months ago I decided to get all zen on my desktop, tired of the clutter of icons. Then, as if by serendipity, I discovered Kevin Suttle’s FFAIR Desktop Wallpapers, and I thought, perfect! But none would fit my Dell 24″ monitor’s 1920×1600 resolution. So I took my favourite one, and expanded it a bit.
Feel free to download it here.
I’m very excited. I have just been handed the lead authorship role on the upcoming Professional Flex 3 title by Wrox/Wiley Publishing. No release date has been set, but it’s estimated to be out in the summer of 2008.
We are in the process of getting together a “dream team” of experienced Flex writer/developers for this project, and I just wanted to open up the process to anyone out there who may want to help write an important Flex 3 reference title.
The goal of this title is to be a very comprehensive, in-depth overview of the Flex ecosystem of technologies, and I am looking for people with good writing and communication skills and experience building visually expressive and/or data-oriented applications in Flex. If you have the passion, the chops and the time to help write this book, or think you might and you have a few questions, drop me a line at jbdesign-at-joeflash-dot-ca.
Feel free to pass on the word to any experienced Flex developers you know who may want to get involved.
Actually it isn’t. But some people think it is. I’ve heard the argument a few times, mostly by developers who have a chip on their shoulder about designers, as demonstrated by this fictionalized conversation with a developer about Thermo. (I gather the names have been changed to protect the guilty ;) )
Normally I don’t bother commenting on fictionalized arguments, it reeks a little too much of he-said she-said flamewars one sees so often. But I’ve heard this argument before, and not just about Thermo threatening the livelihood (read: dominance of) developers over designers, so I felt compelled to add my 2c.
Personally I think the whole argument of whether UI is the exclusive domain of either the designer or the developer, is a waste of time. I used to be a designer, trained in design, went to art school, yada yada. Back in ‘97 no one doing web apps knew anything about UI design on the web. We were all doing it by the seat of our pants. How did most of us learn UI design? By observing what works, what we personally find usable, as well as reading about emerging standards, and emulating that.
Now that I’m a developer through and through, and see things from a more code-centric viewpoint, I notice that although a lot of designers are trained in the tools they use, and are generally very good at design, many of them aren’t any better trained or experienced at UI design than a visually-oriented developer. So there’s a misconception out there that a) all designers made good good UI design, and b) all developers make bad UI design. I’ve see absolutely horrid UI design by very experienced people on both sides of the fence.
As a developer trained in design, I am not shy at tackling a UI design, and do a pretty competent job at it most of the time, but I’m very clear that I’m not an expert in Interaction Design. If an enterprise level app were dependant on my UI design, I would definitely get an UI/Interaction designer on the case. Unfortunately this kind of approach seems to be lacking in both RIA designers and developers alike. And most of it, I think, is simply because traditionally, it has been left up to the “creative person” on the Flash project team to do any of the visual stuff, or to the “deseloper” to manage both UI design and development. For small to medium-scale Flash projects this generalist approach works well; but when you get into large scale Flex projects with dozens of people on a team, specialists will need to be brought in, if for no other reason than to guide certain aspects of the architecture, whether it be visual or data-oriented.
And really, so what if Thermo produces code that needs to be tweaked a little to integrate within a larger project framework? It’s not like we’re talking about designing an HTML site in Word or Front Page or anything: Adobe is well aware of this concern, and is addressing it. And would that not give more work for the developers to do, not less? Developers who feel threatened by Thermo need to get a clue. And clients (or designers) who expect to develop full-blown data-enabled applications in Thermo without a developer are also out to lunch. Tools don’t make good RIAs, no matter how sci-fi they get. Only a good team can do that.
But Thermo might, just might, enable the fledgling “one person web shop” to pump out a few decent applications for Acme Co., or a enterprise RIA project development team to shave the time required to skin and visually design a Flex/AIR app.
I guess the point I’m making is that neither the “designer” nor the “developer,” or even the architect or the interaction designer, should be in charge of the UI design to the exclusion of other people’s input, even though most large teams have a hierarchical structure. It’s got to be a team effort; the moment you start posturing and “excluding” specialities as this piece demonstrates, your project is doomed to failure.
This is such an obvious axiom of RIA development, I wonder if the entire piece was intended as satire, to illuminate just how ridiculous the designer/developer divide really is.