Mixed Feelings about Silverlight

I spent all day yesterday at the Microsoft Silverlight FireStarter event. (You can see the decks here, and the recordings will be up shortly.) It was an appropriate place for me to be hanging out, since Alanta, my current startup, is working to build a web conferencing system on Silverlight. I came away from the day with a variety of mixed feelings.

First, I realized that not only do I have a lot to learn, but what I don't know is hurting me. If I knew the tools and frameworks better, I could make a lot faster progress on our product, and the resulting code would be better architected and more maintainable. The demo that Adam Kinney did on Blend made me realize just how crappy my own Blend skills are, and how I could be a ton more productive if I knew Blend better. Similarly, the stuff that Marco Matos did with the Silverlight Toolkit, and Karl Shifflet's demo of his XAML PowerToys.

I also felt grateful to Microsoft (in general) and to the people who put on the event (very specifically). They've pretty much dedicated their lives to creating tools and frameworks and platforms for the rest of us to use, to make our lives easier or better in some way. And when, like me, you spend more than half your waking hours working with those particular tools and frameworks and platforms, that's not something you can just take for granted. It's something to be thankful for.

At the same time, I think I spent more time at the event feeling frustrated than anything else. I've said before that you know a product is succeeding when people start complaining about it; and by that standard, Silverlight is a very successful product. Here are my top three complaints about the current state of Silverlight and its tools:

1. Silverlight databinding is a mess. This is partly due to the fact that it is missing many of the features of its more powerful cousin, WPF databinding. But databinding in both Silverlight and WPF suffer from the same underlying problem: it's incredibly difficult to get right, very easy to get wrong, and MS provides provides no troubleshooting help at all. As I've said elsewhere (here and here), I think the biggest underlying problem with the current databinding implementation is that it's untyped, i.e., you never specify the type of the DataContext your XAML is expecting. As a result, there's no Intellisense to help you when you define your bindings, and no design-time or compile-time checking to make sure you got them right. I could probably live with this limitation if Microsoft provided better tools and frameworks for runtime troubleshooting. But at runtime, any binding errors get swallowed entirely and completely. A very few of them will show up in the Visual Studio debug window, but you have absolutely no insight into the vast majority of things that might go wrong. Even if MS thought that it was too big of a switch to move to a strongly-typed DataContext, they should at the very least, for the sake of all that is holy, have their controls raise an event when something goes wrong, so that you have some opportunity to see and respond to what might be happening. I can't express strongly enough how absolutely insane it is that we're about to see version 4 of Silverlight, and Microsoft still hasn't fixed this basic, fundamental problem. I spend enormous amounts of time troubleshooting databindings, and it's the primary reason why we've only partially adopted an MVVM architecture for Alanta. I spend enough of my time troubleshooting WCF, which is complicated and annoying, but at least it provides real errors. There's not enough time in the day to guess (and guess and guess and guess again) what might be going wrong with my databindings.
   
   I should note that Tim Heuer, frequently the face of Silverlight to the world, was able to sympathize with these problems yesterday. He pointed me Glimpse, a recent tool from Karl Shifflett, that provides some insight into what's happening under the hood with databinding errors. I haven't had the chance to try it out yet, but it seems like a step in the right direction. Still, "not sucking quite so horribly" doesn't equal "sufficient", least of all "good".
   
   Microsoft and the rest of the community is making a huge push towards MVVM as the standard development model for Silverlight and WPF. That makes sense: but its adoption by average, everyday developers will remain limited until MS is able to fix their databinding experience.
   
   
2. Blend is a mess. Yes, it's incredibly powerful. And yes, V3 is much, much better than V2. And it goes without saying that it's better than Visual Studio for UI design. But as the premiere MS tool for designing great user experiences, it shows an astonishing lack of appreciation of what makes for a great user experience. To take just a couple examples:
   
   1. In the picture below, try to guess which of the two tabs ("FileRowControl" or "FileManagerControl") is selected. Is it the one on the left whose bold, dark color seems to flow uninterrupted into the workspace? Or is it the one on the right whose light gray color, everywhere else in the Windows UI, indicates "disabled"? Astonishingly, it's the tab on the right that's selected. I've been working with Blend for months now, and every time I have to look at the open file tabs, I have to stop and think which one is actually selected. That's inexcusable for a company with as many design resources as Microsoft.
       
      
   2. Here's a fairly standard property panel in Blend:
       
      Now, somewhere in this panel is a way to set these properties in an advanced fashion, i.e., through databinding or other similar techniques. Care to hazard a guess as to how you do that? Might one, perhaps, right-click and see some options for doing so? Nope, no right-click menu is available. Give up? Well, I'm astonished that you missed the tiny little two-pixel squares to the right of every property. It turns out that if you navigate your mouse over one, and after two or three tries manage to click on it successfully, it pops up this context menu:
       
      This is such a non-standard user experience that there isn't even a name for it. (Adam Kinney has suggested calling it a Property Peg.) But there's a darned good reason there isn't a name for it. It's because it's a bad idea! It's a horrible UX design. How more completely unintuitive and non-discoverable is it possible to get? (That's apart from the fact that because the, umm, peg is so small, even once you figure out what it's there for, it's still hard to use.)
      
      
   3. In every other Windows application, scrolling your mouse wheel moves the selected document up or down. In Blend, scrolling your mouse wheel sets the zoom level on your current workspace. That wouldn't be so bad if it made a better guess about where you were aiming. For instance, here's what my screen looks like after I open up a specific user control I've been working on lately:
       
      And here's my screen after four "zoom in" mouse-wheel movements:
      
       
      Rather than zooming in on anything that I might be interested in (say, the selected object), Blend has helpfully chosen to move my control entirely off the screen. And what's worse, it seems bloody well determined to be random about the direction it moves it. Sometimes it moves it off my screen up and to the right, sometimes down and to the left, and occasionally, very occasionally, it decides to actually zoom in on the thing I'm interested in. Taken all together, though, it's as if Blend is determined to take my mouse wheel, one of the very best usability inventions ever, and make it entirely useless.
      
      I could go on for quite a while about Blend's failings: these are only a couple of random examples. But they should be sufficient to demonstrate that Blend desperately needs some UX TLC.
      
      
3. Silverlight is still missing some very basic features. The one that's usually brought up is the lack of printing support, which is laughable, if you think about it very long at all. Given the project I'm currently working on (web conferencing), the feature that I miss the most is obviously web camera and microphone support. Flash has supported web cameras and microphones for years, so it was very disappointing to me that this feature got cut from Silverlight 3. From the knowing and slightly embarrassed looks that I see on Microsoft faces whenever the subject gets brought up, I'm pretty sure that it'll make it into Silverlight 4. But still. Of the six months that I've spent working on Alanta, at least a month out of that time has gone to troubleshooting the clever but ultimately painful Flash hack that we're currently using.

I feel the need to repeat what I said earlier: you know a product is being successful when people start complaining about it. They complain – I complain – because I can see the potential for the product, and get frustrated because it's not there yet. I'm also a developer, and know how hard it is to get these things right. The folks at MS are only human. But I also hope that they're listening.