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.
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.
That is correct in theory, but falls on the face with facebook and others. Unless you literally just mean "more features", and not improving what they're making. E.g. paying for promoted updates so friends see them in their cluttered stream surely is Yet Another Feature, but is it good? I guess it depends on who the market is, here..
If the thing were written in spaghetti code, it would at least mean people would have some time to think in between, or even manage to get out of their 20s before their redefine how grandma keeps in touch.
Still, I'm happy that they improved how their crappy soulless product runs on another crappy soulless product, it keeps them off the street.
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.
I didn't make it out to be simple or complicated. They valued their sense of developer efficiency over user experience.
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.
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.
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.
I'd be interested in your supporting arguments, especially in light of this investment they just made entirely for UX reasons.
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.
http://www.netmarketshare.com/operating-system-market-share....
It definitely needs to be rewritten for Android.
At the same time, having watched my friends swear at Facebook on their smartphones and yet continue to use the app, day-in, day-out, maybe Facebook are more clever than I give them credit for; I haven't seen people move elsewhere because of the problems.
They are getting dragged into a better UX. They aren't pushing for it.
Some are just ugly for example ecards are all screwed up. Others could seriously piss some people off. Quicky scrolling through my feed I saw two imagines that were originally of a female friend standing somewhere, taken in portrait orientation. On the new feed they appear as zoomed in "body shots" with the head and below the knees cut off.
This sort of thing is especially odd given their face recognition on every photo. Surely they could have it center over the faces.
http://newsroom.fb.com/ImageLibrary/detail.aspx?MediaDetails...
Let this be a lesson to us all: when putting user experience as the first priority, the nirvana of writing your UI once in HTML and having it work universally still isn't there.
Are you sure? It's better, yes, but it's not a model of UX and on an iPad it seems not much thought was taken into making it a truly universal app. There's a lot of unused space and everything is too large.
The Google+ app with its combo of Path and Flipboard is a much better model to follow. Fast, and it takes advantage of the screen size in both versions.
I wouldn't go this far. Sure, the CoreData backend and table view controller implementation is beautiful and awesome. However, the root level navigation could be improved. The pseudo-popovers for messages, notifications, and friend requests is inconsistent with the rest of iOS, even though it might be consistent with past versions of the application and the versions of Facebook on other platforms.
And it will never be. HTML just sucks for application development.
Why on earth exchange the benefits of using the hardware resources properly for the mess that HTML+CSS+JavaScript is? To mess the customer's experience?
Don't be afraid of touching C, C++ or any other language with native code compilers and at most rewrite the UI part. Or shell out some money for tools like Mono or similar.
Although I am forced to code Web applications at work, I am a firm believer that web should only be used for communication protocols and documents as such.
Like you I write web apps, but I'm old enough/lucky enough to have had some other experiences, and to be quite honest I find even Gtk+ is more pleasant overall than the MV* framework of the month. That we have folks now trying to write AutoCAD or Photoshop in JavaScript just like a loss for our industry.
Some pages do load slightly quicker though, so good job on that. :)
Despite that, the Android FB app, and most other WebView-based apps on both platforms, tend (IMHO) to be rather dog-slow and buggy anyway. The App Store in iOS6 is one as well, and it shows.
They were appearing for me in the old iOS app & are only be shown every 150 or so (at the moment in the tests they are performing) which has been confirmed by Facebook's CFO David Ebersman who said Facebook are "being very careful about the volume of sponsored stories in the news feed because it’s so core to the user experience."
If the iOS app is more responsive, users tap on more ads, and Facebook makes more money.
(down at time of writing)
Some time after a terrible webapp was released. Not quite sure why someone else there couldn't take over maintenance of it.
[1] The application doesn't work well in landscape mode
[2] No feature to edit comments, this was existing as a feature in the previous app.
