14
Apr 13

The PadFone is not the future

I’ve been pondering the existence of devices like the Asus PadFone and PadFone 2 recently.

Not really convertible devices, not really hybrid devices, they’re an electronic centaur. Like an Amphicar or a Taylor Aerocar, the PadFone devices compromise their ability to be one good device by instead being two less than great devices.

I haven’t found a good description of devices like the PadFone – I refer to them as “form integrated”. One device is a dumb terminal and relies on the brain of the other.

While a novel approach, the reality is that form integrated devices are a bit nonsensical. Imagine a phone that integrates with a tablet, or a tablet that integrates into a larger display. To really work well, the devices must be acquired together, and if one breaks, it kills the other (lose your Fone from the PadFone, and you’ve got a PadBrick).

You also wind up with devices where the phone must be overpowered in order to drive the tablet (wasting battery) or a weak phone that results in a gutless tablet when docked.

Rather than this “host/parasite” model of the form integrated approach, I would personally much rather see a smart pairing of devices. Pairing of my iPhone, iPad, and Mac, or pairing of a Windows Phone, Windows 8 tablet, and a Windows 8 desktop.

What do I mean by smart pairing? I sit down at my desktop, and it sees my phone automatically over Bluetooth or the like. No docking, no need to even remove it from my pocket. Pair it once, and see all the content on it. Search for “Rob”, and see email that isn’t even on the desktop. Search for “Windows Blue”, and it opens documents that are on the iPhone.

The Documents directory on my desktop should be browsable from my phone, too (when on the same network or if I elect to link them over the Internet).

Content, even if it is stored in application silos, as Windows Store applications and iOS/OS X applications do, should be available from any device.

I think it would also be ideal if applications could keep context wherever I go. Apple’s iCloud implementation begins to do this. You can take a document in Pages across the Mac, iPad, and iPhone, and access the document wherever you are. Where Asus is creating a hardware-based pairing between devices, Apple is creating a software-based pairing, through iCloud. It is still early, and rough, but I personally like that approach better.

My belief is that people don’t want to dock devices and have one device be the brain of another. They don’t want to overpay for a pair of devices that aren’t particularly good at either role and instead will pay a premium for two great devices, especially if they integrate together seamlessly and automatically.

Much as I believe the future of automotive electronics is in “smartphone software integrated” head units rather than overly-complex integrated computing built into the car, the future of ubiquitous computing lies in a fabric of smart devices that work together, with the smartphone most likely being the key “brain” among them. Not with its CPU driving everything else, but instead with it’s storage being pervasively available wherever you are, without needing to be docked or plugged in.


06
Jan 11

Windows on ARM – some notes

This evening, in lieu of a transcript, I listened a few times to Steve Ballmer’s CES keynote – specifically around the 3:06:23 mark. Given my blog post yesterday, I was most curious as to whether I was correct that there would not be any x86 application compatibility for Windows running on ARM. Steve’s words are below, emphasis is mine:

“We are very excited about the full set of partners for the next version of Windows.
NVidia, Qualcomm and Texas Instruments are working on SoC designs based on the ARM architecture.
Intel and AMD will continue to innovate on the x86 platform, including the new low-powered SoC systems that will be fully supported by Windows and will include support for native x86 applications.”

To paraphrase the above, x86-based SoC systems will of course include x86 application support, but new ARM-based SoC systems will not provide any emulation support for native x86 applications. Applications and device drivers will have to be recompiled and/or rewritten to run on Windows on ARM.

