[OSKFacebookPostContentItem] More options for a Facebook Share.

[calimarkus]

A Facebook Share should be able to have a link (which will result in a link box attached below the status on Facebook).

Also posts on Facebook support a lot more meta data.. that should be reflected in Overshare. I would recommend a type called OSKFacebookPostContentItem which has all specific Facebook parameters.

[justin]

Patches welcome.

[jaredsinclair]

I like that idea. Facebook stuff should be it's own everything. There's already too much Facebook-specific code mixed into the microblogging APIs, e.g., separate read/write permission requests.

[berg]

I started working on this, because I ran into an issue where our shares weren't creating Open Graph stories on Facebook — but I had put that effort towards hacking it into the microblogging API, as opposed to elevating it to a new content item. You can see that stuff here: https://github.com/berg/overshare-kit/tree/microblog-url

Truthfully, of all of the additional options that Facebook supports, "link" is the most interesting/important one. I think that support for the other options, e.g., tagging, place selection, Open Graph tag overrides, etc., fits best outside the scope of OSK, because it requires significant additional UI.

We manually append a "— shorturl.example.com" to the end of the message we share with the microblog content, even when sending to Twitter, App.net, etc., but that functionality might be usefully encapsulated into OSK instead. I think you'd be able to render a nice-looking text post on Facebook, Twitter, and App.net with just "message" and "url" parameters.

[fjcaetano]

I was only able to share a link, but "smart links" (where they fetch pictures, title, etc) are processed by Facebook clients. In order to share content, not only link, this content must be created by the app.

What I'm unable to understand is why OvershareKit is not using Facebook (and Twitter) native SDK.

I need this ASAP, so I'll work on it in my fork and later ask for a pull-request. Is it okay for you guys?

[jaredsinclair]

You’re welcome to submit pull requests, sure. I can’t promise that we’ll merge the request, though. We’ll happily take a look once it’s submitted.

Jared Sinclair Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Wednesday, January 22, 2014 at 9:05 AM, Flávio Caetano wrote:

I was only able to share a link, but "smart links" (where they fetch pictures, title, etc) are processed by Facebook clients. In order to share content, not only link, this content must be created by the app. What I'm unable to understand is why OvershareKit is not using Facebook (and Twitter) native SDK. I need this ASAP, so I'll work on it in my fork and later ask for a pull-request. Is it okay for you guys?

— Reply to this email directly or view it on GitHub (https://github.com/overshare/overshare-kit/issues/10#issuecomment-33024786).

[fjcaetano]

So, this is the resume of the day:

First, I tried using Apple Social.framework for both Twitter and Facebook. It turns out that the view that is popped when trying to share some content is hideous and doesn't show "smart links" for Facebook.

So I integrated Facebook's iOS SDK, that requires that the Facebook App ID is registered in the Info.plist (there's an assert just to be sure)

I'll test some more and when I'm satisfied I'll update the documentation and ask for the pull request.

If you guys want to test it first hand, clone my company's fork: https://github.com/ideaismobile/overshare-kit

[fjcaetano]

Houston, we have a problem.

I was just checking the diff to ask for the pull request when I realised that our fork has "a little" more than this issue should cover.

Aside from the new Facebook and Twitter sharing logic, there's also app localization via .strings file and a quickfix we had to made in the status bar.

I'll ask for the pull request anyway and I'll leave the decision up to you, @jaredsinclair :grin:

[calimarkus]

you could cherry-pick a pull request branch for this feature only. I think it would more likely be accepted.

[fjcaetano]

I have no idea what you are talking about. hauauahuahau

How do I do that?

[calimarkus]

1) go to the latest point, that is identical to the original repo, e.g. git checkout master. 2) create a new branch e.g., git checkout -b feature/facebookItem 3) cherry-pick the first related commit. e.g. git cherry-pick 96cc36c (where 96cc36c is the commit hash) 4) repeat 3) for all related commits 5) send a PR for that branch

[fjcaetano]

I'll see what I can do.

[jaredsinclair]

I'd like to reboot this discussion to decide how we should proceed.

