openfintech-blog

[openfintech-blog]

The OpenFin Blog has moved!

To see new updates please go to https://openfin.co/blog/

[openfintech-blog]

Introducing Hypergrid: It Will Blow Your Mind

How do you display a peta-size data-set in a grid with smooth scrolling and no-deferred-painting?  What if you have thousands of rows of data that update at over 1000 times per second?  In the past, the solution to these design challenges wasn’t HTML5.  Today, we’re excited to introduce you to Hypergrid, a new HTML5 component that is faster and more performant than any of its native ancestors.

Hypergrid is a grid component that supports unlimited data set sizes while maintaining constant, ultra-high performance.  We built it using traditional graphics programming techniques that are not often used in the HTML5 world outside of gaming engines.

There are two broad use cases that Hypergrid addresses:

Big Data: An enormous amount of data (1 million to 1 quadrillion+ rows) that does not update frequently

Dynamic Data: A smaller amount of data (~10,000 rows) that updates with very high frequency (~1,000 times per second)

To meet financial industry requirements, Hypergrid supports these basic requirements and, in addition, allows for:

Smooth scrolling

No deferred painting

Hundreds of columns

Sorting and grouping

Excel-style keyboard control

Remote data sets

Rich, HTML-based, editors

Real-time, live-ticking spark lines on every row

When you see it in action, it becomes clear where the "hyper" comes from.  It's intense - user experience and performance far superior to anything you've seen even in native languages like C++, Java and .NET.

Hypergrid is currently in private alpha.  If you want early access, please send us an email at support@openfin.co.

To see a live demo in-browser (Chrome, Safari, Firefox, IE10+), click here : http://openfin.github.io/fin-hypergrid/components/fin-hypergrid/demo.html

To see a live demo in OpenFin (Windows-only), run this installer:

https://dl.openfin.co/services/download?fileName=hypergrid-demo-installer&config=http://openfin.github.io/fin-hypergrid/components/fin-hypergrid/demo.json

