Advocacy for native mobile platforms

Bear Douglas: All right. Hey everybody. As Tamao said, I'm going to talk to you guys a little bit about doing developer advocacy for native mobile platforms and what's different when you're not talking about an API that everyone can access. It's not just a restful service somewhere. There's something very specific about native mobile communities. So I can tell you a little about me. Hi, I'm Bear. I currently work at Twitter.

I lead the team for Fabric, which is our set of native mobile SDKs. We provide things like crash reporting and analytics. Before that, I was at Facebook working on Parse the mobile backend service, and then before that on Facebook's native mobile SDKs. Before that even, I was at a startup called Strobe, and we made a development platform and release platform for people who are writing mobile web apps. Hm. Five apps and packaging them up for release to the store.

So I've spent most of my career working on native mobile stuff, but I do have a little bit of JavaScript background context on what is so different when you're trying to build a community for people who are working in web technologies and people who are working in native mobile. So out of curiosity from the rest of you, raise your hand if you have ever built a native mobile app, iOS or Android. Oh, awesome. That's a surprising number. I thought it would be fewer of us. And there's a reason I think that. So mobile is growing. It's very buzzy.

People talk about how there's been this explosion in apps and mobile is the future. And it's because you see on the app store, all of a sudden there are 1. 5 million apps, and that is a stat that is nearly a year old. So I imagine it's substantially higher now.

And on the Google Play Store, there are over 2 million. This happened explosively in the past few years. You'd think that there are lots and lots of people building these millions and millions of apps. But then Stack Overflow released their developer survey for 2016 pretty recently. If you look at mobile technology, it's only something like eight and a half percent of developers worldwide who are working on mobile. And this number encompasses native iOS, native Android, WordPress mobile, and HTML five apps. So the number of people we're working with when we talk about writing tools for native mobile platforms is relatively small. So when we as companies try and attract mobile developers to our conferences, we do our best to try and say, this is a mobile conference.

This is for native mobile platforms. Our tool is only for iOS and Android native, so please come if that is what you work on.

And even then you get a lot of people who are interested just generally they want maybe background information or they don't work on anything related at all. Maybe they're a backend developer and they just saw, I'm interested in going to your conference. So it's really hard to pack a room full of native mobile developers. And so we face a few challenges. One of them is that there are just fewer of us. We have under 10% of developer occupation market share. And part of the reason is that the platforms are still pretty new-ish. So those graphs showed the app stores going back to 2008.

And you might be thinking, bear, that's not really new. That's nearly 10 years old, and that's getting to be pretty mature. But to put something in context, when I first started learning Android in 2010, this was the state of the world and this was the Google Getting started guide for Android apps.

And this is I think the third or fourth paragraph in. And if you can't read it from here, it is talking about the Android virtual machine. This is paragraph three, and it's a fantastic background if you want to learn really deeply about the platform right from the outset. But as you're paging through this, it takes you about 10 pages to get to Hello World. And it was a really, really difficult first encounter. You hit a wall right away if you're like, whoa, we're talking about this. I just want to put a screen on my phone. And how do I do that?

So when we think about how long native mobile platforms have been around, these were the early days and it was really difficult to get a lot of people in the community learning how to build apps. So things have been more mature probably only for the past three or four years, I'd say 2011, 2012.

So that's the place we're working in. So the platforms are new-ish, and there aren't tonnes of experts. And the other thing about working in native mobile platforms is that they are, well, iOS is closed source and Google has open sourced Android. But if you look for people who are the authority on Android, people almost always look to Google. And so finding authoritative sources and establishing authority when you're talking about native mobile platforms is a little bit difficult. And that network of people who feel qualified to talk about what is a best practise and who do talk about what is best practise is only just starting to blossom and become more and more commonplace. So those three things make it a very different world for native mobile developers and for people who are writing native mobile development tools. So what do we do about it?

Well, I have five tips.

First thing is to meet people where they already are. And this is a little bit different from where you would find people who are interested broadly in arrest API. So one of the best places to find people is at the major conferences. You've got of course WW DC and Google io. And then you've got a lot of conferences that focus specifically on the languages and on the platforms. So that's things like the Tri Swift Conference and the Swift Summit, Coco Con and devcon Droid Con, the big Android barbecue, the places that get super specific about being about the platform and being about the language tend to be where developers actually go. I've been to lots of conferences that are about mobile generally, and you'll find when you get there that yes, there are some native mobile developers. There are a lot of people who are interested in seeing what mobile's all about.

There are a lot of business people. So if you're looking to find the software engineers, you need to go to the conferences that are about the languages and about the platform. What about hackathons? I have been to hundreds of hackathons. Raise your hand if you're in here and you've never been to or run a hackathon. No one. It's a huge part of what we do and it's a huge part of why our weekends are occupied with things every weekend. There is a hackathon pretty much all the time.

