pyehouse
27Sep/110

The State of NFC

Stylized white N on a blue gradient background

The State of NFC

Stylized white N on a blue gradient background

The “N-Mark” logo is a trademark or registered trademark of NFC Forum, Inc.

No, I'm not here to discuss the fact that the Detroit Lions have their first 3-0 start since 1980, though kudos to them. I'm talking about Near Field Communications and particularly how it is used to make purchases. If you've ever swiped a badge to enter a building, had your pet injected with an electronic tag, or swiped your ticket to get onto public transportation, then you have used NFC. In essence, it involves two devices communicating information over a very short ranged radio signal. The smarter the devices, the more interesting the exchanges that can take place. With something like a badge, ticket or card, the communication is going to be, by necessity, rather simple, typically one way and typically simple bits of information. With something like a smartphone or computer, the possibilities are endless, a whole host of information being available and both devices being capable of altering what is sent based on changing needs.

Google and PayPal are squared off against one another in the NFC space  and those are two big players, to be sure. Google is going to launch a phone with NFC payment options but and it has some major players lined up to help, but it's still going to be starting off with some limits like only being in a single new model, only being on the Sprint network, only being usable at certain retailers, etc. But it's still a serious bid by Google to get into the game in the US, where the uptake of NFC hasn't been nearly as pervasive as in other countries like Japan.

Meanwhile, PayPal and owner eBay have been involved with a number of acquisitions and partnerships which, while not being as close to actually going live, have the capability of being more far-reaching and touching on more payment processing possibilities (say that five times, fast) than Google's Wallet would out of the box.

Either company would seem to have a large leg up on anyone else entering the field (pardon the pun). For any other company to stand a chance at playing in the same arena for NFC mobile payments (i.e. paying with your phone), they would have to have equal name brand recognition, the ability to widely deploy large numbers of devices with NFC, capacity to handle purchases securely and an ability to establish relationships with merchants for rapid uptake of their payment processing system. Hmm...

Apple. Yeah, you saw that coming. First off, there have been rumors for awhile now that Apple was going to be dallying in NFC. First the iPhone 4 was rumored to be introducing NFC and now rumors are flying about iPhone 5, though admittedly tuned down  . But consider, the iPhone is in widespread use and has the highest retention rates of any smartphone in the industry so it would seem that the smart money would be on pretty widespread adoption of the iPhone 5 out of the gate. Additionally, we're seeing the iPhone move into more carriers in the US which is only going to increase its reach. Plus they've been processing payments as small as $0.99 for quite awhile now, albeit through their relatively controlled App Stores. And the process for signing up for what is essentially a merchant account to handle payment processing on the App Store is relatively pain free.

That said, a 30% cut of sales won't fly and it might be hard to explain why I can sell you a Doubleplusgood Meal for only a 10% surcharge to Apple but end up with a 30% chunk gone for selling you the latest Lady Gaga track. That's not to mention the hardware that would need to be in each location to handle that processing. Of course, the answer to that might be more iPhones or iPads. After all, Apple is already using them in their own retail stores, so why couldn't a similar system be made available for merchants in their own stores? Set up an iPod Touch on the store's wireless connection, secured of course. Run the merchant iOS app, loaded with the store's inventory plus an ad-hoc item option to ring up random sales that might not be present in standard inventory. Walk around and let your patrons make purchases anywhere on the sales floor or at the main register, whatever you prefer.

Not Part of Apple's Core

The catch to all of this is... this isn't what Apple has been about. The App Store has typically been considered an avenue to encourage sales of Apple hardware, not as a revenue center in its own right. Perhaps that principle was Jobs-specific but I find it hard to imagine that his recent departure would result in a fairly big shift in focus. Still, Apple does seem to have a lot of the tools necessary. Or at least enough of them to give it a go.

Personally, I would like to see it happen through Apple. I already deal with them on multiple levels financially and don't want to have to add to the panoply of companies who have my financial information. Then again, I suppose the same could be said of PayPal. Google... not so much. Wallet is new and Checkout has never really taken off. Regardless, here's to an interesting online battle. May the best tech win.

14Sep/110

Google Dart Misses the Mark

Google has revealed they are working on a new programming language, Google Dart, which one can surmise will be targeted at web development, likely on both the back end and front end. The first indication was the release of the speaking schedule for the Goto Conference in October, where two speakers will be presenting the keynote concerning this new language. If it turns out that Dart is in fact targeted at replacing Javascript on the front end, regardless of any other platform targets it might have, it is not going to transform the client side development experience without more support than just Google's Chrome.

