By Eranea, we have an obvious intrinsic affinity with the rich Google Web Toolkit (GWT). As we do transcoding from Cobol to Java, GWT also transcodes from Java to Javascript to allow the development of highly sophisticated web interfaces with high productivity: development is done with the comfort / efficiency of a compiled language like Java with much less risk of unnoticed glitches resulting from direct coding in an interpreted language like Javascript.
GWT has a ton of other advantages for us: we’ll write again about that soon.
The point of this post is that GWT is a great facilitator of our tactics to achieve “migrations by (tons of) little steps”: we are deeply convinced (by – past & painful – experience) that executing small things one after the other is at the end of day more efficient and safer than trying the method of progressing by quantum leaps: this “Big Bang” approach most often fails. Those leaps have often to been reverted and tried again (until users get fed up…) because of unexpected damaging consequences while small steps produce permanent recurring improvement at a very low risk level.
Google Web Toolkit efficiently supports this progressive approach:
-
its remote communication protocol (see page RPC) allows us to transport into some cache within the browser the data objects coming from business processing. We store them in a form neutral to the presentation format to be selected.
-
the sophisticated graphical widgets supplied by GWT can then be combined with those that we produce for our specific needs to achieve a data presentation totally independent of processing done by the central server. Over time, the use of different widgets and widget combination (as well as their CSS styling) allows the look and feel to vary massively over time without any change on the server side.
The look-and-feel that we recommend to start with is the one presented below: for that purpose, we have developed a widget to reproduce as exactly as possible the original presentation of the data as it used to be on the mainframe via its character-oriented protocol (3270, 5250). The rendering in Internet Explorer (but also in Firefox or Google Chrome) produce the following outlook : text fields on a black background with a limited set of colors and other video attributes.
We push the similarity up to the emulation of all the function keys found and heavily used on a mainframe application keyboard: we want users to be able to do on the transcoded application exactly what they were doing on the legacy Cobol version.
This look-and-feel often surprises / shocks the gurus of web interfaces and rich presentation technologies. But, we clearly use this structure on purpose: it allows a very smooth and cheap migration of the end users to the new system. The transition task is limited to informing them about the URL on the corporate intranet of the newly converted application. And that’s done !
End users then open their browser instead of their character-oriented emulator and they are ready to work. They find on those web pages the application that they know for ages:
-
position and format of data fields are strictly preserved.
-
use of keyboard keys is fully identical.
-
chaining between screens did not suffer any change.
This strategy has a double advantage: no training costs and no loss in productivity by end users. They clearly appreciate !
Of course, this legacy-like interface is just the first step to bring all users on board quickly and efficiently. Afterwards, we apply the well-known Open Source strategy « release early, release often » in order to improve this starting point by successive and frequent introduction of interface changes.
Those small improvements are very easily digested by end user: the beauty of “small steps”. A simple mail to explain what is rolled out is enough: no training. Finally, the high frequency of changes results in a high speed of evolution which permits to catch up with today’s standards: We finally achieve a UI that is state-of-the-art for RIA and Ajax interfaces. All of today’s standard stuff is eventually incorporated: predictive input, buttons, check boxes, scrolling lists, etc…
Original goal of the transcoding is achieved: legacy application has been fully modernized and mutated to best technologies (Linux & Java). But, this migration with massive added value was delivered smoothly and with no risk from a starting point mastered by every employee of the corporation: the legacy “black screen” initially produced by the mainframe.
