Q&A with Microsoft's Jay Schmelzer
Jay Schmelzer, director of program management for Visual Studio at Microsoft, gave the opening day keynote address at the Visual Studio Live! Chicago conference Tuesday morning. I caught up with Schmelzer after his presentation (watch the video here) to ask him about Visual Studio LightSwitch, the move away from Silverlight and the new Apps for Office programming model.
Michael Desmond: If you had one message that you'd like attendees to take away from keynote address today, what would it be?
Jay Schmelzer: For application developers, it would be the realization that it's a multi-device world. As much as we would want and love for everyone to be carrying Windows devices, we know it's the consumer's choice, and developers need an experience for supporting that.
I would say the other aspect of this is wanting everybody to realize that hey, the investments we've made in managed languages, VB, C#, .NET--those assets will continue to evolve and will help them to continue to modernize their apps and adapt them to the devices they need and the services they need to build. Those are investments people should feel confident in and continue to invest in.
MD: Platform confidence is of course such an important thing and has been a core strength for Microsoft in its relationship with developers. But didn't the retirement of Silverlight shaken that confidence a bit?
JS: I step back and look at it and say, 'it was really more that the entire RIA plug-in model. In hindsight had a lifespan." Whether it's Silverlight, whether it's Flash, they all are facing the same challenges, where they are dependent on devices supporting them. We could have at Microsoft decided to keep supporting [Silverlight] on our devices, but then a big chunk of its reason for existence is gone. It's not going to do what you need it to do, because I can't make Apple support it forever.
This whole category, rather than being one player in it, is going away. So now we have to help developers evolve to the next thing. It's got a support life that's still quite far out there—the standard five by five [years]—so those assets will continue. And now it's time to consider what is the evolution of that app.
MD: You talked about multi-device support and the choices organizations need to make to enable it. Are you seeing organizations struggle with those choices?
So if you have an app that doesn't require lots of native capabilities of the device but you need to support multiple [devices], then we have tools like LightSwitch which will create a standards-based HTML client that will run on all these devices. And for a business app, a client-based business app, that's actually all you need.
And then we have partners like Xamarin and folks like that who can come in and provide other experiences for getting native within Visual Studio using our stuff.
MD: At one point during the keynote you had asked how many people were aware of LightSwitch. How many hands went up?
JS: I would say maybe 20 percent. I wish I could say it was lower than I expected, but I've asked that question a lot and I've seen that a lot, so I was kind of expecting it.
Some of it goes back to our other conversation on Silverlight. LightSwitch, the first version of it, came out right when the uncertainty of Silverlight was at its peak, and that is what we supported at the time. That was part of it.
We are seeing an uptick just in terms of traffic to our site, traffic in community forums and places like that now that the HTML client is out there and people see where we are going.
MD: Can you talk about how the audience for LightSwitch has evolved? Your keynote certainly positioned LightSwitch as a professional developer's tool.
JS: One of the things that we realized is that we originally targeted an audience that wasn't a Visual Studio customer, but we were branded as a Visual Studio product. That presented some challenges. We still believe that that audience is important, we still keep simplicity and productivity as the key part of our design philosophy for LightSwitch. But we also realize that hey, we are part of the Visual Studio family, so one of the things we have to be able to do is have LightSwitch work in a model that works for developer workflow.
That means things like being better in a team environment, having multiple people working together on a project, working better with the lifecycle tools. So that's an area where we've shifted our focus a bit and said let's make sure these productivity features and experiences work well for professional developers. Nobody would want to spend eight hours doing something they could do in eight minutes, as long as it works within their tool chain.
MD: How important is LightSwitch support for HTML apps in all this?
MD: So do you expect more hands to go up next time you ask a Visual Studio Live! crowd about their awareness of LightSwitch?
JS: I definitely do. I think we've got a number of things coming out that we aren't ready to talk about yet--but probably in the BUILD time--that will get some folks more excited and really understand where we are going with this. I'm hoping next year we come back and I see at least 50 percent of the hands in the air. I think the question for next year will actually be how many people are using it, and we will see probably 50 percent of this kind of audience saying they are using it for something.
MD: And LightSwitch can be used in conjunction with other tools, of course. So you can leverage it where it's needed.
JS: We have examples of folks who build really large applications that use LightSwitch for a portion of it, where it's the table maintenance part of the app, right, where you have lookup values and things like that. And you have to create UI to manage that. You don't really want to go spend 40 hours building that when you could just knock it out in 20 minutes.
Those are other things that we do, patterns people develop where they custom build a core part of it, but there's LightSwitch for everything around it. In fact, every LightSwitch app I've ever seen has got some percentage of the app where they went and took control of that thing completely, the UI or whatever, because that's the part that required the custom work.
MD: How is the new Office and SharePoint app model being received by developers?
JS: I'm seeing two reactions. One, the folks who have never done SharePoint development or Office development are saying this is something I can take a look at now. It does look more like something I'm used to. So that's good.
The folks who have been deep in things like SharePoint and Office, I'd say they're ones who are excited about the model and the pattern. They're now in the phase of trying to map what they used to do to the new world. Because in a lot of ways it changes it pretty dramatically from what they used to do.
MD: How does the new Apps for Office model relate to Visual Basic for Applications (VBA) and Visual Studio Tools for Office (VSTO) apps?
JS: I was talking with a gentleman after the keynote who said he has a lot of VBA and VSTO applications in Excel and can they just kind of move over. And well, it kind of depends on what you are doing. VBA and to an extent VSTO--the old object model--had a lot of automation capabilities in the object model. You could make Excel do things. That's not part of the new model. The new model isn't about making Excel do something, it's about leveraging a service with Excel.
So if your app was all about the calc engine in Excel and putting the data in and out and letting the calc engine do its thing, then OK, the new model is going to work great for that. If you were basically automating a bunch of manual steps through a macro, that's not going to work with the new model. That's not what it's designed for.
Those existing approaches still work and are fully supported in the rich client versions. But that's what we're seeing, is people having to go back and rethink how they accomplish what the app used to do in the new world.
MD: And the new model cleans up some of the problems that could crop up when upgrading to a new version of Office, right?
JS: That was always a pain for app developers. I've got to go test my app for the new version of Office before I can get rolled out. Now [with Apps for Office] it's just a service interface that we need to keep consistent, as opposed to the wacky things that can happen when you're running in the process of another app. Developers are seeing this as a huge benefit.
MD: Thanks again for your time, Jay. Anything else you'd like to address before we close?
JS: We touched on this a few times. The .NET Framework, CLR, VB/C# are core developer assets of Microsoft. We are absolutely continuing to invest, evolve and innovate in those. Customers really shouldn't question their investments there. They should have confidence that we are going to continue to be there and continue to evolve that.
The scope and the size of the enhancements are dramatically smaller than they used to be, but that's more a sign that it's a mature framework. It's a mature platform. We don't need to go and double the size of the base class libraries every time, because they're rich, their pretty complete. In some cases that's actually a benefit to an application developer. In the past we've heard that things were evolving so fast that they couldn't keep up. We feel like we got ourselves to a pretty good point.
Posted by Michael Desmond on 05/14/2013 at 1:16 PM