Remember me

Register  |   Lost password?

The Trading Mesh

The UI Technology Mess

Fri, 13 Mar 2015 07:46:00 GMT           

 

In this article, Mike O’Hara, publisher of The Trading Mesh, talks to Olivier Deheurles of Adaptive Consulting, Ash Gawthorp of The Test People, Eddie McDaid of Software AG and Ofer Deshe of Tobias & Tobias, about the current state of front-end user interface (UI) technology in trading platforms and investigates how firms can future-proof their investment in UI development.

 

 

Introduction

 

In recent years, financial markets professionals have seen a massive growth in the number and variety of trading-related applications accessible not just from their desktop, but also via the web and on mobile and tablet devices. Anyone attending an industry trade show such as TradeTech or FIA Expo these days will encounter a multitude of such trading front ends, running on a variety of platforms. 

 

For the firms that develop these applications – whether banks or specialist ISVs – the decision around which technology to use for the front-end user interface can be critical to the success or failure of the product. Getting the decision right however, is easier said than done. UI platforms come and go at an alarming rate; what is flavour of the month one year can be almost obsolete the next. 

 

So how can firms ensure that the front end they build today will continue to satisfy the requirements of their clients and end users tomorrow? In short, how do they navigate their way through what has become something of a UI technology mess?

 

 

A plethora of UI platforms

 

Looking across the spectrum of end-user platforms, there are many possibilities to consider. From a hardware and OS perspective alone, clients might be using PCs or Macs running various versions of Windows, Linux or Mac OS. They might also be using a variety of mobile and tablet devices that could be running anything from Apple’s iOS to Google’s Android, Blackberry OS or Windows 8, for example.

 

Factor in the choice of development platform – HTML5; browser plugins such as Flex or Silverlight; desktop environments such as WPF; native mobile apps and so on – and things start to become increasingly complicated, especially as new versions of these platforms are constantly being released.

 

Add to that the fact that the back-end systems that drive these end-user applications – particularly those operated by banks - are often legacy systems written in entirely different languages with their own communications protocols, and it all just adds to the confusion.

 

Given this fragmented UI landscape, firms developing trading applications need to be clear on who their target end users are and what platforms they are currently using, as Ash Gawthorp, Technical Director of The Test People, a leading performance engineering and testing solutions firm, explains.

 

“In the consumer world, web apps are designed for the latest versions of Chrome, IE, Safari and Firefox because those are the big ones in terms of usage stats”, he says. “But the elephant in the room in the corporate world, particularly in banking, is that the browser used almost to the exclusivity of all others is Internet Explorer, and often older versions such as IE8. So if you’re creating an HTML5 app for example, a lot of the features and functionality just don't exist on that platform” he says.

 

Olivier Deheurles, Co-Founder and Director at Adaptive Consulting, a software development and integration firm that works with a number of global tier one and two investment banks, agrees that the banking world may not be quite ready for mainstream adoption of HTML5-based apps just yet, even though the desire might be there.

 

“With Silverlight and Flex dying because they are not going to be supported for much longer, everybody is looking at HTML5, especially in the retail and consumer market”, he says. “But the user base of banks is very, very different from the user base of the likes of Google and Facebook. And the fact is that very few of the elements of HTML5 that are useful for building trading apps are implemented in IE8 and IE9. It’s not that HTML5 is not a solution, it’s a good and relevant one, but there are challenges. It’s not as simple as people might think”.

 

If HTML5 isn’t the answer for investment banking and trading applications (yet), what is? 

 

The user base of banks is very, very different from the user base of the likes of Google and Facebook. And the fact is that very few of the elements of HTML5 that are useful for building trading apps are implemented in IE8 and IE9.”

Olivier Deheurles, Adaptive Consulting

 

Performance

 

As is so often the case in these situations, the answer depends. Developers of front-end applications need to have a clearly defined set of criteria to help them choose the appropriate UI platform(s) to focus on.

 

Another key factor to consider when developing trading apps is performance. Regardless of how rich an application’s functionality is, if it is too slow and unresponsive, people just stop using it, so there are various factors that need to be taken into consideration around performance.

 

