Flash Application Design Solutions: The Flash Usability Handbook

.

278

5947CH13.qxd

1/27/06

12:27 PM

Page 279

EMBEDDING FLASH FlashObject also supports easy integration of Flash parameters to your player plug-in, as well as variables to pass into the Flash movie. Adding these requires a minimal amount of code, and the parameters and variables are passed using JavaScript methods, rather than through tag attributes or a query string. The following could be added in between the creation of the FlashObject variable and the call to the write method to add three Flash player parameters and one variable into the embedding movie. fo.addParam("quality", "low"); fo.addParam("wmode", "transparent"); fo.addParam("salign", "t"); fo.addVariable("myVariable", "myValue"); FlashObject also can integrate with Flash Express Install to even further enhance usability by allowing users to update older versions of Flash Player without needing to go to another page. You can find more information about this technique at http://blog. deconcept.com/2005/08/13/using-flash-player-express-install-with-flashobject/. We’ll show you how to use Express Install with FlashObject in the very next section. You’ll notice that the HTML required for FlashObject is minimal, and better yet, you can use it in XHTML code, and it will still validate! Actually embedding the Flash movie is handled entirely within the downloadable JavaScript class, which makes it even easier to manage as future updates of FlashObject are released.

Another embedding method inspired by FlashObject is UFO (Unobtrusive Flash Object) created by Bobby van der Sluis. You can find more information about UFO and download it from www.bobbyvandersluis.com/ufo/.

Using FlashObject with Express Install Let’s see just how easy it is to use FlashObject, along with Macromedia’s new Express Install feature. Begin by downloading Chapter13_Final.zip from the friends of ED website (www.friendsofed.com) and export the files within the ZIP file into a directory on your machine. This example uses the liquid-layout solution from Chapter 12. Our goals here are the following:

13

Embed the SWF file into HTML using FlashObject. Let the SWF file take up the full area of the browser. Implement Express Install to allow Flash Player upgrades (for versions 6.0.65 and later) to be done within the movie. Begin by opening Chapter13_Final.html in the /source/swf/ folder in the browser of your choice. If you happen to have a version of Flash that is older than 8.0.22 (but later than version 6.0.65), you should see an alert box pop up inside the movie (similar to the one shown earlier in Figure 13-1), asking permission to download the newer version.

279

5947CH13.qxd

1/27/06

12:27 PM

Page 280

F L A S H A P P L I C AT I O N D E S I G N S O L U T I O N S : T H E F L A S H U S A B I L I T Y H A N D B O O K Because you are running this on your machine locally, you may first be prompted to change your security settings to allow the Macromedia website to interact with the movie on your machine. Either allow access to it or upload and run these pages from a remote web server instead. After you have downloaded the latest version of Flash (or you already have it), you should be taken to the same liquid-layout solution example we dissected in Chapter 12. Now, let’s see what it took to embed the movie. We will not be going through the flashobject.js and ExpressInstall.as files included in this solution, for two reasons. First, we did not have a hand in the development of either of these files and would not want to misrepresent how the original authors created them in any way. Second, you really shouldn’t need to know how they work; the point is to see how easy it is to implement them.

Writing the HTML code Open the Chapter13_Final.html page in a text editor. Here, we start out by setting this page’s DOCTYPE to XHTML 1.0 Strict. One of the benefits of FlashObject is that all the HTML code we need to write will validate as strict XHTML. Then we write the following HTML code. You’ll notice everything looks the same as the HTML code we initially wrote for FlashObject, aside from a few CSS styles we’ve created to allow the Flash movie to expand to the full width and height of the browser. Also, notice that the flashobject.js page has been included in the same folder as this HTML page, which we reference in the <script /> tag. <script type="text/javascript" src="flashobject.js"> <style type="text/css"> html { height: 100%; overflow: hidden; } #flashcontent { height: 100%; } body { height: 100%; margin: 0; padding: 0; background-color: #f60;

280

5947CH13.qxd

1/27/06

12:27 PM

Page 281

EMBEDDING FLASH } <script type="text/javascript"> // Notice that when we create the FlashObject, we now set the width and height properties to 100%, rather than to a fixed pixel width and height. The version we require is Flash 8.0.22 (the latest version available on Macromedia’s website as of this writing). We’ve also set the background to dark gray and set the Express Install Boolean variable to true. By setting the Boolean value to true, the FlashObject instance will do the setup required to test whether the Flash Player version can be updated via Express Install. Next, we’ll show you how simple it is to add the Express Install check to the Flash movie.

Checking for the ExpressInstall component Open the /source/classes/ folder, and you will discover that all the class files here are identical to the ones in Chapter 12 except for a new ExpressInstall.as file. Geoff Stearns has kindly included this as a part of the download package for FlashObject, and we’ve included it in this chapter’s solution. Now, open Chapter12_Final.fla in the /source/fla/ folder. To ensure that the movie stops playing if the Express Install dialog box appears, all you need to do is call a static method in this class on frame 1 of the root timeline of your Flash movie. Because the ExpressInstall class sits inside one of the paths in our movie’s classpath (see Chapter 2), we can just reference the object as follows:

13

if (ExpressInstall.init()) { stop(); } This simple code just tells the current movie to stop if Express Install has started on your machine by returning a Boolean value. You can see that we’ve added this in frame 1 of the root timeline of the movie and then moved the actions and movie clips that were

281

5947CH13.qxd

1/27/06

12:27 PM

Page 282

F L A S H A P P L I C AT I O N D E S I G N S O L U T I O N S : T H E F L A S H U S A B I L I T Y H A N D B O O K originally on frame 1 over to frame 2. It is suggested that you leave frame 1 completely for this task alone to ensure that someone running Flash Player 6.0.65 can view the first frame of the movie, and thus will see the upgrade dialog box. Amazingly, those are all the changes needed to embed our previous chapter’s solution into an HTML page that handles browsers with any (or no) versions of Flash gracefully!