What is Google Dart Targeting, Really?

Based on an alleged leaked memo discussing a project codenamed "Dash", it seems that Google is trying to supplant Javascript in the browser in order to fight the "encroachment of other, less open platforms". This appears to be referring to native apps and in the case of mobile, iOS apps in particular. According to the "Dash memo", the plan will be to have Dash cross compile to Javascript in order to continue to support Javascript centric browsers until such clients are capable of natively running Dash. The intent, then, is to create a new environment, entice developers to jump in and use it, and use that momentum to move vendors like Apple, Microsoft, Mozilla and Opera to incorporate Dart VMs in their browsers. There are some problems with this approach though.

A Twenty Mule Team

Google is going to be pulling against several different, very powerful forces if they make an attempt such as they seem to be undergoing. To begin with one of the problems they cite as a reason to consider Dart, a multitude of frameworks and libraries to perform various functions, is also one of the reasons many developers will want to stick with the language as they have already invested time and effort in learning and deploying these frameworks. Moreover, Google points to the use of myriad incompatible design patterns. Based on this statement, it suggests they want to perform some sort of enforcement over which patterns might be used or perhaps create alternative frameworks which use a common pattern and provide them as a means to allow developers to use a consistent set of frameworks. This suggests Google is looking to create "the One True Way" for web development by fiat rather than by allowing for the development of a standard which other entities might have a say in. If they were truly concerned about asserting the homogeneity of the Javascript ecosystem they would proffer their own such frameworks using compatible design patterns.

Then there are the other browsers. If you take a look at the speakers list as well as the list of sponsors, you will notice some absences. Namely any other browser vendor. Barring a last minute surprise, it doesn't seem as though Dart has the backing of anyone but Google which means that the best we could hope for would be for Chrome to have Google Dart support out of the gate. Chrome is doing well, but Chrome alone will not be sufficient to convince the majority of developers to switch to its environment. What about the other vendors?

Microsoft has continued to release additional details about development on their upcoming platforms and it seems that it is going to focus on .NET and WinRS on the backend and for native code and use of HTML5/CSS/JS for UI development. It seems unlikely that Microsoft would have a great deal of concern for moving toward adoption of yet another VM for their front end functionality. Not to mention Microsoft has their own development toolchain which they want to see in use as opposed to a Google Dart based toolchain which would allow for more cross platform oriented development.

Apple, too, is focusing on HTML5/CSS/JS for support in their browsers and given the competition between iOS and Android, I wouldn't imagine they would want to provide a leg up for developers to create apps using Google Dart that would function equally well on either platform. On top of that, Apple has already dealt with another company who owned a toolchain which focused on cross platform development. Adobe still has yet to compel Apple to release a Flash compatible update on iOS and in fact has started making overtures to the HTML5/CS/JS crowd through their announcement of Edge as well as the recent changes to their Flash Media Server to deliver alternative content to iOS devices on the fly. Apple isn't going to let their major mobile competitor install a competing VM platform on iOS devices when that means that competitor will have a distinct edge in keeping support for it more featureful and up to date on Android.

Mozilla could possibly accept Google Dart as a native VM in their browsers, simply because they have the least to lose in such an arrangement. Unlike Microsoft and Apple, Mozilla as an organization is not pushing a competing development environment or toolchain, isn't competing in the mobile space and in fact is really only going head to head with Google with regard to browser market share. Still, that may yet be reason enough not to jump in bed with Google. Plus unless Google Dart is made part of a standard of some kind, it's possible that there will be even less traction in this space.

The same argument goes for Opera, perhaps even more so. Opera has a reputation for being one of the most standards compliant browsers available and again, unless Google Dart is made a standard, Opera may not wish to incorporate this VM into their product.

What's the End Game?

Google isn't stupid, so if it seems so obvious that uptake of Google Dart is going to be difficult to achieve, why bother? As the "Dash memo" points out, this is a high risk/high reward option. Given how many different projects Google has going at one time, creating a new VM to include in their browser and to make available for back end development isn't asking much in terms of time and money. The risk is in the reputation. Google is going to put their name behind this and try to get developer muscle to push it into other browsers. In essence it is going to test how much weight they actually have to throw around. If it succeeds, they will have grabbed a commanding position, providing a toolchain which can target apps on their platforms to their liking and which other vendors would need to tailor their systems around. If it fails, it will be a sign that while they are big, they can't yet force the other big players to play their game. High risk, high reward. I don't see a bullseye in the making.

