In his column, Mr. Nielsen focuses on the fact that people read such a small portion of the text. Using data from the study, he calculates that on average people read no more than 28% of the text on a given Web page. This helps to add further emphasis to a point of Web usability that has long been established: Keep the text short, relevant, and scan-able.

Another finding of the study that is of particular interest to those of us who are focused on building Web-based applications is the impact that we’re having on the back button. The browser’s back button has dropped to third place in the list of most-clicked items, and according to the study’s authors, this drop has something to do with what we sometimes call RIAs:

A major finding is the decreasing prominence of backtracking in Web navigation. This can largely be attributed to the increasing importance of dynamic, service-oriented Web sites. Users do not navigate on these sites searching for information, but rather interact with an online application to complete certain tasks.

What I would like to see analyzed is the degree to which the look and feel of the application makes a difference here. Most Web applications, since they’re built with Ajax, still look and feel very much like conventional Web pages. It seems to me that users are more likely to hit the browser’s back button in this case, than if the application looks more like a GUI and feels more like a desktop application. Speaking for myself, I still find myself hitting the back button from time to time when I’m in Gmail, which looks pretty much like a Web page. By contrast, it would probably never occur to me to hit the back button if I were using an app like Scrapblog or Buzzword. (I wonder if I could get a grant to study this?)

Ideally, of course, I’d like to say, “let’s put all of our applications on AIR and leave the browser for text-based Web sites.” However, there are those circumstances where zero-footprint is a requirement, and others where it’s just desirable - particularly from a usability perspective - to have the application come up in the browser. For those circumstances, it is good to have some data on how much people rely on the browser’s built-in controls.

Pretty funny, no? In any case, this should serve as a lesson to all of us: Write useful and professional error messages! It was always a good idea anyway, but now that anyone with the Debug version of the player can see what you wrote, it’s an even better idea. Otherwise, one day the joke may be on you…

]]> http://www.robsondesign.com/blog/index.php/2008/05/05/developer-humor-in-as3/feed/ http://www.robsondesign.com/blog/index.php/2008/04/29/musings-flex-3-vs-flex-2-help/ http://www.robsondesign.com/blog/index.php/2008/04/29/musings-flex-3-vs-flex-2-help/#comments Wed, 30 Apr 2008 00:55:12 +0000 jimrobson http://www.robsondesign.com/blog/?p=36 In the grand scheme of things, this may not seem like a big question. However, as a developer who likes to reference the API documentation frequently, it seems significant. The question is this: Why does the Flex 3 Help feature bury the API documentation when the Flex 2 Help feature made it so readily available?

Here is what I mean. In Flex Builder 2, if I typed “Canvas” in the search field, the first entry in the list was mx.containers.Canvas - Perfect! Exactly what I wanted!

However, if I type “Canvas” in the Flex Builder 3 Help search field, mx.containers.Canvas is way down in the list. It’s number 25 to be precise.

What is even more puzzling is that if I type in “mx.containers.Canvas” the first item that comes up in the list is mx.containers.utiltyClasses.IConstraintLayout. Why does this happen? What cosmic forces are at play here? You may ask, “Where is mx.containers.Canvas in this scenario?” Well, I will tell you: It is number 10 on the list.

While this question may not be up there with “What is the meaning of life?” it is nonetheless a nagging question in my little mind. Perhaps the answer lay somewhere out there in the vastness of the blogosphere, but as yet I am still in search of it. But the pursuit of truth is a grand adventure, and I will not tire of it!

However, that is no longer true for all developers or all applications. There is a significant difference in the way that the Flash 9 player handles swf’s that are loaded in at runtime. Grant Skinner details it thoroughly in this excellent blog post, but to put it succinctly: When you attempt to unload a dynamically loaded swf, the Flash player probably won’t release it from memory.

This issue has not affected me personally, because the applications I have built don’t typically unload swf’s. I make heavy use of lazy loading in order to improve application performance and load times, but I seldom unload a swf once it’s been loaded. The reason for this is a combination of bandwidth and user behavior: It is not unusual for a user to think that she has finished a certain task, only to discover a minute or two later that she needs to tweak something or re-do something. If I unload a swf when the user thinks she’s finished with it, then I need to chew up bandwidth re-loading it a minute or two later when she realizes her mistake.

