In the early days of ChartIQ, we had a small team build a sophisticated, consumer focused technical analysis concept mobile application using our HTML5 Charting Library. The team followed the Lean Startup principles of Eric Ries and built the app in 73 days. Here we will cover our approach and build process as well as outline a few of the lessons we learned.
Step 1: Philosophy
In order to provide the ultimate mobile experience, the team had to build from the ground up using mobile concept and principles. Phones and tablets are different. While both are touch devices, a tablet has enough screen real-estate that it is closer to a web experience than a phone experience. The team also recognized that mobile is often a “one handed” experience while tablets are predominantly “two handed”. Tablets are used at home. Phones are used on the go, so with concern for these factors, the decision to fork the mobile interface from the web/tablet interface was easy. The team decided that it would not build a responsive app. Responsiveness is for web pages, not web applications.
Takeaway: Think about combining both web and tablet characteristics into the mobile interface.
Step 2: Designing the User Interface
It’s important to hold brainstorming sessions first. Our team brainstormed what their ideal mobile user interface (UI) would be, without any preconception about what tools they would be using. They decided that some modern conventions could be safely relied upon: pulling menus from left and right; tapping on the company logo; long hold, etc.
It is worth noting that the final UI diverged significantly from the initial UI. We’ll talk more about that later, but in addition to brainstorming without preconceptions, it’s critical that teams recognize that they will discover things along the way that will influence design. And that it’s okay if some things are fuzzy during the design stage. They will come into clarity simply by living with a project over time. Following the Lean Startup methodology, the team relied on a core component of this project management style, the build-measure-learn feedback loop.
Takeaway: Be open minded about UI design ideas and see how they evolve over time.
Step 3: Picking the Right Frameworks
There were two types of frameworks that are necessary to build the app, and is generally the case for most modern HTML5 projects. You’ll need one framework for architecture which will provide your app services such as routing and data binding. You’ll also need a UI framework which will provide the components used to assemble the interface.These two types of frameworks are often confused by developers and non-developers alike.
Keep in mind, which frameworks you pick can also limit the available choice for the other.
Picking An Architectural Framework
Because we knew the application would expand over time, the decision was made to use a declarative framework. This would allow the team to build a user interface more rapidly. The next step was to evaluate all the available frameworks. This was accomplished by simply building a “hello world” charting application with a very simple chart and menu with each framework: Ember, React, Angular 2, Aurelia, and Vue.js.
Angular 1 wasn’t attempted because the initial thoughts were to start off with Angular 2. There were high hopes for Angular 2 and anticipation for using W3 Web Components. However, as it turned out, Angular 2 was the only framework that was a complete fail. It took the longest to implement and was poorly documented. Comparatively, the team was able to implement a version in each of the other frameworks in less than a day.
Picking A UI Framework
When deciding on a UI framework, it came up whether to use the default UI componentry from the HTML5 Charting Library or to build UI tools from scratch. Because there was a want for a different style of interface and an anticipation that the product would grow beyond charts, the team decided to build their own UI componentry. Things went smoothly as anticipated and the team was able to provide more than charts in the initial release. When they decided to use the HTML5 Charting Library their UI integrated with the Charting Library’s SDK to influence the chart.
Surprisingly, there are still very few mobile UI toolkits available. The team wanted a toolkit that supported modern mobile conventions such as gestures (swiping, long hold) and components (sliders, pills). They also wanted a framework that had a native feel depending on whether you were running on Android or iOS. This wasn’t a deal breaker but it did influence their decision process.
The frameworks they evaluated included: Ionic, Chocolate Chip UI, Material, Kendo, Sencha, Framework7, Aurelia and Ember. This was a case where a commercial framework would have been well worth the money. The two commercial frameworks - Kendo and Sencha - were in fact better than most of the open source options, but were still missing some functionality.
The only framework that the project team felt was truly great was Framework7.
Framework7 was a dark horse candidate, and frankly the last one evaluated, but it turned out to be incredibly powerful. Almost everything and anything the developers had thought of had been built. The Framework7 code itself was written very clearly and allowed the team to leverage Framework7 to implement some complex constructs that weren’t natively supported.
Framework7 includes templating and a lightweight JQuery-like wrapper called Dom7. For a slightly less complicated application, one could conceivably do everything in Framework7 but in this case the team ended up using a bit of JQuery and Vue templates. Overall, very little DOM manipulation was required.
In conclusion, the team chose two frameworks that were primarily the work of a single person each. This gave them a bit of pause, but because of the large framework community and that it was open source they felt comfortable moving forward.
Takeaway: Pick an architectural framework and a UI framework.
Step 4: Rapid Prototyping in Fintech
The project team set a cadence of weekly evaluation and brainstorming sessions. The week was used to implement UI. On Fridays, UI evaluations were conducted by projecting onto a whiteboard and having group discussions.
At this point, Vue was in place as the architectural framework, Framework7 as the UI framework, the HTML5 Charting Library was snapped into place, and market data was being supplied into the charts by Xignite with just one line of code. Within the first few days, the team had a simple application with a chart and a pull-out side menu to manipulate the chart, including changing the chart type (candlestick, bar, line, etc). From here functionality was quickly added to change interval and chart scale.
Next the team built a symbol lookup. The developers used the sample symbol lookup code from the ChartIQ HTML5 Charting Library, but implemented it in a Framework7 dialog. The same went for technical indicators which they decided to implement through a side panel dialog.
A UI construct called “slivers” was decided on which provided functionality related to a feature that could be turned on or off. The first sliver built was a drawing toolbar. Then the ChartIQ sample code was used as a template and so the devs were able to “lift” the CSS styling from the default toolbar for line patterns which saved quite a bit of time.
Finally, a static toolbar was added that would allow users to share charts, turn on drawing tools, and place trades. ChartIQ’s Trade From the Chart module was practically a drop-in. Interfaces of integrated brokerages were already built and so all that was left to implement was menu-ing and working out a url scheme for Oauth.
At this point things were going smoothly enough that the team could implement more functionality, making the app more than just a technical analysis app. A left navigation menu was added and a streaming quote board implemented using data from Xignite. Financial content was added by iframing CloudWidgets, a joint project developed between ChartIQ and Xignite.
Takeaway: Build a functioning app that accomplishes the basic goals before adding bells and whistles.
Step 5: Refinement
With a functioning prototype they began tweaking the UI. The touchstone goal was to make the application intuitive. Sometimes this meant moving features from one menu to another - and then back again. Another goal was allocating as much screen real-estate for the chart as possible. This forced the developers to learn how to be extremely efficient with their interface.
After a few rounds within the founding team, testing spread out to other internal testers. The team watched how their colleagues interacted and tried to accomplish tasks with the UI. Knowing how a user will interact with your app, provides a number of ideas on how to refine and simplify your user interface.
After internal tests were completed, the team ran tests with third-parties. This provided unique feedback from users who were pre-selected to have experience with financial applications. The value of running user tests when working to improve user experience within a user interface cannot be underestimated. User testing was run in parallel with development, so while the test group was testing one set of features the developers would be building another set.
Overall the team implemented five major refinements over the course of two months. The UI ended up having the same “spirit” as that which was originally designed but in many, many ways the final interface was superior to what was originally envisioned.
Takeaway: Test, test, test, and make adjustments from the feedback.
Step 6: Aesthetics
Beauty and the user experience are incredibly important in modern applications. There must be a healthy balance of both functionality and visual appeal for your app to be successful. In our case, not only are stock charts for trading, but we used ChartIQ’s canvas-based charts to provide a deeply visual experience.
To help round out an aesthetically pleasing interface, the team decided to reach out to a graphic design agency to create custom icons. It was agreed upon between team members that they did not want to use the same icons that most of the internet was using (font-awesome for instance). A considerable amount of time was invested reiterating icons until the team arrived at the ones that were both meaningful and aesthetically pleasing. Good icons are important and should not be underestimated, especially when dealing with limited screen real estate.
The graphic designers helped the team arrive at a style that was modern, yet had a hint of “old world” elegance. Strategic placement of serif fonts, crisp lines, and icons that were flat but not too bubbly helped was precisely what they envisioned their users would like the most.
Takeaway: Look to get help from an outside agency to help make your application more unique.
Step 7: Testing
The project team used Applause, firm who tests software and conducts usability feedback research, for its final stages of testing. With Applause, a large pool of testers reviewed the app, provided detailed descriptions of their experiences, and even used videos to capture bugs. Many “corner cases” were found during this process and helped tighten up the application.
Takeaway: Keep testing with various audiences and figure out a support system for when things may fall through cracks down the road.
Step 8: Deployment
In most cases, you’ll want your app to be accessed on mobile and web as well as natively so users can download from the Apple App Store or Google Play. Our native application was built using Cordova by Apache. This allowed our devs to wrap their code so that it could run as a native app. Cordova also provides a few cool features like the ability to share charts through native sharing tools like StockTwits, Twitter, and Facebook. One major advantage of using Cordova was the team’s ability to maintain a single code base to support mobile web and native applications. The performance of ChartIQ’s HTML5 Charting Library, Vue, and Framework7 ensured that users who downloaded the native app got a true native app experience. It’s worth noting that the team also used the WKWebView on iOS which has a much better performance profile than UIWebView. This was turned on with a switch in Cordova.
Finally, the team deployed to the web using Deploybot then a GitHub process was set up for when developers would sent pull requests to their QA team. When satisfied with a feature, the QA team would pull the features which triggered Deploybot to deploy to production. Because of this, building and deploying features is rapid and iterative, so the product constantly moved forward, but in a stable manner.
Takeaway: Make sure you know the environment in which your app will be deployed and create a system for developers to make changes as the application evolves.
From start to finish, the project team rolled out the technical analysis and trading application in under 80 working days which exceeded our expectations of 100 days. It was an incredibly fun and gratifying project and at the end, a professional and beautiful concept application was built. While the desktop reigns king for technical analysis and trading, traders love having access to the same tools while on-the-go.
See how EDGAR Online used our HTML5 Charting Library to build a more dynamic charting system for mobile devices by downloading their case study.