administration mode
Pssst...Ferdy is the creator of JungleDragon, an awesome wildlife community. Visit JungleDragon

 

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

Border cases

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:

http://demos.telerik.com/silverlight/#Scheduler/FirstLook

This is a desktop-like experience for scheduling resources implemented in Silverlight. However, there is also an Ajax version:

http://demos.telerik.com/aspnet-ajax/scheduler/examples/outlook2007/defaultcs.aspx

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.

Summary

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.
  • Powerful forces like Google and Apple are pushing forward web standards like HTML5, CSS3, faster Javascript and DOM2. Even Microsoft is getting on board with IE9. In a few years, it is likely that these standards are commoditized and available across pretty much all browsing devices. This will move web standards technology into the realm of RIA, that is, if their design tools are improved.

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.

Share |

Comments: 8
Reviews: 2
Average rating: rating
Highest rating: 4
Lowest rating: 4

COMMENT: MARK BARTON emailhomepagerating

MAR 31, 2010 - 12:42:06 PM

comment » Great article Ferdy.

As a keen Flex convert I have often had to face this decision tree in the past. At my old company I helped to define the RIA strategy so we faced exactly the same questions.

I think the decision is between an RIA and some form of DHTML framework + Serverside Langauge, unless your web application comprise of static HTML pages + AJAX calls for data. The serverside language can then play a large part in the decision process and of course mitgates your comments about standards.

Having a self contained component which can run on any web server which gets / puts data via standard calls (SOAP, JSON, Remote Object) ok maybe not the last one ;-) can be very compelling. A bit like a Notes database is self contained.

An enterprise can of course remove some of the reach issues and I feel the case for the use of RIAs is much stronger for enterprises anyway as they generally would produce more datacentric, complex applications which are a better fit.

I agree about the effects / animation overuse - its hard for new developers who never had access to these things before, remember when mainframe programmers found when they started to play / develop in Notes that they could change the form background colour!! 01 - so many bright yellow response documents

Still when IT people are first shown the effects / animations that are possible in RIAs & DHTML apps there first response is - our business users don't want that. I then point them to an iPhone. Done right, effects and animations can help usability more than it first appears. «

COMMENT: MARK BARTON emailhomepagerating

MAR 31, 2010 - 01:04:15 PM

comment » Ferdy - just found this

http://www.youtube.com/watch?v=KQkSsmA_lFo&feature=player_embedded

Its a video by James Ward (http://www.jamesward.com/), Technical Evangelist at Adobe, showing performance of Flex running on the Google Nexus One in Flash Player 10.1. Its interesting because in this use case the Flex app would far outperform HTML - though of course it relies on the phone having the flash player and its using a binary format to transfer the data. Still if you have a requirement to have 20,000 rows of data in a sortable(on the phone) datagrid and you don't want to wait for more than a second for the data - maybe this is the answer.

Oh and of course the same flex app runs on the desktop - AIR and in the browser across multiple OS 18 «

COMMENT: FERDY

MAR 31, 2010 - 13:19:13

comment » Mark, thanks for your comments.

Your reasoning seems to be largely on technical grounds, but I want to add that other aspects are equally important: usability, the bottom line, how future proof is the solution, etc. When a RIA solution outperforms anything else in user experience, I'm all for it of course.

And concerning the overuse of animations, I definitely agree with you there. The core of the problem is developers who lack UI expertise building a UI.

I too find Flex and Air to be awesome, but I'm approaching it conservatively. Eye candy may blind us from many considerations to make for such a technology choice. «

COMMENT: MARK BARTON emailhomepage

MAR 31, 2010 - 04:08:35 PM

comment » I agree to a point.

From a pragmatic perspective usability for enterprise apps is a lower consideration - not from me I should add! By the way this looks like a good book which I will be buying - http://designingwebinterfaces.com/

You only have to look at how many companies don't employ UI experts and leave it up to developers to design screens.

By future proof I assume you mean if the underlying technology is no longer supported by its parent company. This will always be a risk to a degree but in fact some of these technologies help to mitigate the risk by separating the data & business logic layer from the UI which would involve less of a rewrite. «

COMMENT: FERDY

MAR 31, 2010 - 16:34:38

comment » That looks like a great book. I too agree that UI design is equally important in an enterprise context. An enterprise may have a monopoly on the applications it forces upon users, still a proper UI will have benefits in the area of productivity, loyalty and work satisfaction. There is a perfect business case for employing UI designers in an enterprise, with proven numbers, but it looks like we're not that far yet.

Yes, I was targetting at the risk of platforms dissapearing or upgrade nightmares. I am figuring that this risk is non existant or much lower when you use standard technologies. You are very much right though, this concerns only the UI part. Still, I am operating in an environment of about 20,000 applications. A partial rewrite is considered money wasted since it costs money yet has no tangible value. This is what makes me somewhat conservative. «

COMMENT: ROBSHAVER emailhomepage

APR 3, 2010 - 06:19:53 PM

comment » There's a bit of a debate going on at Wikipedia.com about how to define what a RIA is. Much of the debate is about weather or not JavaScript/AJAX should be included as an RIA platform along with Silverlight and flex. I haven't contributed there much but did get involved in the discussion (r39525 pseudonym) with some citations from several books which support JavaScript/AJAX as important in creating RIAs.

Perhaps you or some of your readers might want to contribute to the discussion.

http://en.wikipedia.org/wiki/Talk:Rich_Internet_application «

COMMENT: FERDY

APR 4, 2010 - 12:53:25

comment » Rob,

Personally, I do think modern Javascript/Ajax can be used to develop RIA solutions. In this article I am not somewhat suggesting the opposite, but not intentionally. Perhaps the article should have been called "when to use RIA plugin technology". «

COMMENT: SUPERPOWER email

JAN 4, 2012 - 03:02:16 PM

comment » The post is written in very a good manner and it contains many useful information for me. find hosting «

RATE THIS CONTENT (OPTIONAL)
Was this document useful to you?
 
rating Awesome
rating Good
rating Average
rating Poor
rating Useless
CREATE A NEW COMMENT
required field
required field HTML is not allowed. Hyperlinks will automatically be converted.