Selecting Technologies

[ LiB ]

The tremendous variety of new technologies related to Flash apps are very exciting. To keep current, you have to casually study everything but nothing in depth until you're ready to use it. The reason not to study everything in depth is that you'd never finish (or by the time you did, the technology would be supplanted). This section looks at ways to approach the current state of the art as well as how to keep an eye on the future.

When analyzing a new tool or technology, it's important to think about positioning. That is, how would it fit into your project? How could it have helped you in a past project? Or, perhaps, how would someone using it actually use it. Consider the new CSS style sheet support in Macromedia Flash MX 2004, for instance. I can sum up that feature in two words: text formatting. The point is that although the description doesn't really do it justice , it's enough for now. It's sort of like you want to pigeonhole the technology and move on. Then, if later a need arises, you should be able to remember the appropriate technology. Ideally the order is that you first have a need, and then select a tool. However, you won't really know what tools are available unless they're familiar.

It's easy to fall into the trap of designing a project around the available tools. Although Flash MX 2004 includes a "loading" progress bar component, for instance, please don't add some huge media file just to use it. That's backward. It's fine to say I want this huge media file (for whatever justifiable reason) and then recall a new progress bar is available. That is, instead of grabbing a hammer and looking for a nail, it's fine to recall hammers are available if you happen to come across a nail. I already mentioned the issue of justifying every piece of media, and that advice applies here, too.

The following three sections cover the state of the art in an attempt to pigeonhole everything. Don't worry if the descriptions seem terse; the next chapterChapter 3, "Technology Overview"is dedicated to getting into the details of the technologies covered in this book. Right now, however, the focus is on placement.

Tools

The Flash family needs a minivan. It's not just "Macromedia Flash" anymore. There's Flash MX 2004, Flash MX 2004 Professional, Flash Remoting, Flash Communication Server, and Macromedia Central. Then there's Breeze and even Breeze Live. And that's just the Flash family. Check it out. The following table lays it all out, albeit with few details.

Flash MX 2004	The upgrade to Flash MX. It's the tool used to create Flash animations and applications. (Lots of great additions over Flash MX.)
Flash MX 2004 Professional	The same as Flash 2004 except additional features, including external Flash Video creation, the project panel for workgroups, a standalone script editor, additional data integration components , and screens (forms/slides) that basically enable you to author without the timeline visible.
Flash Remoting	A way to send data to and from application servers over an optimized binary protocol called AMF (Action Message Format). In addition, data is automatically parsed so that, for example, database queries arrive as a Flash object. (Flash, by itself, can exchange HTTP data and Flash Pro can handle the SOAP format.)
Flash Communication Server	A standalone server to which your Flash-created SWFs can make persistent connections (allowing real-time interaction with others) that are optimized to both record and transmit live or recorded audio/video streams. Probably Macromedia's coolest product ever.
Macromedia Central	Almost like a replacement to the browser but designed to only display Flash movies and web data. Features unavailable in browsers include special on/offline features for occasionally connected users, support for collaborative data sharing (between different apps), and direct support for outside web services. Depending on how many people jump on this, it may become Macromedia's coolest product ever.
Breeze	Both a tool and a service. The tool converts a Microsoft PowerPoint presentation into a Flash movie and enables you to add audio and chapter delineations. Users can watch your Breeze presentation online (on a hosted or dedicated server). Additional navigation tools enable users to pause, play, and jump to different chapters in the presentation.
Breeze Live	A turnkey application built with Flash Communication Server to enable rich online meetings. It's a very well-thought-out application with tons of useful features. If nothing else, it proves what's possible with Flash Communication Server.
Dreamweaver	A text editor. Sounds funny , but that's all it produces! Granted, there are a million related features that make editing, previewing, and deploying powerful web pages easier.
Fireworks	A raster graphics editor. Although Fireworks uses a native format of PNG (to include additional data such as layers ), it can export any common raster graphic, including JPG, GIF, and BMP. In addition, it has lots of web-centric tools, such as JavaScript rollovers, and features to integrate well with other Macromedia products. (It competes with Adobe Photoshop, although they're different tools.)
Freehand	A vector graphics program. Freehand has its roots in print, where it directly competes with Adobe Illustrator. Although Flash will import graphics from either tool, it's usually better to re-create the artwork in Flash. This can be an extra investment of time but can also reduce file size.
Application Server (including ColdFusion)	A web server (configured and connected so that people can browse to it) that delivers customized pages based on a programming language. Instead of creating static pages by hand, an application server can dynamically create pages on-the-fly .
JavaScript	A client-side scripting language because it interacts with the user 's browser. JavaScript is appropriate for triggering pop-up windows and a couple other tasks that Flash can't do on its own. The good news is JavaScript is nearly identical to Flash's ActionScript.
Java	Basically, just a programming language. When it runs on the client side, it's unduly complex, intrusive , andfranklyno better than Flash. When running on an application server, however, it can be transparent to the user and as powerful as the programmer makes it. Like ColdFusion, it can process client requests and then return customized pages on-the-fly. Any backend technology (including Java) can include Flash on the front end. (Backend being the web server, and front end being the user's browser.)

