Cloud Functions

Firebase recently announced Cloud Functions that allow you to call into code running in Firebase from iOS and Android. This idea isn’t new and is similar to AWS Lambda. In fact, the idea is old in that CORBA had callable server side code decades ago. However, the subtle difference this time is that code can be run without provisioning or managing servers.

So when might you use code at the server? It tends to be used when you need one or more of:

  • More computing power than available in the smartphone
  • When there’s need to access data, for example ‘big data’, not available on the smartphone
  • To protect intellectual property to secure code so that it can’t be reverse engineered or decompiled

In an era where developers are tending to use new, usually more complex, mechanisms just because they seem fun, rather than for valid business reasons, I encourage you to not use cloud functions ‘by default’ and instead use them for a valid reasons.

From Mobile First to Mobile Native

benedictevansBenedict Evans has a post on From mobile first to mobile native where he says he is seeing an evolution beyond ‘mobile first’ to what he calls ‘mobile native’. This is where we forget desktops/laptops and low end phones and only provide a service to modern smartphones.

At first I didn’t think there was much in this idea until I suddenly realised the app I have been working on for a client for the last few months is just this. While I can’t yet say, for confidentially reasons, what the app is, it’s in a sector that’s currently very manually resource intensive and the current ‘state of the art’ innovation tends to be companies trying to take the service fully online via the browser. Conversely, the service I am helping create is fully mobile – skipping the ‘online’ part altogether. While I can’t talk about the service yet, here there some generic observations and insights.

Such strategies are implicitly suitable to target millennials who haven’t known a time without mobile and as Benedict says, the

“mobile-native generation that takes this for granted”.

Going fully and only mobile requires simplification of (business) process flow, simplification of the offering and generation of new value via the facilities offered by the phone.

Part of that added facility is the carry everywhere, always available capability that can make services immediately available. Tied to the immediacy is communication. If you want to engage and retain then the app will need to have in-built communication. The app I am working on uses Intercom.

Further ‘facility’ is the use of context, sensors and the camera to provide utility associated with the service. For example, in the app I am working on we use the camera to check the user’s id using microBlink. An id can be checked in seconds as opposed to relying on days or weeks of manual processing.

As benedict says, think about

“… how many different reasons there are that it would be impossible to build the same thing on the desktop”

If you can answer this question for your service than you might have something suitable for implementing mobile native.

On reflection Benedict coining the term ‘mobile native’ is confusing as, in mobile, ‘native’ means Java/c/c++ as opposed to web technologies. However, his ideas have value and provide opportunities for many sectors to circumvent or skip current ways of doing things and build services that fully depend on rather than just support mobile.

Mobile the First Platform

mobiforgeMobiForge is reporting that 68% of digital media time is now spent on mobile devices. 50% of digital media time is dedicated to using mobile apps.

As the article says, this is leading to the situation where the smartphone experience might be considered the first and primary platform. However, conversion rates are lower on mobile (3.89% desktop vs 1.43% mobile) which means we have to think harder how to retain mobile users.


I believe the poorer conversion rate is partly due to the smaller screens and shorter attention spans on mobile. While there’s little that can be done about this, we can add and promote features that allow users to save or share things for later when they are viewing on larger screens or have more time.

Onboarding and Help

smashingmagazineSome things seem to go into and out of vogue. At the moment onboarding seems to be making a comeback. Onboarding is the inclusion of one or more extra screens to introduce a new user to the app. Smashing magazine has a great discussion and tips on onboarding.

However, my tip is not to go over-board on this. My experience is that most users are impatient and don’t read what’s put in front of them. They try, then question. Hence, also think about how to serve customers when they start to wonder how to do particular things with your app – even if you have already told them in the onboarding. Your support starts with what’s behind a help icon or button.

The Demise of Material Design

xdaThere’s an interesting article at XDA developers on Why Material Design Didn’t Achieve the Grand Unification it Originally Aimed For.

The article describes Material Design as being stifling, contradictory (U turn on splash screens and bottom tabs) and more of a “Google brand” rather than something that is supposed to be generic. The article says…

“The given rules are vague, and lack definition, and with navigation being a crucial springboard for the entire product, its rules and recommendations could use an upgrade.”

I wasn’t a great fan of the introduction of Material Design in 2014. I questioned whether a complete re-design was really needed, asked what it would end up costing developers/stakeholders and observed that there would be old apps and old devices/apps so it would end up being a mishmash anyway.

Such is the problem with many well-meaning and ambitious large initiatives. On their own, they might look amazing, new and innovative. For some strange reason, developers cheer and croon at such things at developer conferences. However, when such things hit the real-World, things get messy.

Perhaps it’s a lesson for such projects to have more pragmatists and real practitioners on the project to help drive things in such a way they will be practical.

Cross-device Optimisation

netmagazoneThis month’s net magazine (May issue to be exact) has a great article on 15 tips for cross-device optimisation. Craig Sullivan gives some rules to remember when testing cross platform.

Four insights of particular use for mobile developers…

  • Track people, not devices. Many people use their phone to find items to buy and complete the purchase on the desktop or laptop where it’s easier to checkout. Use tools such as Google Analytics user view to track the user rather than the device to gain a better appreciation of whether leads are coming via mobile or desktop.
  • Don’t ignore the wider context. Think about varying the functionality depending on the context. Craig gives the example of an airline app where what the user needs might be very different 48 hours before a flight than it is when it’s used at the gate.
  • Don’t assume everyone uses iPhones. Avoid concentrating on what happens to be your personal device. Look to user base numbers and ideally recent domain specific metrics.
  • Segment testing by device class. Different devices might look very different and might need different testing.

Mobile Engagement Crisis?

recodeThere’s an interesting recent post on re/code by Raj Aggarwal, Co-Founder and CEO, Localytics where he says we are in a mobile engagement crisis. He phrases the problem as a request to Mary Meeker of KPCB Internet Trends Report fame, to ask her to consider what she puts in this year’s report and encourage companies to do more.

Raj says that…

“the majority of businesses have failed to innovate at anywhere near the same pace of consumers’ demands and expectations for mobile”

and that there’s a

“temptation to just do “something” and check off the box is greater than ever”

Naturally, his company has the answer in the form of “deep insights from the data”. Nevertheless, I think Raj is right. Companies generally aren’t trying hard enough and consumers really want more (of mobile).

Looking at this from another angle, it means that the fewer companies who currently take mobile seriously and do it well can use it to competitive advantage. While data is one aspect that can be used to drive change, I believe the changes need to be at a higher level than this and are more about addressing end user needs rather than company needs.

App Porting Tools

slashgearOccasionally companies pre-announce porting tools and I wonder how such tools will ever be possible. One such tool was MyAppConverter that I came across in late 2014 when I thought their aims were impressive and hugely ambitious. However, I didn’t think what they were trying to achieve was possible in a reasonable time and/or with a reasonable team size.

It was with this in mind as I read, via SlashGear, about Microsoft cancelling Astoria for Android, another over-ambitious porting tool. It seem like Microsoft finally realised the scope of what they promised and instead decided to focus on (buy) Xamarin that partially solves the problem from the ‘creation’ rather than ‘created’ end.

Re-visiting MyAppConverter, it appears they now only solve part of the problem and you have to ask them for a quote to manually convert the parts that can’t be automated. App converters are the silver bullet that doesn’t really exist.