Taking the Responsive Web to Windows 8... and 8.1
We made mistakes.
Microsoft had a key recommendation early on to support these multiple “view state” scenarios: Take a more “adaptive” approach where you target the four view states specifically using media queries with four specific -ms-view-state values (fullscreen-landscape, fullscreen-portrait, filled, snapped). Snapped view was always 320px wide. Filled was always the device width minus 320px. Portrait was always fullscreen. Landscape was also fullscreen horizontally. While we all felt (on the client project) that a more responsive approach was better and future friendly, based on Microsoft’s recommendation + an aggressive timeline + little documentation and community to find support at the time we decided to take this differing approach.
Enter Windows 8.1
This favorite side-by-side approach for apps in Windows 8 received an important advancement in Windows 8.1, one that fits in much better with 2013. Snapped view is no longer a guaranteed 320px. When you launch apps side by side they are by default each 50% width. Launch another and they fit into thirds. Want to make one slightly bigger? drag it and it is done. The world of four fixed states is gone, and an app can fit any number of widths and heights. Great for the user? Definitely. Great for the developer stuck in self-described 2010-fixed-width glory? Not at all. Great for developers excited about the real world where devices range from tiny to huge, and everything between and beyond? Yes.
Specific Changes in Windows 8.1
Most of these changes are highlighted in Microsoft’s documentation.
First of all, the four specific view states in media queries are deprecated. Snap view even has a new minimum width of 500px (though you are able in your app’s manifest to change it to 320px if desired). So they will continue to work today, but may not work in the way you expect if you target your app to the 8.1 SDK. Instead, use the more common media queries for min- and max-width (and the same for height).
There is no more unsnapping. Well… at least it, too, has been deprecated. We used this one a few times in our client app. Click on an item while in snap view and the app will, as expected, try to make your app be the on in the filled state, and shrink the other to snap view. It worked well, but Microsoft clearly wants your app to work regardless the width/height to which it is constrained. Reasonable.
Our New Approach
Do it right. Use relational units. Minimize our use of WinJS-y methods when there is a standard web alternative (unless there is a performance gain, etc.).
Also, with the old four view states, the thinking was often keep portrait, landscape, and filled relatively the same (scrolling horizontally as all good Windows 8 apps should), but make the snap view flow vertically (as the best Windows 8 apps did). With the increased minimum width, the vertical flow does not make as much sense always. So we are experimenting with always scrolling horizontally, adjusting list styles/sizes, and placement of flyouts, etc. Only time (and users) will tell what approach makes the most sense on this new platform.
The one thing we know for sure is that this approach for Windows 8.1 is a welcome change (even if we have to rework based on the original Windows 8 implementation/recommendation). It’s a step in the right direction.