Category Archives: RIA

Architecture of RIA from JAOO

Josh Holmes and James WardI did a joint session with James Ward from Adobe at the JAOO conference. As you know I’m an evangelist for Microsoft focusing on RIA and UX. James is one of the Flex evangelists for Adobe.

This is a talk that James and I have been talking about trying to pull off for quite a while and I was thrilled that we actually got to do it. James and I have been going back and forth for over a year and a half now talking about the definition of RIA as well as what are the best and worst architectural patterns. Some of this was based on an article that James co-wrote for InfoQ called “Top 10 Mistakes when building Flex Applications”. I borrowed the mistakes that applied across the board regardless of what RIA technology you were using and added the best practices part.

The first time that I delivered a version of this session it was with Mike Labriola at RIAPalooza.

Architecture of RIA from JAOO

View SlideShare presentation or Upload your own. (tags: josh holmes;james)


James and I both welcome emails and contact – email addresses in the slide. You can also comment on the blog. We’ll both be watching the comments here.


The first question that we have to ask ourselves is – what do we mean by RIA?


The acronym could mean anything.
It could be the Rural Inoculation Association whose out there in the world trying to immunize all of the cows and chickens in the world.
If could be the Rare Isotope Accelerator – you know, the one in Switzerland that didn’t end the world… Yeah – I’m thrilled about that.
All the way down to Really Inane Acronym – which is the one I often go with.

But in this session we’re talking about RIA as Rich Internet Applications. This means that we are not talking about simple media players or fancy splash screens or advertisements. We are talking about solid enterprise quality applications that leverage the Internet as a deployment model and typically are built on one of the Rich Internet platforms such as Silverlight or Flash. These are meant to enhance the user’s experience and if you do a good job with design, you will dramatically improve the usability of the application. This is what James and I are both passionate about.


Before you decide that you need to build a RIA, you need to first think about your users and how they are going to use the application. This will help determine where on the continuum of user experience you should target and what type of application you should write.

On the far left hand side, if you are going for absolute ubiquitous reach and need to have information in front of the widest possible audience, text over http is the lowest common denominator. HTML and CSS will still have a long and prosperous life on this end of the spectrum.

On the far right hand side, the guys that were writing Halo for the XBox 360 were able to test the exact hardware, right down to how fast the hard drive spins and which exact video card was in the machine. This means that they are able to make trade offs between how large a map is and what textures are on the walls and so on. This is a huge advantage when trying to create a really rich experience for the users.

However, most people don’t have the luxury of shipping hardware with their software. But can you target a desktop application on a given operating system? Or a family of operating systems?

If you can’t, then you need to start looking at this supplemented web space that we are talking about with RIA.


So what’s different with this RIA development. Really it depends on the skill set of your team. The interesting part is that it’s actually a much tougher jump for web developers than desktop developers.

For desktop developers, there are a number of things that they have to get used to. For example they are locked into a secured browser based sandbox. This means that they can’t do a lot of the things that they are used to doing such as reading and writing anywhere on the hard drive, reading from the registry, accessing local hardware or any number of other typical tasks that desktop developers do.
The back and the refresh button are also quite scary to the desktop developer. Conceptually, you can think of it as opening up the task manager and killing your application. Oops. The question is what do you do when someone does that? There are a lot of differ
ent strategies that you can leverage but the point is that you do have to think very clearly about this potential issue.
State management is also an issue that we have to think about more. On the desktop, it’s natural to just have your state locally. But in this RIA space, what do your users expect if they open up a browser on a second machine? hmmm. You might need to store your state on the server side.
And typically you have a more limited runtime in the browser than you do on the full desktop. For example, the full .NET runtime is about 50 meg and Silverlight is just 4 meg. That’s quite a difference.

However, none of these issues are fundamental shifts in how you think or go about doing your job.

For web developers, on the other hand, there are some serious mind shifts that have to happen. We are used to, as web developers, having everything from the server on hand at any given time. The UI itself is simply rendered HTML. All of the logic and work happens on the server. Often, this happens in a single tier.

