Before the import features in Blend appeared we used the cool plug-in from Mike Swanson which would allow us to convert vector art work in Xaml. This was incredibility useful and mean that we reduce the time it took to convert these assets into Xaml and then modifying the Xaml in Kaxaml or in Blend. The process worked for us and we continued down this path until the import features in Blend improved and are now at a state where we can easily use the import functionality in Blend to convert these assets even easier.

But, that is not where the story ends, if you have tried out the import process on complex AI or PS visuals then you will have found that when Blend performs the import it positions each layer into a Canvas and will also import any images into the project as well. All in all this is cool however not so much when you have an existing project where you are happy with the code architecture and the folder structure of your application. And, this is what I want to dig into in this post is how to use the import functionality to your advantage.

Where do we start, ok so lets imagine that you have a project which you have setup or a developer on the team has created, its nicely structured and potentially uses MVVM or even a MVVM framework like MVVM Light. We also have a bunch of great looking designs that we need to convert into Xaml assets. We have a couple of options available at this point; we can import directly into the main solution or we can create a separate project a scratch project where we can import into. Admittedly at first I started out by importing directly into the main solution however this became a headache as the solution becomes polluted, by this I mean that when we do the import Blend will create a new folder in our project to hold the images that are referenced in the AI file however we are more than likely have an images folder in the project where all our images live. And for me this is where the management headache begins as we have to work out which images we want to keep and the ones we want to remove, and we also have to then move these images to the right folder and change the references to these images from the Xaml. All in all not too difficult when we break them down but on a large import this can become rather sticky very quickly.

Because of these issues what I have found is that importing into a scratch project is a smoother process for creating your Xaml assets and managing what images you want to keep. So the process goes something like this.

Create a scratch project and setup the folder structure for your Resource Dictionaries and images to mirror the same structure in the main project. Then import you AI or PS file into this project.

Next start to clean up your imported Xaml, the majority of the time you will want to ungroup the visual elements from their containing canvas as the visual elements will have been relatively positioned to mirror the layout defined in AI or PS. You will also find that the designer will have used a number of different layers to create the final appearance of an element. For example the designer may have used 4 different layers in order to create the colour of an element. In these cases my approach is to use the colour picker in Blend to find out what the colour is of the topmost layer, create this colour as a resource in your Resource Dictionary and then remove all the underlying layers until your left with the topmost then apply your newly created colour resource so that the visual element looks like the original. We could leave the visual elements as is however there are performance issues that we may encounter when doing this, in that if you have a list and you are planning on using this visual a number of times then those hidden layers are going to be present in the visual tree which means that the framework will render these and will have an impact on the performance of the application.

Other items to look out for are drop shadows on elements, when performing the import the drop shadows will be translated in a png images. In the majority of cases removing these images and replacing them with a drop shadow effect is the best mechanism, however there are some cases where the png works better. These situations are related to interaction design and occur when you are either; animating the visual elements on screen from one position to another; or you animating the drop shadow effect itself; in these circumstances then leaving the png is desirable and you may also consider using the EnableGPUAcceleration param at the plugin level along with setting the Bitmap Caching mode on your Xaml element.

By this stage you should now have cleansed your import and are ready to start styling and templating the imported visual elements into controls. There are two options available to you at this stage and they are related to your experience and confidence around the templating of the controls.

The first option is to group up the different visual layers that you want to make into the control, the majority of the time grouping them into a Grid or a  Canvas will work for you. From here you can then right click on the layout panel that you created and select “Make into Control” option where you can select from the popup dialog the control that you want to create a style for. From here you can start to assign the visual elements to the parts associated with that template.

The second option is to drag onto the art board the control that you want to style and template and size the control to be the same as the visual elements. Right click on the control and select the “Create a Copy” sub menu option located under “Edit Template” option. This will then provide you with a default template which you can then start to modify so that it takes on the appearance of the visual.

The first option works well if you have intermit knowledge of the template you are creating, it can also work well when you know that you are creating styles and templates for controls which are of a fixed height and width. However, if this is not the case then the second option is a preferred route.

The styles, templates, colour and brush resources that you are using need to be added into the correct Resource Dictionaries. By following this approach you can then pick up the visual elements and merge them into your main solution along with the modifications to the Resource Dictionaries and moving any images that you are using into your images folder.

I hope this insight helps both designers who are creating assets using Adobe products to think about some best practices on how you construct your designs and for the Blend folks this should help with cleaning up the imported Xaml.

As always please let me know your thoughts and also what you have found works best for you.

From a developer prospective these files can become large very quickly and the result is a complete management headache when it comes to maintaining the styles, control and data templates. Its is also rather easy  to allow this to happen as its in the Xaml and its what the designer produces, in effect its someone else’s responsibility. What is rather interesting and confusing at the same time is that Blend actually works very well when it comes to dealing with resources that are all in one file and it provides the designer with an easy way manage styles and templates. The other interesting thing about RD is that its actually at the heart of the Designer and Developer collaboration, its one of the areas where these two worlds collide. Therefore one of the ways in which we can help improve the workflow is to have a better understanding of RD and create some guidelines on how to best go about structuring them.

