PROBLEMS IN DEVELOPING ANIMATION FOR TV BROWSERS


Now that the cartoon is resized, it's crucial to check for any serious problems with viewing it through a TV browser. The main areas to check for in developing animation in Flash for TV browsers are playback, line, color, and bandwidth issues. The easiest way to do this is to review the animation on a TV browser emulator for the computer, such as the MSN TV browser. It's even better to view it directly on the target device, but this is often impossible.

Playback

"The Prague Years" was created for playback on handheld devices so all the action is shown as large as possible. Unfortunately, this means that a lot of the animation doesn't play back well on televisions when displayed full screen. In the Web TV browser even a simple walk cycle against a static background is very jerky and halts from moment to moment at full screen (see Figure 11.19).

Figure 11.19. Full-screen Flash animation through a set top box doesn't play back quickly enough.

graphics/11fig19.gif

To fix this the animation needs to be resized or the scene needs to be restaged. The easier of the two is to resize the animation (see Figure 11.20). Follow the steps described previously to make all graphic elements in the scene smaller. This may require that the background gets filled in around the edges, but this is generally preferable to completely reanimating a scene.

Figure 11.20. The walk cycle plays back at a faster speed when it's made smaller.

graphics/11fig20.gif

Lines

The lines around the characters in "The Prague Years" are hairlines (see Figure 11.21). Hairlines were originally used because of the reduced size of the handheld display and the way Flash resizes lines in symbols (line widths scale differently when symbols are resized). Unfortunately, using hairlines makes the lines fuzzy when playing back on television.

Figure 11.21. All the lines in "The Prague Years" are hairlines.

graphics/11fig21.gif

There are a number of solutions to this. The easiest is to live with a bit of flicker and say that television viewers are used to bad display. Although possible, it's unlikely the average viewer will enjoy poorly displayed animation.

The more time-consuming solution is to redo all the lines at a higher pixel width over 2 pixels (see Figure 11.22). This line width resizing is an option that should be experimented with because it may or may not help the animation in question.

Figure 11.22. Lines larger than 2 pixels should look better on TV.

graphics/11fig22.gif

To get around the line-scaling problem, on resize it's possible to turn all the lines into paint fills. Select any line and then choose Modify, Shape, Convert Lines to Fills to make the line into a graphic fill. Unfortunately, this might significantly slow down the animation because using paint fills takes up more of the processor.

Color

After reviewing the cartoon in the MSN TV browser emulator, it's obvious that there are serious problems with colors in the cartoon. The color palette of the cartoon is, in general, much too bright for television. Using the television color safe palette discussed earlier in this chapter, it's important to go through the cartoon and tone down the colors to display properly on television.

