However, going through some of the sites raised a common issue, and that issue is one of userability.

History

As someone in the comments noted, History repeats itself. Looking back to the early days of gratuitous .gif animations, unusable Flash websites, and then to the more recent AJAX revolution of Web2.0. Whenever something innovative comes forward, people struggle to find “proper” use for it, and instead end up throwing it all at the user in the hope that they will be “shocked and awed” by it. Perhaps, in the Dark Ages of Web1.0, this strategy would have worked (and it did, for a time). However, people on the internet are now tech-savvy: they want their stuff, and they know how to get it. To prevent them from doing so in any way would be a death-sentence to any website.

And yet even now, designers (and developers too) fall into the same trap of fancy (and I dare say artistic-wannabe) sites, but poor userability. So lets look at a few examples.

Case Study: Officinanessuno

A simple use of Papervision3D. The site itself is mainly 2 dimensional, but its navigation utilises Papervision3D. Unfortunately, this exposes the biggest flaw of this site. It is nearly impossible to navigate!

A screenshot. Notice how the designers decided that humans had the ability to turn their necks 90 degrees without trouble. Also note that items that are further to the back have less visibility: the designers have inadvertently reduced the amount of traffic to that particular section! So not only is it already hard to read a link, you can’t see all of them.

Luckily, there is a “Quick Navigation” button, but you shouldn’t ever need it.

Rule #1 : Navigation must be be a smooth experience.

If you look at the rule on its own, it seems to make sense. If navigation was such a pain, chances are you’ll get irritated that you had to put in that extra bit of effort whenever you had to transition to another part of a site. Navigation should require little effort on the user. You want to facilitate movement around your site, not lock them down at the front page!

Case Study: Varywell

Not one of the 16 sites in the gallery, but a good example nevertheless.

Personally, I like this site. It is minimalistic, without the clutter of information that might put some people off. There’s just 1 little niggle: its too bare. Look at this link.

Could you tell that was a Link? Perhaps. Now, where does that Link take you? A quick rollover will tell you:

Ah, so that’s what I’m looking at. But what about the other boxes?

Hopefully you, the reader, will understand the issue I’m highlighting here, which brings me to Rule #2.

Rule #2 : Links must be visible, and users must know what they do.

Rollover ToolTips are unforgivable, and this has to be the Number 1 userability trap common to many sites. Why should I, the User, be forced to work harder whenever I want to get information? Information should be freely and easily available, while Navigation facilitates the User’s movement through various parts of information. This is ESPECIALLY important for Portfolios. Imagine a potential user viewing your site, and wants to refer a particular work to his friend. How does he do it? If you’re using Flash, he cannot send a URL. If you had Rollover ToolTips? Now he can’t even give his superiors a proper link. (”Just click that 4th blue box from the left. You have to press the Right Cursor key 2 times. If you rollover it you will see ‘This Title’.”)

All is not lost for this site, however, for there is actually an effective use of Papervision3D in this site. One that enhances the feel and experience of the site, without reducing userability.

It is also worth noting that this feature is not linked to Navigation in any way. Which should be a big hint as to which section of a site you should and should not touch.

Final Case Study: Truth in Engineering (Audi)

This site’s navigation suffers from the same problems above, and this case simply highlights just how bad it can get, although it is my belief that the people who designed this mini-site probably went the route of “shock-and-awe” and decided that userability wasn’t a big deal.

