Hi and welcome to the fourth part in this series on new features in Windows 8.1. So far, we’ve covered the new OS from the user’s point of view, some of the new XAML features, some interesting WinRT classes. In this part, we’ll cover some novelties in the user experience like the new screen sizes and the new options for working with tiles.
New Window sizes
In Windows 8, apps could basically run in 3 modes. By default, an application was running full-screen. However, Windows 8 wasn’t limited to running just one app at any given point like for example iOS. With SnapView, an app could run in a so-called “snap view”, basically a narrow view of 320 px (x the scale factor if any) that is either docked on the left or the right of the screen. The second app running at this point was then in filled mode. So in total, apps could either be in full, filled or snapped mode. When publishing an app to the store, one of the requirements was making sure that your app would run perfectly in these 3 modes. It wasn’t allowed to omit adding the snap view: if running in snapped mode didn’t make sense for your scenario, you still had to include it and perhaps show an image or some text asking the user to run the app in full-screen mode.
While this was OK, it was still somewhat limiting. That’s probably what Microsoft also thought and so with Windows 8.1, they’ve completely changed the way this works. We now basically can run more apps and they can run in all kinds of screen sizes. Also, the snap mode concept has now become optional, but more on that later.
As you can see from the screenshot below, we can run 3 apps on one screen, where one of the 3 is running in snapped mode.
Or we can run 10 apps, spread over 3 screens. I’m not sure this is a very useful setup but it proves the point that we can run up to 4 apps on one screen. The number of apps you can run on your screen depends on the screen resolution and the physical size of the monitor.
The requirements that you need to follow when building an app have thus also changed. Your app needs to offer the full experience, anywhere from 500px upwards. That means that your app can focus on that 500px being the minimum resolution but it has to make sure that the user can get the full experience at this resolution. The latter is important and is also a change with what we had with snap view. In snapped mode, the app had to give the user a vertical scroll experience, since the 320px-wide window was too narrow to do horizontal scrolling. Now, we can use a horizontal scrolling experience without problems: 500px is wide enough for this, the user won’t accidentally drag the resize-gutter.
So how does this translate into your app then? Well, that depends a bit on the scenario. If you have a “regular” horizontal scrolling app, you probably don’t have to do anything special. Just test that your app looks good at a width of 500px should be enough. In the screenshot below, you can see the Bing Travel app, which is running in the new minimum width of 500px. It simply offers the same experience as in full screen.
If the app is a multi-column app, one option you have is hiding columns when you have less available space. The Mail app does this, as you can see on the screenshot below. Notice the arrow at the top, which will unhide other colums.
If your app is a fixed-size app, you can make it smaller, keeping the aspect ratio in place, as shown below.
Let’s now take a look at how all this works from Visual Studio. For this demo, I’m going to start by using Visual Studio 2012 (the “old” version!) and simply create a new Grid-based application. This template includes a SnapView mode by default.
When we simply build and run this app on Windows 8.1 (which doesn’t have snap mode built-in by default), the application will run in some kind of compatibility mode, known as pillarboxing. Note in the screenshot below that the snap view still works. Any resolution between 320px and 500px is however now supported, but the snap view sits in the middle of 2 black pillars, hence the name pillarboxing.
When we now open this same project in Visual Studio 2013, we can retarget the app to become a Windows 8.1 app. Simply open the solution and from the Solution Explorer, select Retarget to Windows 8.1.
When we now run the app again (as a Windows 8.1 app), the app doesn’t support snap view anymore: the narrowest we can make it is now 500px, as shown below.
If we have a valid reason to continue supporting snap view even in Windows 8.1, we still can. However, we need to do this explicitly. Several scenarios come to mind where this is indeed still useful, including a monitoring app, a Twitter app or a video player app that wants to allow the user to use a smaller window to continue watching video.
To do so, go to the application manifest and in there, set the value for minimum width from there.
If we now select 320px and then run the app again, we get the following result. As you can see, the app now supports any width from 320px upwards. Between 320px and 500px, we see the snap view but this isn’t running in the pillarboxing mode any longer: the snap view window now gets all the available space on the screen.
Some of the code related to managing the views, is deprecated. Assume in your Windows 8 code, you’ll have code that checks which is the current application state (FullScreen, Snapped, Filled) so that based on this value, you can use the VisualStateManager to go to a particular state. If we run this code in Visual Studio 2013, we can see that this code is now deprecated, as shown below.
So instead of checking in which state we are, we’ll need to work with numeric values that indicate the current width of the screen. Some code for this is shown next.
Also, the commonly used TryUnsnap() method is deprecated in Windows 8.1, quite logical since snapping isn’t supported as a default feature anymore.
The new Search experience
Another area where some the user experience has changed quite a lot in Windows 8.1, is Search. Previously, searching in an app had to be done by using the Search contract. The Search contract was accessible through the Search charm in the Charms bar. With the Search contract, it was also possible to search within apps: apps could register for the contract and in turn, Windows placed the apps in a list that users could select as the target for their searches.
One problem that arose with this approach to searching is that many people had problems locating the Search option within an app (and perhaps left the app, frustrated they couldn’t search it…). In Windows 8.1, Microsoft has changed Search by making it available through a control instead: the SearchBox control. The control lives in the Windows.UI.Xaml.Controls namespace, just like many other controls. In the screenshow below, you can see the control in action.
As you can probably get from the screenshot, the user experience we’re getting from the control is pretty similar to what we had before in the Search pane, but now integrated in the app’s UI. And that would be a correct assumption: the control offers search suggestions and search recommendations in much the same way as before.
Code-wise, things haven’t changed a lot either: the control supports the same events and search mechanisms as well. Let’s take a look at some sample code.
The control can be added just like any other control in XAML.
1: <SearchBox Name="MainSearchBox" QuerySubmitted="MainSearchBox_QuerySubmitted"
2: SuggestionsRequested="MainSearchBox_SuggestionsRequested" Width="200"
3: HorizontalAlignment="Center"></SearchBox>
In code, we can now handle what needs to happen when the user types (give suggestions) and when he hits Enter (query is being submitted). In the code below, we can see that the entered query arrives in code via the SearchBoxQuerySubmittedEventArgs.
1: private void MainSearchBox_QuerySubmitted(SearchBox sender,
2: SearchBoxQuerySubmittedEventArgs args)
3: {
4: QueryTextBlock.Text = "You searched for " + args.QueryText;
5: }
When we start typing, we want to show a list of suggestions. In the event handler, we’re getting in an instance of SearchBoxSuggeestionsRequestedEventArgs. This contains the current value in the SearchBox (QueryText) as well as the SearchSuggestionCollection (through the Request property). Using these two, we can get a list of suggestions and add these to the SearchSuggestionCollection. Note that the limitation of 5 items we had in Windows 8 is gone in Windows 8.1 for the SearchBox control.
1: private void MainSearchBox_SuggestionsRequested(SearchBox sender, SearchBoxSuggestionsRequestedEventArgs args)
2: {
3: string queryText = args.QueryText;
4: SearchSuggestionCollection suggestionCollection = args.Request.SearchSuggestionCollection;
5: foreach (string suggestion in cities)
6: {
7: if (suggestion.StartsWith(queryText, StringComparison.CurrentCultureIgnoreCase))
8: {
9: suggestionCollection.AppendQuerySuggestion(suggestion);
10: }
11: }
12: }
If you’ve developed before against the Search contract, you’ll see that the code is pretty similar. In fact, when you have to make changes, they’ll be limited mostly to making your code point to the control instead of the SearchPane, the rest is very similar.
If you have an app that works with the Search contract today, what will happen? Well, remember that in the beginning of this article series, we talked about ‘Almost non-breaking’? This is one area where things will break in terms of UX. While the code will continue to work, the user won’t be getting a great experience anymore with your app. This therefore definitely requires an update of your existing app!
Summary
In this part, we looked at 2 major changes in the UX, namely the window sizes and the Search option. Stay tuned for more Windows 8.1 changes.
About the author
Gill Cleeren is Microsoft Regional Director, Silverlight MVP, Pluralsight trainer and Telerik MVP. He lives in Belgium where he works as .NET architect at Ordina. Gill has given many sessions, webcasts and trainings on new as well as existing technologies, such as Silverlight, ASP.NET and WPF at conferences including TechEd, TechDays, DevDays, NDC Oslo, SQL Server Saturday Switzerland, Silverlight Roadshow in Sweden, Telerik RoadShow UK… Gill has written 2 books: “Silverlight 4 Data and Services Cookbook” and Silverlight 5 Data and Services Cookbook and is author of many articles for magazines and websites. You can find his blog at www.snowball.be. Twitter: @gillcleeren