Posted on 18. July 2013

Sparkle XRM

Recently I posted a new Sparkle XRM sample up on the GitHub repository. To-date I've not explained why I've spent time pulling Sparkle XRM together, so this post is going to do just that…

Sparkle XRM is an open-source library for building Dynamics CRM XRM solutions using Script#, jQuery & Knockoutjs. It brings together these open source libraries specifically for the purpose of creating Dynamics CRM HTML and JavaScript Web Resources with a User Interface (UI) that has a similar feel to the native Dynamics CRM one. I found myself converting quite a few Silverlight Web Resources over to HTML and I needed a way of achieving the same productivity I had with Silverlight. I (still) have high regard the Silverlight approach but the reality is that cross-browser and tablet support is becoming increasingly more important to users - especially in the advent of Dynamics CRM 2013. With so many excellent libraries and approaches out there to choose from, I needed to pick ones that worked well with Dynamics CRM and use them as a base-line. Keeping open source was also a priority and so I didn't use libraries such as KendoUI requiring you to purchase a license for commercial projects.

Script# was my chosen JavaScript compiler because of its maturity and simplicity. I appreciate it doesn't full support Generics or LINQ constructs, but I use Script# with Sparkle XRM purely to allow error free JavaScript authoring against a strongly typed set of libraries, and Script# does this very well indeed. Dynamics CRM's JavaScript is also written using Script# and so Sparkle XRM doesn't introduce any more complex runtime library dependencies. Compiling your project will generate your JavaScript Web Resources with compile type checking which are then automatically deployed using the Developer Toolkit – working in this way is truly a joy! I've found that this approach allows you to write code to a level of complexity that I'd never had dreamed of if authoring it in 'raw' JavaScript.

Sometimes you've just got to make a decision and run with it!

There are 2 deployment scenarios I can envisage:

  1. Deployment of the Managed Sparkle XRM solution as a prerequisite your XRM solution. This has the advantage that it keeps your solutions size down so any updates you deploy are quicker to install/publish.
  2. Embedding the Sparkle XRM Web Resources in your managed solution – this would allow you to deploy as a single package – but it would mean that your solution could not co-exist with any other solution that also contains the Sparkle XRM web resources.

Design Goals

Sparkle XRM has the following design goals:

  1. Provide UI controls for editable grids and form fields (both with validation) so that I could achieve the same level of productivity as I did when writing Silverlight Web Resources.
  2. Provide an MVVM framework for HTML Web Resources.
  3. Make writing client extensions for Dynamics CRM similar to writing Server extensions! It is possible to share code so that it compiles to both a plugin assembly and to JavaScript, and I'll be publishing samples of how to do this in due course.
  4. Speed up the code/build/publish workflow and reduce syntax errors and debug time.
  5. Provide a strongly typed library for elements such as dynamic Ribbon menus and localisation (multi-language/date/number formats).

Other JavaScript libraries do an excellent job of providing for SOAP/SDK calls, but Sparkle XRM aims to provide an overall framework that XRM applications can be built upon. I don't see Sparkle XRM as a replacement for those libraries and when you just need to write Form JavaScript – they will be more than sufficient. Sparkle XRM's intended use is to speed up development of HTML web resources in your next XRM project. Where you are using Sparkle XRM for Html Web Resources, you'll find it is natural to use the same library for form/ribbon JavaScript as well.

MVVM 

Silverlight and WPF applications are most commonly authored using the 'Model, View, View-Model' pattern. MVVM is similar to MVC except the View-Model has much more interface centric logic than a typical Controller would do. In the days of Web-Forms/Windows Forms we would create events handlers that were invoked by UI Components (Buttons etc.). Those event handlers would then in turn make calls directly to other User Interface components (Text Boxes etc.). Now with MVVM, the View Model contains all the logic of your client side application *apart* from the User Interface Components, and importantly it has *no knowledge* of what UI components you have. Rather than making direct calls to these UI Components, the View Model refers to only other View Model properties that are in turn 'wired up' to the UI (or View) through the magic of data-binding. The View now 'sits on top' of the View Model through data-binding and invokes Commands and responds to changes in the properties it is bound to.

This approach has the advantage that is makes your application simpler in the long run because the View Model is only loosely coupled to your View. In fact you can test your View Model without even having a User Interface attached!

