Creating a Silverlight Application
IDV Solutions is in the middle of building a multi-phased Silverlight demo application, mostly go get to know Silverlight for ourselves. We also wanted to make something we could release publicly at incremental stages of completion. Here is a short comment on my experience so far and some unfounded prognostication…
Baseless Unsubstantiated Forecast
It’s been an interesting learning process and I see a lot of potential (and I suppose inevitability) in Silverlight. Microsoft will undoubtedly grab market share currently held by Flash/Flex and those lingering Java Applets. Why? Developers will migrate in droves. Silverlight is a developer’s product with the addition of design. Flash is a designer’s product that had programmability added to it. There will be piles of developers who feel right at home in Visual Studio who will be more than happy to trade in their ActionScript files. The hurdle will be pulling designers in.
Silverlight and Flash
The comparisons are inevitable. Flash was animation software for vector animation and banner ads that has incrementally been extended with frame based commands and then much more. What is possible now in flash is fantastic and it has been an interesting evolution, but the animation legacy is clear (it’s a serious gear shift for developers to work within enveloped sets of timelines and action paths). And it’s interesting to see the foundation that Microsoft is building without having to support a legacy of passive animation.
Silverlight is much less timeline/frame based. Instead, it recognizes that animations are, in interactive applications, segregated short visual transitions, or motions activated by direct active user control. It was very hard for me to get out of the nested movie-clip mindset (where it is warm and cozy) but I see the merit.
There are several blogs out there that can provide more test-driven discussions of the performance merits of the Silverlight plug in, but in my anecdotal experience it is just as responsive as our Flash client. We loaded our map viewer with points lines and polygons and zoomed and rotated and inflicted general abuse that would have brought an AJAX app to its knees, and it continued to be smooth and responsive.
Division of Labor
Much of the marketing around Blend/Silverlight seems to promote the notion of the separation of specialties. Designers can do what they do best and developers go ahead and do what they do best and the results merge seamlessly into a supersweet application. But I had to work much more closely with our lead developer, Justin Hoffman, on this Silverlight demo than I have with any Flash project. Probably because I am a relative stranger to the .NET development environment and any visual content I made came after rounds of tentative creation and second guessing. "How do I integrate this…how you say…markup?" About half of the man-hours spent were at the same workstation sketching, debating, and waving hands. Silverlight will be similar to Flash in that for a person or organization to really nail an application, they had better be good at design and development. Silverlight should please artistic developers, while Flash will be a favorite of relatively tech-savvy designers into the near future. In all, I am terribly happy with how it is going, and we have had some good feedback from the public.
Following the initial learning curve, creating Silverlight applications with Blend and Visual Studio will likely be a welcome transition for our developers. For me, it will be a tougher transition, as I suppose it will be of many other UX/interaction designers. But I am happy with the level of support the Blend editor provides for creating the Silverlight XAML (especially the June Preview with enhanced Control Template editing), especially considering that these products are still in beta -people are making some very cool things. More to come. It is a fun time to be in the business.