Showing posts with label mobile. Show all posts

Mobile: Web vs Native (again)

It seems like by now, pretty much everyone has weighed in on the native vs web conversation for mobile development, and being as I haven't yet, I thought why not? The age-old question being, should you make a native mobile app or just go with a standard responsive website? (or just use some common technology to wrap up your mobile website in an app).

The reason that I started thinking about this again was because an article as circulated at work, which seemed to be saying that you should do both native and web, as they have different strategic values - which, whilst I largely disagree with that, I think the underlying point being made was that there are different reasons for going down either path.

A quick caveat:

I will get this out the way up front - I'm not talking about any scenarios where you are in a very mobile-centric business - so if you want to make use of phone hardware like camera etc, or you are specifically a mobile-first type app, or one that is intrinsically linked with the mobile as an identity, then yes. Native is the only option.  This discussion is more for normal existing businesses that might (or not) already have a website and is at the point of inflection of whether to  build a native app or not11.

--- 

So, native or responsive web?

My general rule of thumb is as follows: Don't go native.

You would be right in thinking that's a fairly sweeping rule. But I think probably fair - and whys that? I think there are two primary concerns that make the cost and effort with building a native app not worthwhile:

1. Discoverability

The web is a great place for discovering things - just the word "web" portrays it quite nicely, from any given point there are undoubtedly loads of little threads(I'm talking links) that could be followed at no real cost - assuming it's not a dodgy looking link, the barrier to prevent someone following a link is practically non-existent - So you read a nice featured article about a new company/product on a blog, at the end of the article they link to their site, you click it. I mean, why not right? if it ends up looking crappy the back button saves you and what have you lost? a few seconds? Easy.

This is something that is clearly missing in the mobile app eco-system - assuming you aren't some behemoth of a company that millions of people want (or need) to interact with, a mobile app isn't going to help increase your customer base. Sure it might give you a richer experience for the handful (I'm talking in web scale here) of customers - but its not going to help grow customers, it will cost you time and money to produce/maintain and that's before you start having to work on directing existing customers to your mobile app:

So again, if you are a bank, who has millions of customers who have specific, regular needs to transact with you, or if you are a hot new social-local-sharing company then sure, go for that enhanced UX.  But an app is only going to be any good if the users already have the intent to transact with you. If a user is browsing the web on a mobile, your conversion rate is going to be a lot higher with a link through to a responsive website than to an app download.


2. Scalability

For me, this is the deal breaker. I'm not talking technical scalability - will your servers be able to withstand the un-doubted, soon to be approaching, mass of people who will rush out and download your app as soon as its released (see my previous point), I'm talking customer-to-app scalability.

Imagine your a regular business - you have thousands of happy customers, maybe your website even gets tens or hundreds of thousands of uniques a day - so lets build an app right?

The problem is, there is a limit to how many apps that a user will have on their phone - on a standard android phone you will likely have two screens worth of app icons when you un-box it, so there is a limit to how many more apps they will install - Again, this is how it is not like the web: visiting a website is free, but there is a much greater barrier to installing and keeping an app (let alone using it) - and when the phone is getting full, or sluggish, or the user wants a bit more space to download a show from BBC iPlayer, then the apps that aren't regularly used are going to get the chop.

When you are competing with limited resources and the big players - Facebook, messaging, banks, geo-based stuff (maps, uber etc) - then it's hard to make a compelling case for the phone user to keep or even install the app.  This demand makes it even harder to convert your loyal web customers to mobile - and weighed up against the fact that you could make an awesome(and consistent) responsive web experience, the choice looks more clear for me.


Benedict Evans says you should build an app if people are going to put your app on their homescreen, which seems like pretty sound advice - and given the size of a a phone homescreen, this makes for fairly few companies.

Final caveat:

If you are building the app because it came out of a side-project organically, or a hackathon or something similar, then by all means - there's lots of fun to be had and lessons to be learnt in building, testing and launching a mobile app - so if you don't mind the potential cost then definitely go for it!
Continue Reading

Hello Facebook..

I have been away on a mini-break for the last few days, and whilst relaxing I was mentally planning out a blog post about mobile phones as identity and the social platform they provide (again!), then, I woke up this morning to Facebook's announcement of their Hello app.  In short the app will attach FB user details to phone numbers, so if you get a call from a mobile number you don't know, but have the app installed on your phone, it will attempt display FB info to identify the caller.




For my money, this is a very smart move.


Moving down the stack

One of the questions for the future mobile landscape is whether players like Facebook and Amazon can move "further down the stack" - that is, to start being more core to devices, or making their own. Amazon have tried with their Kindle Fire phone, and Facebook had Home - both bombed out, however, and there hasn't been much to suggest that there is more promise for them.

However, Hello seems to me like it could be a small step to bridging that gap.  The app is simple in itself, and done well I could see it being very popular - after installing, it doesn't need any active engagement from the user, but (hopefully - without having tried it myself) just sits there and enhances the users phone experience (as long as they don't try and do anything stupid, crazy annoying notifications, battery hogging etc) - As a simple enhancement to the incoming call screen, I can imagine pretty high retention/install rate - because why would you go back to unknown numbers?

One reason this could be a huge win for Facebook is that this step could make Facebook more core to the mobile device (and seemingly appear more and more like just part of the OS).  If you have the app installed, and miss a call, I would expect the missed call notification screen to be Facebook's Hello - with the normal stuff you would expect - so and so called you, return call, send message etc - which will inevitably give FB the hook to drive users to FB messenger, WhatsApp etc - This is a chance for FB to hijack the core functionality of the phone and drive traffic to its other properties, quickly FB messenger could become the default messaging app.



Your phone as your identity & network

This is something that I have ranted about before - there are two powerful and fairly unique traits of mobile phones that have the power to really disrupt the social/technology/online space:

Your phone is your identity - Whilst people continue to struggle to fix online identification/authentication issues, with a host of different providers offering Login-as-a-Service (Twitter, Facebook etc) and lots of people complaining about the proliferation of user logins/passwords that need to be remembered, the phone offers an interesting solution to that - Granted, phone numbers are not for life, but they offer simple, unique identification of individuals, plus, with two-factor authentication, it can be simple to verify that the person attempting to login is in physical possession of the device.  And with more moves to ApplePay and NFC payment with your device, this identity/device becomes even more tightly coupled.  

By Facebook tying your phone number with your profile it is an impressive move to help future proof their platform: so your phone is your identity? Well now your FB profile is intrinsically linked to that too.


Your phone as a social network - For a long time, Facebook have been the dominant force in social networking. Despite Google's effort with Google+, they haven't been able to displace the social network king. Do you think they struggled because they couldn't match Facebook's superior product? You think people stay at Facebook because they just love the features so much? Of course not. They stay because of user inertia - the feature that keeps users at Facebook is the network effect, no one would move to Google+ without the rest of the network, and how to you move your network?  As if to prove this, there are fairly regular outcries from the Facebook masses when FB changes their layout, or people find out about some terrible clause in the privacy policy - but do people leave? Nope. They just get on with it and keep using Facebook.  After all, the users are the real product, not the software.

Now, mobile phones change that a bit.  Traditional online social-networking basically just models the real world network of friends/colleagues/etc - In your real life social network, you are the node in the graph, and your mobile phone basically represents your node - If you think of Facebook as a centralised social network, mobile phones are a distributed social network (in other words, Facebook knows about the entire graph, and keeps that information centralised, but with your phone you know about your immediate neighbours in the graph - e.g. the people you have contact details for, but not the rest of the graph).  This is a pretty powerful idea - and this is what has made it possible for apps like SnapChat and WhatsApp to enjoy sudden and un-precedented user growth where non-mobile only apps (Google+) haven't.

If we add to that the fact that modern smart phones aren't just an address book - they have your photos, they have your videos, they have your messaging, they have your friends - is there much on your Facebook profile that you don't have (the ability) to have locally on your mobile phone?

All of this makes the smart phone and the real world mobile connections a very powerful platform for anyone to come and disrupt Facebook's crown - So this move by Facebook again just helps establish them as leading the mobile-social platform, not just an old internet company trying to compete.



An aside - Google needs to catch up

My original thinking for the blog was going to be about how Google should, in my opinion, be capitalising on the Android platform as a social network, and rather than trying to convince users to sign up to Google+ (or Wave, or Buzz etc) focus their efforts on making Android a more social OS and make more of the Android as your identity.  They would have to do it carefully with regards to stuff like "private by default" so not to cause uproar, but if they could effectively make all their Android users a node in the social network, then all of a sudden they could find themselves with a pretty good social network, and can start thinking about how to add value to the product.  Furthermore, with Android being the OS (as low down the stack as possible) then they would have a lot more options with regards bringing together all the aspects above - Your smart phone knows instantly when you take a photo or record a video (because you are doing it with the device!), it knows your location, it knows when/who you are messaging, it knows who your friends are - some nice usability around that and it starts to sound like a very strong value proposition!
Continue Reading

Twitter API & Smartphone as your identity

At Twitter's Flight conference this week, they announced a couple of new toys for developers: Fabric and Digits.

Fabric is a new platform for building mobile apps

The Fabric platform is made of three modular kits that address some of the most common and pervasive challenges that all app developers face: stability, distribution, revenue and identity.


It seems everyone has to be building a platform these days, but really it sounds like Twitter, having previously shut down developers on their API/platform a while ago, realised that actually letting devs on their platform (now that it includes advertising APIs - thanks to their MoPub acquisiting a while ago) is going to be profitable for them.

Maybe it will be well received, and the way the market changes maybe people will go for it - but I wouldn't be building an app based around a Twitter platform given their track record.  The company are a lot older, and maturer now (and they probably released their API too early last time around), but it still seems like quite a risk to have something as central as login/revenue tied to Twitter (I dont like third party logins anyway..).



Anyway, the much more interesting product they released was Digits - which allows sign-in with your mobile number - which as I have ranted before, is an idea that I love, and seems like a really smart move by Twitter. Both in as much that it will move twitter to that space of smartphone is your social-identity/network and also offers a lot more value than just another platform that serves ads and supports login etc.
Continue Reading

Coming Soon..




New mobile-first product currently underway..
Continue Reading

Securing your mobile API - Spring Security

Having recently posted an article on an approach to securing an API for a mobile app to use, here are the details of how something similar can be configured using Spring-MVC and Spring-Security (this post uses Java config - if you are un-familiar with Java config rather than XML then check out my previous post on the topic).


Basic webapp registration and authentication

The first thing we need is a basic web app that supports user registration and authentication.  I am not going to go into the details of how to build a Spring MVC app with basic security and users etc, so will assume you are familiar with basic Spring MVC architectures. For an example Spring webapp that supports user security and registration, you can check out one of my several random webprojects on GitHub.


As I am only looking at an API application - no web client right now - All I need to start with is to set up the security for registration and login:



Ok, so the above is my web security config - the configure() method is what is defining my URLs and the security - it's pretty basic, I state that anyone can access the resources (for css etc), the log-in and the sign-up and everything else should be authenticated.

The only parts of interest are:
  1. In the registerAuthentication() method, as well as the normal setting of UserServices and password encryptor, I am also adding a Remember Me Authentication provider
  2. In the configure() method on the formLogin component we are also setting a RemeberMeService
  3. We are setting @Order annotation on the class with value 2

This class basically just sets up the web part of the security, so all pretty straight forward.


API security configuration

For clarity and readability of code, I like to create separate configuration classes for the different aspects of security - Below is the security config for the API endpoints:



This file is a little more interesting, let's have a look at what is going on:
  1. First of all, we define @Order with value 1 - as you have probably guessed, this defines the order in which the security config is loaded/considered - we want the API security to kick in first
  2. In our configure() method, we first specify an ant matcher so the rules in this config only apply to URLs that start /api/
  3. We state that all requests to this pattern must be authenticated and apply a RememberMeAuthenticationFilter to run before the Basic authentication chain runs
  4. We also set the session management to be stateless - this refers to serverside sessions, as we don't want to retain server session state
  5. We then configure the Remember Me beans - this is all standard and as per the Spring guidelines here.  The only difference is that we have a custom TokenBasedRememberMeService - that we will look at later.


Security flow

Below is the basic security chain that we get as a result of the above confirmation
  1. Request comes in - we check if it matches /api/**
  2. If it does match, then all requests must be authenticated - and run the RememberMeAuthenticationFilter 
  3. The filter simply uses the RememberMeService and AuthenticationProvider to check the token/cookie value to see if it can pre-authenticate the request.
  4. If it has matched the URL but doesn't authenticate on the filter, then it will 403
  5. If the URL does not match /api/** then the request starts the second security config
  6. If the url matches the resources, sign-up, sign-in then allow the request to complete, otherwise require authentication, so (default spring behaviour) direct all other requests to the registered login page ("/")


Customising remember me

 So the good news is we have been able to re-use core Spring Security functionality so far, so no dubious hand-rolled solutions - We use the standard security chain, username/password authentication provider and Remember Me filter/provider. The only thing that we have to modify slightly is the RememberMeTokenService - the default behaviour for Remember Me assumes that the token will always be provided in a cookie (designed for auto-login websites if you tick "remember me"), and as we are extracting the token from the cookie and passing it in the request header instead, we need to modify the service class to grab it from the header.

As you can see, it's pretty simple - all we are doing is overriding the default extract cookie method so it looks in the request header instead.  I would really recommend you read through the source code for the RememberMe classes - starting with the filter - and seeing what is actually happening between the Filter, token service and auth provider, it's pretty clear to read and will help get a good understanding of what is going on.


Caveats

There are a few things to consider here:
  • This is fairly basic security - requests should be made over https to prevent man-in-the-middle attacks, alternatively look at a solution like Amazon use whereby the token isn't passed, rather it is used to hash the request body which is then checked on the server side (prevent the need for sending the user token every request)
  • This is currently open to anyone to use/build against - there aren't any checks for app key/secret etc - so you would probably want to build that in to prevent other parties building apps against the api and getting a user token in the same way.
  • I'm not a security expert - this is just my interpretation of the Google guidelines using Spring Securities RememberMe classes. This is really just a thought experiment, getting up to speed with how Spring Security works in more details and experimenting with mobile app fun. Use at your own risk..
Continue Reading

Securing your API for mobile access

So I have been thinking about potential options regarding securing a server side API for use by mobile apps. No matter what question you ask on the stack exchange network, the answer will always come back as "you should really use oauth", which I guess we should consider as a half truth.

Having used OAuth on several occasions as a client (accessing Facebook/Twitter/LinkedIn/GitHub etc), it was naturally the first option that came to mind for securing my API.


My requirements right now are simple:
  • I am experimenting building an Android mobile app that will use a server API (webapp & API will be built using Java & Spring stack)
  • The app I am experimenting is mobile-only (no web client)
  • It is not going to become a public API (e.g. won't be supporting other apps/sites)


I guess the key point is that I only intend to expose the API to my mobile app, and not have lots of comsumers of the API - and given the complexity of implementing OAuth, it seemed like it would be overkill as a solution.  A big benefit of OAuth is that it supports client/application keys.


So I started looking around for other ideas as to how to do this - I was (and still am) curious as to how Twitter/Instagram secure their APIs for their own applications - I know that the Twitter API is secured for public use using OAuth, but the interesting question is how they secure their own application key/secret. The problem with mobile apps is that an application key needs to be stored on the device - and whilst Twitter offers severely throttled API access using OAuth (register an application, get a secret app key etc), their own apps are obviously not throttled, so it seems like it would be a challenge to keep their application key secured, as if its in the app code, then its subject to de-compilation.

Anyway, getting close to resigning to the fact that I was going to have to use OAuth I came across this one-pager from Google. The guide suggests a much simplified approach with the following basic steps:

  • Build an webapp on your server that has a login page 
  • From your mobile app, embed a WebView of the login page
  • Upon login to your app, return a cookie with a token value that can be used to log in your user on future requests - ideally re-using your frameworks Remember-Me type services so not to have to hand-roll your own
  • On every API request include the token in your request header to authenticate (again using the Remember Me services)

The fact that it was a suggested approach from Google is pretty good, and it's a tonne simpler than negotiating the OAuth dance, so I thought I would have a look at getting this setup.


This is all good - but really, the advice to use OAuth is a half-truth, as if you ever have to scale your application, and think you might one day have/want to open it up do other developers/clients then OAuth is the way to go - You won't get much love from third-party developers with a non-standard approach to securing your API.


So.. how can it be done with Spring? I will cover that in my next post later this/next week!
Continue Reading

Flat Design (& Android)

"Flat" is currently a big design trend, with pretty much all the big players getting involved.  One of the earliest big-hitters in the field was an iOS app called LetterPress (incidentally, the designer behind this has recently been working on Facebook's "Paper" app - which is also a pretty nice experience)

http://www.atebits.com/letterpress/

The trend found a surprising champion in Microsoft with their Windows Metro look (Windows 8, Windows mobile, xbox), before Apple(iOS 7) later joined the party as Jonny Ives took responsibility for software design as well as hardware. Now many of the most popular sites are sporting a flat look (Google flattened its logo, twitter went flat, even NerdAbility.com is sporting a flat design).

Flat design is about being more minimalist and user-focused - it skips the fanfare of effects or lifelike details for apps/backgrounds/controls and favours simple, clean, crisp minimal interfaces. It's kind of the opposite to the skeumorphic approach - which is using lifelike textures/look&feels for things (the obvious examples being on iOS pre-7 where the contacts have graphics in the background that make it look like a leather address book, or the notes app that has a lined paper background etc).  It avoids fancy 3-d fonts and elements, avoids shading, shadowing, textures - and just uses simple colours, fonts, shapes to quickly convey meaning (see letterpress image above - no fancy rounded corners, fonts or textures - just simple block colours).


Flat Android Design

There is no reason why you can't design an Android app following flat trend, in fact lots already have - Thankfully, as a core part of the flat trend is simple, it is simple to build flat looking apps in no time at all.

Fonts

There isn't any hard and fast rule on fonts really - obviously it should be simple, clean and understandable - for this reason, clean, light san serif fonts have been a common font style to use. The most famous, as used by Microsoft, is Open-Sans - this is the font used across their Windows8 OS. It's popularity also boosted by the fact that it is freely available on Google Fonts, so has swept the web in a fairly big way.



Thankfully, as it happens, Android (since 3.0) has come with packaged with a lovely san-serif font called Roboto. The range of weights, especially the thin and bolder weights allow you to achieve similar aesthetics in line with common flat design, whilst presenting a professional, clean & simple typography.  The obvious disadvantage of using the font is as it's built into later Androids, it's fairly widely used.  Personally, I like to use it. I use the default Android font largely across my apps, and if I want to add a bit of character to a heading/title then I opt for the thinner version of the font.


Buttons

Buttons are an interesting one.  Whilst the flat trend is becoming more pervasive, there are still questions regarding buttons. Buttons have always been skeuomorphic by design - the shading and texture to show a raised/bevelled button (like a real life button that you might press) is classic skeumorphism, and whilst this is simple to switch to a 2-D, flat look&feel, there are still arguments as to whether you should do this - as the button look and feel communicates to the user that it is a button - it is so widely accepted a metaphor, people seem concerned that without the detail, people may not understand it is a button. How can they tell if something is a button or just a coloured block quote? (see this stackexchange question on the topic)

http://www.nngroup.com/articles/windows-8-disappointing-usability/

 Above is an example from Windows 8 controls - as pointed out on the StackExchange link, all of those icons are actually buttons, along with the "Change PC Settings" - That could be fairly confusing, and would be an example of how not to design flat buttons.

Personally, I like flat buttons - as long as you take care to design the page so that the buttons are clear, and the form/page obeys general good UI heirarchy - an example of a simple form I was creating for an app with simple flat buttons is below:


As you can see, designing forms/controls that obey standard UI heirarchy and normal metaphors then it is still incredibly simple and clear what are buttons are what aren't. (I know it doesn't look like a fancy form - there are other decorations elsewhere as well though!)


Colours

There are of course, no rules about colour - but there are trends. A simple google image search for flat colours will give you lots of palettes, and there are also lots of great free tools on the web for building palettes

http://mikehince.com/design/amazing-colour-resources-for-designers/


Adobe's Kuler being a great example (lets you build schemes as well as share them with the community and look at other schemes)
Continue Reading

Observations on the WhatsApp Acquisition


Yesterday's acquisition of WhatsApp is a great example of a few trends throughout the industry:

1) The importance of product

WhatsApp currently has 450 million active users, double that of Twitter, and is still growing at an insane rate (which probably hurts even more given Twitter's recent growth struggles), why is that? Sure, in no small part it is because they are the first major company to really disrupt and take on the SMS/MMS monopoly - Why ever pay for text messages through your provider if you can send pictures/chats to anyone in the world for (essentially) nothing? - but their success in becoming that major player is their single focus on the core of their product, they wanted to provide mobile messaging - and thats what they focused on. As users grew they could have spun out with gaming/video chat/desktop clients/etc but they stayed focused on their core product and did it well.

It is telling that founder Jan had this note stuck on his desk:
No ads!
No games!
No gimmicks!

Also, choosing to monetise by annual subscription rather than in-app adverts showed dedication to the statements above - having used pricing as a way to throttle growth to a rate they could manage, they grew confident that the model would work and didn't need to detract from their product with  gimmicks or ads.

Whats more, by focusing on the simplicity and usability of their core product, it also meant they could focus on the technical stability of their platform -  I doubt if they had spun out they would have been able to maintain their impressive tech stats - 32 engineers, 450million active users, 99.9% uptime.  Twitter's "Fail Whale" was infamous during their period of growth as their platform couldn't scale to handle it, but with a more accelerated growth WhatsApp's simplicity has allowed them to maintain 99.9% uptime - failing to keep platform stability could have easily seen them lose their position in the market and not be signing the deal they have.


2) The importance of mobile

Mobile is the platform of growth for the future. We are, and will continue to see more and more mobile-first (if not mobile only) startups. Instagram, Snapchat, WhatsApp - the three biggest recent startup exits - all mobile focused.

And should we be suprised? Let's have a look:
  • On average, people use their phones 150 times a day
  • There are currently ~1 billion people using smart phones
  • But, there are still ~6 billion using feature phones - so huge room fro growth

Smartphone usage has exploded, other mobile computing is growing as traditional computing devices decline.  There is a huge market opportunity for new mobile users, and for many parts of the world, mobile is providing first experience of the internet.

What's more, the mobile eco-system is offering a new opportunity for startups to take on social incumbents - For a long time, Facebook has had the crown of social, and could not be tumbled by others efforts, primarily because it's where people are. It's where people's photos are. It's where people's social graphs are. Sure Facebook's design is kinda clunky now, and kinda ugly, with terrible ads all over the place, but who is going to try and convince their entire social graph to move?  Exactly.  But the mobile eco-system offers something different - your mobile device contains your contacts/address book, your photos, your videos - more and more, your mobile device is becoming your social platform that really holds your social graph.


Mobile is the future.
Continue Reading
Subscribe to: Posts (Atom)