Flash Usability 2 — More on Advantages, Disadvantages, and Best Practices
By: Chris Rubin de la Borbolla - Web/New Media Director, Rose Design, Inc.
Monday, March 4, 2002
As an advocate and long-term developer/designer of Flash experiences, I have seen the product flourish and develop quickly over the past several years. This growth has brought about specializations within the Flash community itself -- one is no longer considered simply a Flash designer. The Flash community is now populated with 3D animators, cartoonists, actionscripters of all flavors and expertise, sound engineers, application developers, Generator integrators, consultants, and so forth. Regardless of a particular developer's specialty, usability and best practices need to serve as a common ground from which to engineer and design applications and experiences in Flash.
After reading Tom Wheeler's "Flash Usability" article, I thought it best to answer some of the questions the article may have left open and add additional advantages and disadvantages.
I will include as part of this article the list of advantages and disadvantages Tom outlined and will then add to the descriptions and clarify. This exercise will allow us to distinguish between advantages/disadvantages innate to the technology of Flash versus advantages/disadvantages associated with the deployment and design of Flash solutions by the development community. Finally I will then conclude with best practices as we have discovered over the years of having worked with Flash since version 3. The overall objective of this article is to disseminate between the reality and misconceptions that have surround Flash design and development.
Advantages (of Flash as a technology)
These advantages are innate to the engineering of the Flash technology as opposed to the actual implementation by a Flash developer/designer.
-
Vector Graphics
Flash uses lightweight, flexible, mathematically-rendered, and resolution-independent vector graphics. The only other current alternative is SVG which is narrowly supported and more difficult to implement.
-
Little or no programming knowledge is necessary to use Flash
This may be true in some cases, but largely depends upon the nature in which Flash will be deployed. In any event, programming knowledge proves very useful when dealing with custom actionscripting or planning a Flash solution that may involve interactivity between a server and a client. As far as actionscripting goes, the skills vary from those that are using the barebones functions and properties in Flash to those who are creating custom scripting that may communicate with application logic and databases.
-
Flash SWF format is fairly open standard
Several authoring tools currently exist such as LiveMotion, in addition to several of the other tools made by Macromedia.
-
Widespread acceptance and adoption of Flash Player
See Marcromedia's Website for the latest statistics and information. This is a detailed independent third-party report produced by NPD Online Research. As of this publication, results show that 98.3% of Web visitors can experience Flash content without having to download and install a player. Broken down further, the install base of the Flash 5 player is around 86%.
-
Cross-platform development environment
Flash content can be authored on the Mac and PC platforms.
-
Allows for user interactivity
Interactivity is only limited by the developer's imagination. With access to key, mouse and data events in addition to the ability to facilitate communication amongst all movie clips, the sky's the limit.
-
Reusable Objects
These include Shared Symbol Libraries, Smart Clips (Flash 5), the Flash Connector Kit for ColdFusion, the Flash Component Kit for ColdFusion, and Flash Extensions made available at the Macromedia Exchange.
-
Modularity
Since Flash has been engineered along the central notion of the movie clip, this allows developers to break up Flash environments into smaller discrete components (movies) which can be loaded into the main movie or other child movie clips. This lends itself to better project workflow with granular control, since separate Flash developers can work on specifically assigned components of the overall experience rather than having to juggle a single version of the source file amongst many developers. As an example, an audio engineer can work with a music movie while an advanced actionscripter codes and tests functions within his/her movie. Additionally, this modularity allows developers to create smaller movies that can be downloaded as needed by the visitor to the Flash site.
-
Streaming and Preloading
The ability to control streaming in addition to preloading assets is an invaluable feature that has improved greatly with the newer releases of Flash. A wide variety of preloading approaches are available which allow elements used initially (or throughout the Flash movie) to be downloaded before playback begins. With streaming in place, a Flash experience can be loaded in the background during playback — this may be used in conjunction with preloading in order to allow for a "buffer." In particular, with Flash 5 actionscript, a developer can exercise a great amount of control over preloading and streaming abilities without having to go through the arduous use of javascript detection, FSCommands and actionscript.
-
Low-bandwidth consumption
Contrary to some current practices, Flash was designed to be an alternative to higher bandwidth solutions with the added benefit of advanced interactivity. Several years ago it was rare to see a Flash experience over 500K. It is good programming practice to keep initial loading sizes small and then either stream or preload more media as needed. Bandwidth detection can also be put into place in order to deliver content based upon an end user's connectivity. This information can then be stored in user preferences for later use.
-
Integration with server-side application logic and databases
Flash is not constrained to functioning only on the client-side (within the browser). It is fully capable of communication with application logic (ASP, JSP, ColdFusion, PHP, etc) and data sources in order to bring timely and fresh information to an end user. For many years Flash, Generator and ColdFusion have been working closely together to deliver information-rich user interfaces. Information can be sent using standard GET and POST methods in addition to XML support.
-
Small plug-in
With a thumbprint of around 300K, the Flash Player is one of the smallest third-party plug-ins in the marketplace. With such a small size, even visitors with slower connections (28.8) are able to download and install he plug-in within a reasonable amount of time. Average download times are 46.6 seconds at 56K, 20.5 at ISDN, 2.6 at T1 speeds.
-
Client-side variables and actions
As a self-contained environment, Flash is natively able to store client-side information (variables) without having to re-establish a connection to the server environment. Additionally, by using actionscript, actions, functions, and aggregate functions can be created, called, and made to utilize available variables — all of this being performed within the client environment!
-
XML Support
With the release of Flash 5, primitive XML support and XML Socket support is included allowing for parsing of XML data by the Flash player. Though limited, such support demonstrates a strong adoption of industry trends that will remain. The development community has made great strides in enhancing the parsing and efficiency of the XML abilities.
-
Integration with Generator
If used online (in real time), Macromedia Generator enhances Flash experiences by allowing you to create personalized Flash SWF movies on-the-fly with connection to live data sources. Generator also features its own set of data objects that add functionality to the Flash environment. Some of the objects included are charts, graphs, tickers, lists, plots, and tables. If utilized offline, Generator can accelerate the production process -- in particular where there may need to be many Flash files created that are template-driven and connected to a data source.
-
Supports export to multiple file formats
The final output from Flash can be exported into one of many formats including image files (GIFs, JPGs, PNGs), Quicktime movies, Flash files (SWFs), as well as Mac and PC projectors.
-
Reusability
New functionality and interfacing can be created from the preliminary Flash application for other media and presentation devices. For example, the created Flash application could have a much wider use (and distribution) including Web, kiosks, standalone multimedia, CD-ROMs, PDAs, and even PS2s, with reduced costs.
-
It's hard to print text rendered in Flash
With the release of player version 4 r20, control over printing was added. Another alternative is to have a print-ready version available, made easier if your site is database-driven. Lastly, with the release of Flash 5, the actionscript functions print() and printAsBitmap(), printAsBitmapNum(), and printNum() were added allowing control over both areas to be printed in addition to bitmap or vector output.
-
It's not always possible to select, copy, and paste text rendered in Flash
The solution is to either make the text selectable within the Flash environment or offer another pure text version outside of Flash.
-
Lack of user control
To make use of the browser's status bar (in order to tell visitors where a link may point to), you can exploit the ability to communicate between the Flash environment and JavaScript. Refer to Macromedia Technote #14827. There is also a developer extension available within the developer's exchange. By doing this you will be able to inform a visitor where a link points. As far as finding text within the page of a Flash document, there is no native support for this feature. Several possible solutions to the problem could be implemented including creating smartclips, external library elements or actionscripts that would make use of string manipulation/recognition coupled with loops in order to find the desired text element and then highlight it. The extent of programming will depend upon the Flash scenario and whether the text is hard-coded into the Flash movie or driven from an external data source.
-
Lack of search engine support
In the world of search engines, best practices still point to creating a number of targeted "doorway" pages that are both search engine-specific and keyword-specific. These can easily be implemented with a Flash solution with a majority of the work being the standard monotonous replication of HTML pages, manual registration with search engines, and so forth. Additionally, Flash content that has met the accessibility guidelines as outlined at the Macromedia Flash Accessibility site will be search-engine ready.
-
Accessibility problems
As far as accessibility, Tom brings up two issues: the first addresses visitors with poor eyesight or disabilities and the other centering on the availability and versioning of the plug-in. Regarding accessibility, Macromedia has recently focused on a new initiative specifically addressing compliancy with Section 508 of the US Rehabilitation Act. These rules govern federal agencies in addition to federally-funded Web experiences. More information is available from Macromedia. Flash 5 now supports HTML text (in a very primitive form), which can be controlled dynamically and in real time through actionscript. Instead of re-scaling the movie clip (which can cause distortion and problems), this actually allows for the font size to be altered. We have been played around with this feature and have gotten it to work without problems. When deployed properly, visitors are able to increase or decrease font size within certain point sizes. Another possible solution may be to use the native ability of Flash to zoom-into areas and create user controls to facilitate this. Regarding the second issue, Flash player availability, developers must remember that before any project is initiated that the target audience or demographic needs to be identified and agreed to by all parties involved (developers and clients). Some things to consider include: connectivity speeds, player versions currently in use, technical ability/familiarity, and security issues such as firewalls, proxy servers, etc. Once this has been determined, your role as a developer should be fairly smooth.
Regarding player detection and updates, there are several models to choose from depending upon the technical level of the target audience. The easiest (and laziest) approach (for the developer) is to have the end-user make the decision and offer a gateway page where the requirements for the site are outlined and it is up to the visitor to know what s/he has as far as browser type, player version, processor type and screen resolution. The other extreme is to implement what we term ‘smart-detection' which utilizes a combination of JavaScript and actionscript to detect the player version (and any other attributes you may need to gather). Once this has been determined, you can direct visitors to different versions of the site or static HTML pages where instructions and links are made available to either allow the end-user to get the proper plug-in or go to an alternative version of the site. In conclusion, identifying the target audience and use of the Flash experience will make decisions on how Flash will be deployed much easier and avoid client discontent in the end.
Disadvantages (of Flash as poorly deployed)
The following disadvantages are the result of poor programming or architecting of the Flash environment. In many cases, simple actions can be put into place to guard against any of these mistakes.
-
Long download times
This is something that should never have been associated with Flash since it was designed to create interactive experiences that are both low-bandwidth and streamable. Even for Flash content characterized by an accompanying storyline with full animation and audio analogous to traditional TV-style cartoons, there are practices that can be utilized for optimization. As you may recall, the series that Stan Lee did for Shockwave.com were fairly long and still had an overall thumbprint of a couple of megs. In general, it is best to keep files sizes as small as possible and break up the experience into modular components.
-
Flash disrupts normal use navigation
This is probably one of the most pronounced complaints against the use of Flash and one that has been propagated by a general lack of standards and the drive towards esoteric interfaces. Due to the high versatility and fluidity of the Flash medium, it innately will push designers to create new navigational paradigms. As with any new medium, its implementation should be carefully deployed after having answered the following two questions: Who is the target audience? And, how is Flash best positioned to solve the business problem? More than likely, a distinct set of usability practices can be discerned between Flash experiences that are part of the corporate landscape versus those that belong to the personal or Flash community. If the target audience is a set of users used to Flash and have had regular exposure then navigational engineering will more than likely be less accessible by non-Flashers.
-
Flash lends itself to self-serving sites and design excess
This is another example of poor usage that is a product of the tabula rasa that the Flash environment invites.
-
Stale content
With the appropriation of Allaire last year and a new marketing push towards solutions rather than products, Macromedia has focused on tighter integration between the server environment and the client allowing for fresh Flash content. The past several versions of the player have supported the ability to send and receive data within the Flash environment via HTTP GET and POST. With the release of version 5, XML and XML Socket protocol have been added to the mix. Though still in their infant stages, the development community has provided tools and scripting that have greatly enhanced Flash 5's capabilities and version 6 will have large improvements in this area. The solution to stale content is two-part: One, get connected to a data source, and, two, establish a content management scenario. There are several scenarios for data-driven Flash applications and, for brevity's sake, I will quickly mention a few here.
The most commonly used method is to create a direct connection between the application logic (ASP, ColdFusion, PHP, etc) and the Flash environment. Information can then be sent using the HTTP protocol and the GET or POST method. The most commonly used actionscript functions are LoadVariables and GetURL. Variable and data can be distributed amongst the Flash, application and Javascript environment. With Flash 5, XML Objects were created to allow larger chunks of information to be sent between the Flash client and the server. The formatting of the data is not limited to URL Encoded name/value pairs. This allows for more data in a looser format to be sent. Another means tokeep content fresh is to couple Flash with an offline or online Generator solution -- or an equivalent. This server technology allows you to create custom, personalized *.swf files on-the-fly according to a present schedule (offline) or in real time (online). Generator is able to communicate to application logic and data sources in a variety of ways including, but not limited to, direct SQL statements, calls to application pages, or text files.
-
Massacring the processor
A general trend that we have noticed is the general lack of performance optimization based upon an end-user's processor. This especially becomes crucial when developing in Flash for mobile devices (whose CPU's are much slower in order to conserve battery life and costs). Developers/designers need to bear in mind that the target audience may not be viewing Flash content on the same machine as s/he is developing it -- this machine usually being state-of-the-art. A simple means of testing is to have several machines (including the oldest Pentiums) available for development and testing.
Overtaxing the processor results in sluggish performance and, even worse, systems freezing up and crashing. Things that contribute to processor over-performance include simultaneous tweens, perpetual actions in multiple movie clips within the same Flash file, perpetual actions in multiple Flash files (for example, a Flash movie may be launched within a new pop-up window and chug along in addition to the main Flash movie that launched it), window size, and higher frame rates.
-
Non-thorough testing/troubleshooting (cross-browser/cross-platform readiness)
It is critical to know the in's-and-out's of how the Flash Player performs on different platform-browser-player configurations. This may extend to the use of system fonts, the ability to use GET and POST, XML support, and other features.
Tips and Best Practices
In closing, rather than list ad infinitum specific tips and practices, I would like to cite some general considerations in thinking through a Flash project from the beginning. These have served to provide an important foundation for architecting such experiences.
-
Define the target audience
When developing in Flash, this should be one of the first questions raised in order to see whether or not Flash is even an applicable solution. Information that is critical includes: the player versions that are supported and being used, browser/platform configurations being used, the web-savvyness of the end user, connection rates and bandwidth availability. Once the audience set has been determined, then proceed along the best path. If there has been no target market established make use of industry statistics to provide a means to an informed solution.
-
Define the scope
Obtaining a definition of scope and related specifications is vital in engineering a good Flash solution. Parameters may include database connectivity, application environment, scalability, portability, usage, file sizes, investment and time-to-market. Once scope has been determined it is a good practice to document and develop an organizational flow of information so that all persons involved in the development of the Flash experience are on the same page. This may involve naming conventions for variable names, file names, database rows, etc.
-
Watch frame rates
As Flash developers attempt to increase frame rates in order to provide more fluid experiences, keep in mind that the virtual reality we are authoring for is largely controlled by the CPU -- especially when it comes to Flash. Additionally, higher frame rates add to the overall file size. Developers at SayDesign (presented at the FlashKit LA 2001 Conference) have done a good deal of testing Flash players on the Mac and PC platforms in order to find optimal frame rates. Their results say that the players perform differently when optimized for different frame rates. For example, setting fps to 20 will result in a playback of 20 fps on the PC player and 15 fps on the Mac (a noticeable 25% difference).
-
Watch the processor
Don't massacre the processor. This can be implemented by being aware of several key factors mentioned previously. As far as troubleshooting use tools indigenous to your OS or third-party tools (Windows has a Task Manager in which CPU Usage and performance can be monitored). Set a threshold and keep an eye on the performance — make sure to watch the CPU meter when the Flash movie is embedded within its HTML environment in addition to testing within the Flash authoring environment. Remember that other applications running may also set the baseline at a value greater than zero, so take this into consideration when optimizing your files.
-
Watch file sizes
Sound, fonts, and graphics can quickly add weight to a Flash file. Use the bandwidth profiler to emulate varying stream rates and optimize accordingly. By using this tool, you will be able to stream and preload elements according to their order of importance. Additionally, make sure to keep the end user informed as to what's happening, whether this be what percentage of the movie is loaded, the number of bytes loaded, time remaining, etc. Lastly, make use of the "Generate Size Reports" option when publishing Flash files. This file will return a list of all the elements included in the swf file with the amount of file size occupied by each, as well as the order of appearance. This will be extremely helpful in compressing images, symbols and sounds.
-
Avoid hard-coding when possible
In order to scale faster and make changes easier to implement, avoid hard-coding when possible. There are numerous approaches to this including: creating functions and objects in Flash 5, utilizing external data sources to populate the information within the Flash environment, variable-izing whenever possible, or using Generator in order to produce template-driven content.
-
Be aware of platform/browser/player differences
As a developer you should be aware of small distinct differences between how the Flash Player operates within the different browser/platform environments — the most notorious being the Mac IE 4.5 scenario or view the entire matrix.
-
Think of the future
Lastly, remember that Flash on the Web is only a small aperture in the realm of digital experiences. When creating Flash experiences, think beyond the immediate application that you are developing. The next phase of the project may include porting the experience over to other devices or adding features and functionality. In any event, it's easier not to have to reinvent the wheel as Flash development moves onward.
If you have any questions or would like to discuss any of the above points, feel free to email me at chris@rosedesign.com.