But we don’t all build the same types of applications for the same user base. Some applications depend on the ability to unload dynamically loaded swf’s. If they can’t, then they experience serious memory issues. (See the replies to Grant Skinner’s post referenced above for some examples.) So this constitutes a dramatic change that requires these developers to do some heavy refactoring.

If Adobe is no longer going to maintain the same level of backward compatibility that Flash has historically enjoyed, then we lose one of our strongest reasons for using Flash. Of course, this is a bug, and not an intentional change. But how long will it be before it gets fixed, and how much pain is being inflicted in the mean time? And what happens if some future version of the Flash player has a bug that directly affects my applications? Can I trust Adobe to fix it promptly?

In the same post, Grant also points to the fact that AS3 handles dynamically loaded assets differently than AS1 and AS2 did. In AS3, you need to remove all references to everything in your dynamically loaded asset, or you can’t unload it from memory. It’s stuck there. I view this as a problem, as well.

In a very (un)helpful Flexcoders post on this topic, Alex Harui explains in that it is a great feature, because it prevents all of us idiots from writing the kind of “bad code” we wrote in AS1 and AS2. My thoughts on this? The Adobe team would do well to remember that they owe a large part of their success to us stupid, sloppy Flash and ColdFusion developers.

The technical merits of allowing us to unload assets without explicitly removing every internal and external reference are being well argued by others in the community, so I won’t repeat them here. However, I will say that if Adobe intentionally makes ActionScript development more difficult, then they effectively take away more advantages of Flash / Flex development: Ease of learning and time to market.

I’m not ready to throw in the towel yet, because I still see great potential in the future of Flash. However, I am concerned that Adobe is taking steps in a self-defeating direction. I hope I’m wrong.

Let’s start by emphasizing that the two frameworks share a number of strengths. Both of them provide conventions that, once learned, enable you to build complex applications faster. Both of them lend themselves (in varying degrees) to team development. Both of them promote some level of code reuse. Both of them help you make applications that are easy to maintain and extend. Both of them will enable you to build applications that any experienced Object-Oriented developer will be able to get up to speed on very quickly. Both of them give you complete control over event flows. (When using native Flex events, you need to be aware of bubbling, and whether there is any native Flex code that is also listening for the event you’re dispatching, but each of these frameworks addresses this issue - PureMVC implements a publish/subscribe system with its notifications, and Cairngorm uses CairngormEvent/CairngormEventDispatcher.)

Having looked at what the two frameworks have in common, let’s now take a look at what makes them different. Since we’re talking about Flex frameworks, I thought it would be fun to put the comparison matrix in an AdvancedDataGrid component:

You can open and interact with the matrix here. (Building it wasn’t as much fun as it should have been, but I’ll address that in a future post.)

I’m sure there’s much more that could be said, and I hope that you’ll add your thoughts to this discussion. If you don’t want to post your comments/questions here in the blog, feel free to contact me directly.

Kudos to Cliff, who had to do a tremendous amount of work to pull this off. I suspect that a lot of developers will benefit from the effort.

We now have a somewhat analogous situation in the Flash development world - especially those of us who have been working with the technology for several years. We all have old Flash assets lying around that are potentially useful, but they don’t have all of the functionality we need, and they can’t be imported into ActionScript 3 projects. So what do we do with them?

One answer is to use the LocalConnection class to enable these antiques to communicate with our current projects. With LocalConnection, any two (or more) SWFs running in the end user’s Flash player can send messages to each other regardless of what version the SWFs are compiled to or which version of ActionScript they use.

Suppose, for example, that you are asked to build an application that has a clickable U.S. map. When the user selects a state, a pie chart displays the relative amounts spent on various types of candy bar in that state. Flex Charting can take care of the pie chart pretty easily, but what about the map? Suppose you have an old interactive map built in Flash 5 laying around, and you want to use that rather than building a new one from scratch. Well, that is precisely what was done here:

