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.
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:
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:
- 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.
- 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.
- 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.
- 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.
- 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".
- 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!