In the last post my aim was to start a conversation around the advantages of building a visual data model.
But this is a POC ? Why would you do this?
Well its an interesting question and I am sure that there are folks out there who like to build prototypes and POC’s in this way, but based on my experience this usually ends up taking longer as you find yourself adding a workaround to the existing workarounds resulting in friction between what you want to do and the limitations of the framework. So the approach that I prefer to use is to take some time out at the start of the process and deconstruct the visual designs and build out a data model to represent what information needs to be presented. We can then go off and create the simple factory classes to build these data structures and take full advantage of the features supported by the framework. In essence we are using the same techniques that we would use for a production quality application but slimming down a journey through the application using more appropriate patterns.
This simple process is not time consuming, helps clear up any potential misunderstanding of how the application will react based on certain interactions, and it means that when deconstructing the visual designs its easy to figure out what type of control you can use in order to build the visual and if the control you are thinking about using will support the interactions required. The additional bonus here is that if you want to go a step further then you easily wire in a simple MVVM pattern, again this is something that I do however its not an essential step.
What I also like about this approach is that POC’s are usually built in a short timeframe and are thus open to change on a regular basis and we need to have an approach which reduces churn. By having a good data model you can limit the pain when things change as you can easily change the data object to suit and then a simple change to the Xaml. The opposite of this can result in lots of conditional logic which becomes prone to bugs and also limiting the application to potentially just a clickable mockup.
The other benefit which results in this approach is the level of reusability that I can pull from the POC and move into the production application. By having taken the time to produce a data structure that is usable this means that I can potentially reuse all the existing data templates, data bindings, styles, templates and certain custom controls. Again from my experience this level of reusability is normally higher than when we push forwards with a more static and tightly coupled approach.
To put this into a better context, a number of Surface applications that I have been involved in recently have required a ScatterView with ScatterView Items as these control provide those all important gestures for NUI interactions out of the box. Cool, but we are faced with the options either; create a known number of items and potentially recreate the same style but with different hardwired data; or create a single data template and style and take advantage of the data bind features. This can easily be achieved by data binding to the DP’s provided by the ScatterView Item that controls its placement, its easy to maintain and manage when those known changes happen. It also provides us with the flexibility to extend certain aspects rapidly without getting freaked out by the amount of conditional logic being added to the app.
My approach here is a simple one, create a base class for all your data controlled visuals which allow you to provide point data information so that when the objects are created you can initialise them where they need to be placed on screen. You can also add into here some more properties such as Orientation and data bind your data object property to the Orientation DP. Properties such as CanScale etc I would manipulate in a Style for the ScatterView Item, however there is no reason why you could not add them into the base. My reasons for the using a Style is so that when I am working with the designer I can easily make changes to the Style when we are both using Blend, it also allows me to share the work with designers visually, this for me is essential, personally I am more of a visual guy I prefer to see something rather than read textual content a visual helps paint the picture in a more accurate way with less room for individual perceptions of a textual instruction or description.
This simple approach provides; the ability to place visual elements exactly where the designer wants them;animations can be built in order to animate these visual elements on and off screen, interrogating the strongly typed data types means that we can apply the required styles on demand; reduces the complexity of app by taking advantage of data binding.
Just to break this down a little further, with the Tag Heuer implementation, I created a bunch of data objects for the locations around the world, London, Los Angeles, Cape Town, Sydney etc; all of which subclass the same base called Location. Location, Travel and Watches, the three different states of the app all subclass a class providing the positioning logic which intern subclasses an abstract base implementing INPC. I then have a data templates for each of the locations that we need to visualise, London, Los Angeles, Cape Town, Sydney etc. The data templates deal nicely with presenting our data, however there is a problem with layout as some of the aforementioned locations need to be positioned from left to right and some need to be positioned from right to left. To achieve this visual effect I used a different style
one for left to right and a second for right to left and wired these into the data template. I could have written c# to flip the visual tree however in this instance it was more effective to rebuild the styles in Blend it also has the advantage that I can show the designer in Blend the visual created and make any additional tweaks required.
I used the same technique for the F1 GP races and the watches area all of which have strongly typed data objects to encapsulate the visual information providing me with the advantages mentioned above to create and adapt quickly with the changes to the visual designs, it also allows me to take advantage of OO when it comes to adding additional properties to the base classes which will have a ripple effect down the object hierarchy.
In your next POC or prototype in WPF I hope that you will feel confident enough to try out this technique and reap the benefits that are at your disposal. Unfortunately the current version of Silverlight does not support implicit data templates, which in my humble opinion is a fundamental missing part of the Silverlight framework. Hopefully we will see this in a future release.
In the next post I am going to dig into how I built the watches section of the application and also dive into how interactions with the watch chrome and its content were created.