Image by renjith krishnan
10Sep/110

Google Docs Outage “Mea Culpa”

Google has made a blog post concerning the reasons for their Google Docs outage last week. In essence, a bug in their software was exposed when they added an enhancement, a bug that was only visible under heavier load than seen in the test environment. One of those "Wait, that didn't happen in the simulator" moments. I don't see this as an indictment against Google. Everyone makes mistakes and this is just that kind of ornery bug that is very hard to find without actually pushing your systems to max. But it still raises the question of how the cloud should be used.

Google's concept of cloud services, where not only is the data entirely stored remotely but the functionality is accessed there too, demands a full time connection to the remote server to work. While losing access to your stash of poetry or your grandmother's cache of recipes isn't likely to have caused you too much upset, being unable to grab the most recent copy of the contract on your way to the merger meeting might be a little more unsettling. Sure, you probably have a copy somewhere locally... right? The fact is, when you rely on this sort of arrangement, you are potentially putting some of your most critical digital possessions in the hands of another company. Even a company as well established as Google can fail. But surely it's more likely that your own machines would fail before Google's would. Okay, let's grant that. Google even outlined the steps they were taking to try to prevent this sort of problem (I hesitate to call it a disaster given what all is happening in the world these days, but some may feel the description fits) happening in the future. Are they going to also put into effect a plan that prevents a backhoe from severing my company's connection to the outside world and thus Google's servers? Will they also provide a plan that will prevent an accounting error from inadvertently shutting off my internet pipe? The fact is Google is not the only link in the chain between me and their servers and they're not even the weakest link. They are only one link and one part of the problem.

Apple's take, using the cloud as a form of automated storage, is a better bet. You get the convenience of local access plus the comforts of remote storage and availability. I won't care (as much) if my link to Apple gets cut because my Word document (or Pages for you purists) is resting peacefully in my Documents folder. Let the backhoes come and let destruction break forth upon my internet connection. I am prepared.

That's not to say that view isn't without its problems of course. It means my hardware purchases will still require more hard drive capacity which means greater expense. It means that I will be responsible for keeping my software up to date instead of simply hitting a website where the software is always up to date. But hard drives are getting cheaper for the most part. It's a downward trend for price, even for SSD devices. And the automatic update functionality for any major OS these days provides plenty of convenience for staying patched. For apps that I didn't get from an App Store, there are still options. Developers have been including update checks in their software for years. And of course, for those that don't, yes there will be a gap. The gap is shrinking over time.

The fact is that Google cannot guarantee that I will always be able to access my data and software anytime, from anywhere. They can hold up their end of things and frankly I trust them to do that. Not just because they have shown a penchant for being able to put together solid deployments but also because it's becoming their lifeblood. What they cannot do is ensure I will always be able to read my poetry at 3AM. And that's just unacceptable.

8Sep/110

Android Cut By The Splinters

So it seems Eric Schmidt, chairman of Google, accidentally gave notice that Android 4.0, the next release of the search giant's mobile OS, will be released in the October/November timeframe. Of course, that may change but regardless it appears to be coming soon. Whether it comes soon or not, without major uptake by a lot of handset vendors and service providers, it's simply going to add to the growing pileup of currently deployed Android revisions, increasing the fragmentation even more.

Android 4.0, code named Ice Cream Sandwich, is intended to, among other things, refine the APIs with an effort to reduce fragmentation. Android 2.0 (Eclair) was released in October 2009, 2.2 (Froyo) was released in May 2010, while 2.3 (Gingerbread) came out in December 2010. 3.0, aka Honeycomb, was a tablet only version first released in February 2011. 2.2 (Froyo) is currently deployed on roughly 50% of Android devices with 2.3 (Gingerbread) installed on another 30% or so. Honeycomb, the tablet version, is only deployed to about 1.5% of Android devices, a fact which leads to its own conclusions, but that's for another time. The fact is, the APIs were originally supposed to be forward compatible. Something written to target an older revision of the OS should work on newer revisions, until a major release comes along which might break API compatibility. The API, therefore, is intended to provide shelter to developers hoping to deploy against the largest possible number of devices. The problem, though, isn't developer application support for various OS's. The problem is the hardware.