The thing about it though is that it's pretty difficult for people to get up and running with a native app in the space of a hackathon. And so you can go and you can say, we've got this really amazing tool, we'd love for you to use it, but you'll find that what people are building are the things that they can prototype quickly.

And so since it's actually very difficult to get things running with the local database inside Android or work with Core Data and iOS to start building something that you'll have anything to show for by the end of a hackathon, not that many people are interested in using your mobile SDK because the thing that's going to get flashy, that's going to be quick and is going to be prototypical, is probably something for the web. So if we're not going to hackathons, where should we be looking? First place is meetups. Meetups are a fantastic resource for native mobile developers. There is a network of meetups, NS meetup for iOS and the Google developer groups that Google has been fantastic about promoting all around the world. That is where people actually come to hang out and talk, discuss the craft. And it's not the same kind of format as a hackathon.

You can't really get people to try your API while you're there necessarily. Maybe if you whip out your laptop and say like, here, let me show you how to do this real quick. And that's definitely a strategy. But the best place to find people is where they're congregating automatically. So I scour meet up all the time to find places where people are going and rather than trying to spin up something new around your platform, meeting people where they are already is a great strategy. We also talk to people a lot who are in school since we've kind of hit this number where we have only 8% of developers in the market right now to work with on native mobile products. You need to find where people are learning. So more and more schools are offering as electives, iOS and Android classes.

I recently went and gave a talk at USC and they've got an Android class and an iOS class because the students are interested in playing around with the platforms and they're the next generation of who's going to be in industry and talking to them early and giving them some insight about not just what you're learning in the context of the classroom, but how people actually work on large scale production apps is really valuable for them.

We also do a lot of work with coding schools because that is also another place where the next generation of native mobile developers is to come from. So we've found that being mentors at these academies, offering information, background talks wherever we can has been helpful for them and for us. So I spent a lot of time mentoring people at Mobile Makers Academy. It's an awesome dev bootcamp that teaches specifically iOS, but we got a lot of people learning the platform new and the perspective that people can give you who are brand new to your product and the platform is always invaluable. That's how you really root out the things that are confusing or could be smoothed out in the product. So the first thing is meeting people where they are. The second is realising that you have a very wide range of experience that you'll encounter and making sure you have documentation for all of them.

So I think of docs as being in three levels. You've got at the most basic level API reference, there are plenty of people who don't want to deal with your flowery descriptions of how your product works. They just want to see the code and they want to dive in right away. And for those people, you've got API reference in the middle. You've got some people who don't necessarily want to just read this raw, they want you to walk them through, but only a little, show me a code snippet and I can kind of figure out the rest, but give me the general shape of things. And those are what I call guides. And guides tend to be the bulk of the documentation that we write at Twitter. And that frankly I've seen from a lot of companies at the very end is tutorials.

And tutorials are the types of docs where you do a lot of handholding and a lot of context giving where you say, not only this is what we're doing, but this is why we're doing it and it's why it's important.

And for our platforms, the tutorial portion is super important because we have so many new learners. So for reference docs, the nice thing about working in an IDE is that you actually get things baked in for you. You can tap to complete, but you can also set a set Android studio up to pull in Java docs from your project and show you as you're working what you're writing. And that's something that is really handy for a lot of people and that's maybe all you need. We also believe in having a web reference so that if anyone wants to, they can just pop online and see what the OCS look like. Writing good guides is probably one of the harder things. And the tips that I have there are that putting code in small blocks and in context is what makes a guide great. So the point of having this intermediate level of documentation is like I said before, to give people the shape of the context of your platform and then get specific with code where appropriate.

So I think Stripe does an awesome job here. Here they're just explaining what one of their objects is and then showing the potential response for the API, but also describing in more detail than you would find in a reference doc, what type of properties are on this object? What should you be using it for? And there's an element of prescriptiveness there that's still important. It's not just what is this, but how should you use it? And that extra layer of not just descriptiveness, but prescriptiveness becomes more useful when you're in this intermediate stage. And then at the end you've got the most prescriptive in tutorials. What you'll see frequently is lots and lots of screenshots, UI screenshots, where do I click?

Not just what's the point of what I'm doing or in general terms, what do I need to do, but show me actually in the id, where do I need to click?

What code do I need to put on what line to make this all work? And you need to have these when you've got raw beginners on your platform. And what's interesting about native mobile is that for us, raw beginners are so important because they're the foundations of the next generation, so we invest a lot of time in them. The other thing that goes part and parcel with writing long form tutorials and great documentation is writing shippable sample code. Because what happens is your code, your apps are not just samples for your product, they're actually samples for the platform. When you've got an open technology where it's standard practise for people to open source their websites or their products, you have lots and lots of samples to learn from. As a new developer, if you think about your first job and how you learned how to code, it was probably by digging through what other people were doing and seeing what the difference is between what you learned in school and what makes something production ready.

