Tonight, I found via twitter a deck from Plaxo’s Joseph Smarr. In this deck he talks about the war injuries he received in heading down the AJAX route. It’s a great deck and worth checking out but what I liked the most about it, was that it reminded me of my struggle back in 2002 as a web start-up.

This is a story of how I made my first start-up work using RIA, but at the time didn’t know what RIA was or heard of it and it was also the reason I took up Flash over DHTML – aka AJAX.

I’ve got an idea, let’s build..

myapp

In 2002, both the Managing Director and I left the company we worked for and made a go of it with our own start-up. We had little or no money to begin with and our grand vision at the time was to build a CMS (Content Management System) that focused purely on user experience. As in those days, UX was something that most product teams would simply echo the following fatal words – “don’t spend too much time on the UI, function is more important” and thus you’d see some really scary CMS. So scary, that we believed that the CMS features weren’t the differentiator, but the user experience was (how funny life turns out).

We however, believed back then that UX was not only important but would separate us from the pack and with this vision; we set out to make our millions. I took Coldfusion and Flash 5 and decided to build out this CMS in a way that I felt was not only unique, but had elements that I’ve always wanted in a CMS but never found. The UX was simple, keep the graphics in a more “pixel art” form, steal as many ideas as I could from Apple in terms of their user interface guidelines and ensure that any mum or dad could use it – whilst providing areas of complexity for those whom wish to venture out of the ui sandbox.

screen1

I made use of DHTML (AJAX to the new comers to this space) and it was quite a bold step, as you see Internet Explorer at the time was probably the only realistic browser that made use of XmlHttpRequest. I chose to use XmlHttpRequest at the time simply because Flash 5 had imitated capabilities and I remember seeing Erik’s WebOS.com many years before (it’s by far the best AJAX/DHTML creation I’ve ever seen to date – incidentally Erik now works for Google - ie Google Gears). I wanted to take elements of Erik’s gratuitous but elegant use of DHTML talking to server-side and also apply them to my CMS and it was pretty much what we’d call “RIA” today (only there wasn’t a buzz term for it back then).

I chose to head down this path, as well, that was the technology at the time and it’s all I had to work with.

User Experience took a lot of trickery to get working...

The vision of focusing on UX was sound. We found some success with the early stuff I wrote & designed in the previous versions. As this is what we felt helped sell the first version of the CMS (as it had really weak features).

What we needed though was the ability to minimise the end users need to refresh and provide instant feedback as they interacted with the web application. In order to fulfil this I’d make use of a lot of iframe and XmlHttpRequest trickery, in that I’d write a Coldfusion wrapper which basically encased an iframe tag with server-side generated attributes. Then using XmlHttpRequest I’d ask the server to give me back the iframe in html packets, which using the Internet Explorer DOM API inject back into the interface – so yes, in 2002 I was using “AJAX” and didn’t think anything of it, as well Erik did it and it was a normal thing to be seen.

SEP-SM-SC1

I first showed this approach working in what I’d call the “Publish Wizard”. The Publish Wizard was a feature within the CMS that allowed the end user to publish pages they had in draft form into real life static html pages (only with a .cfm extension to ensure parts of dynamic were in place). We chose to build out the pages in static form as back then search engines preferred static instead of blah.cfm?ver=1 style url’s (aka we wanted friendly urls).

The previous version of this feature I built used to basically generate the dynamic to static files in a way that was really bad for the end user. In that the end user would stare at a “Publishing..” text on a blank screen and wait for untold minutes until the process finished (we once had a government department that had 20,000 pages at one stage – so imagine that wait).

seifacedemo_v2

I wanted to improve on this, so I made use of the iframe / XmlHttpRequest idea’s I found in Erik’s work. I instead figured that Coldfusion needed to “thread” its processes as I found that if I could write 5 pages in one batch, it would give me 5 times the speed. The problem however still remained, in that the end user was staring at the dreaded “Publishing..” text. I decided to tackle this head-on, and decided that I needed a way to show progress but with a degree of accuracy as to show inaccurate progress would result in more human error (i.e. I also forgot to mention that users would assume it stalled and hit refresh, thus incomplete publishing and bugs would occur).

I found that if I were to create 5 iframes hidden, and using JavaScript I would update each of the iframe URL’s with a pageID to be published. Coldfusion would do its job and write out the dynamic pages to HTML and when finished would update a flag in their respective database rows. That worked, but what I really wanted to do was obviously show the visual progress being adjusted. The way I did this was using XmlHttpRequest I’d ask the server “what’s published so far” and it would return a percentage complete JavaScript object (yes, I was even using a quasi XmlHttpRequest JSON style solution).

