<img height="1" width="1" src="https://www.facebook.com/tr?id=1269148126497016&amp;ev=PageView &amp;noscript=1">

Flight Engineering: Swinging to HTML

Friday August 4, 2017 | By Ethan Morgan

Flight Engineering is a series about developing and shaping the Volo platform to serve our customers' needs. This week, Solution Architect Alaric Snell-Pym explains how the user interface of the Origin platform is evolving, handling huge databases and presenting them intuitively.

flight engineering.jpg

When Volo Origin was first written (under the old name, eSellerPro!), a Java Swing user interface was the best way to make a rich user interface. Web-based applications at the time struggled to handle complicated interfaces, with scrollable tables of thousands (let alone hundreds of thousands) of products being particularly difficult to handle well.

That decision has served us surprisingly well - it's not perfect (naturally), but it gets the job done and our customers consistently say they value its well-honed practical functionality over its appearance. It's certainly unlikely to be the ugliest thing in a typical office or warehouse.

However, it does present us with some difficulties as we evolve Origin to meet the needs of the future. We can't easily make the app available on mobile devices, for a start, and Swing user interfaces are hard to reliably test with automatic regression harnesses. A lot of the system's logic is contained within the downloadable Swing client rather than on the server, so automatic testing of the API exposed by the server can only test parts of the system.

Why not make a browser-based front end?

Good quesiton. The current best choice for a cross-platform user experience is modern HTML. Although it is possible to write native desktop and mobile apps, each of them has a narrower utility than an HTML interface - and users can share links to HTML pages between devices. Native apps have better access to platform facilities, but HTML isn't far behind.

But it wouldn't be practical to just build Volo Origin from scratch in HTML. It would be a lot of work to replicate even the functionality that our customers routinely use, let alone everything the system is capable of; and until it's featureful enough to completely replace the Swing application for even a single customer, it's not actually pulling its weight.

Long development projects without any gratifying deliverables until the very end aren't just risky, they're a strain on the morale of the team and customers - especially if the end result is just to replicate current functionality, without really adding anything new!


An incremental approach

In response to this problem, we have taken an interesting approach. We are developing our new HTML-based interface as a suite of independent interfaces brought together by a uniform look-and-feel so they look and feel just like parts of one application (while allowing each part to be developed and deployed independently).

Rather than offering them through a browser, we are (initially) embedding them in the existing Java Swing application using an embedded browser component. Automatic user session handoff from the Swing application to the Web application means that this doesn't require an extra sign-in step. From the user's perspective, parts of the user interface are starting to look beautiful and modern.

From our perspective, we have a powerful and easy-to-use new user interface toolkit. In our HTML-based Product Data Editor, for instance, it was easy to add the ability to filter the view of hundreds of different product attributes to only show those matching a search term.

Users often have to navigate through large lists of category-specific attributes to find the ones they need, and we were able to add a tool that lets people find the one they want in seconds, within about a day of development time. Dynamically changing the layout of a Swing dialog in an equivalent manner would have taken much more development work.

Simplifying Complexity

Additionally, our HTML user interfaces are purely presentation logic. JavaScript isn't a good language for expressing the kinds of complex processes Origin handles, so the right way to build the system is also the easiest way - logic in the server, exposed via a high-level REST API that the JavaScript front-end uses.

That means we can automatically test the system at that API, and the same APIs are also available for partner integrations, and other user interfaces. We can easily put together specialised user interfaces as, for instance, native tablet apps, re-using the work we did to expose the API for our HTML interface.

Using this approach, we can develop one module at a time and deploy it into production within weeks. As soon as we have enough modules built using HTML to satisfy the needs of one or more users of the system, we can expose those modules to Web browser logins, using a single-sign on system and a shared navigation bar so they all work seamlessly as a single interface.

So we can still get to a complete HTML interface - but in shippable increments, delivering benefits to our users and improving our development processes as we go.