And if you don't have that resource available to you, if you're not inside a company and you can't see how people are actually writing, it's a lot harder. The thing about native mobile platforms is that a lot of people don't want their source code being viewed. There's actually a whole class of products that are designed to help people prevent their packages for being unpacked and looked at. The view source option is what people actually want to guard against. So that means that there's a lack of samples that people can work off of. So what Pars did, which was very interesting and an excellent investment, was work on an app called Any Pick. Any Pick was a clone of Instagram that ran entirely on parse. And yes, it was a sample of the product, but what it also did was give people an example to work from on some very basic app components that were very difficult to find in any other source.

So for example, on any pick you could favourite a photo and favouring a photo meant that there had to be UI changes propagated in different parts of the app. The favourite heart had to be filled in and there was maybe an animation that had to play and you had to think about things like how you're going to persist the relationship between me and who my friends are, my favourites, my friends, my friends' favourites. And having this level of sample app was incredibly useful to people. In fact, it was so useful that we got a lot of support tickets on our forum and to our inboxes asking us to help people re-skin any pick or add one small feature to any pick, and then people would re-upload it on the store. There were lots and lots of people who learned from any pick. And what's crazy to see nowadays is as I'm working with more and more coding schools, I've noticed that any pick actually features in at least three coding schools curriculums that I know of off the top of my head.

So this is something that is incredibly important for us to invest in. And it can't just be that you've got the tutorial, you have to make it available on the app store because people need to see it. People need to be able to play with it, download it, understand what it does. And that's also a critical step that a lot of people don't get taken through when they are learning how to write for native mobile platforms because you can create an app in your own environment, you can run it on your laptop, but then shipping it to the store is a whole other set of challenges, particularly on iOS. When you have to think of code signing and you have to think of, alright, am I setting this up right? Have I provisioned it correctly? Can I accept push notifications? There are so many different elements that people have to think about that create kind of a gulf when you're going from just having something on GitHub and in your local ID to putting it on the store.

And the last part of course is that you have to open source it. People need to be able to pull the code and be able to work with it. And the most important thing about all of this is to know that if it was trivial to write, it's probably trivially helpful. And I think there is value in small sample apps. Small sample apps have the benefit of explainability. You take something small, you're only needing to focus on a small chunk of code. They're very easy to read, they're very understandable, and in a lot of cases, a quick start may be all you need to help give people the push they need to start using your product. And for a handful of people, they are really helpful, particularly for beginners.

So if you have guides where you've got an explanation of what an object does and then maybe a code snippet, there are a lot of people who as beginners can't take the snippet and then put it in context of a project.

So if your app, for example, and we have one of these as an example, is a Twitter timeline that we give you a code snippet for in our docs. But just putting it into the larger project helps people out because they're able to see, alright, this is how this view interacts with the storyboard and this is how you should set everything up. But for the large swath of people who need to rely on your sample apps and are learning from them, the more detail you can go into and the more you can show best practises, the better. So this is Ferney written by the Inid Rama Hewitt here who's now at Stripe, but this was our sample app for our developer conference in October. And what ferney did that was extremely helpful for people is that it relied on a lot of technologies that you might not know about if you had never written a production iOS or Android app before.

So if for example, you are learning Android and you're writing your very first app, you might not know about libraries like Protobuf, for example, that compress network traffic and make it a lot more efficient to send and receive data. It's not something that is top of mind, it's not going to be in the getting started guides. You either need to have somebody tell you about these kinds of things or you have to go spelunking in a project. And so having a really elaborate sample like this that included AB testing that included taking payments, that included actually having inventory in here that people could scroll through and different UI options, this was incredibly helpful and the proof is in the pudding. If you look at our sample repo for the timeline sample, which is really just our docs, but in context of a project, we've got 11 stars and four forks.

Not bad, not nothing but minimally helpful, trivially helpful. If you look at our app Cannonball, this was the sample that we wrote about a year and a half ago. That is a magnetic poetry game, but it is all contained within the phone. It doesn't use any remote services except Twitter. It's four screens. It's complete and it was shipped to the store, but it was simple. This is something that got 222 stars and 95 forks. So people are finding this substantially more helpful than they found the fabric timelines one.

