6 ms·

Facebook made the mistake of optimizing for their developers' sense of efficiency -- at the cost of user experience -- rather than optimizing for their users' e

Facebook made the mistake of optimizing for their developers' sense of efficiency -- at the cost of user experience -- rather than optimizing for their users' experience. Given the resources available to them, switching to UIWebView was a ridiculous trade-off. I'm glad to see they rectified this decision. The lesson to be learned is this: at the end of the day, it's the product and user experience that matters. If you sacrifice product quality for some notion of engineering perfectionism -- whatever it might be -- you're not doing your job as a professional engineer.

dclusin 14y ago
Another problem as well is people do not update their apps, which I suspect occupied quite a bit of discussion. I could see this becoming quite the headache when operating at the scale of facebook.
- deleted 14y ago
  [deleted]
- why-el 14y ago
  I wonder if the mobile space (asking out of complete ignorance) has an example similar to Chrome's automatic updates. But I guess given the amount of bandwidth that goes into regularly updating mobile apps, I am not sure people will opt for it.
  - CodeCube 14y ago
    You can mark an app to auto-update on the google play store for Android. It's opt-in by the consumer
  - jsnell 14y ago
    Android is now supposed to do updates with binary deltas rather than full reloads, which should help a lot with the bandwidth issue.
- hdoan741 14y ago
  Facebook may put announcement (or that sort) in their app to let people know that they should upgrade.
pdog 14y ago
It's more complicated than you make it out to be. Facebook has to work consistently on so many different platforms (not just iPhone, Android, Blackberry and Windows Phone; also, the billion+ feature phones out there) and continuous deployment is the process at the heart of Facebook (the motto: move fast, break things). Facebook is always adding new features and improvements. By using Web technologies, they can share code and make these changes on the server side, not to ease developers' efficiency but to guarantee interoperability and a consistent user experience.
- flatline3 14y ago
  > It's more complicated than you make it out to be. I didn't make it out to be simple or complicated. They valued their sense of developer efficiency over user experience.
  - snowwrestler 14y ago
    No matter how efficient your developers are, it's gonna take longer to get a new version of a native app submitted, approved, and downloaded by users, than it is to simple deploy to a webserver. By going native, Facebook has greatly improved the user experience of this version of their app (which I applaud), but greatly slowed the speed at which they can iterate to the next version.
    - flatline3 14y ago
      User spend their time using the application, not waiting for an update. Sacrificing their user experience for rapid updates is putting a sense of engineering efficiency ahead of user experience.
      - smackfu 14y ago
        What if the update is a bug fix?
        flatline3 14y ago
SoftwareMaven 14y ago
That assumes developer efficiency is what they were optimizing for. If, on the other hand, they were optimizing in a way that attempted to trivialize mobile to drive people to the (more profitable for them) desktop, then then entire experience makes sense from a product perspective.
- jamesaguilar 14y ago
  Or maybe a space alien told them that they must do it in HTML5, as long as we're trading in unlikely hypotheses.
- flatline3 14y ago
  I based my assessment on Facebook's public statements regarding their choice of technologies, rather than assuming some sort of deep conspiracy. It's basic organizational politics. Any organization will have difficulty adapting to a completely different platform, and management will attempt to reframe the problem to fit within the bounds of their existing organization. In this case, a traditionally web-focused organization attempted to co-opt mobile development into their existing organizational hierarchy by reframing the problem. It wasn't until persistent external pressure was applied (user complaint, blatant failure obvious to external management) that they were forced to accede ground.
  - SoftwareMaven 14y ago
    I tried to put myself in the shoes of a product manager at FB, knowing that revenue from mobile sucks but everybody wants a mobile solution. How could I accomplish both? By not making a fuss when engineering builds what is obviously a substandard app. What I forgot to take into account is that Facebook isn't really led by product management. Could FB's PMs force a change like that, after development has built it? I don't know.
sidcool 14y ago
Can you pls explain the issue in more detail or mention a link?
- xstm 14y ago
  http://www.readwriteweb.com/archives/redux_how_facebook_mobile_was_designed_to_write_once_run.php http://www.readwriteweb.com/archives/redux_how_facebook_mobi...
