Localytics have new research that shows that in-app messages drive 3.5X higher user retention. But, as Localytics say…
“Many app owners wonder how to create content that isn’t viewed as spam and doesn’t detract from the user experience.”
The problem is that unless the message is event/content triggered and is useful to the user then the notification is likely to be seen as an annoyance. For example, as some developers do, reminding the user about some feature of the app that isn’t pertinent to specific new content in the app is likely to be viewed unfavourably. If your app isn’t event/content driven then in most cases I’d avoid notifications as it’s harder to justify their use.
Localytics also have some recommendations for you to consider to help drive use of notifications…
- Get the user to opt in (rather than have to opt out)
- Provide personalised recommendations (rather than serving them with everything)
- Provide notifications for upgrade or achievement notifications
- Get users to share app content (I am less sure this is a good idea)
- Provide app quick tips (I personally think this will annoy all but the most ardent fans of your app who will probably already know about the feature anyway)
You might also consider filtering notifications based on what content the user has previously viewed or what they have favorited/saved. Whatever you do, provide the option in the app for the user to turn off notifications otherwise some people might uninstall the app instead.
MobiForge has a great post on ‘25 mobile market statistics that you should know in 2015‘ subdivided into Mobile Hardware Statistics, M-Commerce & Banking, User Behaviour, Mobile Software and Mobile Networks.
The most useful statistic for mobile developers is iOS vs Android across countries…
However, the data comes from DeviceAtlas. This means the data is based on web usage which might (or might not) skew the data. However, it’s probably a more useful way of measuring the user base than shipments because it gives the installed base which takes account of the cumulative affect of shipments/replacements.
The invision blog has a thought provoking post on ‘Why Empty States Deserve More Design Time’. The ’empty state’ is the time, usually when the app is first used, when the user or app hasn’t done anything yet and the UI has no content yet.
As the Dina Chaiffetz says in the blog, the empty state is often the first impression the user has of an app. First impressions can weigh heavily in the users’ decision to re-use or abandon an app. Dina suggests it’s an opportunity to educate, delight or prompt the user.
How do you implement these things? In the past I have worked on apps that have done one of three things…
1) Totally change the screen layout for the ’empty’ case. This can subsequently confuse some users’ concept of the normal navigation flow if not done well. Designs, re-designs and app state changes (e.g. going back to empty) tend to get overly complicated.
2) Use a ‘dummy’ element (e.g. dummy list item) loaded when the app very first starts. While this is the easy way, it can complicate subsequent coding that always has to cater for the dummy element – unless it is deleted once there is real data.
3) Use an OS provided mechanism. There’s sometimes a ‘show this text when empty’ or ‘show this view when empty’ API for a view that keeps the screen layout but automatically provides the temporary information. This is usually the best approach.
As Dina says, the ’empty state’ is often an afterthought. I find it’s always the rushed part of a project, is usually something people can’t agree on and often needs to be re-worked several times. Hence, consider it early if you can, so as to avoid problems late on in the project.
There’s a great free ‘Mobile is Eating the World’ presentation at Andreessen Horowitz. The gist of the presentation is that whatever way you look at it, for example, the numbers of people online, people having smartphones, the cost of devices, how we spend our time or uptake by companies, mobile software is becoming increasingly dominant and is ‘eating’ other channels and media.
The presentation talks of how startups have changed and need fewer staff to get large (million sized) numbers of users. Software and tools have matured and it’s much easier to create (particularly server side) code and create services.
The slide hints of a future scenario where close to 1 engineer can achieve millions of users. While it might be argued that this scenario is already possible with a lone coder or indie developer, it’s not currently a scenario achievable by a typical company. Nor can I see it being possible in the near future. Creating mobile software is currently relatively complex and expensive. The range of things apps need to do and the number of different types of device is far greater than for the server/desktop and tools haven’t yet matured to the point where app creation is more ‘drag and drop’ than it is puzzling out some obscure API on a particular phone. The huge number of possible capabilities of an app is very difficult to describe in a tool let alone generating the underlying code.
This situation is similar to the mobile web vs apps debate. The tools aren’t there to create apps of the required fidelity and even if they were there, the tools would be extremely complex to develop and continually playing catch up with the native APIs. Furthermore, there’s no incentive yet for a company to invest the huge resources that would be needed for such an endeavour.
There’s a new research paper (pdf) from the University of East Anglia and the Centre for Competition Policy on affect of the frequency of app updates on boosting downloads across the App Store and Play Store.
A conclusion is that, on both the App store and Google Play, app updates are released with an extremely high average frequency of every 28 days for Google and every 59 days for Apple. However…
“The release of an update positively affects downloads in iTunes while it has no significant impact in Google Play”
The paper mentions “divergent regulations on the publication of apps” and “the absence of a strict quality check” as to partially explain the differences. The paper also mentions that fixing app problems due to device fragmentation might also be contributing to more updates on Android.
Looking from a developer viewpoint, having worked with multiple clients that tend to release both iOS and Android apps, yes, I can see the Apple review process does slow down the frequency of releases on the App Store. Yes, device problems often cause Android apps to have to be re-released. However, while the adding of features might improve downloads, on both platforms this doesn’t tend to be the reason for releases. Instead it tends to be to re-design, fix or add new features rather than to expressly try to cause new downloads. The study only looked into the top 1000 apps so maybe there’s some learnings there for my clients and the huge long tail of other apps.
As the paper says “to continue growth you need to provide constant value” to the end user.
This site was born 10 years ago in the era when Nokia was the top smartphone vendor and the iPhone and Android didn’t exist. February 2011 was turning point for me when I said that Nokia were heading off in the wrong direction and shortly after that I went ‘Android only’ from working on all mobile platforms at that time. Microsoft ended up taking over the Nokia handset division and more recently, according to Wired, Microsoft finally gets that it won’t win the smartphone war and Stephen Elop is leaving the company.
However, there’s a twist to the story. Tomi Ahonen is quoting Nokia CEO Rajeev Suri telling German periodical, Manager Magazin that Nokia will return as a brand to smartphones in 2016 as the exclusivity period out of the Microsoft deal ends. Tomi says “Obviously these will be Android based”. I’d like to think so. However, as the past has shown, companies don’t always follow what might seem like the obvious path.
There has been lots of press about the recent Samsung keyboard vulnerability. The vulnerability comes about because a new language can be downloaded under a privileged context which can be network hijacked to run arbitrary code.
Many articles mentioning this vulnerability are over sensational because it’s very unlikely that the user/app would download a new language pack AND be on a hijacked network taking advantage of the vulnerability. However, I think it’s more useful to pull apart the vulnerability and look for simple learnings to apply to other existing and new apps.
There are three main problems…
Gartner has a new press release on how the demand for enterprise mobile apps will outstrip available development capacity five to one. Their survey on mobile app development conducted in 2014 found that the majority of organisations have released fewer than 10 apps. A significant number of respondents haven’t released any apps. Gartner says…
“This is an indication of the nascent state of mobility in most organizations, with many organizations questioning how to start app development in terms of tools, vendors, architectures or platforms, let alone being able to scale up to releasing 100 apps or more,”
There’s an increasing pressure on IT departments to develop a larger variety of mobile apps in shorter time frames. Gartner suggests some best practices in their press release that includes prioritisation, process, use of RAD tools and mixed-sourcing.
My thoughts on this are that while RAD (cross-platform) tools might be ok for internal use where users are more forgiving, their use on customer/consumer facing applications usually results in too many lowest common denominator tradeoffs in terms of functionality, performance and look and feel. I think that lack of productivity in the enterprise has a lot to do with how app development is being done and using RAD tools is trying to fix the symptoms rather than the cause – which then causes new undesirable side-affects.
The companies I come across tend to be of two types. The first, as Gartner identifies, have been internally arguing over who and how mobile development should be performed within the organisation and such cases usually result in separate parts of the company going it alone with separate outsourced work. This causes many internal and external problems, one external manifestation being multiple app publishers from one company.
The second type of company I have seen is those trying to do it all in house and running up against productivity barriers. There is often a common theme of building things from scratch rather than re-using open source libraries due to not knowing what libraries are worth using. There are also other common problems such as using non-iterative processes, no tracking tools, not creating domain specific libraries for re-use and lack of knowing what to test. Experience how to best go about things and productivity are related.
In many cases enterprises just need a little extra help via consultancy or a single, experienced ‘head of mobile’ who has seen and experienced most of the problems.