Article: When to use or not use RIA technology »
FERDY CHRISTANT - MAR 31, 2010 (11:10:42 AM)
At work we have been struggling with a specific question for a while now: When to use RIA technologies (Silverlight, Flash, etc) and when not to use them. It's a complex question and we approached it in a complex way. We made a comparison matrix comparing dozens of qualities of these technologies and the outcome was dissapointing. Instead of having a simple guideline the answer was "it depends". It depends on many factors really.
The reason why such an answer is dissapointing is that it does not help when you work in a very large organization and want to standardize your strategy and architecture. In my experience, any guideline or standard that you enforce has to be simple, not subject to interpretation or preference. And of course it has to make sense and be smart, so that the people following the standard feel like they are doing the right thing.
I was not satisfied with the "it depends" answer so I stepped away from it and let it sink in for a while. To make a long story short, I eventually concluded on a guideline that can be summarized as follow:
You should use RIA technology when the interaction requires it or when the audience expects it
This rule still leaves room for interpretation, so I will be using the rest of this article to discuss a few specific cases and how this rule applies to it.
First, our starting point
Before I do that, however, I first would like to address another consideration: our starting point. Why would we not always use RIA technology? There certainly are a few advantages to that approach:
- All applications and interactions will be rich
- Developing a rich application in RIA technology is much more productive than doing a similar thing in standard technology (DHTML)
- RIA applications tends to be pixel perfect, no browser quirks to deal with
Yet, there are also some important disadvantages:
- Users may not have your choice of RIA platform installed
- You will be locked into a vendor specific platform
- There is no guarantee for backwards-compatibility or your RIA platform surviving in the market
- There may be some addition technical disadvantages, such as bookmarking and broken back buttons that conflict with user's expectation of a web application
I'm a standards man, and the industry is on my side. I believe the future is in better web standards support, a neccessity because of the fragmentation of browsing devices. My starting point is therefore web standards, and to only add proprietary RIA technology where it adds value.
You should use RIA technology when the interaction requires it
This rule is best illustrated with a few examples. Here is a screenshot of my Flickr photo stream:
Photo viewing at the largest photo site in the world. Other than perhaps some light Ajax tricks (such as inline editing), there is nothing rich about this interface. No RIA technology is used. You will find this to be true for allmost all big sites (Yahoo, MSN, Digg, Facebook, Craigslist) and the majority of all smaller sites. Do you follow web design blogs that showcase the latest RIA tricks but wonder why on earth no real site or application is implementing them?
The answer is twofold:
- The interaction does not require it. You can browse and view photos, check on your online friends, read blogs and all those things without RIA technology because the interaction is simple and RIA technology will not add any value.
- Besides not adding any value for such interactions, RIA technology actually locks out users because of its proprietary nature. UI experts call this "reach". When it comes to reach vs rich, reach allways wins for simple interactions.
Now, let's have a look at that same Flickr site for a richter interaction:
Here I am editing one of my photos, like Photoshop in a web browser. This is an incredibly rich interaction for which RIA technology is not only justified, it is a neccessity. The target audience will also be smaller, as it only concerns signed in users that actually edit a photo in a web browser.
There are other examples of rich interactions in Flickr. Organizing your photos into sets using drag and drop for example. This would be possible, yet painful in standard technology. The interaction requires it. Sometimes RIAs can enrich basic interfaces too. You can upload a photo to Flickr using a class web upload form, but there is also a Flash-based multi file upload control and even a desktop RIA to upload files in batch. RIA technology provides a richer alternative here, a perfect mix of both rich and reach.
Which interactions require a RIA?
My claim is that RIA technology is justified when the interaction requires it. So which interactions require it? In short, all interactions where the usability of the application is improved by applying RIA technology. To make this more specific, here are a few examples that come to mind:
- Intense data administration. Applications that require a lot of data entry and maintenance benefit from RIA technology. These are the kind of applications that are not really suitable for the web anyway.
- Rich charting and other rich UI controls. Classic web technologies only offer limited input and visualization controls. An interactive chart with filtering and pivoting capabilities is probably best implemented using RIA technology. The same applies to a 3D product view control or a workflow process design control.
- Rich media, primarily video and games
- Offline usage
- Map technology
- Interactions that require some form of desktop integration
- Realtime systems
There are always border cases, specifically when an interaction is semi-rich and can be implemented in both classic and RIA technology. Normally, I then recommend to stick with standard technology. However, there is also a practical consideration to make. Have a look at the following Silverlight scheduler control:
This is a desktop-like experience for scheduling resources implemented in Silverlight. However, there is also an Ajax version:
Now, let us imagine that these 3rd party controls would not exist and we were to implement it from scratch. I can tell you that Ajax development for such a control is incredibly painful, error prone and expensive. The burden would be too large to go for classic web technologies in this case.
Yet another border case
Microsoft once visited us with a very slick Silverlight demo which involved a 3D web shop. Users could actually walk and navigate inside a virtual store and visit sections, have a look at products, and so on. An awesome technology showcase and of course many in the room were sold. I hate it when this happens.
The problem here is that this is RIA for the sake of RIA. Guess why no web shop in the world has implemented this? Because it hurts their sales. It is an interaction that looks impressive but is less usable than a normal web shop experience. The interaction is richer, but the bottom line is not.
It takes some industry experience and usability insight to distinguish between RIA adding value or a supplier simply selling RIA technology using a sexy demo. Generally, when a supplier uses the term "user engagement" you should conclude that he does not know a thing about users.
Why? Because user engagement is a myth in allmost any context. Users do not want to be engaged or be in a relationship with your app. Users want to get a task done and get on with their life. Your app means nothing to them, all they want is for the app to be simple, fast, usable, intuitive. It helps when your app looks good, but when you push this to the point where it hurts usability, you are on the wrong track. If you don't believe me, again, look at any major website or application out there.
A second example I would like to give is another recent demo I had the pleasure to attend. Upon making a filter decision in the application, a data grid rotated in 3D and then stopped into position. Next, it took 10 seconds for actual data to appear in the grid. And it gets better, it turns out users can click on some strange curvy arrow to flip the box in 3D once more and then on the "backside" choose some kind of sub filter. The application of RIA technology in this case clearly violates usability rule number one:
"Users spend most time on OTHER websites/applications"
In other words, do not break conventions and user expectations. Users want to get something done, not learn your application. Be wary of the "cool" factor, needless animations and eye candy.
You may get into heated debates about this. If so, take the emotional part out of it. Look at the bottom line. Measure usability statistics and conversions.
You should use RIA technology when the audience expects it
I have just made a clear point against RIA just for the sake of RIA. However, there are some exceptions to be made. In certain niche areas and audiences, RIA is expected and entirely appropriate even when not technically required. Think of a movie site, an online game or a site about a console game, the portfolio of a designer, a ringtone site for teenagers. These are experiences where users really are looking to be engaged and entertained. Most of the time, this concerns consumer services in the entertainment and media industry.
As simple as my original guidelines was...
You should use RIA technology when the interaction requires it or when the audience expects it
...as lengthy this article became. I hope the examples explained my thinking, in that RIA should be applied where it truly adds value. Value should primarily be added to your user and your bottom line. Be wary of the "coolness" factor and the tension it creates between suppliers, decision makers and you. Have a look at what other websites and applications are doing. In the end, nothing beats common sense and real world figures.
The future of RIA
There are some interesting developments going on in the web and RIA technology area:
- It is expected that within the next few years, the majority of the user population will access your site or application from a mobile device. These devices are not standardized and there is no guarantee that your RIA platform is even available.
If the above is to become true, proprietary RIA technology is in for a lot of trouble and might be reduced to niche usage. I have always been in the web standards camp so I actually hope this is how it will plan out.
This is a highly opiniated piece on technology decisions, therefore I greatly appreciate your feedback. Please do rate and comment below.