This was the first real application that I had tried to build since the Beta 1 and of course there were some API changes - as can be expected between beta versions and a release - but more importantly the security restrictions in Ajax AIR applications make it almost unusable for certain use cases. At least for my HTML apps.

There are two main problems that I found exceedingly annoying and that ultimately led to the shelving of the project.

The first problem was that you cannot use innerHTML to insert HTML that contains event handler code such as <div onclick=”foo()”>Bar</div> when you are in the Application Sandbox. This is of course to prevent people from inserting malicious code on HTML events - which is equivalent to doing an eval if the user somehow triggers that event or the event is triggered manually through JavaScript.

That meant that I had to put most of my code in the Network Sandbox to get around the security restrictions. Fair enough I thought until Murphy reared his ugly head.

It just so happens that you cannot pass complex objects across the Sandbox bridge since they become of type “Object” on the other side. So for example I wanted to pass an XML document from the Network Sandbox where my application UI is residing into the Application Sandbox so that I can do some cross domain requests with it and / or save it to disk for use later when offline - essentially to do anything interesting it needs to be in the Application Sandbox. So to do this I had to write my own code to serialize and deserialize any custom objects that I wanted to pass around, essentially converting my XMLDocuments and so on to strings on one side and then loading them into XML documents again on the other. Pain. In. The. Arse.

A second, and maybe more important result of not being able to pass complex objects across the bridge is that it pretty much means that if you want your UI to be in the Network Sandbox you cannot do file drag and drop unless you have a special place that is in the Application Sandbox where the user can drop onto. This may not seem like such a big deal, however, it poses other problems with the UI layout since the best way to layout the UI in an HTML AIR app is to have the custom chrome in the Application sandbox using the CSS border-image (which is awesome) and then have the rest of the UI in a 100% width and 100% height IFrame with some margin to take into account the custom chrome edges. In that case there is not really any opportunity to have a special drop area in the Application Sandbox to accept dragged information from the desktop.

So to make a long story short, building AIR apps that use dynamic UI generation and some of the APIs that make AIR awesome, like drag and drop, means that HTML / Ajax AIR apps are simply not feasible due to the security restrictions.

if you want to learn about Ajax in a format that is bit more easily digestible than reading a boring book then be sure to pick up the Live Lessons where we step you through all the pitfalls of building an Enterprise Ajax application. Topics covered include a framework review, testing, security and usability.

Go get it!

Of most interest to me was the round table discussion about “what is an RIA?“. There were various opinions on this that I will not repeat here and let you read over on RedMonk.

What didn’t come through on the RedMonk review was what I thought, arrived at through the great discussion, was really the defining characteristic of Rich Internet Applications. In the end it was not about flashy graphics or animations. The one defining characteristic of an RIA is that there is no page refresh.

That’s it. That is all there is to RIA. If you have an application running over the network that does not have a page refresh then that is an RIA - be it using Flash, Ajax or a Java Applet. The discussion went back and forth until Jeremiah Stone from SAP finally talked some sense (afterwards we had a very interesting discussion and I really need to follow up with him) saying that good design is dependent on the context of the problem being solved. Now this is a really important idea since if you are used to working with a keyboard accessible green screen application, a visual mouse driven GUI will probably be far less usable. It is all context dependent. I may take longer to learn the green screen application but it will likely pay dividends in productivity down the road.

At any rate, long story short, the one common theme that people presented was that an RIA is defined by an application that has no page refresh, whether it is made for a user of a terminal or a new web 2.0 application.

I had my epiphany at the very end of the session and was pretty much lost on deaf ears of people who were about ready for a cold one (aside from Duane who was thoroughly liquored already ;)) . However, I felt somewhat vindicated when I was reading James’ post about the session when I noticed that there was a comment from David Mendels of Adobe, who was possibly responsible for defining the term while at Macromedia in the early 2000’s. Indeed David suggested that the original definition of an RIA was an application with no page refresh.

Based on that I think that the case of the meaning of RIA can be considered closed.

RIA == No page refresh

QED

It seems like in the early days of Web 1.0 people would do all they could to get away from the select box and use all sorts of fancy DHTML menus (remember dynamicdrive.com anyone?). However, these days we are seeing most applications that have drop down menus - while not using the HTML select element - are reverting back to the down arrow visual affordance.

For example, GMail, Zazzle, LinkedIn and Amazon are all using the down arrow on their drop down menus nowadays. This simplification of user interfaces becoming a common theme in the latest web based applications.

The question that I have is how many open source developers and evangelists out there that are building their applications on free and open source software like Linux, Apache and Ruby on Rails or that work for open source organizations like the Mozilla Foundation or that are evangelizing open standards like OpenID are going to get on board with the most open mobile device available? How many of them are going to trade in their fancy closed source IPhone - for which Apple has applied for more than 200 patents - for an Openmoko phone? I would wager that very few will.

I would expect that all open source proponents who refuse Microsoft software because of their closed, software patenting ways would likewise refuse a proprietary hardware device form Apple in favour of an open alternative and yet people are still probably more than happy to stick with their favourite pomaceous fruit designed in California.

So who swears by open source and is going to keep their IPhone or other smart phone?

The idea is that you take the analytics information from all the sites using Google Analytics and generate some benchmarking data by industry and apply it to your stats. That way people who use Google Analytics can see if they have an unusually high bounce rate compared to their peers or if they have a really low pages per visit stat. Right now when people look at their Google Analytics information - aside from their past experiences - they haven’t really got much to go on in terms of what a good bounce rate or pages per visit value might be. This way one can actually compare with others and then prioritize what needs to get fixed based on what is most out of whack compared to others in their industry.

In the case of Google Analytics, I think that this sort of feature could really change analytics from being a private sort of thing to becoming something that, dare I say, a social network could build around - who wouldn’t want to be featured on the Google Analytics homepage for having the best web stats?

I had this idea a while back and I think it can be applied to a lot of different industries outside of web analytics - sort of like PayScale is doing with salary reporting - but of course an idea is nothing unless you can execute

Hopefully we can apply the same sort of idea to RobotReplay in the future.

The most notable updates aside from various bug fixes are Firefox 3 support, a new and improved Calendar and Datepicker component, and JSF versions of all the components!

I am really excited to see what sort of adoption we get for the JSF versions of our components and I think that people will be pretty happy with the new and Calendar functionality.

Time to get back to work as it will probably be a pretty tireless last week and a half.

When everything was said and done, Yohei came out on top with a Papervision3D version of the Nitobi office! It was pretty damn cool and you can play with it below.

Alexei also showed his NitobiBug tool that is a cross-browser Ajax debugging tool similar to FireBug.

Thanks to everyone for coming out despite the amazing weather (which you can see out the windows of the model of the office below) and the opening of the new Vancouver Apple store

We will be having the next one some time in the fall I think.

If you use the Ontario Street bike route you must have a death wish. I think that Main Street - though you do have to be wary of door prizes in certain areas - is actually far safer for cyclists. I for one feel that rather than being segregated to the back of the bus, in the name of safety cyclists should be using the proper road ways, pissing of the car driving, climate changing commuters.

At any rate, one can see in the lovely animated gif, care of the Wikipedia article, that vehicles entering the roundabout yield to those already in the roundabout - be them cars, bikes or hover boards. What that means here in North America is that when entering the roundabout you give the right of way to those on the left unlike a regular stop sign.

Maybe we just need more magic roundabouts?