What I see that could happen is that you carry around a multiple form-factor device, e.g. alone it is just a phone, but plug it into a special screen and its a tablet. Attach it to a screen with a physical keyboard and it'd work as a laptop, plug it into a bigger base station type thing and it works as a low-powered desktop.
Each of the larger devices it could plug into could have their own processors, RAM, batteries, etc and connect to a Bus port (like laptops have for docking stations) on the phone and take control of its storage and peripherals.
I was thinking a scenario where a user would use it in 'phone mode' while walking around, 'tablet mode' while on the train or bus, 'laptop mode' at the coffee shop and then use it as a desktop when they get to work. The whole time working on the same document, emails, video conference, whatever, completely seamlessly (well, maybe a small break when switching what its plugged into). Of course to use it in other modes, you would have to carry along those devices. There is also the issue of applications not be suited for a smaller device, but you could hand off to a different version of itself, save its state and go into a sleep mode, or transfer processing to a server/cloud system.
If done right, you could have a very wide variety of devices with different sized screens and different features to cater to different audiences while keeping the same UI.
This makes a lot of sense - imagine if (certain) iPhone apps could be run as widgets on the OSX Dashboard (IIRC, widgets were the proving ground for phone apps)...
The issue this raises is one of prerequisites... are things like accelerometers supported on all Win8 machines? What about cameras?
The prerequisites could be handled in the same way that WP7 handles them already, by warning the user at install time in the store.
For example, some apps require a gyroscope, which I think handsets only came out with in the second generation. If you try to install one of these apps in the store, you'll be warned that some functionality won't work (or perhaps won't work at all - I haven't seen this). Similarly, I've seen reports that in the upcoming update aimed at lower end handsets, there'll be warnings in the store for the few apps that don't work with limited ram requirements.
I would predict Windows 8 will keep a similar list of the device's capabilities and warn the user in the store if they try to buy something that won't work.
It just warns you and says that "same application featurews may not be supported" or something like that. TouchDevelop and some of the Compass apps do this.
That's what I was saying. Its still possible to use TouchDevelop and compass apps without the gyroscope, hence why it is only a warning.
I was wondering though if there are any apps (or if developers have the option to set this) where an optional device feature such as the gyro is so integral to the app that it won't even install without the device capability. This is what I haven't seen yet - though maybe the marketplace is already filtering them out for me.
This wouldn't be a great experience because in addition to accelerometers, and gyros you can't really emulate MultiTouch with a pointer: one finger down would need to involve a click (to distinguish between movement and swiping), and the other gestures would need some indication of where (and how big) the "hand" is relative to the screen.
I think that this will be a good move for them provided they can implement it correctly. I think this would only work for machines with multitouch displays.
There are quite a few Windows Phone apps that don't need multitouch (or necessarily touch at all). Of course, it would be jarring to use a mobile version of most apps on a larger screen, just like it is with other phones-turned-tablets, but I would imagine the most popular apps would be re-released with new graphics to support multiple resolutions (as they have been on other phone-turned-tablets).
If Microsoft takes the same approach to displaying WP7 apps under Windows 8 that it takes to displaying them in the emulator for the development tools, resizing for different screen resolutions won't be critical.
The emulator uses the same resolution as a native phone (800x480 typical) which is quite legible on a larger screen due to the lower density of pixels on the larger display.
Apps running in the emulator are perhaps a bit oversized, but not untenably so.
It probably is, but trust me, you wouldn't want to use it. Because it does hardware level emulation, the Android emulator is unbelievably slow. Way too slow for normal use.
Edited to add: There have been efforts to build android simulators, i.e. compile android for x86 and don't do hardware level emulation. This is how iPhone and WP7 testing is done already, and would run perfectly fast enough.
Each of the larger devices it could plug into could have their own processors, RAM, batteries, etc and connect to a Bus port (like laptops have for docking stations) on the phone and take control of its storage and peripherals.
I was thinking a scenario where a user would use it in 'phone mode' while walking around, 'tablet mode' while on the train or bus, 'laptop mode' at the coffee shop and then use it as a desktop when they get to work. The whole time working on the same document, emails, video conference, whatever, completely seamlessly (well, maybe a small break when switching what its plugged into). Of course to use it in other modes, you would have to carry along those devices. There is also the issue of applications not be suited for a smaller device, but you could hand off to a different version of itself, save its state and go into a sleep mode, or transfer processing to a server/cloud system.
If done right, you could have a very wide variety of devices with different sized screens and different features to cater to different audiences while keeping the same UI.