Now that we are looking at the RIA space, we have to think about where the business logic goes. Sometimes that’s on the UI side running in the browser. Fundamentally this means the web developer needs to understand service oriented architecture. This is a big change from what we are used to where we could, if we so desired, open up a database connection and query directly from the UI logic layer. Instead, our UI logic is happening out in the browser where they don’t have access to do that through the firewall etcetera.

Ron Jacobs talks about a lot of the possible issues in a set of talks called SOA Patterns that can be found and

For example many people look at mapping their database directly to their web service tier. This is the anti-pattern that Ron calls the CRUDy web service layer. Really, you are not service orienting your application. Rather, you are simply exposing the database tier out to the rest of the world.

Once you get over this hump, the rest of the changes are relatively small in comparison.


Onto the best practices… We have laid out 10 best practices here. These are not by far the only solid practices. These just happen to be the 10 that James and I thought were in the top 10 that are across the board regardless if what RIA platform you are using.



Those couches, no matter how pretty they are, are not amazingly comfortable. The primary point here is that your application has to be functional and usable or nobody will use it regardless of how pretty it is or what technologies you are using.


The easiest way to make sure that you are building a functional application is to focus on the architecture.

This is a picture of from Taliesin West, Frank Lloyd Write’s winter home in Arizona. He spent a lot of time working on the overall architecture of the building and the looks of the building. 


However, he spent almost as much time on the inside. He built much of the furniture, designed the lighting, the flow of the rooms, the acoustics and much more.

The lesson that we can learn from this is that we should spend as much time on the inside of our application and the architecture of the client side as we do on the overall application. You really need to apply a lot of rigor to the architecture of the client side as well as the overall application.

There are two client side architectural patterns that are the front runners that we should talk about.


First in the MVC or Model, View, Controller pattern. The idea here is that you have three separate layers with very distinctive roles.

The model is the first layer that we need to talk about. It reflects your web service layer, not the database but what’s returned from the services. This is the only access layer to the services and hides away the details of which services, protocols, security and other details from the other layers.

The second layer to talk about is the controller. This is the logic. It makes the decisions as to which view is shown, what data is changed in the model and so on. It watches what’s going on in the view for various events and responds to those events by making updates in the model.

The third layer is the view. Often, there are multiple views for a given controller. For example, there might be a complex and a simplistic rendering of a given item from the model. The view is very thin as far as logic goes. It watches the model for changes and updates itself based on those changes. Those changes are either the result of logic in the controller or from a web service call. Often, in Silverlight, WPF or even Winforms, this watching for changes in the model is often implemented as data-binding. As it’s data-bound to objects, the view can decide on what attributes of the object it wants to show.


The second pattern to talk about is the MVP or Model, View, Presenter pattern.

The first layer, the model, is actually very similar.

The second layer is the presenter. One of the big differences here is that the presenter actually updates the view with the changes from the model rather than the view watching for those changes. The result here is two fold. First the view are much closer tied together. The second is that, since the presenter is doing all of the input and output, it’s easier to unit test.

The last layer, the view, is much thinner then in the MVC pattern. It’s simply a presentation of the data that the presenter has chosen to show.


I personally prefer the MVC pattern. I don’t thing that the extra testability that you get out of the MVP is not worth the loss in flexibility in the view. Unit testing is still quite possible in MVC and definitely should be part of the process.



The second best practice is that you should have a set of design tenets that the team shares. Really these are values that should be held by the designers, developers and all of the stake holders. This has to be agreed on by the team at the beginning of the project. I actually like to do two. One for the UI layer and the second for the overall development process of the application. For example, in the UI layer, Search is Failure. This means that if the user has to hit search in order to find something on your web site in the course of normal navigation – you failed in the design and navigation of the application. On the development side, think about TDD or Test Driven Development as one of the tenets that you hold.



The third best practice is to use the appropriate level of fidelity for the user’s context. There are couple of things to talk about here.


The first is when you are developing a prototype. If you bring in an amazingly beautiful wire framed application with a ton of colors and full animations the user is going to do one of two things. Either they are going to argue with you over the exact shade of red or some other little detail without really getting through the functionality of the application or they will say – cool, you’re done. It’s really hard to explain to a non-technical person the difference between a good looking prototype and a a finished application and why it’s going to take 9 months to make that leap.

