Flash Design Techniques (Archived Report)










PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The reader
is available for free
download
.

Archived Report:
Flash Design Techniques

by Lynn Greiner

Docid: 00011436

Publication Date: 1604

Report Type: TUTORIAL

Preview

In its heyday, Adobe Flash provided a nearly ubiquitous platform, highly-efficient Web delivery formats, and a comprehensive solution to the problems of cross platform content distribution. For enterprise
Web publishers, it was a versatile, cost effective, "future proof" content development tool.
However, for mobile developers, it quickly became a
dead end, and now, fuelled in large part by security issues, the industry is
slowly but surely moving away from the technology.

Report Contents:

Executive Summary

[return to top of this report]

Adobe Flash is an authoring tool for designers and developers of presentations, applications, and other content that enables user interaction.

Related Faulkner Reports

Adobe Systems Company Profile

Flash projects can include simple animations, video content, multimedia presentations, applications, and everything in between. Flash
was considered extremely
well-suited to creating content for delivery over the Internet because its files
are very small. Flash files run on the client resident Adobe Flash Viewer,
present in one form or another on most desktop computers
until recently.
The combination of this ubiquitous platform, highly efficient use of network bandwidth, and a near comprehensive solution to the problems of cross platform distribution made Flash an extremely attractive, cost effective way to deliver
Web content. However, Adobe ceased producing the player for mobile device
browsers after version 11.1, choosing to focus on HTML5 for these
platforms. As a result, the industry is quickly moving away from
the product entirely, with only 17 percent of the half a million Web sites
monitored by the HTTP Archive now using Flash. A year ago, that
number was 24 percent, and five years ago, it was 48 percent.

Flash facilitated collaborative work among multidisciplinary Web content development teams. Because managing these sorts of diverse collaborations is always challenging, Adobe and the Flash Development Community articulated comprehensive Best Practices for Flash design. These
are useful safeguards that could help ensure the timeliness and maintainability of content, and any serious ongoing Flash content development effort should consider their adoption.

Description

[return to top of this report]

Flash is an authoring tool that designers and developers use to create presentations, applications, and other content that enables user interaction. Flash projects can include simple animations, video content, complex presentations, applications, and everything in between. Traditionally Flash is used for
Web content, but it can also be used for desktop applications. Adobe has
withdrawn support for mobile devices. Individual pieces of content made with Flash are called applications, even though they might only be a basic animation. Flash applications, often called Rich Internet Applications (RIAs), are known for their use of images, sound, video, and special effects.

Flash is optimized for creating content for delivery over the Internet because its files are very small. Flash achieves this through extensive use of vector graphics. Vector graphics require significantly less memory and storage space than bitmap graphics because they are represented by mathematical formulas instead of large data sets. Flash content also takes advantage of significant client-side processing power, as it is presented by a client resident copy of Flash Player, a vector graphic rendering engine which senses the client system’s capabilities and adjusts content playback accordingly.

To build an application in Flash, Flash drawing tools may be used to create graphics. Additional media elements may be imported into the Flash document as well. Designers use the Flash development environment and tools to specify how and when each element of content is displayed and in what ways the user may interact with content.

Current View

[return to top of this report]

Adobe’s Rich Internet Application Concept and Adobe AIR

In contrast to
Web applications based on static HTML and textual content, Rich Internet Applications (RIAs) are designed to offer an improved user experience when performance is important.
The purpose of the
Web app is to provide tailored or contextually driven information or where the user may require large amounts of data that aren’t available by default after initial page load. Adobe has played a pioneering role in developing tools that make it possible to create beautiful, engaging content
that captures and keeps viewers’ attention and integrates well with server-side horsepower that drives an RIA by feeding it content and
data. Adobe Flash is a key tool for creating the winning visual appearance typically associated with
RIAs. RIAs have proven to be extremely effective at increasing the effectiveness of
Web based sales, marketing and interactive teaching for the following reasons:

  • Contextual continuity: Because HTML-based browser applications are page-based, when a viewer wants more information or a differing view of information displayed on a landing page, the browser must request a new page. Page request and load is a time consuming and cognitively disruptive event that takes between
    two and five seconds. During this interval, the viewer’s attention wanders or even evaporates entirely. By contrast, RIAs retrieve content in anticipation of viewer interest. Rather than loading whole new pages, the RIA reveals content that has already been loaded in the background, unnoticed by the viewer. This prevents the app from losing the viewer’s focus and engagement.
  • Productivity/Effectiveness: Optimizing viewer focus is demonstrably effective when trying to make sure people remain engaged by tasks like making purchases
    and using online educational or tutorial content.

