Rich Internet Applications vs. Rich Applications

Had some interesting discussions and observations over the past few weeks. This culminated yesterday into a conversation about games, etc. It just was luck that I garnered an understanding of both of the above comparisons.

First off, I can see why a lot of applications are going web vs. fat client/win32 etc. I like to think of myself as an applications developer vs. a web developer, as most of my Flash stuff for companies (not contract) tends to run on the client machine via some form of client. All of my contract work is for a website in some form or another, with the exclusion of some rare “niche” fat client projects.

*******

One of the challenges companies have is taking their brand as well as providing their customers services, and deploying this on the consumers’ desktops, while avoiding all the normal issues and support call costs. I mean, look at all the time and energy (technotes, emails, etc) that goes into installing new versions of the Flash IDE. Typically, various teams control their development and deployment, thus ensuring in some fashion that they can get to a deliverable scenario, and meet business requirements. I’ve yet to see this be a positive thing for sales and marketing, though mainly marketing. Those in the know in those departments realize the need for consolidated experiences, for driven home brands to be instilled in the minds of consumers in a positive fashion. Doing this in large companies proves extremely challenging. Those that I have had experience in are compromised of rogue, non-IT, internal development teams with very little cross pollination of those teams, and a huge aversion to the IT teams (internal development vs. consumer). The other side of the coin is the majority of the company consists of various levels of operations and management; all the deployable products (software/hardware) are outsourced to contractors and other companies, and managed by the central company.

This is a branding nightmare, it seems to me. For example, you have your hard and fast logo laws that you just don’t violate. Your standards, those de facto, ISO, and those determined by upper level marketing, are typically always followed. To me, though, the rest gets seriously blurry. Like, Cingular is orange, and known for it’s recognizable color. However, their various sites and products sometimes deviate from these norms, and a lot of it out of necessity, other times not. For instance, my Nokia phone that her majesty obtained for me via Cingular is transparent so I can draw whatever I want for my phone’s design… but it came with the orange OS colors. My Cingular text pager is all black… but the secondary key letters as well as toggle button are orange. Later generation pagers actually have the orange more matching Cingular’s color. The pager itself is all black since colors would be more expensive to produce, but you still get the branding you want.

Now take that strategy of getting a brand implemented with various, fat client teams and outsourced software products. That has got to be one of the most hardest things to do in a business, especially when there is immense pressure on those with the ball of ensuring that happens in an all out, straight forward thrust to take a company’s brand, develop next generation products and services, and deploy them to the client with no fuss.

You’ll have IT saying that they don’t want to deal with various, non-related products because of the lack of ensured workability on deployed machines. What version of the Java Virtual Machine is installed? Does said program overwrite our required DLL? Can we afford a new CD mailing? How does this mesh with legacy products? What is the potential adoption rate of the new product? How much revenue should be associated with this product in terms of support and for how many quarters?

To prevent above, a protective silo develops around a certain dev team to ensure the above is all answered with definitive “it’s all good”. As much as I hate Geometry, it “proves” in either a postulate or theorem… forget which one out of the hundreds, that if 2 rays start from the same point, but deviate even slightly in their direction, the farther they go, the farther apart they become. This is true in a product’s branding congruency with other products from the same company.

Are you truly having an experience with using various products from the same company if they differ so greatly? What does that negatively affect if you don’t? How are your perceptions of the company as a consumer affected? Can you continually identify with what the company stands for or less so?

Ensuring the experience of the company’s brand stays true across a myriad of products, while at the same time actually have real products that solve real consumer problems, and introduce new services is tough via fat client deployment scenarios. So far, I’m only convinced this is possible via “pay to play” application frameworks, such as Macromedia’s Central. If you want to ensure your stuff works on all client machines, you simply follow the Macromedia’s development rules, which actually because of their shell built with developer requests in mind, offers more features than a browser could, but doesn’t tie you to OS specific nightmares with traditional development.

Even the above, though, assuming your doing your own shell and application framework, still constitutes a rocky road. You inevitably make sacrifices in shaving off certain functionalities that tie you into a certain configuration. The next best, accessible thing is web deployment; taking your rich app and putting it on the web, aka Rich Internet Application. You avoid a variety of problems by utilizing Flash since, except for weird and extremely isolated yet solvable problems, you can support all of the big browsers and most of the OS’s; enough to meet a business’ need. On the same token, you separate a lot of the business logic into a central location which helps go with the natural scalability of backend services.

Not only that, but you already have pay to play rules in place; it’s known what one can and cannot do in a browser environment, not to mention the fact that connectivity is implied vs. relied upon. That’s a privilege, we must not forget, but still something your treating as a given vs. a technical challenge to ascertain and overcome. Apps can connect to other application’s resources since they all derive from one central location.

Finally, since the GUI is in Flash, which is what its ultimate strength is, you give marketing an easier time to ensure the experience, the look and feel, the presentation; it’s all in the vision to the T.

It just makes sense after I’ve drilled upon it, mainly the other side of the fence, and now I understand from a big business perspective why RIA’s just make good business sense.

One Reply to “Rich Internet Applications vs. Rich Applications”

  1. I agree totally with your arguments. Though you tend to lean more towards internet (web) deployment, I would also include intranet deployment. I’m currently focusing on small to medium sized enterprises (SMEs’) that have a small number of users with no need for web access or has a restricted number of remote users (closed user groups). My initial attraction to RIA’s the R (Rich) part, your arguments are equally valid for these type of enterprises. That’s why I’m very annoyed at the pricing model for Flex. For a 5 user application, Flex is a no go. Sure, the system will expand as more and more applications are made RIA, but the number of users still remain the same. Maybe, the number of users would increase when these SMEs get to the point of giving web access to their clients and suppliers, but these would be very limited in number as these applications would as the number of remote users are resticted in scope and number.

Comments are closed.