http://news.cnet.com/8301-1035_3-20102167-94/nvidia-ceo-sees-tenfold-growth-in-mobile-chip-biz/

I suspect there might be some nifty footwork involving Jupiter but with many Apps using one of the Panoramic style interfaces the difference in form factor might not be that much of a problem ...

30,000+ Apps would be a nice start for a new Arm based tablet platform and would certainly give a boost to existing wp7 developers. 

And then there's HTML5 ...  Hmmmmmmm.

If MS would have just specified an aspect ratio and a minimum screen resolution (800x480 being the minimum) that would have been a lot better, IMO.

Look at the Foursquare app:

I don't see this working at all on a 1920x1200 screen, both in UI and UX(usability).

http://rd3d2.wordpress.com/2011/09/06/windows-phone-apps-on-win8-tablet/

Personally I would want this kind of app to be 'bigger' on a tablet-  so upsizing  could work quite well?

I wouldn't be suprised if Windows Phone 8 and its development framework are being specifically designed to work with the whole jupiter/immersive thing though. Maybe he's onto something, but just off by one major version.

5 hours ago,Harlequin wrote

Yeah, I doubt we'll see this. Like KDawg said, WP7 apps are designed to fit in those resolutions, be it 800x480 ad/or 480x800. Controls like Panorama and Pivot are for a phone UI. The layout is for a phone...the design, has a phone in mind.

This is the reason I was disappointed the "native" UI widgets and toolkit present in WP7 were entirely re-implemented in Silverlight: by having two different implementations of the same concept it means twice the effort is involved in doing "mind-shifting" work such as allowing WP7 apps to work on a PC, such as (for example) "expanding" the panorama view so all tiles are simultaneously visible. I believe this is the sort of thing Apple might do if they made a platform like this (using their ObjC-based frames throughout, no doubt) but thanks for the Silverlight lock-in (or rather, lock-out from system-provided services) you'll see that things really are constrained when it comes to ensuring applications can take full advantage of future runtime environments.

1 minute ago,W3bbo wrote

*snip*

This is the reason I was disappointed the "native" UI widgets and toolkit present in WP7 were entirely re-implemented in Silverlight: by having two different implementations of the same concept it means twice the effort is involved in doing "mind-shifting" work such as allowing WP7 apps to work on a PC, such as (for example) "expanding" the panorama view so all tiles are simultaneously visible. I believe this is the sort of thing Apple might do if they made a platform like this (using their ObjC-based frames throughout, no doubt) but thanks for the Silverlight lock-in (or rather, lock-out from system-provided services) you'll see that things really are constrained when it comes to ensuring applications can take full advantage of future runtime environments.

What are you talking about?

Then there'll be apps written for the higher resolutions... just like iPad versions of said iPhone apps?

Honestly... I've already figure out Jupiter... Ask me if you have questions

http://betanews.com/2011/09/01/windows-8-has-a-split-personality/

6 hours ago,CKurt wrote

@W3bbo: You are saying Silverlight is not implemented in the OS be default? I'm pretty sure it will be in Windows 8 so your point is not completely valid.

He might be bringing up possible lawsuit stuff. I'd guarantee that if Silverlight is installed by default on Windows 8 that Adobe Air is as well.

7 hours ago,CKurt wrote

@W3bbo: You are saying Silverlight is not implemented in the OS be default? I'm pretty sure it will be in Windows 8 so your point is not completely valid.

No

I'm saying:

• Right now, Windows Phone 7 comes with "native" widgets and controls and frameworks for user-interface development. These are used by some (if not all?) of the native applications that come on the system, such as the Settings area.
  • This includes the "panorama" control, swipe/slide controls, and a few others.
• Windows Phone 7 applications, on the other hand, have to use controls and widgets developed entirely in/on Silverlight. Silverlight does not provide a thin managed wrapper around the native panorama/etc controls, instead they're entirely re-implemented.
• As a consequence, if Microsoft wants to make WP7 applications run on desktop Windows in some "enhanced" mode where a panorama view is expanded to show all the areas they would probably make a start by modifying the behaviour of the native controls, but they would alsohave to update how the Silverlight controls work, but this then doubles the amount of work required, as a probable consequence Microsoft will not do this.
  • Therefore if WP7 applications will be enabled to work on desktop Windows, it will be such that they appear as they do in the device emulator (just with a prettier display border). Do not expect anything mind-bend-y.
  • Case in point: early on in WP7's life Microsoft didn't implement the "push" state effect on various Silverlight controls. Developers were annoyed they had to re-implement something that the system should provide itself; many developers did, but couldn't get the effect to look right. Microsoft is free to parameterise the native push effect and make it more prettier in the next release of WP7, but because the Silverlight versions re-implemented it themselves they're stuck with the old look.