Summary As you’ve seen, you have several alternatives for embedding your Flash application into a web page. The automatically published HTML code coming from your Flash development environment is not the optimal choice. (In all fairness, the others were all developed to enhance the limitations of the default HTML method, so naturally it would be the least capable.) This and the previous ten chapters have covered an assortment of web usability topics and shown you ways to design very usable Flash applications. Our hope is that you’ve gained some new insight and ideas about how to tackle usability given the current capabilities of Flash and ActionScript 2.0. We’ve said that programming is an iterative process that often involves some reconsiderations of code after you’ve built the underlying functionality. This concept applies to usability as well. In a few years, when the Flash version number has hit double digits and the latest enhancements to ActionScript surface, some of the solutions and implementations you’ve seen here may seem fairly outdated. However, we hope that what stays fresh and everlasting is the usability thought process. How you approach application design and development is often just as important as how you implement it. In Part 3, we’ll step away from covering the specifics of building solutions to talk a bit more about the Flash usability thought process, and then show you a full-featured application that harnesses many of the concepts we’ve explored so far!

282

5947CH13.qxd

1/27/06

12:27 PM

Page 283

5947CH14.qxd

1/27/06

12:28 PM

Page 284

PA R T T H R E E P U T T I N G T H E P I E C E S TOGETHER

5947CH14.qxd

1/27/06

12:28 PM

Page 285

14 PLANNING FOR USABILITY

5947CH14.qxd

1/27/06

12:28 PM

Page 286

F L A S H A P P L I C AT I O N D E S I G N S O L U T I O N S : T H E F L A S H U S A B I L I T Y H A N D B O O K In Part 2, we described ways to create viable solutions to common usability problems in Flash. In each chapter, we described a particular issue, designed a solution, and then implemented the solution. What was left out of the equation is how any of these design decisions are made in the first place. In this chapter, we’ll discuss how and where usability fits within the design process. Think of this as a primer for how to organize and prepare for creating a usable Flash application. This chapter will cover how you and your team members should implement a process for usability. Here’s what we’ll cover in this chapter: Your goals for Flash usability The new usability paradigm for rich Internet applications Members of a crack usability team Preparation for the development phase Guidelines for usability testing

Setting the bar for Flash usability Recall our definition of usability in Chapter 1 of this book:

Usability measures how intuitive, efficient, and pleasurable the experience of using a Flash application is, as well as how effective the application is in achieving a user’s end goals.

The goal of any web application is to provide a service to an interested user. The user has come looking for that service, and it’s in your best interest to deliver it by the most efficient means possible. However, as you’ve seen throughout this book, that doesn’t mean you should stop designing with innovation in mind. If innovative design played no part in a consumer’s experience, you would have no outlet to improve existing techniques or methodologies. Think of a world without sports cars or Xboxes; the Model-T Ford and Atari 2600 console would still be doing a dandy job! That’s what we view as the differentiator between rich Internet applications (RIAs) and traditional websites: RIAs provide a richer, more pleasurable online experience than traditional applications, while still being usable for the consumer.

286

5947CH14.qxd

1/27/06

12:28 PM

Page 287