tptacek 14y ago
Choosing platforms to optimize developer experience enables you to get more features out the door faster, which is usually the right decision when you don't know precisely which feature set the market is going to value. After a year or two of experience, it's a lot easier to go back and pick a different platform to optimize for something else.
- flatline3 14y ago
  Trade-offs to accommodate your resource or skill contraints are just that -- trade-offs. They're not optimal solutions for your users or your products. Singular dedication to user experience may have an intangible value, but Apple and others have consistently demonstrated that the value is high. This isn't a trade-off Facebook needed to make. Whether it's a trade-off your organization needs to make depends on your resource availability, skills, and target market. However, there's no value in dressing up the trade-off as anything other than a trade-off. The target market and product factors into the question of resource allocation. Nest would not have made such a splash if they decided to skip user experience and focus on fast feature roll-out, and Dropbox would not have succeeded to nearly the same degree (if at all) without first-rate native user experience.
  - tptacek 14y ago
    I reject the idea that Nest and Dropbox were in similar positions as Facebook. The entire value proposition of Nest is simple (and simplicity). Same with Dropbox. It is harder to make a case for how Facebook could have had a "simple" value proposition 2 years ago. You're making a case for why Dropbox didn't have to go through the time-to-market-driven experimentation Facebook did. That is indeed an advantage to being Dropbox. It isn't a very good indictment of Facebook's strategy.
    - flatline3 14y ago
      Facebook started with a native client. They switched to HTML due to internal organizational politics. I'm not sure what you're arguing -- that somehow Facebook lacked the resources to invest in user experience and rapid mobile development from the beginning? It's not as if mobile was unproven at the time they decided to switch away from their native mobile client.
Androsynth 14y ago
This HN meme that all companies should be like Apple is getting a bit ridiculous. FB has always been an efficient engineering organizing that pushes out features constantly. They don't derive their value from their UI nor have they ever. There is no reason for them to start copying Apple now. FB users don't use it because of the slick interfaces, they use it because of network effects. For that type of business, adding features fast (to create more lock-in) > focusing on great UI.
- shadesandcolour 14y ago
  Who says Facebook needs to be like Apple? No one is arguing that Facebook needs to change or make their UI better than it was or that it was even a feature they cared about. The issue was the experience delivered by the client they had out, which sucked. They picked a technology which everyone knew would be slower in order to make it easier on their mobile team. Instead of investing in an Android team and an iOS team, they wanted to make the code portable. Sadly using a UIWebView comes with zero benefits on iOS and Facebook suffered for that. They should have kept their native client in the first place. The point of using a web view is so that you can rapidly prototype features and UI, and as far as I can remember, Facebook did very little of that on mobile anyways.
  - peterhunt 14y ago
    The trendy idea that startups should stay in stealth mode until their UX is completely perfect is a very Apple-y idea which throws away many years of hard-earned knowledge about iterative development processes. Apple can do it since they make hardware and that people will buy whatever they put out, highly competitive web companies, not so much.
- deleted 14y ago
  [deleted]
- flatline3 14y ago
  > They don't derive their value from their UI nor have they ever. I'd be interested in your supporting arguments, especially in light of this investment they just made entirely for UX reasons.
mmahemoff 14y ago
They also made a bet on HTML5 closing the gap on native app platforms over time. But the bet turned out to be wrong as the gap has actually increased.
jamoes 14y ago
Using a UIWebView has benefits other than just developer efficiency. If Facebook wanted to run A/B tests in a serious capacity, they needed the ability to make many changes to thier UI quickly. With the 2 week turnaround on app submissions, as well as the tendency for certain users to not update their apps, they could potentially be waiting years for the results of iterative A/B testing if they stuck with a purely native app. Now that they've had the opportunity to fully A/B test their app, and they have a good sense of what users find valuable (based on this news story, the news feed and photos), it makes sense to switch to a more performant native app.
jcromartie 14y ago
Based on a conversation with someone who worked on the UIWebView-based Facebook app, there were no real productivity gain either. The web app inside the native wrapper was an insane byzantine mess, as is often the case with this sort of app.
- MatthewPhillips 14y ago
  Did it different significantly from the mobile site? From the looks of it, it shouldn't be that complicated at all. 2 views in a carousel (sidebar and the main list). No transitions, no real attempt at being app like. Doesn't look like it should be that complicated to build.
  - dodecaphonic 14y ago
    It seems pretty straightforward on the surface, for sure. However, considering just how convoluted phonegap, weinre and friends can get, it's not hard to believe it turned into a mud ball.
mbesto 14y ago
Actually, I'd argue they optimized for Accessibility, which is arguably the most important aspect of any mass online experience.
JumpCrisscross 14y ago
The Fb web app was originally hailed as a triumph for web technologies, e.g. HTML5, which some believed was going to kill the app store model. Fb's web-centric (versus app-centric) employees would be susceptible to this view - they probably the move was viewed as being in the long-run best interest of the users. One can imagine an alternative outcome where competitive pressures forced Apple to upgrade its web application functionality to where the Fb app became not only competitive with native apps but, owing to its head start, shone as brightly as its first native app did in the app store. With the benefit of hindsight the move was biased by ideology. The takeaway should be pragmatism over ideology and intellectual aesthetics, not the super-prioritisation of UX. Note that around the same time, the Financial Times jumped off iOS and went pure HTML5. For them this turned out to be a good move - it is a delight to use.
evanlong 14y ago
You sir are genius for this line: "product quality for some notion of engineering perfectionism -- whatever it might be -- you're not doing your job as a professional engineer"

