14 Nov 2007

SWFAddress 2.0 part 2 - Why it matters

SWFAddress 2.0 wasn't initially planned. Back in February I started adding improvements with version 1.2 in mind. Little by little the number of features and samples increased a lot and now we can really talk about a major release. I want to thank everyone who contributed ideas, requests, bug reports and comments.

One of the first and main goals was the support for event listeners. Since SWFAddress is a class that provides only static methods, the addition of the EventDispatcher capabilities was a little bit tricky. I've used composition over inheritance in order to create a unified interface for both AS2 and AS3 while utilizing the built-in Flash event classes internally. A new dedicated SWFAddressEvent class now carries information about the SWFAddress value, path and query parameters. All this wasn't implemented for AS1 and projects utilizing this version will still have to rely only on the SWFAddreess.onChange handler. More important is that the event dispatching feature is fully available in JavaScript which opens a lot of opportunities for websites that use Flash only partially.

As most of the SWFAddress users already know, the combination of ExternalInterface and getURL causes big troubles for both IE 6 and 7. We don't know the reason for this behavior, but since things like popup or new windows, email and PDF links are something absolutely normal, I've decided to ease the designer's life by providing two helper methods for dealing with such cases. The first one is SWFAddress.href(url, target) which can be used for any type of links and protocols, and the second is SWFAddress.popup(url, name, options, handler) which on the other hand can be used for popup windows. Additionally the built-in browser methods for history manipulations (back, forward, go) are also exposed to SWFAddress.

The automatic Google Analytics tracking that came out with SWFAddress 1.1 was well accepted, but sometimes when custom behavior is needed you may want to do it completely on your own. Initially I've added a method that disables the tracking, but with the recent news about the upcoming improved Analytics version this was changed. With SWFAddress 2.0 you can provide your custom tracking function and do whatever you want inside of it. The default value is still 'urchinTracker', but you can set it to 'null' if you want to disable the tracking, you can bind it to another tracking system or take advantage of the multiple trackers that the new Google Analytics will support.

Something that might not get very popular, but still interesting is that you can now disable the creation of history entries. This means that SWFAddress will still produce deep links, but the Back/Forward buttons won't work in the context of your website or application.

SWFAddress 1.x wasn't restrictive at all about the format of the deep links which resulted in a variety of naming conventions. While I understand everyone's preferences I want to push the usage of the right convention with the introduction of a strict mode. This means that by default you will get slashes in the beginning and at the end of the deep link value. If you use SWFAddress.setValue('/about') in the change handler you will get '/about/', if you set the value to 'portfolio?id=3' you will later receive '/portfolio/?id=3'. The most important change in terms of backwards compatibility is the fact that SWFAddress.setValue('') now becomes SWFAddress.setValue('/') which looks much more correct. People who want to apply the latest JavaScript improvements to existing projects can disable the strict mode and later in this post you will see how this can be done easily. Once again I want to mention that a good convention will ease any future developments regarding search engine optimization. If you use values like 'myDeepLink' or 'my_deep_link', Google won't threat them as three separate words. The best possible naming for the moment is 'my-deep-link' and if you do some investigation on this topic you'll understand what I'm taking about.

An interesting new feature is the ability to customize the script with query parameters. I haven't seen this technique before, but since I believe that less code is better I spent some time implementing it. The initialization of SWFAddress happens after the DOM of the page is loaded and it's easy to detect if there are configuration options applied. For example, if you want to use the new JavaScript file with an existing project that you don't want to recompile you can just include 'swfaddress.js?strict=0' in order to disable the new strict mode. The list of supported options includes only properties that should be set once, like 'strict', 'history', 'tracker' and 'html'. Since the swfaddress.html is now optional and disabled by default, you can enable it and disable the tracking at the same time by using 'swfaddress.js?html=true&tracker=null'.

With SWFAddress 2.0 you will no longer be limited to a single Flash object. Initially the project was targeting full Flash websites, but the reality shows that there are lots of interesting cases where multiple SWF files can utilize deep linking simultaneously.

So far so good, but there also many new things regarding the SWFAddress samples. All the SWFAddress 1.x Flash based samples no longer use strange arrays and calculated frame numbers. The logic now is much simplified and relies on frame labels. Additionally there's a detection that can point the user to a 404 error page when the requested deep link is not found. The SWF files are intentionally larger, so that the streaming can be tested and fixed in Internet Explorer. The MTASC sample is updated with different usages of the new link, popup and history helpers. The SEO sample was cleaned up and now it provides a better separation between the content and the presentation.

One of the key features of SWFAddress is the ability the work automatically with the Flash embedding script, which in most of the cases is my favorite SWFObject. Although it was always possible to use SWFAddress with other embedding approaches, now SWFAddress 2.0 adds the same out of the box transparent support for SWFObject 2.0, UFO and the Adobe's Active Content embedding script. Basically we want to cover every possible case and user preference and even that SWFObject 2.0 is still in beta testing, we're very happy to be compatible with it. Of course, there are dedicated samples for each scenario coming up on Friday.

Some of you might be exited that SWFAddress 2.0 also supports Flash Player 7. A few months ago I was asked by a client about such compatibility and the time good for implementing it. So there is a new IntKit sample coming which utilizes the Geoff Stearns' modified version of the Flash/JavaScript Integration Kit.

