SourceBottle

One of the tools I have been appreciated over the past week or so is something called YSlow, a validator for Steve Sounders Rules for High Performance Websites, built as a plug-in for Firebug. It has got me thinking, thats all very well and good when we talk about mostly static web experiences, but how do they apply to rich internet applications, built using the likes of Flash or Flex.

Many of the performance rules such as consolidating CSS and JavaScript, moving CSS to the top of your document etc. are not really applicable in this case. Whereas some rules such as reducing the number of HTTP requests will always be relevant.

Lets have a look and see if we can produce our own set of performance tips specifically for RIA developers. All comments appreciated!

Performance Tips for Flash/Flex Rich Internet Applications

1. Make fewer HTTP requests in your containing HTML page.
   As the average browser can only make up to 6 concurrent HTTP requests out-of-the-box, it is important that your HTML page is optimized for this. As you will likely be using a JavaScript library such as SWFObject in order to embed your RIA, this functionality will not be executed until the page is loaded, meaning that the SWF file will likely be towards the end of the download queue. Thats fine, unless the browser is tied up with downloading other items... For the end user this means they will spend longer looking at an empty page, which is not a good experience.
   In order to solve for this, one should refer to the wisdom of YSlow.
   
2. Manage User Expectations.
   The likelihood is that your SWF file is going to be fairly heavy, and take a not-insignificant amount of time to download. This is especially true if you are using the Flex framework within your application. If this is the case, it is absolutely essential that you consider giving the user feedback that something is loading, and how long it is going to take. It prevents abandonment and makes the whole experience seem more responsive.
   Similarly, if at any point an application is required to go off and load more data, similar user feedback should be employed if the response is going to take more than a second.Some would argue that the use of preloaders is indicative of a slow application, that may be true, but a longer perceived load time and unresponsive UI are probably more indicative of a slow application!
   
3. Prioritize Dynamic Content.
   Its easy to get carried away when building applications, externally loading XML files, CSS files and background images so that pretty much every aspect of your application is configurable by external files, rather than a recompilation. Fantastic, except when we consider that all of these files need to be loaded before the application can even thing about rendering.
   Its worthwhile to make a list of all the data files and graphical assets which your application needs to load pre-render. Prioritize these based on how often each particular item is likely to be updated. Consider relocating some of these assets inside your SWF.Its nice to specify text styles using CSS or XML, but if no-one is likely to change it, then do you need it, especially since this could be relocated to an ActionScript class and potential shave a second or two off load time.
4. Consolidate External Data.
   Calls to external services are expensive, often with a round-trip response time of a second or so, and usually coupled with a second call to a crossdomain.xml file. These are a bottleneck, and there is nothing that can be done here. However, if you are making multiple calls, consider consolidating them by developing a server side component which can make both calls, merge the data and return the result. This reduces the client-side overhead, and lets you manipulate the results on the server side if necessary, making your application feel more responsive.
5. Load Cross Domain files up front.
   If a service call is inevitable, consider loading the crossdomain.xml file up front to avoid delaying your initial service requests.
6. Don't be afraid to cache data.
   If data is unlikely to go out of date, or if you want your UI to appear responsive, pre-populated with data, then why not cache data on the client? Data can be stored in a local shared object, and retrieved on the next load of the application. This creates the impression of a responsive UI and can save on HTTP requests.
   In the background, its important to set an expires property so that you can manage data refreshes, based on the lifetime of the data in question. Weather information may have a lifetime of an hour or so, whereas a user's profile information often has a lifetime of at least a few days.If data is secure then this method should not be used, unless in conjunction with encryption, as the shared object is accessible on the user's filesystem.

Thanks to everyone who came along to the SkillSwap on Wednesday - I hope you enjoyed it and learned something!

The slides are online and available for download (11Mb PDF), and if you have any questions, please post them in the comments or drop me an email.

In response to the person who asked "Is there any screen capture functionality within AIR?, I'm afraid at the moment the answer is no - its not in the roadmap for the 1.0 release as far as I can tell. However, if you just want to capture the AIR application itself, then it should be possible to save just that window as bitmap data using AS3.0.

If you are looking for screen-sharing options, then I would heartily recommend Adobe Acrobat Connect which is just great for presentations and/or collaborative working.

I will be presenting a session this coming Wednesday on AIR, at a Brighton SkillSwap event, talking building desktop experiences, specifically using Adobe's AIR. I will be covering the key features and functionality provided by the runtime, with specific examples of Flash/Flex and HTML based AIR applications. I'd also assume a trip to a drinking establishment would be in order for afterwards!

For more details, see the Upcoming Event Page

Some interesting news at the WWDC today - Apple is releasing Safari 3 for Windows XP/Vista, alongside OS X. In fact, you can now download a public beta.

What does this mean? In my opinion this changes everything.

