One of a few practices I see when people customize Dynamics CRM that usually comes back to haunt them during update rollups or upgrades is directly referencing the CSS files and classes that come with the product. It’s an innocent enough mistake, but the CSS files which ship with Dynamics CRM are intentionally not documented in the SDK. Directly referencing them is not supported. The Dynamics CRM team reserves the right to change them at any point, just like they reserve the right to change the structure of their html. That’s why direct HTML DOM manipulation of the UI the server creates isn’t supported either. Of course, you can manipulate the DOM of the web resources you author as much as you like. If you think about it, this makes perfect sense. I am not aware of any product out there that shield you from future changes if you hardcode your extensibility code to html/css structures. So what should you do? Well, you should create your own CSS files which mimic the CRM look and feel and reference those from your web resources. That way, when anything changes with the Dynamics CRM codebase, you are shielded from any ripple effect. You’re customizations may look out of place if major colors or fonts change. However, if you structure your CSS right (i.e. don’t copy paste, reuse), then you should be able to adjust to those changes with less impact. Ok, but how? Here’s a great article from the Dynamics CRM in the Field blog which walks you through the fundamentals:
As many of you know, the CRM 2011 UI leverages more “in browser” processing. Because of this, CRM 2011 will perform better when using the latest version of Internet Explorer (currently IE9) because of IE’s advances in performance through hardware acceleration. Simply put, CRM 2011 runs best on IE9. In speaking with many customers about this topic, I typically get the following response:
“We can’t upgrade to IE9 because we have apps that only work in IE7/8. We can’t afford to invest in updating those applications just so we can run CRM on IE9.”
There’s a solution. The reality is that you CAN tell IE9 to render your app in IE7/8 compatibility WITHOUT changing your web app code. Unfortunately, I’ve found that most people just don’t realize it is possible. The Defining Document Compatibility article explains how to make it so that IE9 will render as if it were a previous version IE. What most people overlook is that you can do this without modifying a single line of your applications code. How? Jump to the Configuring Web Servers to Specify Default Compatibility Modes section of the previous link. It explains how. Hopefully this helps in making the decision to upgrade the workstations in your environment to IE9 so that you can take advantage of it’s advances in performance, etc. without breaking your incompatible web apps.
Now and then, I hear from users that don’t like the fact that CRM loads screens in distinct windows in certain scenarios. I can understand how these windows can get a little daunting if you have too many open and are switching context between multiple windows on your desktop. However, this is actually a really nice to have capability when you are working in a multi monitor setup. A tip that I have been sharing quite a bit lately, but have yet to blog about is to use the features of your browser to control the behavior if you prefer not having to deal with the separate windows. Specifically, change your tabs configuration:
Now let’s walk through the behavior. I’ll start by clicking an Account record:
Notice how the account opened in a new tab next to my first tab:
Again, I will click something that would traditionally give me a popup window. Now there is a third tab:
There’s also a natural “breadcrumb effect” because the tabs are in order left to right of how I interacted with them. Also, when I close the rightmost tab, I’m back where I came from, and so on. So if you are in the “I don’t like all these popup windows” camp, this will hopefully help you out.