Strange times in the world of Microsoft developers

Over the past few months there have been many odd announcements, rumors and convulsions coming out of Microsoft. It all started when Bob Muglia announced that their “strategy has shifted” toward HTML5, and Silverlight will not reign supreme forever. That one statement caused ripple effects that literally put some people out of work, caused projects to be put on hold or cancelled, and made many people in the IT world wonder…

The major concern for people who have invested years of time learning Silverlight, whether it is valid or not, is that they are about to become dinosaurs. For people focused on WPF this news was not as threatening or shocking because, well, WPF was not the new kid on the chopping block anymore. Silverlight was. Until now. Chop!

An awkward time passed, with lots of angst and nail biting in the development community. People who were glad to finally be done with the horrors of cross-browser compatibility and dealing with the latest breaking changes in their DOM abstraction library of choice soon realized that Silverlight was slipping through their fingers. Instead, a hot new technology meant to solve all the world’s woes was soon to plop into their hands: HTML5 and JavaScript. This does not bode well with people who are used to the luxurious and productive world of C#, .NET, and the full powers of Visual Studio 2010. The situation seemed grim, and there was a lot of confusion about the future of .NET and Silverlight. Certainly Microsoft must be planning to explain things more clearly, to put these fears they stirred up to rest.

Unfortunately that didn’t happen. Rather, the opposite happened. Microsoft gave the world a sneak preview of Windows 8 and touted the fact that you can build apps for it that have the Metro UI style using…HTML5 and JavaScript. That’s right, world. Suck on that for a while. In the future we will (should? must?) build desktop Windows apps with the crap that we were trying to get away from on the Web when moving to Silverlight. I’m sure there is a good reason for all this, but I must admit that seeing this go down makes me super-duper happy that I’ve been diving head first into iOS and Android programming. If the future of developing Windows apps means abandoning C# and the .NET Framework and instead using HTML5 and JavaScript, I’m out. See ya, Microsoft. Good luck with that.

Perhaps the world at large does not follow all of this nonsense as closely as the people who bother to blog about it do. I have heard from several friends in major U.S. cities, including New York and Boston, that there are many opportunities for experienced WPF and Silverlight developers. Brief searches on Dice.com confirmed this. The “real world” seems to have just recently (past year or two) wholeheartedly adopted WPF and Silverlight. I have noticed that it takes a long time for large organizations to adopt new technologies, so perhaps all of this handwringing is for naught. Unless you depend on cutting edge technologies for a living, there’s really nothing to be concerned about. But there is something else to be interested in…

Jupiter is the code name for some new UI programming platform that supposedly might be available in Windows 8. There is a lot of speculation and rumor on the Web about what exactly Jupiter is, and is not, but there have been no official announcements as of yet from Microsoft. I have heard tales of it being a replacement for WPF on Windows 8, using XAML (amidst rumors of the XAML team at Microsoft being disbanded), it supposedly is called DirectUI, and it supposedly will support being used with native C++. All I can say is “Cool!” and I hope that this Jupiter thing turns out to be awesome, but I don’t care much about it until I can fire up VS and kick the wheels.

Supposedly all will be revealed and clarified at the upcoming BUILD conference in 2011. I suspect BUILD will answer some questions and unleash a new wave of turmoil in the developer community. Regardless of how successful the Microsoft PR machine is at that conference, one thing is certain. These are strange times in the world of Microsoft developers.

Device-specific interaction logic in an MVVM application

Rudi Grobler recently posted an article called ‘Classic Jukebox‘ that shows how to build a jukebox application using custom hardware.  It’s a very cool idea, and his article is well worth reading.

This article reminds me of a problem that I was discussing with someone at work the other day, and have been thinking about since.  What are the best practices for designing an app, let’s say the Jukebox app, such that it can accomodate multiple form factors?  Suppose you wanted this app to be controlled by a custom input device, or a regular mouse + keyboard, or on a multi-touch device like Microsoft Surface, or an HP TouchSmart running Windows 7. 

Each form factor would bring along new, and potentially unique, interaction possibilities: Surface allows for multi-finger gestures, while a traditional keyboard allows for things like shortcut keys, etc.  How should the MVVM design be used/augmented to make the input processing device-specific, without convulting the core application logic (play next song, pause, lower volume, etc)?  Should there be an intermediary layer  between View and ViewModel, which is perhaps an InteractionModel, to which the device-specific View is bound?   This topic is something that I’m very interested in, so expect to see some more posts on it in the near future.

Food for thought…