Resource Dictionaries

In this post I thought that it would be interesting to share some of my thoughts that I have been having recently around Resource Dictionaries (RD) and how they are structured. It is very easy to just put everything into your generic.Xaml or even into your app.Xaml files and let the designer run away with implementing their designs, but this is not too say that its the best way to roll.

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.

Be Sociable, Share!

8 Responses to “Resource Dictionaries”

  1. Rich,

    Great post. I’m neck deep in RDs and MergedDictionaries with a Silverlight application and I am getting frustrated by not knowing how best to use them.

    Scenario + Question: I have a custom UserControl with a Button in it. I have the style for that Button defined in a ResourceDictionary in an assembly called “ExternalLibraries.” The custom UserControl project has a reference to that assembly and “merges” the ResourceDictionary “BasicStyles.xaml,” from that assembly, in it’s UserControl.Resources collection.

    Why must the application that uses the custom UserControl contain a reference to the “ExternalLibraries”? The main application throws an exception saying that the UserControl’s MergedDictionaries are not found. If I add a reference the exception goes away and the application runs successfully. What if the application doesn’t care a lick about how the custom UserControl is styled?

    I’m greatly looking forward to your next post. RD’s, in my example, don’t seem very intuitive nor do they provide the cohesive features one would think they provide. What is the advantage to using them in this manner only to have to re-reference them in any application that attempts to consume a UserControl that has already referenced them? Does that make sense? I have a zipped project that reproduces this behavior if you’re interested. Just shoot me an email.

    – Aaron

    – Aaron

  2. […] Resource Dictionaries (Richard Griffin) […]

  3. […] Rich Griffin gives a thought provoking post on how Designers and Developers view Resource Dictionaries differently. […]

  4. excellent article! I have been looking for a decent explanation for an hour now. Indeed, why is there so little known about this obvious necessity?
    added to favorites :)

  5. […] of the … will transfer its entire operation, currently split between Terminals 1 and 4, to T5. …Resource Dictionaries xaml ninjaT5 Surface locations main concourse by EAT and in the chill out section at the opposite end to the […]

    heathrow t5
  6. At, you can see WPF and Sivlerlight themes.

    XAML Templates
  7. Hey Aaron,

    How are you getting on ?? So there is quite a lot going in your question. Can you send me a screen shot of your resource dictionaries please.

    When you say custom user control I am assuming that you are talking about a lookless control where you have defined styles and templates to make them look how you want ??

    If you are referencing styles and templates from your controls these resource dictionaries must be loaded.

    If you can give me some more info on some of the individual issues we can concentrate on the detail and get you moving

  8. The post is meant to be thought provoking and not give you an outline of how to organise your RD’s. If you have a colour and you want to make this into a resource then it should live in the Colours RD.

    What in particular are you looking for ?


Leave a Reply