Clever Technology Inc.

don't just say okay

So last month we got a call and subsequent RFP for developing a website, and a few paragraphs into reading the document a deep chill went down my back.  The project was content-heavy, had a very specific need for internal management and future growth, and needed to display sections of their content in a very specific but easily-navigated manner. The problem with this was that they wanted all of their gorgeous, user-enabling content to live within an all-Flash website.  While we hadn't yet sat down to discuss the project, I suspected from reading the RFP that Flash was not going to be a very good fit.

Let me establish this first: I really like Flash (and Flex, for that matter) and have used it since its early days as Future Splash.  We still work with Flash or Flex in many of our projects, using it for application interfaces, media displays and in animation.  This said, whenever we're approached to do an entirely Flash-based site, I always feel obligated to give our clients a fuller picture of what issues might arise from this decision.

Flash is essentially a compiled, independent application running within the browser, as opposed to an HTML document that is read or 'interpreted' by the web browser.  This means that while the browser controls many aspects of how an HTML web page will appear, a Flash-based page is in charge of itself and only works with the browser in the most abstract way.  In some ways this is a very good thing, such as the ability in Flash to use whatever font you wish, or to load images and content as you need them.  There are less desirable aspects of a Flash-only website, however, and these can weigh heavily against a website's full potential.

In our initial client meeting we discussed the scope of the project and what their short- and long-term goals for the site would be.  They wanted a site that was visitor-friendly, easy to maintain, designed towards growth, and organized their information in a way that would be easy to navigate.  By the end of this discussion it was clear that a Flash-based website would conflict with several of these goals, so I opened the discussion to the possibility of changing the framework from Flash to HTML.  It was evident that they already had worries in this regard, and the subsequent conversation brought structure to their concerns.

The first point I raised was that Flash is not friendly from a content management standpoint.  It is essentially a compiled application, custom-written from the ground up to specifically meet the needs of the client.  Instead of simply displaying their content through the use of HTML/CSS layout, everything would have to be programmed and laid out in a fairly rigid format.  Added to this, to manage this content we would also have to custom-build the back-end administrator.  (Note: any time you hear a web developer use the word 'custom', you should be think 'added cost and time').  Another significant issue was that a Flash-only website would never be as Search Engine Optimized (SEO) as an HTML-based one.  Google and Yahoo do not read the content out of Flash movies, and even if they did it would be entirely out of context and valueless in terms of indexing the website or individual pages.

Finally, I pointed out that there are many inherent issues with the 'user-friendliness' of a Flash-based website.  Visitors take features like back/next browser navigation, browser caching, copy/paste problems, printing and bookmarking for granted, but these can be a problem in Flash-based sites.  The idea behind usability is to keep the cup as full as possible 'ease-of-use wise' for your website; each of these issues can drain a little out of that cup and eventually frustrate your visitors.

Until recently, Flash was the only way to make a site dynamic, sexy, and vibrant, and many clients had to accept the costs of a Flash website to achieve their goals.  Luckily this is no longer the case.  Thanks to tools like AJAX, Spry, jQuery and other recent innovations, what used to be strictly Flash territory is now a much more open playing field.  Even where Flash is the best solution, it is often better to integrate into an HTML design to avoid the expense that an entirely Flash-based website would entail.

As to the underlying theme of this posting, I've always considered an RFP as a 'work in progress'. Clients assume that the companies they approach are experts in their industry, so responding with questions and recommendations is rarely met with surprise.  It's far better to risk conflict by discussing their choices than just tallying up the hours and handing over a quote; you should always start a new relationship, business or otherwise, with all your cards on the table.  Of course in the end the website is theirs, and if they decide upon a course that you don't necessarily agree with, at least you will know they did so with information in hand.