Tuesday, February 22, 2011

An Interview with Jeff Wilcox

Jeff is a Senior Software Development Engineer at Microsoft, on the Silverlight Phone & Devices Team. A founding member of the Silverlight Toolkit team, Jeff runs the Silverlight for Windows Phone Toolkit, created several controls in the Silverlight and Windows Phone SDKs, and wrote the Silverlight Unit Test Framework. Jeff lives in Seattle, WA, USA.  You can find more from Jeff at www.jeff.wilcox.name

I interviewed Jeff about his work with Silverlight, the Silverlight Toolkit, and his ongoing efforts at Microsoft.  Though unofficial, below are his thoughts on the subject.

Q. I understand you were a major player in the creation of the Silverlight Toolkit.  Is that still going on, or what are you doing now?
A. We last shipped a desktop Silverlight Toolkit in April 2010, and it's received hundreds of thousands of downloads. Since then, we've all been focusing on the Silverlight for Windows Phone - both the app platform as well as building the initial Silverlight for Windows Phone Toolkit.

We just shipped the latest Silverlight for Windows Phone Toolkit last week, it's called the February 2011 release. It shares some code with the desktop toolkit, such as WrapPanel and AutoCompleteBox.

A lot of the early work we did on the Windows Phone application platform really ended up helping us better understand the unique performance considerations for the phone, and the phone toolkit is being used by a majority of the important phone apps out there like Twitter and Facebook.

Q. The Silverlight Toolkit is a brilliant collection of free controls.  I'm sure it has taken a long, long time to build them all.  What tips could you give other control developers looking to build controls of the same quality?
A. One of the best things we did early was try and make it clear that the Silverlight Toolkit is a special product: it isn't an officially supported product, and that allows us to define the quality bands (such as experimental, and mature). By offering the source code, we allow people who find important issues to make the fixes they need, but it also lets us ship controls like the Accordion that maybe weren't at the highest level of quality yet.

I believe the most important thing other developers can do is try and really grok what it means to build a lookless control: it's a unique skill, there are a lot of design decisions to be made, and you really just need to practice. Doing application building, along with a set of controls for that app, is a great way to get up to speed on control dev.

So lots of practice.

I also have often referred people to the control source code at http://silverlight.codeplex.com/ - yeah, there are some bugs, but it's a good set of different concepts, strategies, and a starting place. The "Common" code files and helpers often end up in other people's controls, they're really helpful for working with the visual tree, visual state manager, etc.

We actually had a number of challenges, if you look through the source code you can tell that there are distinct developers who worked on the project, and it's always a lot of fun (heated arguments included) trying to define the guidelines, what code style we like, and working together on such a big set of deliverables, but over time it all came together.

Now we're mostly just looking at the future and the Windows Phone work has been a fun way to see just how easily it is to reuse those same Silverlight skills. Biggest difference is considering the form factor, touch manipulations, and concepts that don't make sense on the phone (like focus).

Q. From my own experience, there are times when you're building an app that is very small in nature and you don't want unused components adding to the XAP size.  Perhaps it's an obsession on my part.  A couple developers always laughed when I described the effort that went into making Regex Hero under 50 KB at one point in time.  But what do you think of the SilverlightXAP approach of offering individual controls not a part of a larger control suite?
A. There's a lot to be said about the model. If you look at SilverlightXAP and code paste sites and NuGet.org, you find that .NET developers do enjoy a really simple way to get individual components, outside of a suite.

It also lets people mix and match components, and just keep what works for them, without heavy dependencies. I really like that.

Q. Silverlight is being used today on Windows, Mac, and Windows Phone 7.  I hear rumors it's coming to the XBOX 360, and my toaster oven.  I'd love for it to be on everything.  But where would you like to see Silverlight next?
A. While you are correct, we're on Mac, Windows, and Windows Phone 7 today, I can't comment on any official roadmap for where things are headed.

We're always experimenting on the development team - it's a pretty good collection of really smart developers. I don't think a lot of people understand just how much of Silverlight is written in native code. That is a great benefit to us, because it enables us to consider moving to other platforms as business needs dictate.

On the Silverlight Phone & Devices Team, we're hiring actually - http://bit.ly/sldevicedevjob :-)

No comments:

Post a Comment