There are other patterns linked to MVVM (such as inversion of control) – but it is this loose coupling between View and View-Model and the simplicity that this creates that keeps me using it. Sparkle XRM uses Knockout JS as the data-binding magic behind MVVM enabling the same approach to be taken in your HTML Web Resources.

The Future's bright

Dynamics CRM 2013's new UI really sets the bar high for your XRM solutions. Users will expect the same level of single page responsive design from your own web resources and extensions. I've already found that Sparkle XRM provides a good spring board for my own projects; it possibly could for yours too.

If you would like to know more, you can head over to www.sparklexrm.com

@ScottDurow

Posted on 3. July 2013

Evolution of the Dynamics CRM Toolbar

With the first glimpses of Orion being available (or Dynamics CRM 2013 as it is now called) I thought it would be a good time to look back at how the form tool bar has evolved over its history.

I've been working with Dynamics CRM ever since the first version (when it was just Microsoft CRM) and with great fondness I reminisce!

Microsoft CRM 1.0 (Released January 2003)
Microsoft CRM 1.2 (Released December 2003)

The tool bar was very much as you would expect for any application of this era. Drop down menus and 16x16 icons with optional text descriptions.

Microsoft Dynamics CRM 3.0 (Released December 2005)

The toolbar remained very similar to the previous version, but with some groovy shading to give it a fresher look and align with the Microsoft Office toolbar style. Now part of the Dynamics family, this alignment with Microsoft office was an important step change in the product. As the window was shrunk in width, the text labels would disappear leaving only the icons to save space.

Microsoft Dynamics CRM 4 (Released December 2007)

The toolbar was again updated with the Microsoft Office style – and the dropdown menus were replaced with the Jewel menu. I remember many people using Dynamics CRM for many months before realising that you could click on the Jewel to get the 'File' drop down! Dropdown buttons were also introduced (e.g. Actions) to combine the dropdown menu bar with the button bar.

Microsoft Dynamics CRM 2011 (Released February 2011)

The Office Ribbon had been big news already, but its introduction into Dynamics CRM was again a step to align it with Microsoft Office. This was especially important for the Microsoft Outlook integration to give a consistent user experience. In Dynamics CRM, the ribbon introduced different sized buttons depending on significance, rows of buttons, split buttons and dynamic resizing based on the width available. RibbonXml provided a rich and powerful way of adding custom buttons that critically could be context sensitive so that they would dynamically show/hide, enable/display depending on what was selected or the data on a form. This was fantastic for XRM (Anything Relationship Management) applications but it was error prone to create due to the complexity of RibbonXml. The Ribbon Workbench plugged this gap!

CRM 2011 POLARIS/UR12

With the release of the Polaris/UR12 update, a new style of user interface was introduced that was used on an opt-in basis. The UI was based around the new Modern 'flat' user interface that originated from Microsoft Zune, further developed by Windows Phone and later Windows 8. If the 'process' UI was selected, the ribbon was replaced by a simple toolbar that addressed the main criticism of the Ribbon in that it was 'too complicated'. The design principle of 'the content is the UI' aimed to reduce chrome and use simple typography in order to increase readability and usability. An interesting result of this simplification is the reduction to a maximum of 7 buttons on the toolbar before others are pushed into the ellipses drop down.

The main drawback with the Polaris process forms was that they were not customisable and so remained to many customers more of a 'preview' of things to come.

ORION/Microsoft Dynamics CRM 2013 (Release Fall 2013?)

… and so that brings us to Dynamics CRM 2013 which at the time of writing is due for release in October 2013.
It has been well publicised that the Ribbon will no longer feature in Orion in favour of the new Modern 'flat' user interface style, and indeed the style is very similar to Polaris but with coloured buttons and the return of the well-loved 'Save & New' button. I welcome the addition of colour as I often found the grey buttons hard to locate quickly on the form. The design principle of keeping the number of buttons to a minimum still applies and the ellipses overflow dropdown is still there. It has been confirmed that the RibbonXml will still be used to customise this toolbar/command bar – and I suspect that those icons are the same 16x16 ones we see in the CRM2011 ribbon. Naturally, a new version of the Ribbon Workbench will be released for Dynamics CRM 2013.

Thanks for indulging me and reading this far - I'm feeling a bit glassy eyed and nostalgic - but the question still remains – what do we call the new ribbon?
Toolbar? App Bar? Command Bar?

I'll keep you posted when I find out!

@ScottDurow
Check out my Rockstar365 profile!