I'm happy to announce that I received valuable support from Jon MacDonald and Petyo Ivanov. Jon helped me with the documentation and contributed a lot to the new Flash CS3 sample which utilizes ActionScript 3.0 and SWFObject 2.0. My friend Petyo from the Bulgarian Flash community created a Ruby on Rails port of the new SEO sample, which can be a good base for any Rails hacker who want to build an indexable Flash or Ajax powered website.

SWFAddress 2.0 will come with an API reference available in multiple languages. Although it's not very extensive for the moment, it's a step in the right direction and we'll continue to improve it in the future.

Tomorrow I will write down some information about the new Ajax and SEO enhancements.


13 Nov 2007

SWFAddress 2.0 part 1 - The story so far

The time for a new release has come and this is the first of a series of posts in which I'm going to share with you what the project has achieved so far and what new it has to offer.

The initial SWFAddress 1.0RC release came out about an year ago and quickly got attention because of its simple message:

  • Built for Flash. Until then people were trying to achieve the same functionality using libraries with JavaScript roots.
  • Seamless integration with SWFObject. It was a nice addition for the de-facto Flash embedding standard.
  • Simple API for every ActionScript version. The combination of Flash, Flex and MTASC samples was good enough for everyone.

The next releases just made the project more mature and feature rich. Thanks to the growing interest in deep linking and browser history handling, little by little SWFAddress became just better and better. The statistics system on shows that the project has active forums and has been downloaded more than 20,000 times. Some people even used and deployed the SVN copy of the files, bringing the latest improvements and fixes to their clients.

Speaking of clients, I can say that we're pretty happy with our SWFAddress Services. We still cannot make our living completely out of them, but they appear to be good way of making some money with open source. Most of the time we are hired by designers or small interactive studios that don't have the time or resources to learn and implement deep linking. The big agencies have a lot of talent and usually they build SWFAddress powered content on their own, but the lack of extensive know-how in this area sometimes leads to bad practices.

Today we reveal the SWFAddress Showcase which clearly demonstrates that the deep linking is here to stay. We're glad that there are lots of high profile and award winning websites using SWFAddress and we will continue to work hard and bring you the best possible solution for your needs. It's also great and very important that many people are researching and sharing their work. SWFAddress wouldn't be the same if there weren't projects like Really Simple History, HistoryKeeper, StateManager and many others that deserve your attention and our respect.

Tomorrow I will give an overview of all the new Flash related features and samples. Stay tuned.

2 Nov 2007

SWFAddress 2.0 is coming

After numerous postponements the release date of SWFAddress 2.0 has been scheduled for November 16th. There are lots of new things coming and if you want to learn more just follow this thread.

25 Aug 2007

Moviestar - what happened to SWFAddress?

The latest Flash Player Beta release is great: H.264 support, hardware acceleration, immediate Linux availability. I thought that currently I don't have the time to test the new features, but a little bit later I was warned that SWFAddress does not work with this update. While this is something which can be expected from a Beta version I felt obliged to investigate what is the reason behind this failure.

The release notes of the Moviestar update say that the ExternalInterface has been improved and this sounded like a potential reason for my SWFAddress troubles. Yesterday I found some time for experimenting which led me to the following:

So it appeared that there is only a problem with AVM1 and ExternalInterface. After some more testing I came to the conclusion that:

Basically simple function work, but object methods no longer can be called. I suspect that this is not a desired behavior and I've created a test case which is available for download. The bug is now also submitted to Adobe and you should do the same if you find any other issues with your existing content.

Update: Everything is back to normal with the Flash Player 9.0.64 release. Thanks to everybody involved in this quick fix!

18 May 2007

SWFAddress bad practices

As the number of SWFAddress powered sites grows I often see problems caused by poor implementations or lack of information. Here is a list of the top 5 practices which should be avoided:

Usage of getURL() for user tracking, statistics and popups
While this is a standard Flash functionality used for years, the combination with ExternalInterface introduces a critical bug with Internet Explorer. The resolution is to use ExternalInterface for every JavaScript call. SWFAddress 2.0 will help you with some predefined methods for popups and blank window links.
Homepage address values like '#Home' or '#/root'
Such address values are not needed and should be replaced by SWFAddress.setValue('/'). The usage of creates an unneeded history entry when is opened.
Address values naming using camelCase or other forms of custom convention
SWFAddress samples clearly define the best naming convention for deep links. Web addresses are case insensitive and the standard is lower case. For readability and Google SEO compatibility reasons the convention 'my-deep-link' is more appropriate than 'myDeepLink' or 'My_deep_link'. The format is the only one fully compatible with the SWFAddress SEO rewriting.
Including SWFAddress before the TITLE tag
SWFAddress contains a fix for Internet Explorer and URLs which contain anchors. In order to benefit from it the title tag should be printed before the swfaddress.js include.
Duplication of navigation logic

Integration of SWFAddress into a legacy code may require the following implementation:

For brand new projects, the best way to organize your code looks like this:

Update: The post has been updated for SWFAddress 2.0.

« Previous Entries | Next Entries »



Blog Search

Blog Categories

Blog posts

Recommended sites