NextGen Consulting

Upgrading AmdocsCRM Smart Client form (Part Two)

Preface

The original out of the box AmdocsCRM application quite often contains forms which deliver none-optimized user experience; these forms display too much information and lack context sensitive functionality. For certain business scenarios part of the displayed information is either irrelevant or overloaded.

These forms do not take full advantage of the rich client capability provided by the Smart Client underlying Java SWING technology.

In this two part posts I try to demonstrate how the SWING technology can vastly enhance user experience and improve usability by merely rearranging form layout and adding simple logic to it.

In part one I have demonstrated the first steps in upgrading an original, out of the box, Smart Client create case form.

I created an inherited version of the original form, created a form version selector to redirect the application to the newly created inherited form, verified the inherited form, then started to rebuild the new version by first moving all original controls to a parking lot (the ‘Unused Controls’ area), and rearranged the form layout.

Note that all the logic provided with the original form (dataset, code) is still active in the new form, but since all original controls are invisible (moved to the unused controls), I can invoke the new form but can not interact with it yet due to the hidden controls.

A new grid was defined for the root panel: One column and two rows. The single column has a predefined width size (initial form width size of 800 pixels) and will stretch itself (‘growable’) to allow it expand to the full screen width.

Assuming the minimal form height is 600 pixels, the first row was defined to an initial constant height of 555 pixels and growable to provide space for the main form area, while the lower row was defined as a fixed (none growable) 33 pixels height to provide exact space to contain the form’s buttons.

Each of the two rows was populated with a card panel UI control on which second level panels may be added. This gives the flexibility to add several fully overlapped panels under the card panel. Each of these panels can later expose different sets of controls according to the business process context. This paradigm allows for enhanced user experience by exposing only context relevant information at a time. This time we placed only a single panel under each card: crdMain / pnlMain for the main area and crdButtons / pnlButtonsMain for the lower row.

For the lower row buttons area, the new layout is simple: I redefined the panel’s (pnlButtonsMain) grid to contain a single row having a constant height of 22 pixels, and a horizontal strip of ten none-growable columns, each was set to have an initial constant width of 60 pixels (some width size were extended laters).  One column (marked with red arrow) was set to growable, to allow the buttons strip to expand to full width of any form / screen size.

 

Next we need to place all relevant controls in their new locations. All relevant original buttons (those previously moved to ‘Unused Controls’) were moved back from the ‘unused controls’ area to their new locations on on pnlButtonsMain:

 

The upper, main area (pnlMain) was subdivided using the following 5 X 5 grid:

The numbers in red denote the column / row fixed size and an optional (G) whether they are growable.

Note the spacer rows (5 fixed pixels width / height) that initially leave nine real estate rectangle areas (areas A – I), each populated with its own card panel and one or more flipping panels attached to it (eventually, these nine areas are reduced to five dispayable areas).

The three main columns are growable and have similar stretching relative weight. The similar stretch weight guarantees they will evenly stretch within the size of their containing form.

Display Topics

Each area within these columns will be used to display one topic (group of related controls) per panel.

A card panel can display a single panel at a time or flip panels according to some business logic. Each panel practically displays a group of related controls (called topics).

The division to distinct areas provides a convenient, readable view, allowing the human eye to easily capture and grasp each topic’s content.

Reducing the Number of Display Areas

In order to reduce the number of topics, some adjacent areas were defined to share a single card panel (a card panel can occupy one or more neighboring areas). Thus areas A and B share the card panel crdMainA, areas D and E share crdMainB and areas G, H & I share crdMainC.

Placing the Controls

All card panels, except for cardMainC, currently relate with only one panel which is dispaled by default (in other words, they do not flip panels).

Let’s have a further look at cardMainB / pnlMainB1

 

The panel pnlMainB1 layout use a 1 X 3 grid; a single fixed 125 pixels height row, and two subareas, having 220 and 240 pixels width, separated by a 5 pixels devider. Each display area use its own panel: PnlMainB1Inner (Case Type) and pnlCaseIndicators (Case Indicators).

Each of these panels has its own grid layout i.e.: Case Type. Once the grid layout was defined, I was then able to move back the original UI elements from the unused controls to their new location.

As mentioned, the original logic still works with these controls; there is no need to write any new code for them.

Now let’s view the lower card panel crdMainC:

Under this card panel we find pnlMainC1 and pnlMainC2. Unlike the previous example, where the two subpanels were placed on a parent panel grid, each at its own space (therefore displayed together), here we find two panels directly located under a card panel. This layout allows only one of them to be displayed at a time (since both occupy whole parent card panel space).

Each of these panels further carries its own layout hierarchy to support exact layout.

We need now to add logic that will allow the application to respond to user selection and expose the panels, each at a time. In order to provide this interactive functionality, a hyperlink control was added at the upper right corner of each panel.

On pnlMainC1, a hyperlink labeled ‘Details’, on pnlMainC2, a hyperlink labeled ‘Notes’.

Clicking on the Details hyperlink should trigger the application to display pnlMainC2 and Clicking on the Notes hyperlink should trigger the application to display pnlMainC1.

First we had to associate an action – an action object that is invoked when a hyperlink is clicked – to each of these hyperlinks. We associated both hyperlinks with the selectTabPanels action

Here is the selectTabPanels action definition:

And here is the code associated with the action’s start event. This code is invoked when actions associated controls (the Details and Notes hyperlinks) are clicked:

Note that the actual control (hyperlink) that was clicked and triggered the event is identified out of the event data. The name of the panel to be displayed is retrieved from the user data associated with the clicked hyperlink. The User Data programmatically added to the control when the form is initialized:

The actual panel replacement performed by the updateControls() method:

There are numerous additional features that were added to the upgraded page but not described in this post due to space limits.

To watch the new form in action, click the following link Create Case. 

31/05/2010 - Posted by Yuval R. | Amdocs, BSS, CRM, CRM, Smart Client, Technology