Adobe AIR is a cross-platform runtime environment for builders of rich Internet applications using Adobe Flash, Adobe Flex, HTML, or Ajax. Adobe AIR is significant to Flash designer/developers because it makes large scale team programming far more efficient and productive. Discipline teams (such
as designers, programmers, and database administrators) building apps using the Adobe tools can agree at an early point in the design cycle
on what the functional objectives of each effort must be, then work in parallel without significant concerns about how presentation layer, data, and business logic will integrate. As of February 2010, there
had been over
200 million installations of Adobe AIR around the globe, and Adobe
expected 200 million smartphones and tablets to support AIR
applications. In April 2014, it announced support for packaging AIR
apps for x86-based Android devices and claimed there were over 20,000 mobile
apps (down from its previous claim of 50,000) using Flash technology via AIR
in the Apple App Store and Google Play.

Adobe Animate CC
This Web-based
develpment tool, formerly known as Flash Professional CC, is part of the Adobe Creative Cloud, and is sold
separately by subscription for $19.99 per month,
or as part of the full Creative Cloud. It includes HTML5 Canvas support, improved HTML publishing,
WebGL support, 64-bit architecture,
and a simplified user interface as well as
continuing to support Flash SWF and AIR formats. It is
designed to be extensible to support other formats as required. Users can synchronize settings between computers through the Creative Cloud.

Flash for Mobile Devices
In November 2011, Adobe announced that it would cease developing Flash for
mobile devices after the release of version 11.1, instead focusing on HTML5
for browsers and AIR for app stores. However, it is permitting third parties
to develop mobile Flash, and several vendors have already announced their
intention to do so.

Flash for Linux
Flash support for Linux is only available through the PPAPI (codemaned “Pepper”) as part of Chrome. After Flash 11.2, it was no longer
available as a download from Adobe.

Best Practices for Flash Designers
Flash documents have a propensity to become both voluminous and complex, particularly when they are developed by multidisciplinary teams. For this reason, the Flash community has articulated an extensive body of acknowledged "Best Practices" which can speed team development and ease the burdens of maintenance as content ages.

A new "Social" service adds levels of complexity that must be taken into
account. It streamlines integration between Web applications and fourteen
leading social networks by using Facebook Connect, Sign-In with Twitter,
MySpaceID, and LinkedIn.

Premium APIs
In March 2012, Adobe announced a set of premium APIs targeting game
designers who will need to license these APIs separately. According to
Adobe’s roadmap, "Developers who want to use Stage3D in conjunction with the
fast-memory opcodes via the domainMemory API must license their usage from
Adobe. Aside from their use in conjunction with the Stage3D APIs, there are
no restrictions on the usage of the domainMemory API."

However, as of January 2013, the APIs were no longer classified as
premium features, and developers who had used them were no longer required to
submit royalty payments. There are currently no APIs classified as premium;
the company says it may add premium features to the bundle in the future.

Currently, Flash Builder 4.7 is a development environment for games and apps,
which uses ActionScript and the open source Flex framework. It contains features
to make building games for Windows, MacOS, iOS, and Android quicker and more efficient.

Organizing Timelines and the Library

Frames and layers on a timeline are two important parts of the Flash authoring environment. These areas show where assets are placed and determine how the document behaves. The way in which the timeline and library are set up affect the entire Flash Document (FLA) file and its overall usability. The following guidelines help author content efficiently
and provide other authors who use FLA documents a greater understanding of
document structure.

  • Naming Layers – Each layer should have an intuitive layer name and related assets placed together in the same location. Avoid
    the use of default layer names (such as Layer 1, Layer 2), which can be confusing when working on complex files. Place layers that include ActionScript and a layer for frame labels at the top of the layer stack in the timeline. For example, it is a good and common practice to name the layer that contains ActionScript "actions."
  • Use Layer Folders – Use folders to group and organize similar layers.
  • Lock Layers When Necessary – Lock layers that are not being used or are not to be modified. Lock the ActionScript layer immediately so that symbol instances or media assets are not placed on that layer.
  • Never Put Instances or Assets on a Layer That Includes ActionScript
    – This can cause conflicts between assets on the Stage and the ActionScript that references them. Because of this, keep all code on its own actions layer and lock it after creation.
  • Use Frame Labels – If reference frames are being used, use frame labels in an FLA file instead of using frame numbers in the ActionScript code. This is important and useful if those frames change later when editing the timeline. If frame labels are used and moved on the timeline, references in the code do not have to be changed.
  • Use Library Folders – Use folders in the library to organize similar elements (such as symbols and media assets) in an FLA file. If library folders are named consistently each time a file is created, it is easier to remember where assets are located.
    Group related objects into folders when their number exceeds 20 items. In
    addition, determine meaningful file and folder naming conventions and avoid
    default names such as Symbol 1.

Using Scenes