The answer to this is to use a set of printed mockups for the look and feel and a skin such as ProtoXAML for the running prototype so that you can work through the functionality without getting into the arguments about look and feel. 


The second item to talk about with regards to fidelity is the forest for the trees. This means understanding the user’s context and only showing them the data that they need in that context. For example, if you are dealing with a C level executive you shouldn’t show them how much it costs for a particular pencil. Instead, you should only show them how much it costs for office supplies in general. If the want to dive into that detail, then you should let them dive into that level of detail. Another thing to think about is what should be on a dashboard verses in the full application or report.



The fourth best practice is to build with both the customer and user’s input. Step one here is to recognize that these are indeed separate people. The customer is the one who is signing the checks. Often this is some layer of management far removed from the actual day to day operations that the users are doing. The users are the ones that are actually going to be using your application and getting upset with you about the things that don’t work the way that they want.

This is one of the central themes in most agile methodologies. Most actually want to have one of the users on the development team sitting in the meetings and providing input the entire time.



The fifth best practice is to understand who your users are and what type of users you have. For example if you have a public facing web site, you’ll have something like the curve in the slide with some large percentage of your users being first time visitors to your site, some smaller percentage being repeat visitors and some really small percentage being your power users.

Your goal should be to turn those brand new to the site into repeat visitors and then into power users. For those that are brand new to the site, you need to explain what your web site does and why they want to come back. One the other end, the power users shouldn’t be bothered by that introductory information that you present to the new visitors. A couple of sites that do this really well are WordPress and Twitter.



Sixth is planning for concurrency. Concurrency is always an issue in application development, it’s just highlighted in RIAs as the client is running somewhere on the network or across the Internet in the client’s browser.

The fun issue is with concurreny is that it’s hard to test for in development because typically the developer has their own dev environment and/or a database full of junk test data. This makes it hard to spot concurrency issues. Instead they find these issues in training when the trainer asks the 30 students to open up Mr. Jones and change his address and save. At that point, what happens? Which of the users actually saved the new address successfully?


There are two basic forms of concurrency. Optimistic and Pessimistic.

Pessimistic includes locking down the rows that you are accessing until you are finished with them. It really isn’t a consideration in RIA as you don’t have a long running transaction with an open connection to the database.

However, simple last in wins optimistic concurrency is really not concurrency either. You need to think through the various scenarios and understand where you need to detect that there was a change and then decide on what to do with that change. In order to detect that there was a change, the traditional strategies are to either pass both the original version of the data that you retrieved in the first place as well as the changes or to use a timestamp of some sort. As far as what to do with the change, you might be able to perform logic to make the determination on what to do such as if there is an addition or subtraction of some numerical amount. Most of the time, however, you need to raise awareness to the user that there was a change and have them decide what to do. Other times you need to think about doing some type of escalation to a manager. Obviously that requires more development and thought but it’s worth the time.



The seventh best practice is balancing the computing load. Think about the fact that you’ve got the ability to do a lot of logic client side and you can offload the computing load on the server that way. However, there’s still a lot of good reasons to keep the logic server side. The question is what’s the decision tree on where the logic should run. My preference is to keep the operations as close to the data as possible. If most or all all of the data that you need is client side, there’s no reason to burn the extra network traffic and time waiting on the the round trip. On the other hand, if the majority of the data is server side and you can process the data and just return the results of the processing – do that.



Security is a huge issue and really hard to get right. If you make it too tough, people will find ways around it or stop using your application all together.


Both Silverlight and Flash have security protocols around calling web services. It’s based on the domain that your application was loaded from and what domain the application is trying to call the service on. If you were loaded from the domain you’re trying to call then there are no security issues. The domain is defined as the combination of the domain name (including sub domain such as www), protocol (http or https) and port (such as 80 or 8080). If any one of these are different, then it’s considered a cross domain call. That means that is different from and is different
from The reason behind this is that any of those variables, sub domain, port or protocol could point to different servers. That possibility of changing servers is considered a cross domain call and more security kicks in.