The end result was that the user was seeing progress bar updates as each batch of 5 were being published. I thought this was brilliant and how great was DHTML!

The browser started to die, people were afraid.

The Publish Wizard worked a treat and the rest of the UI flowed in similar fashion, in that I’d find ways to ping/pong the server and use the iframe / XmlHttpRequest approach to minimise page refreshes. However, cracks began to immerge as once I started adding more and more of this technique to the UI, the memory started to climb.

Internet Explorer had memory issues (garbage collection) and I cursed its existence – it let me down!. Yet little did I know that it was actually my fault, as I wasn’t disposing of my variables after use and I’d cache way too many getElementById() results inside JavaScript.

screen2

It was too late in the end to recover, as by this stage we were roughly 1 year in and I was mentally exhausted from being a lone coder, designer and architect in one. I needed a break and I had lost the passion as well as the vision. The thought of turning back and re-writing a year’s worth of work was too much, and so we looked at exit strategies quickly. We made a fair bit of money and so it wasn’t a total loss.

The lessons learnt, AJAX can be an evil cretin at times.

I mention all of the above, as I see the same formula apply day in day out with Web Start-ups whom preach at me around why AJAX is by far superior to Flash or Silverlight runtimes. I simply sigh when I hear them, as I could argue the point with these folks further or I could simply let them be and hope they find a better way around the pitfalls associated with AJAX.

It’s relatively simple folks, the browser in a nutshell was never really meant to be pushed and poked into the way it’s been used today. We see great uses of AJAX daily whilst other times we see terrible, painfully poor uses of it. It’s a technique that should be used only when absolutely necessary and I state this simply from experience. Experience in not just building with it many years ago, but also watching others preach the AJAX gospel only to see them a year later hit what I call the browser barrier (similar to Moore’s law in terms of the thermal barrier).

It happens regularly; a web application starts out great, strong and really exciting in its use of AJAX. Yet as more and more features are added, suddenly the weight of the browser begins to fail and one or two pieces of the UI stall. Then another 2 and before you know it, you’re debugging JavaScript and Server-side code trying to figure out which part of the transaction is the one at fault – did I put a try/catch behind that ..Or is the event bubbling right? Etc..

A Runtime is the only way to fly


This is where Runtimes such as Silverlight or Flash play a strong role in today’s web application(s). It’s the right tool for the right job and to hide behind “I don’t want plug-in to be installed” is no longer a fair argument. It’s now a necessity to have both runtimes going forward as to do so will help shift this web 2.0 culture hells bent on using 100% Ajax applications into a different realm of user experience.

The reason why, is simple – the runtimes are mostly goaled on one thing. Make sure you don’t make your users wait and above all else, make sure you don’t make your developers wait either. Browsers on the other hand have to tread much more carefully as in the end they have to treat the web in many ways as either an application or a document. Runtimes simply treat the web as an application or animation, different rules apply and different calibre of developers & designers also.

The simple ability to accurately predict when a data stream is likely to finish download is by far the most basic and simplistic feature within a runtime, yet the browser cannot give you this data with as much degree of accuracy.

Plaxo found out the hard way, you don’t have to

I see Joseph of Plaxo’s deck and I think to myself that was me in 2002 and will this madness ever end? (Note: Joseph did an exceptional job and this by no means taking anything away from him in that regard - it's more a broader question).

Give the RIA idea a shot, pick up Silverlight and take it for a test spin, see what it can do to mitigate the pain ahead. Use both Silverlight and HTML together and yes, mix it up with some AJAX if you like, but consider moving away from a 100% AJAX driven solution as it’s not necessary in tomorrow’s web application. Remove the idea that search engine friendly RIA’s are a stumbling block and instead build in your own way of ensuring users can find information in a contextual way that suites your product. Leverage Live.com cloud’s API or Macros to help you achieve this as in the end separation of your content from your RIA is probably where you need to focus your energy the most.

Deep linking is simply a fool’s errand. Think of an alternative approach to that problem, and think of it at the start of your product’s architecture as it’s something you shouldn’t put off until after v1.

I’ve been mixing Flash, Silverlight, Flex, AJAX, HTML, Coldfusion, ASP.NET, PHP, Java and XUL together for many years trying to find an ideal way to build RIA. The end result overall was simply that I tried to hand roll too much of the workload myself whilst relying on the browser to do most of the work. Instead focus on ensuring your UX Platform scales in terms of performance and can talk back and forth between the servers.

I think Silverlight is going to be the better bet out of all that I've tried, and I state my job on it (heh)

Well done to Joseph for sharing his learning(s) around AJAX. I think it’s a great deck and special thank you to Ashley of Faraday Media for pinging me with this URL via twitter.