Contents

Introduction 1

Considering The Pitfalls Of Legacy Technology 2

Integrating HTML5 Into Your Technology Stack 6

Javascript Charting Libraries: 10 HTML5 Canvas Element Vs. SVG

Why Should Developers Use JavaScript Modules? 12

The Importance Of UX In Financial Applications 15

Enhancing Clarity Through UX Design 18

Business Benefits: The 5 Benefits of 21 Advanced Charting Solutions

The Nitty Gritty: Getting the Library 23 Introduction

Technology for financial institutions today is rapidly changing. The industry is currently experiencing a “once-in-a-generation” change—one that happens about every 15 to 20 years— as firms are shifting from legacy applications that were built in Java, .NET and C++ to HTML5. The last time a movement of this caliber happened was during the .com era, when companies en masse shifted over to web and Java systems.

In the last several years, the momentum of HTML5 has resulted in a technological overhaul within the capital marketplace. Many financially focused companies are investing significant amounts of time and resources into transforming their front-end user interface to enhance their offerings and heighten the user experience. Financial companies are currently in a race to not only offer the most competitive and beautiful interface, but also the most immersive. Delivering on the promises associated with the future of the trading desk - clean and beautiful visualizations, simplicity, and interactivity - is ChartIQ’s driving force.

1 DATE PUBLISHED Considering The Pitfalls Of Oct 13, 2016 AUTHOR Legacy Technology Michael McClung

vs

Consider this. It always feels easier to stay in our comfort zones.

As developers, our comfort zones are typically defined by the technologies we know, whether it’s an , a language, a framework, or a library. However, what we know best may often be a legacy technology, which, in the world of software, can leave an individual or a team behind the technology curve.

But it’s not always our fault. Legacy technologies have a substantial amount of inertia within software organizations. Core products are almost always (by definition) built on legacy technology. Development teams have been trained to expertise levels on this legacy technology, and capital investments have been made on them. It’s obvious there are strengths and weaknesses.

Yet, organizations rarely explicitly decide to stick with a legacy technology that has run past its prime. As the incumbent, it simply becomes the default choice. Even worse, the choice between keeping legacy and replacing technologies is too often seen as a binary decision, with legacy winning through acquiescence, when in fact, a transition over time is optimal and achievable.

Thus, it makes sense to consciously investigate how in-house technologies measure up to the state-of-the-art ones periodically. After all, “state-of-the-art” simply means “the best that’s currently available.” Using the “best” to build applications typically translates to better development efficiency—more top developers are attracted to projects, and perceptions from both inside and outside are improved. Ultimately, better products can be delivered more quickly and at a lower cost while a team’s skill set is enhanced—a win-win for all involved.

2 | The Bridge to HTML5 However, there is almost always an initial hurdle: What constitutes a legacy in-house technology being past its prime is difficult and even controversial. What determines whether a state-of-the-art technology is compelling and worth adopting isn’t always clear either.

Often, the hype around this new technology blurs objective comparison. Unproven tools and products are touted as state-of-the -art, spelling out the weaknesses of legacy technologies before their own weaknesses are well understood and addressed. Early adoption comes with risks and headaches. It is critically important that organizations look for objective evidence when making a crucial analysis.

Are you or your organization operating on legacy technology and unproven tools?

HTML5 is the most compelling state-of-the-art technology for building virtually any GUI-based, cross-device application. HTML5 is well past the tipping point— it’s been thoroughly vetted, matured, and is here to stay. In the field, it is already supporting a new generation of applications. Faster processors, increased bandwidth, standardization, and better implementations have all contributed to the evolution of today’s browser engines into full-fledged application infrastructures. HTML5 has even become the lingua franca for all browsers.

HTML5 runs within browsers on virtually every user-facing computer, whether it’s a desktop, smartphone, or tablet. It is, by definition, “connected” to the power of the Internet and cloud-based services, and with recent innovations, it can run in standalone “browser containers” that mimic traditional desktop applications without being resource-heavy. It supports all the key media types, from PDFs to streaming video. It is extremely stable, secure, and requires no updates.

Along with its siblings, CSS and JavaScript, HTML5 can build 99% of today’s applications. Only the outliers with extreme requirements are better-suited for native environments when it comes to cross-device GUI-based applications.

If you aren’t using HTML5 to build user-facing applications, we encourage you to compare it to what you are currently using. Interested in learning how legacy technology is changing the industry? Continue reading to learn how HTML5 is more necessary than ever. The Promise of HTML5

