How we built it: trading updates

Briony Jones


4 min read

Our senior software engineer, Briony Jones, talks about one feature our customer base demanded of us, and how she and her team rolled it out on mobile devices. From customer feedback to constant iterations, think of it as a behind-the-scenes look at Nutmeg’s feature development process.

If you’re not already familiar, our trading updates feature shows in the Nutmeg app if the investment team has made an important decision relating to one of your portfolios. In it, we’ll let you know what they’ve done and why. To customers, it’s a line or two of copy on the homepage, but the architecture behind it is really quite complex.

The idea stemmed from an Ideation Day late last year. On this day we challenged people from across the business to generate new features based on customer feedback. The winning idea, voted on by fellow Nutmeggers, was built the following week.

As for the ‘techy’ part, we decided to implement and release the feature initially on just one platform. That way we could very quickly evaluate engagement through analytics and customer reviews before rolling it out more widely.

The build can be split into four parts:

Data Storage

The key component of this feature is data, be it the information the investment team are relaying to customers, or the associated meta data, i.e. any dates or the pots affected by the change. For the storage of this data we used a third-party service called Prismic.

Prismic is a headless Content Management System (CMS) that allows data retrieval through simple API requests.

An initial custom data type is created in the editor – this defines the structure of the data we want to store and what fields are required. Once this is defined, the management and maintenance is handled by the content team, allowing them to edit, update and add information as and when necessary. This means the trading updates can be dynamic and time-sensitive, without any engineering resource or code releases necessary.

 

Data Retrieval

Once we’ve created the data type, we need a way to retrieve it. We can communicate directly with our Nutmeg repository on Prismic via HTTPS, for which we can use our existing network layer. Our repository is set to private to ensure that only valid Nutmeg clients can query it. In order to authenticate with our repository, we need to add an access token – a secure token – to our HTTPS headers for every request made to the service.

First, we perform a `GET` request to query the CMS for an API reference ID. The JSON response contains information about the branch and version of the content we are querying, and looks something like this:

 

The reference ID, returned as “ref” inside the “refs” field, associated with the master branch is a unique key. We store this reference ID in the local storage (User Defaults in iOS or shared preferences in Android), so that we always have the latest master ref on the device. This ensures that cached data is always refreshed if there is a new update released.

With this master branch reference ID, we then query the API again, in order to retrieve all trading updates in descending publication date order. The response looks something like this:


Parsing and Filtering

Once we have retrieved the trading update data from Prismic in the format shown above, we parse the response into the required data model, by which we mean we split the data into pieces that can be easily stored or manipulated.

Important fields worth noting include the ‘Investment Style’, which contains a single string for the affected portfolio style of the given update, e.g. “managed” for a fully managed portfolio, and ‘Risk Level Group’ which determines which risk level portfolios are affected by the changes. At this point, we filter out any trading updates that do not apply to one or more of the users’ pots. This way we’re not overloading the user with irrelevant information.

We again use the local storage to store the date of the last shown trading update the user interacted with (either by dismissing it, or by tapping on it and viewing it). We store this so that when the application is launched and we retrieve the latest update, we known if it is actually a new update for the user. If it is, we display it; if it isn’t, we do not.

Presentation

As mentioned above, we wanted to use existing functionality of the app to deliver the feature as quickly as possible. This meant making a few concessions. The design for the Android application reused an existing view type and display logic, as seen in the image below. Clicking on the prompt will display a modal screen with the full update text, including the list of affected pots.

We received great feedback from the Android app. In fact, we had customers requesting the feature on iOS. For the iOS launch, the final design decision featured a scrolling marquee banner at the top of the app on launch.

Unfortunately, there is no built-in tool to achieve floating (marquee) label animation on iOS. There are third party frameworks that allow for this, but adding third party frameworks can be unpredictable. After a little digging, we found out that we could fairly easily build our own solution.

Our solution was as follows. Thanks to Kiryl Karabeika for providing the copy:

  • Extend the trading updates text label beyond the right edge of the screen and slide towards and beyond the left edge until it is fully hidden. The Swift AutoLayout engine is used to change the position of the label
  • Animate using UIViewPropertyAnimator using a feature to seamlessly stop and resume current animation, without which we would not be able to build our own solution
  • After the animation completes, it restarts from the right edge of the screen
  • The animation stops when the user leaves the home screen and resumes on their return
  • We’re not able to set a specific animation duration because the length of text varies with each update. A constant animation rate allows us to let very long text scroll at the same speed as shorter text

Final tweaks

The first release of the Trading Updates feature on iOS was well received – the design so much so that we now plan to replicate it in Android. However, one issue pointed out to us by customers (and staff) is that they wanted the option to revisit an update after they had first viewed or dismissed it. By way of a solution, we’ve added the trading updates history to the Nutmegonomics tab on both iOS and Android.

 

Hopefully this gives you some insight into the lifecycle of feature development here at Nutmeg. If you have any feedback on the app, please email us at support@nutmeg.com. If you haven’t yet downloaded the app, we recommend you do so right away.

Risk warning

As with all investing, your capital is at risk. The value of your portfolio with Nutmeg can go down as well as up and you may get back less than you invest. Tax treatments apply.

Was this post helpful?
Let us know if you liked this post
Yes
No
Powered by Devhats
Briony Jones

Other posts by