[Cross-posted from blog.davemdavis.net]
There have been lots of changes with Windows of the past few years. A while back, Microsoft radically changed the way Windows worked with Windows 8. The goal was to start to converge the different operating systems into a single core. Windows 10 is the culmination of that convergence which started out as “Three Screens and a Cloud” and now includes many more screens.
The road to convergence is a difference story. Here, I want to talk about the user experience. While all this was going on, there was a revolution in the experiences that users expected. No longer are battleship gray user interfaces acceptable. Neither are shrunk down versions of these interfaces acceptable on mobile devices. As a developer, you need to design and build your applications for the form factors that you are targeting. Here is where we pick up that journey on the Microsoft stack.
In Windows 8, there were two environments: a desktop environment and a tablet environment. With the tablet environment, they introduced a new programming language, WinRT. Those tablet apps, sometimes referred to as “Metro” apps, could be running in one of four states: Filled, Full, Snap and Portrait. There was a neat little enum that helped support these states. One of the mantras was good design. Your app should look good and respond well/do the right thing in any of those states. To assist developers, the Visual Studio template for those projects included a LayoutAwarePage that assisted in handling the transition between states. I wrote a blog about it: What is This ‘LayoutAwarePage’ You Speak Of.
Along comes Windows 8.1. That enum goes away and so does your LayoutAwarePage. In 8.1, apps could be resized horizontally independent of those defined states. There was another wrench thrown into the mix: the phone. With this release, WinRT apps can be developed for the phone. The templates changed to include a new Universal App template. There was guidance from Microsoft that you should target both table and phone but no tool build in the framework to help. At Build 2014, there was a pretty good session on how to target screens of any size, From 4 to 40 inches: Developing Windows Applications across Multiple Form Factors. During this session, Peter Torr showed the science of view items on different size screens. He also showed a potential solution to the lack of built-in tooling. Since I wrote about the LayoutAwarePage in 8, I figured I had better write a post about where layout in went in 8.1: What Happened to My LayoutAwarePage?.
In Windows 10, Microsoft wants to target a larger array of device, including some that don’t even have screens. In the image below, there are a plethora of platforms that your apps can run on. The convergence allows you to write code that runs on all these devices, but does that mean I have to write a separate UI for all these devices?
The answer is no. Taking a page from web design, the new guidance is to build adaptive interfaces. Keep in mind that the experience should be tailored for each specific form factor. Recently, a preview of the SDK for Windows 1o was released along with a Microsoft Virtual Academy training course. Module 9 caught my attention because it talks about building adaptive UI and it looks very similar to the solution that Peter Torr came up with for 8.1. In Windows 10, you can truly build one app (one app package) that will run on any Windows 10 device. There is some neat magic behind the sense that allows this to happen and if you are interested in that you should watch the other modules in the course. To support writing a single Xaml file that runs across devices, Microsoft has revamped Visual State Manager to assist with building adaptive UI. I highly recommend that you take a look at that module if you are interested in the story.
I am sure that more details will come during Build 2015 (April 28-May 1) so keep an eye out for what coming down the pike. Keep in mind that everything is in preview right now so things may change between now and release but this looks promising.