A behind-the-scenes look at LinkedIn’s mobile engineering

Pros' network was anything but in the mobile space. Then ethos and execution linked up.

LinkedIn is the career-oriented social network that prides itself on professional excellence. But the company's original mobile offering was anything but—it left much to be desired. There was an iPhone application, but no support for Android or tablets. The backend was a rickety Ruby on Rails contraption; afflicted with seemingly insurmountable scalability problems. And despite serving only seven or eight percent of the LinkedIn population, the company's original mobile build required approximately 30 servers in order to operate. This was clearly not made to sustain a growing mobile user base.

Now, a little over a year has passed since LinkedIn relaunched its mobile applications and website. And the company recently marked the anniversary by debuting a number of new mobile features, including real-time notifications and support for accessing company pages from mobile apps.

Mobile is gradually becoming a central part of the LinkedIn landscape. The company says roughly 23 percent of its users access the site through one of its mobile applications, up from ten percent last year. As our friends at Wiredreported last month, the underlying design language and development philosophy behind the company’s mobile experience is playing an influential role as the company works to revamp its website.

No one knows more about this paradigm shift than Kiran Prasad, LinkedIn’s director of mobile engineering. Prasad was one of the key players in LinkedIn's efforts to resurrect its mobile offerings, and he was kind enough to walk Ars through the process. LinkedIn's mobile man provided a behind-the-scenes look at how the company built its mobile applications and the associated backend infrastructure, while also describing the design strategy the company used to build its mobile interfaces. As you'd probably expect from the brand, it was all a professional level effort.

Initiating an overhaul

LinkedIn decided it was time for a massive overhaul as the company began recognizing the increasingly important role that mobile access would play for the social network’s users. Jet-setting professionals rely on their smartphones to stay in touch while they travel, right?

Mobile soon became a major strategic focus for LinkedIn. In August of 2011, roughly five months after the mobile overhaul began, the company launched an all-new set of mobile apps powered by a completely new backend.

When the effort began, the mobile engineers at LinkedIn had several major goals. They wanted cross-platform compatibility, with support at launch for Android, iOS, and the mobile Web. They also wanted to simplify the user interface, taking the number of icons on the main screen down from 12 to three or four. Finally, they wanted a holistic rewrite—rebuilding both the frontend and backend together with an eye for boosting scalability.

Prasad previously worked on WebOS at Palm before joining LinkedIn. He brought a wealth of knowledge about building native-like user interfaces with modern Web standards. He regards the mobile Web as a platform in its own right, one that LinkedIn had to support well alongside Android and iOS. So Prasad decided that making HTML5 a central part of the company’s mobile strategy would make it easier to reach all of those environments.

HTML offers a useful way to reach more screens, but Prasad believes there are still many places where native user interfaces and native code are needed in order to deliver the best possible user experience. LinkedIn set out to use a hybrid model; blending the two to theoretically offer advantages of both.

This approach made it easier for a small team to support multiple platforms. And crucially, it allowed other LinkedIn developers outside of the mobile team to contribute to the effort using their existing skills.

Everything must be simple

Prasad told me that simplicity is at the heart of LinkedIn’s mobile vision. The company’s internal definition of simplicity, he said, holds that a good solution must be fast, easy, and reliable—in that specific order. Each of those characteristics is considered ten times more important than the next, making performance the chief concern. That philosophy motivated his team’s decisions in almost every area, ranging from visual design to backend engineering.

The thing people value most, according to Prasad, is their time. When users encounter flaws in software, they tend to be more forgiving if the software is extremely fast. A crash is less disruptive, for example, if the application is quick to restart and offers a quick path back to where the user was.

Speed is also especially important for mobile experiences in his eyes, because smartphone users tend to have shorter sessions (often less than three minutes long). Users expect applications to deliver relevant information as quickly as possible.

Ease of use was his next major priority, and Prasad said LinkedIn measures this by counting the number of clicks that it takes for a user to complete a given operation. If it takes more than three, he said, users are going to lose patience and easily be drawn away by push notifications or other things happening on their phone.

Reliability is the final of the three priorities. Basic robustness and stability are important, Prasad told me, but reliability also encompasses other ideas like consistency and predictability. To him, a reliable application is one the user can depend on to behave the same way every time. When the user taps a button and it takes them to another screen, for example, going back and tapping on the same button should take them there again. A surprising number of applications ignore that seemingly obvious design principle, Prasad said.

