Hacker News Reader

Comment by dominostars | Hacker News Reader

It's the iOS paradigm to make feature simple standalone apps. Why do you think Apple has both a "Photo Album" and "Camera" app? And both a "Phone" and "Contacts" app?

Many users upload photos to Facebook, so there's a huge incentive to make an app that makes it simple to do this. Even if the main Facebook app has feature parity with FBPhotos, it's still going to come with all of the cruft.

View on HN

This.

Two things people do that FB wants channeled through their systems: Photos & Chat.

Replacing your camera app with FBs means that all photos go to Facebook, which also represents the most important content on Facebook.

If your photos and your friends photos are all on FB then they go to FB.

If everyone you know is on FB then you'll probably use FB to talk to them. Thus, the chat ecosystem. Because FB is device and OS agnostic, it works even better than what Apple is trying to do with iMessage.

So why separate apps? Because people today already do these things as separate apps. You take a photo with your camera and then upload to FB. Now you just take a photo. This is actually what Google does with G+ and its automatic photo uploads. But FB can't do that, because they don't own the device ecosystem so this is their technique...for now.

Plus it's pretty seamless replacement. Same label "Camera". Same icon, just with a blue background instead of grey.

Smart move. Didn't realize it at first :)

I noticed that when changing the location settings in "Settings". The default Camera app was listed immediately next to Facebook Camera, confused me for a moment.

I wonder if Apple will make them add "Facebook" to the app name to avoid confusion, since it's the exact same name currently.

TBH, I'm kind of surprised Apple is totally cool with this since one of the AppStore guidelines is to not create apps that replicate core iOS features. Now I know that Facebook's Camera app does more than take photos, but they are a direct replacement for the Camera and Photos apps that are native to iOS. Making the name and icon so very similar is close enough to be construed as an obvious intent to confuse/mislead.

Friends uploading all of their photos to Facebook,

Pros: -Pictures of their girlfriends naked

Cons: -A complete lack of relevance and editorial purview.

Every photo a user uploads to Facebook sends a message about who that person is. Out of about 300 photos I take on my iPhone, 1 makes it to Facebook. I have a few friends that upload lots of crap. For the most part, those friends had their feeds blocked by me fairly quick. These are not interchangeable events.

Facebook's biggest threat is a loss of meaning through noise, not users using an alternative app to capture their media.

As for Facebook Messenger, I'll be damned if I let Facebook permanently record every last one of my private message for eternity.

"Facebook's biggest threat is a loss of meaning through noise, not users using an alternative app to capture their media."

This is true of any data aggregator and visualizer. I'd argue they, probably next to Twitter, are the best at attempting to handle it within a social context.

I guess my thought about photos is incomplete in that making FB a storage for media means that your mean average of shared media will go up as well (it's already there, might as well). We see this in bulk uploads.

I agree that there is a certain amount of selectivity involved - but we vary as individuals. I think only in the last couple of years, after the fad of being able to toss everything online in heaps - have we begun to understood how our online perception is made.

"As for Facebook Messenger, I'll be damned if I let Facebook permanently record every last one of my private message for eternity."

Agreed. That's why I'm off it.

It's somewhat in following with the Unix paradigm; do one thing, do it well.

Not always. Regarding core Unix commands yes (like 'ls', 'cat') but look for example at 'git' which is a real beast.

git is just a facade for the git-* commands.

Not to veer too far from the main discussion, but 'git' isn't just some giant monolithic binary. The 'git' command is a wrapper around a bunch of different, relatively modular binaries. They each even have their own man page. (e.g. 'git push' maps to 'git-push'). Each is just a unique action that can be applied to a common data structure (the git repository).

I know. And still all these different libs are accessible by one UI/route ('git').

Do an ls /usr/libexec/git-core/ (or your operating system's equivalent) some time. The fact that the porcelain exists does not mean that the plumbing does not.

Look closer at git, and you'll see that it's actually a collection of smaller programs (each of the git commands is made as a separate executable before being combined into git)

So when can we do $ camera | fb-photo | facebook | sed 4 | awk ?

Chaining the utilities is the crux of the Unix paradigm, remove that and you're left with individual utilities that are far less powerful than when chained together.

Which is why I said "somewhat". However, you can upload a picture from one app and interact with it in another, so that's... something I guess.

Now. With android intents (ok, not cool as pipes, but the idea is there)

You can do it on iOS as well. You can go from the facebook camera app to the main fb app. (Any app can do this, but the point of the article is fb so i used them as the example)

Is the link between the two apps hardcoded on iOS?

On Android you can have any camera app | any photo editing/filters app | any social network upload where each app is chosen by the user which seems closer to the idea of pipes to me.

Yeah it's something that Facebook would hardcode. Click on this person and instead of doing something here it sends you to that person's profile on their other app.

It isn't like intents on Android, but from the perspective of Facebook it is probably preferable. They don't want you to go to your choice of photo or social network or chat app, they want you to go to their app.

This is a great example; it almost works like UNIX pipes except that each application has to take an explicit action to share its result with the next application in the pipeline. But like UNIX apps that do something anti-social like rewrite the input file (hello, GNU Recode), that can be worked around.

For those of you that don't use Android, the process works like this. You take a picture. The camera app provides a "share" button. You click "share". Then you're presented with a list of all applications that handle photos. So you can share to G+, or email a photo, or run it through filters, or whatever. The camera application never needs to know about the filter application (the reverse is also true). This makes it very easy to reuse code and for users to design their own workflows. Platforms don't really like this, since they don't have total control over the user experience, but for us users, it's pretty darn nice.

(You can also register URL handlers, so that something like clicking a link to Google Maps in your email automatically opens up the Google Maps app to the same state. Again, pretty useful.)

in fb camera, if you see someone is tagged, and you tap their name, it switches to the main fb app and shows their profile there. The notion of doing one thing well seems to be preserved.

It's somewhat possible though not very widely used.

Basically, any iOS app can register a URL scheme and be opened with that scheme and anything after that by another app. This is used for example by Camera+: http://api.camerapl.us/app-api

With their API, another app can launch Camera+ to edit a photo and Camera+ sends the user back to the original app with the data of the edited photo.

Facebook uses it for single-sign-on of third-party app. (i.e. user taps "sign in with Facebook", the Facebook app is launched, the user taps "Accepts" and is redirected towards the original app)

One big limitation of this mechanism is that it's very much ad-hoc.

Another existing mechanism is the one where apps can register themselves as being able to handle a certain type of documents. You can then open a document from another app.

"Why do you think Apple has both a "Photo Album" and "Camera" app? And both a "Phone" and "Contacts" app?"

I'd say that in any case, they had to have Contacts and Photo Album apps for the iPod Touch and iPad.

Why also include them on the iPhone? Well, Photo Album has more features than the Camera app (access to Events, Faces…) so it might be simpler to have one codebase for a Photo Album app shared with iPod Touch and iPad, rather than trying to put all the features of Photo Album in the Camera app. For me, it's better too because it makes the Camera app more easily replaceable. (as seen with the OP)

For the Contacts app, I'm not entirely sure since it seems to be a clear subset of the Phone app.

but what's weird is that the Facebook app also does both of these things already, just not quite as well. It's especially weird with Messenger because I think both apps can get push notifications.

We call the unix paradigm now the iOS paradigm?

The Unix paradigm is more about even smaller composable tools.

Reply on news.ycombinator.com