The Mobile Breakfast - 8th September 2016

Centaur Mobile

The 4th edition of The Mobile Breakfast

8th September 2016

This edition of The Mobile Breakfast was held in the wonderful private dining room @ Riding House Cafe, in the heart of Soho.

Attendees:

Chair: Paul Ardealenu, Founder, NextFree

Host: Keith Robinson, Founder, Centaur Mobile

Mark Tootal, Engineering Manager, Mobile, Aimia

Steve Varley, CTO , DEM DX Ltd

Emilio Vacca, Director of Mobile Channels, Telegraph Media Group

Paul Cooper, Head of Mobile Product, Nationwide Building Society

Andrew Ebling, Head of Mobile Apps, Composed

Tim Walpole, Head of Mobile, BJSS

Mike Smales, VP of Engineering & Operations, Chirp.io

Mark Cody, Head of Mobile Product, Camelot Group.

Topics

1.     Native development or cross-platform development, Pros & Cons, Should you/shouldn’t you?

2.     Prototyping to POC to MVP – The easiest journey?

Native Development or Cross Platform, Pros & Cons, Should you/ shouldn’t you?

Our first topic, native vs cross platform technology, is a subject that has always been at the heart of the mobile software conversation.  It can be a divisive issue, with, in my experience, the topic having a polarizing affect on the community. However it is an important subject that cannot be ignored. Within the community many stakeholders and organisations will be asking the question, so as part of this community it is important that we can give the most informed decision possible.

The conversation on this topic was particularly interesting as we had combination of technical & product backgrounds. This gave an interesting mix to the debate.

Below are extracts from some of the more illuminating points and quotes from the attendees.

Paul Ardeleanu opened up the conversation by saying that although he can see that there are pros and cons to both, he sees it as “...choosing between building a Vauxhall or a Ferrari.” native being the latter in that example!

Emilio kicked us off by asking the group on how much money do they think can be saved by going Cross Platform:

Tim Walpole explained that it depends very much on your starting point:

“It depends where your development base is, if you have 200 C# developers then it makes sense to go down the Cross Platform route.

We have been into a business in London that have an iphone app for years but decided to go down the Xamarin route for their Android app. They out sourced it to a Xamarin consultancy that does alot of Xamarin work.

We did some code reviews and within 7 mins we had it breaking all over the place. It’s quite clear that C Sharp engineers have a good understanding of coding, but they don't understand the platform. So the end game is that they are going to have to scrap it and start again.

You need to have engineers that understand mobile not just C Sharp.”

Mark Tootal added he didn’t see the total cost as being any cheaper:

“You can't get the UX right on cross platform.

The initial cost may appear smaller, but the total ownership cost ends up being more expensive.”

Steve Varley gave his opinion from his experience:

“The problem I have found is that the 3rd party is always a long way behind the new releases of the mobile platforms. I have been bitten badly in the past, specifically Titanium, so I would generally shy away from going down that route again.

It's very hard to explain that you can't do anything about the bugs in the products because it isn't your code! 

You can't get a web developer to do mobile, you just can't. You can convert but it takes time. You need to include a ramp up time.”

For Tim, ultimately it is risk issue:

“Reacts a good example of that. If you took React today, can you debug? Can you test it? Can you assure it? Will it be your development platform in 5 years time? Err I don’t know. 

Risk is a major issue...

....As a consultancy's we have seen 20-30 business, and most of them we have this discussion with them. We have some standard framework that we go through with them. We go through the risks with them, and all of them go in saying they probably want to go Cross Platform, and come out saying that they think they want to go native.... We have a few weeks with stakeholders in the business. End of the day it is less risky going native”

The conversation was dominated by the opinion that native was the best was to go...until Paul Cooper gave his interesting insight and experience on this subject. Paul saw cross platform as being the less risky option given the backdrop and the stakeholders involved in his project:

