Robert MacLean

Rangers Treasure Map v2: Transparency & my first design notes

Published on Estimated reading time: 5 minutes

Overview

I am a proud ALM Ranger and one of the projects I’m part of is the ALM Rangers Treasure Map – we’ve just started work on version two of it, and part of that is an effort to increase the transparency of the project. To facilitate this, each team member will be blogging about their experiences and thoughts on what they’re doing for all to see. None of these should be seen as statements of fact or official Microsoft views—rather, these are personal views of people working on a project. You can find a table of contents for all posts on Willy-Peter’s blog.

Lastly, these notes are written with those involved in mind, so I won’t explain everything—that said, if you’d like to know more about something, just post a comment and I’ll go into a lot more detail on it for you.

My first set of design notes

With the overview done, I’ll start with my first set of design notes, which focus on how we could fulfill the following Epic: As Alex, the technology consultant, I would like to view my progress through the guidance on the live tile without launching the application.

This epic is broken into two features, which I’ll break down below.

Feature: Enable users to track their progress through the guidance, sync to the cloud, and track it on a live tile.

The first thing I like to do with designs like this is to create a simplified list of goals—really no more than three or four items that I can then explore in more detail. So for this feature, the distilled list of goals would be:

  1. Cloud sync
  2. Live tile – I don’t see this as cloud-push live tile (e.g., sports app) but rather an app-generated live tile (e.g., photo app).
  3. Chart rendering to image for the live tile.

We need cloud sync

Windows RT already supports this, and it’s a fairly simple task to implement. I’m proposing a small wrapper layer around the built-in aspects to give us a consistent way to work with this data. There’s some overlap here with the features of another epic (As Alex, the technology consultant, I would like to be able to mark treasure items as complete within the ALM guidance, see the same progress on all my devices where the application is installed, and be able to show/hide completed items)—so this may be a feature that gets moved out of here and into the other one.

Technically, the two APIs for cloud sync in Windows RT are:

My idea is to create a simple API that allows us to do something like:

ToggleStatus(Status.Done, <item id>);

This would store the data in either a small XML file in the roaming folder or in roaming settings as a key/value. I propose this style so we could extend it to work for favorites too. From the discussions already, the key/value store might be the easiest way to do this.

This API also needs to support the map pages, where we can ask:

GetStatusCount(<group id>, Status.Done) // returns int
GetItems(<group id>, Status.Done)       // returns IEnumerable of the items

Impact on code: All new code. A new API for our app, and sprinkling ToggleStatus around the app in the right places.

We need live tile

This is straightforward—really, we need to design what it should look like. We need both small and wide designs. Live tiles can take images or text, so if we’re planning on charts, it will mean rendering an image (see below). My thinking is that on app startup—and potentially every time ToggleStatus is called—we update the tile in a separate thread/task. The API here is simply:

TileUpdateManager.CreateTileUpdaterForApplication().Update(??);

Impact on code: All new code. New logic in app startup and integration with ToggleStatus.

Note: We could push this via a service, but that would mean an external dependency, and we’re really trying to avoid that. So keeping everything in-app makes me feel happier.

We need to do chart rendering to image for the live tile

This is going to be tough—we have some drawing primitives in the runtime, but we’ll likely need to rely on third-party code, particularly WriteableBitmapEx (MS-PL license). Once that’s done, we can figure out a way to generate a chart. (Intentional use of “nice,” since how nice it is will depend on how much work we put in.)

While this is possible, maybe a chart should be a stretch goal because anytime we add an external dependency, it also needs to meet Microsoft’s quality gates and legal requirements, which can add extra time to the project. So shifting the chart to a stretch goal (i.e., if everything else comes together) or pushing it to the next version might be better.

This may not be the only option—so we need to check with internal contacts at Microsoft for advice on this.

Impact on code: New dependency on WriteableBitmapEx + all new code. No impact outside these items.

Feature: Add ALM blog tracking/news to the app + live tile.

My understanding of the distilled list of goals for this:

  1. Grab the Rangers RSS feed into the app
  2. Show the RSS feed in the app
  3. Show the RSS feed on the live tile

Grab Rangers RSS feed into app

This is pretty simple—we have a pre-configured list of URLs (which can be placed in an XML file) that we parse on startup (in a separate thread/task) using Windows RT’s SyndicationClient API. My feeling is this is just temp data, so we can store it in memory—but I’d love some feedback on that?

Impact on code: New API that wraps this. Changes to the XML file and its API. Some additional startup logic.

Show RSS feed in app

This is really just a ListView with items displayed. Minor impact—but it needs a design.

Show RSS feed on live tile

This is easy—just grab a few items from the feeds (from above) and send them to the live tile immediately. We need to plan this with the stats display since we only have five tiles to rotate through. Maybe 1 or 2 for stats and the rest for top news articles from the feeds? I’m thinking simple text will be best.

Question: What happens when I tap that item? We can detect which tile was shown, so do we just go to the general feed view (easy and low impact) or try to find the exact item (more tricky since we’d need to persist some data to match it all together)? This is more of a UX design issue than a dev feature.

Code impact (general feed): None—it will just be part of the above logic.

Code impact (matching item): No impact on existing code, but the scope for the first implementation is bigger since we’d need to persist some info on the feed locally so we can quickly launch to the item and show something.