Android @ Dropbox
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 46 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/47159 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
droidcon Berlin 201541 / 46
5
7
10
13
16
18
20
21
23
26
31
34
35
36
41
42
45
00:00
BuildingAndroid (robot)Product (business)Software developerMultiplication signMobile appLecture/Conference
00:27
Multiplication signProcess (computing)Software developerLecture/Conference
00:57
NumberSlide ruleAndroid (robot)Mobile appLecture/Conference
01:24
Android (robot)Polygon meshMobile appPoint cloudSoftwareDigital photographyServer (computing)FamilyVector spaceGroup actionVideoconferencingSequelAndroid (robot)Software developerVideoportalComputer animationMeeting/Interview
01:56
Context awarenessBitCodeBus (computing)Control flowProjective planeLaptopLecture/ConferenceComputer animationEngineering drawing
02:41
Line (geometry)Bus (computing)ThumbnailCodeMultiplication signMetropolitan area networkEmailLecture/Conference
03:15
Hard disk driveMultiplication signNeuroinformatikFeedbackTwitterMereologyData storage devicePoint cloudHypermediaLecture/Conference
04:06
Business modelService (economics)SoftwareInformationFreewareExtension (kinesiology)Product (business)Lecture/Conference
05:10
FreewareMultiplication signSoftwareLevel (video gaming)Mobile appMathematical optimizationLecture/ConferenceComputer animationEngineering drawing
05:39
Bit error rateDifferent (Kate Ryan album)MereologyFocus (optics)Address spaceProduct (business)Lecture/Conference
06:04
ThumbnailSoftwareProduct (business)2 (number)ThumbnailAndroid (robot)Software developerProcess (computing)Structural loadMereologyDigital photographyMobile appOnline helpBitMathematical optimizationCuboidLecture/ConferenceComputer animation
06:51
Maxima and minimaBackupDigital photographyoutputMobile appTouchscreenAndroid (robot)Web 2.0Event horizonThumbnailSquare numberGroup actionStructural loadLecture/ConferenceDiagram
07:31
Structural loadLibrary (computing)Lecture/Conference
07:57
Control flowDecimalDigital photographyMobile app
08:24
MiniDiscLocal ringPoint cloudRead-only memoryTouchscreenDigital photographyOrder (biology)Complex (psychology)Data storage deviceMobile appThumbnailFrame problemRaster graphicsLevel (video gaming)MiniDiscSemiconductor memoryData compressionAndroid (robot)Mathematical optimizationPixelSocial classBit rateFocus (optics)Thread (computing)TouchscreenRow (database)Multiplication signCellular automatonCodierung <Programmierung>Structural loadMathematicsBitLecture/ConferenceComputer animation
10:43
PiPhysical systemDrop (liquid)Sheaf (mathematics)Right angleFrame problemRow (database)Android (robot)Lecture/Conference
11:16
Thread (computing)Frame problemAndroid (robot)Drop (liquid)View (database)Electronic mailing listFrame problemSoftware frameworkWeb pageThread (computing)Computer animation
11:44
BackupSoftware developerMobile appRight angleDigital photographySquare numberDrop (liquid)Raster graphicsEvent horizonFrame problemMultiplication signData structureLecture/Conference
12:16
ThumbnailPixelKey (cryptography)Right angleImage resolutionDigital photographyComputer animation
12:53
Digital photographyThumbnailGraph coloringRight angleImage resolutionShape (magazine)TouchscreenPixelLecture/Conference
13:25
TouchscreenThread (computing)Queue (abstract data type)Codierung <Programmierung>VolumenvisualisierungView (database)ThumbnailPixelThumbnailThread (computing)Medical imagingView (database)TouchscreenLecture/ConferenceComputer animation
14:07
ThumbnailFrame problemMoving averageCASE <Informatik>Raster graphicsThread (computing)PixelImage resolutionSurfaceCodierung <Programmierung>Row (database)Lecture/Conference
14:47
Square numberSquare numberCodierung <Programmierung>PixelThread (computing)ThumbnailRaster graphicsComputer animation
15:15
Android (robot)Roundness (object)Lecture/Conference
15:45
Digital photographySpacetimeTask (computing)Group actionPoint (geometry)Mobile appTouchscreenChecklistLecture/Conference
16:19
NeuroinformatikComputer fileContent (media)Digital photographyException handlingPropositional formulaLecture/Conference
17:06
SpacetimeNeuroinformatikDigital photographyPropositional formulaBitContent (media)Task (computing)XML
17:39
SpacetimeSign (mathematics)Installation artLink (knot theory)Task (computing)NeuroinformatikDataflowConnected spaceComputer fileMultiplicationPoint (geometry)TouchscreenLecture/ConferenceProgram flowchart
18:30
Drop (liquid)Task (computing)NeuroinformatikDataflowTouchscreenPoint (geometry)Link (knot theory)Set (mathematics)Lecture/Conference
18:56
MomentumComputerCompilerOrder (biology)Right angleNeuroinformatikTouchscreenDataflowProcess (computing)Task (computing)Point (geometry)Connected spaceLecture/ConferenceProgram flowchart
19:44
ComputerComputer-generated imageryTask (computing)NeuroinformatikTouchscreenQR codeNumberSequenceProgram flowchart
20:10
Medical imagingTouchscreenNeuroinformatikInstallation artWebsiteComputer file2 (number)QR codeTask (computing)Lecture/ConferenceComputer animation
21:14
WebsiteData storage deviceComputer-generated imageryCodeServer (computing)Token ringMobile WebLoginError messageType theoryFront and back endsServer (computing)Multiplication signQR codeWebsiteDataflowToken ringSinc functionTouchscreenUniform resource locatorLecture/ConferenceComputer animation
22:09
CodeWebsiteToken ringServer (computing)Mobile WebLoginError messageServer (computing)WebsiteAndroid (robot)Semiconductor memoryLoginResultantLevel (video gaming)Connected spaceError messagePressureQR codeCASE <Informatik>Web pageLecture/ConferenceComputer animation
23:00
OvalMusical ensembleContent (media)Sign (mathematics)Service (economics)Mobile WebMultiplication signLecture/Conference
23:26
Content (media)Mobile WebFrictionPasswordInstallation artGroup actionDigital photographyContent (media)Task (computing)Client (computing)PasswordLecture/ConferenceComputer animation
24:01
Product (business)Product (business)Software developerRight angleBitBasis <Mathematik>Lecture/Conference
24:43
2 (number)Digital rights managementProduct (business)Computing platformSet (mathematics)Right angleStrategy gameKey (cryptography)Metric systemLecture/Conference
25:15
Process (computing)Product (business)PlastikkarteProduct (business)Power (physics)Software developerSoftware testingComputer animation
25:59
Computer fileMultiplication signHacker (term)Product (business)Process (computing)Android (robot)Right angleLecture/Conference
27:07
Data structureoutputProduct (business)Computing platformFeature Driven DevelopmentMaxima and minimaBand matrixLecture/Conference
27:45
Expert systemComputing platformCore dumpAndroid (robot)Mobile appArithmetic progressionFeature Driven DevelopmentCodeWeb 2.0Term (mathematics)Lecture/Conference
28:40
Execution unitWeb browserProduct (business)Function (mathematics)Core dumpComputing platformCodeAbstractionBuildingModul <Datentyp>Web browserCASE <Informatik>Product (business)Computer fileComputing platformCore dumpFunctional (mathematics)Endliche ModelltheorieCodeAbstractionProcess (computing)Lecture/ConferenceComputer animation
29:11
Cohesion (computer science)Computing platformDisintegrationData structureIterationProduct (business)Software bugEndliche ModelltheorieCodeExpert systemAndroid (robot)Cohesion (computer science)Mobile appComputing platformINTEGRALFeature Driven DevelopmentSoftware developerMultiplication signLecture/ConferenceComputer animation
30:08
Web 2.0Position operatorMultiplication signAndroid (robot)Lecture/Conference
30:41
EmailGoodness of fitHacker (term)MereologyData storage devicePosition operatorMultiplicationMultiplication signFreewareLecture/Conference
31:21
Lecture/Conference
31:47
Computer animationLecture/Conference
Transcript: English(auto-generated)
00:10
How is everybody doing so far? Are you having a good time here? So today I'm going to tell you about my experience building Android apps at Dropbox, some interesting technical and
00:23
product challenges that we've tackled. And I'm also going to talk about the product development process at Dropbox, because people ask me a lot of questions about that, and how do you decide what to build? And so finally, after that, I'll leave some time for Q&A.
00:40
So let's get started with an introduction. But before that, I want to show off hands. So how many of you are Dropbox users? Awesome. I'd love to see that. How many of you are Google Drive users? OK, we can talk later. How many developers from Wunderlist are here today?
01:02
Nobody. Great. They're all out partying. So first, who am I? By the way, those numbers on the slide, they're all in minutes. My name is Akash. I'm an engineer at Dropbox. I work on Dropbox for mobile. I've been at Dropbox about two years, and I manage the
01:22
Android engineering team. Before Dropbox, I built the Android app also while learning Android development at a small five-person startup called Familiar. And it was a group photo and video sharing app for groups and families. Unfortunately, it failed because it turns out families are not a very good viral vector for spreading your app.
01:42
They use the app within themselves and not with others. Before that, I managed teams and built software. Microsoft in various teams, Xbox Live, SkyDrive, SQL Server. Funny story, I was actually one of the cloud leads for SkyDrive, and so now I work at Dropbox. It's going to be a competition.
02:01
Okay, so before we get to the technical topics, I want to take a few minutes to tell you a little bit about Dropbox because it will set the context for the rest of the talk today and why we do things the way we do. Okay, so Dropbox's story began back in like 2006 or
02:21
so when Drew Houston, our CEO and co-founder, was in college at MIT. So he hopped on a bus to go back home for the winter break, and he was really excited to get a bunch of work done on his coding project. And right when he opened the lid of his laptop, he realized one big mistake. He had left his USB stick with all his code at his dorm.
02:41
And Drew, like many of us, he thought to himself, man, why am I such an idiot? Why does this keep happening to me? Why does technology not work for me? And so that's when he set out to fix it. On that very same bus ride, he kind of started writing the first lines of code for what eventually became Dropbox. So when the company kind of started in 07, we lived in a
03:01
world with like thumb drives, email attachments, USB sticks, but we thought that it made no sense for your stuff not to be with you at all times. We started out by being frustrated with a pretty complicated problem, and he tried to come up with a simple solution to fix that. So what we built was Dropbox, the magic folder, and this
03:24
is the Dropbox that you're all pretty familiar with. And so for the first time, users realized that even if they kind of dropped their computer and destroyed their hard drive completely, they could just continue right from where they left off because all their data was safe and they'd not lost it. And so they never kind of had that before. I mean, there were external hard drives and such, but
03:41
you can lose those too. So people really love this. They love it enough that they're willing to say that they love it out loud on social media, on Twitter, writing feedback to us. And, you know, it's kind of funny because this is basically cloud storage. It's not a very sexy technology, and people tweet about us saying, we love Dropbox.
04:02
And it's not an accident that people love it. Part of the secret of all this love comes from our business model. And our business model is that basically we provide a service, and we make money when people who use our service decide that our service is so valuable to them
04:22
that they want to pay for greater access, for more features, for more storage. That means that we are to make software that's so good that people are actually willing to pay money for it. So in today's world, a lot of companies give away their software for free. But most of them make money by advertising or by selling personal information to other companies.
04:44
And to some extent, they're working for both, you know, they're developing a product for users, but they're also developing a product for advertisers. Dropbox, on the other hand, is selling our software and service directly to users. And you all probably know this, but users don't want to pay for anything unless it works A, really well,
05:03
and B, it gives them a lot of value, more so than what it costs, a lot more so. So why is this important? It's important because it forces us to build the best possible software, something people will be willing to pay for, and so we have to kind of go the extra mile every time we build something to build a very delightful
05:22
user experience, because that's the only way people will actually pay for something. And you should also do this in all the apps that you build, because it just makes users really happy. And so why am I talking about this? Because it's gonna set the stage for some of the optimizations I'm gonna talk about next, why we actually bother to do them.
05:40
We could have totally not done them and just shipped it without, but it makes a difference. Okay, let's get on with it. So I'm gonna go to the technical portion of the talk. It's actually going to be a two-part talk. In the first part, I'm gonna focus on some technical and product challenges that we've tackled to improve
06:01
the user experience. This addresses kind of the what and the why of the software that we build. And in the second part, I'm gonna talk about the product development process at Dropbox, the how, in some ways. So the two product and technical challenges I'm gonna talk about, the first one is about carousel,
06:22
and how carousel loads thumbnails on Android. And this portion is gonna do a little bit of a deep dive into some performance optimizations that we've made to make the user experience better. And the second scenario is something we call getting started, which is something we built to help users get familiar with Dropbox on their phone.
06:45
Okay, thumbnail loading in carousel. So what's carousel? It's Dropbox's dedicated photo gallery app. It's available on Android, iOS, and web. If you haven't had a chance to take a look, please do.
07:01
Hopefully after this talk, you'll be more convinced. So in a lot of photo gallery apps, you'll see this screen quite a lot. And you see this when you scroll quickly or you fling the photos. And these gray squares represent thumbnails that have not yet been loaded and displayed on the screen.
07:22
And so you're scrolling through your photos, you're trying to find a specific photo or a group of photos from some event, but all you see is this gray. And you have to wait for all the photos to load before you can continue scrolling, because you don't know what you're looking at right now. Okay, and here's what happens in carousel.
07:46
So this is our native library loading, it's a little slow, but okay.
08:02
So you see that the photos are always all there. Even if the user scrolls faster, the photos are always there. At the bottom there's a timeline, and you can just scrub on the timeline and the photos will always be there instantly. And yeah, that is typically significantly different from most of other photo loading apps out there.
08:26
So why is this different? And why isn't it simple? Why doesn't everybody's app look like that? Well, because there's a lot of complexity. So in order to load the thumbnails,
08:40
for some apps you have to download them from the cloud and get them to the local storage on the phone. If you're just loading apps from your photo gallery, then you don't have that. Then you have to get the photos from, so the first thing is, you know, you need serious compression for the thumbnail so that you can have a lot of it cached on the device. Then you need to get the photos from disk into memory. And so you need really good prefetching
09:02
so that you always have the data available when you need it. And then finally, you need to get the compressed data, the photo that's in memory, you need to decode it into a bitmap. And you know, many apps combine the second and the third stage together so you can load it and do a streaming decode or something.
09:23
So most companies are actually pretty good at the first two so I'm just gonna focus on this last layer of how we get the compressed thumbnails decoded just in time to show them so that there's always no gray on the screen. So why isn't this decoding so simple?
09:42
Well, if you went to Lucas's talk this morning, he talked about some performance optimizations and basically, Android's frame rate is 60 frames per second. And the way this works is, most people when they're scrolling, typically it's common for two new rows of photos or thumbnails to show up on screen.
10:03
And if you want to get 60 frames per second frame rate, then you have less than 17 milliseconds to actually do all the work on your UI thread. And for a typical screen size, which is about 600 pixels wide or so, or 600 DP wide, three thumbs across is about 200 to 250 pixels
10:21
per thumbnail, which takes about 10 milliseconds per thumbnail to decode on a typical Nexus 4 class of device. And I say Nexus 4 because you do want to make sure your app behaves well even on slightly older devices. And if you do the math, you have six new thumbnails to load,
10:40
10 milliseconds each, that's way more than 17 milliseconds. And so here's a picture from the system trace tool. The top row is basically Android drawing frames. The bottom row is basically, we made a dummy build just to demonstrate this,
11:00
where there's that pink section right there, that's when we're actually trying to load thumbnails. And because they're so big, it takes a while to load them, you see that it takes longer than 17 milliseconds and then you have all these drop frames on Android. But why are drop frames bad? Well, they're bad because if you do too much work
11:21
on the UI thread, then they're late, and the Android framework will just drop them instead of trying to render them late. And when you have drop frames, you have less than 16 frames per second, then there's a perception of stuttering by the user and you don't get that really smooth, like you get that little jagginess when you're scrolling in a list view
11:41
or view page or whatever. So nobody wants their app to feel laggy, right? And so what most developers do is that if you're scrolling really fast, they know that they're gonna have this problem and so they just don't bother doing bitmap decoding until the scroll speed slows down.
12:01
It's actually preferable to have gray squares over having drop frames. But we wanted to go a step further, we wanted to have a slightly better user experience because our whole app kind of structure is around finding photos in your Dropbox as quickly as possible and you can scrub quickly to go back to a certain event in time. So how did we solve this?
12:22
Well, here's a couple of screenshots off carousel while it's scrolling really fast. And if you look at these screenshots over here, I don't know if the people in the back can see it, but they're actually pretty pixelated. They're not full resolution thumbnails. So the key here is that we're not optimizing for beautiful screenshots,
12:41
we're optimizing for a beautiful user experience. And when you're scrubbing really quickly through your photo collection, looking for something, you actually don't need the full 250 or 300 pixel thumbnail. You just need something with the right colors and shapes in it and your brain can kind of fill in the rest and like, oh, this is the photo I'm actually looking for.
13:01
And then when you slow down, that's when you want a high resolution thumbnail. And so also when you're flinging or scrolling really fast, in 100 milliseconds, the screen is gonna be off screen and so why bother with high resolution thumbnails? So how do we do it? Well, when you're scrolling really fast,
13:22
we actually switch to loading 75 pixel thumbnails because they will decode really quickly. And then when you slow down or when you're stopped, you always want to show the 250 pixel thumbnails because then they don't look pixelated, they look crisp and clean. And so the full solution is basically on your main thread,
13:41
we're only usually decoding and rendering 75 pixel thumbnails and you're queuing up the 250 pixel thumbnails to decode on a background thread and we swap them in to the view once they're actually fully decoded. But if you're scrolling fast and the image actually is now off screen, you want to dequeue those large thumbnail decodes
14:03
off of your background thread so you're not doing wasted work. So this is a trace of the real carousel handling a fast scroll. So you'll see some examples right there where each of those pink slots represents the 75 pixel thumbnails being loaded and decoded
14:23
and you see that they're small enough that you can actually do that in that 17 milliseconds that you have. And in the middle row, you'll see the background thread, actually we're queuing up the decode bitmaps for the cases where we actually want the higher resolution 250 pixel thumbnails. If you look at the top,
14:40
the surface linger, it's not actually dropping any frames, it's just very crisply running at 60 frames per second. And so the outcome is that the user never sees any gray squares. When you're scrolling fast, the decode requests are queued and then dequeued off of the background thread and we don't do any wasted work loading the big thumbnails.
15:01
And when the user starts slowing down, the background queued bitmap decodes start finishing and then we swap them in once they're completed to replace the 75 pixel thumbnails. Everybody with me so far? Okay, cool. All right, well, let's talk about something else then.
15:21
Okay, getting started. So getting started is something we did to improve the first run experience for users who specifically sign up for Dropbox on their Android device, as opposed to on the web or on their desktop. So what is getting started? Well, it's a guided kind of handheld
15:40
first run experience for new users. It's only shown to users who sign up on the phone and the entry point is through this persistent notification in our kind of notifications feed. It's basically a Dropbox tutorial. So when you click on that notification,
16:01
you see the screen here and it's like a checklist of tasks to perform. And each of those tasks can be clicked on and it'll take you kind of to the relevant place in the app where you can perform each of those actions. And so why is this important? Well, we realized that users who install Dropbox
16:23
on their phone get some value out of it, but the users who get the most value out of Dropbox are people who have it both on their phone and on their computer. Most creative work happens on the computer, most content is created on the computer, and so it's really important to have Dropbox on your computer
16:42
so you can easily add that content to Dropbox. And it's also really important because you have a lot of that existing content on your computer that you created in the past but you don't have it on your phone. I mean, most people use their phone for consuming content and they don't have their files on their phone.
17:01
I think Photos is the only exception. And so what this does is it explains the value proposition of Dropbox to the user by kind of doing as opposed to just telling. The user can actually click on those and then do things like adding their photo content to Dropbox or installing Dropbox on their computer.
17:25
And the interesting thing here is that we incentivize the user to actually complete these tasks by giving them some free space as a reward. So it's a little bit of gamification thrown in there to actually get them to do this.
17:41
So I'm gonna actually talk about a specific task in the getting started. It's this task called install Dropbox on your computer. And what we call that, we call that desktop connect. And desktop connect is a flow designed to simplify the installation of Dropbox on your computer
18:02
once you've installed it on your phone. And it's important. We want users to install it on their computer. That's when they get the most value out of it. That's when the value they get out of it exceeds the cost of Dropbox and that's when they're actually willing to pay us for it. And this is important enough for us
18:21
that we actually have multiple entry points into this flow. If you sign up for Dropbox, typically you'll have no files in it. So you'll see this empty screen and we have this set up now button that takes you to this flow. We have this, an entry point to this inside the getting started task. It's called install Dropbox on your computer.
18:42
You can also go to your settings and click on link a computer and it also launches the same flow. So you know, repetition is important because it gets users to, you want to funnel users into performing this flow. So in order to reinforce it,
19:00
what are some of the other things we do? Once you actually click on that, we show them the screen and we ask them are you near a computer, right? And if they say yes, then they'll continue on the flow but if they say not now, well that's an opportunity for us to actually show them a notification at some point later, maybe a few days later, reminding them that hey, maybe you can,
19:21
maybe you're near a computer now. Do you want to perform this task? And then once you actually click yes and you launch this flow, this is what you see. It's a very, very step by step process designed to make things really easy. And so we ask them to go to Dropbox.com Connect on their computer and once they do that,
19:42
this is what they see. They see the screen on their computer. And you can see that number one, the first task that you started on your phone that continues on your computer to kind of keep that sequence going. It's a very Dropbox-y screen. It's very clean.
20:02
We stuck our logo in there but if you actually look at that logo carefully, there's a whole bunch of QR codes embedded in that logo. And so when you, the instructions there say tap next on your phone and then point it at the image below. And when you actually hit next, it launches a camera in-pain camera screen
20:21
and then when you point it at this, the camera actually scans the QR code. And when that scans that QR code, you see this screen which basically says, it's a very personalized screen. It has my name on it and it tells you what it's doing. It's downloading Dropbox on your computer and then it has a little thing which points to the actual installer
20:41
that we are downloading. The installer is really small, maybe a few hundred kilobytes because we wanted to complete this download really fast. If you have a large file that's downloading, people have a attention span of maybe one or two seconds and if it's gonna take like 15, 20 seconds, they switch to a different tab and they completely forget about this task.
21:04
And so once you actually click on that, the installer launches. It's a personalized installer because you already signed in to the website and when you downloaded the installer, so it already has your credentials embedded in it and you don't actually need to type your credentials in anymore.
21:20
And so how does this work? Well, on the back end, we generate a 24 byte kind of token and we store it in memcache with a very, very fast expiration time. And then we generate a QR code for that token and nonce with a URI associated with it and we actually embed it in this image.
21:42
And on the phone, sorry, yeah, on the phone, when you go to dropbox.com slash connect, that token is generated and the website shows you the QR code and it kind of starts pulling the back end saying, hey, has the user actually completed the second half of the flow on their phone? And then when you point your phone at the screen, we have the camera going, it scans the QR code,
22:02
we get the URI out of it and we ping the kind of server endpoint. And since you're already signed in on your phone with Dropbox and when we hit the server, we pass the user's credentials from the phone up to the server. Now the server can associate the user's credentials or the user ID of the phone
22:21
with this like whatever user is on the website and basically you can log them into the website automatically as a result. And so that way you can kind of get browser login on Dropbox even though you signed into Dropbox on your phone. And of course, this is not, it seems simple at a high level
22:41
but you need to handle all kinds of edge cases like your token being evicted out of memcache because there was memory pressure or because the user sat on that dropbox.com connect page for too long. You can have connection errors on some Android devices, QR codes don't scan correctly, so all kinds of issues.
23:03
So why did we build this? Well, most of our users sign up for Dropbox and mobile first. But we found that desktop users are the most engaged and productive and in fact, desktop plus mobile users are even more engaged and productive. Mobile users have no content on sign up so it's kind of like a chicken and egg problem. Services like Spotify can show you a whole bunch of music
23:23
when you sign up for the first time but here, this is your stuff that you're putting in Dropbox. It's a little easier on the phone, you have photos which is why one of the tasks is tells you to turn on camera upload on your phone but we want to get your other content into Dropbox too.
23:43
And that mobile to desktop transition is high friction, just telling the users, oh, go to the website, download the client, install it, doesn't work as well as something like this. Of course, there's a large download, people forget the password that they sign up on the phone for. So, yeah, that's basically why we built this. Are you guys still here?
24:01
Okay, cool. All right, I'm gonna switch tracks a little bit, talk about product development at Dropbox. This is more of the human side of things so the rest of my talk is not very technical anymore. A lot of people ask me, how do we work on a day-to-day basis? How do we decide what to build?
24:20
So here's kind of the inside look. There's nothing revolutionary here. I mean, a lot of you probably do this but hopefully it'll give you an insight out of how things work at our company. So basically, I think of product development as kind of a three-pronged approach. There are the company-wide initiatives.
24:42
Those are the features or products that we build across all the platforms. So we build them on web, we build them on desktop, we build them on mobile. And these are kind of the big features, the marquee features, the things we make press announcements for. And these are driven by product managers based on strategy, user research, competition, blah, blah, blah.
25:02
The second set of things we do is kind of for growth and engagement. This is to increase and engage your user base, increase your key metrics, increase revenue. And this is mostly driven by kind of the high-level company goals for the year, like where do we want our user base to be in a year? Where do we want our revenue to be
25:20
at the end of the year, things like that. And the third one, which is kind of the most exciting for me is kind of bottom-up innovation. And this is basically putting power in the hands of engineers, right? This is letting your engineers come up with the new product ideas and the new features, right? You've hired really, really smart people to work at your company, so let them actually
25:41
contribute to product development. Run experiments like do A-B testing, do all the things to see what works. So yeah, engineers are smart. Let them contribute to product development. Do a lot of experimentation. We actually hack a lot on our product to see what works and what doesn't work.
26:01
We use 1% experimentation on Android a lot. Again, to see what features are sticky, what is not sticky, what is actually working for users. And finally, we have something called Hack Week. This is a week-long, 20% time, but it's 100% time for a week.
26:20
Happens a couple of times or a few times a year. And basically, it's a week where you can not do your regular job and just do anything, like just build any new product, any new feature. It doesn't necessarily have to be Dropbox-related. It can be anything technology-related, right? And a lot of innovation comes out of this. And a lot of the stuff that comes out of this
26:42
actually ends up in our primary product. So we recently launched a feature called Harmony, which is this blue bubble that shows up on Microsoft Word. And if you're in a shared folder and editing a file in a shared folder, it tells you the blue bubble turns red if somebody else you've shared with also has that file open. And if they've edited that file, it'll tell you that,
27:01
you know, John has edited this file. You probably don't want to touch it right now. So that was something that came out of Hack Week. Somebody just hacked it up in like three days and eventually we made it into a product. Cool. So last thing is I want to talk about team structure. We have a very monolithic platform team.
27:21
We have an Android team. We have an iOS team. And the bottleneck here is kind of team bandwidth. We prioritize our feature requests across all kind of incoming features for maximum impact. And that means that some feature requests get starred because they're, you know, small requests. And the feature is basically we want to spread
27:41
mobile talent into feature teams across the company and while maintaining kind of primary app ownership with this core platform team. And so what are the benefits of feature teams? Well, you can iterate very quickly on new features. You can make progress without being blocked on the kind of Android experts.
28:03
And you can have, you know, all the disciplines working very closely together to ship stuff. And also the important thing is that there's long-term ownership of features. There's not this notion of drive-by coding where somebody basically just builds something for like a sprint or a milestone and then they move on to working on web and then move on to working on infrastructure.
28:21
And then you're stuck like maintaining that feature. And also it helps them kind of make progress on the kind of the smaller impact features which may not be important for us to do but, you know, it's interesting for say the growth team to work on. And the core platform team will, you know, it's important that they maintain ownership
28:41
of critical product functionality. So in our case, for example, the core Dropbox file browser would still be owned by the platform team. And the other job, their other role is to accelerate the rest of the company through, you know, better tooling, more, you know, better abstractions, more modular code, and also, you know,
29:01
spreading Android expertise throughout the company. You want to really make sure that if you have this model this core platform team is happy and they have strong product ownership because otherwise it's very easy to put them in this role where they're just fixing bugs or fixing other people's problems or doing code reviews. And it can lead to people getting dissatisfied.
29:23
So you want to be careful about making sure they actually feel strongly vested in the product. Okay, so both these models have kind of pros and cons. In the model, you get really deep platform integration because everybody working on the team is kind of an Android expert.
29:41
And you have this really, really deep, cohesive user experience across all the features in your app. But when you have feature teams, then you get fast development and iteration, but potentially the people working on those teams aren't necessarily deep Android experts, and so you might have slightly lower quality. And, you know, this is a matter of time.
30:01
Expertise will come by doing, so you want to make sure that the folks on the feature teams aren't basically working on Android for three months and then jumping to iOS for another three months and then jumping to web for the next month. You want to make sure that they specialize in something. And, you know, during the Q and A, I would love to hear if any of you have done this
30:21
and what works and what doesn't work. Cool. So that's mostly it. Before we go to Q and A, I very quickly want to say this. We love Android engineers. We are hiring both here and in the US. We have paid and full-time positions,
30:41
both internships and full-time positions. And if you're interested, send an email to me. My email is sky at dropbox.com. And there's a lot of good benefits of working at Dropbox. You know, you get unlimited vacation. You get unlimited Dropbox storage. You get to work in, you know, take part in multiple hack weeks per year.
31:00
And you're surrounded by really, really smart people. So you're constantly learning from them. But, I think the most amazing perk of Dropbox is the food. So we have an in-house kitchen at work. We call it the Tuck Shop. And you get free breakfast, lunch, and dinner every single day. No dish is ever repeated, ever.
31:23
And so here's a peek at just one week, just one week worth of the food from the Tuck Shop. Wait for it.
31:40
Well, lunch is next, so.
32:03
Cool, so, yeah. And that's about it for me. Thank you. If you have any questions. Thanks guys.