During the design process, LinkedIn used a simple metaphor to encourage predictability and ease of use. The idea is that an application is like a house—there are rooms with specific functions, and there are corridors that connect those rooms in a practical way. When you are putting together a room, you don’t fill it with an incongruous range of functions. You may end up with a living room, a bedroom, a kitchen, and a bathroom. But you don’t cook in the living room and you don’t sleep in the bathroom.

Continuing this house analogy, when you begin designing an application, you start by defining the structure. You determine what rooms you want, what their purposes will be, and how those rooms will be connected. You don’t start with the visuals (in the house analogy, these are like the carpeting or the paintings on the walls). When you introduce a feature, you think about the room in which it belongs.

For the mobile application, LinkedIn decided that it didn’t want more than four “rooms” of functionality. You can clearly see the house metaphor in action when you open the LinkedIn iPhone application. The main screen limits itself to four icons: your updates, profile, messages, and groups. It serves as the hallway, allowing the user to tap an item in order to enter a given room.

33 Reader Comments

Reading this and comparing it to the writeups about Facebook’s switch back to a (more) native code using app is interesting. And as much as I like to be sceptical about Facebook the company, they do have some very, very competent people on their payroll. On LinkedIn I deleted my profile a few months back anyway. So, yeah, good for them for discovering HTML5 and the fact that Rails can’t cover the whole spectrum of needs a massive platform like LinkedIn has (just like Node.js can’t). One would think that was common knowledge years ago already.

"The company’s internal definition of simplicity, he said, holds that a good solution must be fast, easy, and reliable—in that specific order. Each of those characteristics is considered ten times more important than the next"

This is the most interesting statement to me. Anyone know of any published evidence or studies relevant?

Their mobile site is downright awful. Their device detection is overly aggressive, so even if you deliberately go to the desktop site, it bumps you back to the login page of the mobile site. Which doesn't work on many Android devices. (And by many, I mean "all 3 that I own.") Even their support team admits the mobile site doesn't work, and their solution is to tell it to use the desktop site... which would be nice but the menu to get to telling to go to the desktop site *doesn't work*!

Sorry, not installing the Android app to find out if it works -- the permissions are WAY too aggressive and they collect way too much PII.

And not to mention the privacy breaches thanks to stealing our contact info http://arstechnica.com/apple/2012/06/yo ... kedin-app/ which you mention at the end of your cheerleading article.Why am I so pissed off at LinkedIn, this idiot who found out omg node.js is faster than rails, and their shitty practices.

And not to mention the privacy breaches thanks to stealing our contact info http://arstechnica.com/apple/2012/06/yo ... kedin-app/ which you mention at the end of your cheerleading article.Why am I so pissed off at LinkedIn, this idiot who found out omg node.js is faster than rails, and their shitty practices.

And not to mention the privacy breaches thanks to stealing our contact info http://arstechnica.com/apple/2012/06/yo ... kedin-app/ which you mention at the end of your cheerleading article.Why am I so pissed off at LinkedIn, this idiot who found out omg node.js is faster than rails, and their shitty practices.

Calm down.

He may need to calm down, but I agree : after the fuck up that LinkedIn made with the iOS app, I deleted and will never install anything from them again.

And my trust in LinkedIn is so low that I even consider deleting my account.

One may disagree on the value of LinkedIn or the developer interviewed, but it is clear from my experience that many developers can benefit from some of the basic tenets outlined in the article.

Here are two of the usability guidelines that are frequently ignored by major websites / apps (thankfully not Ars):

Quote:

Ease of use was his next major priority, and Prasad said LinkedIn measures this by counting the number of clicks that it takes for a user to complete a given operation

...a reliable application is one the user can depend on to behave the same way every time. When the user taps a button and it takes them to another screen, for example, going back and tapping on the same button should take them there again.