The reason that this matters is that when the application makes that call, all of the cookies for the domain that you are trying to call are passed along with the call. This is not an issue if you are calling a server that doesn’t have private information such as the public web services on Flickr or book searches on Amazon and the like. However, this is a huge issue if the application can call some outside domain that does have private information, such as Paypal or your hospital or some other server that has sensitive information, and pretend to be you by passing in those cookies.

Since it’s the server that knows whether or not it holds sensitive data, the server gets to decide if it is going to allow that call. The method for doing that is a policy file. The Adobe version of this file is the crossdomain.xml and the Microsoft version is called the clientaccesspolicy.xml though Silverlight will leverage the crossdomain.xml file if it doesn’t find the clientaccesspolicy.xml file. In these policy files the server can specify which domains, from all down to a very specific one, are able to call which services.


The quick dos and don’ts for your server that you’re expecting RIA applications are divided into private services that your own applications are going to call and public services that you are opening up to third party applications to call.

For private services:
Do use browser-based authentication through cookies, HTTP Auth and so on. This will allow your application to leverage the existing authentication methods that you are using with the rest of your web applications. This is a big win.
Do not, since these are private services that are using browser based authentication, enable public access via a cross-domain policy file of any sort.

For public services:
Do not use browser-based authentication. You can either just open up anonymous access or pass in the credentials on each of the service calls and use more traditional authentication methods from the SOA world.
Check on the calling application’s URL and other authentication techniques.
And definitely separate out the public from private services into different domains but at least subdomain or something.



If you’ve not spent any time in a support center answering calls from irate users, you should. It will change you’re outlook on writing software, logging, bug reporting and more. Now, let’s have the application running out there in a browser in a secured sandbox so that you’re users don’t have direct access to any log fine and the issues that they might run into could be network issues and you wouldn’t able to log errors on the server side.

Do you see the problem? 

One technique to deal with this is to code for a parameter that the user can pass in on the url that will bring up an error console that the user can read back to you. For the error log, you can store the errors in a cookie or local storage.

The point is that you need to think long and hard about supportability and what could possibly go wrong and how to handle it.



Very importantly, you have to keep your user’s context in mind. Are they mobile? Disabled? What role do they play? How are they going to be using your application? What’s the minimum data that they need to accomplish their duties?

By remembering your user’s context you can build the most effective application for them in their unique situation.


I’d love to hear about best practices that you’ve uncovered in your work as a RIA designer, developer and architect.


I learn best from my failures and the best practices wouldn’t be best practices if there weren’t worst practices. As such, I don’t think that any best practices talk is complete without addressing the possible worst practices.



The first possible worst practice when creating a rich internet application creating a rich internet application in the first place. You shouldn’t use 2.0 technologies to build a 1.0 web site. HTML, CSS and light javascript can go a really long ways in creating a beautiful site that’s rich with information. You have to think about the user’s interactivity and context when picking the technologies that you’re using. We are all gui
lty of finding a slick technology and picking it as our hammer going around making every problem a nail.



Many RIA applications forget about the page refresh and back button. By default, when the user hits refresh, the application unloads, reloads and starts over from the beginning forcing the user to navigate back to the where they were in the first place. By default when the user hits the back button, the page with the application in it is unloaded as the browser goes back in the history to the previous page. In either case, this is probably not what the user expected.

If they were using a traditional HTML based web application the refresh would simply reload the page that they are on. If there was a postback involved, it will even offer the user the possibility to repost those variables to get the same result again. You can, if you write code to handle it in the unload and load of the application write out the state on unload and recreate the state on load.

For the back button, things are little bit more complicated. One way you can handle this is to build a state machine that tracks the logical pages in your application such as the pages in a wizard. Then you can trap the back button event and unwind the state machine. If you are at the beginning of the application, let the event go and act as normal.



The first thing that a lot of people think of when they start thinking about those challenges with regards to the back and refresh button is to simply disable them rather than going through all of the effort of handling them. This is a choice but if breaks the way that users expect to browse on the web so doing do it.