• TL;DR: By making the Silverlight stack use its own re-implementation of controls on WP7 Microsoft hasdoubled the amount of effort involved in making changes to the platform, this will stifle innovation.

The main reason they have the difference in 'native' controls and 'SilverLight' controls on WP7 is because the OS itself and the DEV tools were developed at the same point in time (because if the tight schedule).

There would be no reason for updating the 'native' controls, why not just only update the SilverLight controls? The only thing they then have to do is reduce the usage of native controls in WP7 and start using the SilverLight ones by default when adding new features to the OS. And I'm thinking they are already doing that.

Running WP7 applications on Windows 8 would only be a matter of running SilverLight on Windows 8 and interpreting the XAML in a different way if the screen resolution is different (large windows screen). [It might need to be duplicated or recompiled but I'm taking the optimistic side here]

Running WP7 native hubs/applications on Windows 8 would be harder, but also less appealing to the dev audience and less needed as long as they provide a good way to port SilverLight based applications to Windows 8 (and Xbox360)

23 hours ago,Bas wrote

Even if you sort of scale up the panoramas and such, all the assets like icons and such would be super low res. It would never work. I could imagine that in future you could write an app that runs both on Windows Phone and Windows 8 (provide high-res assets and they'll get scaled down when compiled for the phone or something), but existing apps? No way.

The main problem is that most assets intended for a phone would look too huge when viewed on a desktop, even when viewed without scaling. A finger-friendly graphical button for a phone is typically like 80 x 80 pixels. A standard toolbar button in a Windows desktop application is only 22 x 22 pixels. If you run an application on smaller notebook or tablet, a button that's as small as 50 x 50 pixels might be optimal for finger-friendliness.

IMO, the resolution of the assets, per se, is not the problem. It's the size of the controls relative to the screen size that's the problem. 

1 hour ago,cbae wrote

The main problem is that most assets intended for a phone would look too huge when viewed on a desktop, even when viewed without scaling. A finger-friendly graphical button for a phone is typically like 80 x 80 pixels. A standard toolbar button in a Windows desktop application is only 22 x 22 pixels. If you run an application on smaller notebook or tablet, a button that's as small as 50 x 50 pixels might be optimal for finger-friendliness.

Don't worry, Apple is solving this problem for us by introducing double-dpi displays across their whole Mac range within the next few years.

Us on Windows will be stuck at 96dpi for the foreseeable future.

1 hour ago,W3bbo wrote

*snip*

Don't worry, Apple is solving this problem for us by introducing double-dpi displays across their whole Mac range within the next few years.

Us on Windows will be stuck at 96dpi for the foreseeable future.

I'm not sure how this matters. An 80 x 80 pixel button takes up 10% of the horizontal dimension on an 800 x 480 pixel display. Let's say Windows is able to support a crazy 8000 x 4800 pixel screen. That 80 x 80 pixel button would then magically scale to an 800 x 800 pixel button. That's still 0% of the horizontal dimension. How does this solve the problem that I mentioned?

1 hour ago,Bas wrote

@cbae: that's something you could fix programmatically, though. Detect the screen size (and the type of device) and let the UI framework resize stuff automatically.

But whatever scaling that needs to happen can't be proportional. You need the window frame to scale to a larger size (i.e. to 1920 x 1080 or whatever), but you want the images to scale DOWN (i.e. to 50 x 50 pixels or whatever). This is not a trivial thing to solve, and it certainly isn't going to be solved by magically increasing the PPI of the display. 

6 minutes ago,cbae wrote

*snip*

I'm not sure how this matters. An 80 x 80 pixel button takes up 10% of the horizontal dimension on an 800 x 480 pixel display. Let's say Windows is able to support a crazy 8000 x 4800 pixel screen. That 80 x 80 pixel button would then magically scale to an 800 x 800 pixel button. That's still 0% of the horizontal dimension. How does this solve the problem that I mentioned?

I don't understand the problem you're positing exists. WP7 apps run fine in the device emulator, and I imagine you could engineer it so WP7 apps could be ran at arbitrary resolutions since everything's done in Silverlight anyway.

4 minutes ago,W3bbo wrote

*snip*

I don't understand the problem you're positing exists. WP7 apps run fine in the device emulator, and I imagine you could engineer it so WP7 apps could be ran at arbitrary resolutions since everything's done in Silverlight anyway.

It's not an issue of whether or not the app will run fine. It's an issue of whether or not you're maximizing the use of the available screen real estate provided by the OS. If your app is designed to be finger-friendly on a 4" screen, then all the graphical controls are going to look huge if you scaled it to a 24" flat panel, a 17" notebook, or even a 10" tablet.

The only reason you don't have problems with all the varying sizes of smartphone displays is because there's really not much difference between a 3.5" display and a 4.3" display.

Text also should be set to an absolute size, but the size would need to change according to the type of display you're using. You hold a smartphone closer to your face, so the standard font size could be small. A tablet is held a little farther from your face, so the standard font size for a tablet needs to be slightly larger. A notebook or desktop display is generally positioned farther still, so the text needs to be larger than on a tablet. Because the standard font size is set to an absolute unit of measure, text will be the same size across all displays of the same type. However, if you have a 10" tablet, a single character that's rendered on the screen will take up a larger percentage of the screen real estate than it would on a tablet with a display that's, say, 12".

What would be neat (and I suspect part of the deliverable for WIN8) is a UI that allows us to bring in live tiles from different WP7 Apps onto the main surface simultaneously with tiles from other environments (HTML5/WPF/Jupiter or whatever).  I like the sound of that and it goes some way towards a kind of 'super - exhibition' mode that I mentioned elsewhere.

I probably need a 45 inchs HDTV for my current Windows to have the OK OK font size and button size. But, the problem is my neck would hurt if I use HDTV on my desk. I am currently using 125% DPI, mainly because some apps break horribly because they are not WPF apps. 125% is at least manageable when the apps break. Also because I need lower DPI like 125% for coding. Otherwise I would want 200% DPI myself.

Yeah, is this absurd? Who cares about my old grandpa vision? Sure it is just one grandpa's opinion, but, it is an opinion nevertheless.

Herbie

22 hours ago,Harlequin wrote

*snip*

He might be bringing up possible lawsuit stuff. I'd guarantee that if Silverlight is installed by default on Windows 8 that Adobe Air is as well.

This is the hottest battle right now. Silverlight vs Adobe Air. 

1 minute ago,fanbaby wrote

*snip*

This is the hottest battle right now. Silverlight vs Adobe Air. 

Blech, Air pisses me off. The other day I made the mistake of accessing help from Illustrator instead of going online. It did three updates before it would let me do anything, and the font rendering is as bad as anything Silverlight or WPF have ever had. Plus, it was slow and glitchy. Overall, a wonderful showcase.

Safari does not compare to IE9 when you zoom in, and I really am at a loss why it Apple products are so so overrated. I did try the New York Times app a while ago, and the Air version was better than the WPF version but WPF 3 was still rudimentary.

3 hours ago,Dr Herbie wrote

Unless, of course, Microsoft find a way to edge towards HTML5 development for WP7 because then you could unify desktop to phone from the HTML side ...

So HP was right about webOS then?

8 hours ago,CKurt wrote

@magicalclick: Or you can change the text size setting in Windows and stuff will look huge on any display. (not just text but all windows/icons) Just search for Text in Windows start menu.

that's why I have 125% DPI.

Like I said, some apps breaks, thus, I didn't do 150% DPI or actually I want 200% DPI. Apps that breaks horribly = VS2008. The intelsense is completely screwed up and the property windows are gigantic to become useless. VS2010 finally fixed it though.

5 minutes ago,Bass wrote

Since Windows 8 applications will be written in HTML5 and JavaScript, they should run on phones as well. This really shouldn't be surprising to anyone.

Really? Do you know something we don't?

7 minutes ago,Bass wrote

Since Windows 8 applications will be written in HTML5 and JavaScript, they should run on phones as well. This really shouldn't be surprising to anyone.

yeah.... how many will that be?

how many iphone apps today that are popular are html based? some are but how many are native apps?  i bet it's like 75% native or more... just a guess i admit but i bet it's at least that.

Actually I don't know. The title says Win8 runs WinPh7, not the other way around.

Going offtopic:

As far as I can tell, there will be extra security on the WinPh7 IE that some things would not work as expected.