Jan 14

Bimodal tablets (Windows and Android). Remember them when they’re gone. Again.

I hope these rumors are wrong, but for some odd reason, the Web is full of rumors that this year’s CES will bring a glut of bimodal tablets; devices that are designed to run Windows 8.1, but also feature an integrated instance of Android. But why?

For years, Microsoft and Intel were seemingly the best of partners. While Microsoft had fleeting dalliances with other processor architectures, they always came back to Intel. There were clear lines in the sand;

  1. Intel made processors
  2. Microsoft made software
  3. Their mutual partners (ODMs and OEMs) made complete systems.

When Microsoft announced the Surface tablets, they crossed a line. Their partners (Intel and the device manufactures) were stuck in an odd place. Continue partnering just with Microsoft (now a competitor to manufacturers, and a direct purveyor of consumer devices with ARM processors), or find alternative counterpoints to ensure that they weren’t stuck in the event that Microsoft harmed their market.

For device manufacturers, this has meant what we might have thought unthinkable 3 years ago, with key manufacturers (now believing that their former partner is now also a competitor) building Android and Chrome OS devices. For Intel, it has meant looking even more broadly at what other operating systems they should ensure compatibility with, and evangelization of (predominantly Android).

While the Windows Store has grown in terms of app count, there are still some holes, and there isn’t really a gravitational pull of apps leading users to the platform. Yet.

So some OEMs, and seemingly Intel, have collaborated on this effort to glue together Windows 8.1 and Android on a single device, with the hopes that the two OSs combined in some way equate to “consumer value”. However, there’s really no clear sign that the consumer benefits from this approach, and in fact they really lose, as they’ve now got a Windows device with precious storage space consumed by an Android install of dubious value. If the consumer really wanted an Android device, they’re in the opposite conundrum.

Really, the OEMs and Intel have to be going into this strategy without any concern for consumers. It’s just about moving devices, and trying to ensure an ecosystem is there when they can’t (or don’t want to) bet on one platform exclusively. The end result is a device that instead of doing task A well, or task B well, does a really middling job with both of them, and results in a device that the user regrets buying (or worse, regrets being given).

BIOS manufacturers and OEMs have gone down this road several times before, usually trying to put Linux either in firmware or on disk as a rapid-boot dual use environment to “get online faster” or watch movies without waiting for Windows to boot/unhibernate. To my knowledge most devices that ever had these modes provided by the OEM were rarely actually used. Users hate rebooting, they get confused by where their Web bookmarks are (or aren’t) when they need them, etc.

These kinds of approaches rarely solve problems for users; in fact, they usually create problems instead, and are a huge nightmare in terms of management. Non-technical users are generally horrible about maintaining one OS. Give them two on a single device? This will turn out quite well, don’t you think? In the end, these devices, unless executed flawlessly, are damaging to both the Windows and Android ecosystems, the OEMs, and Intel. Any bad experiences will likely result in returns, or exchanges for iPads.

May 13

The Cloud is the App is the Cloud.

During the last week, I have had an incredible number of conversations about Office 365 with press, customers, and peers. It’s apparent that with version 3.0 of their hosted services, as Microsoft has done many times before at v3.0, this is the one that could put some points on the board, if not take a lead in the game.