Hypergrid is using some pretty sophisticated techniques to achieve all this performance.  To abstract the complexity and simplify development, we wrapped it up as a modern, polymerized (https://www.polymer-project.org/), fully encapsulated, web component.  If you have a dataset in JSON, you will be able to get it into Hypergrid in under a minute.  If your data is in a kdb+ database, you can point the grid’s data behaviour right at it.

We are already getting great feedback from early access developers and we're open-sourcing Hypergrid early next year under a friendly (MIT-style) license.

For more information about OpenFin:

Visit: www.openfin.co Blog: blog.openfin.co Contact: info@openfin.co Twitter: @openfintech

[openfintech-blog]

Fat Client - Extreme Makeover

If you're bemoaning the sorry state of your bloated fat client financial application, don't worry -- you're in good company.  It's a common problem that goes something like this.

Years ago, someone built the application in Java, WPF or C++.  At the time, it was slick and everyone loved it.  As requests came in, features were added and the application got more and more complex.  Institutional customers started asking for customizations and suddenly there were multiple versions of the same application.  Development got harder and product release cycles got slower.

The original guys who wrote the application moved on to greener pastures.  The new guys, shocked by what they inherited, first tried to rewrite the whole thing but realized they couldn't.  The rewrite would take 18 months or more and no one was going to green light the budget, especially with so many new urgent requests in the queue.

What to do?  By now you've likely heard us (and others) talk about the benefits of building front-ends in HTML5.  Development is faster, performance is better and applications are mobile-ready.  A wide consensus has formed in the financial industry that it is the right choice for UI development.  So how do you get from there from here?

Simple.  With OpenFin, you can start migrating to HTML5 without having to rewrite your whole application.  Here's how:

Include an OpenFin API adapter in your existing fat client application.  We provide libraries in Java, C# and C++.

Use the API to invoke the runtime and launch a new HTML5 window from within your fat client application.

Use the API to create a seamless experience between your fat client application and the HTML5 window, including two-way data sharing and window-docking.

With this approach, new modules that you write in HTML5 look like they are just part of your fat client application.  Done right, the user can’t tell which part of the application is HTML5 vs. Java / C# / C++.  This allows you to do a phased migration where you can write new components in HTML5 and, over time, you can rewrite old components of the fat client application until it becomes completely thin.

Several major financial services platforms are using OpenFin to give their fat client applications an extreme makeover.  In one example, a firm extended their existing application to add a new high performance charting module.  The charting component is provided by ChartIQ, an industrial-strength HTML5 charting engine.  ChartIQ’s “trade-from-the-chart” capabilities allow a user to visually manage complex multi-leg orders.  The limit order details are passed to the core execution logic in the fat client application using OpenFin’s inter-application messaging bus.  The user experience is seamless and the development time to deliver the functionality was a matter of weeks. 

For more information about OpenFin: Visit: www.openfin.co Blog: blog.openfin.co Contact: info@openfin.co Twitter: @openfintech

For more information about ChartIQ: Visit: www.chartiq.com Twitter: @chartiq

[openfintech-blog]

4 Things HTML5 Can Do That Will Surprise You

Traders, salespeople and other front-office users are among the most demanding power users of applications in the world.  Whether it's performance, scale or ergonomics, these users' requirements and expectations are at the very top end of the spectrum.  So the conventional wisdom has been that HTML5 can't satisfy these users -- "it's not ready for prime time."

The reality is that, for financial use cases, HTML5 can now do everything that Windows Presentation Foundation (WPF) can do (and more) on desktop and that iOS or Android can do on mobile.  Everything.

Here are four things that you might think HTML5 can't handle (but it can):

1. Charting Huge Data Sets Sure, a simple or even somewhat complex financial chart works fine using HTML5 frameworks like HighCharts or D3, but what if you need to plot 5 years of data for 125 investment grade names on the same chart?  Suddenly things start to become sluggish or break down altogether.  Zooming is slow, scrolling is painful.  You can only do this with a native application right?

No longer true.  A new HTML5 charting engine called ChartIQ has solved this for the industry.  Throw in your huge data set, manipulate it, zoom in, scroll the time series.  It's buttery.  Native has nothing on it.  In fact, good luck creating the same visualizations easily with a native charting package.

2. High Performance Grid The other quintessential financial widget is the grid or table.  HTML, of course, handles grids and HTML5 frameworks like SlickGrid make it possible to scroll relatively smoothly through even large datasets.  But it's not native performance.

If you need a grid with 10,000 rows, 300 columns and you're doing 1000 price updates per second while sorting and filtering, SlickGrid will struggle as will the other HTML5 frameworks out there.  But we're pleased to tell you that this is no longer an HTML5 limitation.

Our engineers at OpenFin have developed a new grid up to financial industry specs that provides native performance.  It can handle an unlimited number of rows, hundreds of columns, over 1000 price updates per second and it scrolls as smoothly as native.   Scroll fast, yank the scroll bar up and down, filter, sort -- it's as fast as anything you can do with native.  And we're going to be open-sourcing it next month.

3. Mobile One of the biggest concerns around HTML5 is with mobile.  Most people are convinced that a native iOS or Android app is faster and slicker than an HTML5 app.  We put that theory to the test recently working with a large investment bank.  The project was to replicate an existing iOS app in HTML5 so that it would work on both iOS and Android.

The bank was convinced this was not possible so we were told "we don't expect you to fully replicate the experience but we need you to come close."  Our engineers not only replicated the app but the only way to tell the difference between the iOS version and HTML5 version is that the HTML5 app is slightly faster!

We used Cordova to wrap the HTML5 so that it could be placed in the App Store, but otherwise did not need the native wrapper for anything else.  What we found in the development process was that specific techniques were needed to get native performance (stay tuned for our blog on this). But the effort was worth it because the app is truly cross-platform and as beautiful as any native iOS app.

4. Desktop Desktop presents multiple challenges for financial applications.  First, most financial users have a legacy web browser that doesn't support HTML5.  This will get resolved over time as firms upgrade to Internet Explorer 11 and install Google Chrome more widely.  More importantly, trading applications and other applications currently being built in WPF or Java don't want to be constrained by the user experience of a web browser (not even Chrome).  These applications require a multi-window, multi-monitor experience that enables efficient use of screen real estate.

At OpenFin, our core mission has been to solve this problem for the industry.  Our HTML5 runtime enables firms to build with HTML5 and have all the capabilities of native WPF and Java applications.  The advantages of this model are game-changing for front-office desktop applications: faster development, no installation, better performance, better user experience and better security.  To top it all off, the desktop applications you build are cross-platform and can run on mobile devices.

Conclusion HTML5 has been evolving quickly with enormous investment from Google, Apple, Microsoft and many others.  Whether you need high performance charts or grids or you need native experience on mobile and desktop, HTML5 is not just ready for prime-time, it’s redefining what prime-time means.

For more information: Contact us at info@openfin.co. Follow us on Twitter: @openfintech

[openfintech-blog]

Yo OpenFin!

We are happy to announce our own Yeoman generator, focused on reducing the amount of configuration and setup for an OpenFin application. The OpenFin generator creates a configured and self-hosted application that is framework agnostic and ready to be extended. If you have not heard of Yeoman, let us introduce you -- its been embraced as the de-facto scaffolding solution for modern web apps.

What do you get?

The OpenFin generator provides a build system using Grunt that lints, styles, and serves the code. Additionally, it runs the OpenFin runtime, HTML5 boilerplate, Bootstrap and the OpenFin Javascript adapter. The generator is open source and can found in Github, the installation and usage instructions are can be found on the project read me. 

Yo - Get it now!

 OpenFin generator

Questions? 

Get in touch with us at: support@openfin.co

[openfintech-blog]

Introducing the Svelte Client

When building a front end desktop application, one of the first decisions developers make is whether to build a thick client or a thin client. For those not familiar with the terminology, "thick” or “fat” client refers to a native, installed application. The languages most commonly used for this are Java, .NET or C++. A "thin” client typically refers to an application that runs in a web browser and is not installed. These are usually developed using HTML5, Flash or Silverlight.

What’s the reason for the terminology? With thick client applications, much or most of the application logic is in the front end application, resulting in more code and therefore a bigger download. With thin client applications, a significant amount of the computing is done on the server side, resulting in less code in the client.

The thick vs. thin choice usually boils down to an application’s requirements for user experience on the one hand and ease of installation and upgrade on the other. Thick clients provide great native experience but come with installation and upgrade overhead that is particularly problematic for enterprise users with locked-down desktops. Thin clients are easily accessible from a web browser but are limited in the user experience that they can provide because they are constrained by the web browser.

It is now possible to have the best of both worlds - great native user experience without the overhead of installation and upgrade. To do this, a developer builds the application using a thin client technology (preferably HTML5) and puts the application in a native wrapper or container such as OpenFin. This enables a light-weight deployment and extends the application’s capabilities beyond the constraints of a web browser. Some people call this a “hybrid” client. The problem with this terminology is that most people don’t know what it means. We think it would more accurately be called a “svelte" client (let’s see if that catches on).

Why “svelte”? The “thick” vs. “thin” distinction captures only the amount of code in the front end application and whether or not it is installed. “Hybrid” suggests a combination of the two but says nothing about the real value proposition. The svelte client is about a light-weight deployment together with amazing user experience(i.e. slender and elegant).

So the next time a developer is considering thick vs. thin, tell them there’s no need to compromise anymore. What they need is a svelte client. They’ll get what you mean.

[openfintech-blog]

10 Things CEF and NodeWebkit Don’t Do

Firms often ask us how OpenFin compares to other Chromium-based products including Chromium Embedded Framework (CEF) and NodeWebkit.  Here’s what we tell them:

At a high level, OpenFin provides a complete, finance-ready app container while products like CEF and NodeWebkit provide building blocks for those who want to build their own app container.

CEF: Embed a Chrome window control in an existing app container

NodeWebkit: Enable Node.js support and provide native UI capabilities

Essentially both products provide you with a great Chromium engine but leave you to do 80-90% of the work to build your own app container.  And they’ve made some things much harder.

Both NodeWebkit and CEF integrate with the Chromium code using the Chrome Content API.  This API was mainly introduced to make testing easier for those working on different 

parts of the Chromium code, but it means that with NodeWebkit and CEF, your developers have to spend time re-implementing key, powerful features that have already been built and well-tested by Google’s engineers!

OpenFin, on the other hand, is built using the Chrome extension system and can leverage all the advanced features available in the full Chrome browser.  This was the primary driver for OpenFin to move away from CEF last year and to work directly with the full Chromium runtime build.

Here is an abbreviated list of OpenFin features not provided by CEF or NodeWebkit:

Installers for running and auto-updating on locked-down computers

Multi-process architecture for performance and security

Client-side message bus to securely share data and context

Adapters for integration with .NET / C++ / Java / Flash apps 

Window animation, transparency, docking, tear-out and frame-removal

UI implementations for authentication challenges and SSL certificates

Group policy manager integration

API support for memory, processor and cache management

Self-hosting of Google Platform Apps

Enterprise support and SLA

The work involved in building these features is not only significant but must then be maintained on an ongoing basis as new versions of Chromium are released by Google (every 6 weeks).  The last item, enterprise support, is often the biggest concern for any bank or financial services provider.  When there are problems, there is no one to call.  For mission critical systems, that is a deal-breaker.

For more information, please contact us at info@openfin.co

[openfintech-blog]

BA Doesn't Build Planes and You Shouldn't Build an App Container

In the financial industry, HTML5 has rapidly become the new standard for real-time desktop applications.  A second and related trend has also emerged.  Instead of using web browsers, financial firms are often deploying their HTML5 code in application containers or app containers.  HTML5 app containers eliminate the dependency on a user’s web browser and enable a native, outside-the-browser experience that is crucial for front-office applications.

Firms looking to deploy their HTML5 applications in an app container are faced with a basic build vs. buy decision: should they build their own Chromium app container or use OpenFin?  For those who choose the build option, there are a number of frameworks that make the job easier, the most prominent of which is Chromium Embedded Framework (CEF).  Other options include Awesomium and NodeWebkit.

While these frameworks make it easier to work with Chromium, they each have their downsides and most importantly, they each leave you to build 80-90% of your app container from scratch.  Credible estimates usually have a small team of experienced developers working for a year to build a production-worthy first version app container with CEF.

For non-technical managers (and even many technical ones), it's hard to quantify the effort involved and sometimes an analogy is helpful.  Imagine the app container you are trying to build is a jumbo jet and your apps are the passengers.  In this analogy, CEF is the airplane's engine.  You're not going anywhere without an engine but your airplane also needs a cabin, wings, propellers, wheels, seats, lighting and much more.

Would you build an airplane yourself if you could source a great commercial engine?  British Airways wouldn't and neither would any other airline.  They know there's no competitive advantage in building their own planes.  Instead they compete on brand, network, airport real estate, service and price among other categories.

Similarly, for banks and financial service providers, there is no competitive or strategic advantage in building your own Chromium app container.  Firms compete on their brand, apps, content, analytics, liquidity, risk models, user base, service and price among many other categories, not the container facilitating the deployment.

Do CEF and other Chromium frameworks help reduce the cost of the build?  Yes, but they still leave you to do most of the work yourself and they provide no support along the way.  If you need a complete, industrial strength HTML5 app container with an enterprise-grade SLA, please give OpenFin a try.  Contact us at info@openfin.co.

[openfintech-blog]

5 Reasons Why HTML5 is the Right Choice

In speaking with firms across the financial industry, we’re often asked why they should use HTML5.  We’re not HTML5 purists and we’ll be the first to say that there are times when HTML5 is not the best choice.  But for real-time financial desktop applications (e.g. trading, market data, single dealer platforms), HTML5 is now usually the right choice versus WPF, Java, Flash, Silverlight and other front-end technologies.  In fact, many of the largest banks and financial service providers have already selected HTML5 and many have either already deployed or are in active development.  

Here’s why.

#1 Cross Platform

Even 5 years ago, the only platform you needed to target was a Windows desktop.  Today, the list includes Macs (for home use and increasingly at work), iOS and Android.  When it comes to cross-platform, there’s no technology other than HTML5 that is even in the conversation.

#2 UI Performance

A common complaint about HTML5 has traditionally been performance.  Now, thanks to investment by Google, Apple, Microsoft and others, HTML5 provides direct and easy access to hardware accelerated animations and transitions that are more performant than Flash, Silverlight, Java and WPF.

#3 Faster Development

Developing front-ends with HTML5 is ridiculously easy compared with other technologies.  This is due to the nice separation between layout, styling and application logic inherent in HTML5.  It’s also because of the large and growing number of open-source frameworks that help with everything from code organization, to widgets to automated testing.

#4 Cost of Maintenance

Today’s college graduates don’t know Java, WPF or Flash and they have very little interest in learning.  Talent is already migrating to HTML5 and, as time goes on, it will be harder and more expensive to find developers willing to code in older technologies.

#5 Future Proofing

Many firms who are regretting their decision to use Flash or Silverlight don’t want to be burned again.  “How do we know this isn’t just the latest fad?”  It’s not.  Google, Apple and Microsoft are all heavily investing in HTML5 and future desktop operating systems will provide native support for HTML5 the way mobile operatings systems already do today.  For the next 7-10 years, HTML5 is the safe bet.

Not convinced or have a use case you think HTML5 can’t tackle?  We’d be happy to discuss it with you live.

[openfintech-blog]

Use NodeJS or Waste Money

You are wasting time and money if you are not leveraging at least some of what NodeJS has to offer these days when it comes to your JavaScript project. There was a time when NodeJS and its package manager NPM, in a more incipient stage, could be dismissed as just another cool JavaScript project. Its event-driven non-blocking nature made it great at doing networking stuff right from the beginning. NodeJS has since grown into something far more than just a simple network file server. The productivity software that has been built in NodeJS has extended its reach and made it increasingly indispensable from both a productivity and business standpoint.

  Why should you invest time on a JavaScript build process? 

Without a doubt the tide has turned from server side MVC to client side MV*. We find ourselves writing JavaScript that is far more complex than ever before as more logic shifts out to the client. This is both a blessing and a curse. As a language, JavaScript is expressive and adds little friction to the development process. The downside, especially for developers coming from a languages such as C# and Java, is that JavaScript does have some major flaws (The Good Parts) and anti-patterns. Mistakes that a Java developer can expect to be caught at compile time now build just fine and can be hard to debug later. 

Choosing not to waste time with a NodeJS powered JavaScript toolkit. 

With a language that is as dynamic as JavaScript, enforcing best practices becomes critical on any project of size. Things that we should all be doing, but in the past were just such a pain to set up such as linting, minification, concatenation, maintaing a build and src directory, handling dependencies responsibly and running tests now come free and easy.

NodeJS projects such as Grunt and Yeoman have masterfully addressed the pain points associated with many of the previously mentioned processes. For example, setting up all of these things for an AngularJS web app with Yeoman is a simple as entering ‘yo angular some_great_name’. Thats it. You'll get all the above along with a live development environment courtesy of a built in NodeJS server that updates every time you save a project file. Whether you want a quick proof of concept or are seeding a production application, this is the way to do it.  

NodeJS has grown into an ecosystem of projects and tools that is too useful to be ignored. You can still choose to roll your own scaffolding, linting, sockets, dependency injection, testing, etc, but at this point you would just be choosing to waste time.

[openfintech-blog]

Angular or Ember? We think Angular.

We are frequently asked to recommend an HTML5 framework for building single-page web applications in the Enterprise. Sometimes answering that question well requires a deep understanding of the problem that the person is trying to solve and sometimes there are a handful of perfectly good choices but usually there aren't. Nearly every time we recommend Angular.

Here is why:

Google Trends: Angular vs Ember vs Backbone vs Sencha

With a solid foundation of support from Google and a steadily growing community, Angular has what it needs as an open source project to be successful for quite some time. Beyond the strong foundation and community what is it about Angular that we like so much?

Plays nicely with other libraries

Extensibility

Componentization and code reuse

Testability

Plain old JavaScript Objects

Caveat emptor - we have not done much with Ember in anger as of yet - Alex Matchneer (@machty) of the Ember.js Core Team and author of Emblem.js put together this deck that does a great job of highlighting the differences in approach: 

Angular.js from the perspective of Ember.js

From the deck:

"[Ember is] a framework for creating ambitious web applications" - Ember.js Homepage

"AngularJS is a toolset for building the framework most suited to your application development." - AngularJS Homepage

This is a key point. Angular is targeted at helping you build a framework that you then use to build applications whereas Ember is more prescriptive, with lots of conventions, different classes, inheritance, and non-pojo data models. In an Enterprise setting, the Angular approach is very in line with how we generally think about things.

Does this mean Ember is a bad choice? No, not quite. Ember looks like a great framework with a solid approach and a growing community - we are interested in keeping an eye on it over time. It is possible that it is ideally suited to your needs - it is not yet clear that it will be able to thrive in the Enterprise.

So we aren't anti-Ember but there are other things we actively recommend staying away from - the mega-frameworks like Sencha/EXT.JS and GWT - these all encompassing frameworks generally abstract away too much, add significant overhead, and put you in a position where achieving that last (but required) 10%-20% is nearly impossible. Even worse is the fact that they don't generally play well with other JavaScript libraries.

[openfintech-blog]

What you need to know about Chrome and Firefox dropping Silverlight/NPAPI support

Chrome and Firefox are dropping support for the NPAPI which is what powers Silverlight, the traditional Flash plugin, the Java plugin and many others. They are expecting you to reengineer your code rather quickly if your users use their browsers. The NPAPI will be turned off by default in FIreFox in early in 2014 and by December 2014 it will have been removed from Chrome entirely.

You can read about their approaches here:

Chrome - Saying Goodbye to our Old Friend NPAPI http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html

Firefox - Plugin Activation in Firefox https://blog.mozilla.org/futurereleases/2013/09/24/plugin-activation-in-firefox/

This is generally a good development for the consumer internet but a very tight timeline for enterprises to swallow. Silverlight, and other legacy plugins will no longer be able to run in the most modern browsers - Flash continues to work in a limited way via the Pepper API in Chrome but has significant performance limitations and different behaviors than the NPAPI plugin. And Firefox is building a Flash emulator in JavaScript (Shumway - https://github.com/mozilla/shumway) for its support of Flash in a post-NPAPI world. None of this is ideal if you have infrastructure that relies on these technologies.

So why are we talking about it? OpenFin will continue to support the NPAPI after Chrome/Chromium have removed it entirely from their codebase. Our enterprise customers have complex environments that often contain components that are challenging to migrate - we provide them certainty going forward that they can migrate on their own timelines.

So if you need a blazing fast HTML5 runtime that can continue to support the NPAPI going forward please contact us.

[openfintech-blog]

Things you should know about Google Packaged Apps

Last month Google officially released its Packaged Apps initiative for the Chrome browser.  At a high level, Packaged Apps enable traditional web apps to behave more like installed, native applications.  While this is an important innovation in web technology, Packaged Apps have significant limitations when it comes to financial industry needs.

What are Packaged Apps?

Packaged Apps are HTML5 apps that give you the deployment of traditional web apps and the user experience of native applications. Packaged Apps grant your applications access to the native windowing environment and to OS-level functionality like the file system, displays, memory and sockets.

Packaged Apps - Key Features (from Google's blog)

Work offline: Keep working or playing, even when you don’t have an internet connection.

More app, less Chrome: No tabs, buttons or text boxes mean you can get into the app without being distracted by the rest of the web.

Connect to the cloud: Access and save the documents, photos and videos on your hard drive as well as on Google Drive and other web services.

Stay up-to-speed: With desktop notifications, you can get reminders, updates and even take action, right from the notification center.

Play nice with your connected devices: Interact with your USB, Bluetooth and other devices connected to your desktop, including digital cameras.

Keep updated automatically: Apps update silently, so you always get all the latest features and security fixes (unless permissions change).

Pick up where you left off: Chrome syncs your apps to any desktop device you sign in to, so you can keep working.

Sleep easier: Chrome apps take advantage of Chrome’s built-in security features such as Sandboxing. They also auto-update to make sure you have all the latest security fixes. No extra software (or worrying) required.

Launch apps directly from your desktop: To make it quicker and easier to get to your favorite apps, [Google is] also introducing the Chrome App Launcher for Windows, which will appear when you install your first new Chrome App. It lives in your taskbar and launches your apps into their own windows, outside of Chrome, just like your desktop apps. Have lots of apps? Navigate to your favorite apps using the search box.

Given all these features, Packaged Apps is clearly a compelling offering for many developers looking to improve the user experience of their consumer web apps.

   What are the limitations for Wall Street?

While Google may be suitable for consumer applications, firms who deploy business-to-business applications to financial desktops may find the heavy integration with Google’s services too invasive or inappropriate for enterprise settings, especially in locked-down security environments such as those encountered in finance.

Because Google’s larger strategy to displace Windows with Chrome OS and to attract more users to their search, payment, storage, mail and authentication services, Packaged Apps include some strings that may be a concern for IT administrators. For example:

Users must have Chrome: The vast majority of financial users have either IE6, 7 or 8 on their desktops and aren’t permitted to run Chrome. This will change over time but is likely to remain a problem for at least the next few years.

Users must have a Google Account: In order to access the Chrome App Launcher, the user must be signed into a Google Account which most financial users don’t have for work. In fact, many finance firms even block their users from logging into Google.

Security and privacy concerns: Use of a Google Account for work raises additional concerns over security and privacy of confidential information.

Your application code must be hosted by Google:  There is a way around this but it requires your end user’s firm to white-list your application in their Group Policy Manager which creates additional overhead.

User-managed application privileges: During installation, the end user can provide the application with privileges to access resources outside the security sandbox.  This creates a security concern for most financial institutions.

In addition to these challenges,

Advanced windowing: Packaged Apps lack the ability to perform window animations and to break up the GUI into separate dockable components to support interactions commonly needed by financial applications.

Client-side messaging: While Packaged Apps allow local point-to-point messaging between applications, they don't support a local publish-and-subscribe model which is an important use case for real-time data (e.g. in order to stream prices to Microsoft Excel).

End-of-Life for NPAPI: Google just announced that they will start End-of-Life for the NPAPI just 3 months from now and that it will have removed it completely by the end of 2014

Discontinued support for Flash and Silverlight: Packaged Apps already disables support for Flash and Silverlight which are both used heavily throughout the financial industry.

How does OpenFin address these issues?

At OpenFin we have specialized Google’s Chromium to offer a solution that both utilizes the great benefits of Packaged Apps and addresses its shortcomings for financial industry use.  OpenFin App Desktop offers the same native user experience but removes the dependence on Google and its services.  App Desktop enables organizations to write Packaged Apps and deploy through their own portal or app store.

Below are some of the key enhancements:

No dependence on Chrome: App Desktop is a standalone runtime and does not require a Chrome browser to be installed on an end-user's desktop.

No dependence on Google Services: App Desktop does not require a Google Account or a login of any kind.   Application code is hosted on your own servers.

Advanced windowing: We have extended the Packaged App API with features like the ability to dock windows and tear out components.

Inter-application messaging: App Desktop includes a client messaging bus that supports local publish-and-subscribe messaging between applications including those running outside of App Desktop.

Sandbox security: Users have no ability to grant an application privileges outside of the security sandbox.

Support for Flash and Silverlight: App Desktop supports Flash and Silverlight applications and provides native language APIs for access to App Desktop features.

Continued support for NPAPI: Although Google is phasing out support for the NPAPI, OpenFin will continue to support it as long as it is needed by financial industry applications.

[openfintech-blog]

iOS vs. HTML5 for Wall Street apps (Part 2)

Reasons Wall Street firms should consider choosing HTML5 over iOS for mobile apps.

Many financial firms are recognizing that iOS vs. HTML5 is actually a false choice and that a hybrid approach offers the best of both worlds.  With a hybrid approach, developers build the app in HTML5 and package it in a native app container, allowing the app to access device features it couldn't otherwise, such as contacts, camera and push notifications.  With this approach, the app can also be submitted to the Apple App Store, making it easy to find and monetization ready.

Here’s why financial firms should consider switching to a hybrid HTML5:

#1 HTML5 Meets Financial App Needs

The primary reason developers choose iOS is to access full device capabilities and because they don’t believe HTML5 can provide the same slick experience.  In reality, whether it’s news, research, real-time market data or charting, HTML5 can provide the same user experience as iOS.  With few exceptions, HTML5 animations are the same because they are hardware accelerated just like iOS.  And for important native functionality like push notifications or in-app browsers, a native container enables developers to bridge the gap.  

#2 Other Mobile Platforms

iPads are still well over 95% of the tablet market share on Wall Street.  However, other platforms have caught up to Apple in the smartphone market and the same will undoubtedly happen eventually with tablets.

Consumer companies like Facebook often have one or two apps that are essential to their entire business.  Rebuilding the same app natively for each platform does create additional development effort, but it’s a relatively small cost for these firms.  By contrast, Wall Street firms build tens or hundreds of proprietary applications.  Building native apps for every platform is a much bigger development effort and creates enormous maintenance overhead.  With HTML5, developers can build once and run everywhere.

#3 Cross-Platform Mobile and Desktop

Unlike most of the world who have all but forgotten the desktop computer, Wall Street business happens almost entirely on the desktop.  The overwhelming majority of applications used on Wall Street are desktop applications and this creates two significant challenges for IT:

Desktop applications aren't written in iOS so they would need to be completely rewritten for mobile

New mobile apps are usually much better than old desktop applications, further disappointing users on the desktop

Some firms have experimented with other approaches such as virtualization (e.g. Citrix) to make desktop applications available on mobile. However, the results are usually poor because desktop applications aren't designed with mobile form factors and touch interfaces in mind.

With HTML5, an application can be written once and run on both mobile and desktop with native user experience.

#4 Faster UI Development

User interface development is much faster with HTML5.  This is partially to do with the architecture of HTML5 applications that makes it uniquely useful for building interactive interfaces:

HTML for content and structure

CSS for styling

JavaScript for application logic

It is also a result of a proliferation in HTML5 tools and frameworks that are now available to developers, most of them for free.  Interfaces that previously took months to develop with other technologies can now be done in weeks with HTML5.

#5 Future-Proofing

Wall Street technologists are all too familiar with technology fads.  Financial applications often live for ten years or more so betting big on the wrong technology means years of legacy application maintenance.  Some worry that HTML5 is just the latest fad, but it is different from previous technologies in several important ways:

No one owns HTML5. It is an open standard.

It is the only UI language supported by Google, Apple, Microsoft and Adobe

It can run on most desktop browsers and all modern mobile devices

It's getting much better, much faster than previous technologies thanks to huge investment from the major technology players

There is a large and fast-growing open-source community developing tools and frameworks to make development easier

All of this means that HTML5 apps are future-proof and significantly more likely to withstand changes in mobile and desktop operating systems for years to come.

To be sure, there are financial applications for which iOS is the right choice.  However, for most categories of applications, including real-time trading and complex charting, a hybrid HTML5 approach offers the richness of iOS experience together with the cross-platform advantages of HTML5.  Wall Street providers including Interactive Data and Chaikin Analytics have already made the move and are impressing their users.  Others should consider this approach while mapping their mobile strategy.

[openfintech-blog]

iOS vs. HTML5 for Wall Street apps (Part 1)

Wall Street has been choosing iOS for its mobile apps.  Is it for the right reasons?

In the battle between iOS and HTML5 (if you can call it a battle), iOS is winning hands down.  A cursory look through the Apple App Store (1) and a few Google searches (2) can validate this assessment.  Virtually every major bank and financial service provider has a native app in the App Store and few firms to date have built a Wall Street app with HTML5.

Gone is the euphoria from 2011 when the Financial Times famously left the App Store in favor of a new (and impressive) HTML5 app.  Back then, bloggers were openly discussing whether HTML5 would be the end of native apps.  So where did HTML5 go sideways?

#1 HTML5 Limitations

Much of the knock on HTML5 is misguided (3), but there are some genuine limitations.  For example, with HTML5 you can’t access the device camera, get full access to local storage or provide push notifications.  With that said, tools like PhoneGap and Cordova bridge this gap and enable HTML5 apps to have the same capabilities as native apps.

#2 Rich User Experience

While device limitations are a factor, the primary reason most financial executives choose to go with iOS is the rich user experience.  A common refrain goes like this: “Our apps need to be native iOS because we need exceptional user experience and performance.  HTML5 isn’t there yet.”

#3 The Facebook Effect

A key reason for the misconception about HTML5 were comments made by Facebook CEO, Mark Zuckerberg last year: “The biggest mistake we made as a company was betting too much on HTML5 as opposed to native."  This led many financial executives to conclude (understandably if mistakenly) that HTML5 is not ready for prime time.

#4 Lack of HTML5 Talent

Finally, for those who have tried building an HTML5 app, the result is often just plain disappointing.  The “app” looks like a web page, it’s painfully slow to load, the animations are jumpy.  To be sure, knowing HTML does not make you a qualified HTML5 app developer.  It is easy to get it wrong.  Building a beautiful, rich HTML5 mobile app takes a certain kind of programming talent and artistry that most developer don’t (currently) have.

In light of these challenges, should Wall Street continue building mobile apps in native iOS?  For some reasons to consider switching to HTML5, stay tuned for Part 2 of this post.

Sources:

1. Look in the Finance category under “Free Apps”.

2. Search for “HTML5 finance mobile app” or anything else you think might hit.

3. For example that it can’t support rich interfaces including complex charting -- it can.

[openfintech-blog]

Why we've moved on from Chromium Embedded Framework (CEF)

We have used CEF for the past 2 years and been very impressed with the community, quality and overall utility of the project. It is a truly awesome tool that helps address some key problems in bringing HTML5 to desktop applications - CEF has certainly accelerated our development. Using its clean and easy to use interface to add HTML5 rendering to your application allows you to not worry too much about the underlying Chromium codebase which is quite complex.

However, the core problems we are addressing at OpenFin around security and truly native user experience for pure HTML5 applications are not in the forward path of the project so it was time for us to peel back our use of CEF and operate directly on the Chromium codebase. Doing this has required a big investment in getting up to speed on direct use of Chromium - navigating 25GB of code is not the easiest task - but will pay big dividends over time.

CEF integrates with the Chromium code using the Content API. This API was mainly introduced to make testing easier for those working on different parts of the code but it means that CEF and any other consumers of the Content API have to re-implement key, powerful, features that are available in the full Chromium browser.

Key missing features:

Sandbox

Desktop Notifications

UI implementations for authentication challenges and SSL certificates

Visually clean alert dialogs

Support for clearing cache, data and cookies

Managing unresponsive renderer processes

Perhaps even more compelling than having to re-implement/port some core features that are not present in the Content API is the Chromium team's progress around packaged apps and its related API's. These API's expose many cross platform native windowing features in addition to the the ability to launch HTML5 applications outside of currently running browser context. Though this work is at a very early stage it is clear based on Chromium's blistering delivery track-record that now is the right time to start leveraging as much of this work as possible. The gaps we will fill here have proven to be much smaller than the work we would have needed to do to continuing to come at it from the Content API.

So, to complete the move, we have retired quite a bit of our code that bridged the CEF gap in favor of leveraging the core Chromium components. This pruning process is not a one-time-event - as the packaged apps API matures and the Shell/NativeApp gets further refined we will be leveraging all of the powerful features that are exposed and closing the new gaps that are created.

CEF - thanks for getting us going - we have jumped from the nest...

[openfintech-blog]

OpenFin and the FinTech Innovation Lab

We are proud to announce that OpenFin is 1 of 6 companies selected to participate in this year’s FinTech Innovation Lab in New York City. You can read the official release here.

The FinTech Innovation Lab has been a great experience for OpenFin in further validating our technology and receiving invaluable feedback from the participating banks, mentors and VCs. The program gave us the opportunity to build meaningful relationships with leading technologists across the financial industry and opened the doors to getting OpenFin’s runtime technology deployed on financial desktops.

We look forward to what’s ahead and want to thank the Partnership Fund New York City and Accenture for putting together such an innovative program for the financial community.

If you have any questions, press inquiries or want to learn more please contact us at info@openf.in.