An example violation of both of the above are the navigation controls for www.macnn.com, which alternate between underlined links (http://www.macnn.com/#jq_older) in one position on the page and dimensionally uneven tabs in another position:

And not to mention the privacy breaches thanks to stealing our contact info http://arstechnica.com/apple/2012/06/yo ... kedin-app/ which you mention at the end of your cheerleading article.Why am I so pissed off at LinkedIn, this idiot who found out omg node.js is faster than rails, and their shitty practices.

Calm down.

He may need to calm down, but I agree : after the fuck up that LinkedIn made with the iOS app, I deleted and will never install anything from them again.

And my trust in LinkedIn is so low that I even consider deleting my account.

I agree with you both and I'll add that linkedIn has had absolutely zero effect on my career and just seems to be a bunch of tech recruiters spamming my contacts.

But still, there's no reason to be rude to that guy and the article is interesting.

curious how combining native elements with HTML using a local HTTP server is 'simple'. After working on an iOS app that uses embedded webviews to display some content, and native UI for other content -- and the headaches of communicating and managing embedded webviews, a fully native app seems like a much better approach.

Clearly linked in is useful as a website. I don't see why they think they need a mobile app though. Hey aren't Facebook, they are just a convenient way to catch up with people you used to work with. As a consultant I have about 30 potential employers on linked in.

Linked in's mobile Android is pretty crap. About all you can do on them is chat. Can't get contacts without syncing. And don't get me started on Touch.linkedin.com, also crap and I've got to wait for like 13MB of JS to download. And now their front page is a bunch of yahoo like crap that I don't care about. Luckily I really only use it to find other people's contact info (like glacier for contacts). Unfortunately their crap apps make that almost impossible with slow network.

FWIW I lead the mobile team at a tech company of similar size to linkedin.

I would have been interested to see some more in-depth explanation of the net ROI they think they achieved with their hybrid solution. I agree with a previous poster that it sounds like significant time was invested in developing a native/webkit bridge first in javascript, then websockets, then finally again as an HTTP server. It sounds like that was included to give a sense of how hard they worked at this, but it does seem to fly contrary to his #2 mantra: "easy".

How much of that time could have been spent elsewhere I wonder?

I also have zero idea how the explanation of using a long polling solution for network traffic has anything to do with MVC. I think that entire section of the article was some sort of misunderstanding between the author and the engineers.

Enlightening article. Don't think it really matters who the developer or the company is, more so the strategies and technologies being discussed.

Like the house analogy used for design. So much so that I might just steal it. Also agree somewhat with the MVC comments. Even the conventional desktop web apps seem to moving away from what would be traditionally called MVC to MVVM or something similar. Also agree with the need for a "pipe" to the backend. I think this transcends mobile apps and has a place on the desktop too. Meteor is something that interests me a lot (http://meteor.com/).

The one part that I can't understand is the split between HTML and native. Admittedly, I don't know a lot about PhoneGap and the other offerings, but my understand was that they exist to do exactly what you have spoken about. I can't see why you need to imbed a HTTP server to get access to contacts etc.. Surely this is something PhoneGap can handle? The native list controls I can understand if the performance they have spoken about is correct.

There is a little detail that Ryan missed here - "sponsored article" - it sounds like one, if feels like one, it reminds me on non-ARS web sites, that I am not visiting anymore.... Also, LinkedIn has lost every piece of >my respect< by treating their users with >no respect< whatsoever - storing the passwords in SHA-1 - a high-school level knowledge. Of course "the high-tech" guys from LinkedIn probably (....) - I will stop here.and the Quote of the Day: "...prides itself on professional excellence..." - comedy channel gets jealous.sorry, and the last one:"LinkedIn's app on a second generation iPad—demonstrating the relaunch focus on speed, simplicity, and reliability." - yeah, and the battery indicator drops by 48%...

I would have been interested to see some more in-depth explanation of the net ROI they think they achieved with their hybrid solution. I agree with a previous poster that it sounds like significant time was invested in developing a native/webkit bridge first in javascript, then websockets, then finally again as an HTTP server. It sounds like that was included to give a sense of how hard they worked at this, but it does seem to fly contrary to his #2 mantra: "easy".

"Easy" doesn't refer to ease of implementation:

Ryan Paul, in the article, wrote:

Ease of use was his next major priority, and Prasad said LinkedIn measures this by counting the number of clicks that it takes for a user to complete a given operation.

DougHW wrote:

I also have zero idea how the explanation of using a long polling solution for network traffic has anything to do with MVC. I think that entire section of the article was some sort of misunderstanding between the author and the engineers.

Not quite.

I'm on a small team responsible for an enterprise-deployed mobile application that pretty much fetches remote content for every single view. The original implementation was outsourced, and web views were used liberally - not an intrinsically bad thing. To populate these views, RESTful GET requests and POSTs are made to a remote web server running an MVC application, which returns complete HTML documents that are rendered as-is. This means that half of the application state is implicitly server-side!

For our inevitable rearchitecting and rewrite, we want to cache content aggressively, store templates client-side (with the ability to invalidate and update them from the server) and keep all state purely client side. This means the application may request from the server all content matching a set of filters updated since a provided timestamp in order to refresh its cache; rather than opening and closing several connections, we want to open a single long-lived connection and stream all of the relevant metadata, assets and content. (Again, remember that the original implementation just rendered the returned HTML, which means that URIs for images, etc pointed to the server, and because the web views were being created and destroyed with navigation, the images were not being effectively cached.)

In the long-lived connection implementation, there are no longer "views" in the traditional MVC web application sense. The final result of server-side processing in the controller to aggregate any necessary data is not markup written to the output stream but rather a large binary blob which the client unpacks to extract all relevant data.

So while I see your concern that the term MVC is being misused here, its usage is correct in a web application context-specific sense. The "view" (markup written to output, including references to external URIs that must be resolved by the rendering web view) is now an aggregated data stream, which gets unpacked, cached and then rendered client-side into the view.

curious how combining native elements with HTML using a local HTTP server is 'simple'. After working on an iOS app that uses embedded webviews to display some content, and native UI for other content -- and the headaches of communicating and managing embedded webviews, a fully native app seems like a much better approach.

I'm on a small team responsible for an enterprise-deployed mobile application that pretty much fetches remote content for every single view. The original implementation was outsourced, and web views were used liberally - not an intrinsically bad thing. To populate these views, RESTful GET requests and POSTs are made to a remote web server running an MVC application, which returns complete HTML documents that are rendered as-is.

I don’t know about the size of your deployment, but your planned approach sounds a thousand times better than what you got delivered by the company you oursourced to if scaling is important. Even for web-only applications things like Batman.js (if you can support coffeescript) helps a lot to bring the whole rendering and layout to the client side, especially if you’re counting on low latency updates from the server. Regenerating all the HTML all the time is often not feasable once you go into 100+ simultaneous users territory without the appropriate backend resources (which many companies don’t care to provide and which, themselves, require a lot of time spent setting them up if you are in a small team).

I find it fascinating how often "serious business" web companies (like LinkedIn) mess up with decisions that seem really, well, fairly easy to decide on to me. A small team obviously might need an attempt or two to figure stuff out, but LinkedIn et all are paying their people big bucks (hopefully!). Anything but a rock solid and secure solution makes those teams look really, really incompetent.

I don’t know about the size of your deployment, but your planned approach sounds a thousand times better than what you got delivered by the company you oursourced to if scaling is important. Even for web-only applications things like Batman.js (if you can support coffeescript) helps a lot to bring the whole rendering and layout to the client side, especially if you’re counting on low latency updates from the server. Regenerating all the HTML all the time is often not feasable once you go into 100+ simultaneous users territory without the appropriate backend resources (which many companies don’t care to provide and which, themselves, require a lot of time spent setting them up if you are in a small team).

Amen... and you don't know the half.

I should clarify and point out that the in-house development team, which is very small, was only brought in after the application had been in active deployment for some time. If we had been on staff when this project was being specced out, I would never have allowed such an addled design to move forward.

smoofles wrote:

I find it fascinating how often "serious business" web companies (like LinkedIn) mess up with decisions that seem really, well, fairly easy to decide on to me. A small team obviously might need an attempt or two to figure stuff out, but LinkedIn et all are paying their people big bucks (hopefully!). Anything but a rock solid and secure solution makes those teams look really, really incompetent.

To me, a lot of it stems from a perspective-based lack of knowledge/understanding of the constraints of native applications on the part of less experienced web developers. Since a web application is largely useless without network availability (Web Storage aside), a lot of developers unaccustomed to building large-scale systems don't think to ensure components can operate if counterparts fail or are unavailable; and they don't think too much about memory implications, particularly the sorts of constraints presented by mobile devices. I'm convinced the frequency of these large, web-based startups shipping mediocre mobile/native experiences and subsequently upgrading them significantly - typically by moving away from their pure web technologies approach and incorporating techniques long familiar to native platform developers - is a reflection of experience and competencies.

Besides, the consequences of "looking incompetent" are clearly negligible: Facebook, Twitter and more all experienced regular interruptions and failures as they pursued scale (remember the fail whale?), throwing more hardware/money at the problem when forced to and only turning to improved implementations once the early subscriber growth started to level off or the pressure to show profits started to mount.

And that's before you get buy-in from management. I'm preaching the gospel of infrastructure, but, even as he acknowledges its important, my boss primes us for a brainstorming session with the CEO by specifically noting that he isn't interested in infrastructure. He wants to hear about "sexy" ideas like sales metrics and heat maps.

You know what I think is sexy? Being able to reach, convert and process all of your customers, every time

Like half, or more, of the comments here I am baffled at the cheer leading this article represents. My entire experience with LinkedIn on a mobile platform can be summed up in the image link. Oh and occasionally it asks me to install an app... no thanks.

What I find is still missing in the mobile business space is a standardised, widespread e-business card distribution system that isn't a load of crap. With NFC here it seems like a good opportunity to try again. If Linkedin wants to be anything more than a corporate Facebook maybe they should take the lead in this. Right now they are probably best positioned to succeed.