Interactivity

HTML5 is, at its heart, interactive. When managing and analyzing large amounts of data, users need interactivity. It’s important to have the ability to zoom in and out, swipe, and move around quickly as a trader on any device.

This kind of interactivity was difficult to achieve with legacy technology, not only because it put an extreme burden on the developer to build it, but also because

3 some of the tools developers were leveraging were not meant to be dynamic. They used static charts like infographics, which are useful in demonstrating 90% of data, but the other 10% that’s super critical and financial required tools that were not available. Now, with HTML5 and ChartIQ, you have a technology and a tool that’s interactive and much better for traders and analysts who need to understand their data.

Improved Interface

HTML5 offers the ability to build powerful user interfaces that break the old paradigms. Because HTML5 is so flexible, it can accommodate any interface, giving developers freedom and agility. Programmers can build an interface that actually solves the problem rather than trying to cram a problem into a pre-existing interface. The end result? Businesses that use HTML5 have happier customers and better user experiences across the board.

For the financial space and capital markets, especially—it is all about moving quickly. Paradoxically, the financial space has been held back by heavy legacy technology, always at least five years behind and trying to get to the new stuff.

JavaScript, a fairly newer language, sounds very lightweight, but it’s not. It’s an extremely powerful language, though it’s not difficult to learn. Even a novice developer can create interactive websites using JavaScript because it is so easy to understand. On the other hand, JavaScript offers powerful architectural tools for hardcore developers, which enables them to program incredible solutions. JavaScript is the first language that has been able to cover ground from simple scripting to deep architecture.

When most people think about HTML5, they think of it running in a browser, but the reality is that HTML5 is everywhere—it’s pervasive. You can run HTML5 in a mobile app, a Java app, and a .Net app. HTML5 is the solution that is moving technology forward, which is why ChartIQ’s product portfolio is built completely in HTML5.

4 | The Bridge to HTML5 Back to Table of Contents DATE PUBLISHED Sept 6, 2016 Integrating HTML5 Into Your AUTHOR Terry Thorsen Technology Stack

Many developers today—as many as 37%—are not implementing HTML5 at all or only somewhat in their applications. Since being declared the W3C standard in 2014, HTML5 has become popular for many reasons. However, the complete transition to HTML5 for many developers still seems daunting.

ChartIQ outlines why it uses HTML5 to build its data visualization products and how it has overcome obstacles below. Containers: Building HTML5 Desktop Applications With the advent of HTML5, it is now possible to build uncompromising business applications in the browser. The introduction of the HTML5 API narrowed the functionality and performance gap between browser and desktop applications by providing a high-speed canvas for data visualization, WebSockets for streaming network communications, a file system API, and more. The list of advantages continues to grow.

Given these advances, the “last mile” for HTML5 is to gain the capability of acting like a true desktop application that is indistinguishable from native applications. Embedded Framework (CEF) is the technology that makes this possible. CEF essentially allows native applications to embed a Chrome browser into their UI in a way that is seamless and invisible to the end user. Thanks to innovations from a few brilliant companies, this technology has been abstracted so that it can now be easily leveraged to build new desktop applications and to extend existing applications with HTML5 functionality.

5 Why HTML5? This all sounds great, right? But only if you’re first convinced that HTML5 offers a unique advantage over traditional programming methods. Native coding (Java, .NET, Objective-C) is alive and well, but it is now generally understood that the HTML/CSS paradigm is usually simpler, quicker, and more flexible than traditional native approaches. HTML’s evolution was primarily driven by graphic designers who required flexible layout and complete control over aesthetics in order to build beautiful, mostly print-inspired web pages. The Document Object Model (DOM) and Cascading Style Sheets (CSS) evolved to meet these needs. These technologies were well established by the time browsers gained the ability to present dynamic content. Manipulating graphic design disciplines has resulted in the dynamic content and interactivity we know today, lush with interfaces that can simultaneously offer power and simplicity.

In addition to the UI design and layout advantages offered by HTML5, JavaScript itself has become today’s dominant programming language. A vast ecosystem of tools, frameworks, cloud services, and sample source code have emerged, putting JavaScript programmers in an enviable position— one that may have been unimaginable just a few years ago.

Development speed has accelerated. Plug-and-play interoperability has transitioned from dream to reality.

The benefits of adopting HTML5 for new functionality, particularly UI, are compelling. The questions of how to apply an HTML5 strategy to the desktop and how to leverage the benefits in the context of legacy desktop applications have been answered by what’s now known as the “container.”

