ChartIQ Blog

Posted on by Terry Thorsen

The Bridge to HTML5: The Extra Mile of Design

Considerations for HTML5 Containers

Containers, of course, are not all wine and roses. Working within a container exposes new considerations for HTML5 developers and requires some rethinking about design and technique. It is critical to put the extra work in, otherwise, your desktop-based application will be no more than a browser window launched by a double click.

First and foremost, one must consider the user interface (UI). Traditional desktop applications rely on cascading menu systems. Not only are such menus out of style in terms of modern web development but in a multi-windowing application, they can be cumbersome—even in a native app. We are seeing many container-based applications moving toward “launcher” or “docked toolbar” paradigms and replacing cascading menus with dialog-based navigation.

Screen Shot 2018-04-17 at 11.01.34 PM

Second, “responsive design” takes on more nuance in a multi-window environment. User interfaces that switch to mobile mode when the screen size shrinks look weird on a multi-window screen. Making a distinction between responsiveness for screen resolution and responsiveness for mobile devices is critical (not just for touch—keep in mind that more and more desktop monitors are touchscreens). Menu bars also need to make space for navigational icons, such as “maximize” and “close.”

Last, working inside a container system reveals technical complications. Modern JavaScript frameworks, such as Angular and React, are not designed to operate across process spaces. However, in an HTML5 container, each window behaves like an iframe or a browser tab with dedicated DOM and subject to CORS restrictions.

In Java and .NET containers, each window is a truly discrete process, separated by a virtual vacuum that is the container process. In both cases, communication between windows must be coordinated and transmitted through the container’s process space. This essentially reveals itself as a distributed systems problem, allowing us to find solutions to these problems within algorithms and by leveraging interoperability buses.

We at ChartIQ have encountered and worked through many of these issues for our own deployments with state-of-the-art software systems. Several of our customers have successfully embedded our charting library into their Java and .NET platforms using TeamDev’s solutions. Along the way we’ve built up experience and capabilities that we are compiling into our Finsemble library for HTML5 desktop developers. The combination of a Finsemble container solution and ChartIQ’s W3C Web Components-based HTML5 Charting Library equips financial firms with the ultimate solution for building desktop applications their users will love and adopt for years to come.

To begin the Bridge to HTML5 blog series, start here or read the previous post, "Going All In." 

Download this complete blog series, Bridge to HTML5, below.