Ditch the Aging UI not the Aging App

There is no excuse for poor user interfaces – even in legacy applications.

Let’s consider how we can revitalize, and in some cases remove, serious problems to existing user interfaces – without the need for a complete re-write that incurs significantly more investment of time and money.

Here we’ll typically be looking at applications built on a thick client architecture.

It’s Already Obsolete – Do We Throw It Out & Start Again?

As a technology leader, you know that whenever you work on a new initiative, regardless of the technology you choose, it is already obsolete.

Knowing this, what do we do?

We assess current technology, even if nascent, and try to determine if it will be here for the long haul. We know we can’t wait around for the next big thing.

The systems we chose 10 years back, when bandwidth speeds were magnitudes slower than today, screens had sensible resolutions and the cloud was significantly less mature than now, are now due an overhaul. Though possibly leading edge then, with millions of dollars of R&D to their name, they aren’t now.

Do you throw all that away and start a brand-new development initiative and move to a new technology stack, or do you stop and take the customer perspective and consider what they really need?

Back Then, the Thick Client was the Answer

A decade or more ago, users may have needed large amounts of information at their fingertips, ?lots of information packed on the UI, or an offline capability. We may have needed to synchronize large datasets locally for near instantaneous slicing and dicing – updated in real time.

With this in mind, CTOs and technology heads considered the technologies already used in house to avoid the technology stack being unduly fragmented. If a new technology framework was selected without full consideration, future leaders would likely face a mess of interconnected systems written in many technology stacks – presenting successors with a support nightmare (remember that at this stage, microservices and loosely coupled systems were yet to emerge).

To control the hardware and all its resources, including graphics and filesystems, we chose to develop the software as a thick client, building and evolving those systems over many years.

It Just Needs to Work!

If you ask a system user what they care about, they are unlikely to demand that the system must be written in a particular language, or utilize a particular relational database management system, or that it work with multiple operating systems. More likely, their reply will be: It just needs to work.

Given the reality of finite resources and clear opportunity costs, as well as the evident truism, “if it isn’t broken don’t fix it,” we continue to develop and improve existing systems, even if the framework or architecture has been surpassed.

With user needs top of mind, it’s important not to get precious about the underlying technology – it just needs to work!

Re-Engineer The Things That Matter

As technology leaders, we care about the long-term support of the system, with all the moving parts that are needed to make it function. Slowly upgrading the backend infrastructure, such as the database management system or the operating system, is something that typically requires minimal effort and keeps the platform safe, as well as securing its future.

What about the user?

A decade ago, who predicted the advent of 4k laptop screens? (Well done if you did). Unless you are superhuman, you can only view a certain amount of detail - especially on screens the size of laptops. So what do users do? We ‘zoom’ the content. We view at 200% so that a 4k screen renders with sizing equivalent to a full HD screen.

It is interesting to note that if you keep a 15 or 17 inch laptop 4K screen in its native resolution, you can see 101 rows and 59 columns of a spreadsheet running in Microsoft Excel - but only with the aid of a magnifying glass! That’s why we zoom to 200%.

However, a number of graphic libraries do not scale well and some user interfaces become distorted if the zoom is not 100%. This does not make for a happy user experience. Operating system providers have done their best to mitigate the problem, but if your original UI was pixel based or does not have in-built transparent scaling, you can run up against some serious problems.

The end user has 2 choices. Zoom – or go non-native.

With ever increasing screen resolutions, users have 2 choices to ensure the UI can cope. Zoom more or adopt a non-native display resolution. In some cases, only the adoption of a non-native display resolution is appropriate. However, this adopting means that the more modern systems suffer in terms of quality and detail.

What does any self-respecting technologist do? Look for alternatives.

We consider whether there is a more up to date version of the graphic system or a different graphics system - such that re-engineering the user interface is not a herculean task associated with a complete re-write.

A good example is to consider a thick client written in a legacy graphic system like Microsoft WinForms. A natural progression would be to take it to a more modern graphics library like Windows Presentation Foundation (WPF), solving the display problems. But questions like “is there the expertise?”, “is WPF still supported?” abound.

While it solves the immediate need, it doesn’t go far enough.

Is There A Future Proof Baseline?

Is there a baseline which, if it could be implemented within a legacy system, would keep it fresh, allow continual upgrades and minimize costs?

This is where the browser comes in – because it has come on leaps and bounds over the past few years. With ever-improving graphics toolsets, such as Bootstrap and other libraries, combined with the massive technology base of HTML, CSS and JavaScript, it seems like a sensible approach to build a new, fresh UI using web technologies, whilst integrating this within a legacy environment.

The Browser

Browser technology is now a highly optimized system for rendering quality graphics on any resolution.

