Resizing Matters: Reflections on Windows 10 (Technical Preview)


Windows 10 Technical Preview

Windows 10 Technical Preview has just been released and the biggest news is not only has the Start Screen been killed off (or rather hit with a shrinking ray and in limpet fashion been adjoined to the Start Menu), but also that Windows Store Apps now exist inside resizable windows like any other. Gone is the snapping that we all had to learn for using multiple windows at once.

Of course this is the very earliest release and things might be put back or changed further. What we're seeing is not the final version that will ship. Far from it. Still it does provide us with an insight into how all this customer-driven change will have an effect on future app development for Windows and no doubt other platforms too.  

The problem

We've been resizing windows on desktops for decades, so what's the problem? Why do we have to make such a big deal about how modern apps adapt to different screen sizes? Well here's the thing, most apps designed for tablets don't have for one thing internal frames that can be resized (like regular desktop apps), so when we start to adjust the external frame size it is down to the app itself to decide how content is adjusted. So the experience becomes very much like that of a website when the browser window changes in size. And it's very difficult (let's say impossible) to force the user to do anything when it comes to the size of the browser window (yes, even for you JavaScript gurus!).

Unfortunately, the current situation with the (preinstalled) Windows Store Apps running in Windows 10 is that when they are not in full-screen mode some behave just like a website with a fixed width rather than a reflowable or adaptive layout. But this isn’t the only issue, desktop UIs are typically based around apps that contain vertically scrolling content, whereas Windows Store Apps commonly employ horizontal scrolling.

Current fixes

It is clear that Microsoft have thought about the issue of resizing to a certain extent, because the absolute smallest size that a Windows Store App can be shrunk to is much larger than, for example, a File Explorer or Internet Explorer window. But the problem is that some apps handle small windows sizes more elegantly than others.

This is not to write that when File Explorer is shrunk to its smallest size that it remains usable. This is not the case at all, we've just become used to the ability to do things we would never want to employ. I would note, however, that it's possible to shrink File Explorer to half the size of the Windows App Store minimum size and still have a functional experience, because it employs vertically scrolling columns and has further optimisations that can be made such as removing some of the detail columns manually to reduce the need for horizontal scrolling.

The solution

So the solution must be to return to internal adjustable frames for apps, right? Well no, this is a rather bad and inefficient solution that we've been coping with and have just got used to. Adjusting internal frames, we discover the optimum size ratios that we prefer so that content doesn't look too cramped but really there could be algorithms doing this work for the user. Not only so that the user doesn't waste time. But also so that for smaller screen sizes the adjustment is more than just a resizing. Similar to when a website displayed on a small screen snaps into a mobile layout.

And besides adjustable frames won't be as effective in resolving the problem of horizontal scrolling content. But notice how I keep mentioning the web. This is because it is a problem that has existed for website builders since browsers began or at least since things started to be arranged graphically on the web. So web builders are actually rather good at adaptive layout and it is the experiences of the web that programmers must now turn to in order to rebuild apps for this new age of resizable apps.

Where to start

As a starting point in this research, we might look to a site like Smashing Magazine, shrinking it to its smallest size and then stretching it to its fullest in a browser window. Watch as you do so how the positioning of content and menus changes and how detail reduces and expands. This is a site that clearly employs the strategies that it discusses in an extensive way.

If we simply ignore the possibilities and let device sizes grow without adaptive layout (or fluid layout, or whatever we want to call it), then we're going to see a lot of empty space on our ever growing phones and tablets.

Mac and iOS

Resizing isn't a Windows-only issue, the sizes of iOS devices are becoming more various and if an iPad Pro (or Plus) really is in the works then it's possible that more than one app might be displayed at one time. And we don't yet know whether we'll be employing snap resizing or free resizing in iOS (if any resizing at all happens!).

What we do know is that iOS 8 deprecates the old rotation methods present in earlier versions and simply provides information about size changes to the app upon which to act. And this suggests that things might not all remain as they have been before. While further clues include:
  1. inside Xcode you'll find not only iOS Simulator options for testing all the "current" iOS devices but there are Resizable iPad and Resizable iPhone options as well
  2. in iOS we now have the ability to set a preferred primary column width in a UISplitViewController giving greater flexibility for relative width adjustments 
So change we presume is afoot in the iOS camp, even if it happens at a different rate to that which we find in Windows 10. And already we've seen the iPhone 6 Plus adopt the UISplitViewController of the iPad in apps like Mail.

Endorse on Coderwall

Comments

Post a Comment