http://blogs.msdn.com/b/windowsappdev/archive/2012/03/15/combining-xaml-and-directx.aspx
Have you seen the video of the guy trying to use Windows 8 for the first time? Not sure if the video proves that the desktop mode should be improved or just done away with.
I see nothing that we can class as a desktop improvement. Metro actually gets in the way of the desktop, rather than enhances it.
If we were to have a unification of features such as WinRT, XAML as a first class citizen, the feature posted here, charms, etc, then MS would have a surefire hit in the corporate world. I have just had a client ring me to tell me not to offer them a Windows 8 update to our software because they will not upgrade. Now, these people throw money around on just about any software upgrade because they do this to protect their budget. For them to say no to this is unprecedented. Heck, they even upgraded to Vista when that first came out.
I don't know how clear we can make this, but there are lots of companies out there who have applications that cannot be offered in a Metro way, so not offering access to the same features and not listening to people who really do need to treat the desktop as their primary system is just alienating us. I have tried to love Metro, but I just can't. Embracing it would be financial suicide for us. The single screen app does not work for our clients, this being one of the reasons we never went the ipad route.
The error that many people do is to consider Metro applications as an *upgrade path* from classic desktop apps. This is not that at all. Just like a phone application is not an upgrade to a desktop app.
In fact Metro apps are companions to full blown desktop apps, with less features and touch oriented. The firms who don’t get that are doing it wrong. Metro apps should be developed *in addition* to standard applications.
There is no doubt that in some cases we will see Metro-only apps (just like we have some phone-only apps), but if the client has a running application on the desktop already, proposing an upgrade to Metro doesn’t make sense.
All this IMHO of course.
Laurent
Not sure if my comments will conflict or agree – probably some of both. No offence intended. A lot of this are “my thoughts” – the are based on strategic decision making and how I logically see it playing out from a commercial point of view. Commercial scenarios control the technology choices we have in front of us, not technical features. That is the way it has always been.
Metro is for both desktop and tablet form factors. You must demonstrate that your WinRT based solution can run on both for marketplace submission. Thinking that it is for one over the other is naïve – I am not saying that it is the right way to go of course.
The start screen is just that – a start screen, an extension of the existing start menu. It is not the place where WinRT application run. It is a snapshot of applications that have access to the start screen (menu) properties such as tiles and common contracts.
Metro is a touch first UI technology, but beyond that (and no chrome) they are what we traditionally think of as desktop applications. WinRT is everywhere in Windows 8 and I think what we will see is that you will have the choice of building a chromeless Metro style application for “consumer” experiences, or a traditional Windowed application with no constraints on design language implementations for “enterprise” experiences – both in WinRT with the features and benefits of WinRT. We already know that in order to target ARM – you will need to provide two different install packages, and it is not inconceivable that you will also be able to specify “metro” or “desktop” either. The reason why is that companies like Banks need to be able to privately distribute and install solutions without public stores. I don’t think that will be there for GA – maybe, but I wouldn’t bet on it.
The downside to that with LOB is that the entire framework is not there yet – nor do I believe it will be for GA timeframes. We honestly don’t even have parity with Silverlight 4 at this point (both in tooling and framework), but that is not to say that it isn’t coming. When you throw the phone into the mix – getting framework consistency has to be a higher priority, because it has been pure crap up to this point being restricted in one platform to the other, building multiple code bases to support similar features of the same solution on a phone compared to a desktop. This is not about creating the same application on all platforms but creating companion solutions because the use cases are different from device to device.
In terms of users – yes there are many more desktop’s, but that simply won’t be the case moving forward. The stats and buying trends backs that up – but again we are talking mostly around consumer use.
There is nothing stopping you from creating your traditional Silverlight or WPF applications and ensuring that they will run under compatibility for Win8. So where is the issue?
Developers in general maybe angry at the direction of MSFT – but pause for thought – The existing frameworks were heavily limited to what could be achieved with them moving forward in terms of hardware requirements. The entire architecture of the under-lying OS needed to be modified to move towards the performance requirements of solutions and hardware moving forward. This is a reason why we see HTML based “Applications” performing faster in rendering terms as compared to C#-C++ solutions. The platform is optimised for rendering and performance – as opposed to execution speed of the code that is powering the solution within the framework.
In the end – I hope that they remove backward compatibility altogether. They have needed to do it for years and it keeps getting pulled. I am sick of the frameworks, performance and functionality of cross platform delivery being constrained by it.
If users of older solutions want to use those solutions and are happy and efficient doing that – they have 10 years to get used to another scenario. As a developer, if you want to keep targeting that market, again, there is nothing stopping you from continuing to develop for it in those technologies – WPF and SL.
There are a whole heap of other reasons why MSFT would head this way – commercially with revenue in content distribution, eco-system ownership (people owning all MSFT devices as opposed to Apple), improvements in management scenarios, and lastly the disastrous cloud. The cloud will get better and the terms under which we build for it are about to change as well – it has to in order to make the entire proposition viable. MSFT know this. Let’s see if they can actually execute it without all the BA’s and other people that have never written a line of code getting in the way.
Either embrace the change and try to understand how to make solutions for it that benefit users, or master the tech that you are currently happy with. In the end, the users (both consumer and enterprise) will decide what works and what doesn’t. It’s our job to be able to build for that expectation and that is why (love or hate Windows 8) you should all be learning how to build for it.
The XAML DX interop I saw a mile away...they need it if they're going to support running WP7 apps on Win8. With regard to the rest...it may be burnout talking but I'm pretty much feeling m'eh about the whole technology carousel. I'll let the next group figure out how all this stuff works. Not sure why they took the start button away from the consumer preview. If having it bring up the Start Screen was too confusing, not having it at all is probably worse. Like I said right now, I'm really not as hyped about Win8 as I should be. It might pass, it might not. It's just another cycle of learning followed by a few years of waiting for the market to follow. Judging from the adoption of WPF, we have about 4-6 years before we start seeing any true demand for it.
Then again, I could be totally off base and it takes off like gangbusters. There are a lot of issues holding it back from being the default new project template for the business world. But the consumer space may take a liking to it. We'll see.
--Mike