Flash Usability: Sizing Up Text, Part 1
Date: Sep 6, 2002
Imagine this scenario: You go to an automaker's Web site to look up information on your favorite German sports car. The text on the page is slightly hard to read at your screen resolution of 1024 x 768, so you increase the size of the text onscreen by clicking the browser's text-sizing button and selecting Largest.
To your surprise, the text size doesn't change. In fact, nothing changes. The functionality you have come to expect from your browser's text size button has somehow been rendered useless. This may not deter you from reading up on your future car purchase, but this inconsistency in browser behavior can be a shock to some users and can lead to an unhappy experienceall because the designer of this Web site assumed that breaking the text size button in the user's browser was okay with the user. It wasn't.
Don't Break the Browser
In Skip Intro: Macromedia Flash Usability and Interface Design (New Riders, 2002, 0-7357-1178-X), we talk a lot about knowing your users and designing a site that creates the ideal experience for them and helps them accomplish their goals at your specific site. One of the issues with Flash, however (and an easy target for the Flash-bashers out there) is that, although you are using Flash to improve the usability of your Web site, in some cases Flash does the unspeakable: It breaks the browser's basic functionality, such as rendering the Back button and find functions unusable to the unsuspecting visitor.
In the latest version of Flash, MX, Macromedia has fixed the problem of the Back button breaking and introduced an option to turn it on just a few clicks away. You can include this in any of your Flash Web site interfaces. Robert Penner also has a fix for the Back button problem that works in Flash 5. These fixes go a long way toward making Flash interfaces even more usable on the Web. This shows usability gurus that Flash can improve the user experience without sacrificing browser features that we all take for granted when developing in plain old HTML.
Another topic that we cover in depth in Skip Intro is how cutting corners when developing a Flash Web site can (and probably will) lead to unhappy users, unhappy customers, and an unhappy client. In this article, we take you through the details of making that text size button work again in the user's Web browser. This means some extra legwork to implement the fix, but the payoff will be worth it: Users can now expect the same browser functionality on your Flash Web sites as they do on Web sites designed in HTML.
The fix that allows your Web browser's text size (or text zoom) button to work with Flash is what we like to call a "brute force workaround," commonly known as a "nice hack." This is because this fix is not just a few lines of ActionScript or JavaScript; instead, it's ActionScript, JavaScript, Flash, and DHTML all working together. The unfortunate reason why we need to use all these technologies in a brute-force way is surprisingly simple: Not all browsers are the same.
Not the Browser Wars Again!
In the last few years, Web browsers have fortunately been approaching a point at which they are all very close to being standards compliant. Unfortunately, however, there are still vast discrepancies in the way they interpret those standards. Furthermore, some things are not yet standard, such as having a text-sizing button. So, although many browsers support the feature, few of them support it in the same way: In Internet Explorer the user can choose from Largest, Large, Medium, Small, and Smallest. Each of these sizes are about two point sizes apart, with the default setting being Medium, or 12 point. Netscape Navigator, on the other hand, supports different percentage sizes: 100% is 12-point text, 200% is about 29-point text, and the user can choose any arbitrary percentage as well.
What's more, none of the current batch of browsers offers the developer a way to access the size or percentage that the user might have set the browser to. Some might ask why this is an important feature. Well, part of most Web designers' goals is to design Web sites that look as consistent as possible across browsers and platforms. Using standards such as CSS, HTML, and JavaScript, Web developers can ensure that all users are seeing their Web sites in the most usable way. Now, if some of your users have their text size zoomed to 250%, you have no way to design for that: Some browsers will make just the text in a page 250% bigger, while other browsers will scale the entire page, including any images, 250%. Welcome back to the days of not being able to adequately predict what your user might be seeing.
NOTE
Here is our formal vote for standardizing the way text sizing is handled in browsers and providing access to that setting with JavaScript. All browsers should offer the capability to size the text on a Web page by percentages (100%, 150%, 200%). This should not size the images, however. The text size setting should then be made available through JavaScript, perhaps by way of the window object (window.textScale). This will allow developers to design pages that are more flexible and that take advantage of the text-sizing features of the browser to actually enhance the user's experience. For example, if a user of your map site has set the text size to 300%, you could decide to download a higher-resolution image for the map.
Getting back to Flash, because there is no way in any browser to get the text size that the user has set the browser to, Flash Web sites potentially offer frustration to users who use that feature. To prevent that frustration, this article walks you through the process of building a "text size getter."
Working the Workaround
As was mentioned previously, getting the text size in the browser is not a trivial task because it is not offered in any way by the browser. Through some investigation, you'll find that you can trick the browser into giving you that information by using Flash MX's Screen object and being creative with JavaScript.
Internet Explorer, for example, lets you get the dimensions of DIV elements on the screen using the offsetHeight property. If you put text in a DIV, set your text size to Largest, and check the offsetHeight property of that DIV, you will notice that it returns a different height! Netscape Navigator and Mozilla offer similar access to the DIV's height, but through the slightly more complex getComputedStyle() function.
In Opera, JavaScript could not return any new information about the size of the DIV element when the text size was changed. However, Opera actually changes the size of everything on the page, including Flash movies. So if the page was zoomed 200%, the Flash movie dimensions would also be zoomed by that percentage. Using the Flash MX Screen object, you can determine the new size of the Flash movie.
Ultimately, through trial and error, we discovered that JavaScript needs to continuously check to see that the height of the DIV does not change. If it does, the Flash movie is drawn at the specific height of the DIV. The Flash movie uses the Screen object again to get the new height of the movie and sends that value to the main movie using the LocalConnection object. This method works for Internet Explorer 5 and up, Netscape 6 and up, and Mozilla 1 on both Windows and Macs.
For Opera on both Windows machines and Macs, it does not change just the text size, but it also scales the entire page to the specified percent. In this case, the Flash movie does all the work using the Screen object to determine the new percentage that the screen has been zoomed.
With a little more investigation, we were able to put together a list of design guidelines for our text-sizing workaround:
JavaScript must be used to determine whether the text size setting has changed. If it has, this must be communicated to the Flash movie.
JavaScript cannot be used to communicate directly to the Flash movie on the Web page because not all browsers support this communication. (As of the Flash MX release, Internet Explorer on Windows and Netscape 6.0 and above using the new r40 version of the Flash player are the only browsers to handle this, as advertised by Macromedia.)
Initially, a hidden frame was to be used to house the text size getter because it will need to make use of some generic elements on the page (such as a DIV). Unfortunately, because of an optimization to the Flash player (or a bug), if a Flash movie is run in a hidden frame, the Stage object (which is used to determine the height of the DIV on the page) returns null values for its height. So, for the Stage object to return the proper values, the Flash movie needs to be visible onscreenat least 1 pixel of it, anyway. The Flash movie will use the LocalConnection object in Flash MX to communicate to your main Flash movie.
Because actual text point sizes are different across browsers and platforms, the percentage that the text has been scaled rather than a specific text point size is passed to the main Flash movie. This percentage can then be used in the main Flash movie to calculate the point size of text or to scale movie clips and text fields to a new size.
Now that the design guidelines are set, it's time talk about the JavaScript!