Going “All In” With Containers Using Containers for Your HTML5 Build Builders of new applications can consider going all in by starting their projects with an HTML5 “container.” A container is a platform that embeds Chromium into a native shell so that a developer doesn’t need to actually write any C++ to build the native app. The two predominant containers are Electron and NW.js. NW.js has been around a bit longer and has a slightly deeper API, but Electron (which was created by GitHub) is quickly becoming the container of choice, spurred by a large community of contributors and evangelists, below.

6 | The Bridge to HTML5 For financial applications, the company, OpenFin, offers a particularly robust solution. OpenFin provides a container environment that is based on Electron but is further abstracted to solve problems specific to the financial industry, such as deployment, security, and interoperability with legacy applications. The “last mile” is a bit longer for financial desktop applications.

Once inside an HTML5 container, developers can essentially write applications the same way they write for browsers, but they gain access to an additional API that allows window manipulation.

Applications built in containers look and feel like native desktop apps. They can interact with the taskbar. They can run across multiple monitors. They can have floating windows and “launch pads.”

Container applications built with OpenFin arrive as an EXE installer; simply double click to install. Fortunately, though, application logic (the HTML5) can still be hosted on the web so that users can gain access to updates without ever needing to re-install or press an “update” button—the same benefits as browser-delivered applications.

Here at ChartIQ, we’ve built a desktop application using OpenFin. The display is beautiful and performance is fast. Along the way, we’ve developed architecture that AAPL addresses some of the common issues related to building desktop-based HTML5 applications. Workspace capability and bus communications (to coordinate and pass information between windows) are being assembled in a library we have dubbed FinSemble. We plan to make this library available in the coming months for others who are building complex financial applications in HTML5. Best Of Both Worlds: Java and .NET Not every firm has the option (or the desire) to build applications from scratch in HTML5. A legacy application written in Java or .NET might contain millions of lines of trusted, tested code and a significant deploy base that expects a steady, stable upgrade path. Even if the desire does exist to move to HTML5, reality and prudence may stand in the way of embarking on a massive rebuild.

Luckily a middle ground does exist. Today, all native UI frameworks provide what is called a WebView, which is essentially a native UI control that embeds a browser into an application (, .NET, etc.). The native code can then interact bidirectionally with the WebView, allowing developers to build new functionality in HTML5 within the context of a legacy application. In the mobile world, this is called a “hybrid app” and has become quite common, though it’s just starting to catch on in the desktop world.

7 OpenFin and TeamDev both provide commercially supported libraries to embed Chromium into native applications. OpenFin for Java & .NET, JXBrowser for Java developers, and DotNetBrowser for .NET developers provide the same advantages as Electron and NW.js. They are based off of Chromium, providing a consistent, reliable, and high-performance HTML5 container.

We generally recommend using a commercial product, even when a native WebView is available, because pure Chromium has a better performance profile and commercial libraries provide a simple, easy-to-use interface. In short, commercial products take all the guesswork out of including HTML5 in desktop applications.

With this hybrid approach, firms can establish a bridge from legacy applications to pure HTML5 container-based applications. They gain access to the wide array of JavaScript-based software and services that are available. Product managers can evolve their solutions using HTML5 without the risk of undertaking a major replacement project. This is also great news for Java and .NET development teams as it allows them to dig in and learn HTML5 in a safe, limited context without having to completely re-invent everything or the way they code overnight.

A unique example of leveraging containers to extend an application can be found in Thomson Reuters’ Eikon product. Eikon is a powerful market data terminal that can be found on thousands of professional desktops. The core application is written in C++, but most UI components are written in HTML5 using the very container strategy we’ve described.

Thomson Reuters has taken things one step further by opening up its container to third parties and providing an API to access the application’s internal data. This strategic decision delivers on the promise of HTML5—applications from disparate sources can be easily combined into a comprehensive and congruous user experience. Without HTML5 containers, such integration would require a degree of coordination and exposure that is almost unthinkable in a financial application.

For firms that use Eikon, it is now possible to write custom applications driven by the market data that they already rely on. Development and deployment in such an environment can be quicker than a custom build since problems of authentication, infrastructure, data management, entitlements, and deployment have already been solved by the container.

HTML5 containers make work easier, but they do not make things better automatically. Developers will need to rethink design and technique so they don’t end up creating a browser window with little to no functionality.