It turns out this table mainly covers stuff considered in this book. (Well, we won't really get into Java and the backend stuffonly how Flash ties in.) Obviously, other solutions compete with Flash. Nothing is truly equivalent, however, so just understand what Flash can do and you'll be able to appropriately compare.

Media Formats

Assuming you've rationalized all the costs of adding a particular media element (as discussed earlier), you still have to make a decision as to exactly what format to use. The decision you make affects your production approach, the deployment mechanism, andmost importantlythe user experience. The following three tables cover considerations when making a media selection for graphics, video, and audio, respectively.

Raster Graphics

Generally, these are appropriate when the nature of the image cannot be drawn using vector tools (like in Flash); for example, product images or photographs. On the same note, they tend to be larger than vector graphics, so only use them when appropriate.

Graphics Format	Production Concerns	Delivery Concerns	User Experience
GIF, PCT, BMG, PNG	Use library properties to compress during export (JPG) or leave lossless (PNG/GIF).	File size is inversely proportional to quality.	Only PNG supports transparency.
JPG (imported)	Select Library Properties, use imported data, or you'll recompress.	File size is inversely proportional to quality (but JPG is usually the most efficient).	Effective compression for continuous-tone images.
JPG (external)	Can't view until you test. FLAs remain small, and you can replace images any time without using Flash.	Modularity means the download is distributed over time.	Timely downloads mean delays are spread out, although forcing a long initial download is sometimes desirable.

Audio

Music and sound effects can add a dimension of realism ( especially when subtle). Sound also tends to trigger emotional responses. Start with the highest quality possible and don't fall for the fallacy that lower quality is acceptable for voice. If the content is naturally occurring (like a human voice), users have a clear idea how it should sound, so they'll more likely notice when it sounds bad. In any case, there's only one tool to judge audio quality: your ear.

Audio Production	Delivery User	Format Concerns	Concerns Experience
WAV, AIF	No significant differences; however, you should always import the highest quality possible and let Flash do the compression.	Only use the Library property Raw for high-quality desktop applications; otherwise , use MP3 or voice based on experimentation.	Only timeline sounds will be progressively downloaded. (A sound object requires everything to be downloaded first.)
MP3 (imported)	Ideally the MP3 compression is done effectively, because you don't want to recompress in Flash.	Like JPG, be sure to always use imported MP3 quality (instead of recompressing).	Only timeline sounds will be progressively downloaded. (A sound object requires everything to be downloaded first.)
MP3 (external)	Nice because your FLA files remain small and you can swap out audio files later.	The loadSound() option for stream means sounds will progressively download.	Even better than external JPGs; you can hear a sound while it downloads.
MP3 (streamed)	Requires Flash Communication Server for both testing and delivery.	Can't distribute as standalone app unless you're sure of the Internet connection (and you open your server to outside connections).	Even better than regular MP3 streaming because it's true streaming (not just progressive), meaning you can seek and experience much better performance.
MIDI (external)	Requires a proxy sound because you won't hear the real MIDI until you deliver.	Only works on handheld devices such as PocketPC.	MIDI is tiny, but PocketPCs may not fit in your pocket protector.

Video

There's nothing like video. When you want to demonstrate how an expert performs a task, only video will do. Also, live video interaction is unique. Do ask yourself, however, whether the content really warrants videobecause not only does it mean more bandwidth, but also more constant attention from the user.

Video Format	Production Concerns	Delivery Concerns	User Experience
MOV, AVI, MPG (imported)	Besides occasional compatibility issues, pretty straightforward.	Files are large, so you might consider importing into separate files to become SWFs you load via loadMovie() .	Quality isn't quite as good as FLV and can only progressively download.
FLV (imported)	Requires you to produce the FLV outside Flash, meaning that you need a third-party tool as well as the video encoder that ships with Flash Pro or, for the best quality, use Sorenson Squeeze. In fact, you can record local streams from your webcam to make FLVs using the free production version of Flash Communication Server, but this isn't appropriate for content such as movies.	Same as imported MOV, AVI, MPG.	Can expect better quality.
FLV (streamed)	Requires you to produce the FLV outside Flash (either with a third-party tool or Flash Communication Server).	Must be streamed from Flash Communication Server.	More important than quality (which can be great); you can truly stream the video (as opposed to progressively download).

Chapters 9, "Advanced Communication Server," and 10, "Production Techniques," cover the Flash Communication Server (which is the only way to stream media into Flash). Notice that the preceding discussion didn't include general media elements such as animation or text. Countless books have been written about how to employ thesehere the focus is on the "rich media."

Deployment

It is impossible to discuss the topic of media selection without mentioning deployment. Depending on how you're planning to delivery your project, certain issues may become more or less important. If you're delivering on a CD-ROM, for instance, you probably don't care so much whether a video is 100MB. On the web, however, that would take upward of an hour to download even on the fastest connections.

This section briefly covers the common delivery options. Although this book doesn't cover all of these topics in detail, you definitely want to think about where you're headed as you design your app. For example, I had a client who wanted to convert a 50MB CD-ROM project to run on the web. It wasn't impossible, but my task would certainly have been easier had I known this objective early on.

In an ideal world, the deployment stage can be equivalent to licking an envelope and stamping it. That is, a well-planned and well-built app can be quickly converted from the production and testing format to the final delivery format. It should be a painless process.

Here is a series of questions regarding deployment that can help you both design an application and help you see options not previously considered.

Will the App Be Run in the Browser or as a Standalone Projector?

If in a browser. . .

What version of Flash will you require?

What window size do you plan to use (and required user screen resolution), or do you want your app to be resizable?

If standalone. . .

Do you want it to work on both Mac and Windows?

What platform-specific features do you plan to use (for example, printing, writing preferences, copying files, and standard dialog boxes are all unique to the operating system)?

Will it have connected features? (That is, does it require an Internet connection?)

Will the connection need to be persistent, or will you only need to connect periodically (say, to download updates)?

These are just the sorts of questions you can ask as you design your app. You can ask more. And it's not like you're being pushy; after all, they have to be answered eventually. When asked something such as whether they want it to work on Mac or Windows, most clients answer "both." That's fine, but no matter how you answer, it will affect your design and production plan.

The preceding questions aren't really loadedthere's no right answer. For any question that's a "yes," however, consider the addition suggestions in the following sections.

Building for the Browser

If your app isn't restricted to the browser, you're given more privileges to make changes to the user's computer. Although this means a malicious developer could do harm (making a wary user less likely to run it), it usually just means you're given more latitude to do things, such as display data downloaded from any web site. In a browser, Flash can only tap into data residing on the same domain. Additional restrictions are lifted when you deploy a standalone projector. One big disadvantage of standalone apps, however, is that the user must download the EXE. (You'll learn how Macromedia Central solves this issue later in this chapter.)

An in-browser application can either pop up to a preset size (via the JavaScript window.open() command) or just reside in whatever-size window the user's browser is set to. When popping up, you have the option to prevent the user from resizing (by setting Resize to ). What this all comes down to is the question of screen size. When laying out your application, it's easiest to just pick a screen size and stick with it ( carefully considering what screen size your users can accommodate). I recommend against making a Flash app that's taller than the HTML page, one that requires the user to scroll to view all the content (see Figure 2.1). Instead, if you need more vertical space, create a scrolling mechanism inside Flash. Incidentally, you can only ensure no scrollbars appear if you're doing a pop-up window (and you don't pop open a window taller than the user's screen height).

Figure 2.1. If you make your app taller than the HTML window, users may not know to scroll down for more content.

Note

Pop-Up Script

For your referenceor in case JavaScript isn't your bailiwickhere's script you can use in one HTML file (say the home page of your site) that can pop open a fixed-size window in the center of the minimum screen resolution of 800x600:

 1 <html><head><title>your title</title> 2 <script language="javascript"> 3 <!-- 4 function launch(){ 5 if(screen.height>=600){ 6 popup(450,550,"app.html"); 7 }else{ 8 alert("You need to be running 800x600 or greater."); 9 } 10 } 11 function popup(width, height, filename){ 12 var left = (screen.width - width) / 2; 13 var top = (screen.height - height) / 2; 14 var attributes= "left=" + left + 15 ", top=" + top + 16 ", width=" + width + 17 ", height=" + height +","; 18 attributes+="toolbar=0,location=0,directories=0,"; 19 attributes+="status=0,menubar=0,scrollbars=0,"; 20 attributes+="resizable=0"; 21 window.open(filename,"appwindow",attributes); 22 } 23 //--> 24 </script> 25 </head> 26 <body> 27 <a href="#" onClick="launch()"> launch </a> 28 </body></html> 

The idea is your main app is app.html , but first you want to check whether users are running 800x600 or greater (line 5). Then, you just figure out the center of the screen and pop open a window (line 21) with nearly every attribute set to 0 (lines 1420). The trigger is a hyperlink on line 25. This code is just a start; you can modify it for additional features.

By the way, you also can let your Flash app open other windows directly. Just include the popup() function in the JavaScript portion of the file that houses your Flash app (say, app.html). Then, inside your Flash movie use a variation of this code:

 getURL("javascript:popup('300', '300', 'somefile.html')"); 

Finally, it's possible to let the user resize the screen and make your adapt on-the-fly. I'm not talking about having Flash scale, because that makes small text illegible (although letting it scale is easier than what I show next). Basically, there's an event triggered called onResize() , and you just write code to respond accordingly . The idea is easy: When the user resizes, your code rearranges things onscreen. Doing it well can be quite involved, depending on what you are displaying. Here's a quick example: Suppose that when the user resizes the browser, you want your content to remain at 100 percent except for four graphic borders that should always fill the browser (as shown in Figure 2.2).

Figure 2.2. Trapping onResize() means your app can change layouts as the user resizes the browser.

First, you need to use the No Scale setting either in your HTML Publish settings or with this line of code:

 Stage.scaleMode="noScale"; 

Then you set up a listener, as follows :

 myListener = new Object(); myListener.onResize = reDisplay; Stage.addListener(myListener); 

My reDisplay() function is defined here. Notice that I use Stage.height and Stage.width to display the borders. (Stage properties are only accurate when you are using noScale .)

 startWidth=400; startHeight=400; function reDisplay(){ left_mc._height=Stage.height; left_mc._x=(startWidth-Stage.width)/2; right_mc._height=Stage.height; right_mc._x=(startWidth+Stage.width)/2; top_mc._width=Stage.width; top_mc._y=(startHeight-Stage.height)/2; bottom_mc._width=Stage.width; bottom_mc._y=(startHeight+Stage.height)/2; } 

The two keys to redisplaying your screen are setting up a listener that knows when the user resizes and accessing the Stage.width and Stage.height properties to ascertain the new size. With this information, you can do complex rearranging such as having a button bar that adapts to the width or even changes from vertical to horizontal as appropriate.

Distributing Standalone Applications

If you think you've got a lot of deployment questions to answer when building for the browser, you're right! In many ways, standalone applications are easier because you rarely worry about file size or browser incompatibility . However, the mere number of options available is a bit overwhelming. You know every EXE ever built? Well, you can pretty much do anything they can. This discussion covers the options in a general manner, instead of taking a detailed look at every possibility.

The basic way to distribute an application as a projector is just to embed the Flash Player into your SWF. It's done automatically from an option in the Publish settings. The only funky part is that creating a Mac projector on Windows compresses it as BinHex (HQX), whereas making a Windows projector from Mac zips (ZIP) it. This makes file transfers to and from the different operating systems possiblealthough you'll want to uncompress it on the target platform for final delivery.

The two significant "extra" features you can include when distributing a Flash projector are the ability to go full screen and a quit feature (not applicable in the browser). To make your app go full screen, just use this code:

 fscommand("fullscreen", true); 

This is great if you build a presentation in Flash, because it hides the desktop and taskbar. In addition, if you want it to go full screen but not to scale (that is, just mask out the desktop), you can add the following command:

 fscommand("allowscale", false); 

If you're not the only one running this app (that is, if you're distributing it), you probably want to include something that executes fscommand("fullscreen", false) , because using the standard "un-full screen" key (pressing Esc) isn't intuitive. Alternatively, you can add a quit button as explained next.

To close your Flash projector, use fscommand("quit") . Obviously, you don't want this to execute in the first frame (wait until the user clicks the quit button instead).

Unfortunately there's not much else a Flash projector can do. However, several third-party companies have produced tools that extend what's possible with Flash projectors. These tools all involve building your app in Flash, but then, at the last stage, you build the projector using their tool. At that time, you can add additional features to your app. They also have ways for you to write ActionScript that taps into even greater capabilities. For example, I built an app that enabled users to download Acrobat files to disk. In my Flash app, users could select PDF files, and then I triggered code that presented the user with a standard Save As dialog box. Then I used still more custom code to copy the files from a CD to the specified location. With these tools, you really do have nearly limitless options available.

I've included a list of tools with which I'm familiar and have had some experience using. These are probably the most popular tools. They're all variations on the same idea, although each has its respective advantages.

• SWF Studio ( www.northcode.com). The first in this field, SWF Studio just recently released the only Mac projector tool of its kind, called flashthing. Also, Northcode provides prompt email support.

• Screenweaver ( www.screenweaver.com). If nothing else, the Screenweaver app itself is a model RIAbuilt in Flash! It really is impressive. Of course, it also has hundreds of script triggers available and some really fancy support for nonsquare or transparent applications.

• Flash Studio Pro ( www.multidmedia.com). Similar to these other tools, except its price for personal usage is very good: free.

This book would probably spin out of control if I were to attempt to document these and the countless other third-party tools. For example, I haven't mentioned there are many tools for turning your Flash animations into screen savers. You can also find several obfuscation tools that turn your completed code into spaghetti so that others can't make sense of it if they attempt to hack into it. Finally, I also didn't mention perhaps the best projector maker with optimized performance and a complete programming language of its own: Macromedia Director MX! I guess the main point I wanted to make is that there are lots of options out there. And, RIAs definitely include desktop apps with greater richness and feature sets than in-browser apps.

If standalone apps are so great, why don't we just go study those? Mainly because of distribution. First you have to get the user to download your EXE and trust you enough to install it. Then you have to invest an effort to ensure users are using the most up-to-date revision of your product. This isn't impossible, but more traditional web apps (and Flash RIAs) avoid most of these challenges. There is one tool that blurs the delineation I've spent the last section defining, and that's Macromedia Central.

[ LiB ]