Behind Microsoft's Popfly

REDMOND, Wash.—Popfly, Microsoft's mashup tool for non-programmers, stands to tap a ripe market for the software giant. The man behind the idea, John Montgomery, group program manager for Popfly, discusses his thinking on the concept with eWEEK Senior Editor Darryl K. Taft.

So, what was it that prompted you to raise your hand in the first place to deliver this?

There were a couple of things that happened. One was I'd been sitting in developer marketing for a very long time and watching sites like MySpace and Facebook grow and realizing that every person who tricks out their MySpace page is a developer. But Microsoft had no offering for them and, in fact, nobody had an offering for them. The tools … if you look at how you customize a MySpace page, it's awful. It's just not a good experience. And I thought, there's just got to be a better way of doing it.

The second thing was Marie Huwe, who was in developer marketing. One of the things Marie followed closely was how many people were going into college and majoring in computer science, and particularly how many of those people were women.

And what research has shown over the past couple of years is that computer science enrollments are declining, which is a big problem for the IT industry in general and for Microsoft also. But even worse, the paltry number of women who were going into those classes was declining even more rapidly. And I think a lot of it has to do with the way we teach computer science.

I talked with a lot of computer science educators through the process of creating Popfly and it's very well understood now that boys and girls, men and women, learn differently. Males learn through experimentation. They're very comfortable not reading the manual and just going and trying things. Females are much more comfortable when they understand the implications of their actions.

And the problem we have right now is that much of the computer science curricula are still designed around the assumptions that were used around the late '70s and '80s. The curricula are not changing to meet the needs of the current set of employers who are trying to hire people.

Then the third thing was the recognition that if I didn't go and try to build an entirely Web-based tool, probably nobody else at Microsoft was going to try. It appealed to my sense of the ridiculous to go and try to build a tool that ran entirely in a browser.

What were some of your other influences? Meaning, what existing technology did you look at?

I think there were two or three. The first was Visual Basic. And not VB as it exists today, but VB 1.0. It was small, a couple of floppies, it was pretty obvious when you started it what you were supposed to do. You dragged things from the toolbox on the left onto a form that's in the center of the screen and you hung them together with some code. So that was one thing.

The second thing was this site called TryRuby, which was a Ruby interpreter that ran on a server farm but you could connect to it from a browser. And it'll teach you Ruby step-by-step.

And then the third thing was watching MySpace, Facebook and Windows Live Spaces and how people on those environments learned how to customize them. And they didn't learn by following instructions and manuals. They learned by borrowing stealing, pasting together and making mistakes. And I realized that if that's the way people learned we should build a tool that works that way.

And at the time there was no Yahoo Pipes or anything like that. We made up the idea that you could build mashups by dragging blocks onto a form. It was just a totally different way of thinking how to build apps.

Click here to read more about the legend of Popfly.

Do you have a business plan or thoughts on how you might monetize this?

Yeah, there is a bunch of different ways to do it. If you actually look at the current builds of Popfly, when you log in you're going to start seeing placeholders for advertising. And insofar as we intend to monetize this, it's around this as a page you would get when you log in and there'd be a banner ad there. When I visit my profile page, you might see another ad on that page. So that's within the environment.

And then we haven't gone the next step, but you can easily imagine scenarios where we make it very easy to integrate ads into the things you create. For example, the mashup creator. We already have a live ads block and you can actually integrate that into your application today and tell it what you want to search for. So say you search for cheese. And you can build applications that call for that and you could have all kinds of ads for cheese. That might be kind of strange, but definitely workable.

So we're looking at that as our way of monetizing this.

And the nice thing about being the developer division we also have the option of rooting this and saying we're not trying to monetize it, it's more about getting people to try the platform technologies.

When did you know you really had something with this thing you were working on? You blogged that it was after you showed Bob Muglia.