The specific problem that began the thread was that Facebook link posts (which, I'll admit, I know almost nothing about) aren't supported by OSK without forking and hacking the existing classes.

The broader problem surfaced by this issue is that no two OSKActivities have a perfectly-matched set of requirements, even if they both act upon the same content item type. OSKFacebookActivity is in general a microblog post activity like ADN or Twitter, but in practice it needs additional data.

One solution to this problem is to just say "Fuck it" and break out Facebook into it's own content item subclass. I am not convinced that this is the most prudent solution in the long term.

The same general problem applies to activities for text editing apps and services (Drafts, Editorial, Evernote, etc.). They overlap in the core details (text, tags, etc.), but differ widely in the extras.

I think a more prudent solution might be to follow in the footsteps of the ADN API's "annotations" model.

Rather than add a "url" property of the microblog content item, I suggest that we add an userInfo NSMutableDictionary to the parent class, OSKShareableContentItem, and let all subclasses (microblogging or otherwise) have a place to put these kinds of data.

Look at OSKShareableContentItem.h on the dev branch to see what I mean.

OSK's convenience constructors for OSKShareableContent can be reconfigured to pre-populate userInfo dictionaries with the values it knows the built-in classes need. Apps with bespoke OSKActivity subclasses can also use these dictionaries to provide custom data without having to fork and hack OSK.

As OSK matures, we can periodically promote frequently-accessed additional info data types to class-level properties where prudent.

What do you think?

cc @berg

[fjcaetano]

In my fork I'm currently able to share content to Facebook using simply a URL. I believe I haven't changed any models.

Twitter on the other hand is a little different because it doesn't "treat" tweets contents. But, it actually created a "shorted link" (http://t.co/).

I have some time today so I'll try to cherry-pick a pull-request as @jaydee3 suggested.

[berg]

I've thought about this a bunch, and IMO, it is best to use a separate OSKShareableContentItem subclass for Facebook content, as well as replace the current OSKFacebookActivity with in-app UI with a stub that punts to the Facebook SDK. This is at odds with my original thinking, but my experience shipping OSK inside of the App.net first-party app has changed my mind.

• Typically the default content of Facebook posts is different from microblog posts. The default post you create for Twitter and App.net, for example, might be the same, but typically you don't include a URL in the body of a Facebook post; typically it's sent as metadata along with a post. Further, the Facebook terms explicitly forbid you from including canned post text -- you're supposed to include any canned text in the destination link itself as OG tags or as supplemental metadata with the post, but the post text must be supplied by the user.
• Facebook post metadata is complex. You can send all kinds of different metadata that will override the page's open graph tags if you want, or you can let the page itself fill in the image, icon, etc. If you just include the URL in the post body, as OSK does currently, the resulting shared Facebook post is pretty ugly. It doesn't have an image or any Open Graph data, and the Facebook native deep-linking feature doesn't work. This alone is a reason not to use OSK altogether, if you're a developer and a content publisher.
• Many users don't have the built-in Facebook account support turned on. With the SDK, you don't even have to authorize Facebook -- you get punted into the FB app then quickly and seamlessly punted back.
• While the OSK sharing activity UI is gorgeous, the Facebook UI includes a nice Open Graph post preview, etc., and it's really easy to hook up. I did it, very very hackily, in my OSK fork: https://github.com/berg/overshare-kit/commit/3701977b5ccff07e6b07f603c3ad624b4e527d59
• AFAIK, with the SDK, you can choose to publish to Facebook pages as well as your own timeline, basically for free.

So I firmly believe that it's in the best interests of both end-users and content publishers, and therefore in the best interests of the community of developers that use OSK, to implement native Facebook sharing support, both OSKFacebookContentItem and a new OSKFacebookActivity.

[jaredsinclair]

...the Facebook UI includes a nice Open Graph post preview...

@berg Is this a reference to the iOS system-supplied Facebook user interface, or does the Facebook (the company) iOS SDK provide the view controllers you mention?

[berg]

@jaredsinclair I believe it's the latter. I don't think the Open Graph post preview exists in the Social.framework view controllers.

[jaredsinclair]

@berg So your recommendation is to eschew both the system supplied UI and the system supplied account management, and link to the Facebook official SDK to provide both?

[berg]

@jaredsinclair Yes. What OSK has today is already dramatically better than the UI provided by Social.framework, and in my experience, the system account management is configured properly much less often than you'd hope. Facebook-iOS-SDK is better at both of these things.

[giffnyc]

Just to provide an alternate voice here, I've been weighing a similar choice about Facebook sharing. And I've spent a lot of time with the Facebook SDK for a previous Facebook group manager/client (Roundup for Facebook ).

The kit offers an abstraction for content. Facebook specific content that is highly detailed is not an abstraction that is useful other than on Facebook . What else would one do with a OSKFacebookContentItem that is highly detailed, other than exchange it with Facebook? For such specific and detailed content activity with a single provider, I would stick with the native FB SDK.

I think the kit should stick to its abstractions, and eschew such detail. Developers who need FB specific features are never going to be happy with something other than a very detailed content model, and a very detailed posting sequence that is not in line with the model of giving users choice about multiple content destinations.

Don't get me wrong - I am basing the model I plan to use for FB on the content model in the kit - I think its great. But the model I'm building would be of little use to anyone else and of no use to user who wanted to crosspost. I am also not planning to use the kits posting methods - I'll use the FB API, since I often interact with it anyway - to set privacy in more granular way, for instance. Also, I will not be showing the activity view to a user for Facebook purposes - elsewhere, such as sharing a single photo, sure, but not in the use case of a detailed FB post.

I have a feeling the same issue will come up as regard different blogging platforms.

I try to keep it clear in my mind that the kit is for opening up choice for the user and necessarily must avoid too much detail for a content model. Even supporting such a detailed content model in the main branch, given FB's penchant for change, would be a negative time suck IMHO.

[berg]

While I agree that building deep support for Open Graph objects into the kit itself is not desirable, users have come to expect certain behavior when posting to their Facebook newsfeeds or pages; the current implementation yields stories which will convert poorly and users may be surprised that no link abstract appears in their feeds. A basic implementation is well worth the effort, IMO.

[giffnyc]

I understand your point and agree with the goal - allow users to share to Facebook in way that meets or exceeds their expectations, and make sure that the FB account management is done properly. Where I think I disagree is integrating all of that into OSK at the current time.

I am more supportive of Jared's extended dictionary approach, which I think could go so far as to address your very real concern that linked content currently delivered as a microblog item does not work very well with the FB format. There is a cross-platform feature gap of uploading metadata that I do think the kit should address, such as posting to FB as well as blogging platforms, and I think its smart to figure out how to accommodate it.

But stepping into a the creation of a content item that also has a different auth path, and a different editing view seems like a side project, not something to address in the main feature set of the kit. As an example, the sharing dialog you mention above, a feature of the FB-SDK, requires the user to have the FB app installed and configured. It no longer falls back to web based views as it used to. For certain cases, such as posting content to another user's wall, FB provides no other option - the action cannot be done with graph API calls, it can only be done my calling the share dialog. To which I re-iterate, at this point, what is the role of OSK here? I am using FB auth and FB dialogs to deliver a content item that is FB specific. Why bother even showing the activity view when I have no real equivalence across sharing services at this point?

Please don't take my advocacy for a point of view as disrespect - its a healthy dialogue and I, too, kinda wish I had a drop in one stop FB solution.

[jaredsinclair]

Well, I’m back. Sorry for the long time away. Between launching Unread and dealing with some family emergencies, it's been hectic here.

With the benefit of time, I have come to see that @berg's bulleted list of advanced Facebook needs from his comment above are totally right — and yet they’re mostly outside the scope of an off-the-shelf implementation of OvershareKit. With one exception: links. As @berg mentioned near the start of this thread, users expect that content derived from a shared link will appear in their timeline as a proper link post, not just a normal status update.

I think the right path is to try to provide a richer link-sharing experience for built-in Facebook sharing. For more advanced needs, I would recommend that developers disable the OSKFacebookActivity type altogether and provide their own app-specific substitute activity type for Facebook (FooAppFacebookActivity or whatever). I don’t think it's prudent for the built-in implementation to rely upon a external dependency for the whole stack, from authentication to UI, not for something as common as Facebook sharing.

If someone wants to submit a pull request later on for an optional OSKAdvancedFacebookActivity that's built on the Facebook SDK, I think we’d all welcome it. I just don't think that the default Facebook activity should diverge that far from the other activities.

My proposal is that I update OSKFacebookActivity to use the userInfo dictionary of the microblog content item to obtain the necessary contextual info to produce a proper link post.

[berg]

Sounds good to me, Jared. I think that's a very sensible approach; supporting proper link sharing is the most important thing for users.

I actually think I've already written the OSKAdvancedFacebookActivity that you suggest. Let me see if I can rename it, get it to coexist along the current OSKFacebookActivity, and then I can submit it as a PR.

[jaredsinclair]

Pushed up Facebook link sharing to the dev branch today:

I ended up adding an OSKFacebookContentItem because the content required more finessing than just adding a single NSURL property. Attached links show a little preview thumbnail, similar to the preview used by the native iOS Facebook share sheet.