Using scenes is functionally similar to aggregating multiple SWF files to create a presentation. Each scene has a timeline. When the playhead reaches the final frame of a scene, it progresses to the next scene. When publishing an SWF file, the timeline of each scene merge into a single timeline for the SWF file. After the SWF file compiles, it behaves as if the FLA file was created using one scene.
Scenes can cause problems if not used correctly, for the following reasons:

  • Scenes can make documents confusing to edit, particularly in multiauthor environments. An FLA document user might have to search several scenes within an FLA file to locate code and assets. Consider loading content or using movie clips instead.
  • Scenes often result in large SWF files. Using scenes encourages a programmer to place more content in a single FLA file. This results in larger documents and larger SWF files.
  • Scenes force users to progressively download the entire SWF file, even if they do not plan or want to watch all of it. The user progressively downloads the entire file, instead of loading the assets they actually want to see or use. By avoiding the use of scenes, the user can control what content they download as they progress through the SWF file, allowing better bandwidth management. One drawback to this approach is that it requires management of a greater number of FLA documents.
  • Scenes combined with ActionScript might produce unexpected results. Because each scene timeline is compressed onto a single timeline, inconsistent ActionScript can result.

Scenes can be used advantageously for some tasks. For example, they are a good choice when creating lengthy animations. Review corporate needs and the needs of the audience before deciding.

Saving Files and Using Version Control

When saving FLA files, it is important to consider applying a strategic naming scheme for documents. Problems may occur if a programmer edits a single FLA file without saving versions incrementally. File bloat and an increased risk of corruption are important considerations when deciding how much to rely on Flash’s built in change history management facility. Use of version control solves this problem in a systematic, reliable way.

The following are different ways of saving new versions:

  • Select File > Save As, and save a new version of document.
  • Use version control software (such as SourceSafe, CVS, or Subversion) or the Project panel to control Flash documents.

Outlook

[return to top of this report]

Adobe has asserted that, in one version or another,
its Flash player is installed on up to 99 percent of the networked computers worldwide.
Given declining industry support, that number is likely optimistic
today.
The forecast that Flash was here to stay as a tool for
developing and disseminating cross platform desktop Web content
is no longer valid. Mobile Flash
has been off the table as a mainstream
technology from Adobe for five years, and industry pressure
is forcing online marketers to change to HTML5 for their web initiatives as
well.

Adobe’s Open Screen Project

In 2008, Adobe pioneered the Open Screen Project, a broad coalition of more
than 60 computing, telecom, and content industry giants. Open Screen aims to
leverage Adobe technologies to create a consistent content publishing and
delivery platform that spans four classes of electronic devices: Laptop and
desktop computers, mobile internet devices (Netbooks, UMPCs, tablets and
the like), smartphones, and televisions. At the 2009 GSMA World Mobile
Conference, lead Open Screen partners Adobe and Nokia announced that they
were jointly funding a $10 million Open Screen Project fund, intended to support developers engaged in the creation of cross cutting content hosted on the Adobe Flash Platform.

The effort was significant because, in 2008, mobile phones outsold PCs four to
one and forecasts predicted very strong growth for the
tablet class of devices as well. Adobe Open Screen initiative
was a preemptive move to "future-proof" its
developers’ business spaces and the large volume of Flash legacy content that
would find its way onto small screens. The Open Screen Project FAQ said it thusly: "Companies
contributing to the Open Screen Project share the vision that a
consistent runtime environment will remove barriers for delivering
content and applications across screens. A more open and universal
runtime across devices will drive rapid innovation that will
ultimately be good for consumers."

At the 2010 Mobile World Congress, Adobe upped the ante by unveiling Air
on mobile devices. In addition, Flash 10.1 supported a wide range of
mobile devices and operating systems through Open Screen Project partners.
However, as of 2012, the Open Screen Project no longer accepted new
applications, and its URL redirected to Adobe’s Flash runtime page.

Beginning of the End

As concerns over Flash’s security posture have increased driven by hacks of unpatched vulnerabilities, the industry has
turned against Flash. In January 2015, YouTube dropped Flash as the default player for its HTML5 video,
and in February 2015, it began automatically converting Flash ads to HTML5. Beginning in June 2016, advertisers will no
longer be able to upload display ads built in Flash to AdWords or DoubleClick Digital Marketing services.
On January 2, 2017, display ads in the Flash format will not run on the Google Display Network or through DoubleClick.
For the time being, video ads will be unaffected.

And in August 2015, the Interactive Advertising Bureau (IAB) drove another nail into Flash’s coffin by updating its
“IAB Display Creative Guidelines” to encourage marketers to move from Flash to HTML5

In an attempt to mitigate the security issues, both Microsoft and Google
have distributed patches for Flash, and Adobe has increased the cadence of its
updates. However, given declining industry support, it seems clear that Flash
is doomed. Although Adobe’s roadmap for the product indicates that there will
be further development, the company has abandoned plans for what it calls
"Flash Player Next", and says it will focus development on top of the existing
Flash Player architecture and virtual machine, shifting to continue its
next-generation development "as part of the larger web community doing such
work on web-based virtual machines."

