Josh Talks Flash

AdvancED Flex Application Development offers a unique perspective

Unlike other Flex books, AdvancED Flex Application Development: Building Rich Media X by R Blank, Hasan Otuome, Omar Gonzalez, and Chris Charlton (enough authors, guys?) doesn’t cover Flex with a lot of little examples that introduce the features of Flex to newbies. Instead, the authors present a bit about Flex through a look at an application they built called Rich Media X. Rather than cover all the same-old, same-old Flex basics, this book covers the process of building the application and many of the considerations they had to make during the process. I think it’s great that Flex books are starting to move into a wider variety of material, and I hope this is the first of many.

What’s most interesting in this book, in my opinion, is the section on planning. Every Java head (and probably his mother too) knows all about requirements and design documents. In the Flash world, a lot of coders don’t have any experience with this sort of traditional software engineering stuff. It was great to see the authors spend time talking about finding requirements, determining how much time they had available (and inevitably, what needed to wait until a future version), and things like wireframes and various other diagrams. I honestly wished they’d spent another chapter or two on this subject. I think the Flex development community would benefit from a more engineering-focused book that has an ActionScript twist.

One thing I didn’t like was the actual application the authors presented. Rich Media X is more of a distributed set of applications that Adobe User Groups can opt-into individually, and it’s very different than the traditional Flex app. While it’s good to show that Flex can do crazy and interesting stuff, the subject of this book is very abstract compared to most Flash and Flex books. Combine that with an app that requires a reader to wrap her head around its very purpose and you have a very confusing read. I found myself switching contexts too often. They’d slip in a chapter on how to specifically do something like styling in Flex, and suddenly everything would change as I learned about installing Drupal or what makes a good advertising platform. Not to say that learning about Drupal is a bad thing. In fact, I think the topic of technology integration with Flex made the book a little more interesting.

At the end, there was a “Special Topics” section that covered what I assume were chapters that the authors didn’t know how to integrate with the main content. A chapter on SEO was nice, especially the mention of Ted Patrick’s XSL-based Flex SEO system. On the other hand, the tip of using CSS-hidden HTML content for search engines to crawl was misleading since Google penalizes that behavior. The next chapters about how to build an audio visualizer and what’s new in Flex 3 didn’t fit in at all. The tendency for authors and publishers to say “oh, a new version came out, let’s make sure we add a chapter that covers the new features” is getting old. Either integrate it into the main book’s content, or in the case of this book, don’t include it at all because the topic of the rest of the book wasn’t an overview of the previous version.

Ultimately, while I had some gripes with AdvancED Flex Application Development: Building Rich Media X, it was a nice change of pace for me. I like when tech books experiment with the normal format because I generally hate tech books. This one looked at Flex from the perspective of how to build a big application instead of how to start using Flex. That’s awesome. Personally, I think it tried to fit in a bit too many subjects at once, and maybe some more focus would have made it better. Check it out if the regular “getting started” development book isn’t your style.

by Josh Tynjala | Start the Discussion

Bug when creating CS3 UIComponents in Document Class constructor

Under one specific condition, a Flash CS3 component will not draw for the first time until after it has been displayed to the user. Generally, that's not a problem, but there are times when it becomes noticeable. The following report demonstrates an obscure bug that most component developers working with the CS3 UIComponent architecture won't encounter. However, it becomes more visible with specific types of components, such the the Layout Containers in the Yahoo! Astra components for Flash CS3.

A quick background explanation to get everyone up to speed. The CS3 UIComponents rely on the stage's "render" event as part of the validation model. Basically, a component will wait until just before Flash Player displays something new to screen before running its main drawing code. This ensures that developers can set many properties at once without redrawing every single time. The render event provides a "last chance" place for code to run.

The Bug: No Event.RENDER for first frame

When a SWF first starts up, the document class constructor is run. Imagine that you want to create an application with a layout container, like the Astra VBoxPane, to arrange your controls. You insantiate the VBoxPane and add it to the display list. Next, you create several controls and add them to the VBoxPane. Very standard stuff, and you put all this code into the document class constructor.

