Since January first, I’ve been posting a picture a day on photo.cate.blog. Now I’ve been doing it for long enough to consider it a proper project, I asked one of my colleagues for a suggestion for a better theme, and she suggested this one – Cubic. I really like it.
An incomplete list of what I’m getting out of it:
Using the WordPress apps every day.
Doing so in less controlled environments: blogging in spare moments and odd places (e.g. On the chairlift whilst skiing).
I’m working on a talk about running effective mobile engineering teams – I’d love to know what questions you have about this, what you worry about when it comes to mobile teams in your organization, and what you’ve found most helpful to communicate about them. Comments or email or DMs on Twitter welcome!
Title: YOLO Releases Considered Harmful – Running An Effective Mobile Engineering Team
Organisations often worry about their mobile teams. Sometimes they are a bit separate. There’s often this inexplicable hostility to mentions of “React Native”. Why do bug fixes take so long to get to production, and what are all these certificates for, anyway?
In this talk we’ll cover the realities of shipping compiled code, the woes of the app stores, and the infrastructure challenges we haven’t figured out yet. You’ll leave with a better understanding of the realities your mobile teams may be struggling with, and some strategies for how to help them – and your organisation – build an effective mobile team that ships regularly. And yes, you’ll finally understand the React Native argument, too.
Speaker notes from a talk I gave earlier this year at Try!Swift, and 360iDev.
There was an article I read last September that profoundly affected my thinking. It was by Sarah Tavel, and is called “Times have changed — going after dollars vs minutes”. She breaks products down into minutes – which I think of as attention as a metric, and dollars – which are things people pay for, and compares two periods, noting that the earlier one (2008-2012) had mostly minutes raising Series A funding, and in the later one (2012-2015) it was a balance between minutes and dollars.
She writes from a VC perspective, but from an engineer, from a design perspective, these things are also entirely different problems. It reminded me of a conversation I had with a friend a long time ago – she was contemplating a job at Zynga (remember Zynga? I told you it was a long time ago) and our conversation was around how we would feel, whether we could actually do a job… where what we were building was a form of digital crack.
Addictive games. Digital crack. But what this article did was expand my view of what digital crack is. How many jobs in tech involve building it. Not just games, which have never appealed to me, but any kind of social media. A long time ago I worked on G+ and perhaps the problem there was that instead of digital crack it was more like a digital multivitamin.
Digital crack is about the thrill of unpredictable reward. It’s creating a place where hours pass – with user attention spans on mobile being short we’ve cut it to minutes pass. It’s about pulling people back in with notifications. It’s about a careful balance between sucking people in, but not being too annoying, because we’ll drive them away.
Digital crack is a pejorative phrase, but digital crack is not inherently bad. I love Twitter as much as the next person, and my current digital crack is actually Duolingo. I spent a lot of time this year in South America and I’m working on hablando más español.
And I realised I don’t want to build digital crack. And I’ve always known this, if I look at the things I’ve worked on – I built most of the first Google presentations experience on iOS, I ran a team that built a location based B2B app. Most recently I was working at Ride where we built something to help people car pool. My passion project for a long time has been an image processing app – note processing not sharing. I look at my career choices, and that brief lapse in judgement when it comes to G+ aside, I have chosen to build things that help humans achieve things. Tools rather than experiences.
But I think it’s hard because in this industry we laud the digital crack. Attention is the foundation of the business model. This analysis aside, we have the impression that it’s what the VCs are funding. It’s what we’re talking about. Like right now, when everyone has been talking about Pokemon Go. Yes, that second list was balanced, but I’d heard of more of the “minutes” apps.
But if we’re not building digital crack, if our metric is not minutes spent, if it’s actual human effectiveness, what matters? What are we even doing?
Make Complex Processes Simple
Show and Hide
This is my passion project, it’s called Show & Hide. So like I said, it’s an image processing app but what does that mean vs something like Instagram, which is an app that filters images and a platform for sharing them? A process means that we analyse the image and change it based on that analysis. So what Show & Hide does, is it analyses the dominant color of an image and then makes two partially coloured images based on that. The first one showing the dominant color, the second hiding it. The idea is, that it creates those postcard images – you know like the ones of London, the bus is red and the background is black and white, but you don’t need, you know, actual artistic talent.
Anyway, an image is just an array of colours, which we might think of as a grid of numbers. And a filter is just another grid of numbers, so to apply a filter all we need is a little Matrix multiplication. Not only is this a solved problem, it’s one that is done for us by the platform.
But processing an image is not a solved problem, and it’s vastly different based on what we are processing that image for. So my first functional go at this on iOS scaled down the image a lot and took ~10 seconds to run. But the version that shipped, you move the slider and the image changes in real time, and on iOS at least, that’s pretty much the full-sized image.
On a practical level, what did I do? I optimised the hell out of it and wrote it all in C.
On a user-experience level, what did I do? I made the distinction between a process and a filter invisible. It’s a process, but it feels like a filter, which is what users are used to – and what they expect.
Location
When I think about location, I think about Harry Potter and the Marauder’s Map map. Harry is invisible, but he still shows up on the map. This is often when he is being most effective. He – or pretty often Hermione (we all know she does most of the work) – are doing stuff that they can only do when they are invisible.
It’s often clear as developers how location will help us, but if we’re not careful we are too visible. Either by draining the battery, or just being annoying.
I worked on this B2B app called Coordinate. It was an app for tracking your mobile workforce, like they would have jobs and you could route them to nearby jobs.
We needed to do continual background location updates with varying levels of accuracy. For high location accuracy we needed 8 hours and like, ~15m 5minute data.
We came in to do this on iOS when it had already been done on Android, and so people didn’t really understand how different it was. But the iOS location API wasn’t designed to work that way. When we just turned it on with that level of accuracy, the battery burnt down in an hour, especially if you were say, riding a motorbike on the highway.
We weren’t exactly invisible there.
So we figured out thresholds for turning the GPS on and off, tried to be smart about when we would send a location and when we wouldn’t, cached locations, and eventually when caching wasn’t enough – if say, you were on an island with poor cell service, taking pictures of adorable koalas – implemented offline.
Eventually we got to ~12 hours of battery life on high, and for low accuracy our battery usage was barely noticeable. We were actually doing better than the Android app.
We had become invisible.
Glowforge
This is my friend Dan. He’s taking selfies with an owl in Tokyo.
Dan made this game called Robot Turtles with his kids, it was the most backed boardgame on Kickstarter. As part of doing this, he acquired a 10,000 USD laser CNC machine that had to be delivered on a forklift truck.
Here’s the CNC machine, with some children for scale. And on the right are the custom pieces, and a key. Pretty cool, right?
Anyway, Dan’s now CEO of this startup called Glowforge. They make a desktop laser cutter – they call it a 3D laser printer. It’s pretty amazing. Pre-sale right now and shipping later this year. Full disclosure: I’m an advisor, and one of the many benefits of that is that when I go to Seattle they let me play with it.
Here’s some stuff I made on it. It’s really cool, you see the bed, and you move your design over it, and then you press go. So first – because I’m such a programmer – I made a hello world. I printed out a logo for my then-boss. More ambitiously, these are the pieces for a Technically Speaking keychain, and the necklace is the Show & Hide logo, engraved and cut away.
I also made this thing. So this is a picture of my shadow, which I took in Venice. Then Tony and I turned it into a cut, and printed it on clear acrylic. Now when I hold it up to the light, and shine a light on it, I can project my shadow all over again.
I’m not really a physically creative person, so this whole experience was pretty revelatory for me. I was so intimidated at first, but then I discovered that it’s super easy! And super fun!
So you might think the achievement here is getting it on a desktop – no more need for a forklift truck on delivery. And that’s true.
Or maybe that it’s now less than half as expensive. That’s pretty cool too.
But from a software – user experience – perspective – here’s something I think is really, really awesome. Because that old laser printer? Not only is it large, and expensive, and terrifying, to make it cut in the right place requires the user to position the material very exactly.
But Glowforge users won’t need to do that. Probably many of them will never know that’s how it used to be. The challenges of positioning have disappeared. It’s all done using image recognition.
Show Decisions not Data
What Should I Wear?
Weather is the canonical example of this, because how many of us have ever even seen a meteorological report? Well now we have. But with weather we care about the the conclusion – what are we going to wear? What is a good day for that hike?
And so we look at something like this which gives us the conclusion, not the data it’s based on.
When Should I Leave?
Another example is traffic. I have a smart watch, and it tells me when I need to leave. It’s not super accurate, and often it tells me when I’m already on my way, but it’s getting there.
The interim step to getting there was this traffic view – notice the subtle color coding on the map about the severity of the traffic. A really subtle visualization of a lot of data.
What Should I Do?
The first two of these are kinda boring, and predictable – stuff that we’ve all known was coming for a while. But what should I do is an interesting one. This is the problem with FourSquare. They are evaluated like they are building Digital Crack because it’s considered to be a social network, but they are actually trying to drive behavior – dollars in the real world. If I use FourSquare, and I take 5 friends with me, that’s not tracked on the app but it’s a change of behavior way beyond the metrics we see in usage. I found my favourite tea place in Medellin on Foursquare, and now I go there several times a week. That’s a significant behavior change.
FourSquare tries to help me make decisions. It tells me where people go after the art gallery. It tells me where people go who like the things I like. It’s the app that I use that comes closest to making decisions for me. My usage doesn’t demonstrate addiction – it’s not digital crack – it does drives dollars in the real world.
Eliminate Compromises
The UI has always been a compromise. Programmers thought the terminal was fine. Humans wanted other humans. The UI was this thing in the middle. It was a hack that pleased no-one because humans found it so foreign and programmers have generally despised building it. So now we see the rise of Slack as a platform, the increasing popularity of chat based interaction – the idea that no UI is the new UI.
Go Where People Are
This is why I find bots and integration interesting, because they come to where you are and don’t ask you to add another (digital) place that you “visit”. The interaction comes to you. the behavior change seems minimal.
I think this relates to bots being so effective at causing significant behavior change. Who uses Slack? Who has the bot that corrects you when you say “guys”? We had that at Ride, and I saw it changing people’s behavior. They don’t have to seek out this awareness of language, and how it matters, it comes to them. Now most of us have left, we have a new Slack, and we haven’t set up the bot – but I don’t see anyone using “guys”.
Speak Human
This is about meeting the user where they are. And when we think about language here we think about error messages. The worst culprit of inflicting tech speak on humans, we give people this terrifying experience – something has gone wrong! Did they do something to cause it? And we communicate this with an incomprehensible message. More subtly we fall down on this when we focus on what the user does, rather than what they achieve. Kathy Sierra talks about this. She talks about making users badass and isn’t that… well that’s what I want to be doing.
But really what it means is you don’t ask them to learn anything, because you are communicating with them in a way that they already know. This is not just human language, but conceptual language – it’s dragging an image over your material and pressing “print”, rather than trying to figure out an opaque calibration system.
Listen
Human communication is only around 7% vocal content. Some of it is vocal elements, but 55% is non-verbal. Body language, tone, these are all clues to our real meaning.
Digitally we have the interaction, but we also, especially on mobile, have things that we might know, like location, calendar, social media. These are all signals of what is going on with a user, and when we can use them it’s transformative of the UX. When a product appears to learn and get better based on this data, then it requires less and less interaction because the conclusions from that data have got better and better.
…
Here’s the thing…
User experience has been the bridge we built between the way that machines operate and how humans do. It is how we have allowed humans to create and manipulate data digitally.
But really it’s been a hack. This is why movies had talking, humanoid, robots. Because that was the dream – a computer wasn’t a computer, it was a cool sidekick with a super-power – machine intelligence and computational power.
We’re not there yet. Anything that begins to look like the dream has typically been so much of a disappointment that it just makes it seem that we are further away. But putting together this talk encouraged me that we are making progress on this – it’s just different, and so gradual, that until I took the time to think about it, I didn’t fully realize.
Because the experiences we’ve seen in the movies have always been so ostentatious and shiney.
But real progress, it turns out, sometimes looks like nothing at all.
I discarded my Android watch in the UK. My brief period as the kind of idiot that wears two smart watches is over. I’m all in on iOS.
The irony is I actually preferred the Android wear, I haven’t really made sense of the Apple Watch and it’s even more annoying to have a bunch of random apps on my wrist. I don’t have the activity tracker hooked up. Google maps and default calendar don’t work as well, and it feels like my calendar is never properly synced. I miss Fitcat.
But my nostalgia for the android wear is for when it worked which in practice wasn’t that often. The step counter borked a while before I gave up on it and my cat was constantly fat and recriminating, no matter how much I moved. It would randomly disconnect from my phone. Bluetooth destroyed my phone battery life to the point where I thought the phone itself was broken.
So why not replace it with another Android wear? Because I worry that would have the same issues, and because of where I used to work I am accustomed to getting Android products for free (that one a friend gave me; I gave him a bottle of water). But most of all because the Android watches are huge and ugly and the Apple Watch is cute and dinky and rose gold. Form over function, then.
One of the (many?) things my team may be tired of hearing from me is “empathy is part of our job”.
What do I mean by that? Well as mobile developers, we are the closest to the humans that use our product. We need to have empathy for our users – what do they need? What’s their experience?
For me empathy starts with a foundation of self-awareness and self-care. It’s a lot easier to consider other people’s needs when my own are being met.
Then, we can build on that with empathy for each other. If you can’t find it in you to connect on a human level with the teammate you work with every day, how do you find it in you to connect with the abstract idea of a human using your product?
What does this mean? Because honestly this phrase even for me invokes some nightmare scenarios of codependent emoting. But what I mean is the practise of seeing someone else’s perspective. Listening to each other. Valuing each other’s strengths, and not judging each other for our quirks.
We could start with a culture where we don’t blame, where instead we look at our processes and consider how they have contributed to the situation. Then, we improve our processes. Our “culture” is defined by our processes, afterall.
It’s a pyramid, and at the top is empathy for the user. We have to care about them. What they are trying to do, and in what situation, and on what device, they are trying to do it.
For me, the practise of empathy is mainly taking a moment to see the other side. But how do you do that for an abstract person? One example is that when I’m frustrated by fragmentation on Android, I remind myself that fragmentation is mainly a problem on lower-end devices, and as a result lower-income users. And then I feel a lot better about spending time on it. When I’m trying to prioritise anything to do with personal information I think about how upset I was when GMail changed my name and I couldn’t change it back and that reminds me how that would be even more upsetting for some other people.
Basically when I look at some large piece of engineering work and ask how important it is, I ask, who is it important to?
Thinking about this left me with one question – can you have empathy for the user if you don’t have empathy for your team-mates? Or, can you build a functional product without a functional team?
The conclusion I came to was that I think it’s possible, but I have never seen it. I think the answer as to why is that emotional energy is exhaustible, and if you spend it fighting for or defending yourself, there’s less of it when you need it to fight for, or defend, an abstract person you’ve never met.
On iOS I do this using a button (with different pressed state), and I figured it would be the same on Android, but turns out, no.
Step 1: Add a second image to the XML, and set the visibility to “gone”.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
I used to be a ski instructor. Back when I was in grad school. Weekdays I would write code, academic papers, and teach first year programming. And at the weekend I would be out in the fresh air, teaching people, mostly kids, to ski.
One of the interesting things as an instructor, of anything really, is the process people go through as they learn. I didn’t actually learn to ski myself until I was 22, so I remembered the learning curve, and how hard and scary it had been. That empathy served me as an instructor.
As we gain expertise, we go deeper. I’m sure you can think of an example in whatever technology or part of the API you’ve been learning recently. So the beginner skier, their goal is something like “how to get down this hill without hurting myself”, and the expert skier is working on a specific part of a specific turn.
The other thing that changes, is perspective. The beginner skier is very focused on the front of their skis, and almost nothing else. They are scared to look further, but it’s not much of a view.
The expert skier, they consider the whole hill. You have to, right, if you have 10 kids following you in a line. Or if you’re going 30k down a standard hill, not having that perspective is a quick way to ski into a tree and die. Olympians hit up to 95 miles per hour.
We’ve got to do the same thing when we think about mobile. We can take a broader perspective and take in the whole view. We’ll build better apps if we consider the fuller context of the user experience.
The User
The User and Your App
If you don’t ski, or don’t ski much, you might think there’s plenty going on for the skier. You’ve got poles, and gloves, and a helmet, and goggles, and don’t forget the skis. it’s super-cold, windy and sun gets in your eyes. That would seem like plenty to juggle, yet skiers are pulling out their mobile phones like everyone else. I personally like to take videos.
And that should not seem too ridiculous to us. Take a look at this…
I love this video. Often when we bring an existing product to mobile, we ask, “how do we get this to fit”, and sometimes, “what can we leave out”. Capital One have approached their banking app from the perspective of – how does someone do their banking on the go? How do we enable them?
One of the most interesting changes is the login. Logging in on any online banking system tends to be pretty unpleasant, right? It’s for “security”, where security seems to be defined as “the most unpleasant user experience your user will tolerate”. Capital One, instead of taking the standard unpleasant banking login and shoving it onto a smaller screen, took the login we are familiar with on mobile – the swipe – and built it into their app. Now that might even work on a ski slope.
The way we evaluate usability on mobile is so contrived, at a table, in a room, focused on nothing else. How often do you actually see people use their phones like that? Being chased by bulls is a little extreme, a little gimmicky, but the question, “how usable is it one handed with the whole world going on around you?” is a question worth asking.
The User Making Decisions
When I lived in Sydney, a friend and I had a routine. On Thursday evenings we would hit the gym and eat at the mall – mall food in Australia is amazing. We had a conversation at some point, about whether we should be doing more exciting things of a Thursday evening and her response stays with me. She said, “By Thursday evening, I have made so many decisions that if I don’t have an evening off, there will be no decisions left for tomorrow.”
Decision making is exhausting, right? I don’t think I could count the number of decisions I make in a day. The thought of trying to do so makes me want to take a nap. I’m seeing more and more advocates of removing decisions, how you’ll be happier and more effective if you focus on habits.
Part of the problem, when we make decisions, is that we want to have all the information – we believe in choice. The more choice, the better. But more choice overwhelms us. If you’ve ever got to a big mountain and skiied the same run over and over again, you know what I’m talking about.
The original example of this is the Jam Study conducted by Sheena Iyengar (she has two great TED talks). The experiment went so: customers in a grocery store were offered a choice of jams to sample, and given a discount coupon should they wish to buy. When there was a bigger selection of jam to sample, more people tried the jam. But more people bought jam when there was a smaller number of jams to sample.
What metric really matters to the store owner here? The buying of jam.
So we build systems to make user decision making more efficient. In the UK, the insurance industry is completely commoditized, and customers have no brand loyalty, so insurance sales mostly take place through “aggregators”. You put in your information into one system, and you get quotes back from many different insurers, and then you choose the best.
Right? Wrong. Now instead of putting their information into multiple insurance sites, users put their information into multiple aggregator sites, each of which generates a multitude of quotes. And then they compare between them.
But do aggregators make the decision less overwhelming? Or now, instead of picking between a couple of options for a couple of insurers, the users picks between tens of options on a couple of aggregators instead.
Distraction, decision fatigue… I think they relate to this current trend we see for curation. Newsletters are more and more prevalent – (a friend and I have one, check out techspeak.email), Maria Popova has turned Brainpickings into a business. And last year Product Hunt raised $6.1 million. It’s a curated list. Remember when Yahoo was a curated list? But algorithms won out. Now curation is coming around again. At the end of the day, users want people they trust to create trails for them, the whole mountain is just too overwhelming.
The User in Love
For me, and this comes back to a talk I gave last year (Distractedly Intimate), the biggest difference on mobile is how users feel about their phones. Most people love their phones, and many people hate, or fear their computers. I don’t know if any of you have been on an online dating site recently, but pretty much everyone seems to say they can’t live without their phone, the computer mostly doesn’t get a mention.
As developers, I feel that we failed humans with the computer. We created things, that stress them out, confuse them. The joy of developing on mobile is freedom from that history. Not quite the same freedom as a deserted mountain early in the morning, but pretty close.
But this freedom comes, I think, with an obligation, not to mess it up again. And also imposes it’s own limitations – the phone is for fun, and for pleasure, and personal, so the top paid apps are games and lately health apps.
That personal nature exacerbates some problems, and how users feel about certain things, including privacy. When apps demand too many permissions it feels much more intrusive, almost a violation. I know people who won’t put Facebook apps on their phones because of it, remember the person describing Uber for Android as “literally malware” which went viral but was apparently inaccurate. People uninstalled Twitter because they started checking to see what apps are installed on your phone to improve advertising.
I think what we see here is the result of three things. Firstly, ad click through rates are lower on mobile so companies need better data for better targeting. Secondly, poor communication around permissioning on the OS, like many things, worse on Android. And thirdly people being more protective of the device they love.
The World
The World Around You
We want to log everything that is going on in our app, right? But how often do we see someone just on a mobile device? It’s what we use as we go about in the world. In effect, we are logging the position of the tips of the user’s skis, without the context of the slope they are on. Logging is only part of the story of what’s happening. We log what users do, not is what is going on in the world around them.
Maybe we log that they triggered shake to send feedback and cancelled it – this happens for me with Google Maps every time I get in and out of my car.
Maybe we log that send failed because of lack of internet connection – maybe because the user got in an elevator, or is on a train travelling in and out of service. We don’t know.
Maybe we log that a timeout happened on the form they were filling in – perhaps Covert Affairs got particularly dramatic.
We don’t really know what is happening. On the computer we could be reasonably confident that they were sitting still, and either had, or didn’t have, internet. And now our user could be anywhere, doing anything. They could be being chased by a bull. They could be on the chair lift. It’s pretty likely that they are watching TV. And the world around them – the quality of service, the lighting, the movement, affects the experience they have with our product.
The World is Exciting
This leads us to distraction. By this point, I bet most of you have checked your phone, maybe email? Maybe Twitter? Maybe you’ve responded to something important. Maybe you’ve been clearing out your inbox.
I was mostly shocked by how long this took. Let me tell you how I work out. I get my cardio on the elliptical. With me I take my iPad, and at least one cellphone, normally both (I carry an iPhone and an Android phone).
So I would have estimated mobile to be way above TV, based on an assumption that TV means also being on mobile, but being on mobile does not also mean watching TV.
Did you know that texting whilst driving is more dangerous than driving drunk? That’s the cognitive overhead of multitasking.
On mobile, your users are multitasking. This means: your users are effectively drunk. There’s a reason why you’re not supposed to drive (or ski!) drunk – it reduces reaction time.
The World and Other Humans
I’ve got used to skiing alone, basically because I would sooner ski solo than ski slowly. But there are few things better than a great ski companion – someone who can keep up with you, push you to go a that bit faster, brave that scary run, pick up your poles when you wipe out.
There’s a great quote from Douglas Crockford in Coders at Work; he talks about how computers used to be social because a group of people shared a computer and an email address. There was a community around it. And then we moved to the personal computer, and computers became anti-social. Now we move back to them being social, because we’re humans! Social is normal. And nowhere is that more true than the phone.
What does this mean? It means your app is going to get interrupted by the ding ding ding of text messages, and twitter notifications, and email.
It also means that social is a normal part of mobile interaction, and sharing what you’re doing is standard. We’ve bastardised the meaning of the word social in this industry, and it’s come to mean “one person broadcasting channel” but that is not what I mean. If I’m booking a holiday with a friend, I want to show them what I’m looking at. If someone is being annoying I’ll be discussing it privately. Pulling out a phone and showing things to people we are with is normal.
The System
The System is Broken
One of the things about being a ski instructor, is you ski like a pro and like a beginner. When the day is over, you can carve it up down the hill. When you’re teaching, you ski at the level you want the student to aim for. It sounds simple to do a snow plough, right? You just make a pizza. But it’s actually much more work. You’re working against the mountain, against the snow. When you work with the physics of the skis, the shape of the mountain, it’s much less exhausting.
We know, that someone learning is working way harder than we are. That thing that took us 2 minutes, they had to look 6 things up and now it’s only nearly done. But also we do this to ourselves – when we do that “easy” hack, we pay for it later. When we focus on a sensible structure, on documentation, onboarding and subsequent changes become easier. We work with our system, instead of against it.
Skis used to be straight, but then in 1988 we got the side cut, the parabolic ski. As a result, people could ski even faster than before, because the new ski allowed you to accelerate through the turn. But a whole new way of skiing had to evolve as a result – a wider stance, and a lower centre of gravity.
Now, our mobile apps have become bigger and more complicated. This is really a whole other rant, but as our mobile apps become more complicated we have to evolve our infrastructure and processes with them.
For a long time on iOS, people barely wrote unit tests. And Android appeared to be untestable by design.
And I still find things. Like, I was using the G+ app recently (I know, strange behaviour), and I tried to open the locations tab, and it just… crashed. Which to me is a sign that there’s not a UI automation test just like, checking every single view controller loads. That should be a bare minimum.
Or the Twitter for Android app. I tried to take a picture of my passport and a cup of tea at the airport, and I carefully cropped it and added a filter to make it less generic.
And it discarded my edits. I had a couple of goes and had to just post an image that in no way reflected my limited talent with aesthetics.
And I just asked the world, futilely, how do you not have a unit test for that? Why?
The System is Tired
I went to Bali in 2013. Not to ski, obviously, but to do yoga! And earlier this year I went to Easter Island. Both these places are incredibly beautiful. But the internet was terrible. And all the apps on my phone, that are written with this expectation that I have high speed network all the time… they just stopped working. Twitter, especially with inline images, became basically unusable. G+ with even more images wouldn’t even load. Living with a poor data connection is like a ski resort without a snow-making machine. That used to be possible, but isn’t any more (thanks, global warming!)
When I travel within Europe, I used to use my Android phone and “restrict background data” to get by on the meagre data allowance O2 gave me. But last year in Scandinavia, I discovered that doesn’t work anymore – most of the apps don’t work without background data. For a while I was collecting nano SIM cards everywhere I went, now I finally have a SIM card that works in 17 countries.
I’m sure the majority of the time it has incrementally improved the experience. But it’s really not improved the experience when I travel, which is an important use case for me.
And let’s talk about battery life. I’ve started carrying around two cellphones and an external battery. That has become a new normal for me.
It’s easy to pass this off as an Operating System problem. And it is. But if someone’s battery is dead, they won’t be using your app. If they notice your app is draining the battery, they’ll delete it.
The System Has Many Pieces
Mobile is a systems problem. To get down this mountain, we’ve got to look at the whole mountain, not just the tips of our skis.
We talk about it though, like it’s form factor. And when we talk about “beyond mobile” we talk, mostly, about wearables. About smart watches and Google Glass. We wouldn’t talk about “beyond skiing” and fixate on goggles and helmets.
I wear two, sometimes 3 activity trackers, but no smart watch, and now that I no longer work for Google I can admit that there are few things I want less than a notifications bar attached to my face. Distraction is a far bigger problem for me than turn around response time on Twitter or whatever.
Mostly I think wearables are cool. But that’s not what I’m talking about here.
Mobile is just part of a multi-device world. People move between devices as they go about their day.
I still go to websites via twitter on my laptop, and click on links others have shared that open mobile sites, which aren’t great on my laptop. Or worse on my phone, I open links others have shared from desktop, which don’t or barely load on mobile. We’re not doing great supporting these transitions, yet. The skier doesn’t live on the slope. The user doesn’t, usually, live on one and only one device.
We see this especially with shopping, conversion rates on phones are lower and if you’ve tried to pay for something on a mobile lately maybe you think you know why, because it’s often terrible. But actually when we drill into patterns of behaviour in shopping we see people browsing on mobile during the day, earlier on their phones, and then later converting on their tablets, or on desktop.
So people say “mobile isn’t important, people don’t convert” but that depends what you mean by “convert”. Do they mean people don’t enter their credit card information at the same rate? Sure. But if they mean people don’t see things on their phone and decide to buy them – no.
Takeaways
I do think it’s possible for us to get a more complete picture of a mobile system and let it guide us down the mountain – a much better path than just following the skis. In fact, while beginner skiers look at the tips of their skis, the pros watch the back of your skis to see what’s really going on.
So here are some things you pros can be looking for when you’re trying to take a systems view of your mobile user:
More extreme UX evaluation: Can people use your app with one hand whilst moving?
Remove decisions: Consider the experience of decision making, not just information presentation. Every time you ask the user for information, they have to decide whether they want to give it to you.
Design for affection: Users love their phones, and that relationship is stronger than their relationship with your app.
Log early, log often: It’s your best bet for knowing what is going on, but recognize that it is only a partial story.
Design for distraction: Allow users to resume easily, expect partial, intermittent, attention.
To be human is to be social: Social doesn’t mean broadcasting, it means communicating with other humans.
More complex systems require more complex testing: The later you leave it, the harder this gets.
Don’t hurt The Precious: Consider the experience in extreme conditions.
Embrace a multi-device world: Make transitions smooth.
I’ve started to port Show and Hide to Android. There’s still a lot to do, but I hit a milestone of having it working end to end on the emulator last week, which was exciting.
One of my friends asked if I was using any libraries to make it easier, and the short answer is no. But I think the long answer is potentially interesting so here it is.
1. I want to learn Android
I don’t think there is a better way to do that than building an app from start to finish on that platform. The more libraries and bits and pieces you work with, the more you learn the intricacies of that system, rather than the platform itself.
Sometimes that is exactly what you should be doing. There’s often no point doing something that has already been done. But cross-compiling isn’t re-implementing something that exists already, it’s choosing to write something a third way and hope it works well enough on both platforms (more on this later). At this point, if I haven’t written an entire app already, I don’t think I can really have the information to just decide that cross compiling is the way to go. How could I compare the experience to a problem that I haven’t solved?
2. UI Code
Fundamentally there are two reasons why I don’t think we will ever have a good cross-platform UI solution. The first is that with major releases every year, it would be a huge amount of work to maintain such a thing. Almost no-one has the resources to run such a project, and of those that do even fewer have the incentive. The second is that the UI patterns on iOS and Android are different enough that what is “right” on one platform won’t feel “right” on the other.
3. Non-UI Code
Here I think there can be a good argument for a cross platform solution, depending on what you’re doing. Libraries like Parse are interesting, making it easier to abstract persistence and networking out and share it.
But – the core of Show and Hide on iOS is about 400LOC of optimised C code that is tied to the way that the platform represents images. I don’t even know if that would be possible to share x-platform, and the chances of it being performant enough for my purposes is vanishingly small.
Because it’s a relatively small amount of code and I deeply understand it, moving it to Android took only 1-2 days. I’ve yet to see whether it is performant enough, but this way I’m also in a much better position to optimise it.
Porting the Architecture
Instead of using cross-platform compilation what I’ve been doing is:
Building the UI according to Android best practises (or trying to).
Keeping (initially) the same function definitions for non-UI code.
Changing the implementation to make sense on the platform – e.g. the way that iOS and Android represent images are completely different.
This means that:
The two apps have very similar architecture – the same objects, with similar methods on them.
The unit tests are near identical: given this input expect this output.
It’ll be some time before I can declare success on this as a strategy, but I’m cautiously optimistic.
StartApp – mobile monetisation platform. Brains and beauty of the mobile industry. Right ad, right time, right user. Using BA tools and data. Beauty side – most engaging and appealing ads.
How do you make your app stand out in a crowd?
How do I retain the user?
How do I monetise the user?
3 Application types:
Flash light click
Can generate a lot of downloads
Many free alternatives
Minimal usage time
Similar apps – wallpapers. widgets calendar.
Action game
Super popular
Addictive
Similar apps – strategy games, puzzles, gambling.
Music player
loyal users
long sessions
many features
similar apps – social apps.
Paid app
Don’t go there.
90% of apps on iTunes are free.
95% of downloads are for free apps.
90% of paid apps being downloaded less than 500 times per day.
Top growing apps on iTunes. Only paid app is Minecraft.
Not a recommended business model, but you can try.
Banner adds
Most popular.
Bring traffic, network places adds.
Over 400 networks (admob in 40% of free apps)
Acceptance from users
ECPM is your BFF.
Do this:
Plan and integrate ahead.
Engage at the right time (exit point).
Use – fill page, app walls, video. Full page interstitials have best ECPM.
Test, test and test some more.
Avoid:
Use only classic adds.
Misplace adds – disrupt UI/gameplay.
Don’t be ad-blitzing.
Settling for the first network you try.
Clock widget:
No space for ads.
Action game:
Suited for interstitials.
Music player.
Relevant adds.
An attention catcher.
Summary:
Use a variety of ad units.
Strategically place banners.
Analyse performance (need to learn and know the users behaviour, change according to what you see).
Take advantage of tracking tools.
To make this work, need a LOT of traffic (need a lot of daily actives).
eCPM
eCPM = CR * CTR * layout * 1000
CTR
CR
Factors that impact both CTR and CR (engagement of users with the ads).
Payout.
More users click on full screen ads rather than small ads. Need to take that into account.
Freemium.
Application is for free.
Inside a variety of options for purchases.
Dominated by games.
Numbers are mind-blowing (e.g. Candy Crush).
Don’t go into making a game expecting these numbers, but huge potential.
How to make it work:
Plan from day 1
Make it highly addictive.
Offer purchase at the right time.
Create a currency. Even two.
Issues:
Successful app – no child’s play!
Not a game? A lot tougher.
Need to “hook” the user.
Usually works for very high end games.
Flashlight / clock:
Not an easy one.
You can try this.
Action games:
Addicting.
Add a social layer.
Need to know when each user might agree to purchase.
Can be a great fit.
Music player:
Pack it with features.
Offer a trial.
Can be good.
Summary:
Great money making opportunity.
Plan ahead.
Best suited for games..
Need to find a balance between UX and revenue.
Summary:
Lots of opportunities.
Start with making a great app.
Don’t settle – test, explore, optimize, analyse.
Reach out to the other side – users and ad networks
You can turn this into a business.
Cookie Consent
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
Here’s the CNC machine, with some children for scale. And on the right are the custom pieces, and a key. Pretty cool, right?
