Microsoft’s Surface Garage: A Cross-Department Development Team, With Pizza And Beer

Despite being the only TechCrunch writer in Seattle, I don’t get out to Microsoft nearly as much as one might expect. The fact is it’s on the other side of a big lake and getting there usually involves a lot of traffic. But when I get an invite like I did recently, to join a sort of unofficial Surface developers’ club for a meeting, it’s hard to say no. The promise of free pizza had nothing to do with my enthusiasm. I like the Surface.

So it was that I got to join a group of developers from all around Microsoft as they spitballed ideas, compared new projects, and developed a new feature as I watched. They didn’t initiate me into the mysteries of the device or swear me to secrecy regarding plans of world domination, but I got to see some cool new Surface apps and contribute to the development of a new feature. Also, they had Alaskan Amber.

I arrived at the Microsoft campus (one of them, anyway) around 6, and after wandering fruitlessly for a short time (navigating corporate architecture isn’t my strong suit) I was captured and conducted to a conference room where a dozen people or so were arrayed around tables as if for a weekly meeting. After some introductions, the purpose of this secret society was explained.

It turns out that some people really just love working with the Surface. So much so that they can’t get enough during working hours! So this recurring event was created, with pizza and refreshments, to make it worth the extra time being put in. There were people from gaming, Windows, Kinect, marketing, a real cross section of Microsoft life.

I was then given a short tour of some things that people in the group had developed in their spare time, for the most part on their own. A simple but versatile pamphlet presentation app, a sort of paperless coffee table, spoke to the Surface’s tragically commercial-only availability:

But one developer, like myself a fan of “shmups,” had put together a rudimentary but promising shooter using real-life tokens to control your ships. You might remember some time back when we went to see a Dungeons and Dragons game for the Surface, complete with figurines, spells, and kobolds. As you can see below and at the top of this article, this game is a bit more frenetic.

The dots emanate from various locations and it’s your job to navigate them. You move your ship around, point it where you want to shoot, and so on. Having a physical item to play with helps address the lack of tactility that occasionally makes touchscreen games so unsatisfying.

Last was an interesting fusion of two innovative Microsoft products: the Surface and the Kinect. This is a sort of “morning briefing” app that is meant to run on your living room’s idle TV, which one can imagine may some day have a touch panel and depth sensing camera built in. Today it was an upright Surface 2.0 and a stock Kinect:

You always see people in movies set in the future talking to their computers, controlling them with a gesture, and so on. This is a small-scale attempt at something like that that people might actually use. When you’re at a distance, it displays large-granularity info like the weather, upcoming appointments, and so on. You can say “mail” and it’ll switch to email, or “calendar Wednesday” and it’ll switch to that. And when you approach, it senses your proximity with the Kinect and switches to a touchscreen mode where you can touch the news and email items and read them.

All put together by one guy, admittedly using APIs developed by hundreds, but a fun demonstration of what’s possible with the project right now.


We then selected a proposed UI element to be coded tonight more or less from scratch. In this case, a sort of drawer menu was desired, something that could display metadata or properties for an item on screen like a photo. It would need some kind of UI cue to let people know it was there, a gesture to activate it and deactivate it, and some basic parameters to make it play well with other elements.

For something as simple as this, there are still tons of design decisions. Right off the bat, there was the “just in time” question. Should the drawer’s “handle” be visible at all times? Should it show up when you tap, drag, or hold the object? How long after should it disappear? I asked if we could use the Surface 2.0’s ability to see things before they touched the screen and “magically” make the handle appear, but there wasn’t enough time to create the brightness-based blob creation I had in mind.

And then there was the question of how far we wanted to dictate how the item was used. We shouldn’t make it right-side-only in case developers wanted to make it ambidextrous, for instance, and it was decided that handle visibility could be made flexible and left up to the software designers. It’s in situations like this that you can see some fundamental differences between how Microsoft and Apple work. A small sample size, admittedly, but it falls in line with the philosophies I observed at work last week in the Explorer ribbon debacle.

First we discussed, then we whiteboarded, then we started coding. And by “we” I mean “they,” because I don’t know anything about it. I did make some suggestions regarding how to monitor certain types of touches, and I thought I had a rather clever idea regarding how to combine the gestures for opening and closing the drawer (we didn’t implement it, despite its brilliance). And piece by piece, with a few hilarious setbacks (including a not-so-hilarious pizza-related one), our UI element took form.

By the end of the night, we could boast that we’d created a box that you could slide out from underneath another box. But its simple operation belied the many details that went into its construction: it was aligned with and moved along with the other UI element, it only pulled out to a certain distance, and it could potentially be filled with content very easily. We’d left ways for it to be configured one way or another, and despite a few bugs it was a working element — from concept to execution in two hours.

And this is why Surface Garage exists. Because it’s fun to create things like this, to see the results of some collaboration and work after a short interval, and know that it was created that way because everyone wanted it that way. After this, someone will pick up the code for the drawer, clean it up, give it a few parameters, and who knows, maybe the next time you see a Surface, our drawer will be lying dormant under the virtual photos scattered in virtual piles on the screen. Maybe you’ll even see something like it in Windows 8.

I’ve often written about how Microsoft tends to smother good ideas in the cradle, or else strangle them with internal conflict. It’s good that groups like this one (surely one of many) exist, as a blowoff valve for developers just interested in creating. They may not be building billion-dollar ideas, but beer, pizza, and time with like-minded colleagues is its own reward.