Deploying to a global client base for example can create problems around latency, due to the physical distance of the app’s users from the web servers. Another factor that can impact performance when building new UIs on top of legacy applications, is that those legacy systems are generally not designed to minimise the number of requests back and forth, when delivering content back out to the browser, for example.

 

“When you’re deploying to a global client base it’s very easy to build a web app, but people often don’t take care of the problems that can create; they don’t think about latency and the fact that if you’re rolling the app out globally, then the distance away from your web servers may be a problem in itself. Another challenge is where you’re building new UIs on top of legacy applications, which probably haven’t been designed to minimise the number of requests back and forth when delivering content back out to the browser”, he says.

 

 

How to Choose?

 

There are various other criteria that need to be considered when choosing a UI platform, says The Test People’s Gawthorp. One is installation friction. “If you’ve got a fat client application, then the upgrade process can be difficult, whereas if it’s in a browser it’s a lot easier. But even in a browser, you need to consider which plug-ins the app requires, because an HTML5 app for example requires no additional software installing in the browser, whereas Flex or Silverlight apps require plug-ins that need to be downloaded, installed and kept up to date all within the organisation’s standard release cycle”.

 

Availability of development resources is another important point, says Gawthorp. “Web developers are far easier to find than good Flex developers for example, so the availability of those skill sets and the price that you pay for them is a key consideration”, he says.

 

Another factor to consider is longevity. Given that UI technology moves so fast, developers need to have an idea of how long the front-end UI platform is likely to be around for. Other criteria might be how easy or difficult it is to test and release the app on the chosen platform, the total development costs and even the ‘stickiness’ of a desktop app versus a web-based app. Whereas a fat client sitting on a desktop is always there and can be heavily branded, anything running in a web browser disappears as soon as the browser is closed.

 

Adaptive’s Deheurles explains how issues around workflow are particularly important when developing trading applications for mobile. “The workflows and functionality that you expose on different UIs are completely different”, he says. “A desktop application has a very rich experience with lots of functionality and supports expert users. On mobile, we see people building more specific workflow-driven approaches, which perhaps integrate with both desktop and mobile clients. It’s critical, in this case, to have a shared backend and API so you can reduce costs drastically and consume the same functionality on different platforms but expose it different on those devices”.

 

 

Future-proofing

 

Given the challenges, the range of choices regarding UI technologies and the fact that the trading application space is so competitive, what are some of the best practices that firms can adopt in order to ensure they future-proof their investments in UI development?

 

“By keeping as much common platform development on the back-end as possible you can reduce complexity on the front-end, making everything event-driven and reactive is a great way to achieve this.”

Eddie McDaid, Software AG

 

The answer may be somewhat counter-intuitive in that it involves investing more heavily on the server side - rather than the UI itself – to enable multiple front-end technologies to work with a common infrastructure. 

 

“Having to redevelop business logic in each UI can sap precious development resources", says Eddie McDaid, Head of Product Management for Streaming Analytics and Big Data at Software AG. "By keeping as much common platform development on the back-end as possible you can reduce complexity on the front-end, making everything event-driven and reactive is a great way to achieve this”

 

Gawthorp agrees. “The choice of the right enterprise messaging technology is crucial, because the right one will provide bindings and APIs for all the different UI technologies enabling reuse of the same backend services  - both for today and for new client technologies in the future”, he says.

 

These are the principles that the Adaptive Consulting team have been following for some time when working with investment banks. “Realistically, technology on the back end is always around for much longer than you’d expect, maybe 15, 20 years”, says Deheurles, “whereas UI technologies move much more quickly and also design fashions change, so you need to keep things nimble and really keep the costs down at the front end. The back end services have to survive multiple generations of UIs, so they should be very highly engineered and provide very strong APIs to support multiple UIs and UI technologies.”

 

“The choice of the right enterprise messaging technology is crucial, because the right one will provide bindings and APIs for all the different UI technologies enabling reuse of the same backend services - both for today and for new client technologies in the future.”

Ash Gawthorp, The Test People

 

A real world example

 