Yeah, when we showed it to Bob, it wasn't anything that looked like this. It was so much less sophisticated. It was much more like a command line interface for making mashups. And he got so excited by what we were doing. His exact quote was '[Go, go, go.' It captured a portion of his imagination.

So the idea that you could take stuff out of Twitter and mash it together with a geo-location service and basically drag and drop to create a mashup that every 30 seconds goes up to Twitter and pulls down the latest last four public posts and gets the latitude and longitude and pushes the whole thing onto a virtual earth map … nobody had this.

In the early days when I was pitching Web services as a marketing guy, this is what I pictured—the idea that you could just take different services and make them talk to each other. This was what I wanted us to go and do as an industry.

And for the people who've been trying to change computer science curricula, it's the same thing. Because they see this and they get very excited because they see this tutorial window over here and as a teaching tool, the concept that a tutorial is built into the product and with the perspective of a social network you can use what others have done. There's this inherent nature of all these applications that they are viral. I create this gadget, you see it, you like it, you want it with photos you customize and you post it to your own thing.

What's the enterprise applicability of this?

I think a lot of the concepts of the UI paradigm would be applicable. Popfly is not targeting that as a segment at all. It's really about Internet mashups. And there are pros and cons with that approach. It's directly in line with what I want to tackle, which is getting people who are already on the Internet to have a custom experience.

Going in the direction of the enterprise is not what we are after. It's a hard problem. If you look at the history of Web services, those intranet scenarios where you pull the data out of your ERP system and to push together the data you have in your proprietary sales database and to update your HR database … to actually create those things [is] complicated. Some day I hope to be able to put the same type of easy to use interface on top of it. But the state of the services themselves isn't there yet. And the state of some fundamental tricky problems, like authentication, non-repudiation, reliability of the messaging and things like that, are not ripe for the plucking yet. Web services aren't that simple yet.

The original version of Popfly was built using the Express products, but the first thing we ran into was when we had a second developer on the team, we were screwed. There was no way for them to separately work on the project and synch their changes back with each other in an efficient way. So we did an upgrade to Visual Studio Team Suite with Microsoft Team Foundation Server running. We connected to TFS and shared everything up there. And we're upgrading to the latest builds of Visual Studio 2008.

Now that Popfly is here and it's getting pretty healthy adoption and lots of accolades, what do you see that it needs? What's on your list of adds?

The wish list is so huge for the things we want to do. I really want to get to a point where it is much easier when you see some kind of a Web site or a Web service to make it programmable from within Popfly. And there are a bunch of technical problems that need to be solved there.

There's the idea that data needs to be free. For instance, governments publish a ton of useful data. The challenge they face is they don't have the budgets to put them into a database that versions and is 'queryable' through Web services and so on. So they tend to publish them as HTML pages or big old XML files. And Popfly needs better tools to be able to reach into those data sources and actually make them useful.

I think a second thing is the ability to embed the creations from Popfly in lots and lots of different places. There is so much more to be done once you've created these things to push them to a lot of different places and have people take them from those places and tweak them on their own and let them have a life of their own.

I still hold out hope that we will be able to partner with some educational institutions and kind of revive what I remember from computer programming classes when I was in junior high school—which was the idea that you could walk into your school's computer lab and start coding. I want to get to a place where we can do that.

If you look at what Silverlight is going to be doing around dynamic languages, there's a huge opening for us to be able to make Popfly much richer. Right now we're supporting Silverlight 1.0, but if we move to 1.1 and we're able to use the dynamic languages that are going to be running on top of that, man, that opens up new doors for us.

What new doors?

JavaScript is one among many languages that people know. Other people know C# and VB and Ruby and Python. And they want to use those languages in Popfly. One of the questions we get from loyal Microsoft customers is, 'Why don't you support VB in this environment?' And the answer is it's an entirely dynamic language environment. We need a technology like Silverlight in order to enable those scenarios.

There's a litany of interesting edge features, but it comes down to I want to make it more social. And I want to make some kind of inroads into, not necessarily changing how AP [advance placement] computer science is taught, but making it so that people who don't want to take AP computer science can still learn how to program and how to interact with the Web and aren't limited by the frameworks that your particular blog provider gives you.

Did you take any cues from any of the existing tools for teaching non-programmers to program?

I talked to the folks who did BlueJ, I talked with the folks who did Alice, and I talked with the folks who did Kids Programming Language. And I walked away from all of those with the same feeling that the problem of how we teach kids who were already interested in computer science was a solved problem. And there were an awful lot of very smart people working on iterating on those solutions.

The second thing that hammered home for me was that for people not interested in actually learning computer science, there wasn't very much that was going to take skills people might already have and teach them structures and concepts in a way that actually had them creating useful things that they wanted to show off.

Because part of the thing about learning to program is at the end you want to be able to show somebody something. It's like learning how to cook. At the end you want to be able to show somebody, hey, look at this cool thing I did, or taste this dish, it's really good.

I kind of felt like a lot of computer science curricula you ended up at the end with nicely chopped onions, nicely chopped carrots, nicely chopped celery and maybe you put it in a sauté pan you wound up with a sofrito, but you hadn't actually finished the dish. And I was more interested in getting to the point where you made the dish.