Windows 10 apps to rule them all – phones, slabs and PCs: Microsoft pulls out 'universal' tool

Microsoft has released technology previews of new developer tools and an SDK for Windows 10, giving coders their first taste of what it's like to build Windows Universal Apps that run across PCs, phones, and tablets. The tools are available now at no charge to members of Microsoft's Windows Insider program. Like Windows 10 …

[James Anderson]

The folly of a single user interface

Image if Honda decided to make there customers like easier by have a single user interface for all thier products.

Maybe they would put a steering wheel and gear lever on the motor cycles.

Or perhaps a handbrake on the jetskis.

Or maybe do the microsoft thing and have a completely new interface for everything. Something intuitive like a tiller to steer with and an anchor to throw overboard when you want to stop.

[WP7Mango]

The folly of a single user interface

There isn't ONE interface. Each device type has a different user interface, optimised for that form factor.

Therefore, no "folly" as you put it.

[big_D]

Re: The folly of a single user interface

@WP7Mango agreed (and there is a username that brings back memories). The "one Windows" is the underlying core being brought closer together. The interface will still be optimized for the form factor in question.

[Kristian Walsh]

Re: The folly of a single user interface

"Responsive UI" is just the same principle as "Responsive Web" - the top level container controls in your layout respond to the screen dimensions and lay their content out differently, so that the same "markup" produces a different UI (This already happens in Windows Phone versus "Metro" to a limited extent - "Hub" controls fit one column per screen on phone, but on tablet they're shown as a free-form multi-column layout).

Right now, you need to maintain separate layouts for Tablet and Phone, but with smarter container controls, it might be possible to use the same UI file. Personally, I think that'll only go as far as "get it to run" - for proper UI, you will always have to tweak each device's UI, but hopefully the bulk of the layouts will remain the same. As it is,the code that handles your app UI interaction (the ModelView) remains constant across all layouts (and all platforms, if you've thought ahead).

The other visual problem is of scale: put a touch app directly onto desktop and you'll see that every control is about double the height that it needs to be. However, "Metro"/"Phone" apps use a scaled co-ordinate system, so there is some scope for changing that scaling factor depending on whether you're using mouse or touch. Fix that, and they become fairly well navigable with mouse and scroll-wheel.

The devil, however, is in the details.

[Kristian Walsh]

Re: The folly of a single user interface

(I meant "the ViewModel", of course. Great idea, confusing name... )

[Paul Shirley]

Re: "The devil, however, is in the details."

Indeed. It's an ancient idea that dates right back to the first GUI's and I can't remember any layout manager that does does it particularly well without some programmed assistance.

Even if the MS effort works better than anything before it, they'll inevitably bind in the the look&feel choices their designers want to inflict on us. We could easily end up with apps that look equally ugly on all formats - great auto-layout but still the wrong result!

I doubt the days of supplying multiple layout files to help nudge layout in the right direction for formats are over, even with the woefully dull 'Modern' look&feel.

[G R Goslin]

Jack of all trades....

....and master of none, comes to mind. On past record, it might wll be true

[Anonymous Coward]

API Contract is not just feature availability

API Contract if it is a real "API Contract", not a marketing one is not just feature presence. It is availability as in "present and allowed as authorized".

If MSFT has finally gotten its act together to do a decent authorized (f.e. oAuth) API contract across all of its OS this will put it ahead of Android and maybe even a bit ahead of Apple. Android does not have true API contracts - you are either allowed a set of features as in the app manifest or not. You cannot "haggle it down". Apple is a bit better - you an actually whack a particular API on the head even if the app is trying to ask for it without killing the app altogether.

[Paul Shirley]

Re: API Contract is not just feature availability

I didn't read anything suggesting this is more than feature query support in the article.

Android supports runtime permission and api presence checks. The problem is few programmers use them or deal with unexpected errors gracefully, I cant see them doing any different on Windows. Unless 'API Contract' involves the user and becomes widespread in practice we'll continue assuming the permissions we asked for are what we have. It's a compatibility wrecking change - again, don't see any suggestion of that in the article. Be nice to have as a user but lazy programmers (or plain malicious ones) will carry on ignoring it.

Or maybe all it means is, when I call an API and it doesn't instantly crash, the call actually worked? Unlike the empty stub functions Microsoft so loved inserting without warning in my past encounters with Windows programming ;)

[dogged]

.Net projects written in [...] JavaScript

wait, what?

[TheVogon]

".Net projects written in [...] JavaScript

wait, what?"

.Net supports multiple languages: http://en.wikipedia.org/wiki/Category:.NET_programming_languages

[Mike Dimmick]

JScript.NET has existed since .NET 1.0 was released in 2002. However, it hasn't been tracking ECMAScript releases, being approximately based on ES3.

I can't see anything saying that the recommended way to use JavaScript to write Windows Store apps - using WinJS - has changed at all. That will continue to use the Chakra engine and presumably the new EdgeHTML rendering engine from Spartan, once you change your manifest to Windows 10. I'd expect Windows 8 and 8.1 Store apps to continue using the older MSHTML in Edge mode.

[dogged]

> JScript.NET has existed since .NET 1.0 was released in 2002. However, it hasn't been tracking ECMAScript releases, being approximately based on ES3.

I don't think I've even seen JScript.NET installed since about 2003. I honestly thought it was dead.

[Anonymous Coward]

"I don't think I've even seen JScript.NET installed since about 2003."

It's installed as part of the .Net runtime, so pretty much every Windows PC has it.

[dogged]

That makes no sense whatsoever, AC. The compiler is installed sure but it's not been a part of any VS install I've used in years. And the runtime only deals with intermediate language.

[Anonymous Coward]

"The compiler is installed sure but it's not been a part of any VS install I've used in years"

It's part of all .Net SDK / Visual Studio installs.

[Anonymous Coward]

Visual Basic isn't totally out of the equation, long term

The .NET Native FAQ (https://msdn.microsoft.com/en-US/vstudio/dn642499.aspx) says

"Will F# or VB or my favorite language be supported?

This preview release supports only C# code because it’s the .NET language used by most Store apps. But nothing prevents us from supporting any .NET language when we broaden our focus."

[Ken Hagan]

Re: Visual Basic isn't totally out of the equation, long term

This is very puzzling. The link you mentioned strongly suggests that the .NET Native compiler goes to work on the MSIL. Since that is the common intermediate representation shared by all .NET languages, it really shouldn't be limited to C# code.

In short, how the hell have MS managed *not* to be able to handle all the .NET languages?

[bearded beercan]

Not bad

Not bad at all. If only the world would switch to windows phones

[Anonymous Coward]

The last time that Microsoft pulled out a 'universal' tool was when they ejected Steve Ballmer.

Hopefully this tool will prove more useful.