The structure of the screen created by Sage CRM v7.1 and earlier is frames based. If you have done any exploring of Sage CRM 7.2 you may well have discovered that there are hidden frames in the page. 

If you right click on a page in Sage CRM v7.1 or earlier and view source you will see the frames structure.

A simplified version of the structure looks like this

<FRAMESET COLS="105,*"> 
<FRAMESET ROWS="74,0,24,*,0" > 
<FRAMESET ROWS="70,*,0,0,0" > 

Most of the frame names are self explanatory. Some of the frames in Sage CRM v7.1 are hidden and some become visible because of different system actions that are called. The hidden frames in Sage CRM v7.1 and earlier were used to perform different tasks. They were used for CTI and session "keep alive" actions for example. The CTI frames were usually hidden away but become visible when needed.


The removal of the framesets is a very big change in Sage CRM 7.2 which is very likely to have an impact on customizations in existing systems and any components and products created by developers.

This change will affect any client side code that references certain functions or objects and interacts with the frames such as TopContent or eWare_mid.  I have discussed this in two earlier articles


New element IDs and changes to page structure, and the way JavaScript code is referenced within system pages including the implementation of a new client side API will require you to look carefully at any code that is designed to execute in the browser.


But why has the Sage CRM development team removed the Framesets?

I think there are 4 reasons why I think it is a good idea.

  1. Firstly, the use of frames works against the idea of simplicity in web design.  Imagine we want to look at the details of an entity (e.g. company) in Sage CRM.  When frames are used they break the information up across multiple URL fetches.  Ideally a single URL should be used to fetch the details of an entity.  The web ideal is the ability to expose any resource as a single endpoint.  
  2. Secondly, when writing client side code in earlier versions of Sage CRM, designed to execute in the browser, referencing functions and objects in other frames could prove very problematic.   A developer may create code to run in the eware_mid frame, but which addressed an object in the eware_menu frame and then updated the eWare_top frame.  A system administrator trying to support such code would be confronted with a web of target references because of the frames. 
  3. Thirdly, a simpler interface, based on well marked up pages, is much easier to control through CSS and styles. It will be much easier to create customizations for Sage CRM 7.2 that work with multiple devices. Also non-frames based web applications provide better usability as frames can disorient screen readers (web to speech).
  4. Lastly, the removal of frames will provide an easier interface for Sage's own developers to code.  This will mean less defects, it will be easier to QA and to support so will allows more effort to go into new feature development.

The old Frames have been replaced with DIVs.

The neater, cleaner structure will allow the Sage team to move faster in developing new stateless CRM and mobile solutions.  It means a much simpler navigation for all users as there is no longer any special forward and back buttons


Instead of using the special Sage CRM forward and back buttons a user of Sage CRM can simply click on the standard Browser Back and Forward buttons.  And if the user is working with the standard Sage CRM interface on a Microsoft Surface tablet then they can use the screen swipe behaviour for forward and back actions.

Before you rush to any conclusions as to which tablets and devices will fully support the full Sage CRM interface it is important that you check the latest version of the Sage CRM 7.2 Support Matrix.