Adventures While Building a Silverlight Enterprise Application: Part #21

Introduction

I came back from a short vacation today and read this post from Tim Heuer. I then realized that in all twenty parts I've written on our adventure of building a Silverlight Enterprise application, I've actually never elaborated about why and how we chose Silverlight and how we (or at least I) learned to use Silverlight technology. So, now seems as good a time as any.

Let me be a lazy author and just follow the questions that Tim put up there.

Decision Resources

Obviously, when you are about to start a project, you have to decide on what you are going to use and why. If you are looking at Silverlight, what factors into your decision?

In our case, one of the most important targets was to move from a client-server based solution with a (very) fat client to a multi-tier solution with a web based client. The first choice was to go with DotNetNuke as some experience was already available; however, as you may very well know, this uses regular ASP.NET AJAX like solutions, which we found very limiting in UI perspective. At the time, Silverlight 2 was just about to come out of the Beta stage, and we felt we should at least take a good hard look at it. We needed to have technology that was relatively easy to implement and yet have enough flexibility to make for a very useful UI.

So our major decision factors where:

1. UI possibilities / user friendliness
2. Development speed
3. Flexibility

Why did your company choose to adopt Silverlight (or choose not to)? Was there another technology that was chosen to be better? Why/why not?

We choose to go with Silverlight because it checked the boxes on the above list. We felt it was easier to build a good user friendly UI with Silverlight, in comparison with ASP.NET / AJAX. Also, we experienced in our prototyping / proof of concept face, that building a UI with Silverlight takes less time as well, because of the use of XAML and C# only. No HTML or JavaScript code made life a lot easier for us.

Another elementary aspect of Silverlight proved valuable to us. It was the fact that you can embed controls inside other controls and work with templating. In combination with declarative databinding, this became an important topic for us during decision making.

Again, we were comparing to DotNetNuke, which had some advantages over Silverlight as well. One of the things that DotNetNuke had which was considered an advantage, is the fact that you could access the database directly from your client-side code. In hindsight, I'm glad that we can't do this with Silverlight and just have all the logic in a service layer. This proved to be much more flexible for a lot of scenarios we already ran into.

What is the most important thing in deciding Silverlight is right? Feature set? Existing technologies? Rapid development? Other reasons?

At the time, Silverlight 2 was not exactly existing technology as it was just coming out of Beta. This was a concern for us, but the fact that this was Silverlight 2 and that there was already an active and growing community, combined with the fact that Microsoft had plans for updates laid out already, pulled us across. The feature set was definitely important. The way databinding is implemented is important to us, as we are building a data rich application. Also, the controls available at the time as default, and also through the Silverlight Toolkit, and the fact that third party companies literally jumped at Silverlight 2, helped ease the choice even further.

Rapid development was obviously something that needed proof as no real world examples where available at the time. We built prototypes of several scales and found that it was indeed fast enough to build something with Silverlight 2, even without experience with the technology.

Learning Resources

On learning – how do you best learn? Do you prefer “atomic” samples? These are the ones that you can just pop in and figure out a task-based situation (i.e., how do I open a file in Silverlight?). Or do you prefer more of a “lesson plan” approach to things? This would be a series based on a task (i.e., Build a Media Player in Silverlight).

For me personally, a lesson plan approach was new. I did part of the digg API sample series, but after several steps, I lost interest, mainly because some of the topics were not of interest at the time and some of the topics were just too easy for me. This makes me lean towards atomic samples, although as a starting place, I can see why people like this lesson plan thing. Later on, atomic samples are obviously the way to go. They have the advantage of showing only the bare minimum of implementation without the burden of having to go trough previous steps to understand code that was already there.

On medium – in either type of these learning paths, what is your preference? Video? Written step-by-step guides? Labs? When you are completely new to a topic, watching a video is great. It takes away some of the effort of having to follow along with some article and just being shown how things work. This is also great for some more in-depth topics, with less code and more explanation.

If looking for a reference, or if I need to actually start coding on something, I do prefer written material, as it is a lot easier to just scan through and look for that bit of code, or that bit of explanation you needed, instead of plowing through twenty minutes of video trying to find that five second shot of the code you need.

I've tried labs in the past and I found that they are not my thing. I tend to get bored very quickly because usually the level of instructions make things too easy. Also setting up to do a lab feels like a lot of work most of the time.

On topics – what are the top three topics you expect when learning a new technology? How do you on-ramp yourself when you know nothing about it? Do you expect to learn the tools first? Or jump right in to data access?

This is actually a very tough question to answer. It really depends on what a technology looks like. When looking at Silverlight, I felt that I already knew enough about the most important tool: Visual Studio 2008. Of course, Blend became part of the toolset I use, and over time, I did watch videos and read tutorials on Blend to learn some tricks here and there. So for me, while learning Silverlight, diving right into important topics was very helpful. I do feel it is important to include tips on how to use tools, where this is important to the topic at hand.

For example, if you are talking about databinding and data access, it is handy to demonstrate on how to do this in Blend including using sample data. If something like this becomes too elaborate, at least make sure you point out to the public that this is a handy feature they should know about and tell them where they can find more information about it.

Other Notes

Something that bugged me for quite some time when getting started with Silverlight was the number of resources that were available for Silverlight 2 Beta 1 and 2. While being a great help to win over management to go with Silverlight, this made life a lot tougher when trying to find useful resources for Silverlight 2 RTM as a lot of times the important bits would not work in the RTM.

Something else that I found is that, although silverlight.net is a great resource when learning Silverlight, it is a bit of a mess. Videos are not categorized in a way that makes them easy to find, and there is not a proper search function on the site. Also, I think it would be very helpful to have a search engine that can search for Silverlight content for your specific version only. So, if I'm working on Silverlight 3, I might not be very interested on Silverlight 1.1 and 2 content. Or at times, I might not care if it's Silverlight 2 or 3 content, because they are likely to be compatible any way.

As a final note, I would like to encourage anyone who hasn't already done this, please go to the article of Tim Heuer and comment. Or you can comment on this article as well.