But one thing has been painfully clear to me for quite some time, and the last week only serves to reinforce it. As I’ve mentioned before, there’s not only confusion about Microsoft’s on-premises and hosted offerings, but simply confusion about what Office 365 is. The definitions are squishy, and Microsoft isn’t doing a great job of really enunciating what Office 365 brings to the table. Many assume that Office 365 is primarily about the Office client applications (when in fact only the premium business editions of Office 365 even include the desktop suite! Many others assume that Office 365 is only hosted services, and Web-based applications, along the lines of Google Apps for Business.

The truth is, there’s a medley of Office 365 editions among the 4 Office 365 “families” (Small Business, Midsize Business, Enterprise/Academic/Government, and Home Premium). But one thing is true – Office 365 is about hosted services (Exchange Online/Lync Online/SharePoint Online for businesses, or Outlook.com/Skype/SkyDrive for consumers), and – predominantly – the Office desktop application suite.

I bring this up because many people point at native applications and Web applications and say that there is a chasm growing… an unending rift that threatens to tear apart the ecosystem. I disagree. I think it is quite the opposite. Web apps (“cloud apps” if you like) and native apps (“apps”) are colliding at high speed. Even today it isn’t really that easy to tell them apart, and it’s only going to get harder.

When Adobe announced their Cloud Connect service last week, some people said there wasn’t much “cloud” about it. In general, I agree. To that same end, one can point a finger at Office 365 and say, “that’s not cloud either” because to deliver the most full-featured experience, it relies upon a so-called “fat client” locally installed on each endpoint, even though for a business, a huge amount of the value, and a large amount of the cost, is coming from the cloud services that those apps connect to.

To me, this is much ado about nothing. While it’s true that one can’t call Office 365 (or Cloud Connect) a 100% cloud solution, at least in the case of Office, each version of Microsoft’s hosted services has come closer than the one before to delivering much of the value of a cloud service, it continues to rely on these local bits, rather than running the entire application through a Web browser. With Office, this is quite intended. The day Office runs equally well on the Web as it does on Windows is the day that Microsoft announces they’re shutting down the Windows division.

But what’s interesting is that as we discuss/debate whether Microsoft and Adobe’s offerings are indeed “cloudy enough”, as they strive to provide more thick apps as a service, Google is working on the opposite, applications that run in the browser, but exploit more local resources. When we look at the high-speed collision of Android into ChromeOS, as well as Microsoft’s convergence of Web development into the WinRT application framework, this all begins to – as a goal – make sense.

In 1995, as the Web was dawning, it wasn’t about applications. It was about sites. It gradually became about applications and APIs – about getting things done, with the Web, not our new local networks, as the sole communication medium. Conversely, even the iPhone began with a very finite suite of actions that a user could perform. One screen of apps that Apple provided, and extensibility only by pinning Websites to the Home screen. Nothing that actually exploited the native power and functionality of the phone to help users complete tasks more readily. Apple eventually provided the full SDK that enabled native, local applications, which would still often connect out to the Internet to perform their role – when the Internet was available.

Windows has largely always been about “fat client” applications, even going so far as to have the now quite old – but once new and novel – Remote Desktop Protocol to enable fat clients to become light-ish weight, as long as a network connection back to the server (or eventually desktop) running the application was available.

I bring these examples up because the idea  of “cloud applications” or cloud services is, as I noted, becoming squishy and hard to explicitly define, though I have to personally consider whether I really care that deeply about when applications are or are not cloudy (or are partly cloudy?).

Users buy (or use) applications because they have a specific task they need to complete. Users don’t care what framework the application is written in, what languages were used, what operating system any back-end of the application is running on, or what Web server it is connecting to.

What users do care about is getting the task done that led them to that application to begin with. Importantly, they need productivity wherever it can be available. With applications that are cloud-only, when you have a slow, or nonexistent Internet connection, you are… dead. You have no productivity. Flying on a plane but editing a Word document? You need a fat client. Whether it’s Google Apps for Business running on a Chromebook (with caching), QuickOffice on an iPad, or Office 2013 Pro Plus running on a Windows 7 laptop, without some local logic and file caching, you’re SOL at 39,000 feet without an Internet connection.

Conversely, if you are solely using Microsoft Office (or Pages), and you’re editing that important doc at an airport that happens to have WiFi before a flight that does not have WiFi, you might be SOL if you don’t sync the document to the Web if you accidentally leave your laptop on board the flight afterwards, never to be seen again. Once upon a time, productivity meant storing files locally only, or hand-pushing files to the Web. Both Office 2013 and Apple’s iWork (through iCloud) offer great synchronization.

The point is that there is value to having a thicker client:

  • Can take advantage of local hardware, data, and services.
  • Can perform some level of role offline.

But there is value to taking advantage of the Web:

  • Saved state from application can be recovered from any other device with the application and correct credentials.
  • Can hook into other services and APIs available over the Web, pull in additional data sources, and collaborate with additional users inside or outside the organization.

But I believe that the merit of both mean that the future is in applications that are both local and cloudy – across the board. Many people are bullish that Chromebooks are the future. Many people think Chromebooks are bull. I think the truth is somewhere in the middle. As desktop productivity evolves, it will have deeper and deeper tentacles out to the Web – for storage and backup, for extensibility, and more. Conversely, as purely Web-based productivity evolves, expect the opposite. It will continue to have greater local storage and more ability to exploit local device capabilities, as we’re seeing Chrome and ChromeOS do.

Office 365 isn’t a cloud-only service in most tiers. Nor do I ever really expect it to be. Frankly, though, Google Apps isn’t really a cloud-only service today – and I don’t expect it to go any direction except towards a more offline capable story as well. Web apps and native apps aren’t a binary switch. We won’t have one or the other in the future. Before too long, most Web apps will have a local component, and most local applications will have a Web component. The best part is that when we reach this point, “cloud” will mean even less than it means today.