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

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

  1. Great post Salim.

    I’m currently going down the HTML5 path myself, and yes it’s a steep curve, but I’m finding it very exciting.

    I often find that delivering end-user ease is difficult with the out of the box interface.

    We draw up the “ideal solution” quickly, and achieve the functional side with the standard toolset (entities, workflow, plugins etc).
    However many compromises are usually made in the UI/UX, to the detriment of the end-user.

    I wasn’t sure how much the custom user interfaces were out in the real world as I hadn’t seen many examples/posts like yours.

    If this is such a wide-spread thing for partners, do you think Microsoft is letting us down with the out-of-the-box options or flexibility? I’ve noticed in the Salesforce eco-system there are options like Skuid etc.

    Cheers,
    Dan

  2. Very fair comment Dan. What you said there : “many compromises are usually made in the UI/UX, to the detriment of the end-user” perfectly summarizes the reality on lots of projects I’ve been a part of, especially when a custom built application is being replaced by Dynamics CRM.

    I wouldn’t say Microsoft is letting us down, at least not completely. It seems to me like they leaving some space for their large ISV echo-system to survive and somewhat keep growing, while adding some components in the out of the box offering at a reasonable pace. To their credit, it’s been a very fast for the past 2 years or so with Adxstudio, Field One, Voice of the Customer and some other major features that were added in a short time span. I do agree that some basic stuff that most competitor products have should be in the product (e.g. editable grids should have been there 5 years ago, and we’re still waiting – sense the angry tone there? :).

    That being said, depending on the industry you company is in, you will almost always find tools/IVS products that can help you get closer to what you need to do without compromising too much on user experience in general. The down side is the cost and maintenance.

    I also find working on HTML5/JavaScript user interfaces very exciting. Enjoy!

  3. Thank you for not mentioning Silverlight as a solution …
    Obviously, HTML and the rest of the Open Standards are the only viable direction … 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s