“My experiences where a bit different. When I joined to launch the mobile banking apps, the main player was Blackberry, Windows where new players on the block then there was the Apple iOS.

I had to make the call on the multi million investment on how to take our product to market. We had a make a decision on whether to go Cross Platform or Native.

I still don’t think people fully understand it. However we didn't want to be handset dependent. Nokia for example 5 years ago where the main player in the market, and now they cease to exist.

Even 5 years ago, although it was clear mobile was the way it was going, internally we weren’t there and there were concerns from stakeholders.

They are a massive Microsoft house, so those where the background factors to the decision making. We decided we weren't going to go Blackberry, which was massively controversial.

We wanted to be device agnostic. So we moved towards a cross platform solution, it wasn't fully cross platform but the main part of the app was. It was a tough financial backdrop given the situation at the time, to get that investment. And banks right off IT assets so it was effectively cost.”

Paul Cooper asked the group what is the exposure of risk to an organisation of one of the big mobile players stopping supporting their OS?

Mark Cody & Tim Walpole explain that they saw this infact as a weakness of Cross Platform solutions:

“You are relying on Cross Platform provider supporting that platform. Cordova would still need to release support for that.

“They would probably be later and behind the curve on getting it out to you. The native would be out first. Min 3 months later you would get the update from your 3rd party”

Mark Cody went onto explain the current situation with his project, and how they are heading towards a cross roads of having to make a decision on whether to continue Cross Platform or go down the native route:

“We have been on Cordova for a long time. I have been there a year, but we have been on cross platform for alot longer.

We went cross platform to get to market quickly, which did a job for us. However my frustration is that two years on we are still in the same boat. One the ambitions are that we want to be where our customers are i.e. TV, watch etc which you can't do on cross platform.

We haven’t pushed the development yet on our cross platforms apps so there is room there still to push that further.

So we are looking at in 6 months time, we need to make a decision as to whether we are going down the native route.  We have got 16 engineers, mostly JavaScript, we have only got a couple of people that can do native. It isn't a simple a decision, as it has a big impact on business.

.... One of the challenges is how to do you get a hybrid of people who have the skills vs people who are up skilling and training in mobile. That is one of the challenges.”

Andrew Ebling suggested that it might not be long before Swift may be the new cross platform language of choice:

“It will be interesting now that Swift is open Source. It will be interesting whether that will end up being a language for Cross Platform. The problem I foresee is that you can't make the most of the native frameworks. You would have to re write the frameworks.”

The conversation on native vs cross platform covered the main aspects of the topic: cost, risk, performance, security, and speed to market. And came to the same conclusion as the topic always had: there is no right answer.

The general consensus was that in most circumstances that native was the best solution. However taking into account different backdrops to decision making process, there are situations where using a Cross Platform solution may the correct way to go.

Prototyping to POC to MVP – The easiest journey?

Our second topic looks at the journey from an idea of an app to its deployment on the app store. What is the most time efficient way of going about it, while making the most of the innovation and ideas that come out of the process?

Paul A was very clear about his views on the subject:

“My view on this is that I think you shouldn’t write a single line of code, unless you know exactly what you are writing. 

A few years ago when I used to work with clients, I would use keynote to put something together so they can see something.

Now, it is a lot easier. You can use Storyboards in Xcode, so they can create the Prototype, they can use TestFlight and they effectively have a native apps with images they can click on and see what’s happening. You can then use that app as a scaffold for the apps.”

Mark Cody gave his insight into how useful this journey was to a recent product they have released:

“Our UX guys have used a number of platforms for prototyping. We do corridor testing, go out to customers to test new products.

Ticket scanner is a good example. We thought we would know how people would react to it. You can scan the ticket with a camera view and it tell you whether you have won or not. Which is great.

But we certainly realised that you think you know all the answers until you put it in front of customers, you know nothing. We had some customers who had the ticket in one hand and had the ticket in the other hand. And they were running the ticket over the app like a bar code reader. In pretty much every work shop we did, we had a user that was using it like that. 