Ignoring your bandwidth is another large mistake that people make. There are a couple of different ways that this happens.

To start off, you need to think about the size of your application and how that will effect load times. A lot of desktop applications are many meg in size. This is fine since you are not having to download the application to run it over and over again. If this is the case with your right internet application, you need to think about partitioning your application to optimize load times. The simplest example here is to make sure that you don’t embed assets such as videos or images inside your application unless you absolutely need them on startup.

More advanced techniques include partitioning the application itself into multiple easily digestible parts.

The second thing to thing about is video streaming if you are using video.

One more area for concern is the amount of data that you are pulling back at one time. There are a lot of different paging techniques that you can employ with easily implemented patterns.



There are good ways and bad ways to leverage animations. Many times there is gratuitous animation that have been thrown in just because they can.

The good is when a particular animation helps the user visualize data in a unique way or leads the user to the next action. For example, you can, when all required fields are filled in, add a shimmer behind the “next” button to draw the user’s eye to guide them along the way.

Another example of good use of animation is showing transitions in state or data. As Mike Labriola put it, if your user rolls a ball and it just disappears as it leaves their hand and appears across the room, they would be very surprised. By showing the state transforming through animation, you can show your user what happened.



We, as developers, are infamous for NIH (Not Invented Here). There are, even with a limited framework, a tremendous amount of utilities in the framework that you don’t have to reimplement. There are a lot of possible issues with not leveraging the framework that you’re running on. First, you have to maintain it. But the other issue that is more unique to the RIA world is that the user has to download this code when they run your application. This bloats the application and contributes to the other worst practice that we already talked about with ignoring your bandwidth.



Cowboy development is always a worst practice. The problem is that there are times that people get away with it. And that makes them bolder and bolder. “It’s just two lines of code. A tweak really. I’ll just make that on the production server.” Tweaks have brought down more servers than major production roll-outs. The major changes have been through testing and QA and all sorts of engineering rigor. The tweaks has at best been reviewed by the guy sitting in the next cube.

With RIAs, we are building real production applications and we need to apply the same disciplines that we should for any other application development. That includes Source Control, Change Control, Bug Tracking, solid development processes, TDD, Continuous Integration and the whole kit and caboodle.



In laying out the application’s interface, it’s really easy to get carried away with the number of containers to control the exact positioning of the items on the screen. In the HTML world, we did this with tables until we were all told that tables were evil. The answer was to switch to divs and put divs inside of divs and so on. This proved not to be any better. The real answer was to use CSS to set the relative positioning of the items.

The same idea applies in the RIA technologies. The more containers that you use to create your layout, the more constricted it will be. 



If you have a really complex rendering of a given item, that’s not necessarily a bad thing. However, if you take that same item and databind a thousand of them into list – now you have a problem.



Getting religious about your technology decisions is a really common and really horrible practice. You should evaluate the possible technologies on their technical merits rather than on feeling, personal biases or any other non-technical method.

Instead you have to determine if the technology will actually do what you need for it to do, what your team make up is and if they will be able to leverage the technologies, if the IT department will be able to support the roll out of the application and all of the other technical merits of the chosen platform, technology and so on.

This is the point in the talk where James Ward (remember that he’s from Adobe and I’m from Microsoft) came over and hugged me on stage!


I’d also like to, just as I asked for your best practices, hear from you about worst practices that you’ve found over time.



Rich Internet Applications are meant to enhance the users experience. Poorly designed applications don’t accomplish this goal. Furthermore, we’re probably going to face a period where we have a lot of “Silverlight Blink” so called for the HTML Blink tag that annoyed us all for so long. We all need to champion user centered design to ensure that we are building the applications that will help, not hurt, the user.

The architecture of the client matters, especially now, as much as the overall client. It helps with testability, maintenance, flexibility, changes and a ton more.

These are real applications and should be built following the best development practices. This includes all of the engineering rigor that any enterprise quality application is built with. This includes change control, feature and bug tracking, TDD, continuous integration and the whole ball of wax.

