Accidentally in Code

Tag: native

  • 5 Reasons to Build a Native App

    5 Reasons to Build a Native App

    cellphone
    Credit: Flickr / Janine

    Notifications

    This is a really common reason to want users to have a native app, but the question is – do users actually want alerts for this product? And if so, how many? For example news apps – they could sent an alert for every new story but that would be excessive! It’s important to be selective.

    If the app overloads on notifications, users have a choice between turning off notifications for that application, or removing it. Removing it takes fewer taps.

    This is the only option that isn’t available (at all) in a web-app.

    Offline

    Offline experience natively is really pretty easy. In the browser, much much harder. If offline is important (the biggest place I notice the lack of offline is my RSS reader, which renders it basically unusable on the tube) it usually makes sense to go native, depending on the complexity of your application and how much needs to be reimplemented.

    Location

    One-off location is obtainable through the browser, but anything that requires more than that, e.g. ongoing location, or location-based alerts, needs to be native.

    Uber is a good example of this.

    Camera

    You can upload pictures through the browser (as of iOS 6), but it’s hard to imagine Instagram succeeding quite as much with a webapp. If images are an important part of the experience, the image selection and picture taking experience is much nicer from a native app.

    Audio

    Background audio requires that the app be native (with some limited exceptions), if your app uses a lot of audio, for example museum apps are very audio heavy, a native one will be able to be played in the background with the screen off (screen is a major battery drain), whereas this is not the case with the mobile web.

    Peak App

    I prefer native apps – to build, and to use. They are faster, more convenient, better at saving state. But, I only want them for things that I use a lot, or have a short period of high usage – museum or conference apps are good examples of this. I don’t tend to download them unless I’m on wifi.

    Heathrow Airport now has a native app. Which I have taken to be a sign that we have reached Peak App – I spend a lot of time at airports, but I can’t fathom wanting such a thing.

    There seems to be a knee-jerk reaction sometimes that “going mobile” means “build a native app”, but I don’t think this is true. The mobile web is one option, but I think more broadly, sharing and other social apps are also part of it. People are tasked focused in the use on mobile. By which I mean, they’ll think “I should find somewhere to eat”, or “I need to check my flight time” rather than “I want to explore everything that is going on at this airport”.

    Restaurants, for example, as people check reviews, and menus on the go. Personally I rarely go anywhere below an 7.5 rating on Foursquare (exceptions are usually personal recommendations). This is part of how mobile affects the restaurant business, but is the answer for each restaurant to have a native app? No, that is clearly ridiculous (although one chain does have one), the answer is about making sure that information about the restaurant is in the existing apps that users use to discover and decide where to eat.

  • There’s An App For That is Not A Mobile Strategy

    There’s An App For That is Not A Mobile Strategy

    Dooky! Pick up the phone!!
    Credit: Flickr / matthijs

    People throw the word “mobile” around a lot, and my observation is – they all mean different things, but think they are talking about the same thing.

    When I talk about mobile, I want to talk about how everything changes when everyone has a device this powerful on them, all the time.

    “An app for that” only scratches the surface for how things change (that link contains the most fascinating stats on mobile usage I’ve seen, and the surveys were done Q1 2012, the world has only become more mobile-centric since then). And sometimes people talk about “not having a mobile experience” – that is nonsense, the mobile experience is whatever happens (or doesn’t) when the user tries to use whatever it is on their mobile device.

    A restaurant with a flash only website has a “mobile experience” – it’s just not one that makes you more likely to eat dinner there.

    There’s a fascinating document on mobile insights from Ford (related article), which is interesting because they are a car company, but in this context makes sense, because everything changes.

    Individuals have mobile strategies – phone stacking is an example. When out for dinner with friends, cellphones are placed face down on the table (pile optional), and whoever touches their device first, pays. That’s part of a mobile strategy, aiming to address the need to be mentally and emotionally present for the people we are physically present with. The book Alone Together covers so many examples of individual disconnection as the result of devices.

    I wear two activity trackers with a third on the way. Part of my mobile strategy addressing my need to stay active (and measure my mood and sleep as a result).

    One of the things I find fascinating, that no-one seems to talk about, is how people take more pictures as a result of having these devices, and they are shared much faster. See how Apple is the second most popular “camera brand” on Flickr.

    Also fascinating to me – the rise of disconnected vacations (as told by journalist, as taken by brain scientists, mine, Full Contact’s paid paid vacation policy) as a means to escape from the constant connectivity and demands.

    People ask me what North Korea was like, I say, “do you ever feel you have decision fatigue? You can go to North Korea and make no decisions for 6 days.”

    I think decision fatigue must be worse as a result – every time my device beeps, and it beeps so much more because it’s not just calls or text messages but instant messages, and Facebook likes, and Twitter mentions, and emails. And I have to decide whether to look, whether to read it, whether to respond.

    At the level of creating user experiences, I think the question is not “web or native?” but rather – what is different? What do users want?

    Web or native is a much easier question to answer.