It is a sandboxed system so that one tab of a browser does not directly affect the other open tabs (how many times have you had a website become unresponsive but your other tabs are working just fine?).

Google went a stage further and open-sourced the browser component into a project called Chromium, which is the ‘browser window’ i.e. the window that displays the web page content. Microsoft Edge now features Chromium, as do other browsers, such as Opera.

More importantly for technology leaders, it is possible to encapsulate the Chromium component within libraries that can be loaded into our legacy environments. In the Microsoft world it is called WebView2. Projects exist to migrate this into Java (Java Chromium Embedded Framework) and other environments.

Electron is a notable example of a cross platform system utilizing this technology - and Microsoft MAUI, while still new, promises UI across mobile and desktops, including Linux and Apple operating systems. But let’s not get carried away. We are dealing with legacy systems here.

Using Web In Legacy

The ability to use the framework of Chromium means that we can now get HTML/CSS designers to design a modern user interface and ‘clip’ it into an existing legacy system. There are a few things to consider, but these are specific to the product you are looking to refresh from a UI perspective, rather than a technology problem.

How It Works

The idea is to dock the web library (control if you prefer) into a window in the legacy system and unclip the existing UI in favor of a UI hosted via the web library. This opens up the world of web design and modern web servers. Since the HTML/CSS can implement the same controls as more traditional UI frameworks and more, it is possible to refresh the UI.

Think of a web page hosted in a window in the legacy application. It is sized correctly to be a comfortable transition by the existing user base, it can make the best use of space, and it does not need to be ‘mobile aware’, since the system is running in an existing environment. Making a UI mobile aware adds complexity and cost, even if the designer uses modern bootstrap and other libraries.

Let’s look at the possible solutions for the incorporation of this technology. Which use case does your application fall into?

Option 1: If we developed it now, it could be completely or predominantly browser based.

This option really refers to applications where there are more trips back and forth to a data source than there are performed locally. This option is for applications that simply serve up content from the data source, without a whole lot of processing on the client.

If this app became fully browser based, there may be a change to the working practice of the familiar legacy UI - and we should minimize this to ensure a smooth transition. There may be other problems – especially if the system required direct access to hardware. However, looking at the system overall, it could be hosted.

Option 2: There is too much processing locally for it to be a viable browser solution.

This option is for legacy systems that incorporate a large local processing component. These can still benefit from integration of this technology – but the approach needs to differ slightly.

Implementing The Options

Implementing Option 1

In order to implement option 1, ultimately, the new UI component will be shunted onto a server-side web based technology. This is largely due to the fact that the page is really a view to the data, which is stored on some data source.

So why not develop the whole UI in a modern server-side architecture and host the page in the web library – and send the information to the legacy system to deliver the output?

If the output is saved on the server in the original legacy application, the web pages can consume this content directly, once created. This is best illustrated by the flow below:

Implementing Option 2

In this scenario, where there is a large amount of local processing, the new UI is maintained locally so that processing can be fine-tuned. Remember that hosting the new UI in the legacy application, or even in the local filesystem, allows complete manipulation. There are numerous libraries that can manipulate the document object model of the browser, or even an HTML file. As long as the legacy application’s manipulation of the HTML produces valid HTML, the control doesn’t care. Since there are no server-side trips, this can produce a highly responsive UI and mesh with your legacy system perfectly.

Mix and Match

You may decide to mix and match both approaches.

For example, in its simplest form, pages are displayed to the user from a webserver URL. Now let’s say processing begins and you need to update the progress via a progress bar. It would be better to manipulate a progress bar locally, without a trip to the web server to update the progress, and only when the processing is complete, redirect to a new page from the web server.

The choice of webserver hosting or local hosting depends on whether your legacy application involves a lot of local processing and manipulation of the UI based on local results. By utilizing local content and re-writing the HTML pages on the fly, you can construct a highly responsive interface.

Conversely, if the UI is simply collecting user information and then passing it to an engine, for example, then there may be benefits to hosting all the of pages on a web server and simply passing the selections to the legacy system, and redirecting to another page on completion. The icing on the cake to all this - virtually any programming language can manipulate an HTML document model. So whatever your application is written in, a refresh is almost certainly available.

You Decide

While a complete re-write of any system may be the optimal solution, it may not be possible from a business perspective – given it may well incur very hefty investment.

Here, you have alternatives that enable you to deliver an enhanced UI – and enhanced user experience - but with the benefit that all those thousands of lines of code, which do the processing, remain untouched. This drastically reduces the risk of bugs and other related software problems.

These are your options: a complete re-write, a shunt of UI to a modern server or a mix of local and server content. It’s not that one of these alternatives is better than the other - and I am not advocating one approach over another ?– my objective is simply to support you in the creation of viable solutions.

Enjoy evaluating your options.?