Shawn Burke's Blog

Pushing the new stuff

Control Freak.

Control Freak.

  • Comments 48

Hmmm...no blogging lately...what has Shawn been up to? 

Yes, guilty.  But here's what's been going on over the past few months.  Shortly after MIX07, ScottGu brought up an idea of building a larger team focused on building controls.  We kicked this idea around for while as we talked about details, timelines, and goals.  In April, most of these details were worked out and we hashed out a charter and some early areas of focus and deliverables.

The problem we saw was that we had a bit of a fragmented controls story.  My team (the Agility Team that brought you the AJAX Control Toolkit, etc.) had been writing some controls.  The core Silverlight team was writing some controls.  The UIFX Team (which brought you ASP.NET and Windows Forms) was writing some controls.  The WPF team was writing controls.  You get the idea.  So Scott asked me to build a team that would unify these various efforts, in strategy if not in implementation.  And the Controls Team was born on April 28th, 2008.  After reporting to Scott for a little over two years, my team and I popped down to report to Ian Ellison Taylor, GM of the WPF and Silverlight teams and veteran of all things "UI-Platform" at Microsoft for over 15 years.

Sooooo...what exactly will you be doing?

Good question.  My team owns the charter for both Silverlight and WPF control development.  That means doing most of the engineering, planning, and development of controls.  But it also means figuring out other ways to get controls into the toolbox for developers to use.  For example, if another team is developing a control that might be generally useful, we'll try to figure out a way to get it into our deliverable.

The team is being built mostly from scratch.  So while we are ramping up and getting people hired in, we're focusing primarily on Silverlight controls.  Meanwhile, I have been working with the WPF folks helping them get some controls delivered to - the first of which is the DataGrid now available via the WPFToolkit.  I am definitely committed to improving the controls story on WPF as well.

One of the reasons Scott asked me to build this team is to continue the work we've been doing around pioneering transparency and agility in our software development process here at Microsoft.  The open model of the AJAX Control Toolkit really broke a lot of new ground, and we continued some of that with the Silverlight 2 Beta 1 Controls we did when we shipped not only buildable source, but our unit testing harness, and tests too!

Who is on this team you speak of?

All Stars.  Some of them you may already be familiar with. 

David Anson, Ted Glaza, Jeff Wilcox, Ning Zhang, Mehdi Slaoui Andaloussi, Beatriz Stollnitz (Costa), Justin-Josef Angel, Jafar Husain, Shawn Oster, Keith Smith, and just this week, Ruurd Boeke.

That's some horsepower right there, I tell you what.  I really couldn't ask for better people, and we've got more to hire!

What about the AJAX Control Toolkit?

The AJAX Control Toolkit is in good hands.  We've transferred ownership over to the ASP.NET team, and Bertrand is leading the effort.  They've already started making good progress and I'm very excited about what they're planning for the future.

Okay, so when will you be shipping something?

Right.  Good question.  We are currently working on a set of controls for a preview release at PDC 2008 in late October.  This will be a preview release, but we feel good about the quality bar that we think we can hit nonetheless.  Because we're using a slight different development model, our controls will be released earlier, improve evolutionarily over time, so there isn't a clear "RTM" date for them.  But in any case, we're doing a preview at PDC. 

Here's a list of the Silverlight controls we are currently working on that we think will be ready.  We are working on some other components as well, but I'm leaving them off the list until we have higher-confidence about them being ready:

  • DockPanel
  • WrapPanel
  • ViewBox
  • Label
  • HeaderedContentControl
  • Expander
  • TreeView
  • NumericUpDown
  • AutoComplete
  • Accordion

All of these controls will use the new Visual State Manager templating model and be fully customizable in XAML by hand or through Expression Blend.  They will also ship with full, buildable source, unit tests, and an updated unit testing harness nicely wrapped up with a tasty OSI-Approved MS-PL license.

Wait as second...what's this 'slightly different' model?

Another good question.  Part of it, as noted above, is that we're going to be aggressive about shipping early and shipping source.  We'll be leveraging many of the learnings from the AJAX Control Toolkit as well as the SL2 B1 Controls efforts.

Basically, it is based on an iterative, customer-centric delivery model that focuses on driving out the most critical customer issues over time.

Sometime between now and PDC, we will be launching a CodePlex project for our Silverlight components (as a sibling of the WPF project mentioned above).

Here's how it works:

  1. When a new component reaches "80%" quality - that is it meets the scenario needs of ~80% of customers - it will be added to the project.
  2. The project will have frequent releases when there is a critical mass of customer value (say, bug fixes or new components) that justifies a release.  Think every 6-8 weeks or so.
  3. Each release will include the components, documentation, sample code, and unit tests.  You, as the user are free to modify, copy, or redistribute the components however you see fit.
  4. Customers will file bugs/issues with the components via the CodePlex Issue Tracker.  Issue Tracker has a great voting facility built in.  We will prioritize our bug fixing and/or enhancement work based heavily on this voting.  Highly voted-for issues get fixed first, with some discretion based on cost/complexity.  For example, if the #2, #3, and #4 issues are easy fixes, they may get done ahead of a complex and difficult #1 issue, for a particular release.
  5. A given component, over time, will reach a very high quality level.  Throughout this process, two things will happen.  First, the "bar" for fixing a bug will go up.  That means, as the component stabilizes, we will be more-and-more careful about which fixes we accept.  Second, and as a corollary to the first, as the component stabilizes, we will be enforcing a stricter-and-stricter bar with respect to breaking changes.  This will happen pretty quickly.  A component that is "new" may have some amount of API changes as we react to feedback.  But after a release or two, we will lock down the API and behavior so that these components are very stable and easy for users to upgrade as new releases come out.  This is critical.  We're working on a way of marking (think metadata attributes and docs) each component to call out which  "stage" it's in, but the goal is to get them API stable relatively quickly.  Because we do frequent releases, upgrading to each new release has to be a "no-brainer".
  6. For all new components, goto (1)