dclusin 14y ago

Another problem as well is people do not update their apps, which I suspect occupied quite a bit of discussion. I could see this becoming quite the headache when operating at the scale of facebook.

deleted 14y ago
[deleted]
why-el 14y ago
I wonder if the mobile space (asking out of complete ignorance) has an example similar to Chrome's automatic updates. But I guess given the amount of bandwidth that goes into regularly updating mobile apps, I am not sure people will opt for it.
- CodeCube 14y ago
  You can mark an app to auto-update on the google play store for Android. It's opt-in by the consumer
- jsnell 14y ago
  Android is now supposed to do updates with binary deltas rather than full reloads, which should help a lot with the bandwidth issue.
hdoan741 14y ago
Facebook may put announcement (or that sort) in their app to let people know that they should upgrade.

pdog 14y ago

It's more complicated than you make it out to be. Facebook has to work consistently on so many different platforms (not just iPhone, Android, Blackberry and Windows Phone; also, the billion+ feature phones out there) and continuous deployment is the process at the heart of Facebook (the motto: move fast, break things). Facebook is always adding new features and improvements. By using Web technologies, they can share code and make these changes on the server side, not to ease developers' efficiency but to guarantee interoperability and a consistent user experience.

flatline3 14y ago
> It's more complicated than you make it out to be. I didn't make it out to be simple or complicated. They valued their sense of developer efficiency over user experience.
- snowwrestler 14y ago
  No matter how efficient your developers are, it's gonna take longer to get a new version of a native app submitted, approved, and downloaded by users, than it is to simple deploy to a webserver. By going native, Facebook has greatly improved the user experience of this version of their app (which I applaud), but greatly slowed the speed at which they can iterate to the next version.
  - flatline3 14y ago
    User spend their time using the application, not waiting for an update. Sacrificing their user experience for rapid updates is putting a sense of engineering efficiency ahead of user experience.
    - smackfu 14y ago
      What if the update is a bug fix?
      - flatline3 14y ago

SoftwareMaven 14y ago

That assumes developer efficiency is what they were optimizing for. If, on the other hand, they were optimizing in a way that attempted to trivialize mobile to drive people to the (more profitable for them) desktop, then then entire experience makes sense from a product perspective.

jamesaguilar 14y ago
Or maybe a space alien told them that they must do it in HTML5, as long as we're trading in unlikely hypotheses.
flatline3 14y ago
I based my assessment on Facebook's public statements regarding their choice of technologies, rather than assuming some sort of deep conspiracy. It's basic organizational politics. Any organization will have difficulty adapting to a completely different platform, and management will attempt to reframe the problem to fit within the bounds of their existing organization. In this case, a traditionally web-focused organization attempted to co-opt mobile development into their existing organizational hierarchy by reframing the problem. It wasn't until persistent external pressure was applied (user complaint, blatant failure obvious to external management) that they were forced to accede ground.
- SoftwareMaven 14y ago
  I tried to put myself in the shoes of a product manager at FB, knowing that revenue from mobile sucks but everybody wants a mobile solution. How could I accomplish both? By not making a fuss when engineering builds what is obviously a substandard app. What I forgot to take into account is that Facebook isn't really led by product management. Could FB's PMs force a change like that, after development has built it? I don't know.

sidcool 14y ago

Can you pls explain the issue in more detail or mention a link?

xstm 14y ago
http://www.readwriteweb.com/archives/redux_how_facebook_mobile_was_designed_to_write_once_run.php http://www.readwriteweb.com/archives/redux_how_facebook_mobi...

tptacek 14y ago

Choosing platforms to optimize developer experience enables you to get more features out the door faster, which is usually the right decision when you don't know precisely which feature set the market is going to value. After a year or two of experience, it's a lot easier to go back and pick a different platform to optimize for something else.

