Progress update: Core App

I agree with this. I thought the grey bars would not require a long tap before being able to move.

1 Like

We have ideas for hiding multiple items apart from Pots. And we also have designs for sorting accounts instead of just Pots (ie JA before Personal) but we can’t do that just yet).

7 Likes

Are there still plans to nest pots?

For example, I might have a bunch of pots that relate to household spend that I want to group together. I have a vague recollection this was in some early designs you showed when the new nav was being developed.

@bruno - Hiding from the carousel is one thing, but hiding from the overview is a use case that I personally don’t recognise. Especially the idea that you might add 3rd party accounts to Monzo and then choose to not look at them - can you share the research / testing you have done around the concept of hiding in general? My personal preference is to exclude from carousel, but see full details fo all accounts i have added and pots i have created in overview, which I see as my financial control centre…

On the other hand I do want it hidden in the overview, so let’s just say that mileage varies and I personally am happy with it as is

4 Likes

6 posts were split to a new topic: Wrong card number in app

Id prefer it worked like this if theres the option to build for that as well as complegely hiddeb

I get this is the benefit of releasing to one client in Labs first.

4 Likes

:roll_eyes: ohh come on now, you’d have found the same benefit if you’d released to both clients in Labs first.

But it would have been found weeks later…

1 Like

Not if they’d released to both at the same time.

And no, I don’t mean ‘wait until’ I mean ‘we the users wouldn’t have known we’d been waiting an extra X for this feature so the time difference wouldn’t even be an issue’.

Anyway, old ground.

Glad it’s moving forward.

I think it’s more about finding overall design or implementation issues which could have an effect across both platforms as quickly as possible.


For example
Let’s say Monzo have two features they want to build: feature A and feature B.

  • Case 1: feature A is built on iOS and on Android (~4 weeks) at the same time, then released to labs on both platforms at the same time. Work then starts on feature B (~ 4 weeks). If there’s a design or implementation issue discovered on feature A, developers for both OS’s need to go back and fix it (~ 1 week).

Total time spent: ~ 9 weeks development time on each OS

  • Case 2: feature A is built on Android while feature B is being built on iOS (~ 4 weeks each). Each feature is released to the respective OS labs once completed. Android work begins on feature B and iOS work begins on feature A (~ 4 weeks each). Design or implementation issue discovered on feature A. However, since the iOS team hasn’t completed the implementation of feature A they can modify their approach and so lose no extra time. Android developers fix the issue with feature A (~ 1 week).

Total time spent: ~ 9 weeks development time on Android, ~ 8 weeks development time on iOS.


There could also be cases where a feature is built then scrapped because it’s not working well. Building this on one OS first would save many weeks of development time for the OS which didn’t build the, now scrapped, feature.

When stuff like people taking holiday and sick leave, the varying ability of individual developers, and that some features might be a lot more difficult, and therefore take longer, to implement on one OS than another is taken into account, building features on one OS first makes even more sense.

NB: I also find it frustrating when one OS has something that another doesn’t, by I understand why it makes sense to do it that way.

12 Likes

But they’d have spent double time developing before realising they ultimately want to the final version to be different. Now IOS can develop purely based on what they want the end result to be without any wasted time.

2 Likes

FYI it happens both ways. Sometimes iOS get things before Android:

2 Likes

It’s mostly down to priorities and what they deam to give the most value to customers.

If iOS team are busy working on a feature for the iPhone while Android teams are ahead of schedule or vise versa. They might priorities other projects over port sorting for iOS, for example, greater budgeting features > pot sorting.

Anyway, looking forward to seeing what’s next :blush:

I think a lot of the arguments above regarding this being fine would hold more weight if there wasn’t a whole thread full of things which are still not equal on platforms.

The more this happens, the more annoying it will be, whatever way round. And I feel the sentiment isn’t that they do this for any good reason other than not treating parity as important.

And it would be fine to say it isn’t important for a week, or a feature still in development, but that doesn’t seem to be where monzo’s line ends. And as long as the list of feature parity issues continues to grow, don’t think Monzo can really refute that very strongly :man_shrugging:t2:

I agree with your sentiment here, and that’s why we have actually been decreasing the differences between both platforms. A few years ago we had no Android app, then a year later we released an Android app that lacked most features already available on iOS. I think it’s remarkable how the Android app has caught up with basically 1 full year of iOS development.

With new nav one of the requirements was to build a design system that worked on both platforms, so that both iOS and Android could have the same experience. This didn’t used to be the case before.

That’s our long term strategy, and we want both our platforms to have the same functionality. I actually think we’re there on this front, the product advances in both clients in parallel. Overall both apps are at feature parity (bar some edge cases).

But in the short term there will always be differences in what’s available to test out. Always. Here are some reasons why in the short term features come to one platform before the other:

  • Building for just one client first allows us to test a concept with half the time. This way we can test two ideas at once (one per client), and then swap eng effort to get parity if we decide to release it.
  • Early feedback from our most engaged customers, that’s you!
  • Address issues that only exist on one platform while another platform builds something else. Imagine if we couldn’t fix any performance issues on iOS if Android didn’t also have performance issues.
  • People can go on holidays.
  • Engineers can build things in their spare time / Monzo time if they want to. Imagine if they couldn’t build something because they also needed an engineer from another platform to do anything.
  • Just giving something to users early on… if one platform has it available, why would we prevent half of our customers to access to it?
  • iOS and Android have different implementation costs. Some things are “nearly free” to build on one platform, others take a huge amount of time if the platform doesn’t give out of the box frameworks, this depends on the feature.

I saw some comments about having fewer iOS engineers than Android in the team. This is not true. We always try to have the same number of iOS and Android engineers in each team. Sometimes this is not the case if we are onboarding someone new to the company and need a new home while they get up to speed with our codebase (before finding a forever team). In other times people might move internally for whatever reason and leave a team with an imbalance on any eng discipline, this is also part of everyday life at Monzo, and in the long term we correct for these imbalances.

The interesting question is how can we keep a different release cycle between platforms (which we do), and still move towards a world where both platforms have feature parity (which we also do).

Once something has been implemented on iOS/Android it’s actually much easier to get the other platform running. Don’t forget each feature requires support from Design, Backend, Research, Testing, Data, etc. Once it’s built and we’re happy with it it’s much easier to implement the same thing on the other platform - the hard questions will have already been answered.

It also comes down to planning in advance. We can plan for a sprint where both clients will implement missing functionality from the other platform. But this can only happen if there’s a backlog for both platforms. For example I gave the example of potentially deferring Hiding Pots on iOS for after we built some budgeting features. A project like budgeting benefits from having everyone building the same thing at the same time, rather than building first on Android.

We’re :100: committed to build the same product for both iOS and Android. It’s only a healthy thing if we agree there will always be slight differences between platforms for those living on the edge of our product development cycles.

Knowing that features can’t always be worked on both platforms at the same time, I think it would be a worse outcome if we kept you in the dark about what we already have in one platform. But if you don’t want to see what’s being built, reading the Making Monzo forum section might be counterproductive.

40 Likes

Thanks for the answer. Overall, you’re making some good points. And I love your engagement here.

But it’s gotta be a no to this still: “Overall, both apps are at feature parity”.

When features like merging payees and putting notes on any transactions still aren’t at parity, and given the length of time they haven’t been, I can only assume never will be. It’s those features which aren’t flashy, but are so core to making the app a great experience which sting the most. Because they feel like they just should be.

Overall thanks but I’m not gonna believe it until I see it.

4 Likes

I agree that it is half the man hours designing a feature on one OS and carrying out the testing and such which enables you to do the same with a different feature on the other OS.
But can I ask when, now or in recent times has there been 2 test ideas running in parallel at once? When one OS had one feature whilst the other OS has had a different feature at the same time for testing? In the scenario you mention…

For example Android now has hiding and sorting pots, so what has been designed for iOS to be tested at the same time?

I feel this reason has been created just to try and justify it not being built yet because I can’t remember this ever being the case. I could be wrong :man_shrugging:t4:

Salary sorter
Get paid early.

1 Like