Don’t rewrite the framework that you should be leveraging.

Leverage user centered design techniques. There are a lot of great resources out there that you can tap into to learn more. I’ll follow up with a post about that in the near future.

Take religion and emotion out of the technical decisions that you are making. Evaluate technologies for their technical merit and choose the one that’s going to work best for your team


Be sure to subscribe to James and I’s blog. Follow up with us with questions. Let us know how you’re leveraging the RIA technologies. We’d love hear it.

I enjoyed giving this talk and thank Mike and James for joining me in presenting it.

Definition of a Mashup

The JournalSince Larry Clarkin and I wrote the Enterprise Mashups article in the Architecture Journal, I’ve been getting a ton of questions about mashups and what they are. To that end, I thought I’d put my neck out and lay down a public definition.

A mashup is an application that pulls together data from different sources and puts that with functionality that didn’t know about each other previously to provide a interesting graphical look at that data.

Often, a mashup is used to the end of making decisions based on a visualization of the data.

The canonical example is putting data on a map. For example, Wikipedia (at least as of when I wrote this) defines it as follows:

In technology, a mashup is a web application that combines data from more than one source into a single integrated tool; an example is the use of cartographic data from Google Maps to add location information to real-estate data from Craigslist, thereby creating a new and distinct web service that was not originally provided by either source.

Mashup (web application hybrid) – Wikipedia, the free encyclopedia

However, it doesn’t have to be a map. It could be a graph, chart, mind map or any number of different overlays.

Now, notice that I didn’t talk about any given UI technology in my description. It could be AJAX. It could be Silverlight or Flex/Flash. It could be Java Applets. I’m not concerned about the exact technologies involved – just the overall idea that you are pulling together data with functionality with a UI none of which knew about each other before your “glue” code put them in the same room and let them dance.

Granny wants to Mashup?Things that are not mashups

Composite applications are not mashups. This is actually a funny one. Mashups are, by and large, composite applications. You can equate it to inheritance. Mashups have an IsA relationship with Composite Applications. However, the composite application that simply pulls together a number of different widgets each completely independent of the others on the page is not a mashup. So, what I’m saying here is that CAB Smart Parts, Sharepoint web parts and Java Portlets are not mashups – they are simply part of an overall application that has been assembled.

Aggregations are not mashups. I’ve been asked several times if aggregating 2+ RSS feeds or simply combining different data sources is a mashup. The reality is that it’s not.

If, on the other hand, you were pulling in 1+ RSS feeds and/or data sources and laying those out on a timeline or some different view of the data than just an aggregated list – then we are probably talking about a mashup. The key part here is that we are doing something more with the data than adding it together. We are enabling decisions to be made based on that data.

Tools to build mashups

You don’t actually need tooling to build a mashup. You could create it from scratch with a little bit of Javascript and a chart control. The most common mashup, as stated in the canonical example above, is a map with geographical data laid on it. Both Google Maps and Live Maps have SDKs that you can build on top of. Actually, the Live Map SDK has a completely interactive documentation set as you can play with that will let you try different things and copy source code right into your own applications. In a lot of ways, you can look at these maps as not only applications but mashup platforms.

Popfly and Yahoo! Pipes

Then there are more complete frameworks and platforms that will help you build mashups such as Popfly and and Yahoo! Pipes. These platforms allow you to drag and drop different data sources and apply logic and ultimately run that through a front end visualization. My 12 year old son has played with Popfly and created mashups with ease. Denny Boynton wrote a great post entitled “Is the Future of Popfly in the Enterprise?“. I think that he’s got something there.

One of the interesting parts about Yahoo! Pipes is that it allows you to pull in your data, build out your functionality and then at the end you produce it and have a tabbed view with a different visualization on each tab. That’s cool! If your data is geo tagged, then it will give you a map view. If you have numeric data, it will show you charts and so on.

Where to get started

There are a couple of ways to get started playing with mashups. First, you can take a look at Popfly and the like. Or you could get started with one of the online mapping applications/mashup platforms. However, if you are serious about mashups in your own company and want to produce mashups with your own data – you need to start by taking a long and hard look at your SOA strategy.

