We have an application where we're combining several different user controls into one main window. About 3 of the controls are developed outside our group, so we really don't have much control over their appearance. The main shell of our application uses AvalonDock so the users can rearrange the layout however they please.

The problem is, because three of the controls are not in our direct control the application doesn't blend very well together.

So I was wondering what could we do so that the application feels more cohesive?

2 Answers 2


That's a really good question.

Option 1

What I would want to do is push the big red EMERGENCY STOP button and make the project come to a complete stop. I would then like to call the project sponsors and project manager(s) to a meeting and explain why this project have a high risk of failing when it comes to the projects usability aspects.

On the meeting I would beg for an Interaction Designer and an Information Architect to be hired right now. I would also want to give them a week to get a clear picture of all aspects of the project, and have them present the results of their work no later than two weeks away. Then the project would have to restart with the hired usability team as responsible for the User Experience of the entire application, no matter where in the world User Controls are built. Consistency is key.

This is what I want to do.

Option 2

If the above is not possible due to organizational or political reasons (or your job might be on the line for calling a meeting), then you need to create a cross functional team. Even if you don't have control of what others develop you can allways colaborately decide which style to use. As you mention in your quesation, to get "user controls feel more unified", all the developers need to be unified in the sense of completeing a common goal. Within that goal is a big part the User Experience of the application. You also know that the application you are colaborately building will never be better than the tasks your intended audience of users manage to accomplish, when the application is published. Unify the teams, decide a common style guide, iterate wireframes and mockups together and get all teams to work as one.

  • I like the idea of Option 2. The other existing controls could be migrated by a phased development. You could create new controls for the existing components as WPF components and only bring in the winforms components when needed. This gives the existing control an "almost same" style. We did this with graphing controls where we created the UI for querying in WPF then only loaded the Winforms component when data was ready. The Winforms component was later phased out once it could be upgraded.
    – lifeofmle
    Apr 9, 2012 at 17:46
  • @lifeofmle Thanks! Option 2 is my real answer, but I wanted to challange Project Management as well, since this problem is owned by Management. However unifying style is very crucial, and I hope they don't release anything until they are satisified that it works as One UI. Apr 9, 2012 at 18:32

This is not an easy problem to solve in my opinion but since you are using WPF (Windows Presentation Framework) there are a few options you can do here.

  1. Create a generic theme for all of the common controls like textblock and buttons (ie. Style TargetType={x:Static Button}). This will allow the other controls to use the same styling at the root level. However this will not work if all of the controls are using styles by different using keys.
  2. Host each of the other controls in a ContentControl thus displaying the controls with the same "chrome border" around it. Maybe play with some Panel.ZIndex and Margin space to get it looking like the chrome border actually is part of the control.

The generic theme could be added into the application's resource dictionary so that all of the controls to get access to it.

If one control is using a light theme and another using a dark theme then if developers got lazy then they probably hardcoded some colours for the text so just changing the root style may not solve it.

The best way to move forward here is to create a style for your control to be used as the root control and use best practices so that the controls and be styled easily or if they must be used by specifying a key from the resource dictionary then use standard naming like "TitleForegroundBrush" rather something too specific like "MyControlDarkBrush". Once this is done perhaps with gentle persuasion you could get those two other controls onboard with your common styling. The best part here is that if you or another team has to create a new control they can just continue with clean XAML and your style theme.

  • We're using WPF Apr 5, 2012 at 21:43
  • Or I should say, mostly WPF. The controls we're getting from another team use GL Studio or something with OpenGL which we then host in a WindowsFormsHost. Apr 5, 2012 at 21:55
  • With the WindowsFormsHost you could still try to leverage the idea of the chrome border but there is a limit to this as the WPF control can't be shown on top of the Winforms control. This is known as the airspace issue, here is a list of other gotchas that you may run into
    – lifeofmle
    Apr 5, 2012 at 22:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.