The handsets are targeted at a given revision of the OS and a lot of time and money is put into making sure the handset works as intended with that version of the OS. Even between minor releases, as evidenced by the already existing fragmentation, it has been difficult to get the various parties involved to consider revisiting existing handsets, some of which might not even be marketed any longer and therefore unlikely to provide further revenue through additional sales, in order to incorporate a new Android revision.

Android 4.0 is supposed to address this, allowing one OS to target both handsets as well as tablets. That's great, but realistically is not going to reduce fragmentation very quickly. To begin with, Android tablet sales have been something just shy of anemic but even then it is doubtful that without some potent new features unlocked with 4.0 any Android tablet manufacturer will want to revise the OS on tablets currently in the sales channel, much less those no longer being sold. As for handset developers, they're in a worse boat since many deployed devices are much older than any tablet currently out there. And it's not like current handsets will suddenly drop dead of electronic heart attacks now that 4.0 is available. They will continue to perform as they always have. So Android 4.0 is really only expected to solve fragmentation moving forward.

And yet, even with the release of 4.0 imminent, major manufacturers who must have had access to beta versions of Ice Cream Sandwich, have still elected to roll their own with forked older versions of Android (vis-a-vis the upcoming Kindle). Sure, eventually Android 4.0 will become the mainstream version rolled out on new devices. But by then Google might have already been working on Android 5.0, aka Monster Truck Rally (who knows?). Meanwhile, the Android ecosystem will be falling to pieces.

8Sep/110

Google, Red Handed and Red Faced

Now making the rounds are comments surrounding the internal Google documents revealed in the Oracle v Google case. The bits that seem to have everyone's interest aroused concern two things. The pertinent bullet points from the discovered document are as follows:

  • Do not develop in the open. Instead, make source code available after innovation is complete
  • Lead device concept: Give early access to the software to partners who build and distribute devices to our specification (ie, Motorola and Verizon). They get a non-contractual time to market advantage and in return they align to our standard.

A lot of time and attention is being given to these statements, making Google out to be hypocritical or as having less than savory business practices. The fact is that there is absolutely nothing wrong with either of these practices.

The first bullet point, concerning not developing in the open, is innocuous. There's nothing evil going on here. There's nothing about open source or openness in general that requires your code repository be visible 24x7 for all the world to see. If you want to stay in the coding cave and do your development (or innovate as Google puts it), only releasing the fruits of your labor when they are ripe and bursting with innovative goodness, that is your prerogative. I suspect it's the word choice that has folks up in arms here but conceptually this is the same thing as the guy working on a new device driver to tack onto the Linux kernel, not releasing it until it's feature complete. Really, it's just not a big deal.

The second bullet point, concerning early access to partners who abide by Google's standards, is a bit more interesting, but nonetheless does not rise to the level of being 'wrong'. Perhaps a bit embarrassing and maybe even damaging now that it's out in the open, but not wrong. If Google is developing a codebase and wants partners to adhere to their standards as a precondition of early access, isn't that their right? Is there anything indicating they absolutely must provide access to everyone, equally? Most open source licenses simply indicate what is involved in the relationship between the developer and the recipient of the code. It has nothing to do with any other relationships. Should Google have done this? Probably not from where they're sitting now, but at the time it was a calculated risk. Were they able to offer something in exchange for partners abiding by the vision Google had for the Android platform? What were the chances of it becoming public knowledge? How damaging would it be? Unfortunately for Google they may be about to find out. For my part? *meh*

7Sep/110

Google’s Cloud Evaporating

I've written before, elsewhere, about cloud computing as the latest trend (though that's not to say it's new, just that it is trending.. again). At the time I laid out pros and cons from the point of view of putting the entire computing experience into the cloud. But of course, that's only one way to do it. Currently there are two major companies who are pushing their own views of how cloud computing should be done, Google and Apple. And Google just stumbled.

Google suffered an outage today with their Google Docs service. Google Docs, if you are not familiar with it, allows one to import, create, edit and share documents using only your Google account and a modern browser. These documents are Office-like, with the ability to import Word, Excel and Powerpoint documents as well as to create native Google Docs documents too. All of the storage is tucked away on Google's servers. All you need to be able to do is launch a browser and direct it to Google and you're good to go. Equally convenient is the ability to share these documents with other Google users making them immediately available for viewing or even editing, including collaborative editing should you so choose. That is, convenient until it stops working.