Are all of your services written because you needed to move the client to a different machine? Often you can tell these because they start to resemble your table names and fall into Ron Jacob‘s CRUDy Web Service Anti-Pattern. Unfortunately, this is the vast majority of applications that I’ve seen in the world that use web services. It’s just using web services rather than truly service enabling your platform.

Or are they strategically built services that encapsulate business logic? Are you thinking about your authentication and authorization strategies? Are you thinking about SOAP verses REST? Can you produce either from your platform?

These are all decisions that need to be made before you decide on the UI technology.

Continuum of Experience

One of the key messages that I’ve been talking about with a lot of my customers recently is a continuum of experience.


It starts on the left with Web and it’s absolute ubiquity through HTML and CSS. This works on any device with a browser from a phone to any desktop and even a lot of computer based applications (such as search engines or spam email harvesting engines). The tradeoff is that the user experience is less than optimal. Billy Hollis calls it the Cobol of the web referring back to the old time green screens. Whether we like it or not, HTML not only has it’s place now, it’s going to continue to have it’s place long into the future. Unfortunately, one of the reasons that many applications go this direction is not because they need ubiquitous reach but rather because it’s easier on the IT department to deploy it. This makes things hard on the user. Oops. Things can get better with AJAX. At this point, you are sacrificing some reach for functionality as you are giving up phones, PDAs and older browsers. Often that’s an easy decision to make.

On the right hand side of the continuum is Platform Optimized. This is really giving up broad reach for absolute functionality. As an example, the Halo 3 team knew which video card was in the target machine so they could tailor the experience for the edges of what’s possible on that hardware. That’s a good position to be in when you can be because it means that you can create the absolute best possible experience available. However, it would be hard to take that same experience and put it on any laptop. Short of knowing what hardware you are targeting, look at the platform that you are targeting. If you know that your users are using Vista or XP with the Service Pack 2, you can target WPF, WCF and so on because you know that it’s on the box. Backing up from there, if you can target .NET on the box, great.

Somewhere between the Web and Platform Optimized is the Supplemented Web with Silverlight and Flash/Flex. This is an exciting frontier to be in right now bridging the gap. It’s not full ubiquity but it’s more reach than platform optimized and it has a far superior user experience than HTML and CSS.

Microsoft and Adobe are working from opposite angles here. Adobe, with Air, is trying to take this supplemented web development paradigm to desktop. It’s an interesting idea to be able to bring HTML, Flex/Flash, embedding PDFs and so on to the desktop. Microsoft, on the other hand, is trying to take desktop application development paradigm to the web with Silverlight.

I think that there’s room for every type of experience along the continuum but you really need to evaluate your skill set and what type of experience you want to target when starting an application. Today actually, I had a customer meeting where we talked about a blended approach where we build a simple ASP.NET application for their ubiquitous touch and then target a click-once deployable application for those clients that are able to leverage it. This would be a great move on their part as it would give the best possible UX for the greatest possible audience.

Rich Web Experience Conference Kickoff Panel in InfoWorld

I’m speaking on Silverlight at the The Rich Web Experience conference in San Jose, CA. At the last minute, I was pulled into a panel discussion that kicked off the conference. It was a fun panel. There was a editor from InfoWord named Paul Krill who wrote a fantastic article on InfoWorld.

There were representatives from Microsoft (me), IBM (Jon Ferraiolo), Yahoo (Bill Scott), Ryan Breen (VP of web testing company Gomez) and many consultants including Scott Davis and Stuart Holloway. The panel was run by Neal Ford (ThoughtWorks). Neal threw out the question designed to bait the panel, “Ajax, Flex, Silverlight – who’s going to rule the world?” I thought just for a moment about jumping up on the table and yelling “Silverlight!!!” but I thought that’s probably not the introduction I needed to the crowd so I waited. There were several of the guys that said that stepped up for AJAX because of the ubiquity factor. I stepped up for Silverlight/Flex talking about the continuum of experience from ubiquitous lowest common denominator web applications supplemented web to platform optimized. Silverlight/Flex fill that spot in the middle. It was fun to be the guy on the panel that was answering all of the Flex questions as well as the Silverlight questions. People asked about testability, accessibility, tooling and more. I had fun and was really happy that I had attended the RIA Jam in Crested Butte. I was also thrilled, with the crowd that we had in attendance, to announce the Moonlight project news. The whole panel went really well.