Unfortunately, even though RD are one of the core parts that make up the presentation layer there is very little information on best practices on how we should be doing this and why its important to get it right in order from which to have a good platform to move off from. Structuring RD in the wrong way can have rather serious performance problems.

There is a great article on the WPF Disciples pages providing very good advice on how to structure your RD and naming conventions, but I want to attempt to take it a little further. There are a number of different scenarios that I have come across and I am sure that there will be more along the way.  These include; a POC application where this is built quickly and iteratively and requires a compelling UI but there is a high potential the application will not make it into production; themeable applications where a number of different themes can be applied to change the look and feel; and also applications that leverage 3rd party controls which have their own and sometimes rather interesting ways of how they are styled and templated. Each scenario is different but can be solved in the same way by using well structured RD to produce a clean, performant and easy to maintain application.

Ok, so how can we achieve a better structuring of the RD, help improve collaboration and provide a basic pattern and best practices in order to satisfy the different scenarios outlined above ?

Putting your RD in a separate project is the first thing to do, there are a number of advantages in doing this; but primarily this is about separation of concerns to help with workflow; and it helps to provide a blue print of a theme that can be reused over time.

In addition to the guidelines put forwards from the WPF list I am also going to add some more into the mix.

Suggested WPF Disciples Resources :-

BrushResources – solid brushes, linear gradient brushes and drawing brushes

ConverterResources – allows us to reference any of the converters by merging our resource dictionary with this file, rather than re-declaring our converters every time.

ImageResources – as above, allows us to declare an ImageSource once and reference it from anywhere. 

TextResources -styles applied to textual elements (Hyperlinks, TextBlocks, etc.)

Additional Resources:-

Colours – for simple colours used as a swash for branding of clients colour palette.

DataTemplates – holds all the Data Templates used in the application.

Storyboards – holds all the Storyboard animations.

VectorGraphics – holds all the vectors graphics

CustomControls – holds styles and templates for those custom lookless controls

CommonControls- holds styles and templates for those common controls

Now the above list is not an exhaustive one and there is a high potential that this may change in the future but for now these provide a good platform from which to start. There are a number of ways in which you can slice and dice the RD used in your application some of which I will talk about shortly, but in general its best to think about the RD as a whole. The reason for this is that its best to see the Xaml assets as what constitutes your design and interaction of the UI that you are projecting onto the view for the user to experience. Therefore a change in the template or style means a  complete new design. By thinking about them in a more holistic view as a the sum of all parts.

Therefore by splitting up the styles, templates etc into different high level RD categories provides the capabilities for the designers to work in an independent way and not have the constraints of working in the same project as the developers. The majority of times you will want to split out the RD into a separate project, and provide an area where they can create and design controls and elements. It also means that as they are working in a separate project they are completely separated from the developers but they are both working in the same solution.

What are those other views of RD that I mentioned earlier. Another potential way of looking at splitting up the RD is to break out the control templates and styles and place those into separate files. This will provide the ability to change the colours, font types etc and leave the control templates alone, which is great for those situations where you want to restyle the application and want to retain the layout of the controls. However, there are some problems with this approach; making significant changes to the style of controls will almost certainly mean that you will have to change the layout of the control, or building a custom control to handle the different styles; support in Blend for this type of structure is sub optimal in that it becomes more difficult to navigate and manage the styles and templates.

So why is it important to structure the RD in this way ? Why can they live all in the same Generic.Xaml file ? Is it the developer or the designer who owns the files ? How does this make my application more themeable ?

So those are a few of the questions which I have been asked about recently from both designers and developers, and they are all good questions and ones which i have also been thinking about hence my solution attempts to tackle these questions and provide a simpler implementation of how to use RD in your app.

One of the main problems with coming up with a good structure is the lack of guidance that is actually out there, plenty of high level information around some structure and naming conventions but no real information on the details. Rather frustratingly although we have gone head first into solving and building frameworks that address MVVM and come up with some notable solutions. It does feels like we have neglected an important area of the presentation layer.

What is rather interesting is how differently developers and designers perceive RD and this comes out in how they implement them in the app.

Developer : As a developer it is a natural and in the interest of best practices to split out each individual control so that each control is sat in its own RD.

Designer: As a designer its natural to think of all the controls at a higher level so that at set of individual controls contribute to the overall design of the app.

So as you can see neither side is right or wrong its their interpretation of RD which differs and this is natural as the different roles have different views and priorities on what is required to build the User Experience. What is interesting as well is that these opinions are skewed by the tools that they use and how they interpret and solve problems. The developer is very much focused on detail and implementation, mean while the designer is more interested in the higher level and the total experience of their design.

Therefore a combination of both these views seems to feel right where we split up the RD into a higher level categorisation with good naming conventions. This approach meets both parties needs and is Blendable allowing the designer to work in an environment which has a reduced reliance on the developer world and vice versa.

So I am hoping this that has made you think a little more about RD. In the next post I am going to talk more about how to implement the RD in your application and drill into the performance issues related to implementing RD and some sample code to help with guidance.