I 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.
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
http://channel9.msdn.com/shows/ARCast+with+Ron+Jacobs/ARCast-Patterns-and-Anti-Patterns-for-SOA-Applied/ and
http://channel9.msdn.com/shows/ARCast+with+Ron+Jacobs/ARCast-Patterns-and-Anti-Patterns-for-SOA-Part-2-of-2/
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 http://www.somedomain.com is different from http://somedomain.com and http://somedomain.com is different
from http://somdomain.com:8080. 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
makeup.
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.
I’ve been a long time supporter of PreEmptive Solutions. They’ve done a great job of supporting .NET. As a Cleveland based company, they are in my territory as an evangelist. 
– 
– 
