It’s rare that I opine on my blog, but since we’ve recently been able to talk openly about our involvement with Microsoft Surface, I’ve been feeling like it’s worth discussing this much-maligned creature. People seem to treat it a bit like Michael Jackson — a reclusive enigma, rarely seen in the wild, impossible to capture on film, difficult to understand. But there seem to be no shortage of initiatives aiming to bring the “Surface experience” into the hands of the many, not just the privileged few.

Now, we’re fairly platform agnostic over at Stimulant — we’ve had a chance to work with the most homebrew of systems all the way up to some of the most polished. Surface is just one of many tools in our arsenal, but I feel like it’s a bit misunderstood. Sure you can build your own multitouch system for the price of a Wii remote, a projector and a laptop. But that’s about where the similarities end. Even higher end multitouch systems seem to either ignore or miss some of the finer points of Surface, and that’s what I’d like to discuss.

Surface > Multitouch

Yes, Surface senses a multiple touches. But it’s also inherently multi-user (given its flat orientation) and most interestingly, it features object recognition. The last one there seems to be one of the most overlooked features of Surface. Beyond blob detection, Surface can recognize a finger and determine in which direction that finger is pointing. Most infrared-based multi-touch systems are happy to get a blob at all, and call it a day. Beyond that, the cameras housed inside (with help from some smart software) can can recognize unique shapes, as well as read data from “domino” tags — small 3/4″ stickers with a series of dots on them that encode a short identifier. These tags could theoretically be printed or engraved on physical items as well, enabling an easy way to interface with said objects. This thinking “beyond the blob” really sets Surface apart in its capabilities — at least with regard to other offerings out there today. It adds a level of richness to the user experience (when leveraged properly, of course) that I’ve yet to see equaled elsewhere.

Easy to build

There are a smattering of open source frameworks showing up that enable multitouch hacking, from players such as NUIGroup and Ideo, and I applaud them all. But none of them feature a rich and full SDK that comes with well-thought out controls — it not only makes rapid prototyping easy, it enforces evolving best practices for user interaction. Plus, you’ve got the enitre .NET 3.5 platform at your fingertips. Admittedly, there’s a very sharp learning curve for folks who haven’t dabbled in Windows Presentation Foundation. But we’ve seen first-hand how much effort is going in to testing, developing and documenting this SDK. Think of what the iPhone SDK did to enable and “standardize” user experiences for 3rd party application development on the iPhone. It’s like that, only for a big-ass table.

Also worth mentioning that Surface can also be programmed against using XNA, which, though lacking any sort of UI controls or safety nets, opens Surface hacking up to a world of game developers already familiar with the framework.

I’m hoping that we will see these open source SDKs evolve into something as polished as the iPhone or Surface SDK, but until then, it seems like there’s something to be said for the cathedral over the bazaar.

Built to Last

The world of “installation computing” is a mixed bag. On one hand, you’ve got complete control over the hardware, so there’s no worrying about tweaking your app for the odd edge case. On the other hand, when something breaks, you can guess who’s getting a phone call. So given an opportunity to design and install and application that needs to persist in a public space, if you’re smart, you’re going to go with the burliest, most bulletproof, battle-tested option. The homebrew and grassroots options out there are amazingly functional, but whose pager goes off when a mac mini melts down or someone kicks the box and the webcamera gets out of alignment? If you’re playing with Surface, Microsoft is offering a solid level of on-site support for its units. That’s enough to let me sleep soundly at night.

Not to mention that Surface units are built to support the weight of a full human, withstand spilled drinks and survive rough play. The whole thing is built like a tank, and it’s been through multiple design revs so while you may laugh at that form factor, you’ll thank Microsoft for having put these things through years of the lather/rinse/repeat cycle to get it where it is today. Sure, it’s not perfect, but I’d have a hard time deploying a Cubit in a public space in a remote city where someone wasn’t there to tend to it night and day. These DIY pieces are fantastic for development and exploration, but I’m not so sure about permanent installation. It’s a frustrating conundrum — you can build an inexpensive system to play with, but where do you deploy your work? Ah, life on the bleeding edge.

Now, don’t get me wrong, I’m a complete supporter of every single effort out there exploring these new interaction paradigms; heck, we’re building our company around just these kinds of hardware solutions. The more people that start working in the arena, the faster the technology makes its way into the mainstream, and the more familiar these solutions get, the lower the barrier for designing solutions that can be enjoyed and used successfully by a larger audience. I merely wanted to highlight some of the characteristics of Surface that seem to go unmentioned in most discussions, all of which are why we’re particularly excited about this platform. I expect that we’ll be hacking together several franken-systems over time because we like to play, too. But when showtime hits, it’s nice to know there’s a piece of hardware out there that has our back.