Adaptive’s Deheurles gives an example of how investing more heavily in the back end than the front end can work in practice. “Say you are streaming prices to an FX trading application and you need to provide different prices to different groups of clients. The problem with just pushing out core prices and applying logic and calculations in the UI – which is certainly efficient from a server-side infrastructure perspective because you are mutualising lots of stuff and streaming the same thing to everybody – is that if you want to build the app on another UI platform to do the same thing, you’ll need to port all of the functionality and implement it all over again. So a better approach, even if it’s more expensive up front, is to do that kind of complex business logic on the server side and have the UI free of all this logic. That way you can still build a rich user experience but the UI is a lot thinner and doing a lot less”.

 

The kind of functionality that Deheurles describes can be achieved through the implementation of flexible messaging fabrics that integrate with technologies such as complex event processing (CEP) engines on the back end and multiple UI platforms on the front end, according to Eddie McDaid of Software AG. “By combining the CEP / streaming analytics engine and the messaging system, you can control pricing subscriptions from the back end rather than the UI”, he says. “The pricing engine on the server side can contain the logic enabling it to become the orchestrator of distribution, and the benefit is that it simplifies the application logic on the remote application. The more logic you have where it’s easy for you to manage and control it - i.e. on the server - the better, because not only do you get more simplicity, you also get better performance”.

 

 

Know Your Users

 

Possibly one of the most important things to keep in mind when navigating through the UI tech mess, is that - regardless of the technology components - for any UI to be successful it has to address the needs of the people who are using it. That means that the UI designers need to understand the total environment of those users, according to Ofer Deshe, Managing Director of Tobias & Tobias, a firm specialising in human-centred system design.

 

“The key element of the UI is the user experience”, says Deshe. “In order to get the UI itself right, you require a deep understanding of the people who will be using it, not only in terms of their business requirements, but also in terms of their psychological, cognitive and behavioural characteristics; their work flow; their mental models; how they collaborate; how they work, and so on. If you can gain a deep understanding of all that, you can choose the right UI elements and information architecture that will make the user experience truly successful”, he says. 

 

“The key element of the UI is the user experience. So in order to get the UI itself right, you require a deep understanding of the people who will be using it.”

Ofer Deshe, Tobias & Tobias

 

Deshe, who’s background is in Psychology and Cognitive Science, creates models to discover how people working in a capital markets environment retrieve and process information in order to make decisions. He explains how Tobias & Tobias works closely with Adaptive Consulting on design projects such as those for single-dealer platforms.

 

“We conduct a contextual enquiry, which is where we sit and observe people in their natural environment to understand how they think”, he says. “We look at how they work and what they do in the context of their environment so we can create prototypes. And Adaptive are able to bring these to life very quickly so they can be put to the test”.

 

 

Conclusion

 

In conclusion, it is clear that there are many factors that need to be considered when developing front-end user interfaces for trading applications, from both a user experience and a technology perspective. As Ofer Deshe summarises, getting the user experience right is good for business.

 

“Get it right first time and you will see faster — and greater — return on investment, high rates of user adoption and user satisfaction”, he says. “Get the user experience wrong and you will suffer from slow user uptake, poor and inefficient user interaction, higher rates of human errors, reduced revenues, higher training costs, and unnecessary increase in post-implementation change requests due to uncovered user requirements and usability defects. Even more importantly, your brand is not simply a logo, or a standard set of visual treatments. Your brand is also the way people experience your software products and digital services. Poor UI leads to brand failure. Great UIs strengthen brands and enable new opportunities”.

 

There are also some solid principles that should be followed from a technology perspective. Adaptive’s Deheurles sums these up. 

 

“On the front end itself, know your users and focus on the platforms they are likely to use. Be aware of the fact that the lifespans of these UI platforms are short, so don’t invest too heavily in any one platform. Instead, invest more on the back end and messaging technology that will enable your server side infrastructure to continue to operate with a constantly changing landscape of UI platforms”. 

 

By following these principles, firms can minimise the significant costs and problems of constantly re-developing trading apps for every new UI platform that comes along and navigate a clear path through the 'UI tech mess'

 

 

For more information on the companies mentioned in this article, visit:

www.weareadaptive.com

www.tobiasandtobias.com

www.softwareag.com

www.thetestpeople.com 

 

 

, , , , , , , , , , , , , , , , ,