Usability Issues Emerging as Business Process Concern

A discussion blossomed examining the concept of fiduciary responsibility for
Web designers. The theory runs along these lines: Armed with extremely precise tools for detecting and measuring performance changes, and for correlating these changes to interface design, IT auditors are now able to hold
Web architects accountable for design impacts on enterprise site performance. The incentives are clear. If an enterprise is solely or mostly
Internet based, then the quality of its
Web presence has a material effect on business results. In the event of a competitive downturn that clearly links poor
Web interface usability to a decline in revenues, Web developers could be liable for damages.

While this is currently a stretch, it unquestionably hints at a time in the not-too-distant future when developers could be assigned liability for software disasters that proceed from violation of broadly accepted "best practices." A few examples of practices which demonstrably reduce usability,
and thus should be avoided, include:

  • Hidden Navigation – Interface design, color schemes, or graphics
    that obscure methods of navigation; perverse use of common navigational elements.
  • Absence of Back Button – The back button is the most widely used of all browser controls. It should always be present and always behave in the standard fashion.
  • Visually Indistinguishable Interface Elements – Excessively small fonts, lack of white space, monochromatic color schemes and failure to use recognizable elements for standard controls dramatically reduce the viewer’s motivation to interact with content.

Recommendations

[return to top of this report]

It would be wise to consider moving away from Flash sooner rather than later. This will, of course,
involve additional new tools and training for developers, but given the migration away from Flash by mobile advertising, the move is not an option
for marketers in particular.

For those who still plan some Flash development, consider these guidelines.

Test Performance in a Variety of Runtime Environments Before Deployment

Flash has broad appeal to both designers and marketing professionals for its aesthetic impact and ease of use. With modest training, a creative professional can accomplish things with Flash that normally require a more costly and risky software development. This ease of use cuts both ways, however, because beautiful interface design doesn’t necessarily result in effective or efficient
Web page design. The most widely voiced criticism of Flash is that its designer population tends to a form-over-function bias, sometimes resulting in sites of impressive appearance which are not easily used.

This is clearly a circumstance in which competent design leadership and adherence to best practices for a given genre will forestall many problems. Aggressive performance monitoring can provide early warning when content is overdesigned or ambiguously structured. One thing seems clear, however: With a device presence of over 90
percent, Flash content is one of the best ways to optimize the reach of your message.

Be Ready for the Challenges of Mobile Devices

Flash content development culture has a distinct bias toward aesthetics,
creativity, and originality. Much of what fuels the visual impact of a
best-of-breed desktop/laptop Flash app, however, is going to be absent or at
least very limited on small devices. High resolution images, high quality audio,
fast action video, photo realistic colors, and animations using sophisticated
techniques like color gradient fills and vector rendering all make demands that
are out of reach for small, battery powered devices. This is an important
consideration for content producers, for three reasons:

First, developers and designers will need significant training to learn how to best utilize small devices like smartphones,
tablets, and notebooks. Developing an understanding of what is necessary to make an application or content element a
"good citizen" on a power and resource constrained platform is key to success and will largely be counterintuitive for professionals
who developed skillsets in a desktop or
Web environment.

Second, content owners and publishers are likely to expect that existing material should port directly and easily to small devices like
notebooks or tablets because they run familiar operating systems. Unfortunately, this will rarely be the case. Very small screens require a much flatter navigation hierarchy than typical desktop or browser based applications. Media like sound, video, images and animation can’t simply be scaled to a new screen size.
Considerable refinement and editing will typically be necessary to repurpose content for small devices. Make sure to plan for these challenges when creating timelines and budgets.

Third, and possibly most important, Google has announced that it is giving
priority in search rankings to mobile-friendly sites. This means that
inattention to mobility will affect a company’s entire Web presence.

Since Adobe does not support Flash on mobile devices, developers
need to become acquainted with the company’s newer tools: Adobe
Animate CC, which is integrated with CreateJS (formerly codenamed "Wallaby"),
a tool for converting Flash to HTML5 for use by Webkit
browsers, and Adobe Edge, which lets designers use HTML5, CSS3, and Javascript
to create animated content for the Web (as of November 2015, Edge is no longer under
development, although customers subscribing to Creative Cloud All Apps can download and use it).
To use Flash-like output across all
platforms, these additional technologies are now a necessity.

[return to top of this report]

About the Author

[return to top of this report]

Lynn Greiner is Vice President,
Technical Services for a division of a multi-national corporation, and also
an award-winning computer industry journalist. She is a member of Faulkner’s
Advisory Panel.

[return to top of this report]