Great! :)
Thanks, we'll contact you soon.
If you’ve been following our blog, you’ve probably seen several articles on our project with our client in the financial services industry.
In case you haven’t had a chance to read the other articles in this series, we helped our client with their legacy desktop app development and rebuilt it as a modern app for the web.
In this final article of our series, we’ll take a technical look at several challenges we faced during this project and the solutions we developed to overcome them.
After we were tasked with rebuilding the legacy desktop app as a new single page web app, we communicated closely with the customer. We determined that it would be easier to encourage early adoption if we made the new app feel similar to the old one. As a result, we set out to design a web app that felt similar to a desktop app.
A crucial part of maintaining the old app's UI was replicating the old system's tabbing in the new modern app. In addition, the primary users were used to using Salesforce, which also uses tabbing, so the client requested that the homepage be designed with tabs.
In the old system, when someone opened a new software component, it would open in a new window. For example, if the user had one window open and started a new search, the new search would open in a new window. In the new app, we wanted the new components to open as new tabs rather than new windows.
Furthermore, in the old desktop app, the entire page would be refreshed when a user applied filters to a search, but since the new system would use tabbing, this presented a unique challenge.
We had to develop an unconventional solution for opening a new tab while keeping everything else static, and we only wanted to load the new page with information necessary for the query results without loading additional data.
In addition to the above functionality, there were several other key features that the client wanted us to create with our new web app development. For instance, when a user selects a bond record, the client wants the place order page to open in a new tab instead of refreshing the same page.
Also, after placing the order, a new tab would open to place the order with key bond details already populated on that page. Finally, the client requested that the app retain the latest search data from when it was closed. This search data would include the filters applied to the data and the results or records generated.
Unexpectedly, these requirements would cause complex technical challenges in our new web app development. Plus, the new app needed to integrate with the old system and Salesforce, so even more challenges arose from this integration need.
However, we love solving challenges and delivering excellent solutions, so we set out to design a new web app that we knew our client would love.
Before our new web app development journey, we needed to select a framework to build the app. Our team evaluated several technology solutions, including React and Angular, but we decided to build the new app using Angular.
We chose Angular for several reasons. For instance, Angular is easier to learn than React, which has a steep learning curve. Furthermore, Angular is well suited for single-page applications, which suits our new web app goals. Hence, we set out to build the new web app in Angular.
Along with deciding to use Angular, we had to decide if we wanted to use any of the pages that already existed in the old system or if we wanted to build everything from scratch in the new web app.
After discussing with our team and the client, we decided to reuse some of the same pages from the old system.
The pages were already implemented in the old system, and the same end users would be using them in the new web app. Furthermore, this shortened the time for our new web app development project.
After using the old pages, we needed to develop a new way to send the data through the web app. For example, since the app was session-dependent, you couldn’t display two sets of results with different criteria in different tabs in the old system.
Rather than show different results, the two tabs would show results with the same filters or criteria and data. Consequently, we needed to fix this in the new web app.
We solved this problem by changing the method for fetching the data. Instead of using a session to get the data, like in the old system, we used a URL with a query string to differentiate requests.
As a result, we were able to reuse pages from the old system without having to reimplement them in the new web app.
After we decided to use some of the old pages for our new web app development, we needed to figure out the nuts and bolts of the integration. Specifically, we needed to determine how to combine the old system with the new web app.
We saved the data in the session to apply the integration for multiple pages in the new web app and converted it to work with a query string for various models. Then, we developed a method to inform the system that a new tab should be opened when the user takes action.
In the old app, we found an option to post messages with parameters or events, such as “PLACE_ORDER” or “RESULT_PAGE_LOADED.” We set up the new system to look for those events and execute the desired code.
For instance, if a user were placing orders, the new web app would look for “PLACE_ORDER” in the old system and open the tab with the corresponding URL from the old system. Thus, we could use this method to integrate the old system with the new web app efficiently.
Searches returned thousands of results before we finished the integration, causing the pages to load slowly. The paging was being applied on the client side, the results were processing on the client side, and all the data was returning from the server.
We fixed this issue by applying server-side paging and loading. After the integration was completed, the only information needed to load was the total number of results and the page the user selected by using the page index instead of loading all of the results.
To cap off our work on this project, we adjusted the interface of the new web app. We removed the breadcrumbs, headers, and footers in the old system so the user wouldn’t know that these pages were coming from the old system. As a result, we created a new web app with a seamless look and feel that didn’t show any traces of the old desktop app.
Our client is happy with the work we’ve done on the new web app, but we know we can keep improving. We plan on adding more functionality as time goes on, and we’ll keep thinking of new ways to improve our new web app.
Although this is the final article in our article series on this project, we’ll keep producing content on our work for our clients. Stay tuned for more content, and don’t hesitate to reach out if you have any questions about our work or team.
If you’re seeking assistance with your solutions, contact us for a free consultation.
Integrant’s Vision is to transform the software development lifecycle through predictable results.