One of the things that I find most exciting (and perhaps challenging) with Windows 8+ is that it runs on such a staggering array of devices.

The most recent “PC” I’ve bought is the Dell Venue 8 Pro;

This is an 8” tablet running on Intel’s Atom (quad-core) processor running full Windows 8.1 with 2GB of RAM and a 1280×800 touch screen with 10 points of touch.

Having Windows 8.1 as the OS means that the device should run whatever Windows software I want to throw at it ( subject, naturally, to it being a relatively low spec’d device ) and it should also connect to whatever Windows hardware I want to link it to ( subject to the device having the right kind of port/connector ).

It’s a tiny tablet. It’s a full PC. It’s both. It’s neither. It’s a chameleon. Who knows what it is?

I think it’s fair to say that most Windows “desktop” software wasn’t designed for this type of device. A lot of “desktop” software tends to assume things like;

• mouse/keyboard input which is definitely a use case for a device like this but I bet most of the time these devices will be used in a “touch only” manner
• the power socket is not too far away so power consumption isn’t a top priority
• the user will sign up to installing a software which may compromise the stability of their system in the future

So, while desktop software is definitely going to run on this device it’s perhaps not going to be what I’d generally use it for. That’s not to say it’s not valuable to have that possibility for scenarios where I have this device to hand want to (e.g.) write a quick blog post with Windows Live Writer so I might connect to an external monitor, add a bluetooth keyboard and get something done.

On this particular form factor though I think I’m more likely to spend most time running Windows Store apps that have been designed to cope with;

• touch-based user interface that also supports mouse, keyboard, pen as and when those devices are available
• conserving the user’s battery while remaining “alive” through use of various platform provided notification mechanisms
• easy and non-intrusive application install and uninstall
• easy access to data whether stored locally or in the cloud and roaming of user’s state via the cloud to support the app across a user’s devices
• variations in the characteristics of the display technology from small tablet to huge all in one

apps like Flipboard, Bing News and so on;

I don’t only run those apps on this small device though. I also run them on my Surface RT (this one below isn’t mine but you get the idea);

and I run them on my laptop which is currently a Dell XPS 12 as below (again, that one isn’t mine) and those screenshots of the 2 apps above actually came from this laptop;

 

 

and, if the budget ever allows me to buy one, I might one day run them on a big all-in-one machine like this Lenovo below;

and I expect that these apps will “just work” and, specifically, I expect that they will do something sensible in terms of responding to the available display technology.

This isn’t very different from what happens on the web under the banner of “responsive web design” and I guess the right name for it here might be “responsive app design”. I don’t think that’s a new term -  I think that it’s something that the Android community (with their diversity of devices) have been dealing with for quite some time ( I came upon this post as a great example of that kind of thinking ).

This same idea shows up for Windows Store apps that need to be designed to deal with extra screen space.

Rather than expecting a designer/developer to go out and buy lots of different devices, both Visual Studio and the design tool Blend have features to try and help with designing a responsive app and one of those tools would be the simulator that, amongst other features, lets you run and debug your app on different display sizes and resolutions.

Here’s the simulator showing what it’s like to browse a particular website on a 27” monitor running at 2560×1440 with IE11;

i.e. it’s not a very responsive site when run at that kind of resolution. Moving away from a web site, I can change my simulated screen size to be a 10.6” screen at 1366×768;

and running the Bing Travel app shows me;

what’s interesting about this is that if I go and choose a 10.6” screen running at 2560×1440 resolution and navigate to the same part of that travel app;

then I don’t see any difference. There’s nothing “responsive” going on here. The clue as to why this happens is hinted at in the menu that I used to change the simulated resolution;

each of those resolutions have a little percentage after them stating to what extent Windows is going to scale the app’s UI.

For a 10.6” 1366×768 screen, Windows does not scale the UI but for a 10.6” 2560×1440 screen Windows scales the UI to 180% of its original sizes which means that the app is going to “think” that it is running on a screen that’s approx 1400×800 pixels here and hence it has little to do in the way of being “responsive” and changing what it displays.

If I choose a simulated screen which is scaled at 100% and has more pixels than the original 1366×768 like the 27” screen at 2560×1440 then I see the travel app behave in a different way – it responds;

I get a lot more content on the screen – clearly the whole UI is prepared to stretch itself and the 4 “Tools/Tasks” are anchored to the top left in their layout and then the 2 grids of “Trip Ideas” and “Local Destinations” must have layout that allows them to vertically stretch to near the boundaries of their container which allows them to display a larger number of items.

This also comes into play when a user resizes an application on screen in order to display multiple apps. For example, if I take an application like the ‘Fresh Paint’ app and run it up on that monitor at 2560×1440;

then as I scale it down to half-screen size then it scales;

and at a really small size I think it gives up the ghost on being able to actually paint anything and displays different UI;

 

In terms of how a designer/developer handles this sort of layout in their app there’s a few approaches stretching from the;

• manual – write code that waits for resize events and then show/hide/resize everything yourself

approach which I couldn’t really recommend through to the;

• automatic – just scale everything up to fill the space

which I wouldn’t usually recommend other than it does work well for certain types of content (e.g. games might do some of this) through to the;

• automatic – use the UI framework that you’re working with to make things easier

The main UI frameworks for apps in Windows 8/8.1 are the XAML framework and the HTML/CSS framework and so it’s interesting that if you were working in HTML/CSS then you would be using the same techniques to handle “responsive app design” on Windows 8.1 as you would be using on the web to handle “responsive web design”.

If you’re in the XAML world then you’d be using techniques like visual states and animations to declaratively show/hide/move/resize UI elements (typically by repositioning items in various rows/columns of grids).

But it’s an aspect of design/development that spans across the web, Android devices and Windows devices – how to make the best use of the screen space that you’ve got on the device in a productive way both for the developer and for the user.