Custom User Interface in CRM – HTML5/JavaScript or ASP.NET Web application?

Lots of times on CRM projects, we are required to build and display custom screens inside of Dynamics CRM. There are a lot of factors that come into play in the choice how we build these custom user interfaces. It is a very key decision to make because it can sets the standard technologies and tools that you use for custom screens on project (among other things). I thought I’d share some key points to consider in your decision making process to determine what technologies and tools to use.

The need for custom user interface

First, it is important to know and understand when it is required to build custom UI as part of your CRM solution implementation. As a wrote a few years ago, we sometimes find ourselves in situations where we can come up with a complex data model and we feel like the out of the box UI capabilities won’t be user friendly enough to drive user adoption. Situations like that create the need to build more user friendly interfaces to simply make people’s lives easier when they start using the CRM/XRM application. Some examples are

  • Custom calendar view for timekeeping
  • Tree view to display a complex hierarchy
  • Interactive Bing or Google maps views of CRM data
  • Editable grids
  • Complex grids with aggregates, grouping functionalities
  • Integrated views to other systems

And the list goes on. The needs are very different depending on the nature of the enterprise looking to implement a CRM/XRM solution.

Most common technology choices

From experience, I have seen a lot of custom screens built using the following tools/technologies:

  • Silverlight
  • ASP.NET / ASP.NET MVC
  • HTML/HTML5 + JavaScript + CSS

The screens are usually displayed in web resources or in an IFRAMES inside CRM on forms or as standalone modules (open from a button, display in sitemap area). I will not cover Silverlight since Microsoft announced its end of life and continued support for a few additional years, plus the world has started to move on.

ASP.NET / ASP.NET MVC

  • Pros
    • Flexible server side business logic
    • Easily integration with external systems (web services, databases etc.)
    • Can be very quick to develop depending on the requirements, expertise and accelerators (advanced controls provided by Telerik, Infragistics or others can speed up development time significantly)
    • Develop with a familiar programming language (C# + Visual Studio) – this of course depends on your development background
  • Cons
    • Requires the deployment and maintenance of a hosted web application
    • You have to deal with the weight of ASP.NET (ViewState, Postbacks etc.)
    • Not a great fit with CRM Online and cloud offerings in general (cloud deployment, cross origin web sites, integrations etc)
    • Required additional configuration in CRM + JavaScript to set the IFRAME’s sources (URL)
    • Effort for developing custom web applications is often under-evaluated

HMTL(5)/JavaScript

  • Pros
    • Usually, a much lighter solution and if done properly, custom UI components can be very responsive and provide great user experience
    • All components are in CRM Web Resources (html pages, JavaScript files, images…)
    • Custom screens are CRM Solution aware and there is no need for deploying and maintaining an additional web site on a web server
    • A definite plus for cloud based Dynamics CRM implementations
    • Can be very quick to develop depending on the requirements, expertise and accelerators (Kendo UI controls or others can speed up development time significantly; other frameworks like Knockout JS, Bootstrap can also be useful)
    • Leverage trending technologies and tools
    • Use any IDE you want (no obligation to use Visual Studio, even if you should J)
  • Cons
    • Possibly additional complexity if you need to display information from an external system
    • If not structured properly, JavaScript code can become massive and hard to navigate/maintain
    • For non-web developers, might be a steep learning curve
    • Need to establish good project structure and standards (e.g. use TypeScript or Script Sharp)

What else to consider?

There are other factors to take into account, some being specific to each organization. A few examples:

  • What is the expertise or your resource pool?
  • Do we have people to build and maintain what we deploy?
  • Are we in CRM Online or planning to move to CRM online?
  • Are we, as a company, trying to get into HTML/JavaScript more?

This is good food for thoughts for starters. If you want more guidance, feel free to reach out to us.

Advertisements

Silverlight, HTML5 and Dynamics CRM

The Glory Days of Silverlight

Silverlight is Microsoft’s plugin for web-browsers that enables running rich Internet applications, with features and purposes similar to those of Adobe Flash such as multimedia, graphics, animations etc. Shortly after Silverlight was introduced to the market in 2007, Microsoft quickly started to build knowledge around how to write and deploy rich applications and integrate them with Microsoft Dynamics CRM starting at version 4.0.

When you thinking about it, the need for custom UI integration with Dynamics CRM has always been there since the earlier versions. As CRM solution providers, most of us have been in situations where we can come up with a complex data model and we feel like the out of the box UI capabilities won’t be user friendly enough to drive user adoption. Situations like that created the need to build more user friendly interfaces to simply make people’s lives easier when they start using the CRM/XRM application.

To better illustrate, here are a few examples of when we would want to write a custom UI components in CRM

  • Display a tree view of related records with parent/child relationship.
  • Display complex search results: I’m thinking about PowerSearch which is a Global Search add-on for CRM. If you want to search for multiple entity types at once, a custom UI is required to display all results on a single page/view
  • Display timesheets, Gantt project management charts in Professional Services Automation solutions such as Assistance PSA and XRM1 (view screenshots below)

The Decline of Silverlight and the Rise of HTML5

With the emergence of HTML5, it seems we are headed towards a future in which browsers will support HTML5 tags natively thus enable rich content without the need of plugins like Silverlight or Adobe Flash. If some of us as individuals don’t believe this is true, Microsoft and Adobe seem to believe it is since they both dropped or significantly slowed down the evolution of their platforms. Silverlight’s latest major release (version 5) came out in 2011 in a world in which we see companies releasing software solutions at a very fast pace. The emergence of HTML5 have been well documented over the past year. There are still a lot of skeptics out there and that is understandable given how long it’s taking for the HTML5 standard to be completely defined and made available in all browsers.

Dynamics CRM: HTML5/JavaScript or Silverlight

What does this all mean for us Dynamics CRM integrators? The need to have custom UI controls is still existent and it will not go away even with all the new flexibility that we get with CRM 2013. Some data models will always be complex enough to require a better UI to give the solution its best chance of being used. In addition to that, there are still plenty of CRM add-ons built by Microsoft Partners that still use Silverlight 5 as a key piece of their solution. Below is a decision matrix that I came up with for us CRM Solutions providers going forward in making a technology decision when building new UI pieces for MSCRM.

What about the upgrade question? You have Silverlight controls and are wondering if you should built new controls in HTML5 and JavaScript. It’s your decision. Silverlight is not dead, Microsoft is still supporting it and it will for a long time. If you want to learn the new technology and have the time and money to do so, then go for the HTML5 remodeling. Keep in mind that it is a risk given that we have no idea what the lifespan of HTML5 will be.

What about buying an add-on that heavily relies on Silverlight controls? I don’t have a problem with that as long as it’s OK for you to install Silverlight on all client computers. Moving controls from Silverlight to HTML5/Javascript is A LOT of work and represents a significant amount of work for the add-on solution providers. They will upgrade when the time is right for them to do so (hopefully).