When you run your SWF, sometimes you notice a very strange issue on the edge of your vision. For a very brief moment (if you blink, you'll miss it), all the controls in the VBoxPane are stuck in the top-left corner at x=0, y=0. You don't see it happen every time, though. Maybe it's your monitor's refresh rate. Maybe the browser just doesn't allow Flash Player to draw itself right away, but it definitely happens sometimes.

The problem I discovered is this: Event.RENDER doesn't get fired before the very first frame is drawn when you start up your SWF. The first time you can receive Event.RENDER is after the first time Event.ENTER_FRAME is fired. For reference, the enterFrame event is a lot like RENDER. It's the very first code that gets run after Flash Player draws to screen. When the SWF starts up, the document class constructor code gets run, then Flash Player draws itself, Event.ENTER_FRAME is fired, and then Event.RENDER is finally fired the first time before frame two. In the case of our VBoxPane, all of its children are on the display list and visible to the user when the first frame is drawn because we added them to the display list, but the component never had a chance to position them!

The Workaround: A simple drawNow()

If you're using any of the Astra layout containers, and you encounter this problem, there's an easy fix. In your document class constructor, after you create the layout container and add its children, call drawNow(). This will force the container to draw immediately. Since we're still in the constructor, it's before the first frame is displayed to the user, and all the controls should be laid out properly.

I should note, most developers using the CS3 components never have to touch drawNow(). It's most useful to custom component developers who want to put components inside other components. It ensures that the child components draw properly. While a bit of a pain, that's a very different thing than the bug I'm reporting here.

Test case: Some simple code to see this problem.

As part of my investigation, I created some simple code to demonstrate the bug. This is code I'm submitting to Adobe in a bug report. It contains trace() statements that show the difference between the expected order of operations and the actual order.

First, a document class that instantiates a component:

And the simple component that is created in the document class constructor:

For the next version of Astra, I plan to work around the bug in a different way so that developers don't need to call drawNow() manually. However, it is a hack that involves visibility changes, and I definitely want to see this bug fixed in UIComponent in the future.

by Josh Tynjala | 1 comment

Foundation Flex for Designers has a misleading title

Friends of ED markets its books with the slogan Design to Designer. When I read Foundation Flex for Designers by Greg Goralski and LordAlex Leon, I wondered who gave this book the wrong title because it didn't quite fit that philosophy. A better name might have been Foundation Design Tools for Flex Developers because I don't think the book's target audience will find it very appealing. Instead, maybe a developer might be able to pick up a few skills to use when he doesn't have a designer on hand. Either way, I think the book as a whole could use some rethinking.

A design major was my second choice in university. I ultimately become a software engineer, but I'd like to think I have at least a little insight into what makes a good book for designers. When I put my design hat on, I want to learn from looking at things that are designed well. Inspire me while you teach me the basics. Unfortunately, this book doesn't offer anything like that for me. Almost every screenshot displays what some of my co-workers call "programmer art". Even worse, many still have "a blue-gray background and silver-skinned components". That's exactly what the description on the back says the book is trying to prevent. It also claims to help the reader create "an application that is both visually stunning and beautifully functional". With big goals like that, some very strong designs featured in every example should have been a high priority. At the very least, every example should have been fully skinned so that they looked nothing like Flex's defaults.

It's common for book authors and documentation writers to ignore best practices when demonstrating how to do something specific with technology. People want simple examples, and it can be hard to do things "right" when there are many more ways to get the point across that take a shortcut or two. I'm against this practice of taking shortcuts because I believe every line of code (or every pixel of your design, for that matter) will teach your reader something, and its not always something you intended. Someone who has no basis for judging good code will believe all your code is perfect because you're supposed to be the expert.

An example of skipped best practices appears in chapter 3 where the authors create a "personal website" with Flex. Where should I begin? First and foremost, this website consists of mostly text and and a few static images. No real rich interactions provide a justification for using Flex (or even using Flash Player!). The chapter's purpose was to teach the reader how to use states. Personally, I think a view stack would have been better for the use-case presented in the example. In short, everything about this example would have been better in HTML. Something smaller, perhaps more of a component with advanced options, would have provided a better example of states.

One interesting detail about the design of the book itself bothered me: All the sample code is displayed through screenshots from Flex Builder. In other words, a ton of text in this book is displayed as images. Sadly, this makes all the code slightly blurry because the regular book text is printed at a much higher quality. Additionally, for some particularly long lines of code, rather than breaking each statement across multiple lines, they simple scaled some of the screenshots down to smaller size. This makes the text absolutely tiny. Anyone with poor vision will only get frustrated trying to read the many of the MXML samples.

In most chapters, the examples are presented through simple Flex applications. Unfortunately, I believe this pulls the focus of the book away from design and the tools available for designers targeting Flex, and it presents a lot of ActionScript that doesn't influence the design in any way. Friends of ED, O'Reilly, and other publishing companies already have entire books introducing ActionScript. It seems to me that most of the code should be skipped to really focus on things designers can do to enhance rich applications. More time could have been spent on building content in Flash CS3 or other designer-friendly apps and bringing those designs over to Flex Builder. Similarly, some tricks for making skins completely transform components in new ways would really energize the Flex community. I remember the first time I learned how to exploit background images combined with padding in CSS to add icons and other flare to HTML. For something so simple, I was excited because it was looking at a problem from a direction I would never have considered. Nothing like the CSS design revolution of the HTML world has influenced Flex yet. Projects like Degrafa are starting to change things, but the book provides no evidence of this project's interesting new take on Flex design.

I can't recommend Foundation Flex for Designers. With the focus of design inherent in the title, I expected some real new approaches to design for Flex that would provide ways to skin components that aren't immediately obvious (and maybe even do things in ways that Adobe didn't expect). Instead, I got a rehash of the same old stuff that appears in other Flash and Flex books. All the Flex and ActionScript basics are available in book form now. Publishers need to begin branching out to more specialized areas. Most disturbing, for me, is the fact that the skin designs presented in the book are so poor that it seems difficult for even an experienced designer to pick up Flex-related skills. I see many readers spending their entire time critiquing the ugly screenshots instead of reading and learning.

by Josh Tynjala | 2 comments

iPod Classic Usability and Quality Concerns

In 2004, I became the proud owner of a third-generation iPod. It changed the way I listened to music. I had every MP3 from my computer at my finger tips. The user interface (both hardware and software) was simple and easy to use. The iPod was the first Apple product that I enjoyed. It probably played a big part in why I'm a Mac user today.

I'm a big fan of waiting to upgrade a product until there's a good reason to do so. I definitely won't buy a new cell phone every year, and I'm generally only an early-adopter when a product is particularly revolutionary. At the time, the iPod had already gone though a couple revisions, but this was the first one that really caught my eye (and it was around this time that it was starting to pick up real steam in the market). It wasn't a brick, it had more hard drive space, and the controls had improved some. Some may remember the battery-life troubles of those early versions too. I actually had to replace the battery twice and get a new hard drive too. Certainly, the iPod wasn't without its flaws back then, but this version had the polish to keep me satisfied for several years.

After witnessing some of my co-workers marvel at this piece of ancient technology (which was still running strong a couple years after the previously-mentioned repairs), and finding myself unable to find a decent set of speakers compatible with the older dock connector, I decided it was finally time to get a newer model. Of course, I had always been excited to get some of the features added to the newer generations. I saw the color screens on my friends' iPods and felt a bit of jealously. My own iPod's screen was smaller and only one color. I liked the new wheel design without the separate buttons for play/pause, menu, and next/previous. The longer battery life was going to be great. In short, I was making a mental laundry list of features that would someday add up to a convincing argument to get a newer version.

During a visit to the Apple Store a couple months ago, I knew it was finally time, and I bought the Sixth-generation iPod "Classic". While I dig the smaller Nano, it still doesn't provide the hard drive size I need. I was tempted to try out the iPod Touch, but I didn't like the higher price. I've been using it quite a bit since I bought it, maybe even more than my old iPod. I discovered some very obvious changes to this newer model that just feel wrong and leave me thinking it's a partial downgrade.

The Wheel

The first thing that felt a little off to me was the sensitivity of the wheel. At times, it's just too fast. It takes only the tiniest touch to go from one band to the very next on the Artist menu. I frequently find myself having to scroll back and forth several times to ensure that it picks the correct artist when I'm scrolling. My hands are smaller than those the average guy, so you can't argue that I have fat fingers. It happened on very rare occasions with my old iPod, but I keep noticing this again and again with my new one. Slow down!

There's a new scrolling feature that seems cool at first, but fails to be usable very quickly. As you scroll through the list, it may suddenly show a letter of the alphabet in the middle of the screen. At that point, you stop scrolling artist by artist (or album by album, whatever the menu may be), and it will begin jumping to the next letter rather than individual items on the list. The first thought that ran through my head was "Cool! That'll save tons of time." I imagine everyone else thinks the same thing. Unfortunately, it doesn't save any time for me.

Much like with the previous sensitivity issue, I discovered myself scrolling way too far. Then I needed to scroll back the other direction. In other words, it's probably great if you're going from C to W, but not so much with smaller jumps. In many cases, I've had it suddenly change to letter scrolling when I'm only a few items away from my intended choice. Ugh. What's interesting about this one is that I remember my old iPod scrolled faster depending on how fast I spun my finger on the wheel. That felt intuitive. The sudden appearance of a letter and a completely different scrolling speed means that my brain can't switch contexts fast enough and I always need to correct myself when it scrolls too far.

Oddly enough, sometimes scrolling can be completely unresponsive too. I'll spin the wheel half a dozen times to change the volume before it reacts. My old iPod didn't have that problem. To me, this is a major decline in product quality, and its absolutely the worst of the problems I've encountered with the newer model. It seems to happen mostly when I first start playing a song. I've considered what might cause this behavior, and I have three possible explanations.

• The iPod may have some software or hardware that is still being initialized in the background, so the CPU is overworked. I'm very likely to tweak my volume setting immediately when I begin listening to the iPod. I listen to the iPod in two main locations: in my car or with headphones. Both require very different volume levels. Seeing as I've just started using the iPod when this happens, it has my entire metal focus, so it needs to work well. I don't care if it takes longer to get everything running, don't degrade my experience once I can interact with a device.

• Compared to my old iPod, more data appears on screen when a song is playing. I suspect that it's working very hard to display the album artwork. The main evidence is that the image doesn't appear right away when the song changes. It's just the standard placeholder graphic for a moment. For a small device, I wouldn't be surprised if decoding a JPG were a little difficult.

• On my MacBook Pro, there's a setting for the touch pad to ignore "accidental" presses. I'd be willing to bet that Apple uses the same technology for both devices. There is no such setting for the iPod. If this is the cause of the unresponsive interface, I can't do anything to correct it like I'd be able to on my laptop.

Regardless of the reason for unresponsive scrolling, whether it be technical or by design, the device shouldn't feel like it is lagging so far behind my input.

The Screen

I remember hearing that a certain generation of iPods had especially poor screens. They were prone to scratches and Apple almost immediately released an updated design with special protrusions mean to protect the screen. My new iPod already has two very noticeable scratches on the screen and no special protected protrusions to prevent such damage. They're ugly, and now I'm annoyed every time I look at my iPod.

My old iPod had many superficial scratches, sure, but it felt more like standard wear and tear than this nasty multi-colored scar. Personally, I refuse to buy a special case for any of my devices. Some scuffs or nicks are okay with me. All the cell phones I've owned, my old iPod, the old portable CD players I used to use, and everything other portable device that comes to mind has survived my daily life with nothing I'd call "damage". Sure, my iPod is still usable, but it clearly isn't as durable as my old one. I accidently dropped my old iPod a couple times, including on pavement once. It looks a little worn, but like I said, that's fine. My new iPod has been set down gently in the same place every day, and it goes into the same otherwise-empty pockets as the old one. I haven't dropped it. I can't even explain what caused the scratches.

Random Stuff

When I don't interact with the iPod for a minute or so, the screen changes. Rather than showing me the currently playing song like it did a moment ago, it provides me with the current time. Now, I might be strange, but I listen to a lot of new music on my iPod. Sometimes, if I buy a new album or download a new promo song, I might not recognize what's playing. Before, with my old iPod, I could generally just peek down at the screen to see what's playing. If it was too dark, I could touch the wheel and the backlight would pop on.

Now, as I mentioned, there's a clock. I'm required to touch the wheel to see the song information. When I do, it still shows the clock for a moment once the backlight turns on. That's two short moments where I could have already gotten the information I needed with my old iPod. To go a step further with my annoyance at this feature, I'd like to point out that I own a watch and a cell phone. They both tell me the time already. I don't need three clocks on me at all times. With my old iPod, Apple provided a setting to let the iPod track the time or not. This time around, I get the time no matter what. It's a minor annoyance, these are really starting to add up.

One last thing. I can't turn the volume down to zero. Every audio device I've owned could be turned down all the way. Now, one might argue that turning it all the way down rather than just pausing it is silly. I agree. However, twice now, I've turned it all the way down and I wanted it to be quieter. I had to turn it off because the volume was distracting rather than providing the subtle ambiance that I desired.

Conclusion

For years, I was a happy iPod owner. Even when I had trouble with my old iPod, I felt more worried about not having music to listen to at work than feeling like I could have purchased a better device. Unfortunately for me (and maybe Apple too), the problems I described above don't make me want to go out and buy a new music player today. I can live with them. However, when the time comes again to buy a new device, I'm far more likely to look at the competition than I was before. Last time, I knew I was getting another iPod. There was no question about it. Next time, I'll be spending a little extra time checking out what else is available.

My problems with the iPod can be partially attributed to one problem that exists throughout the world of computers and electronics. You can start out by inventing an amazing product, but over time, as you add more features that weren't needed immediately, the product can become bloated. Worse, in my opinion, the existing features might be change in a bad way. This problem can sometimes happen when users stubbornly refuse to accept changes. Other times, it could be that you're just adding or changing features because you need to create a new version to sell. Personally, I think the standard "classic" iPod has reached this point. There's little that can be done to improve it now, but Apple keeps churning out new features or changing features without improving them much, if at all. It adds up, and only with a major upgrade skipping several versions (like mine), do some of these problems become obvious.

by Josh Tynjala | 4 comments