I am a proud ALM Ranger and one of the projects I am in is the ALM Rangers Treasure map – we have 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 are doing for all to see. None of these should be seen as statement 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 am not going to explain everything – that said if you would like to know more about something, just post a comment and I will go into a lot more detail on it for you.
With the overview done, I’ll start off with my first set of design notes which look at how we could fulfil 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 will break down further below.
The first thing I like to do with designs like this is get a simplified list of goals, really should be no more than three or four items that I can then dig into more detail. So for this feature understanding of the distilled list of goals on this would be:
Windows RT already supports this and it is a fairly simple thing to do. I am proposing a small wrapper layer around the built in aspects to give us a consistent way to work with this data. There is 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 is moved out of here and into the other one.
Technically the two API's for cloud sync in Windows RT are:
My idea around the wrapper is to give a simple API that allows us to say something like ToggleStatus(Status.Done, <item id>);
This would store it in either a small XML file in roaming folder or in roaming settings as a key/value. I propose this style so we could extend it to work for favourites too. From the discussion already, the key/value store may be the easiest way to do this.
This API also needs to be able to assist for the map pages where they can ask, how many of items of group X are done (maybe something like GetStatusCount(<group id>, Status.Done) [return int] and also GetItems(<group id>, Status.Done) [returns IEnumerable of the items].
Impact on code: All new code. A new API for our app and then sprinkling the ToggleStatus around the app in the right places.
Easy enough to do again – really what we need the design of what it should look like. We need both a design for small & wide. Live tiles can take image or text, so if we planning on chart - it will mean rendering an image (see below). My thinking here is on app start up & potentially every time ToggleStatus is called we update the tile in a separate Thread/Task. API here is simply the TileUpdateManager.CreateTileUpdaterForApplication().Update(??);
Impact on code: All new code. New bit to the app start and then integration to the above ToggleStatus
Note: We could push this via a service, however that means an external dependency and we are really trying to avoid that. So having it all in app makes me feel a lot happier.
This is going to be tough - we have some drawing primitive support in the runtime, but really we will need to rely on third party code here most importantly http://writeablebitmapex.codeplex.com/ (MS-PL license). Once that is done we can look at trying to figure out a nice (intentional usage of a word that could mean different things to different people, since how nice it is will be a factor of how much work we put in) way to generate a chart.
While this is possible, maybe a chart should be a stretch goal on this because anytime we take on an external dependency, it also needs to meet the quality gates from Microsoft & also needs to meet legal requirements for Microsoft. This can add a load of additional time onto a project. So shifting the chart to a stretch goal (i.e. if all comes together we do it) or pushing it out to vNext maybe better.
This may not be the only option – so we need to check with internal contacts at MS for advice on this.
Impact on code: New dependency on Writeablebitmapex + all new code. No impact outside the above items.
My understanding of a distilled list of goals on this:
This is pretty simple, we have a pre-configured list of URL's (can be placed in the XML file) that we then parse on start up (in a separate thread/task) with the SyndicationClient API in Windows RT. My feeling is this is just temp data so we can just store in memory but I would love some feedback on that?
Impact on code: New API that wraps this. Changes to XML file & it's API. Some additional start up stuff.
This is really just a listview with items being shown. Minor impact.
Needs a design though.
This is easy, grab x items from feeds (above) and send to the live tile immediately. We need to plan this with the stats display since we only really have 5 tiles to rotate through. So maybe 1 or 2 for stats and rest for top news article from feeds? I am thinking simple text here will be best.
Question I have here, is what happens when I tap that item. We can detect what tile was shown so do we just go to the general feed view (easy & low impact) or do we try and find the exact item (more tricky since we need to persist some data to match it all together). This is more UX design issue than a dev feature.
Code impact (general feed) - none, it will just be part of the above.
Code impact (matching item) - to existing is none, but the scope for the first item is bigger since we should persist some info on the feed locally so we can quickly launch to the item and show something.