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 rebuild their legacy desktop app as a modern web app. In this final article of our series, we’ll be taking a technical look at several of the challenges we faced during the course of this project and the solutions we developed to overcome them.
Tabbing in the Old System and Goals for the New System
After we were tasked with rebuilding the legacy desktop app as a new single page web app, we communicated closely with the customer and 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 key part of maintaining the UI of the old app was replicating the tabbing of the old system in the new app. In addition, the primary users were used to using Salesforce, which also uses tabbing, so the client requested that the home page be designed with tabs. In the old system, when someone opened a new component of the software, it would be opened 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 that was necessary for the query results without loading additional information.
In addition to the above functionality, there were several other key features that the client wanted us to create in the new web app. For instance, when a user selects a bond record, the client wanted 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 that were applied to the data and the results or records that were generated.
Unexpectedly, these requirements would cause difficult technical challenges to arise in our development of the new web app. 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 awesome solutions, so we set out to design a new web app that we knew our client would love.
Check out how we create change in the software industry. Read more software development case studies today!
A Modern Framework for a Modern Web App
Before we built the new web app, we needed to select a framework to build the app with. 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 suited our goals for the new web app. Hence, we set out to build the new web app in Angular.
If It Works, Don’t Fix It
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 amongst our team and with 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 amount of time it would take to release the new app.
After we decided to use the old pages, we needed to develop a new way to send the data through the web app. For example, in the old system, you couldn’t display two sets of results with different criteria in different tabs since the app was session dependent. 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 were able to solve 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.
Looking for more than web app development? Check out what we can offer you!
Combining the Old with the New
After we decided to use some of the old pages in the new web app, we needed to figure out the nuts and bolts of the integration. Specifically, we needed to determine how we would combine the old system with the new web app.
In order to apply the integration for multiple pages in the new web app, we saved the data in the session and converted it so that it would work with a query string for multiple models. Then, we developed a method to let the system know that a new tab should be opened when the user takes action. In the old app, we found an option where you can 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 was 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 were able to use this method to efficiently integrate the old system with the new web app.
Improving Performance for Faster Searches
Before we finished the integration, searches were returning thousands of results, and this was causing the pages to have slow load times. 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 that needed to load was the total number of results and the page that the user selected by using the page index instead of loading all of the results.
At Integrant, our engineers are ready and eager to take on your project. Get in touch today!
Customizing the User Interface
To cap off our work on this project, we made some adjustments to the interface on the new web app. We removed the breadcrumbs, headers and footers that were present in the old system so that 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 so far on the new web app, but we know that we can keep making improvements. 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 the work we’ve done for our clients. Be sure to stay tuned for more content, and don’t hesitate to reach out if you have any questions about our work or team.
Always Improving
Related Content
We rebuilt a legacy app as a modern web app by taking several key considerations and best practices into account. You can read more about what we learned here.
We helped our cautious, small business client, successfully build their dream software project. Read more here.
Subscribe to our newsletter!
We've been in the software industry for 30+ years so we have a lot to share with you!
Follow US
Address: 16870 W Bernardo Dr, Suite 250
San Diego, CA 92127
Email: info@integrant.com
Phone: +1 858.731.8700
© 2021 Integrant, Inc. All Rights Reserved