I’m a fairly committed Yugma user for conferencing, screensharing and remote desktop control (it works really well around firewalls), but my recent upgrade to Vista had rendered the app unstartable. The app would always quit on startup with the following error:

Application cannot run without client.properties file

I contacted Yugma support, and was informed that this bug was only happening to less than 1% of their Vista users, and that they were unable to reproduce — hence, there would be no fix. Undeterred, I’ve been Googling for a fix for a while now, and today happened to stumble upon this post by Alessandro Vernet with regard to getting the app up and running on the Mac. Heartened that it might simply be a missing file problem, I quickly scanned my Yugma dir (located in my userdir on C:\), but found the client.properties file right where one would expect it to be.

Next step was to run Process Monitor, one of my favorite low-level Windows debugging tools, to see what file the app was actually requesting. Turns out that many of the requests for that file were successful, but 1 request was being made on the E:\ drive for:

E:\Users\darren\AppData\LocalLow\ Yugma\properties\client.properties

Eh? Well it turns out that I had moved my Vista user dirs to another drive, and while Yugma installs to C:\Users\darren\Yugma by default, there is code in the app that seems to trust Vista with regard to where the userdir is. Well, my janky solution was to copy the entire Yugma dir to the E:\ drive location, and it worked like a charm.

I’m not sure this a long-term solution, but hopefully it will help Yugma correct the problem for other users.

Mike Swanson ( of Illustrator-to-XAML exporter-plugin fame, my most-used AI plugin to date) just released some bits implementing seam carving in .NET. Very impressive. I’m anxious to see if and how this can be segued in with live code, especially in a multitouch scenario.

Back from a 2 week hiatus in Nicaragua and I’m feeling refreshed and rejuvenated (and only a touch rum-soaked )

Some cool Silverlight demos and meta-sites I’ve stumbled upon since my return:

• Chris Craft is compiling a very comprehensive list of Silverlight links
• Chris Cavanagh has a port of the Managed Bullet physics engine for Silverlight 1.1, complete with source code (nice!)
• A whole stack of how-to videos at Silverlight.net

2007 was the sophomore effort for Microsoft’s MIX conference, and I must say, the sequel was better than the original. I spoke at MIX last year, when things like WPF and the Expression Suite were still in their infancy, and I think the audience approached new ideas with caution and skepticism. With Vista finally out the door and real-world applications and tools starting to mature, the vibe this year was one of strong interest and excitement. The products had already sold themselves; people were ready to dive in. Production quality was high, the keynote was tight, and the sessions were really well-thought out.

The announcements about Silverlight clearly stole the show. Having worked in WPF for several years now (and Flash for many more than that) it’s truly exciting to see the seeds of parity starting to be sown with regard to cross-platform deployment for .NET applications. I was highly skeptical of WPF/e when it was first shown at PDC 2005; it was so far from WPF that I was amazed it garnered that moniker ( “In-browser XAML-Lite” was more appropriate). Now that plans are under way to make a reasonable subset of the .NET framework run cross-browser and cross-platform, we’ve got a real contender in the works. Perf is impressive, media support is rich and the programming model is not too far from what I’ve come to expect from WPF.

I was also extremely impressed that Microsoft managed to make an alpha version of the player and an SDK available in time for the conference. I mean, we can actually start playing with this stuff, even though it will be probably more than a year before it’s ready for prime time (my best guess). Here’s the long and the short of it:

What you get:

• Canvas-based layout
• Solid cross-browser HTML DOM support
• Rudimentary controls
• HTTP networking + XML
• Web Service support
• LINQ
• Ruby & Python scripting via the DLR (insane!)

Noticeably absent (but in the works):

• TextBox control (for text input)
• Rich control set
• Layout management
• Databinding
• Styling

Nice-to-haves that aren’t planned for inclusion

• 3D
• Hardware acceleration

Unfortunately, my 3 favorite things about WPF (layout, styling and databinding) are the ones that have yet to be included in the platform. Basically this means there’s not much you can do in Silverlight 1.1 right now that can’t be done in Flash/Flex (tho 720p WMV streaming is soooo sweet). If you’re already familiar with XAML/C# (and there aren’t a lot of you out there), then you’re going to be able to dig in pretty quickly, but I don’t think there’s much here for advanced Flash devs that’s going to wow them. Fast forward to a year from now, and if Microsoft fills in the blanks per the roadmap, and you’ve got a cross-platform story that, IMO, is going to find a lot more devs building Silverlight apps than Flex apps. That said, Flash Player 9 is rapidly approaching 90% penetration, so Microsoft had best get crackin’ on building a user base.

I don’t have the full lowdown on what Moxie brings to the table, but I think that now that Microsoft and Adobe both have a declarative-markup-based programming model for UI development, we can officially say “It’s on!”.