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.
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.
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.
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.
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.
If it's so easy for Facebook to get a good mobile client out, why didn't they update the (much loathed) iOS client months and months ago? My suggested answer: it isn't in fact easy for them to do that. So time to market is an issue for them.
User experience is the not the only governing factor in software development. As the John Carmack post on HN front page says, software engineering is a social activity, which as you can imagine has more than one goal factor influencing it. I don't know what politics went on in this decision, but choosing a HTML/JS platform on mobile phones on definitely has its technical advantages. Though it doesn't apply to Facebook, a financial advantage would be to save money on hiring iOS experts/programmers.
As you noted, the financial advantage does not apply to Facebook. Contrarily, there's a financial advantage to shipping a better product, if you can afford to do so.
I'm interested in your supporting argument for other governing factors or software as a social activity, and how that relates to making engineering choices that sacrifice product quality for some notion of engineering perfectionism.
No, he isn't. Another way that a UIWebView can provide a super experience to custom NSViews is if the UIWebViews implement more of Facebook's functionality than the custom views, or if the features the UIWebView expose match the ones users want better.
- Facebook fails to deliver features through the superior approach ...
- ... but does deliver them through a lesser approach ...
.. then the mechanism they use to deliver the features provides a better user experience, because it has the features, thus justifying the choice to deliver them in the through a subpar mechanism?
That's ... circular. Painfully so.
It would be better for the user experience if they delivered features with the highest level of quality they're capable of providing, and that's demonstrably not inside of a UIWebView.
> They switched to HTML due to internal organizational politics.
Sorry, but how do you know this? Also, politics in of itself is rarely the real reason why decisions are made. Someone who seeks to gain benefit by making decision (which is deemed therefore political) can certainly be a reason. So, I'd be curious as to what benefit some individual or individuals sought to gain by making this decision.
It's not difficult to determine who in a web-centric engineering organization would benefit from promoting web-centric ideas in favor of alternatives, thus spurning engineering choices that would fall outside their area of responsibility or skill.
I'm not sure if you're being obtuse; this is basic organizational politics.
Pretend that Facebook's hitherto web-centric engineering team is external to Facebook -- they're a consultancy. Now imagine Facebook comes to them and says: We want a mobile application. Who benefits if they manage to convince Facebook to pay for them to produce a web application?
Let's reel it back to reality. How do people inside an organization benefit if they expand their area of purview, responsibility, and increase their value to the organization? Likewise, what power dynamics come into play when a new, potentially distinct engineering team garners additional purview, responsibility, outside of your domain, skills, or control?
There's no value in dressing down trade-offs as being anything but ubiquitous, either. Supply chain and operational concerns constrained and changed how Apple products turn out, too.
"a year or two" - that's quite a long time to be testing something. Also I'm not sure how much of a time to market advantage they gained from using UIWebView, if any. There's simply no evidence to support it. Everything points to internal politics.
"Choosing platforms to optimize developer experience enables you to get more features out the door faster"
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.
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.
Consider a UI update that is, provably, an improvement to the user experience. Delaying that update by 3 weeks (due to the App Store process) is itself a form of sacrificing the user experience.
Or more likely, consider an example where Facebook is not sure which of 3 UI changes would most improve the user experience, and they want to serve each of the 3 to small subsets to collect test data. Native UI rendering takes away this ability, potentially reducing Facebook's ability to improve the user experience--also a form of sacrifice.
Now maybe you believe that the poor performance of the HTML5 UI was an even greater sacrifice than these, and thus the switch to the native UI is a net improvement in user experience. I happen to agree with that, but that doesn't mean there aren't tradeoffs.
Performance issues aside, the user experience of the Facebook mobile app is miles better now than it was when they last rendered the iOS UI natively. A big reason for that is the speed at which they iterate changes in the HTML5 UI.
Edit to add TL;DR: There is more to optimizing the user experience than maximizing UI performance.
Given the reaction to any small UI update Facebook has rolled out since people began using the site has be pretty bad, maybe it's better that it takes more time to roll the changes out.
The reaction to any small UI update, anywhere, is pretty bad. People hate change (or more specifically, they hate having change forced upon them). The reaction to rolling back the changes after they've been out several months is usually equally bad.
I just want to correct a factual error in your post. I've noticed that the review process time used in a variety of responses continues to creep upwards -- here, it's up to three weeks.
As it currently stands, as per Apple's published status, 95% of applications are approved within 8 days.
After Apple publishes a new version of your app, your users must notice the update and choose download it--my guesstimation includes that. If you'd prefer to use 8 days, that is still a lot longer than the next HTTP request, which is how long it takes users to get a new version of a web app.
If you look into their tech blog post about the update, they use HTML5 as a fallback render for new stuff. They then create the native renderer for the widget and push it with the new update a few weeks/months later. So they can still A/B test as quickly as they want.
I don't think that they said that their fallback renderer was HTML5, but they did say that there were still areas of the app that still used that technology.
That still isn't where the vast majority of user time is spent.
If the goal is putting user experience first, and you're concerned about critical bugs, then expend the engineering effort required to reduce the risk of rolling out a bug.
Related aside; Apple can roll out an emergency fix in an hour or two.
I think you're missing the point. How long does it take for that fix to be downloaded? Tons of users will never see it. Tons of users will continue to use the version with the vulnerability.
"They valued their sense of developer efficiency over user experience"
No, they made a judgement that user experience would ultimately be better from being able to deploy rapid changes via a consistent cross platform experience under their control vs writing OS specific code and placing themselves under the control of a third party and that will significantly operationally limit them ("Can we roll out the new user profile yet? No, we're still waiting on Apple to approve the change ...").
They may have been wrong, but it doesn't change their original intent. If anything we should all be lamenting the failure of HTML5 as a truly viable app replacement at this point; I can't blame Facebook for wanting to believe it would be possible.
I'm curious as to whether you think users want, need, benefit, or care about whether Facebook can deploy rapid changes via a "consistent cross platform experience".
In my experience, users want a consistent platform experience -- one that fits in with the platform that they're using. They're also not interested in your development processes, especially if it means rapid dispatch of potentially breaking changes. In fact, I'd say that runs counter to user's interests.
Engineers and product managers seem to be the primary cheerleaders of "consistent cross platform experience". I don't see why a user would want that. I do see why developers and product managers would want that.
> If anything we should all be lamenting the failure of HTML5 as a truly viable app replacement at this point; I can't blame Facebook for wanting to believe it would be possible.
I'm not lamenting HTML5 as a viable application platform replacement, because it never was going to be one. The web industry consistently ignores 30+ years of experience that the desktop (and now mobile) development industries have in bringing high quality applications to user's devices. The web universe eschews common platform conventions, common rendering approaches, common widget libraries, and instead has attempted to force everyone to individually reinvent application development on top of DOM, CSS, and JavaScript -- a SGML-derived history-laden mess that served documents well and applications poorly.
The lesson for the web industry should be that they need to figure out how to bring align whatever ethos they have -- presumably of a common, open platform -- and bring them to bear on implementing something genuinely competitive with the native development platforms.
> I'm curious as to whether you think users want, need, benefit, or care about whether Facebook can deploy rapid changes via a "consistent cross platform experience".
It's not about me; your statement was about what Facebook's values were (valuing their own expediency over their users). I just don't think your statement about their values was fair, especially in the light of history (do you remember Steve Jobs walking out on stage and telling everybody how the iPhone didn't need apps because the browser was so awesome?).
> In my experience, users want a consistent platform experience -- one that fits in with the platform that they're using
Well we're not that far apart then. You consider iOS the platform, I consider Facebook the platform. You can hardly blame Facebook for considering Facebook to be the platform.
I general I don't think there's a single answer to this. If lots of new features delivered rapidly are what your users need then it seems obvious that only writing code once and delivering it to lots of platforms can get them those features fast. If features are slowing and quality of experience is more important then native code is a better option. I'd posit that Facebook is actually transitioning from it's rapid-development-new-feature phase into a more mature, stable platform where quality of experience is more important, and this transition is just natural and even optimal for them rather than the kind of "mistake corrected" that people are making it out to be.
Give me a freaking break, please. Tell me where the Android 100% native app is? Oh, it doesn't exist yet? In my book, not existing is the worst kind of user experience. There are concessions to be made when going full native just like they are when going hybrid. In this case, it's speed of development.
I didn't make it out to be simple or complicated. They simply valued their sense of efficiency over user experience.
There's not much room for "simply" when you're talking about a service that has to work across dozens of OS/browser variants, is practically a utility to its (hundreds of millions of) users, and receives multiple daily updates. This isn't an upstart web service that can optimize around a platform that might be only a fraction of their potential user base either.
Since mobile is their biggest growth platform and considering that they have the resources, I just don't see this as a strong argument. I always thought it was very silly that the website ran better and faster in Safari vs the "native" app.
That's not Facebook's fault its Apple's. iOS's UIWebView uses an older version of webkit and a much older version of there javascript engine. Apple doesn't want you building web apps they can't monetize.
I don't know if you're an iOS developer, but that's plain mis-information.
The reason native apps use a different flavour of WebKit to Safari is because the latter operates in a privileged security mode, whereas the former are all sandboxed. Mobile Safari uses a JIT compiler, but this introduces the possibility for remote code execution.
It's not that Apple 'doesn't want you building web apps they can't monetize' - it's that JIT compilation of JavaScript doesn't sit well with the current iOS security model.
People seem to easily forget that Mobile Web was originally the only way to get apps onto the iPhone. A number of Apple's own apps (the App Store, for example) are HTML based rather than ObjC based.
"It's not that Apple 'doesn't want you building web apps they can't monetize'"
That's simply not true.
1) A year ago Apple rejected one of our app updates because a webview inside the app had a payment form. (They told us that they do not allow any other payment option other than Apple in app purchases)
2) Yesterday they rejected yet another update for our app because it had a form where users could enter bonus codes.
Their explanation: We don't know if you are not selling those bonuscodes to your customers somewhere else on the web. (We don't, thats just bonus codes from promotion agreements with blogs/newspapers etc)
Of everything that irks me about the app store (and I say this as someone who uses almost exclusively Apple computers / mobile devices), this is pretty high up there. It makes it damn near impossible to run a successful marketplace businesses on iOS: if your business is based on skimming a percentage fee off the top of your user's transactions, Apple taking 30% is more often than not a dealbreaker.
That being said, that's not an issue of native apps vs. web apps. If you want your application distributed through the app store, anything payment-related (or even potentially payment-related) needs to go through Apple's payment services. Period. Apple would complain just as much if you had a native app that had your own payment form, and they'd be 100% fine if you built a pure webapp (i.e. not on the app store) that accepted non-Apple payment.
> because a webview inside the app had a payment form
You didn't get rejected because it was inside a webview. You got rejected because you were selling something outside of In-App Purchases. You know this.
That's insane, I just had the same 2) rejection and spent literally weeks thinking that I wasn't able to properly explain what the codes where for, because it didn't make any sense for them to reject that. But since you've had the same issue, i guess they really start to be seriously deranged.
That issue is not as simple as you make it out to be. Just in time compilation of Javascript requires an app to have permission to execute code that is generated as data on the fly. Applications with this permission are vulnerable to exploits.
The standard UIWebView available to applications doesn't include just-in-time compilation because 3rd party applications don't have this permission. This is the biggest reason why its Javascript engine is slower than the one built into Safari.
Apple doesn't want you building apps that open up exploit vectors into iOS.
If it really is an engineering challenge it needs to be fixed. We're going on 2 years of Mobile Safari having JIT and UIWebView not having it. They can simply make an exception for UIWebViews without making an exception for the rest of the app. I don't know their codebase and it might be really really hard to fix, but I hope it isn't something they've given up on. It cannot continue in perpetuity, as the web cannot continue to evolve if the makers of one of the most popular browsers have given up on speed improvements.
No they can't: part of a process cannot create executable memory while another part cannot. They'd have to move WebKit completely out of process: a huge task as it already does most text drawing.
An interesting alternative would be to enhance the current 'Save to Home Page' feature beyond specifying a manifest of resources and a home page icon. If this was fattened up to allow developers to make something that looked even more like an app but was running Safari (not a UIWebkitView inside a native app), you might have something interesting.
No, but web pages (including apps that are installed to the home screen and run full screen) run inside the MobileSafari process, which is much more carefully audited than your typical iOS app.
Audited how? Unless MobileSafari is itself tightly sandboxed, I don't see how auditing the code inside it is useful. Once you get malicious executable code inside MobileSafari, it can do whatever MobileSafari can do.
I doubt they're trying to audit behaviour, you can always write an app in Lua with an interpreter and they would have a hard time "auditing" the app statically.
The propblem is that if you allow executable memory you open aup a lot of exploit vectors. Now, that's true of Mobile Safari as well, but they trust their own team more than they trust you, and they have one app to watch instead of 100,000, and if an exploit os found they can push out a fix immediately, whereas 3rd party apps have a tortuous process for pushing out bug fixes.
Remember, it's part of their value proposition that apps from the app store appear to be relatively safe in comparison to the clusterfuck that is downloading random desktop apps, especially on Windows.
Can you give an example of an exploit that would do harm from within a UIWebView but would not do harm from within Mobile Safari? Not questioning you, I'm genuinely interested.
Given the current architecture, if UIWebkitView within an application can execute data, then the entire application can execute data.
So you could have a buffer overrun anywhere in the app. For example, if they are silly, you could go to the preferences for Facebook and enter a very, very, very long user name, overrun the name buffer, and have executable code.
That's not an exploit of UIWebkitView, it's an exploit of giving the application the permission it needs to have UIWebkitView use a JIT compiler for JS.
This seems like a silly argument. You can release a free app in the iOS app store with a UIWebView or as a native app. It seems like Apple is optimizing for safety (a sandboxed version of the web view) and encouraging app performance. I don't see any monetization strategy at the heart of this (since Apple's cut of a free app is still 0).
> Apple doesn't want you building web apps they can't monetize.
This doesn't even make sense. You have it backwards.
If you run a web app in Safari, or save it as a web app in the home screen, it's going to run full-speed. If you wrap it in a UIWebView and sell it in the App Store (hello monetization) it's going to be slower.
And that is somehow a valid justification for writing an inadequate "native" app? Why would you choose to do it this way then if the platform you are targeting is 1) important and 2) doesn't have good support for whatever technology you are using?!?!
This is equivalent to being hired by a bank to re-write an entire enterprise timesheet app and then I decide on using Websockets and WebGL. Of course I will blame the fact that the app doesn't work on any of the internal bank computers because "they run crappy IE8 and nobody should be running it anyway". Nevermind that 50% of the bank's computers have those constraints.
Sometimes, you have to face reality and write the best application that you can considering the current constraints that you presently have.
If UIWebView is the cause, how come the Android Facebook app is also really slow? And to be honest, even surfing to mobile.facebook.com in Mobile Safari the app was really slow.
You know it takes talent to write a statement that is so completely wrong.
Others have addressed the JS point but Apple originally wanted developers to only build web apps and it took a lot of convincing to get them to change their mind. Also Apple has a lot of free apps. So this idea that Apple is somehow obsessed with monetizing apps is simply not true.
Not really... if you write an app that's native, then in-app purchases are controlled by Apple and they get a 30% cut of those sales. If you build an app using UIWebView then you could by pass those in-app purchases and get 100% of the sale.
1) A year ago Apple rejected one of our app updates because a webview inside the app had a payment form. (They told us that they do not allow any other payment option other than Apple in app purchases)
2) Yesterday they rejected yet another update for our app because it had a form where users could enter bonus codes.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
They originally invested in the webview interface. In light of that investment, doesnt that mean its a good idea?
No, of course not. What they invest in is irrelevant. Only results matter.
Just look at Mootothemax's comment further down the thread. Poor UI wasn't causing people to not use FB.
Valley execs are probably the most susceptible group to falling in line with the echo chamber. Currently the chamber is reverberating with 'APPLE GOOD!'.
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.
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.
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.
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"
Just updated - it's quite noticeably faster, and feels much more native than their previous shortcut of lots of UIWebViews. I commend the Facebook iOS team! This app has regained its throne as the model of iOS UX.
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.
> This app has regained its throne as the model of iOS UX.
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.
> 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.
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.
I love the energy itself that people are putting into making the web more of an app development platform. It's commendable how strongly and energetically they push to get there, building cool demos and frameworks that on a relative scale (i.e. from the web of ten years ago to the web of today) seem magical. But, frankly, more and more I feel like you, and more and more all that effort seems wasted on bringing everything up to par with old desktop patterns and techniques when we could all instead push everything somewhere new.
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.
It has constantly amazed me that Facebook's mobile app experiences are so, so poor.
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.
I don't use Facebook because it's got a superior UX, I use it because it's the only site where I can videochat with my girlfriend, catch up with my middle school math teacher, and view pictures of my grandparents' anniversary at the same time.
The cost of this demand type is attention. People will keep paying attention because they are invested personally (or they believe other people are invested personally and they want access to the peoplemarket).
You can measure the elasticity by adding anything detracting from user experience (i.e. wasting your user's time when you could automate solutions (e.g. cragislist spam apartment listings you spend 20 hours sorting through manually) or speed up your site (e.g. social website slowness/downtime/high variance in page load times)). You've found some elastic jumps when users start leaving because you're wasting more and more of their time.
People only have so many minutes of focusable attention every day. It's precious and irreplaceable. Don't waste your user's limiting waking attention with errors, manual aggregations, confusions, slowness, or "oops this failed try again and it may work or it may not work and you'll have to try again and it still won't work."
It's not very "creative", but the site is pretty awful on an iPhone. You have to zoom in an order of magnitude to be able to click up/downvote, and the layout doesn't shrink to fit the smaller screen at all.
Facebook doesn't want to optimize the mobile experience. They make far less money from mobile users. Their ideal world would be that people can get their immediate fix on their phone, but for most interactions, they head to their desktop.
They are getting dragged into a better UX. They aren't pushing for it.
I've found the Facebook app on my GNex is faster than it was on my iPhone 4, but that might be chalked up to phone speed differences rather than the Android app actually being better.
Android WebViews still get to use full-on V8 (where the equivalent Nitro on iOS is limited outside Safari); which likely helps web-based apps on Android.
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.
The "photos-overflow-outside-the-white-card-theyre-on" effect has always bugged me. It looks like a rendering defect or something. I get that they're trying to maximize screen real estate, but I think it just looks terrible.
The worst part is the way it chooses to resize/stretch images.
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.
> 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.
It's an extraordinary improvement. Does anyone know if it was written in native Objective-C or if this is a very optimized HTML5 version (or hybrid, like the LinkedIn app)
Yes, the app is faster. Engineering backpedaled and rewrote the app to become fully native again. Speed should be a top requirement for mobile apps http://news.ycombinator.com/item?id=4424212
Has anyone there found info about what libraries Facebook has embedded into this app? For example, if you go to Privacy and Legal in the Camera • app, you get a nice list of every open-source project they embed. I can't find it in this new FB app...
I vaguely remember when Facebook previously had a nice native iOS app long ago and their main or only iOS dev ranted about the App store and refused to do any more iOS development.
Some time after a terrible webapp was released. Not quite sure why someone else there couldn't take over maintenance of it.
Facebook app lost 100% of their iOS dev team when joe hewitt stopped developing for them. They decided to let interns in charge of native libraries like Three20 (which has become a mess since then) and let web people in charge. It took them to hire someone from Apple to get their things together and do something valid on that platform.
What's crazy is that nobody around them was able to tell them that mobile constraints makes it a entirely different think than the web. You just need to code one "hello world" with one button using phonegap to realize that uiwebview isn't anywhere close to native sdk.
On the other side,the fact that Apple decided not to update UIWebView to nitro was probably a big matter for them...
Did they added monetization strategies into this app (ads, sponsored stories, etc)? I'm not an iOS user, but after their harsh stock decline I would've expected to see aggressive monetization on the mobile app/web.
Facebook are making currently making $183M a year off mobile & they haven't rolled them out worldwide yet either.
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."
Just tried, very good! A big step forward.
I hope they'll go the extra mile and release a full featured desktop client as well, starting with osx possibly.
Even though Facebook for Android may have higher monthly active users, the iOS user base from a marketing perspective is a more attractive demographic to target nascent mobile revenue opportunities at. Soccer moms almost exclusively use iPhones.
This again? Really? The main improvement in this version is that it was rewritten for iOS, it didn't need to be rewritten for Android. Whether or not you have more marketshare doesn't mean you need an update for a platform you're not on.
Android has the market share, iOS has the usage share. Lots of people get android phones who have no desire to use it as a smartphone, they just get a free phone that happens to be android. iPhone users actually use their iPhones for Facebook and web browsing and other smartphone tasks.
I tried the new app on the iPad 1 and personally I still prefer the web page - it still feels smoother for scrolling. Another thing I don't like in the app is the chat list on the right that is always visible even if I'm offline. Is it better on the newer iPads?
Well if something, it would make you fall back to check Facebook on its full browser version, forcing you to see ads, which would be a good move for them.
Probably because the users expect better on iOS. They certainly complained louder. Also, my guess is the iOS user base might be higher value - as in they click on more ads and the iOS app brings in more money.
If the iOS app is more responsive, users tap on more ads, and Facebook makes more money.
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.