So over time you have a rolling release that is getting more and more featureful.  I don't know if 'featureful' is a word but if it's not, I'm coining it as a term right here!  Anyway, you get the idea.  If you want just the "baked" stuff, you can stick to the mature components.  If you have a need for another newer component, you can use those too.   It's up to you.

Over time, you will see some (maybe many) of these components work their way into either the Silverlight Core, or the Silverlight SDK as fully-supported components like you are used to.  That's the beauty of this model - it offers quick delivery at the front end for more cutting-edge customers, and the traditional "I got it with VS" model for customers that prefer that.

When we start focusing on WPF components in the future, we'll be following a very similar model.  Just replace "Silverlight Core/SDK" with ".NET Framework" and you'll get the idea.

In contrast to the AJAX Control Toolkit, we will *not* be accepting any customer contributions of fixes into the code base.

So that's what I've been up to.  It's very exciting, stay tuned for more details!

Leave a Comment
  • Please add 7 and 8 and type the answer here:
  • Post
  • PingBack from http://www.easycoded.com/control-freak/

  • Jeff Weber released "Diver", Mike Snow on Bookmarks and Terence Tsang on 3D Image Space. Want

  • Why won't you be accepting community contributions ala AJAX Control Toolkit or IronRuby? Is this decision final or is there hope for this to change in the future?

  • Shawn Burke's Blog : Control Freak PDC 2008 で Silverlight 2 の追加コントロールのプレビュー版がリリースされるようです。 Microsoft Public

  • You've been kicked (a good thing) - Trackback from DotNetKicks.com

  • @Mike - The main reason is because we want to make sure some of these controls can eventually ship in the core Silverlight install, Visual Studio, etc.  As it stands, we can't do that with projects that have externally-contributed code.  

  • Microsoft Introduces the Silverlight/WPF Controls Team

  • @Mike Moore: If you contribute code to an open source project you (most of the time) still hold the copyright for the work. Some projects makes you give away all copyright and IP before committing.

    If they accepted external contributions it might be harder to move the controls into the WPF/Silverlight core frameworks, as the code might contain IP and copyrighted material from external developers.

    This is for instance the reason you can expect to see IronRuby shipping as part of Visual Studio, as it's developed as a "true" open source project on Ruby Forge, with external contributors etc.

    Perhaps Shawn could elaborate a little more on this?

  • Post: Approved at: Sep-18-2008 Silverlight Game: Diver While this Silverlight game can be entertaining

  • Hi Shawn,

    not sure why but your post doesn't quite surface anywhere, especially not on the Silverlight forums. Luckily enough I found it somewhere in my unread blog items. Anyway, sounds like a good plan you got going on.

    What I do notice though is that none of the controls you mentioned are on the wish lists maintained on the forums. Microsoft people actually asked the forum members to create these and they've been really active in doing so.

    Now, the fact that you release a control set is obviously a good thing. How do you explain to the forum members that none of their requests are actually in this release?

    Again, no offence. Any control building activity is a good thing. Just wondering though.

    Ps. Also, why is there a new "label" control when a normal textblock basically is the same?

    Ps2. Have some doubts about other controls as well. Are you going to elaborate on them in later posts?

  • @Nathan - the news will get around over time...

    Good questions, here's some insight into the process from my POV.

    I'm not sure which wishlist you're referring to.  Is it this one (http://silverlight.net/forums/t/23014.aspx)?  This is the first I've heard/seen this so any ignoring here was by accident not by design.

    If so, 1 will be in the next version, 4 & 8 are in post-B2 SL builds.  The rest are things that need to be done in the SL core itself and I know the core team is aware of, some of which will be in the SL 2 release.

    But here's how we decided on this list of controls:

    1) Critical components that people are used to in WPF

    2) Requests from user feedback sessions (e.g. TreeView has been a frequerequest)

    3) Since we're building a team and ramping people up, and were looking at a pretty short timeline between team creation an PDC, I wanted to stick to "basic" controls that we could execute well on and achieve some early success before moving on to more complex components as the team and team members mature.

    Hope that helps.  If there are other wishlists around for controls,  please send me the links so we can add them to our prioritization matrix!

  • You mention WPF at the end - but why not attempt a shared source with two targets?  Incompatibility at the control level is going to make SL2/WPF interop really difficult.

  • @joewood

    We will be doing as much sharing as we can, but it's not quite a simple as it sounds.  On the WPF side, you want to be able to write a control that takes advantage of WPF (Triggers, 3D, etc), and on the Silverlight side there are enough small differences that this is hard. We do have some controls that can cross-compile (see B1 ListBox), but in any case it's best to start with the SL control then do the WPF one so you don't end up relying on things not available on SL.

  • Oh - just to be clear.  Shared sourcing is orthogonal to API/behavior compat between SL/WPF. We're definitely making things compatible even if the impl is slightly different.

  • Great post Shawn, looking forward to seeing the new stuff.  Quick question: when will us WPF developers get to take advantage of the Visual State Manager goodness?

Page 1 of 4 (48 items) 1234