8 | The Bridge to HTML5 Back to Table of Contents 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. 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.

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 is 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. We are launching our Technician market data product based on OpenFin™, and we have integrated our charts into Thomson Reuters Eikon™ terminal. 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 Charting Library equips financial firms with the ultimate solution for building desktop applications their users will love and adopt for years to come.

9 DATE PUBLISHED JavaScript Charting Aug 11, 2016 AUTHORS Libraries: HTML5 Canvas Hanni Chehak Dan Schleifer Element Vs. SVG

In the development and build-out of our core product (a JavaScript charting library built for capital market applications), ChartIQ weighed which technology would deliver the best performance for our time-series charting library and why.

The introduction of HTML5 gave us two new options for graphics technologies and the promise of being able to create graphics directly in HTML5 (goodbye workarounds of Flash, Silverlight, and Java!). Our goal was to build a charting library that was as visually immersive as possible, while still providing the end user with a continuous in-app experience. We weighed both options—SVG & HTML5 Canvas—and here’s what we discovered.

Scalable Vector Graphics (SVG) gave us what initially looked liked advantages: SVG is easy to understand and as part of DOM, every object is represented on the screen. Everything from CSS styling to hover-and-click state manipulation, as well as iteration through the DOM is simple. SVG also made printing advantageous because SVG is vector-based and, therefore, has the ability to infinitely scale. SVG also offers easy-to-style animation and convenience features with the look and feel one would expect from a modern HTML5 application.

In comparison, HTML5 canvas was raw and pixel-based. If you’re old enough to know what programming on the Atari 400 was like, the HTML5 canvas is reminiscent of those days, according to our CTO (we swear that wasn’t our deciding factor in choosing canvas). The HTML5 canvas element is simply a large XY grid of pixels that gives the developer freedom to decide everything. Initially, we thought it felt very rudimentary, but we quickly changed our minds, and here’s why.

We needed the ability to render huge amounts of data quickly and with fluid user interaction (panning, zooming, etc.). When we evaluated performance, we found that SVG performance degrades logarithmically based on the number of objects that run on the screen.

Canvas on the other hand, had high performance and was able to handle real- time mathematical operations and animations. Canvas degrades linearly based on the number of pixels that are in the canvas (rather than logarithmically, based on the number of objects). Imagine building for something like the iPad with

10 | The Bridge to HTML5 retina display. You have a relatively low-performance CPU and GPU, but you also have a lot of pixels. This is your worst-case scenario and one, which you can optimize for in advance.

With SVG, if you have 10, 50, or 500 objects on the screen,performance is stable, but the moment that you have 1000, 5000, or 10,000 objects on the screen, the SVG grinds to a halt. This is great for pie charts, bar charts objects, and the occasional scatter plot, but it is not performant enough for real-time financial charts with thousands of data points.

We love games at ChartIQ and were inspired by the game developers process to build out our data visualization engine.

Desktop and console games were always coded in C++ for maximum performance. If you play a game on the web, a phone, or a tablet, chances are it’s been built on top of the HTML5 canvas. Why? Because the companies that build gaming engines realized that only the canvas— not SVG—could handle the performance requirements of immersive video games.

Game developers don’t start with the raw canvas though; that would be like mining for minerals before building a skyscraper. Game developers build on top of gaming engines that handle all the complex functions required for building great games: physics, layout, sprite animations, levels, and all the rest. Depending on what kind of game you want to build—a side scroller vs. a first-person shooter—you would choose the most appropriate gaming engine. This is how game developers are able to focus on building the game engine they want to build, rather than wasting time building out the physics engine that underlies it.

We wanted to provide this exact same environment and experience to developers who are building the next generation of financial applications. Developers can now focus on exactly how they want to build their application - the user experience and workflow - knowing they have a supercharged charting engine under the hood.

11 DATE PUBLISHED Why Should Developers Use Nov 15, 2016 AUTHORS JavaScript Modules? Brad Carter

Packaging HTML5 HTML5 is powerful, expressive, and expansive. It does exactly what it was designed to do: describe the structure of web pages.

But you can’t create an interesting web application with HTML5 alone. Most developers want to create immersive, interactive experiences; and you can’t do that without JavaScript.

Loading external files is so commonplace, that you might be wondering why we’re talking about the different ways to load them. We certainly don’t dictate the way our clients use our software. Some of our clients use Webpack, Browserify, or Gulp/Grunt, while many others simply include our files with old-fashioned