I'm actually working on Windows in my current contract. Don't say anything, don't say anything, don't say anything, don't say anything, don't say anything ... mmgggmfff mmrrrf mrrrff ... :P
Microsoft doesn't just make money off of Windows, they also make money off of Azure and other services (which are easier to use with MS tools/languages/etc.)
The Xamarin partnership stuff is meant to keep existing MS developers using MS tools (and therefore make it easier for them to target Windows as well), it's not really aimed at attracting new developers. For that I think they should consider a "reverse Xamarin" strategy: improve Windows' support for common languages and APIs from other platforms - for example with WinRT bindings for Java and OpenGL ES support - and make it easier to target Windows using tools popular to developers on other platforms (Eclipse? Android Studio?)
@itsnotabug: Don't think so. They were always planning to evolve/expand the immersive windowing model (you saw the first step of this in 8.0 -> 8.1), but not necessarily in the direction of merging it with the desktop "overlapping windows" model.
I think there's a lot of confusion of terminology here, which I guess is partly Microsoft's fault for overloading "metro" to mean a bunch of different things. Are we talking about the Windows Phone design language, or the more vaguely defined Microsoft-wide design philosophy, or the Windows 8 immersive windowing model, or the WinRT application model, or the set of new shell features in Windows 8 (live tiles, contracts/charm flows, etc.), or what?
From the rumors it sounds like the main thing they are de-emphasizing for "classic" PC form factors in future Windows is the immersive windowing model, in favor of fitting the new features (including Start / tiles) into the stacked-window desktop model instead. I personally wouldn't characterize that as "abandoning metro" but just reducing the focus on (or decoupling) one aspect of it.
I think Chris Anderson's answers at 9:09 - 11:34 in this video -> http://channel9.msdn.com/Events/Build/2014/9-007 are probably salient:
T: So Charice wants to know: Does XAML in Windows 8.1 code work in Windows 7 WPF desktop application or do we need customization?
A: That's a fabulous question! WinRT XAML is not accessible to desktop applications in Windows 8.1, so you have to write the UI again.
H: Especially not downlevel to Windows 7. We got some parts of this question earlier. WinRT is built on other improvements in Windows as well, that don't exist in Windows 7. It's hard to decouple some of the optimizations of some things like our composition, and aspects that just aren't there in Windows 7.
T: Absolutely. And this kind of goes back to when I jokingly said something like - one XAML. Right - One Microsoft, OneDrive, One XAML. Do you foresee sometime in the future where there actually could be one XAML that runs in different runtimes, or different contexts, like WinRT, desktop - it's something that would be really interesting.
A: Of course. I think that in Windows 8, we coupled a bunch of decisions together, around app containers, and security models, and store distribution, and programming models, and windowing models, and all of these other things. We put a bunch of these decisions together and we called one side the name of M which cannot be spoken, and the other side we called desktop apps. I think you see already in the keynote, and the work we've been doing, and where we've taken the 8.1 experience and where we're going in future releases, that we're starting to take those decisions and decouple them and make them be independent. So Harry showed a demo that showed you being able to break out of your app container and call full-blown native .net code to access LOB functionality. We saw Terry show a demo where there were some hints at future windowing ideas, that we're looking at decoupling that. And so I don't know if I necessarily say that the XAML we see today is going to suddenly light up in desktop, I'm just not sure how long that distinction between those two experiences is going to remain, and which decisions are going to be where.
Personally I very much agree that
- Clicking on a tile with a specific notification doesn't take you to that thing the notification represents. Instead it launches the app and you have to dig around the app to find the thing you were notified about (Facebook is a prime example). I find that very frustrating as that's what I'm used to on my Android phone.
is a huge problem with the current implementation of Start and live tiles. So I think a reliable way to deep link into the specific information a tile update represents would be very welcome.
OTOH I'm not sure the start screen would be a good place for more involved interactions with an app. The objections RealBBoy and magicalclick raised, that it would complicate interaction with Start and present developers a dilemma of where to implement features or require them to implement the features twice, are pretty salient I think.
So personally I'd prefer if interactions with tiles were kept focused on (1) dynamic deep links (e.g., click on a specific email out of several in a large tile and open that email directly) and (2) quick actions involving no more than 1-2 user interactions, the sort of thing you might see in a taskbar thumbnail (e.g. play/pause for music) or an Android notification (e.g. quick delete for an email). Whereas something more involved, like replying to an email, would be reserved for the app itself.
Eh, I'm not sure I completely agree with that. The taskbar in Windows 7 was already designed to reduce the distinction between launching and switching. And then even in Windows 8.1, once they added multiwindow support for store apps (a pretty useful feature I think), it sort of breaks the model in that even if there's no distinction between n=0 and n=1, there's still a distinction between n=1, 2, 3, 4 ... so there is some amount of instance management you end up having to do in some cases anyway, though hopefully not as much. (This is one situation where I do appreciate having the taskbar everywhere.)*
In general ... all these models are abstractions over 1s and 0s, right? And they're ultimately tools, they're meant to serve our purpose as users, we're not here to serve them. So I'm fully OK with "cheating" the model when it's just a lot more convenient to do so. Even back in the 8.0 Developer Preview days they broke the desktop-as-an-app model with things like Alt-Tab, because it was just really handy. However, I do think there should be a higher utility bar for features that break the model, because models are ultimately what allow people to make sense of the system (a cognitive lever). I'm not sure a lot of the 8.1.1 stuff meets that standard as is, but I think it could work better with some design adjustments.
*(Though personally I kind of think they screwed up the implementation of multiwindow a little, at least in IE - IMO additional windows in the new model should be treated as just a transient way to see two things at once for a while, rather than a persistent container for the state of ongoing activity. So there should just be one list of tabs accessible from all windows rather than each window having its own tabs - this has already tripped me up a bunch of times - and I'm not sure if offscreen windows should even each get their own slot in the left edge switcher.)
Hey, that's actually an interesting idea - since in immersive apps the taskbar only appears when you explicitly summon it, maybe it could be made much bigger, perhaps as big as the IE tab/favorites bar is now. The extra space could be used for thumbnails, tiles, more apps, etc. Of course it would be tricky to reconcile with Peek.
(You can resize it to be multiple lines today, but that doesn't work very well in this scenario because apps are ordered from top to bottom instead of bottom to top like they should be, among other reasons.)
I'm not sure I agree they're necessarily incompatible, I think with some adjustments to the taskbar design they could solve or at least mitigate the problems.