This application uses a Flash 5 map of the U.S. loaded into a Flex 2.0 application. Just a few lines of LocalConnection code added to the version 5 FLA were sufficient to enable this perfectly useful old asset to communicate with its ActionScript 3 host. Apart from the developer, the only people who could tell the difference between this application and one built completely from scratch are the people who pay the bill - they could see it in the money they save.

As an aside, you’ll also notice that the Flex project included in this application illustrates a few interesting things in addition to the LocalConnection code:

• The use of a custom renderer component to build a custom legend
• Using a custom color palette with a Flex chart
• Using the interpolate effect to animate a pie chart
• An AS3 helper class to read, manipulate, and generate XML data

You can run the complete application here. When the application opens, right-click on it to view and download the source.

Note: The XML data file used for this application is a work of fiction. Any resemblance to actual sales figures or percentages, living or dead, is entirely coincidental.

Enjoy!

Now I need to tweak this blog’s CSS so that it coordinates with the look of the static site.

*UPDATE:

I’ve modified the blog’s css and added some links to the static site. It would look much better if I didn’t need to make adjustments in the layout to accommodate IE6. If you’re using IE, please switch to a really good browser now, before you forget about it again. If you don’t like Firefox, then try Opera. If you insist on using IE, and you’re still using an older version, please at least upgrade to the current version!

I’m particularly glad that Harris Reynolds will be speaking this year, and he has some pretty sweet topics: “Design Patterns and Architecture Frameworks” and “Highly Coordinated Visualizations using Charting.” I didn’t get to see him at 360Flex last year, so I’m really glad that his FlexManiacs sessions don’t conflict with mine.

What’s that you say? You detect an ulterior motive in this post? Well, OK, I’m excited to be speaking again this year, and I’m happy with my topics, too. Here’s what I’ll be doing…

Making Large Applications Manageable with Modules: Modules were pretty cool in Flex 2.0.1, but they’re even cooler in 3.0.

Introduction to ECMAScript for XML (E4X): There will be two versions of this - a lecture and a hands-on. E4X is amazing.

Building Accessibile Applications with Flex 3: This is important for everyone, but especially developers in the D.C. area.

I noticed that the abstracts haven’t been posted on the conference site yet, but you can see them by clicking here.

Come to the conference if you can make it. It looks like it will be a great use of your time - not to mention a lot of fun. Take a look at the conference site and I think you’ll agree. And you might want to think about registering soon, because the prices go up on Friday.

**UPDATE (02/01/08):

• The early-bird pricing has been extended two weeks, to February 15. The price difference is significant, so if you’re reasonably sure that you’re going to attend it’s worth registering now.

Unfortunately, I haven’t lined up Rails hosting as yet, so I don’t have an online demo to play with. However, you can download the source code here. Please let me know if you have any feedback (criticisms, suggestions, kudos, etc.). Most of the code is still uncommented, so feel free to ping me with any questions as well.

In addition to being my first significant Rails application, this is also my first use of the PureMVC framework. I will admit that this slowed me down much more than expected, as I had some trouble wrapping my mind around PureMVC. However, now that I’m starting to get the hang of it, I think I like it. I will have a better idea of how much I like it when I start adding functionality. I’ll be posting comments here as I build out the app, so stay tuned.

As it stands, the application has the basic required functionality: you can create, update, and delete index cards, and you can flip through the cards to study them. However, I plan to add (at bare minimum) the ability to study only one rubber band at a time. I also hope to add user management and login functionality so that there could be multiple users of the same instance, as well as different ways of studying with the index cards (multiple choice etc.).

Below is a list of resources that were instrumental in getting me to this point.

Rails:
Agile Web Development with Rails (of course) by Dave Thomas, David Heinemeier Hansson, et al
Rolling with Ruby on Rails Revisited by Bill Walton and Curt Hibbs
Integrating Flex 2 and Ruby on Rails by Derek Wischusen

PureMVC:
PureMVC Best Practices by Cliff Hall
Cafe Townsend demo by Michael Ramirez (This is an adaptation of the Cairngorm demo for PureMVC)