Open Graph Configuration

In the next release of JFBConnect, we'll automatically be adding the app_id tag to all pages (when Open Graph integration is enabled). To do it now, for both parameters, we recommend going to the Social configuration area, clicking on the Open Graph tab, and making sure Open Graph integration is enabled. Next, use the big area below that for setting the defaults and enter:
app_id=12345
admins=12345,654321,88888,etc

Yes, you should set your App ID for the application used on your site (as set in the Facebook API tab).

Regardless of these settings, likes will automatically be for your site. All Likes on your page are tied to the URL that was liked. This occurs regardless of the Open Graph tags. However, JFBConnect does do some checks and extra things to make sure the URL is the 'best' URL to be liked (by removing unnecessary query strings and other things that could make non-unique URLs). All of this is meant to focus your Likes on the proper page, instead of spreading them out among multiple URLs that work for the same page.

Finally, for SEO benefits, I believe Bing is the only search engine that has stated they use Like data to modify rankings. Google currently (and likely will not in the future) use this for rankings.

As for K2, if you're already setting the title and description in K2, JFBConnect will automatically use those for the Open Graph values as well. You may want to set a default type and image in the defaults area, as above:
image=http://site.com/default-image.jpg
type=webpage

Then, in each article, you can override any of these settings (title, description, image, etc) with our easy-tags:
{JFBCGraph title=Best title for article}
{JFBCGraph image=http://site.com/best-image.jpg}

Hope that answers your questions!

Tim,
You can put the overrides anywhere on the page, and JFBConnect will find them. This can be in the article's content area, in a custom HTML module (good if you're not on an article page) or even in a template file itself. We scan the output that is meant for the user for the tags, and replace them appropriately.

As for using both tags, yes. They're different in Google's and Facebook eyes. While generally, being the same is good, there are times when you may want to target or describe your pages differently for Google/Search Engines vs Facebook.

Good luck,
Alex

Yes, we recommend enabling Open Graph integration, and at the very least, setting the following default values for your site: title, description, image, and app_id (we'll be setting app_id by default in the next release)

Enabling and using Open Graph allows you, the administrator, to determine how each page on your site should be represented when it's shared in Facebook via a like, comment or other method of sharing. When a user share's content from your site with their friends, that's your opportunity to really make sure that your page is represented in the best way possible, which can attract more users to your site. Without Open Graph tags, when a page is shared, Facebook (or in some cases the user) determines the title, description, image, and other information to represent your page.. which may not always be the best.

Hope that makes sense. Yes, the Open Graph stuff takes additional effort, and if there's any suggestions on how you think we can improve the integration and/or make it simpler, we'd love to hear it.

Thanks,
Alex

Not yet. We looked into adding this the 4.0 release, but realized there was an unacceptable performance hit with trying to load them in real time. We're hoping in the 4.1 or 4.2 release to cache the comments in the database, which will allow us to display them hidden, and even do some other nifty things like reading them in the admin area. Still in the planning stages, so don't hold me to anything

Thanks for the suggestion,
Alex

Stephen,
Yeah, we read that too, which is awesome for a lot of reasons. Doesn't directly change our plans for implementing the caching, because there are cool things we can allow for as far as searching comments and moderation, but it relieves a little pressure to get it done in 4.1 (and adding more features later) vs getting more done possibly in the 4.2 release... leaving time for other cool features in 4.1.

As for privacy, yes, scanning comments may make it more public.. but when you're leaving comments on a public website, there isn't much of an expectation of privacy. If we had been doing a hidden div with the comments, that would have exposed all the comments and user's names previously as well, and been just as public as Google digging into the iFrame. Generally speaking, if you're concerned about your comments being seen on the web, they shouldn't be in a public context to begin with... regardless of what kind of commenting system is used.

Hope that makes sense,
Alex