Transferring user context between multiple applications

Question

I am currently maintaining an old legacy thick-client application with many individual screens and functions.

We have a strategy for migrating screens from the old technology (VB6) to a newer architecture and UI technology. Up until recently this was to embed Winforms or WPF inside the existing VB6 screens but the company is moving towards Web-based applications.

For the web-based portions, we remove the old screen, retain the exiting navigation and then transfer the user to a web-based application, passing the current customer context along on the URL.

This has introduced some issues due to the disconnected nature of the two applications, where a user could open customer A, then navigate to a web screen for that customer, then go to customer B, but in their web browser it is still pointing at customer A.

The web page has a time-out which forces the user to acknowledge they want to continue with the current customer, but there is a concern for some screens we are planning on moving to a web interface, where a mistake by the user could have a large financial consequence.

I am hoping someone might have a good solution for handling this situation, better than a simple time-out.

Please let me know in a comment if more information is required.

I have asked this same question on StackOverflow, but thought I might get more usability options here

EDIT: Switching between different customers is done in the thick-client application. At the moment the web pages are an extension of the thick-client application, not a full-blown application by themselves.

Answer 1

There are a couple of alternatives you could try as you move along. I assume you don’t have an API to access a Data Access Layer – which would be the best and therefore my first option:

Make a full blown web application

Switching back and forth between different types of application is not very useful and will probably ware down your users with agony and fear. My idea is instead to either make an API in the existing application so you can access the database from there. The other alternative is to access the database directly from the new web application. Which way you chose is, from a UX perspective, irrelevant. But working in one application isn’t. In fact it is quite crucial. Still – since you post this question here, I guess you already know that, and that you want the second best option, not quite as costly. That leads to contestant no 2:

Control the web page - server side

I guess this is possible since you work in an ASP.NET environment (?) and that you user the attribute runat=”server” for the controls? If this is true you could use the same event when a user clicks a customer in the application, but you don’t open a new window. You use the same instance of the web browser and let the native application control what happens in the browser. This means that when user (in the native old app) clicks on customer B, the web page is reloaded with customer B instantly. No timing events and no “confirm” events needed.

But seriously consider option one, because in the long run it will be cheaper than what you’re currently doing. Maybe use a break-even cost analysis which shows that you will gain on the first approach in three years’ time.