PLANNING FOR USABILITY Conversely, if traditional expectations and predictability had no part in design, it’s possible that the modern day sports car wouldn’t even have a steering wheel, if the designer decided at some point it no longer fit visually with the design of the interior! The point is you should observe certain standards when developing new web applications. For example, a clearly defined navigation menu is essential for the average website. Moreover, using familiar iconography, such as a shopping cart icon or an envelope icon indicating an e-mail contact, enhances usability. Knowing where and when you should feel free to explore and take liberties in design becomes paramount to innovative usability. As they say, there’s no reason to reinvent the wheel, but feel free to make it faster! The solutions you saw in Part 2 try to balance familiarity with innovation. The past few years in Internet development have seen RIAs explode on the scene. These applications have both extended and challenged the bounds of web usability. From the Ford Motor Company’s online car configuration application (www.fordvehicles.com), shown in Figure 14-1, to Google Maps (http://maps.google.com), to more experimental applications like the NewsMap news aggregator (www.marumushi.com/apps/newsmap/ newsmap.cfm), shown in Figure 14-2, the boundaries between innovative design and usable functionality have gotten increasingly fuzzy.

Figure 14-1. The Ford Motor Company’s Flash-based car configuration application allows you to customize and purchase a car online.

14

287

5947CH14.qxd

1/27/06

12:28 PM

Page 288

F L A S H A P P L I C AT I O N D E S I G N S O L U T I O N S : T H E F L A S H U S A B I L I T Y H A N D B O O K

Figure 14-2. An experimental Flash news aggregator correlating the importance of news items to their size

So what can you do to ensure that a user can quickly grasp the use of an application, while at the same time continue to make advancements with the user experience? The answer lies in the phases of planning and discussion that occur before you ever even open Flash and start developing your application. So let’s explore the challenges that Flash and RIAs in general have introduced to the usability world and the new usability standards evolving as we speak.

RIA usability: a new paradigm Since the dawn of the Internet, HTML has been the primary method of delivering web applications. Most web usability methods are naturally based on what we will call the page paradigm. The page paradigm is nothing more than the process of explaining a user’s experience in terms of the pages he must view before accomplishing his task.

288

5947CH14.qxd

1/27/06

12:28 PM

Page 289

PLANNING FOR USABILITY For example, imagine an HTML application that allows you to configure and order a car (an HTML version of Ford’s car configuration application, for example). To accomplish your task, you must first visit the homepage, click through to the models page, select a model, then proceed to the configuration page, where you will be led through a series of subpages to put together the car of your dreams. But as Flash applications and other RIA technologies like Ajax gain popularity, it’s becoming more difficult to describe a user’s workflow in terms of the page views necessary to accomplish a task. It’s far more relevant to describe RIA experiences in terms of interactions and states. We call this the interaction paradigm, a more applicable approach to describing a user’s experience in terms of interactions made to accomplish a task. We don’t mean to imply that the slate has been wiped clean of pages, only that there is a lot more activity that can happen on one page that just doesn’t fit with the old way we thought of web applications. Consider the drag-and-drop solution in Chapter 6 if it were integrated into a real bookstore application. To explain how a user views and orders a book, you would need to describe how the user has interacted with the book thumbnail items and the resulting state changes to the application. For instance, you might say, “Jane drags and releases a book item over the shopping cart, which initiates a change to the state of the cart,” rather than, “Jane clicks on a book item, which leads to the shopping cart page.” Another interaction might be similar but with a very different result: “Jane drags and releases a book item over an empty space, which causes the book item to fade back to its original position and no other state change to occur.” There wouldn’t even be a comparative interaction in a normal HTML application. Another good way to think about RIAs is to compare them to different types of desktop applications. HTML is like a “widget” or “wizard” application—a page-based application providing a limited set of tools and a linear workflow. An RIA, on the other hand, is more like Adobe Photoshop—an application with a complex user interface and many controls to allow for the richer, customizable interactions that certain tasks require. Recognizing the challenges that RIAs have posed to traditional usability and understanding the need to describe their interactions in a different manner, when and how does usability planning happen? Let’s take a peek into what it takes to successfully design for usability and optimize the user experience, beginning with the usability team members.

The usability team members Key players compose a good usability team. Each team member requires not just expertise in the specific tasks related to the job, but also a good understanding of the roles and assignments of the other team members.

14

289

5947CH14.qxd

1/27/06

12:28 PM

Page 290

F L A S H A P P L I C AT I O N D E S I G N S O L U T I O N S : T H E F L A S H U S A B I L I T Y H A N D B O O K Here are the usability team members: Experience planners: These are usually the first ones to get their hands on a project after thorough market analysis, financial expectations, and the like are solidified by the management team. Their primary role is information architecture—determining and organizing all of the use cases of an application into an efficient flow of states and pages. Over the past few years, this job has grown more into an application mastermind who interfaces with clients and addresses their marketing concerns and goals in terms of application experience (thus the title!). They translate their findings into documents (for example, interaction models, wireframes, and application maps), which the visual designers can use to begin to make art and the technical architect can use to begin structuring the application. We discuss these various documents in the following section. Technical architects: These translate the experience planner’s documents into technical objectives (logic diagrams, UML, and so on), so that developers have a road map to guide them through the coding process. They manage the development team and address clients during the development phase. They’re integral in deciding which software platforms will be used to best fit the needs of the application and generally have a broad knowledge of most web technologies. Visual designers: Often divided into art directors and screen designers, visual designers turn the experience objectives into an engaging and intuitive user interface design. Visual designers need to design for each state of an application, while considering the marketing and identity goals of the project. The successful designer will foresee and accommodate certain scenarios unrecognized by the experience planner, and often will work as a production artist with the development team to break out the design into visual assets that can be incorporated into the final application. Flash developers: Before development even starts, Flash developers have their hands full! While architects lead the development from a high level, developers are the ones actually doing the coding. The successful developer shouldn’t just be able to write code, but have the ability to write code that’s scalable and reusable within the application, as well as document it in a manner that other developers can easily understand. Flash developers also often find themselves playing the role of interaction designers. Interaction designers: Somewhere in between the experience planners, visual designers, and Flash developers lies a handyman who ensures that the solution is well designed purely from the viewpoint of the interactions between the user and the application. They often will start where the visual designer leaves off and complete tasks such as state transitions and rollovers. The need for this middleman has grown exponentially over the past few years because planning for RIA development has many more caveats than planning for traditional web applications. Of course, if you’re doing a project by yourself or with just a few people, you may not have the resources to fill all of these positions. It’s a situation you’ve probably been in before. As an independent contractor, you’ll often fill more than one, if not all, of these roles!

290

5947CH14.qxd

1/27/06

12:28 PM

Page 291

PLANNING FOR USABILITY

Preparing for development Whether you’re working as part of a team or taking on the task all by yourself, preparing for development is almost as critical as the development itself. We find that rushing into projects without clearly defined objectives leads to poorer usability. Before you even begin delegating the work (or doing the work yourself), consider the following preparatory steps. Usability thinking plays an integral role in each of them.

Defining the application’s purpose First, you must define the purpose your Flash application serves for its future users. Is it a shopping tool to help a buyer find the best price, or an online help desk for software support? If this definition doesn’t make crystal-clear sense in a couple of sentences, consider refining it by chopping out the extra noise that clutters the perceived goal of the application. Think of this as defining a thesis for your web project. In the end, if a visitor can spend a few moments on the site and state something similar to this thesis, then you’ve succeeded!

Creating an application map When you’ve firmly defined what you will be building, begin creating an application map. This is a chart that lists all of the project’s sections and subsections. This map should be the grounds for you to define your primary navigation items, as well as the secondary, tertiary, and so forth sections. An application that is clearly organized in such “buckets” makes it easier for the user to navigate. This stage also helps you define a budget for the project, by giving you a road map to just how many things will be a part of the application and how long each portion will take to develop. Figure 14-3 shows a generic map for an application. Notice how each major step is documented as a column and how it creates an organized navigational workflow.

14

Figure 14-3. A sample application map with inset

291

5947CH14.qxd

1/27/06

12:28 PM

Page 292

F L A S H A P P L I C AT I O N D E S I G N S O L U T I O N S : T H E F L A S H U S A B I L I T Y H A N D B O O K

Exploring interactions through interaction models When you’ve defined the goals and the different sections of your application, it’s time to explore all of the ways a user will be able to accomplish her goals by sketching out interaction models. An interaction model describes all of the states of an application and what results occur when a user “does something.” Models typically consist of several logic flowcharts showing which routes users may take and what logic leads them down each path. An example of an interaction model is shown in Figure 14-4. In the flowchart, the rectangles represent an application’s state or result of a user decision, and the diamonds indicate a user decision.

Figure 14-4. A sample interaction model for a bookstore application checkout scenario

Designing wireframes for the application states After defining the interaction models, it’s time to get into the real specifics of what sorts of interface elements will be in the application. Based on the application map and interaction models, design a wireframe for each state of the application. Each wireframe defines the elements that need to be present to allow the user to accomplish her goals for that portion of the application. These are the blueprints a visual designer must work from, so all the important elements should be documented thoroughly here. Figure 14-5 shows an example of a wireframe for a hypothetical website.

292

5947CH14.qxd

1/27/06

12:28 PM

Page 293

PLANNING FOR USABILITY

Figure 14-5. A sample wireframe for a hypothetical website

When you have these phases completed, you will automatically be steps ahead of the game. Issues that you may not have foreseen expose themselves before you encounter them during development. Another important process that should begin during the preparation phase and continue throughout development (and beyond!) is usability testing. Let’s take a look at just what this involves.

Usability testing Usability testing is the process of observing and evaluating the ability of a user to accomplish specific tasks with a web application. It’s often the most useful reality check in each phase of a project, as it gives insightful, firsthand evidence of whether things are in good shape or in need of rethinking based on feedback from users.

14

293

5947CH14.qxd

1/27/06

12:28 PM

Page 294

F L A S H A P P L I C AT I O N D E S I G N S O L U T I O N S : T H E F L A S H U S A B I L I T Y H A N D B O O K While a formal usability testing phase performed by usability experts is a great complement to a project, it’s often more feasible (and easier on smaller budgets) to make smaller, more ad hoc tests at specific points in a project to ensure that no major roadblocks pass under the radar.

A fantastic resource for usability testing (and much inspiration for this chapter) is a book called Don’t Make Me Think: A Common Sense Approach to Web Usability (New Riders Press, ISBN: 0-32134-475-8), by a very well-spoken author named Steven Krug. It’s a very insightful primer for web usability in general and offers some smart guidelines for usability testing.

Testing is meant to help your application become more usable, not to be a giant pat on your shoulder. Take criticism as an invitation to make your application more successful. Bear in mind that it’s not yet public. This is your chance to iron out those kinks before the masses notice them.

The phases of usability testing It’s important to test early, and test often, so that your project is always closely aligned to the expectations and desires of the user. Let’s look at the phases of the project where you’ll find it most useful to test with users.

Concept/experience design As you are defining the goals of the application, this is also the time when you should try out the concept on some test subjects. Give them some conceptual text to read describing the application’s purpose. Then devise a series of questions to ask them about the proposed experience. What do they like about it? What’s useful or would be useful in addition to your concept? After all, usability isn’t just about how the application works, but whether it’s a useful one in the first place! You may find that users will come up with ideas that your team hasn’t thought of yet. The concept may trigger users to reference experiences with similar applications and potential pitfalls of your idea. The goal of this test is to refine your statement of purpose and objectives for the application.

Screenshot design Show printed designs of a few major states of the application to your testers once the design is underway. Show them what the application‘s initial state and a few top-level navigation links will look like. Ask them to describe how certain elements on the page make them feel. What is good or bad about the page hierarchy and color schemes? Is the copy readable? Provide them with some tasks that would take place on a screen. Would they be able to guess how these tasks are accomplished?

294

5947CH14.qxd

1/27/06

12:28 PM

Page 295

PLANNING FOR USABILITY The objectives here are to settle on the overall look and feel of the application and decide whether the general interaction design decisions you’ve made are headed in the right direction. Addressing the major problem spots now will save dozens of hours of design changes later.

Prototyping Build a simple prototype of the application—no frills, no whistles. Simple screens with hard-coded data and canned responses for certain tasks will do the trick. The objective here is to have the users follow specific paths in hopes of them reaching a goal. Unless animation is integral to the usability, you can leave out these types of details. The prototyping phase of usability testing will guide further design decisions, as well as give interactive designers a good start. Along with the information you’ve obtained from screenshot design testing, you can now complete the predevelopment documentation phase and begin actually building your application! In theory, a well-executed series of usability testing should provide enough information to complete the application. But, if you’ve ever worked on any complex project, you know bumps in the road will occur along the way. From unforeseen issues with code development to design problems that went under the radar in the prototyping phase, diverging slightly off track from your timeline and end deliverables is all part of the game. That’s why it’s just as important to provide usability testing during and after development, as discussed next.

Beta release This version of the application is close to final and works on most levels with a few known bugs or functional deficiencies. The application should now be about 90 percent programmed and functional, albeit not optimized for public release. The previous three usability tests should have provided you the input necessary to be fairly certain that your application is ready for prime time. Still, some problems may arise, and it’s worth the extra effort of a beta release to be sure that you launch a stable product to the market. Test the beta version of the site with users to see if they can still accomplish the tasks outlined in the previous usability tests.

Public release Launching your application to the public is always a satisfying step in the development process. But, even though the project has launched and hopefully gained some momentum in the public, your job isn’t over yet. Keep an eye on everyone you see using the site, and if the budget allows, do one more complete phase of testing. If your client is happy with the end product, you’ll likely be doing facelifts and new versions of the application in the future, so keep documenting usability issues for that second round of fun!

14

295

5947CH14.qxd

1/27/06

12:28 PM

Page 296

F L A S H A P P L I C AT I O N D E S I G N S O L U T I O N S : T H E F L A S H U S A B I L I T Y H A N D B O O K

Testing materials Getting together a usability testing environment is pretty simple and requires only a few common resources. Of course, you’ll need testing subjects for your tests. For each iteration of the testing you’re planning on doing, we suggest having three or four people test your materials. Whether it’s commenting on color schemes or clicking through your beta release, you’ll need fresh eyes each step of the way. These people will ideally represent the entire spectrum of your target user base. For example, a car configuration application should be tested on users of all driving ages, young and old. A more specific application, say a patient-tracking system in a hospital, should be tested on doctors, nurses, and staff members who are familiar with the process and potential problem areas of tracking the status of patients. Having a computer engineer, or someone unfamiliar with the goals of the application, test the system might lead to feedback that could actually hurt the usability of the application. For more general applications that you typically find on the Web, these test subjects can be friends, family, or a random group of willing participants, as long as they have no prior knowledge or preconceptions of the project. Along with your subjects, here are the ingredients you need for the perfect usability recipe each time you do a round of testing: Documented task scripts: The experience planner should write a document containing detailed lists of tasks that the test users should perform. These tasks will give you a much better understanding of whether your application is satisfying the end goals of your target audience. This document will take different shapes over the different phases of testing, but each item will contain a description of the task, an area to give a grade (alpha-based, A through F) based on the ease of the user to accomplish the task, and plenty of room for comments. Supervisor: The supervisor’s job is to go through the documented tasks with each of the testing subjects. This person should be someone who has no emotional attachment or bias toward the project (despite being on the budget!) and can write detailed notes and comments regarding how the users approached each task. Video camera: The only person in the room with the test subject should be the supervisor. All others will be able to view the usability tests either live or via a recorded session. If you can, set up a video camera facing the monitor so you have a record of how the user interacts with the application. This is helpful not only to document the testing process for later review on other projects, but also to give the rest of your team insight into how a typical user actually reacts when using the application. Office space: Finally, you should have a spare office or space set up with a desk, comfortable chair, computer, and Internet connection. This space should be somewhat quarantined from the surrounding activities of a typical workplace to keep the test subject focused on the task at hand and not distracted by other people in your office.

296

5947CH14.qxd

1/27/06

12:28 PM

Page 297

PLANNING FOR USABILITY

Summary Usability planning is one of the most valuable tools for a project. This is where the important decisions are made regarding what the user experience will be and how it can be finetuned into a veritable racehorse of usability and efficiency. In the real world, you might often find that usability planning is reduced (or even worse, omitted) from a project due to time constraints or unexpected shifts in the functional specifications of an application. When it comes down to it, things first must function before they can function well, and sometimes there’s only time given for things to just function! That’s why we believe it’s critical to plan for usability from the outset of the project. Needless to say, the revising of an application never really ends, which is why we’re already on the eighth version of Macromedia Flash! No application can ever be perfect. The goals of usability planning are to get as close as you can. In our next chapter, we will put together all of the solutions in Part 2 to create one integrated solution! Let’s see how well we planned for creating that perfectly usable application.

14

297

5947CH15.qxd

1/27/06

12:29 PM

Page 298

5947CH15.qxd

1/27/06

12:29 PM

Page 299

15 THE USABLE BOOKSTORE

5947CH15.qxd

1/27/06

12:29 PM

Page 300

F L A S H A P P L I C AT I O N D E S I G N S O L U T I O N S : T H E F L A S H U S A B I L I T Y H A N D B O O K Alas, we’ve come to the very last chapter of our little book about Flash usability. We hope that the past 14 chapters have made you think about developing Flash applications with a new perspective. We also anticipate that you haven’t agreed with everything we’ve said. If you have an objection to a coding approach, a line of thought, or any other subjective statement we’ve made in this book, that’s good! It means you’ve thought of a better way to solve a particular usability problem. Usability design needs this kind of constant argument from all angles of development to be both progressive and innovative. However, that’s not to say we won’t put up a good fight and defend what we’ve written in the previous chapters! In this final chapter, we will synthesize many of the solutions discussed previously into a complete, usable Flash application. Think of this chapter as a final exam for our solutions—an exam we hope we’ll pass with flying colors before graduating from Flash University (and prove that we’re not just a party school). You may have noticed a theme with many of the solutions in Part 2. A whole bunch of them revolved around the concept of an online bookstore using some friends of ED book titles. It shouldn’t come as a huge surprise then that our final project will be to create a friends of ED bookstore with the kinds of usability enhancements you saw earlier. Our Book Shopper application can be found at www.userenabled.com. First, let us assure you that this is a demo only—feel at ease to use the demo as often as you wish, with the knowledge that you aren’t really going to be purchasing 500 copies of Podcast Solutions and absolutely no information you share will be stored anywhere on the server! Second, we recommend that you give the application a few trial runs before you continue with this chapter, so that you develop your own unbiased opinions of it. We’ll spend the bulk of this chapter analyzing the bookstore from the user’s perspective, stepping through a typical user’s workflow, so you can see how all the usability enhancements combine to aid the user experience. At the end, we’ll summarize the solutions used in the application. Here’s what we’ll cover in this chapter: Navigation through the bookstore application Where each solution fits into the usable bookstore application

Navigating through the application When you first arrive at www.userenabled.com, you are presented with a clean interface with a clear objective: to browse and potentially purchase (OK, pretend to purchase) some informative books by friends of ED publishers. Our statement of purpose for the application is clear and simple.

The purpose of this application is to make the experience of browsing and potentially purchasing books an efficient and enjoyable process.

300

5947CH15.qxd

1/27/06

12:29 PM

Page 301

THE USABLE BOOKSTORE

Arriving at the Book Shopper Before you even begin your book shopping experience, we’ve done a few things to optimize the delivery of the application. First, we’ve made accommodations for users who do not have the version of Flash Player this application requires (Flash Player 8). For those of you with Flash Player version 6.0.65 or higher, you should see a prompt within the player that will let you install Flash Player 8 without having to leave our site. Otherwise, you will see some HTML directions that will lead you to the Flash Player download site. In addition, we’ve built the application to be flexible on all browser sizes. Whether you are using an 800✕600 screen or one of those monster 1920✕1200 screens, the bookstore should take full advantage of your screen real estate. Notice how the application adjusts as you expand or contract your browser. Figure 15-1 shows the opening screen.

Figure 15-1. Our completed Flash bookstore application in action

Finding help If you begin using the bookstore and find an area of the application that looks unfamiliar to you, you can use the help tip feature by clicking the on button in the lower-right corner of the application. In designing this application, we assumed that its average users are more technically advanced than average Internet users (given that they are here to buy a book on a particular technical subject), so we’ve defaulted the help to off, with the anticipation that it won’t be used frequently.

15

301

5947CH15.qxd

1/27/06

12:29 PM

Page 302

F L A S H A P P L I C AT I O N D E S I G N S O L U T I O N S : T H E F L A S H U S A B I L I T Y H A N D B O O K If you have turned the help on, you can use the mouse cursor to roll over and get additional information about each different element of the application. For instance, roll over the shopping cart area on the upper-right side of the screen with the help turned on to reveal its help tip, as shown in Figure 15-2.

Figure 15-2. Using help tips to provide better support for newer users

Selecting a category of books The first thing you probably want to do when looking for books is head to a category of interest. Technical book consumers know a good deal about the kinds of books they are interested in before they even step through the door. As Flash-o-philes, we head right for the Flash section on the computer book shelves at the local bookshop. Likewise, HTML enthusiasts will be looking for books on web standards, CSS, and so forth. As shown in Figure 15-3, we section off the entire friends of ED catalog into major categories, represented as selection tabs across the top of the application (Flash, naturally, is the default section!). Within these categories are more specific subcategory links that allow a more refined level of categorization for our expansive book catalog.

Figure 15-3. Using sensible categories to help customers find the topics they are seeking

When you first click a tab, the catalog displays all of the books within the category, and if necessary, a scrollbar on the right side (based on the height of your browser). You can then sort your selection even further by clicking the text links underneath the tabs. By the way, as you navigate through the various categories and subcategories, you may want to click your browser’s back button to go to the previous section of books. We’ve enabled the browser back button to do just that.

302

5947CH15.qxd

1/27/06

12:29 PM

Page 303

THE USABLE BOOKSTORE

Filtering the book catalog The book’s topic is essential but probably not the only criterion you’ll use to buy a book. Another key consideration about book purchases is the price of the book. Even the most successful web professionals still hunt down the good deals! The application includes a slider, as shown in Figure 15-4, which allows you to filter the book results to just those that meet your price range. Those book items that no longer match the price range fade out instantly, so you know which items just missed your price range. In addition, we’ve included another slider that filters books by their page counts, for those of you who want to know how much reading you’re getting yourselves into!

Figure 15-4. Using sliders to filter prices and page counts

Learning about books in a category You can learn about each book in several ways. When you click a book item, the application will load and display a description, product information, and a larger cover image in a pop-up window, as shown in Figure 15-5.

15 Figure 15-5. The description window provides great insight into each book.

303

5947CH15.qxd

1/27/06

12:29 PM

Page 304

F L A S H A P P L I C AT I O N D E S I G N S O L U T I O N S : T H E F L A S H U S A B I L I T Y H A N D B O O K An additional, unique feature we’ve added to the application is a comments and reviews pop-up window. Because books are often purchased based on recommendation, we felt that including this information would be an asset to users. Click the Comments and Reviews text link within the description panel to pop open a window that includes other people’s opinions on the books in your category, as shown in Figure 15-6. You can then filter through the most recent entries by rolling your mouse toward the bottom or top of the listing using mouse-position-based scrolling.

Figure 15-6. The blog window uses mouse-position–based scrolling to cycle through entries.

Adding and modifying items in your cart Relying on drag-and-drop, the application includes a shopping cart drop area in the upperleft corner. Adding an item to the cart is simply a matter of dropping the item over the panel, or clicking the Add to cart link within a book item.

304

5947CH15.qxd

1/27/06

12:29 PM

Page 305

THE USABLE BOOKSTORE You can then click the cart itself to bring up a window that shows detailed information about your current purchases, as shown in Figure 15-7. Here, you can use a numeric stepper component to buy multiple copies of the books you’ve placed in your cart. In addition, you can remove items from the cart by dragging an item from the listing over to the garbage can icon displayed within the pop-up window.

Figure 15-7. The shopping cart detail window allows you to remove items by dragging them over a garbage can icon.

If you accidentally close your browser after adding items to your cart, don’t fret—your cart information will be stored automatically for you when you return! This is helpful not just if you closed your browser, but also if you want to take your time searching for the perfect set of books and decide to come back later.

Submitting your billing and shipping information When you’re ready to check out, simply click the Proceed to Checkout button on the bottom of the shopping cart window or the Checkout tab, and you’ll be presented with a form, as shown in Figure 15-8. This form provides a quick way to fill in your billing and shipping information by taking advantage of tabbing, auto-scrolling, and on-the-fly validation.

15

305

5947CH15.qxd

1/27/06

12:29 PM

Page 306

F L A S H A P P L I C AT I O N D E S I G N S O L U T I O N S : T H E F L A S H U S A B I L I T Y H A N D B O O K

Figure 15-8. The billing and shipping form uses on-the-fly validation for increased efficiency.

Submit the form, and you’ve just completed your fictitious book purchase!

Synthesizing the usability solutions Having played around with the bookstore, you’ve probably found some elements that look all too familiar to you now. That’s because we’ve done our best to incorporate all the different chapter solutions into this final application. It’s like a geeky game of Where’s Waldo. Can you find all of them? In Table 15-1, we list the different usability solutions that are incorporated into the final solution. Table 15-1. How the usablity solutions fit into the completed bookstore

306

Solution

Implementation

Mouse-position–based scrolling

Allows gesture-driven scrolling for book comments and recommendations

Loading progress bar

Used to load the individual book thumbnail images

Drag-and-drop selection

Allows you to drag a book into the shopping cart or into a trash can from within your shopping cart

5947CH15.qxd

1/27/06

12:29 PM

Page 307

THE USABLE BOOKSTORE

Solution

Implementation

Data-filtering slider

Lets you filter books in a category by price and page count

Scrolling forms with on-the-fly validation

Allows you to efficiently submit billing and shipping information

State management

Maintains the state of your shopping cart the next time you return

Help tips

Provides easily accessible pop-up tips for the major sections of the application

Enabled browser back/forward button

Allows you to go back and forth between previously selected book categories

Liquid layout

Adjusts the application’s interface to any browser size

Embedding Flash using FlashObject

Displays alternative content for users without Flash Player 8, and also includes an implementation of Flash Express Install for users with a player version higher than 6.0.65

Summary While the sun has set on our little book, it should just be rising for you in your exploration through this boundless medium we call Flash. We sincerely hope you’ve enjoyed your time reading this book and that it finds a nice spot on your office desk or nightstand. That being said, we would be remiss if we didn’t point out some other great pieces of literature. In Chapter 1, we said that this is neither a book on ActionScript programming nor a book on usability theory; rather, it sits somewhere comfortably in between. The appendix that follows contains our recommendations for reading material that focuses more on one or the other. Just as pairing a great wine with your dinner makes the experience that much better, pairing this book with one (or more) of the books that follow will also give you a much richer experience! So, check out those books and have another great read. Until then, happy Flashing everyone!

15

307

5947App.qxd

1/27/06

11:44 AM

Page 308

5947App.qxd

1/27/06

11:44 AM

Page 309

APPENDIX RECOMMENDED READING

5947App.qxd

1/27/06

11:44 AM

Page 310

F L A S H A P P L I C AT I O N D E S I G N S O L U T I O N S : T H E F L A S H U S A B I L I T Y H A N D B O O K As we mention in the introduction, this book is neither a doctrine for usability nor a primer for learning Flash—it’s somewhere in between. We hope that in reading our chapters, you are both invigorated to consider how to make your Flash projects more usable and eager to harness the true power of ActionScript 2.0 (AS2) code. That being said, we wanted to use this appendix to provide you with a summer reading list of sorts. Many great books and websites help you focus in on usability, Flash, and the mix of the two. Here some of our own personal favorites.

ActionScript 2.0 (and OOP) programming This book is not just about how to make pleasurable web interfaces. A whole lot of code goes into making these solutions work. Sprinkled with our discussions on usability are some helpful tips on making your code reusable and scalable through using object-oriented programming (OOP) techniques. The truly advanced Flash developer needs a thorough knowledge of OOP to really benefit from (and enjoy) the advantages AS2 programming has to offer. The following are some books we consider to be absolutely essential reference guides to have near your computer. ActionScript 2.0 Language Reference for Macromedia Flash 8 by Francis Cheng, Jen deHaan, Robert C. Dixon, Shimul Rahim (Macromedia Press, 2006): This book provides the most thorough print documentation we’ve seen on the AS2 language, with understandable explanations of pretty much every Flash method, object, and property. You’ll find it an invaluable resource when you need that refresher on a particular object. Coming in at over 1,000 pages and 2 inches thick, it also makes a great paperweight or seat booster! Essential ActionScript 2.0 by Colin Moock (O’Reilly, 2004): This book is broken into three parts: an overview of AS2, application development strategies, and how to use design patterns with Flash. Even if you’re a well-seasoned Flash developer, the introduction to design patterns is a must-read! It will give you a real flavor of the incredible power and flexibility of AS2 and OOP. The Object-Oriented Thought Process (2nd Edition) by Matt Weisfeld (Sams, 2003): This is a very solid, easy-to-read book on basic object-oriented concepts. If you’re new to OOP and haven’t yet taken advantage of AS2, this book will get you up to speed on key concepts and methodologies. It’s also a great refresher and reference guide if you’ve forgotten anything along the way. As the book title suggests, this book makes you see the world in an object-oriented way. In addition, watch for the following friends of ED books coming out in the very near future. These make great companions to the code discussions we have in this book!

310

5947App.qxd

1/27/06

11:44 AM

Page 311

RECOMMENDED READING Foundation ActionScript for Flash 8 by Kris Besley, Eric Dolecki, and Sham Bhangal: The ultimate beginner’s book for learning how to use ActionScript in Flash 8, this book explores all the fundamentals you’ll need, as well as the new features Flash 8 has to offer. It expands on some of the new Flash 8 features we discuss in this book (such as filters and new font-rendering capabilities).

A

Object-Oriented ActionScript for Flash 8 by Peter Elst, Sas Jacobs, and Todd Yard: This book is all you’ll need if you want an up-to-date guide to coding objectoriented applications in Flash 8. It covers OOP basics, design patterns, custom component frameworks, and more.

Usability design We recommend the following books for information about usability design: About Face 2.0: The Essentials of Interaction Design by Alan Cooper and Robert M. Reimann (Wiley, 2003): Cooper, author of The Inmates Are Running the Asylum, is the founder and chairman of Cooper, an interaction design company, as well as the “father” of Visual Basic. This book takes a very refreshing look at software design (both on the Internet and the desktop) and introduces you to goal-directed design. If you’re looking for a serious study in usability and interaction design, this is the book for you! Don’t Make Me Think: A Common Sense Approach to Web Usability (2nd Edition) by Steve Krug (New Riders, 2005): Usability is often discussed in a dry, deliberate, plodding manner. It doesn’t have to be this way! Case in point: Steve Krug’s second edition in the Don’t Make Me Think series of usability books. Krug approaches usability in a humorous way, uncovering the myths and facts about how people use the Web. Homepage Usability: 50 Websites Deconstructed by Jakob Nielsen and Marie Tahir (New Riders, 2001): This book specifically examines the usability of website homepages. It offers a number of specific tips on improving a homepage, and then deconstructs 50 different website homepages. One interesting approach they use is to break down the screen real estate of each home page to determine how much of your page is dedicated to different user tasks. This book will give you a very visual lesson in homepage, and website, usability. Making the Web Work: Designing Effective Web Applications by Bob Baxley (New Riders, 2002): If you’re looking for a comprehensive discussion on web application design, this book is a great place to begin. It has a good mix of material on information architecture, usability engineering, and web design.

Flash usability (historical) One of the reasons we felt compelled to write a book on Flash usability is that there hasn’t been one on the market in the past few years (at least not since AS2 was released). Why this came to be is anyone’s guess. Perhaps the initial interest in discussing Flash usability has lost some momentum in recent years. We hope we’ll be the ones to revive it!

311

5947App.qxd

1/27/06

11:44 AM

Page 312

F L A S H A P P L I C AT I O N D E S I G N S O L U T I O N S : T H E F L A S H U S A B I L I T Y H A N D B O O K The following are a few “historical” books on Flash usability that gave us great inspiration for the book you hold in your hands right now. While some of the technical approaches and feature discussions are somewhat outdated, they are still worth reading, as they provide a ton of useful information on usability best practices that are just as relevant today as they were a few years ago. Flash 99% Good: A Guide to Macromedia Flash Usability by Kevin Airgid and Stephanie Reindel (Osborne/McGraw-Hill, 2002): The title of this book is a bit tongue-in-cheek. In 2000, usability guru Jakob Nielsen proclaimed Flash to be “99% bad” based on the prevalence of unusable Flash sites. This book seeks to repudiate Nielsen’s claims by offering sage advice on Flash usability. Included are interviews with Flash developers and designers, as well as several real-world case studies. Skip Intro: Flash Usability and Interface Design by Duncan McAlester and Michelangelo Capraro (New Riders, 2002): This book was probably the first true code-heavy Flash usability book to hit the market. McAlester and Capraro approach usability without sacrificing innovation. Some of the solutions found in the book your holding (such as help tips and gesture-driven scrolling) are also found in Skip Intro, though the implementation there is geared toward Flash MX. The Flash Usability Guide: Interacting with Flash MX by Chris MacGregor, Crystal Waters, David Doull, Bob Regan, Andrew Kirkpatrick, and Peter Pinch (friends of ED, 2003): This guide talks about design principles, conventions, and methods that are critical to successful usability projects in Flash. This book goes more into the thought process of usability engineering rather than specific solutions.

Web resources The following are some Web resources we recommend: www.actionscript.org: Actionscript.org is a good site for Flash tutorials, job postings, and news. www.digital-web.com: If you’re into reading articles on a wide range of web design issues (or even want to contribute your own), Digital Web Magazine is a great site to keep up-to-date on the state of the Web. http://blog.deconcept.com/flashobject: Deconcept: FlashObject contains a full explanation of the FlashObject embed method that we discuss (and highly recommend) in Chapter 13 of this book. http://livedocs.macromedia.com/flash/8/index.html: Flash 8 LiveDocs is a great resource for AS2 language reference, samples, and tutorials www.flash99good.com: Flash 99% Good is Kevin Airgid’s (coauthor of Flash 99% Good) website, which was revamped in the fall of 2005. It provides great links and ideas about Flash usability. www.useit.com/papers: Jakob Nielsen, perhaps the most well-known web usability supporter, writes a host of articles worth reading at Useit.com.

312

5947App.qxd

1/27/06

11:44 AM

Page 313

5947INDEX.qxd

1/27/06

12:32 PM

Page 314

5947INDEX.qxd

1/27/06

12:32 PM

Page 315

INDEX

5947INDEX.qxd

1/27/06

12:32 PM

Page 316

INDEX

A About Face 2.0 (Cooper and Reimann), 111 ActionScript directory structure, 15 features, 4 Flash Player and, 8 navigation menus, 51–62 recommended reading, 310 shopping cart solution, 121 usability benefits, 4 ActionScript Settings window, 15 addDropArea method, 130, 135 addEventListener method, 179 addFormElement method, 190–192 addListener method, 100 adjustable layouts. See liquid layouts Ajax, 8, 229 alert boxes (JavaScript), 166, 170–171 Alert component (Flash), 171 alpha property content loading and, 79, 91, 102 data filtering example, 160 movie clips, 50 shopping cart solution, 119, 133 Tween object and, 34–35 alphaTween property, 217 alt attribute (HTML), 210 Amazon.com, 112, 250 anchor tags browser history solution, 238, 243–244 hyperlinks and, 20 Internet Explorer and, 230 Anti-alias for readability option, 254 APIs, 83 application maps, 291 applications Book Shopper, 300–307 building skip intro feature, 202 defining purpose, 291 form validation, 165–167 liquid layout, 248, 252–267

316

remembering state, 198, 203 RIAs, 10–11, 286–289 usability testing, 294–295 wireframes for states, 292–293 asynchronous processing, 6, 8, 69 attachButtonItems method, 123, 126 attachDragItem method, 128–129 attachMovie method, 33, 191 audio clip loader building audio player, 77–82 laying out features, 75–76 Model-View design pattern, 82–96 audio players, 77–82 AudioFileLoader.as class building loader model, 84–89 building loader view, 89–95

B back button browsers, 228 Flash history solution, 230–242 Flash issues, 228–230 bandwidth, content loading and, 68 beta releases of applications, 295 billing and shipping information, Book Shopper, 305 Blur X property, 49 Blur Y property, 49 book item button clip, 23, 30–32, 34 book item buttons, 203–204 book selection system browser history solution, 241 creating movie clip, 32 linking classes to movie clip, 23 state management example, 203 Book Shopper application, 300–307 BookItemButton class browser history solution, 241 creating, 23, 33–36 state management example, 204 BookSelectionSystem class, 23, 37–38

5947INDEX.qxd

1/27/06

12:32 PM

Page 317

INDEX broadcastEvent method EventBroadcaster class, 159 EventDispatcher class, 157 browsers back button issue, 228–230 built-in functionality, 20 cookies and, 114 cross compliance, 6 Document Object Model and, 202 download dialog box, 70–71 embedding Flash, 272, 274 Flash and, 4 Flash history solution, 230–242 liquid layouts, 248, 251 navigation menus and, 44–45 shared objects and, 199 sniffing, 273, 277 Button component (Flash), 171 buttons. See also back button adding to audio player, 81 defining actions when clicked, 37–38

C calendars, 111 callBack function (MovieClipLoaderUI), 99 Cascading Style Sheets. See CSS catalogs, Book Shopper application, 303 categories, Book Shopper application, 302–303 centerClip method, 106 chain of inheritance, 33 check boxes, 171 Checkbox component (Flash), 171, 174, 187 checkLoadStatus method, 87 checkPage method, 234–235, 241 checkURL method, 237–238 class package, 15 classes extending, 23 interfaces and, 132 selection system and, 24–30 singleton, 261

classpath, 15–16 clearError method, 180, 183 ClearHistoryButton class, 206 client/server model data storage, 143–144 Flash Player Detection Kit, 277 shopping cart solution, 114 codebase attribute, 276 ComboBox component (Flash) building better forms, 173, 181, 187 JavaScript equivalent, 171 ComponentWrapperBase class, 177, 179–183, 187–188 concept/experience design, 294 containers for forms, 176, 189–193 content loaders/loading alpha property, 91, 102 audio clip loader, 75–96 building for menus, 61–62 case study, 103–107 Flash solution, 69–75 HTML and, 69 movie clip holder, 96–103 ContentArea class, 257–261 cookies, 114, 199–200 Cooper, Alan, 111, 211 CSS (Cascading Style Sheets) Ajax and, 8 browser history solution, 235 capabilities, 20 liquid layouts in HTML, 250 navigation menus and, 44–45 title attribute and, 211 cueDragDropManager method, 127

D data filtering building Flash solution, 147–160 improving with Flash, 143–147 limitations of standard searches, 140–142 data object, 201

317

5947INDEX.qxd

1/27/06

12:32 PM

Page 318

INDEX data storage, 143–144, 198 DataFilterManager class, 150–152, 155–156, 158, 160 DataFilterSlider class, 152–155 date format, 167 design pattern metaphor-based, 110–111 Model-View, 82–96 Singleton, 157 Strategy, 180–182 development, usability and, 291–293 directory structure, 14, 16 disableMenu method, 53–56 dispatchEvent method, 156–157 displayError method, 180, 183, 188 Distance property, 49