I don't get the complaint. Google obviously doesn't want to be in a position that it can't change how its ads are served because it's hard coded into a third party app they can't change, so they require it be done with HTML5. The requirement isn't a secret or a surprise and I highly doubt that Microsoft lacks the technical expertise to comply with it. It looks a lot more like Microsoft refusing a completely reasonable requirement so that they can make a stink about Google blocking them.
And complaining that there isn't an official version of some Google app for Windows Phone is like complaining there isn't an official version of Microsoft Office for Ubuntu or FreeBSD. Why would you even expect there to be?
My complaint - and I'm speaking as a consumer, who pays for devices and watches ads - is that Google doesn't provide apps for Windows platforms and blocks developers (Microsoft and 3rd party) who do.
For the YouTube case, neither the Android nor iOS app were built on HTML5. Why did the WP app need to be? And, fine, if it needs to run on HTML5, were there API's or metadata provided to allow showing the ads using HTML5 standards? Nope.
Same for Google Voice - they won't provide an app and won't allow other developers to provide one. I don't care about having an official Google app; I do care about them completely walling off access to one.
Starting around the Google+ days, I began to get a very clear sense that Google cared about their strategies a lot more than me as a user. As a long-time Google user - since Gmail beta, OG Droid user, etc. - this was a dramatic shift.
Compare this to pretty much everything Microsoft releases these days - published standards, open API's. They publish things for other platforms and encourage developers to access and extend theirs. That's a technology future I'd prefer to support.
> My complaint - and I'm speaking as a consumer, who pays for devices and watches ads - is that Google doesn't provide apps for Windows platforms and blocks developers (Microsoft and 3rd party) who do.
The problem is they're not really apps, they're services. Go ask Netflix if you can write a third party client for their service. Or Skype for that matter.
I'll be the first in line if you can get rid of all the useless DRM/telecoms regulation/whatever that makes these companies think this is necessary, but Google is if anything doing less of that than their competitors. At least they have platform-independent HTML5 versions of pretty much everything.
You have to admit the schadenfreude is delicious. Microsoft pushes DRM knowing full well it will disadvantage minority platforms and then it comes back to bite them now that they're the minority platform.
> published standards, open API's
It doesn't count when the standard just says "do it the way X version of Microsoft Office does it" without actually specifying what that is.
To me as I consumer, schadenfreude is never delicious when it affects me.
> It doesn't count when the standard just says "do it the way X version of Microsoft Office does it" without actually specifying what that is.
Which API are you talking about? There are published, documented API endpoints for all kinds of Office services: https://www.google.com/?q=office+apis
I wasn't just talking about Office, by the way. For example, part of the HoloLens announcement was the invitation for Oculus, Magic Leap and Google Glass devs to build on the holographic APIs (http://www.theverge.com/2015/1/21/7865539/microsoft-windows-...).
Back to the original point - if a service provider won't provide an app, they should provide an API. Ideally both, but at least one. It's in their rights not to, but that's my cue to go somewhere else because that's not how I want to be treated.
> Not really an issue because Skype releases clients for Mac, Linux, iOS, Android, Kindle Fire, PlayStation...
It's still kind of an issue if you want to run it on SteamOS, Solaris, FirefoxOS, Tizen, BeOS/Haiku, Plan9, all the different BSDs, etc. etc.
You can't expect anybody to support everything.
> Sort of.
Yes, Chrome-only for the brand new bleeding edge stuff is stupid. But it doesn't actually exclude any platforms because chromium is open source and anyone can port it to whatever you like. And then they end up supporting other browsers anyway.
> To me as I consumer, schadenfreude is never delicious when it affects me.
Yeah, I was a little confused about that. It seems like you were saying that Windows Phone users are having a hard time so you decided to switch to it. In which case it affecting you would seem to be intentionally self-inflicted.
> Which API are you talking about?
The "standard" for OOXML that Microsoft pushed through so they could say it was a "standard" even though the standards document was essentially entirely written by Microsoft and didn't provide all the information necessary to actually implement it correctly.
> Back to the original point - if a service provider won't provide an app, they should provide an API.
What you're really saying is that they should always provide an API, because nobody is going to provide an app for each of 10,000 different platforms. And I completely agree. But YouTube is doing the same as Netflix/Hulu/HBO and Google Voice is doing the same as Skype/MagicApp/Vonage. Blame all of them or none of them.
First, I appreciate the thoughtful discussion. Good points, and it's nice to have avoided Godwin's law in a thread this deep.
> Skype
I fundamentally agree with you. Skype does support way more platforms than just about any service I can think of, especially when you consider Skype for Web beta (http://blogs.skype.com/2014/11/14/please-welcome-skype-for-w...). But I agree that nobody can support every platform.
> Chrome
Kind of true, but not all platforms can or will support arbitrary browsers. Worse, as a user I should never have to run multiple browsers just to use a web app. Extra chagrin here because holy cow this is the web we're talking about, and Google's established a pretty clear pattern over the past year of Chrome-only dev that should be pretty worrying to anyone that cares about web standards.
>shadenfreude
In my case, I decided that I was irritated enough at Google's actions that I'd rather not have Google apps on my phone apps than support their ecosystem. Plus, I genuinely prefer Windows Phone as a platform.
>OOXML
That was 2006, the same year jQuery was first released. Cars and Da Vinci Code were big movies that year. That was before Windows Vista shipped. It was a long time ago. If that's your reference on Microsoft's standards support, it's not the full picture.
>Blame all of them or none of them
I'll blame them all then, but I definitely feel like Microsoft's by far the least bad in this area. I'm disappointed, when I first got excited about the Android platform, I had high hopes that it would be something else. I ran early releases in VM's before phones were available. I was excited about an open source phone platform, and Google's general trend (at that time) of doing cool stuff on open source, open services, open API's. Things turned out differently.
> That was 2006...If that's your reference on Microsoft's standards support, it's not the full picture.
The new standard for high capacity SD Cards - SDXC - specifies a filesystem in the standard. That filesystem is exFAT, a proprietary, patent-encumbered filesystem from Microsoft.
Microsoft like to make out that they're an all new and open company, but they were a nasty company in the past, and they're a nasty company now.
I'm not clear on how this relates. Microsoft created and patented a filesystem that solved some problems for flash memory. The SD association decided to adopt it for high capacity SD cards. I haven't read anything alleging that Microsoft did something sinister to trick them into doing that - is there something I'm not aware of there?
I get that this is inconvenient for users on other platforms that don't or can't license it easily, the same way GIF and MP3 and similar file formats have been in the past. I don't know why the SDA picked a proprietary filesystem.
Regardless, that was something the SDA did, and they did it in 2009. How does it relate to talking about how Microsoft currently produces apps and publishes APIs for other platforms?
Oh please! You can't honestly believe that Microsoft didn't exert any pressure to get exFAT specified as the filesystem? There was no reason to specify a filesystem in the standard at all. SATA drives don't have a 'specified filesystem' now do they?
But even assuming that Microsoft had nothing to do with exFAT being adopted as the SDXC filesystem (yeah, right) it still relates as MS could have released the exFAT specification and they could have released the filesystem from licensing.
That would have been sign of them being a more open company, allowing integration with other OSs, but instead it just looks like since they failed to kill off OSS, they're now trying to own it. Same old Microsoft.
Once again, that standard is nearly 5 years old. Microsoft has definitely continued changing their approach to OSS software. I think my favorite move posed by Microsoft that supports this is their open-sourcing of .net and working with the Mono developers to bring a better experience to all platforms.
The effects of that standard are only just hitting us now. Have they dropped the requirements for a license for exFAT yet?
As for Open Sourcing .Net, what good has come of it as of today? It looks like a move to push their own environment more than anything else. But I'll tell you what: if in 2020 the decisions Microsoft are making today prove to be for the good, then I might start think better of them. At the moment, though, they've got a lot of past to make up for.
And complaining that there isn't an official version of some Google app for Windows Phone is like complaining there isn't an official version of Microsoft Office for Ubuntu or FreeBSD. Why would you even expect there to be?