Testing the new blog setup...
Hey you with the camera...yeah, you...
If you're interested in learning from 3 of the best photographers in the world (yes, I said world), you may be interested in attending YinYang Workshop. I recently developed the site for Dave & Quin Cheung of DQ Studios and Huy Nguyen of F8 Studio, and not only are they photographic rock stars, they are amazing people who are truly gifted and passionate about what they do. They are putting on a 3 day workshop in San Francisco in September of this year, and the seating is limited, so if you're interested, contact them right away!

If you need proof of the quality of their work, check out DQ Studios' and F8 Studio's websites. They truly do AMAZING work and have won tons of international awards!
On a related note, I also built a site promoting DQ Studios' new DQ QuiKeys, a workflow empowerment tool for use with Photoshop. See examples of what you can do with QuiKeys as well as tutorial videos by Dave & Quin themselves.

I wanted to take a look at Silverlight VS Flash, but this comparison has been done a million times ("Silverlight VS Flash" yields 205,000 results in google), so I wanted to look at it from the project manager side of things and why they should choose one over the other. Neither technology is monstrously better than the other so picking the technology really depends on your needs, your resources and what you want to accomplish. Hopefully this post will provide you with more perspective in making that decision.
Silverlight & .NET Framework:
The first and in my opinion the most appealing thing about Silverlight is its leverage of the .NET Framework. There's some hurdles to get over when first venturing into the world of Silverlight, but for any seasoned .NET developer it feels just like home.
Any .NET Developer, whether windows or web based, can jump right into coding a Silverlight app with ease. What does this mean for your project? You can now take any .NET developer from your resource pool and expect results within a week or so of them first delving into Silverlight.
IDE & Workflow:
There's no question that Flex Builder is a huge improvement on the old Flash IDE, but I don't think any developer that's used both Flex and Visual Studio 2008 would deny that they are miles apart. Visual Studio is a full blown and rich development environment, coupled with addons like ReSharper, CodeSmith, NUnit and so so much more, VS is on a whole different level.
Once you leverage common tools and practises within the .NET framework with your Silverlight app, you suddenly have the same core development structure as you can have for your windows apps. Unit testing, Continuous Integration and agile development are available to any Silverlight developer. So the workflow that you're used to in the .NET world is available to you with Silverlight, with the bonus of now being able to utilize WPF to add a rich UI.
Market Exposure:
The stats I can find suggest that about 85-95% of users on the web have some version of Flash Player installed on their machines. Silverlight has a lot of catching up to do on this, but lets not forget this is Microsoft we're talking about not just some startup company trying to get a piece of the pie.
Microsoft have made huge ground on getting exposure to the Silverlight plugin. NBC moved to Silverlight right before their exclusive coverage of the Olympics, I've heard that's a big deal. Also the DNC (Democratic National Convention) provided, for the first time, video coverage of the Convention on their website, of course Silverlight based. Biggest of all though is the one that most people overlook ... according to Compete.com, Microsoft.com is the 8th most popular site on the Internet, with around 60 million unique visitors a month. With the homepage and also the download center now in Silverlight that's quite a bit of exposure.
Conclusion:
Flash has been around for a long time and in a lot of ways it's still better than Silverlight. You have to put it in perspective though, Flash is now moving into version 10, whereas Silverlight is in beta on version 2.
Microsoft, however, has the benefit of leveraging years of work on the programming side whereas Actionscript is relatively new and has only recently started moving from a scripting language to more of a programming interface for Flash.
So bottom line it depends on your needs and resources, if you have a bunch of .NET Developers and a client that wants a RIA then it's really a no brainer ... Silverlight is for you. If you have a client that needs a full scale business application on the web, Silverlight might also be for you as you have a full scale development framework to leverage. If, however, you have a client that wants a cutting edge UI with 3D integration, then Flash might be a better option. Either way RIA's are the future for business applications and if you want to pitch a solution to your client be sure to consider either Flash or Silverlight apps as a way to deliver that solution to your client.
---
Living to Code != Coding to Live
After asking Chris to post his thoughts on the topic of Silverlight VS Flash from a .NET developer's standpoint, I wanted to post my thoughts from a Flash developer's perspective. I have been heavily involved in SL development over the past 8 months working for some big clients on big projects. I realize that's a relatively short period of time considering I've been doing Flash development for nearly 10 years, but I've gained enough insight in that time to write down some informed thoughts. Keep in mind that these thoughts are based on the current incarnation of SL2 (beta 2) and I'm sure some of this will have been addressed by the time SL2 drops in completed form.
Runtime penetration
No one disputes that the Flash player's penetration rates dwarf those of SL at this point. So the key here is the ability for Microsoft to provide a seamless install experience. Adobe has years of experience in this realm and have become experts of both minimizing the size of the runtime (squeezing as much as they can into every single kB) as well as providing a really simple install. SL has a much larger runtime to download and install (anyone know the exact size of the beta2 player?) which sets them back right from the get go. Obviously it supports a subset of the .NET framework so there are a lot of features there, but at the same time, it still lacks a lot of functionality already built into the Flash player (discussed below) which if/when implemented will only increase the player size. This is key, as having a bad install experience may turn a user away from SL, but could also turn a user away from other install processes (i.e., Flash player).
Workflow
Visual Studio is no doubt a great tool for coding. The ability to just plug in the SL development bits and start coding (only C# currently) is a dream for .NET developers. As Chris mentioned, leveraging existing knowledge is key and MS have done a good job of that. I have to say that the intellisense really is outstanding. Integration with the backend is strong, as should be expected. As Chris mentioned in the previous post, there are also lots of add ons which provide cool functionality. The biggest area where improvement is needed is in the designer/developer workflow. Firstly, even though VS displays the visuals associated with your XAML, you can't select or modify elements visually. You have to edit the XAML directly. Also, often it wouldn't display the entire "stage" in the display area but didn't give you the ability to scroll it so you could get it where you wanted it. Expression Blend is a step in the right direction to address this. You can create your XAML in Blend and then open it in VS, and your graphics are ready to go. The problem comes when you need to tweak your graphics. What I generally ended up doing was copying and pasting XAML back into Blend and tweaking visually there, however, there are issues if you are using custom XAML tags and such. So it ended up being a really painful process. On the flip side, you have Adobe's Creative Suite. The designer/developer workflow there is far superior at this point and is promised to improve with the addition of Thermo (as well as other enhancement I'm sure we'll see in CS4). If Thermo lives up to the hype, MS is going to have a lot of catching up to do.
Features
Though I've worked on several SL based projects, most of them had one thing in common - video. It's no secret that a large part of the initial interest in SL has been building either standalone video players or players that integrate into a larger app. Support for WMV is a driving force behind that. And for the most part, I think that's a good application of the SL technology. But the nod in overall feature set no doubt has to go to Flash. Things like bitmap manipulation, advanced text rendering, printing, skinning, 3D engine, and sound generation, which are all things that put the "rich" into RIA, are currently largely unavailable in SL.
Conclusion
There are several compelling reasons why SL should be seriously considered for certain types of projects. The same can be said for Flash/Flex. Based on my experience, the most critical aspect of this whole debate is knowing the strengths and limitations of either technology and making decisions based on that information. It would be ignorant to say that Flash is always the best solution in every situation or vice versa. Part of our job is to advise and help clients make informed choices. There will come a time in the future where you will be asked whether you think Flash or SL is the more appropriate choice for a project, so be prepared to defend your position.
In my next post, I'll discuss the heart of the issue...Silverlight VS Flash isn't necessarily the right way to approach this discussion of the 2 technologies.
We previously approached this argument from 2 sides: .NET developer and Flash developer. However, maybe that's not the most appropriate perspective on this issue.
I recently came across this discussion (started back in May 2007 but still active as of a week ago) at the Silverlight.net forums. What interested me right away was that the initial poster is a .NET developer. He was asking the Silverlight community for reasons to use Silverlight instead of Flex and specifically looking for "concrete value-add" after he was come up dry of reasons himself. Unfortunately, it largely turned into a flame war after Ted piped up and stated the facts about the Flex side. In the end, I'm not sure much was gained in terms of the initial question (feel free to read it as there are some interesting points made), but it did reinforce something in my mind.
Ever since MS released Silverlight, most of the discussion around Silverlight and Flash has been related to which is the better technology and whether one will win out at the demise of the other. Unfortunately, the argument has revolved largely around programming languages and runtimes and development environments rather than the real issue at hand...ROI for the client.
When we distill it down to the basics of why we do what we do, it all comes down to ROI. After all, that's the reason why we all have projects to work on isn't it? The client is willing to pay money for something that will benefit their company. Breaking that down further, I see 2 basic factors (related to developers like us) affecting ROI:
1. User experience & brand awareness
Obviously, we're all trying to build things in such a way that the user will have a positive experience. The type of experience may vary depending on the goal of the project. For example, an online hotel booking system needs to allow a potential customer to quickly find rooms available for specific dates, with specific parameters, and then follow through with the booking and payment. A microsite for a car manufacturer needs to allow the customer to experience the car and entice them to become emotionally involved with it through the senses. All the while, UI controls need to be intuitive and work like the user expects them to. These are things we strive for as developers.
To that end, if a technology supports a greater feature set, there may be more options to the client in terms of building that experience. For example, being able to adjust bitmap color would allow customizing a product's color. Support for 3D would allow the user to interact with the "virtual" product similar to the way they would the physical product. Integration of rich charting components allows interesting ways for users to visualize data. However, this has nothing to do with AS vs. C# or FlexBuilder vs. Visual Studio. Those distinctions mean nothing to the end user. Also, just because a technology supports more features doesn't necessarily mean they are the *right* features for the project.
In the end, the goal is generally to make a sale or make the user more aware of a brand in a positive way, which may result in a sale (or something intangible like the influence over choices that a user makes) in the future . If the user has a good experience while using the app you've built, regardless of Flash or Silverlight, you've done your part.
2. Development process
This is the piece where we get a lot of passionate discussion about how one technology is better than the other. MS developers are very passionate about their tools, languages and processes. I think Flash & Flex developers are as well, though maybe not to the same degree. But again, let's not lose our focus. For someone to hail their technology as king because it uses a specific language is meaningless. What's important is the ability for a developer to utilize that technology to build what they need to build quickly and intelligently (simplified yes, but that's the general goal).
The key here is efficiency of the development process. In the end, that's what affects the client's bottom line. To make a blanket statement that Visual Studio and C# is better than FlexBuilder and AS doesn't make sense (nor does the opposite argument). However, if you have a team of developers who have honed their process in a given platform, then it would make sense to build using that platform. That's why it does make sense for .NET developers to jump into Silverlight. But to say that Silverlight is better than Flash just because it implements a subset of the .NET framework is again a misguided response. To reiterate, what is the value-add for the client in that statement?
Conclusion
So where does this leave us? Unfortunately, I think the question of whether one technology is better than the other will continue to live on despite the fact that it's not really the right question. Don't get me wrong...I'm a Flash developer at heart and probably will be for a long time, and am passionate about it as most of you are. However, instead of wasting our energies bickering with the "other side", let's use that passion to build better "stuff" and push Adobe and MS to continue developing the tools we need to do that.