Blog / 2011
Flash in a Pan? Thoughts on Flash production...
September 21, 2011 by Peter Loomis
The use of Flash as a development platform for web sites and other web media is one very relevant and current issue that has been on my mind with respect to investment in development platforms and technologies as well as something that's been coming up with clients lately.
In addition to Steve Jobs' very eloquent and influential posting about his Thoughts on Flash which I just came across on the Apple site, I wanted to offer some of my own opinions after working with Flash as a professional interactive designer, art director and rich media specialist for over 15 years in both New York and San Francisco. I have worked on Flash projects with clients such as Maybelline, Affymetrix, Nokia, eBay, MGM CityCenter, Sugar Ray Leonard, IdealBite and Disneynature.
PROS
1. Consistent & cross-browser compatible
We can start with a bit of good news to grease the wheel a bit... Since Flash represents a true cross-browser delivery method, via their browser and OS versioned plug-ins, the overal display consistency is typically excellent when viewing on Mac or PC, and also between various browsers. Theoretically, everything should be identical, as long as the Flash plug-in is up to date and the fonts are either embedded or available on the user's machine.
2. Valuable fallback media delivery
Even with the advent and ascension of HTML 5 as a more modern web technology, there are still a lot of older browsers out there that can represent a significant proportion of the population. Granted that newer computers will be bundled with more up-to-date versions of the plug-in, but for those technophobes who have a computer that still works, but they don't know how to update their browser or Flash plug-in, this will still usually work, provided you export a your files set to a player version that is a few years old... This is really the defining factor for backwards compatibility with Flash plug-ins, otherwise, most of the modern browsers will support HTML 5 options also.
3. Established conventions and ways to integrate common technology
Deployment pathways hwave already been carved within Flash technology for some now-standard user-interface options such as full-screen access, as well as a robust engine for online application development. Translating Flash items to non-Flash construction will almost undoubtedly present some development cost. Then again, so will continuing to pay someone - who might have to be a highly-trained specialist in Flash to understand or decipher how your site was built in order to maintain or update it.
CONS
1. Closed system & subject to Adobe
Versus HTML5 / CSS / JavaScript editing Flash to me seems like a slightly clumsy editing process. The programs take longer to open and load than text editing software, there is an inherently closed development system with Flash CS programs bundled with other Adobe software which can be expensive to purchase and maintain active licenses. This is from my own developer's perspective.
2. Sub-optimal SEO implementation
Although SEO and metric tagging is possible with Flash, the added layers of file and content nesting usually result in a sub-par experience for creating a multi-page web of content like a web site. Sure you can create them, but often a site that's built entirely with Flash, will contain one or few actual HTML pages from which to draw their meta and searchable web of relevant content. It is possible to embed alternate, non-Flash content, but producing content in multiple formats increases production time and costs. Also, it is common for sites to serve multiple sections and subsections of content from within them. While alternate content could be placed on the HTML pages containing any number of pages, it is optimal to have smaller individual pages with more relevancy to create a wider web of information for search engines to pick up.
3. Potential complexity
The variety of production possibilities can lead to many variances in file construction which can also make it more complicated for another developer--unfamiliar with the previous developer's intentions or even those of a pre-existing and well thought out branding process--to understand exactly how the site or files are constructed. This in turn has the potential to take more time and result in a higher cost to a client.
Now this could be viewed as a pro or plus side of the Flash platform, sure, it encourages production and allows for multiple ways...which is great for your developer.
HOWEVER, it creates potential challenges if you ever switch developers or if you are NOT the developer, as the code can be constructed in many different manners and increases the potential complexity, and realistically, the potential cost of your developer, commensurate with technical skills and up-to-date software development tools.
Sure, the ideal and possibly most savvy coders may keep their files super well organized. But I know from my own experience that developers do not always keep organized files or clean them or before transferring them to another designer. Nor is there always the well-intentioned transfer of organized files...or perhaps it is the indiscretion of the previous design team to leave symbols with random names and code placed throughout a matrix of frame actions, symbols, movies and scenes, rather than all in a clean, well-organized and portioned out Actionscript document which could even be externally located from the actual Flash application.
Actionscript is the true way to do things (in Flash) for increased interactivity and object-oriented coding. But significant archives of older or less-often updated sites or files still contain legacy traces of timeline and frame or symbol based scripting and development. Actionscript 2 still works and produces great web sites even by todays standards...which by the way, have changed and are definitely moving towards Actionscript 3 or even more-so mobile development for apps and devices, rather than the web.
Some of this is just ranting against the more-involved process of editing files within Flash versus the easy updating and editing of files with a mere text editor, diving straight into the precise variable that needs modification and clicking a few keys to change the value, and hit save. Having to export a the Flash file format (vuersus saving an HTML or text file only, really) can add up over production periods and testing/debugging issues. Also, Flash requires the startup time for such a very robust program to cycle through and open, listing scores of developers while watching their application logo at startup...yet another area where Flash proves to require additional development time from the client's budget. This is almost negligible, except that the many fractions involved could -- and do to the developer who edits Flash a lot -- add up to a long time, depending on how much file interaction there is during updates and how often the source files are used in production.
_ PL _
PERSONE