I've attended a very nice Microsoft Community Days event in Milan last Friday. Good level of sessions, some great speakers (and some not great, but good), very nicely hosted at the new Microsoft Milan office (which is very nice and has much better parking). I liked the event, spent some time chatting with speakers, and learned a lot. 

But in the end, I was really puzzled by the design decisions behind the new Metro user interface. Not the graphical design decisions, those are actually quite nice and inspiring, but the technical design decisions (or at least those in the current developer preview which dates back several month and are subject to change within a few days, when the first public preview of Windows 8 will become available). Some info at http://www.tested.com/news/windows-8-metro-app-multitasking-will-mimic-mobile-apps/3564/ and https://wiki.mozilla.org/Windows_8_Integration.

Why am i puzzled? In short, Metro apps run one at a time, generally full screen (the exception is 2 side by side), an app moved to the background gets suspended after 5 seconds and must save its state (and do it fast), given the OS might kill it in case it needs more memory (cannot they just warn the user and ask to close some apps as Android does? Too geeky?). The reason for these design decisions is to save CPU time and so increase battery life. A good idea for a phone? Maybe, but with dual core phones becoming the standard and with Android offering better multitasking, this seems a bit strange to me.

But that's not my point. Windows 8 Metro interface is going to show up on my 8-core PC, which has enough memory for tons of apps, and most of the time has a cable connected to a power plug. So I don't care, and yes I want my email app and my twitter app and new newspaper app to keep running, so that when I get back to them I see up-to-date status... not what was there when I moved on. Because I'll have to wait for the app to fetch more data and update the user interface. I'll have to waste my time! Keeping my browser pages open, after all, is currently making me a better service. And running native Windows app provides a better experience. I'm sorry, but I really don't get this. Even the Metro UI tiles "seem to update", but have lots of limitations. From what I've learned, Metro is very inefficient at multitasking by design: it keeps re-executing the same application over and over with different start-up parameters. This is not fast, compared to waking a suspended thread. The only good news is that Native C++ (and possibly Delphi) apps will be much better than managed .NET apps that need to to just-in-time compilation at every execution!

Moreover, as a developer you have to write a lot of code to support all of these start-up options, support saving and restoring state and much more... and this is compulsory for an application to show up on the Microsoft store. So you have to write a lot of code to support this memory management model. More than competing platforms require. This makes is practically impossible to build business apps with database connectivity and so on, unless you want to disconnect and reconnect from the DB every time the user checks the weather. I think Microsoft should really know better. And this is not the only point, as there are other limitations in the name of user experience that simply add unneeded burden on the developer.

Either I really missed something relevant, or on full blow portable and desktop PCs I see the chances of Metro and WinRT very low. Trying to unifying the two interfaces might be interesting, but trying to push desktop application developers towards a more limited architectural model, seems clumsy. Thinks might be very different for tablet and phones, but still why target for lower multi-tasking support than your successful competitors?