Apple on the other hand is nearing the release of the much anticipated iCloud service, enabling the cross-device sharing of documents and settings between thick client apps on a per user basis. As information is altered, it is marked for synchronization. Presumably if the service is unavailable, the synchronization step is simply delayed until the service is available once more. This could be because the network connectivity has dropped or because Apple's servers are dead. It doesn't really matter. The cloud connection becomes a mere background task while for the end user life goes on as usual. And that's the way cloud computing should be.

Google's entire platform is centered around it's own services run on its own servers. Apple is about their hardware. The services are an aside, or perhaps a funnel, showing potential buyers the extra goodies they get by joining the Apple camp. As a result, Apple doesn't need to create a web enabled version of iWorks or iLife that works in a browser. They don't want to. They want apps that run on your iron, in your own home or office. Namely, the iron you bought in the form of your MacBook or iMac or Mac Pro. Google, on the other hand, is platform agnostic. You could be using a Dell, an Asus, an HP (well, for a little while longer anyway). It only matters that you are using their services.

I should correct myself. Google does actually have hardware for sale... the Chromebook. Running their OS, targeted at their services and software. So in fact, insofar as Google is playing in the hardware space, they are actual working the exact reverse route as Apple, using hardware to sell their services. As their flagship hardware product, I don't expect them to drop it, but I also don't expect it to take off. Especially with the possibility that one little network outage could leave you unable to work with any of your documents.

Which brings us back to today's outage. Google hasn't misstepped very often, but they've double down on software as a service and full commitment to cloud computing, pushing everything off of the user's PC and into the cloud. As a result, if they lose this bet, it's going to hurt very badly. And that doesn't even mention Microsoft's burgeoning efforts in this space. Google is taking their stand in the cloud but if they're not careful, they'll find themselves taking a big fall.

7Sep/110

What Went Wrong At Yahoo?

Yahoo is hurting. It's been hurting for some time now. It's growth has been stunted, in fact seeing ad revenue shrink, particularly in the face of fierce competition from Google and subsequently Facebook. According to the Wall Street Journal, an insider source reports the company is willing to consider selling to the right bidder. Taken with the rest of the financial news about the company's woes, it signals a pretty sharp descent from what were once lofty heights. What went wrong?

It is easy to say "Google and Facebook" and leave it at that, but that leaves a lot unsaid. Google, for instance, nominally offered precisely what Yahoo was offering. As has been stated repeatedly of late, the real client of Google (as well as Yahoo) is advertisers. Their real product for sale is the attention of the users of their various services. But in order to create that product, they still have to provide something attractive for those visitors. In other words, a better experience. That is where Yahoo failed against Google. Whether Google has strayed from it's "Don't Be Evil" mantra, it started by focusing on providing quality search results for those using their search engine. The algorithm has been tinkered with and improved over time, but even from the start, users were treated to a very simple and very effective interface. One text field, one button. This was in contradiction to Yahoo's interface which enticed you to drill down through their heirarchy of categories. Of course Yahoo also had a search field, but on top of the relative clutter of their home page, they had yet to really provide a similarly effective search experience. As a result, the core reason people visited either site was better served by going to Google rather than to Yahoo. Yahoo began providing peripheral services to their users before Google did, like Yahoo Mail, still one of the most widely used web-based email services. But monetizing those services was still problematic.

So what of Facebook? Where Google stepped in and did Yahoo's services but better, Facebook offered a completely different service but one that ultimately competed for the same advertisers. Yahoo has had social services and had them in place well before Facebook. But again, they weren't capitalized on and thus lost ground. Moreover, services like Yahoo Groups, Yahoo Personals and Yahoo 360 were all too disparate and never provided a single cohesive experience for the end user. Facebook provided all of the social aspects in one location and has continued to add to them. More importantly, Facebook provided third party developers the opportunity to tap into their ecosystem and make money. This not only increased direct revenue to Facebook, it also allowed additional compelling content to come into Facebook for visitors without Facebook having to lift a finger to create it. Yahoo, in contrast, focused primarily on user created content and again didn't seem to effectively make what services they did have into revenue centers.

What Yahoo lacked was a focused vision of not only where to go but how to get there. It seems like any time a new feature was to be added, it would be bolted on rather than integrated. And with the revolving door policy that is developing in their top spot and now the leadership-by-committee approach that also looks to be developing, Yahoo doesn't look to be breaking out of their slump anytime soon. Still, they are big. They do get traffic. They may not be top dog, but they aren't to be ignored. If the right person is brought in with the right mandate, a lot could be done to turn the company's fortunes around.

I'm just not holding my breath.