Is it possible that Facebook Home has fallen flat on Android because it was designed by iPhone users? That’s certainly possible. But more likely, it seems to me, is that Facebook Home is just a bad idea. As I said last week, it’s a well-designed implementation of an idea no one wants.
-
-
For a developer, doing beta releases on iOS can be a real pain sometimes. […]
iOS 4.0 brings Web-based, wireless distribution of ad-hoc apps … Your beta users can now install the software without ever using iTunes at all!
The only problem is that it’s not really documented, at least not in an end-to-end manner. […]
Enter ‘iOS BetaBuilder’ – a simple MacOS X app takes your archived IPA file and creates the required manifest and HTML files for wireless distribution.
— Introducing iOS Beta Builder (August, 2010)
-
Facebook’s iPhone and Android apps were hybrids: They packaged the nascent mobile-web language inside Apple- and Android-specific programming. The problem was that apps built explicitly for iOS and Android were much handsomer and cooler than Facebook’s hybrids. […]
Ondrejka and some colleagues also added discipline to the production cycle for mobile products. On the web making updates and rolling back mistakes is easy and fast, and as a result engineers were encouraged to take chances and move quickly. Mobile platforms work very differently. For one, Apple and Google, as operating system owners, vet changes to apps, which can take time. Consumers also need to remember to update their apps, and that can be an infrequent occurrence. If a developer makes a mistake, it takes a lot longer to fix. Rather than a few minutes, a Facebook user may live with that error for a few weeks.
-
Marco helped the Home team understand the expectations people might have for the product and identify potential interaction issues. He collected and analyzed feedback through interviews, diary studies, surveys and discussion groups. […]
Anything that changes the deep relationship people have with their device is really challenging to design for. You can’t predict what people will expect and how they’ll react.” […]
“We acted quickly and used quite a few different research methods and approaches to mitigate not only the fact that the phone is so personal, but also that we wanted to cover different contexts and situations of use. Doing this also allowed us to gather data and feedback at different paces, and to have a solid sense of patterns of behavior from an early stage.”
-
“Pushing” a piece of new code live to the desktop and mobile Web is a much faster process than making changes to a native iOS or Android application. …
Previously, Facebook split dealing with these problems in two. Desktop coders were part of one group, while the mobile apps teams were separate. In fact, as product manager Dirk Stoop told me, the native iOS and Android apps were so small in the early days, only a handful of people were responsible for maintaining the iOS and Android applications — two of the most-downloaded apps in the entire world.
…
The Facebook product structure of today looks very different than it did before. Teams are separated across the company by product rather than platform.
So, for example, the Facebook Messenger group, led by Facebook veteran Peter Deng, is one team composed of desktop, mobile and native engineers who create features for every place that this product appears. This is the same for Photos, the team which Stoop leads.
— “Own Your Code”: Facebook’s Engineering Shift Tackles the Problem of Mobile
-
distribution is much harder on mobile than web and we see a lot of mobile first startups getting stuck in the transition from successful product to large user base. strong product market fit is no longer enough to get to a large user base. you need to master the “download app, use app, keep using app, put it on your home screen” flow and that is a hard one to master.
-
You want to squash all your bugs and deal with the major design issues before you try to get your big launch spike. Otherwise, you might get a spike plagued with bugs and 2 star reviews – not good.
I got a couple great comments about how to do this, by stealthily releasing and rebranding. Matt Brezina’s genius comment below:
One thing we did was launch 2-3 versions of our product under a different apple account, without our personal names on the app, before we launched Postagram. When we did a PR launch the product was basically just a branded version of our work from the past 4 months; we knew it would function well and we knew users would love it. Since then we’ve never spent more than 4 weeks developing a release. And we particularly use Android for quick experiments – the apple 1 week app approval delay can really slow down the iteration cycles
-
Updating an app — while easy for most people — can be more disruptive than reloading a webpage. Because of this, we also wanted to balance getting improvements out to people quickly while minimizing disruptions for users. Our 4-8 week release timelines feel like a good trade-off for now.
-
We wanted to know which pieces of information about an app users most commonly employed to make a decision about installing an app regardless of the App Store used. The three most frequently reported items were:
- Rating
- Screenshot
- Review
-
While Facebook for iOS is much faster than it was before, the speed comes with one compromise: the company can no longer roll out daily updates
-
We came up with a different plan to let you use the newest features without requiring you to update the entire app: a “fallback” renderer. When the news feed team designs a new type of story, Facebook for iOS downloads something it doesn’t quite understand. When we detect this, we use a “fallback” renderer to show the pertinent information in the new story in a format the app already understands. In the meantime, we create a new custom renderer and have it ready for our next app update. For areas within the app where we anticipate making changes more often, we will continue to utilize HTML5 code, as we can push updates server side without requiring people to download a new version of the app.
-
Mobile engineering and Design had about nine weeks to design, prototype, develop, test, and calibrate mobile.twitter.com for launch.
-
Easiest way to capture real user interaction on your apps
Delight enlightens developers and designers on how their users interact with their iOS applications. We seamlessly record your application screen and automatically capture all gestures. These recordings are then uploaded in the background to our server for viewing and sharing. -
Mobile does not reward feature richness. It rewards small, application specific, feature light services. I have said this before but I will say it again. The phone is the equivalent of the web application and the mobile apps you have on your home screen(s) are the features.
That is why Facebook should (and it looks like will) break its big monolithic web app into a bunch of small mobile apps. Messenger, Instagram (not yet owned by Facebook), and Camera are the model for Facebook on mobile.
-
You need to be super intentional about putting anything on screen when the screen is the size of a credit card.