It really helped us to re think what we were doing.”

Tim explains how what he sees as the challenge in this process:

“My view on this is, there is an early Prototype stage that leads into a POC that moves into a MVP. 

How do reuse those assets that you’re generating? So that they are reusable. Do they need to be low fidelity? Can't they be used all the way through the app?

You might want to spin up a POC really quickly, you might want to consider a back end services like Firebase or something like that. How do you then migrate that application into an MVP, which has probably got bits of the app that you want to use but you want to change those back end services, maybe to AWS, it’s that whole lifecycle, how to do you get to MVP and do all the integration etc.”

Mark explains how they approach that challenge:

“What we did with the ticket scanner, is get the developers involved early stages. So the prototype wasn't the real thing it didn't pull server calls but it looked the real thing.

We had number of versions, having them involved at an early stage really helped with the flow. They build the prototype much quicker, and used 20/30% of the original code so it wasn't completely wasted.”

Paul Cooper added that for him the problem lay with the fact that the outcome isn’t clear from the MVP:

“In my experience, the biggest problem with MVP is that it isn't clear what the outcome. 

Touch ID being a good example, everyone wants touch ID but I think it’s a miss interpretation of the requirements. Everyone is trying to do is to make access to your information but still securely.

We spent alot of time on this though. For me touch ID is great, but if you've been gardening or something to much then it would be 20/30% hit rate. So we also had no sequential pin log in, we worked hard with our control groups to look over non sequential log in.

Actually the requirement was to achieve an easier way to log in but securely. It was important to have new and sexy to show to the board, and I think that is actually where MVP goes wrong. Is isn't enough work done criticising the product owners, to really think through exactly what the problems are. I think prototyping is just burning cash, the bars is set too low to starting sometimes. I think raising the bar until you absolutely clear what you want and you have an empowered product owner to put into that team.

Andrew Ebling confessed he was old fashioned:

“Call it old fashion, but I like straight forward pencil and paper sketches till you know exactly what you want. People don't feel bad about throwing away pieces of paper, you communicate better and get a better idea by the end of the session as to what they want.

The more you've invested in a prototype or mock up, they more reluctant they are to throw it away; especially if they are paying for your time. So you’ve got that far as to something that you can ship to the app store then it’s very hard to walk away from if you haven't made the right thing...”

Mark Tootal raised his concerns about the process from his experience:

“One thing I wanted to touch on there, we talked about how to do this rapidly. 

There is a tendency for these teams to continually work to make it absolutely perfect and then you have used 2 thirds of your time on that phrase then the development and testing is squashed up at the end. This is where a strong product owner is necessary to take control of that.” 

Tim Walpole gave his assessment on the conversation:

“We have all brought up several times, but the empowered Product Owner is the key part. That’s the key part, most of the time the product owners aren't empowered.”

Andrew posed the question on more left field requirements from clients:

“What about when a client comes to you with a completely left field idea that you aren't sure is even possible with current technology. Should you jump straight into prototyping and coding at that stage?”

Mark Tootal explained how if it’s the code that needs proving then there is good reason to jump into the code, Mike Smales gave his project as an example of how it just wasn’t possible to build a prototype for their project:

“We built Chirp.io without a prototype, it’s not something you can visualise.”

Although there were a few different ideas and variation on what the process should be, one thing was clear: A strong empowered Product Owner is key. Getting a strong product owner in place who understands the platforms, who has a clear idea of how they are going to go on that journey, have a good concept of the tools and technology available to help facilitate, who has the experience and ability to make tough decisions on the product; while keeping the stakeholders satisfied is one of the most important components of any project. Getting that skillset in place will play a crucial factor in taking a concept of an app to a successful product in the app store.

Thanks for everyone that attended, a thoroughly enjoyable morning with great company from the mobile community. A delight to host once again. Thank you to our marvellous host @ Riding House Café, potentially our favourite venue so far!