For many years, web developers have focused on supporting a wide variety of browsers, but in practice, this has often been interpreted as supporting Internet Explorer and Mozilla/Firefox. Very few developers go out of the way to support Safari, for the simple fact that it has been limited to the Mac OS platform and it is used by likely only around 3-4% of user's, however this figure has been growing quite significantly in the past year. (Opera is another story, it accounts for around 0.2% of users and this never seems to change! Opera users also seem used to switching browsers in the event a site doens't work for them!).

Now, Safari has a chance to get into the mainstream, and this will force developers to pay attention to it. With Mac gaining market share, there was some additional pressure to support Safari, but now that it is becoming cross-platform, this becomes essential.

It also makes it easier for developers - the three major browser rendering engines; Trident (IE), Gecko (Firefox) and WebKit (Safari) are now easily available on Windows and Mac OS, leaving no excuse for lack of testing or consideration.

Do I see Safari gaining market share? It is a difficult one to judge - on one hand Firefox has been around for ages, and still see's only 15-20% usage on your average non-geek commercial website, on the other, Apple have twice as many people downloading iTunes downloads than Firefox on Windows - if they can use this as a launching platform then perhaps there is hope.

If nothing else, it will serve to give Microsoft and the Mozilla platform an incentive to focus on supporting web standards, alleviating any kind of development hell that may await; whilst at the same time, increasing developer awareness and ushering in a compatible, cross-platform, web, which can be enjoyed by anyone - wether the computer be white, brushed metal or beige!

Earlier this week, Google Gears was unveiled to the public, it represents Google's solution to the eternal problem - how do I make my web application's functionality available offline?Gears comprises of three components:

• A local web server, for storing HTML/Image/CSS/JavaScript assets locally.
• A local database server, for storing data used by web applications.
• A worker thread pool, allowing CPU intensive operations to be performed in the background.

All of this functionality is accessed by extensions to the JavaScript API which are enabled by a component which must be downloaded and installed. Currently Firefox is supported on Windows, OS X and Linux; along with Internet Explorer 6+ on Windows.

Whilst this is a nice idea, I have to say that I am skeptical about wether or not this is indeed the right way to go with regard to offline applications...

First of all, you have a dependancy on an external piece of software - one which at the moment has very limited market/user penetration. Sure, you will find web-savvy individuals likely to be running Gears, who can leverage your gears application, however the vast majority of your userbase will likely be oblivious to what Gear's is, or where to get it.

This can likely be addressed if Google decide to bundle Gears with some of their other products, such as Toolbar. In addition, developers themselves can use the promise of offline functionality to drive users to install Gears... but still, it is going to be a long time before Google Gears has the universal ubiquity of, say, the Flash Player (over 95% user penetration). Until Gear's reaches a similar level of ubiquity, its bound to be a hard choice as to wether to invest effort in developing an offline application which may not reach the majority of your user-base.

Other minor points here revolve around lack of browser support (in particular Safari, though Google are working on this), and the (likely) perpetual beta status of Gears.

The other main point I want to touch upon is simple - we talk about wanting our data offline, and that is fair enough, but is the browser the correct front-end for this?

Users have been conditioned to associate the browser with connectivity, and even though you can migrate applications to the desktop, you cannot migrate all the data - you will reach a point where you need to go online to download additional data. For example, your reading your email's in a Gears-enabled Google Mail and you click a hyperlink a friend is telling you to check out... 404 page not found. Although its obvious, it represents a massive downward dip in the user experience.

Also, many features which are great offline, are simply not relevant or workable in an offline application. Although many web applications let you perform a Google Maps lookup with a simple click, a lot of this functionality could never work offline - either due to the size of the dataset which would need to be stored locally, or due to the fact that the functionality is owned by a 3rd party and you have no control over wether it can be made available offline (and then you find out they are adding offline functionality, but building it around a platform like Morfik!).
Rather than looking to bring entire web sites to the desktop, we should look at what functionality user's actually want to access when they are offline. From there, developers can move on to deciding the appropriate means of user interaction and technology platform.

Looking towards either native applications or OS-Neutral platforms such as Apollo or Google Gadgets may be the right way to go. Appropriate functionality can be developed with ease (and if your using Apollo or Gadgets, using web development skills), and you have the capability to develop much richer and targeted features for desktop users.

Usually, one of the first development choices faced when building a web application is "What should I use to build it?".

Often, the choice of client side technology is often determined by what you are using on your web server - for example Ruby on Rails lends itself much more naturally to applications build using HTML, CSS and JavaScript, however there are always instances where HTML may not always cut it, and you may be better off looking towards more richer presentation technologies such as Flash in order to deliver your experience.In corporate environments, this choice may be even more complicated - on one side you may have programmers used to working with a certain set of technologies, and perhaps not knowledgeable about the capabilities of other options, on the other side you may have business partners or design agencies hooked on a certain platform because it allows them to use pretty transitions all over the place!

Anyone with some experience developing websites should realize two important things:

• You need to keep an open mind.In our industry, things change every day, and as a developer it is important to at least be aware of these changes - wether it be a new technology platform such as SilverLight, JavaFX or Apollo; or perhaps just a new way of using existing technologies to add value... things like Microformats, CSS Sprites etc. Shutting the door to a particular technology leads to stagnation, and could potentially mean overlooking a perfect solution to meeting business goals.
• You need to keep your wits about you.When keeping an open mind, it is often important to also be realistic. Don't be wow'ed by a new technology with a pretty demonstration page - pretty doesn't always mean usable! As web developers, it is our responsibility to deliver solutions to our clients, but it is also our responsibility to deliver effective solutions. This may mean making decisions based on usability, maintainability and other best practices, and it may mean challenging the requirements of a project. A project need should not be "This should be delivered using technology xxxxxxx". What is the underlying business need, and what is the best solution?

Technology choice is often one of the first decisions made in a project, and it has a direct impact on project success. One path may see a 20% increase in ROI, another may irritate your customers and result in lost sales. Its a tough call, but its essential that whatever you choose, you choose it for the right reasons.

Wow.... I can't believe it has been over a month since I posted here. It has been a hectic month, but I'll try not to let things go quite so quiet again.

I celebrated another birthday yesterday, and I'm slowly nursing off the hangover in front of the Eurovision Song Contest - a quality piece of entertainment!

I've been having a clear-out at home (anyone want some hawaiian shirts?). It is amazing as to the sheer volumes of junk which one seems to amass. Wether it be old birthday cards, clothes which you wore through some of the more memorable times or just random trinkets that you may have picked up on holiday or even just on a night out. Going through all of it brings feelings which you don't get when you are looking at the average website.

The web is a strange medium... pages age, especially the design elements used on them (I'd imagine gradient fills and rounded corners will be held with the same esteem as blink tags in 5-10 years time!). Yet, whilst designs become dated, the fidelity of the site itself does not change. There are no fingerprints, no coffee stains, scratches or signs of wear and tear. Color's stay strong and true, never fading. Its interesting to wonder, if these things were carried forth onto the Web, wether we would be looking at a better or worse user experience?

When I left school, we all signed messages on each others shirts - good wishes for the future. You may carve your name or a special message into items. These things have carried over into the digital world - in the form of discussion forums, guest-books and shoutboxes, albeit in perhaps a slightly more controlled and ordered fashion.

How can we bring together technology and lessons from the 'old world' in order to create more sophisticated and engaging experience? Any thoughts?

The website looked so real, with lots of attention to the details and completeness of the experiences. I totally fell for it! Nice one guys.

For a moment I did wonder about the availability of conference facilities and accommodation on the South Pole, but I brushed it off, because I thought heading somewhere exotic for a conference would actually be really cool. Part of the reason I enjoy attending industry conferences is for the inspiration, and what better place on earth to actually get inspired?

Perhaps the @media guys have unintentionally stumbled on a new cash cow.... extreme Web 2.0 conferences in exotic locations.... Now that would be fun!Its started this year, with @media expanding to cover three continents, Future of Web Apps also followed in the footsteps of Kate Winslet and became another successful British export to the USA. And, as much as I enjoyed the fact that I could just walk home after dConstruct and Flash on the Beach, a new exotic set of venues could refresh the creative juices. Plus, perhaps everyone would be too busy taking in their surroundings to notice the lack of female speakers!

As already posted, I have been over in San Francisco this weekend. The purpose of my trip? Well.. partly sightseeing but mainly for Adobe's ApolloCamp event - an evening dedicated to Apollo, Adobe's new desktop application platform. Here is a roundup of some of the secrets gleaned at the event!

For over 10 years now, Flash has become a ubiquitous standard on the web, installed on an estimated 750 million PC's. It is cross-platform, and cross-browser. More recently, it has made the jump to being cross-device, with the release of Flash Lite. But what if I want to take Flash outside the browser? With access to the local filesystem and windowing API's?

There have been several attempts at this, the most notable probably being Zinc, but most have their quirks and detractors - making it difficult to really take a complex Flash based application and deploy it to the desktop. Thats where Apollo comes in, providing a cross platform runtime for desktop applications which can either be Flash-based or HTML/JavaScript based.Currently supported platforms are Windows and Mac OS X, with Linux support being promised for the 1.0 release which is due towards the end of 2007.

Interestingly, it also appears that Adobe are interested in supporting mobile devices as Apollo moves toward 2.0, although developers shouldn't expect this to happen until later in 2008.

So, what kind of things can Apollo do? At the event we saw lots of demo's which were quite cool, including: Fine Tune, Dashboard Widgets, Widgets (in General), Twitter, E-Mail Clients, BuzzWord (Word Processing).

More tidbits as I continue my experimentation with Apollo....

I'm over in San Francisco at the moment, at the Adobe Apollo Camp event and for some St. Paddy's day celebrations - more in depth blogging on that after the hangover, but for now here are some of the more interesting tidbits gleaned so far...

• Apollo will be released on Adobe Labs at some point in the next week! This will be the alpha version which is already in the hands of Adobe Prerelease developers.
• Lydia.com will be hot on the heels of this with training videos for Apollo.
• Apollo will see a name change for trademark versions, the new name is apparently really cool!
• We should expect public release towards the end of 2007