Rich Web technologies debated | InfoWorld | News | 2007-09-06 | By Paul Krill

*Update – ComputerWorld picked up the article –

Technorati Tags: , ,

Dancing in the Moonlight!

Very, very close (It was #1 Explore)         132 times Fav.!When I was at MIX and walking down the hall, I ran into a rather excited group of people that included Miguel de Icaza at the center. I stopped and listened as Miguel was running through the Silverlight 1.0 and 1.1 collateral and saying things like “We’ve already got that”, “That’s a week’s worth or work”, “That won’t take too long” and so on. I realized that I was watching the formings of the Mono-Silverlight project later to be named Moonlight.

I didn’t foresee this news though!

Microsoft is going to officially endorse the Moonlight project from Novell!

Here’s what that means:

  • Microsoft is listening to it’s customers and is delivering that they need when they need it.
  • Moonlight, via Novell, is going to have feature parity and compatibility with Silverlight and Silverlight content will run on Moonlight with no changes. Woot! That’s going to be ensured because Microsoft is giving Novell access to the same test suites that they are running on Silverlight. That’s sweet.
  • One of the large pushes on Silverlight 1.0 is HD video but it’s WMV. Guess what – Microsoft is producing codecs for the Moonlight project that are going to run on all distributions of Linux and BSD that Moonlight runs on.
  • That last bullet point means that Moonlight can be distributed commercially because the video codec that they are currently using is not licensed for commercial distribution.
  • Very importantly for me – I am allowed to officially as a Microsoft employee to say that Moonlight is the answer for Silverlight on Linux.

What this does not mean:

  • Microsoft is not going to support Moonlight, that’s still up to Novell and the Open Source community.

Miguel de Icaza‘s post on the subject:

This is the official press release from Microsoft:
Microsoft Delivers Silverlight 1.0, Extends Support to Linux: “Entertainment Tonight” HSN and World Wrestling Entertainment showcase new online experiences; more than 35 partners commit to Silverlight Partner Initiative.

Technorati Tags: , , , ,

Silverlight Twitter Badge

It’s by no means perfect, but I’ve got a new Twitter Badge on in the right hand margin.

I was sitting at the Flex and Air Jam and started working with James Ward on a Flex twitter badge and started thinking about what a Silverlight Twitter Badge would look like. James had this concept for creating a clock for the time to really give the badge some context and pop. I liked the idea so I stole it… :).

I’ll post the whole source code and all shortly. I’ve got a few more things that I want to play with – like making the white background transparent.

Technorati Tags: , ,

Mindview Rich Internet Application Summit August 15-17, 2007

This is 3 days of conversations around RIA (Rich Internet Applications) with some of the movers and shakers in the RIA movement. There are going to be a lot of great minds at the table, including James Ward (the RIA Cowboy) and Bruce Eckel. This should make for a lively conversation. I’m not sure who else is going to be attending.

I’m going, are you? I’m pretty excited actually – this should be a fantastic gathering. I know that it couldn’t be in a whole lot more ideal of a place. If you’ve not heard of Crested Butte you need to check out these photos and these photos. It’s 4-5 hours driving from Denver. I’m really looking forward to that drive though – it’s through Colorado in the summer crossing the continental divide. I’m flying in on the Sunday before and planning on taking my time driving up with lots of stops to take in the scenery.

Once the summit starts, it’s an interesting format that you might or might not have heard about called an Open Spaces Technology format. There are 4 “laws” that are in effect at any Open Spaces conference.

  • Whoever comes are the right people
  • Whatever happens is the only thing that could have
  • Whenever it starts is the right time
  • When it’s over, it’s over

    It is fairly limited seating so you should reserve your seat now.

    Mindview Rich Internet Application Summit


    Technorati tags: ,