Here we see infringements on both rules. Firstly, Navigation is not smooth. Sure, the effects, and the movements are cool, but the depth-of-field effect obscures the labels at the back (Problem #1), making them hard to read. The easiest way to read the labels without going crosseyed is to rollover the link (Problem #2). However, even that is not without its worries.

Here we see what happens when you rollover a link. It EXPANDS (Problem #3). One of the biggest no-nos ever. The first reason is that expanding Symbols usually have a sweet spot which causes the Symbol to “spaz-out”; repeatedly and rapidly expand and contract. Not very pretty. This site does not suffer severely from it, thankfully.

The next problem is that when something expands, the chance of something being obscured from view is very high. From the screenshot, you can see that links at the back are obscured from view. Not only that, upon rollover, all other links CONTRACT (Problem #4). Where is the logic in that? Not only have you covered links, you’ve made it harder for people to see other links. When I’m using a site for the first time, and I’m faced with blurred out links that I had to rollover to figure out what they did, and the site does this to me? I leave.

Conclusion

As previously noted, History Repeats Itself. Despite poor starts by most innovative products, many will eventually learn to do without, or master it and produce something of great value for us all. Hopefully it will be the latter which will push us closer towards true Web2.0. In the case of Papervision3D, a truely great framework that pushes new boundaries in Flash, it should be used only where it is appropriate. A great 3 dimensional User Interface is a worthy goal, but without taking note of the fundamental flaws in design that others have made, we will fail to make progress in the future.

Thus, I hope those who read this article will benefit from my observations thus far, and make their own observations as to what works and what doesn’t.

Comments are, as always, welcome.

Then you can put talking animals in your blog, your mySpace, like you see below.

Give it a whirl!

Experiment Focus:

• flash.geom.Point;
• Line of Sight

View Experiment

So be sure to go over for a look at how you can start developing in Actionscript 3.0 for less than a penny.

I write this article because it seems to me that quite a few people still have no idea how to duplicate external assets (such as duplicating MovieClips, for example). Thus, I decided to take this opportunity despite there being quite a few articles that document this. If I haven’t bored your by now, read on!

First, Some History

Assets in Flash are normally quite coupled with the SWF. This is probably a result of the long years of timeline scripting that has been burnt into our memories. In Actionscript 2.0, however, the process of abstracting Assets from Actionscript was slightly alleviated through the copious use of duplicateMovieClip(). I too, used to be an avid user of duplicateMovieClip(), until I made the transition to Actionscript 3.0, But before then, duplicateMovieClip() was my quick and dirty solution to many situations I came across in Flash.

Abstracting Assets from Actionscript in Actionscipt 2.0 was relatively simple. One need only separate his/her assets into separate swf files, and simply loadClip() them into the SWF, and employ the use of duplicateMovieClip(). In Actionscript 3.0, however, this situation has changed as Adobe saw fit to remove (or shall we say, omit) the duplicateMovieClip() method.

Now, Adobe recommends the use of the “new” keyword to instantiate multiple instances of a Class. From the Actionscript 2.0 Migration reference:

In ActionScript 3.0, use the new operator to create a new instance.

This doesn’t really help us abstract our Assets from Actionscript. Most of us who have played around enough in Actionscript 3.0 would know that this requires that the Class be part of the SWF calling it, and in facts forces us to embed our assets within the SWF. Using the Loader class to import external SWFs does not expose any classes that we may use to invoke the “new” operation. At least, not obviously, as we shall see later.

Asset Libraries

Today we will go through a step-by-step process on how to create an Asset Library. Note, of course, that this isn’t the only way to handle External Assets, but this is the way I like to do it.

Creating an Asset

First things first, we create an Asset. This can be anything from a Shape to a Sprite.

At this point you need to note the “Class” field. This field is important as it is how you will be referencing this class externally.

Next, click OK, and ignore the prompt that pops up when you do. Now, you may export your SWF (Lets call it “circle.swf”). Once that is done, start another SWF, which is where we will try to load our external Asset.

Loading an Asset

Now we get to the nitty gritty of it all. First we need to create some code that will load our Circle, so that we can duplicate it. Let us create an event handler too, to handle Event.COMPLETE.

Above you see some code for loading external SWFs using the Loader class. So now what we are going to do is use what is called the ApplicationDomain to get the class definitions from within Circle.swf!

Lets explain what we did there. We accessed the ApplicationDomain of the SWF we loaded, and then we got the definition of the Class we wanted, in this case the Circle class we did in the first SWF. Note that the name of the definition has to be exactly the same.

Now let us compile, and see what we get!

Closing
Using this technique, it is simple to create a library of assets, that you can load into your main SWF and duplicate them! While this isn’t the only technique, nor the only method of utilising the ApplicationDomain, this is (in my humble opinion) the best way to go about Abstracting Assets from Actionscript.

Links
Here are some links if you want more information, as well as a zip of source code so that you may look at the code directly.

http://blogs.adobe.com/rgonzalez/2006/06/applicationdomain.html
http://livedocs.adobe.com/flex/2/langref/flash/system/ApplicationDomain.html
Asset Libraries Tutorial Files

Very excited (first convention I’m attending) so anyway, be sure to RSVP at their site if you are interested as well else you’ll miss out!

Note: don’t ask me how old my country is. I am pretty sure it is 42, but don’t expect me to actually get this sort of things right.

Again, of course, the library is still currently in Beta status. So it is probably not perfect. However these are the kind of things I’m hoping they will iron out as time goes along.

Unfortunately, I can’t seem to grasp 3D Rendering techniques, and I won’t be making my own engine anytime soon! There goes my Rubik’s Cube idea…

Some people really need a life… No I don’t need a new ToyAta or a Lexus give me a break!