In v2 the team has invested a great deal of UX design and feature coding to improve the accessibility, the user experience and ensure that the user always has a snapshot of the latest information relevant to the treasure hunt. In this post we will peek into the App Bar, Splash Screen and Live Tiles.

Splash Screen

We start with the easiest finish touch, for which no complex coding is needed to show a splash screen while the application loads. All we need to do is define an image with a named SplashScreen.jpg asset, scaled to 620×300, 868×420 and 1116×540 pixels.

Done!

UX Lead question time …

Q: Why is the splash screen still using the v1 yellow mellow style, while the rest of the UX has migrated to the ocean style blue?

The splash screen is still mellow yellow, as the title has remained the same colour. The same principle still applies as to the tile – it is eye-catching and stands out from the rest of the apps that are out there.

Live Tiles

In version 1 the ALM Readiness Treasure map had a normal, wide and static Tile which resembled the splash screen. In version 2 the team decided to provide the user with real-time news and progress information, creating a dynamic feel … also known as Live Tiles

If we look at the start screen, we will notice that our ALM Readiness Treasure Map displays two Live Tiles, one displaying the latest News (left) and the other the exploration Progress by the user through the Treasure Map, displayed as percentages completed per treasure category (right).

Open the LiveTile\TileGenerator.cs file to explore the magic:

Looking at the call stack we notice that we instantiate a TileUpdateManager class as a continuation to LoadDBAsync(), which in turn calls the GeneratePerecentageTile(), followed by a call to GenerateNewsTile() as a continuation to the RangersNewsFeed.LoadItemsAsync() call. A lot of magic happening within a few lines of code, but essentially instantiating both the progress and the news tile we introduced above.

Somewhat off track … make sure you experiment with the new CodeMap feature in Visual Studio. It allows you to visually display the call hierarchy of calls within your application, which adds immense productivity support to code explorations.

Looking at the GenerateNewsTile() method we realise that the notifications are done by creating a XML message, allowing us to potentially display images and as in our case text on both the square and the wide tile.

Both the News and the Percentage Tiles call the CreateTileNotification() method, which creates a notification object used by to display the dynamic tiles.

Dev Lead question time …

Q: Where is the magic that starts the Live Tile when the application has never run on the system?

There is none & it isn’t possible. The tiles are only generated on app startup.

Q: So in other words if you never run the app the Live Tiles will not show? It requires the user to run the app at least once??

Yip

App Bar

Last but not least we look at the App Bar, which supports the drive by Windows Store Applications to reduce the clutter on the user interface and focus on content. To enable the AppBar right-click the screen or swipe from the bottom or top of the touch screen.

The top AppBar is intended for navigation and the bottom AppBar for action command types. If we enable the AppBar when we are perusing one the the project treasures, we nota that the top AppBar allows us to go home (navigation) and the bottom allows us to pin or add as favourite (actions).

For those with Eagle vision it is apparent that the bottom AppBar example we showed above had two action buttons (pin and favourite), whereas the XAML defines three (pin, unfavourite and favourite). If you explore the XAML for the second and third button you will realise that the visibility of each button is based on the IsFavourite property, ensuring that either the Unfavourite or Add as favourite button is displayed. The magic potion: Visibility="{Binding IsFavourite,Converter={StaticResourcetrueMeansVisibleBooleanToVisibility}}"

To conclude we emphasise that AppBar is an object that resides in every Page object.

UX Lead question time …

Q: Should we define a Top AppBar on every page or an AppBar on the main page that is shared throughout the application to promote a consistent navigation?

App bars provide the user with easy access controls for the app when they need them. App bars – whether they are top or bottom app bars should only be made available when there are controls that a user may need for that particular area of the app they are in. For example: in a finance application in an app, there might be a return to ‘Home’ button, but the top app bar in the ‘Home’ does not need a home button, and may have a button that is ‘Apply’. For further information about this area, check out this MSDN page that describes the do’s and don’ts of app bars http://msdn.microsoft.com/en-us/library/windows/apps/hh465302.aspx

Dev Lead question time …

Q: Hypothetically and assuming our UX expert is not watching, what happens when we fill the landscape AppBar with action icons from left to right, i.e. use up all real estate. Then we flip to vertical view.

This isn’t even a portrait vs. landscape issue – it can hit landscape too if the horizontal resolution isn’t high enough. Since we have a grid with two balanced columns (i.e. each uses 50%) & each have a stack panel in it, on lower resolutions like portrait, the inner icons (i.e. the ones to the right of the first column & the ones to the left in the second column) would disappear behind each column.

Next?

We will peek into the code that aggregates the blog feeds and thereafter the code that tracks the progress through the treasure map to see if we can reveal a few more gems.