Reply to Message
The OS is only a small factor
Microsoft has always stumbled on this because they've never really committed to their decision. Consider the approaches here:
- Microsoft tried implementing tablet functionality into a desktop OS. This didn't work. Why? Because the vast, vast majority of apps were meant to be used on a desktop. So what if you could bring up an on-screen keyboard or handwriting-to-text conversion panel? It wasn't integrated, it wasn't cohesive. Just cumbersome and ill-supported. Most developers would never test their application's accessibility with a tablet interface. Plus, the available hardware sucked, and you still had full boot and shutdown times - no instant-on gratification - making it little more than an underpowered, expensive device lacking the ergonomics and power of a laptop or desktop. FAIL.
- Microsoft's Media Center is an application on a general purpose OS. This is OK if you wanted a PC in your entertainment system, but most people didn't. They wanted an appliance with the power, versatility, and customizability of commodity PC hardware. When specialized hardware (tuner and A/V output cards) *finally* started showing up to give a computer the same I/O capability as a cable box or DVR, the only thing lacking was software that could be used with the ease of a remote. Again, you don't want a Start menu and 60-second boot times. Appliance-like. Windows MCE was never like this. Again, FAIL.
- Apple's iPad solved all of these problems. It turned on instantly, it had a consistent interface. Apps that ran on the iPad were *designed* for the iPad. The only problem, really, is how locked down it is. No custom apps, lack of flexible I/O. But it did what it was supposed to do, and it did it REALLY WELL. Finally, a successful tablet computer.
- Linux has a ton of options for customizing commodity hardware. You can get the power of a real, modern multitasking kernel, and do whatever you want with the UI. Touch, appliance-like, whatever. But, you have to build it yourself. For a very small niche, this has been nearly perfect. The only thing really preventing (albeit limited) success is the effort required by developers to support enough and the right kind of hardware, and of end-users to essentially engineer their own solutions. Unless some third party sells a pre-fabbed bundle, this won't ever take the computing world by storm, but for some it's plenty.
So, given this history, what direction should Microsoft go? Bundle the add-ins with the base OS, or develop separate OSes? Neither.
The problem here is that MS doesn't know how to do "modular". What they NEED to do is build "The Windows Kernel" and package that with:
1) a general-purpose KB/mouse UI for desktop use.
2) a minimal KB-only, or KB/mouse UI for server use.
3) a minimal touch UI for tablet use.
4) a minimal graphical UI with generic input event handlers for interactive appliance use.
5) no UI for hypervisor or headless service hosting use.
Is this a lot of effort? No, not really. You have a kernel team, a driver team, a base library team, a couple UI teams, and a couple integration teams. The kernel should build with any level of options enabled to suit the target platform. The GP-OS would be the superset of ALL options, so the duplication of testing would be minimal.
The development tools should be built to target these different platforms and load the requisite UI libraries rather than the generic Win32 presentation library as it exists now. Changing the interface would be as simple as building an alternate presentation layer on an existing codebase. Developers who build business logic into the UI will have trouble with this, but that's NEVER been a good practice, and Linux has proven this approach works. Many applications can be targeted for console use, or gtk or Qt UIs through a simple switch passed to the build script.
As separate, targeted, supported platforms, when someone distributes a desktop application, they don't need to worry how tablet users would be able to use it. But they can take their back-end code, develop an alternate UI and compile it for the tablet market if they choose to. Etc., etc.
This is the ONLY approach that will work, and I bet my left big toe that MS has still not learned this one essential lesson. And they will still fail to dethrone the iPad. Now, they stand to lose the desktop, too.
- Microsoft tried implementing tablet functionality into a desktop OS. This didn't work. Why? Because the vast, vast majority of apps were meant to be used on a desktop. So what if you could bring up an on-screen keyboard or handwriting-to-text conversion panel? It wasn't integrated, it wasn't cohesive. Just cumbersome and ill-supported. Most developers would never test their application's accessibility with a tablet interface. Plus, the available hardware sucked, and you still had full boot and shutdown times - no instant-on gratification - making it little more than an underpowered, expensive device lacking the ergonomics and power of a laptop or desktop. FAIL.
- Microsoft's Media Center is an application on a general purpose OS. This is OK if you wanted a PC in your entertainment system, but most people didn't. They wanted an appliance with the power, versatility, and customizability of commodity PC hardware. When specialized hardware (tuner and A/V output cards) *finally* started showing up to give a computer the same I/O capability as a cable box or DVR, the only thing lacking was software that could be used with the ease of a remote. Again, you don't want a Start menu and 60-second boot times. Appliance-like. Windows MCE was never like this. Again, FAIL.
- Apple's iPad solved all of these problems. It turned on instantly, it had a consistent interface. Apps that ran on the iPad were *designed* for the iPad. The only problem, really, is how locked down it is. No custom apps, lack of flexible I/O. But it did what it was supposed to do, and it did it REALLY WELL. Finally, a successful tablet computer.
- Linux has a ton of options for customizing commodity hardware. You can get the power of a real, modern multitasking kernel, and do whatever you want with the UI. Touch, appliance-like, whatever. But, you have to build it yourself. For a very small niche, this has been nearly perfect. The only thing really preventing (albeit limited) success is the effort required by developers to support enough and the right kind of hardware, and of end-users to essentially engineer their own solutions. Unless some third party sells a pre-fabbed bundle, this won't ever take the computing world by storm, but for some it's plenty.
So, given this history, what direction should Microsoft go? Bundle the add-ins with the base OS, or develop separate OSes? Neither.
The problem here is that MS doesn't know how to do "modular". What they NEED to do is build "The Windows Kernel" and package that with:
1) a general-purpose KB/mouse UI for desktop use.
2) a minimal KB-only, or KB/mouse UI for server use.
3) a minimal touch UI for tablet use.
4) a minimal graphical UI with generic input event handlers for interactive appliance use.
5) no UI for hypervisor or headless service hosting use.
Is this a lot of effort? No, not really. You have a kernel team, a driver team, a base library team, a couple UI teams, and a couple integration teams. The kernel should build with any level of options enabled to suit the target platform. The GP-OS would be the superset of ALL options, so the duplication of testing would be minimal.
The development tools should be built to target these different platforms and load the requisite UI libraries rather than the generic Win32 presentation library as it exists now. Changing the interface would be as simple as building an alternate presentation layer on an existing codebase. Developers who build business logic into the UI will have trouble with this, but that's NEVER been a good practice, and Linux has proven this approach works. Many applications can be targeted for console use, or gtk or Qt UIs through a simple switch passed to the build script.
As separate, targeted, supported platforms, when someone distributes a desktop application, they don't need to worry how tablet users would be able to use it. But they can take their back-end code, develop an alternate UI and compile it for the tablet market if they choose to. Etc., etc.
This is the ONLY approach that will work, and I bet my left big toe that MS has still not learned this one essential lesson. And they will still fail to dethrone the iPad. Now, they stand to lose the desktop, too.
Posted by nwallette
10th Jun 2011