flatline3 14y ago
Trade-offs to accommodate your resource or skill contraints are just that -- trade-offs. They're not optimal solutions for your users or your products. Singular dedication to user experience may have an intangible value, but Apple and others have consistently demonstrated that the value is high. This isn't a trade-off Facebook needed to make. Whether it's a trade-off your organization needs to make depends on your resource availability, skills, and target market. However, there's no value in dressing up the trade-off as anything other than a trade-off. The target market and product factors into the question of resource allocation. Nest would not have made such a splash if they decided to skip user experience and focus on fast feature roll-out, and Dropbox would not have succeeded to nearly the same degree (if at all) without first-rate native user experience.
- tptacek 14y ago
  I reject the idea that Nest and Dropbox were in similar positions as Facebook. The entire value proposition of Nest is simple (and simplicity). Same with Dropbox. It is harder to make a case for how Facebook could have had a "simple" value proposition 2 years ago. You're making a case for why Dropbox didn't have to go through the time-to-market-driven experimentation Facebook did. That is indeed an advantage to being Dropbox. It isn't a very good indictment of Facebook's strategy.
  - flatline3 14y ago
    Facebook started with a native client. They switched to HTML due to internal organizational politics. I'm not sure what you're arguing -- that somehow Facebook lacked the resources to invest in user experience and rapid mobile development from the beginning? It's not as if mobile was unproven at the time they decided to switch away from their native mobile client.

Androsynth 14y ago

This HN meme that all companies should be like Apple is getting a bit ridiculous. FB has always been an efficient engineering organizing that pushes out features constantly. They don't derive their value from their UI nor have they ever. There is no reason for them to start copying Apple now. FB users don't use it because of the slick interfaces, they use it because of network effects. For that type of business, adding features fast (to create more lock-in) > focusing on great UI.

shadesandcolour 14y ago
Who says Facebook needs to be like Apple? No one is arguing that Facebook needs to change or make their UI better than it was or that it was even a feature they cared about. The issue was the experience delivered by the client they had out, which sucked. They picked a technology which everyone knew would be slower in order to make it easier on their mobile team. Instead of investing in an Android team and an iOS team, they wanted to make the code portable. Sadly using a UIWebView comes with zero benefits on iOS and Facebook suffered for that. They should have kept their native client in the first place. The point of using a web view is so that you can rapidly prototype features and UI, and as far as I can remember, Facebook did very little of that on mobile anyways.
- peterhunt 14y ago
  The trendy idea that startups should stay in stealth mode until their UX is completely perfect is a very Apple-y idea which throws away many years of hard-earned knowledge about iterative development processes. Apple can do it since they make hardware and that people will buy whatever they put out, highly competitive web companies, not so much.
deleted 14y ago
[deleted]
flatline3 14y ago
> They don't derive their value from their UI nor have they ever. I'd be interested in your supporting arguments, especially in light of this investment they just made entirely for UX reasons.

mmahemoff 14y ago

They also made a bet on HTML5 closing the gap on native app platforms over time. But the bet turned out to be wrong as the gap has actually increased.

jamoes 14y ago

Using a UIWebView has benefits other than just developer efficiency. If Facebook wanted to run A/B tests in a serious capacity, they needed the ability to make many changes to thier UI quickly. With the 2 week turnaround on app submissions, as well as the tendency for certain users to not update their apps, they could potentially be waiting years for the results of iterative A/B testing if they stuck with a purely native app. Now that they've had the opportunity to fully A/B test their app, and they have a good sense of what users find valuable (based on this news story, the news feed and photos), it makes sense to switch to a more performant native app.

jcromartie 14y ago

Based on a conversation with someone who worked on the UIWebView-based Facebook app, there were no real productivity gain either. The web app inside the native wrapper was an insane byzantine mess, as is often the case with this sort of app.

MatthewPhillips 14y ago
Did it different significantly from the mobile site? From the looks of it, it shouldn't be that complicated at all. 2 views in a carousel (sidebar and the main list). No transitions, no real attempt at being app like. Doesn't look like it should be that complicated to build.
- dodecaphonic 14y ago
  It seems pretty straightforward on the surface, for sure. However, considering just how convoluted phonegap, weinre and friends can get, it's not hard to believe it turned into a mud ball.

mbesto 14y ago

Actually, I'd argue they optimized for Accessibility, which is arguably the most important aspect of any mass online experience.

JumpCrisscross 14y ago

The Fb web app was originally hailed as a triumph for web technologies, e.g. HTML5, which some believed was going to kill the app store model. Fb's web-centric (versus app-centric) employees would be susceptible to this view - they probably the move was viewed as being in the long-run best interest of the users. One can imagine an alternative outcome where competitive pressures forced Apple to upgrade its web application functionality to where the Fb app became not only competitive with native apps but, owing to its head start, shone as brightly as its first native app did in the app store. With the benefit of hindsight the move was biased by ideology. The takeaway should be pragmatism over ideology and intellectual aesthetics, not the super-prioritisation of UX. Note that around the same time, the Financial Times jumped off iOS and went pure HTML5. For them this turned out to be a good move - it is a delight to use.

evanlong 14y ago

You sir are genius for this line: "product quality for some notion of engineering perfectionism -- whatever it might be -- you're not doing your job as a professional engineer"