Following on from Barcamp a few weeks ago, I have finally gotten around to tidying up my slides, so here they are in all their glory..

• High Performance RIA’s (3.5mb PDF)

As the title suggests, I presented on various performance tips for developing Rich Internet Applications, which I have blogged about here previously. The session itself seemed to go quite well, with some good audience participation and feedback - I would definitely recommend the whole barcamp experience, it was a fantastic weekend.

(more…)

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.

(more…)

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.

(more…)