There are a variety of solutions to this problem. It's possible to take all the RGB values of the colors in the Flash movie and create a color palette in Photoshop. Run the NTSC Colors filter on this palette and then transfer the new RGB values back to the colors in the Flash movie. It's quicker to take the RGB values and check the safety of the color in a tool like the one online at MSN TV (currently http://developer.msntv.com/tools/colorpick/Default.htm). This tool also contains a web-safe color palette that can be clicked on to determine the closest TV safe color. If the colors aren't TV safe, but still view reasonably on many different television screens, then it's possible to skip this step.

There can be problems with trying to get colors safe for television quickly. As an example, in certain instances throughout "The Prague Years," symbols with tint effects are shown as the wrong color on some television screens (see Figure 11.23). This is extremely distracting as symbols used to build the characters move between different shades throughout the cartoon. In this case it would have been better to develop the cartoon without using tint on symbols.

Figure 11.23. Symbols with tint effects might display with the wrong color values when shown with "TV safe" colors by the browser.

graphics/11fig23.gif

In "The Prague Years" this happens most often when the patch symbols are tinted using the Tint effect. The patches match other symbols when there is no Brightness change, but when the other symbols' color values have been changed with Brightness and the patch has the Tint effect to match this, the color values don't seem to match on a TV display. They match perfectly on a computer monitor, but the color shifting that occurs on a television display makes them a real problem.

The simplest solution to this problem is to create a new set of character patches for each main color in the cartoon's color palette (see Figure 11.24). These patches can then use the Brightness effect rather than the Tint effect to match color values (see Figure 11.25). Although this adds to file size in the Flash movie, it does fix the color problem.

Figure 11.24. Create new color patches for the colors used in the cartoon's color palette.

graphics/11fig24.gif

Figure 11.25. Use Brightness to match these color patches to the underlying symbol colors.

graphics/11fig25.gif

Bandwidth

"The Prague Years" was created for narrowband devices with small built-in memories, so file size is not an issue. If the target audience has broadband, then the cartoon could be significantly improved by outputting audio at a higher quality and adding more music or sound effects to the cartoon.

As can be seen, there's quite a bit of work that goes into redoing a simple file for proper display and playback on television. It's often much easier to create the simplified version for television first or create it in parallel to a more robust version for the web.

There are no hard-and-fast rules for creating great animation for playback on television displays through a TV browser. It takes a lot of trial and error to get the right combination of line, color, and animation that will play back well on these devices.

The optimal situation is to create a style of character and animation that is suited to display on TV browsers. Styles that work well are paper cut outs as in Blue's Clues, limited animation as in Japanese anime, and any other simple form of animation. There's certainly no chance to create feature film quality lifelike character animation in Flash for this platform.

Because it's fairly certain that the animation won't be the best part of the production because of all these playback issues, be sure that the story, writing, dialogue, and sound are fantastic. Great animation can't carry a bad story, but a great story can survive mediocre animation.

Interfaces for TV Browsers

Flash can easily create full rich media web sites for interactive television. Rather than clunky HTML page refreshes (page "blinks") when a user selects a navigation option, a more seamless, media-like experience can be created.

A hypothetical Flash site navigation will show tricks to developing for tab-based input devices such as remote controls or keyboards. In the example presented here, a company wants to create a web site about living on islands. The site needs to be accessible to TV viewers using a remote control. It's a straightforward site with only six main categories of navigation with several subcategories under some of them.

The standard way to create this navigation in a Flash web site would be to provide navigation at the left or along the top and then use drop-down menus or menus that pop out to the right of the main buttons. To investigate tab order, we'll place the navigation on the left.

The first step is to create a standard button that TV viewers will recognize as a button (see Figure 11.26). Standard TV browser navigation is not the place to win sophisticated art director design awards. Interface navigation design needs to be relatively large, cleanly designed, and easy to navigate. TV viewers are probably not used to highly designed navigation and will gravitate toward the simplest, easiest experience. In this case, a bevel edge signifies that the button is a button.

Figure 11.26. Viewers should recognize that a button is a button.

graphics/11fig26.gif

After the standard look and feel of the button is created, it's time to place the six buttons of the primary navigation on the left side of the screen. The first layout has the navigation bottom justified to the screen. This can be a problem in television displays because the TV browser might take up part of the screen and cut off the bottom button. Although it's possible to scroll down to what's cut off, it's better to design so that no scrolling is needed.

In testing with the MSN TV browser, the bottom button is cut off so the buttons need to be moved up the screen. It's important to begin designing a web site for TV browser display with an understanding of how much space the browser will take up in the screen.

After the buttons have been moved up so that they're all viewable (see Figure 11.27), it's time to test how easy it is to move around the buttons with the remote. In this case the buttons are so simple that the up and down remote buttons will move through the buttons properly as will the left and right remote buttons.

Figure 11.27. Main navigation should always be immediately viewable by the television audience.

graphics/11fig27.gif

The next step with the navigation is to add a rollover-type effect to open second tier navigation (see Figure 11.28). Unfortunately, the rollover action with buttons doesn't normally work for television because the remote doesn't work like a mouse.

Figure 11.28. Using rollover navigation is a standard interactive navigation practice.

graphics/11fig28.gif

To create a rollover effect, the button action must be changed to on press to make the second tier navigation pop out (see Figure 11.29). Rollout can't be used to close the second tier navigation so a more complex system of ActionScript must be created to track which button a user has activated and then provide an action depending on the next button a user moves to. Creating navigation for use by a remote control on a TV browser is definitely more difficult than creating navigation for a computer with a mouse.

Figure 11.29. The viewer can easily jump from the second tier navigation to the main navigation by mistake, sometimes missing buttons in the process.

graphics/11fig29.gif

Now the main problem with the navigation begins the tab order is odd because of the second tier navigation. Flash moves around buttons and form elements based on the centerpoint of the symbol. Even though the centerpoints on all the buttons are the same so the order of the buttons is consistent and logical, it's still really easy to accidentally jump between the secondary navigation and the primary navigation by mistake (see Figure 11.29). It's not clear to the viewer when this will happen and why it happens because the viewer does not understand Flash tab order problems. To the viewer, it just doesn't work properly.

One solution would be to send all the primary navigation buttons, except the button with the open secondary navigation, to a non-button state in a movie clip. This would then mean that the viewer would have to go back to the original primary navigation button before moving on in the navigation. It would take some ActionScript to manage a complex navigation system, but it would work. It may not be the most intuitive navigation system for viewers so it's best to test this on any particular project.

After the secondary navigation is open, quite a lot of code needs to be written to track and then close the secondary navigation. Because there is no rollover state with most remote controls, it's impossible to know what specific parts of the navigation to close or not to close by simply using an invisible button (as would normally be the case in a Flash 4 movie). Instead, the whereabouts of the tab focus must be tracked at all times programmatically in Flash 4 syntax. This isn't a fun process to develop for in the more limited programming range of Flash 4.

There really isn't a great solution to the problems with this kind of standard interactive navigation design other than keeping navigation structures as simple as possible. Drop-down menus have fewer tab order problems than left side navigation so they might be a preferable starting point for layout.

The next part of the example file is the addition of a form element (see Figure 11.30). This form element messes up the left side navigation even worse. If the secondary navigation is open, it causes the remote to miss several of the main navigation buttons. It's then difficult to move around the interface to get to those buttons. This is because the centerpoint of the form element is at a different coordinate value than the buttons and takes over access to some of the buttons.

Figure 11.30. Form elements can quickly throw off tab navigation.

graphics/11fig30.gif

The easiest solution at this point is probably to redesign the entire site interface so that these tabbing issues don't exist, whether that means shifting to fewer navigation elements or reordering on the page. If that's not possible, then a good way to handle this is to go to a brand new page inside the Flash movie for form input. On the new page, the number of elements can be lowered so the tab order can be more easily controlled. When the user finishes the form or cancels the form input, the user is sent back to the main navigation. With television interfaces, less is much, much more.

Navigation keys don't use frames. However, they keep centerpoints for buttons in a consistent place, turn form elements into symbols and keep their centerpoints in a consistent place, and lay out the elements of the interface and test navigation before creating the whole site.



Macromedia Flash Enabled. Flash Design and Development for Devices
Macromedia Flash Enabled. Flash Design and Development for Devices
ISBN: 735711771
EAN: N/A
Year: 2002
Pages: 178

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net