Counterpoint has a new infographic based on data from their latest Mobile Market Monitor report showing mobile handset and smartphone shipments. The report covers over 75 OEMs globally. Global phone shipments grew 4% annually. Three in four mobile phone shipped globally is smartphone.
The following chart is for smartphones and shows which OEMs and, by inference, what platforms are most popular in the various geographic regions…
Last June I wrote about initial screen empty states, their influence on users’ decisions to re-use or abandon an app and gave some alternative implementation options. However, while it’s ok to have an implementation startegy it doesn’t help if you don’t know exactly what you are going to to display instead.
Benjamin Brandall has a recent article on TechCrunch where he considers what might be placed in those empty state screens. I recommend you read the article to learn how to inject emotion, incentives and positivity as well as use the empty state opportunity to promote the benefits of using the app.
I have a particular interest in Bluetooth beacons because I have worked on a few projects that have used iBeacons. For the uninitiated, Bluetooth LE allows beacon unique ids (and sometimes extra information) to be seen by smartphones without having to pair devices as was the case with previous versions of Bluetooth. It also uses lower power.
The id in the advertising data can be formatted as either an Apple iBeacon id or Google’s Eddystone-UID. Google also has the facility to broadcast a URL that can be launched via Chrome and Opera web browsers or an app. However, most of the effort at the moment is involved with apps that do things when they see the ids. This obviously needs a server side to map ids to things to show or do.
Many companies have sprung up to integrate all of this and most are currently trying to monetise by charging a monthly fee for a generic server side and selling custom or re-branded beacons under their own name. Google partly threatened the server side monetisation model when they announced Eddystone’s free cloud beacon backend that can equally be used for iBeacons. However, as I previously mentioned, it’s a headless backend and you still need to create some type of web UI.
All this has just changed. BeaconControl has released, a free open source UI and backend for managing beacons that will put pressure on beacon solution integrators.
I believe these companies will now need to specialise in order to survive. This specialisation might take many forms. One might be to concentrate on unique facilities that only their combined more-customised beacons and platform can provide, for example, beacon battery health. Alternatively, they might produce more specialised backends suitable for specific usecases such as museums or retail where the user experience and in-app actions might be better if they were more oriented towards those domains. A third opportunity is specialising in management. As evidenced by Brooklyn Museum, the setup and location of beacons, creation/entering of data, ongoing monitoring and support of venues can be large tasks that are sometimes under estimated.
AppAnnie has a new report on the use of apps by top retailers, particularly in the US, UK and Japan. They conclude that apps are increasingly vital to strategy.
The report gives some great examples of how top retailers are using apps. For example, US drug stores are building in loyalty through repeat prescriptions and personalised dose reminders. Boots in the UK links to the customer loyalty card and provides personalised offers. Low cost retailers in UK such as Asda and ALDI have apps that allow people to find the best deals. Large stores, such as Target in the US, have interactive maps to help people find items.
These examples demonstrate how the same kind of app (i.e. retail) can differ a lot from store to store. I think the key is to ignore the stereotypical retail ‘shopping’ app and instead find what’s unique or different about the store, from a consumer viewpoint, and play on that strength within the app.
I previously wrote about the new Android M Permissions scheme and how, while more transparent permissions is good for everyone, they introduce a lot of complications. These complications are yet another example of something that developers usually know a lot about but their product managers and some designers won’t know how to resolve. This leads to lots of trouble agreeing/deciding how screens and messages should look and feel, especially when developers aren’t included in the pre-development stages of a project.
There’s discussion that even top apps might be avoiding the move to targeting Marshmallow so as to avoid the complications. I have one such client project where I did some small changes that involved fixing on M devices but I didn’t have the time budget to go through the new permissions implications with my client. Hence the app stayed targeting Lollipop. I have another client who isn’t interested in M at all until it is seeing a greater uptake on devices. I suspect these scenarios are typical at the moment. However, most apps will one day have to ‘bite the bullet’.
This week’s Android Dev summit, particularly day 1, has some great recommendations on to how to handle the new permissions scheme. However, the real problems are with edge cases that can seriously bazooka your app. The first was an Android Dev summit audience question and involves what happens if the user taps “Don’t ask again” and the user then has to go to App… Settings to fix the problem, The Android team said that if this happens, you have lost the trust of your user and that’s that. However, Manideep Polireddi has some thoughts on how you might recover from this situation. Another edge case is if the user does “Reset app preferences” as explained by the CommonsBlogs.
Stepping back, is all this worth it? What is this all about? There’s a very recent article on the Forrester blog where it says…
“Consumers are more willing than ever to walk away from your business if you fail to protect their data and privacy”
Some might say that this is something for older users and that younger millenials have a different attitude to privacy. However, the Forrester research shows this isn’t true…
Forrester says that privacy concerns are very much alive and are set to be a competitive differentiator in years to come. For apps, this means that those that do it well will be rewarded with better user retention.
Skyhook has a recent article and infographic based on a Research Now survey into consumer attitudes into keeping location services on. 50% of users are concerned about privacy, 23% don’t see the value of location data and 19% think that location services drains their battery.
Skyhook recommend developers concentrate on the First Time User Experience (FTUX) to tell users what data is being collected, why and the value in keeping it turned on.
Also don’t forget that on Android, as of Marshmallow, Bluetooth LE beacons (iBeacon and Eddystone) also need coarse location permission and location ON to detect in background. This is actually a functional regression in Android as older previously working apps now fail to detect Bluetooth LE beacons in background on Marshmallow phones without this permission and location ON.
I have updated my Mobile Development Primer with more recent relevant content.
Many people, particularly individuals or startups, approach me who have an idea for a mobile app but have no experience of creating software or mobile apps. This site contains thousands of posts, created over 10 years, with lots of insights for startups. However, the blog-style format isn’t very digestible for people who ask me how to get from idea through to development.
The Mobile Development Primer lists some of the things startups should be thinking about when considering mobile development. It links to relevant posts on this site to give more detailed insights into specific areas.
INSIDE Secure has a new infographic showing that 17% more consumers will start using mobile payments over the holiday season. Nevertheless, security is still a big concern…
This correlates with previous research by Accenture where I commented that users need more motivation to pay by mobile to help overcome the security concerns.