Now if you look at ferney, Ferney blows 'em all out of the water. We've got over 900 stars and 124 forks on ferney. And it's because people are actually getting value out of that. They're pulling it down, they're looking at it, they're treating it as a canonical sample. And that's something we did at Facebook too when we wrote the app for F eight, the conference that was important to open source it as the general conference app. So I wrote the Android app on Parse, now it's in React native, but they're continuing to use it as the canonical sample app. So now if you're looking for what does React native look like, you can go to the Facebook GitHub and see that they have their conference app for F eight, which is fully featured, live and usable for anyone in the store, all explained on the web.

So obviously we have a lot to do to invest in teaching and that's what part three is all about. Sample code needs to be not just about your product but also about the platform. Then there's another element to this, which is that every time people come to you for support, it's often a teaching opportunity. And this can be really tough to deal with sometimes when you have a lot of people who are beginners or who are trying to get started really, really quickly. You do get emails like this, this is urgent, I'm on a deadline and I need to reskin any pick. Give me the exact sample code. Now this is kind of a joke, but it's actually not really a joke. I've gotten emails that look exactly like this in the past, and when you get them, it's really hard not to just feel like, and it's really hard to take the high road and handle it, but if you can provide a lot of value to people.

So here I was in a long thread with somebody who was having a lot of trouble with some basic getting started stuff inside iOS. He had never known where the terminal was on his machine and he wanted to get started with his project. And so he didn't know how to link a library in iOS, and that's not a bad thing. That's something that everybody has to learn and it's a really intricate UI and it can be sort of hard to find. So I just told him where to find it, told him about a common gotcha, and immediately he was like, wow, amazing. I'm on my way. And unblocking him just like that. Even though it has nothing to do with our project, it has nothing to do with our product.

He just needed to know how to use X code. This is something that could have ripple effects down the line, but we're not saints.

You can't say that I'm going to teach everybody iOS or Android who asked me because that's a tonne of your time and you want to make sure that you do help people, but also that you're reasonable about it. So I have a few guidelines for how I think about it. And the first thing is that if the issue is simple, if it's small, take the time and educate somebody directly and it might look something like this. So your first instinct is just to tell them the answer. And that is very easy to do. Well, sometimes easy to do. You might have to go spelunking for the answer yourself, but if you've got the answer, resist just giving that to them. The next sentence that's really important is it's a problem because give the context, just like you would give in a guide or in a tutorial about why what they hit is a problem, why it's necessary to solve it, and then actually how to fix it.

And that extra context has dividends later down the line where people really understand the platform, they really understand the product and people pay it forward. You see this in communities everywhere, people on Stack Overflow can zoom a tonne, but they also feed back. And so the more that you can enable people to say, not only I know the answer to this, but I can tell you why I know the answer to this is huge, but there are times when explaining something in detail is a little too complex. You don't have time to write five pages in an email telling people exactly what gradle is and how to use it. So in cases like that, I like to link out to more authoritative sources, but actually take the time to find the resources for them, not let me Google that for you and make it sarcastic, but actually include things because I know where to find this doc.

I know this doc exists. And telling somebody to Google, it's not only a jerky thing to do, it also takes for granted that they have the same resources and context at their fingertips that makes this so easy for you to do. Why isn't it so easy for them? Give them a hand, but also set community standards about what's okay and what you're reasonably going to respond to. I'm very much an advocate for teaching the platform, but you also should protect your team. Protect yourself. If people are swearing at you, if they're being a jerk, if they're saying, you need to respond to me ASAP because I'm on a deadline, this has nothing to do with your product, but please give me sample code, you would be given a pass if you said we're not going to do exactly that, but here's where to find resources.

So in essence, educate where you can, educating people is really important, but you don't have to be a saint. So then the last piece, after finding people where they are writing sample documentation for many levels of learner, creating ambitious sample apps and teaching people through support is giving people context to tie it all together. The phrase thought leadership is a little bit like, well, but that's what I'm essentially talking about when you can give people broader context about how people work, and Adam talked a lot about this in the blogging section, talk about how you work at a company, talk about the things that people might not be able to see just by using your app, walk people through what you do and how you think about approaching new frameworks and approaching new tools and adding them to your app. All of that additional context is incredibly hard to get when you don't work in a large company with a lot of experienced people.

So throw people a bone and pass on whatever you can. So three takeaways from all of this, for those of us who are building native mobile products, is meet developers where they are and where they learn with an emphasis on where they learn. Because this is a market that's been growing, it's grown substantially in the past four years, and the only way it's doing that is through code schools, through people teaching things at university and from people doing professional development courses and picking things up online. So the more you invest in the community, the more it pays you back. Creating docs in samples for audiences and multiple skill levels is something that we all do. This is not necessarily strictly a native mobile thing, but it becomes extra important when you have to focus on beginners in addition to experts. And at the end of the day, investing in levelling up the community is a win for everybody. So if you've got the time, if you've got the resources, if do it, it pays such dividends.

So thank you.