This is very significant, as it is both a pro and a con. The pro is that legacy x86 applications not optimized for gesture won’t likely cross into ARM, and new applications will likely be written that both take advantage of the ARM processor, end-user scenarios anticipated for the device (not sitting at a keyboard using a mouse, running Lotus 1-2-3), and be designed for the small/mobile form factors we can anticipate. The con is of course that application compatibility is what made Windows what it is today – most major applications make the leap from version to version of Windows,  and Microsoft makes a concerted effort to ensure legacy application compatibility. If you have an ancient x86 app for Windows 7 that you love, it may not be waiting for you (but a new version or an entirely new app may be) when you get there. This is uncharted territory for Microsoft. I can recall major burps Windows has hit along the way – 95 (loss of some 16-bit apps and many devices), ME (loss of real-mode DOS apps, XP (loss of many more DOS apps and many devices), Vista (mostly loss of devices). But this will be the most major hiccup I can think of in terms of application compatibility. Honestly, I feel that is a mixed bag, and Windows on ARM shouldn’t be noted as a “it’s a stupid idea because…” as I think a new generation of apps, designed for the form factor, CPU, scenarios, and end-user needs will be far more valuable to Microsoft than 20 year old applications that don’t need any of the new functionality delivered by systems using the ARM SoC architecture. Another significant benefit to excluding emulation support for x86 on ARM is operating system size. In order to support x86 applications with an emulation layer, the operating system would likely need to be nearly twice the size of an ARM-only version.

As I alluded to yesterday, Windows on ARM is step 1 of 4 to building computers (tablet/slate or other) that can compete with the iPad. This first step is significant – but it shouldn’t be touted as a move that will make a Windows PC on ARM an immediate alternative/equivalent for a consumer considering an iPad or other ARM-based slate or ARM-based notebook. To do that, Microsoft has to do the three additional steps, below.

  1. Natively support Windows on the ARM (or low-powered x86 SoC) processor architecture (including streamlining the OS to minimize background services and processes that blow CPU time/battery life)
  2. Emphasize gesture-based APIs as an equal mode of interaction with Windows vs. mouse/stylus
  3. Work with OEM partners to come up with system designs that are feature/value competitive, unique, and that consumers fall in love with
  4. Evangelize and enable an ecosystem of gesture-based applications and games before the platform arrives

04
Jan 11

Should Microsoft ARM Windows?

There has been quite a bit of recent discussion and hearsay about Windows on ARM processors – that is, a rumor that Microsoft is developing a version of Windows (full Windows, not CE/Windows Phone 7 – which already run on ARM)  that supports the low-powered ARM processor preferred for mobile devices today.

Windows NT, upon which all full versions of Windows today are based, was designed from day one to be a “portable” architecture. Though the Intel x86 (and the architecturally derived 64-bit AMD64/x64 platform) has always been and continues to be the principal architecture supported by Windows, it didn’t start out that way (the first architecture supported by NT wasn’t x86 – it was the Intel i860 RISC processor – explicitly to force a portable architecture).

Throughout it’s life, NT has supported quite a few non x86 architectures – but in the end, every one has been deprecated – even the Intel Itanium (IA64) architecture is now end-of-lifed – leaving x86 and it’s descendant x64 as the sole Windows architectures. Again.

It is surely possible that the Windows codebase could be ported to support the ARM architecture. But let’s stop for a second and asses what Windows on ARM would really mean. Assume Microsoft released a version of Windows 7 (say at the same time as Service Pack 2) or it simultaneously shipped Windows 8 for ARM at the same time it shipped for x86/x64 in the assumed Q4CY2012 timeframe. What would Microsoft really gain?

As many people say Microsoft should port ARM to Windows, I think it’s important to note what Microsoft would and would not gain by adding support for ARM. This list is not perfect, it is comprised of some fact and some opinion, and I welcome your feedback and will tune it accordingly. But I believe anyone saying, “Microsoft needs to port Windows to ARM” should carefully consider this maneuver. Microsoft has never sustained Windows on any platform besides x86. What would make Windows on ARM succeed where others have failed?

Truths of Windows on ARM

  • Windows on ARM is possible. TRUE – Microsoft has ported the Windows codebase to RISC architectures before, and could surely do it again. The low power constraints of ARM provide a unique challenge, but it could be done. See the next point though; this is only part of the battle.
  • Windows applications could be ported to ARM. TRUE – Though key applications and APIs are designed explicitly for the x86 or x64 architecture, it would not be insurmountable to port them to ARM – again, this still isn’t the most significant problem facing Microsoft to provide an iPad counterpoint – gesture-based navigation and low power consumption are.
  • Windows on ARM could provide a desktop platform as well as a tablet platform. TRUE – certainly Windows optimized for tablets could run on desktops as well, and would likely provide a great thin client platform (as Windows CE and now Windows Embedded Compact have done for some time). Touch enablement may not be as logical here, though and a focus on thin clients would risk mindshare and potentially marketshare of Office users unless an ARM-based, gesture-focused version of Office was also available.

Fallacies of Windows on ARM

  • Windows on ARM will provide a counter to the iPad. FALSE (technically) – Architecturally porting Windows is step one. Gesture-enabling the entire operating system and providing gesture-focused development APIs are step two. OEMs must then provide devices as compelling as or more compelling than the iPad, at a competitive price and with reasonable non-WiFi connectivity options (see the recent $100 Galaxy Tab price drop for an example here). Simultaneously, Microsoft would need to nurture an ISV application ecosystem in a way they have not in some time, and with urgency they haven’t really ever done – all while not randomizing the Windows Phone 7 platform or ISV ecosystem.
  • Windows applications and games will work on Windows on ARM. FALSE – no way. Windows has used legacy application compatibility as a cantilever to induce upgrades from one version to the next. Not only is that not possible in this scenario, it becomes a liability. Every aspect of Windows and any application would need to assume that there may never be a mouse or physical keyboard attached to the system, and must focus on gesture-based navigation at all times – if it is to provide a true counterpoint to iOS. In addition, Microsoft would need to provide Flash and Silverlight for this platform, or full HTML5 in the browser in order to enable multimedia playback. If Microsoft included a full Flash runtime, it would need to be gesture enabled as well, and would likely encounter power consumption and/or performance issues. Android and other ARM-based platforms running Flash have been criticized for high power consumption, as have full Windows systems running on single-core Atom processors (simultaneously criticized for their performance – resulting in the need for dual-core Atom processors).
  • Windows on ARM provides a significantly better solution than a gesture-enabled Windows running on Atom. False – though a power-optimized, gesture-enabled Windows with API support is hardly trivial – it is an easier task than porting Windows, and would result in legacy applications working – though that is potentially a detriment, not a benefit.
  • Windows on ARM provides a significantly better solution than Windows CE or a “Windows Tablet 7” derived from Windows Phone 7 would. FALSE – Windows Phone 7 has shipped, and will be updated throughout 2011. It is gesture-enabled now, runs on ARM processors today, and supports gesture-enabled application development. Though no legacy x86 applications would be supported (I believe this actually to be a net benefit), it would be considerably easier to derive a Tablet/slate focused version from Windows Phone 7 than porting Windows.
  • Devices for Windows would work with Windows on ARM. FALSE – no devices would make the shift. Though this has traditionally been a detriment to Windows (lack of application and device driver support precluded Windows XP for x64 from being widely adopted) this would actually be a net benefit if considering a competitor to iOS. You don’t want mice. You don’t want legacy keyboard, display drivers, or game controllers. Those are baggage. In a gesture-enabled Windows, the cut line needs to be clear, or customers won’t understand, and OEMs won’t “go big” with new platforms.

14
Dec 10

App Ideas – Parking finder

Name: Parking finder

Product: Mobile maps (iPhone, Android, Windows Phone 7, any other mobile device)
Problem: When looking up directions to a destination – why not provide parking resources too?
Proposed solution: You’re looking up directions to a theatre, pub, or some other venue that you want to go to – and almost any mapping software can get you there. But if you’re traveling to any densely populated area, such as downtown in a major city, a theme park, or other major destination – getting you there is only half of the battle. Where do you park?

  1. When looking up directions you should be able to specify include parking as an option, or set it as the default for your mapping product.
  2. Type in the destination.
  3. Click Route
  4. The directions include steps to get you to the destination by offering you nearby parking, which you can select and then be offered walking/bus/transit directions to get to your destination.
  5. Bonus points:
    1. Easy: Include options to categorize available parking by type:
      1. Street|Lot|Garage
      2. Free|Pay
      3. Cash|Credit
    2. Harder: Include pricing information
    3. Hardest: Include availability, and even offer the option to reserve a space using a credit card/Paypal.

Next time you go to a restaurant or concert, and you find parking a challenge, listen to the feedback around you – you’re not alone. I’ve noticed it’s a common thread that people have difficulty finding parking near their destination.


11
Dec 10

App Ideas – Route builder

This is the first post in a series I plan, outlining ideas either for modifications to existing products, or a desire for an entirely new product. As a product manager or program manager for almost 10 years, random ideas strike me at a moments notice, but I can’t productize everything I dream up. If I post an idea here, it is public domain.

Name: Route builder
Product: Mobile maps (iPhone, Android, Windows Phone 7, any other mobile device)
Problem: When you need to run three errands, why can you only put in one destination?
Proposed solution: Say you need to go to Target, your Chase bank branch, and a Hallmark store. Sure, if you’re in your home town, or going to stores you always use, it would be limited in use. But when going to stores, parks, or other destinations you dont normally visit or when travelling to other cities, it would be useful.

  1. Click Build Route
  2. Type in each of the destinations. I envision a spot for a single destination, with a + to append additional destinations.
  3. Click Route
  4. Route builder finds the most efficient route to visit all three of those destinations.
  5. Bonus points:
    1. I should be able to tell my mapping app my home address, work address, and add addresses of family members by way of the address book, allowing me to use them as a destination (or if I’m at one of them, the source).
    2. With any route, the user should be able to specify that they want to complete a round trip to their current location. In doing so, the route could be optimized either by the order I need or want to visit them, or by the most efficient route.
    3. I should be able to save a route for access later if I want to.
    4. This could easily be modified to append additional destinations after you’re on your way to destination 1.

As an iPhone owner, I’ve often wished for this functionality in the iPhone’s built in Maps application – and I doubt I’m alone.