Difficult Choices. (Photo by Beppie K, cc-by-nc-sa license)

Over in the WordPress Support forums for WPBook, WPBook user TheCitizen was asking about the absence of “share” links on Wall Excerpts posted via WPBook. I responded that in my experience posts made via the API (by an App, rather than by the user directly) don’t get “share” links inside Facebook.

He pointed to Facebook Page Publish, a WordPress plugin which also cross-posts to Facebook (though it does not import comments). Posts made via this plugin do get a share link.

Digging in a bit, I realized that Facebook Page Publish uses the Link object in the Facebook Graph API, whereas WPBook and WPBook Lite both use a Post object.

What’s the difference? That’s what I’m trying to determine now.

Links are posted with these fields (ref):

• link
• message

The rest of the values “are taken from the metadata of the page URL given in the ‘link’ prarameter.

Posts are created with these fields (ref):

• message
• link
• picture
• name
• caption
• description
• actions
• privacy
• object_attachment

So Posts are more complex than Links, whereas Links rely on getting the Facebook metadata from the page returned by the link.

How does each appear, on the timeline and in the news feed?

Here’s the same link, posted twice, using the Facebook Graph API explorer – the first time (the lower box) is as a Link, the second time is as a Post:

That is how they look on the timeline – logging in as another FB user and looking at News Feed, I could not even see the Post type, only the Link type:

Though I’m certain that in the past I have seen items in the newsfeed which were posted as Posts. (Maybe it was that I’d just posted the same link as a link, so Facebook was hiding the second item as spam? I’ll retry with something different).

(Update: here’s what a Post type object looks like in the Newsfeed – the item for this blog post):

A few things to note:

• The nicer excerpt – “We are an interactive agency . . . ” was pulled from the page being linked to by Facebook themselves, not entered by me. In the case of WPBook or WPBook Lite posts, we want to provide the full excerpt, not have it pulled from the link destination.
• The image – again, this was pulled from the link destination. In the case of WPBook or WPBook lite posts, the image would be provided by the app (the featured image from the post) not grabbed from the destination link – but it looks the same in both.
• In the case of the link type, the “via the Graph API Explorer” is next to the poster’s name, but in the Post type it is down at the bottom above the action links
• The Link type gets a “share” action link, while the Post type only gets “Like” and Comment.”

Given all this, plus the fact that I found it hard to find the Post type in the newsfeed of an account I know follows me, I wonder if we shouldn’t switch to posting blog posts as the “Link” type.

The challenge is that the “link” type depends on the target blog having the right open graph metadata in place already (unless wpbook / wpbook lite try to actually provide that metadata).

When Facebook visits the link, it looks for Open Graph Metadata – which your blog’s theme may or may not provide.

Using the “Post” object allows WPBook / WPBook Lite to control the message being sent to Facebook more explicitly, rather than relying on metadata.

The part that worries me though is how frequently “Post” type objects get into News Feeds. Since Facebook controls the algorithm which decides what, out of the hundreds or thousands of possible posts in any given user’s feed, to show that user, I have no way of knowing whether object type (Post vs Link) has any impact.

Anyone have data on that to share?

Tagged and released version 1.1 of WPBook earlier today – get it from the wordpress plugin directory or this blog.

New in 1.1 (more info in the README with the plugin):

• Option to show “view post on www.blogurl.com” links associated with each post – shows the blog post in its original context
• Option to move the “share” link and “view original” link to the top or bottom of posts
• Option to show/hide the “add to profile” button

(Thanks to Brandon for all of the new settings).

Also I believe I’ve got the profile.setFBML working – meaning users no longer have to copy default FBML anywhere. At least it works in my two test blogs – let me know if it works for you.

I’ve also included better (I think) documentation, including screenshots of Facebook admin screens, to try to demonstrate the process of setting up an application.

If you’re using WPBook, please visit this page and add your blog in the comments.

Remaining open issues:

• Sociable.es Facebook Connect plugin conflicts. You’ll have to update the facebook client provided with the Connect plugin as described here
• Custom home pages – if your WordPress blog has a homepage that is not the default list of recent posts, I don’t know if this version will work for you – sorry, it is on my list to address but the theme currently assumes a default home page setup
• Javascript/CSS plugin conflicts – if your other plugins use css or javascript to set the height of the body or html elements to 100%, this will interfere with Facebook’s own iframe sizing javascript.

Enjoy!

A few changes since 0.9.3, the last version I blogged about (the most recent version can always be found on this page or at the WordPress site):

Share Button. This version adds a Facebook style “Share this post” button next to each blog post in Facebook, which allows the user to send the posts to Facebook friends or post and individual blog entry to their profile.

Here’s what the share button looks like, in context:

Share Button for Post inside Facebook

And here’s the resulting popup, with the “post to profile” tab active:

The resulting Popup with 'Post to Profile' active

Ease of installation and Update. Earlier versions required the user to add a directory to their /wp-content/themes/ directory. In this version, and moving forward, the plugin carries the theme directory inside it. Among other things, this means that the “update automatically” function from inside the WordPress plugins page will now work with no additional effort on the user’s part.

Add to pages. The directions have been clarified with respect to profile page boxes. If you want users to be able to add your Facebook Application to Pages as well as user profiles, you will need to enter some FBML (provided by the plugin, on the settings page) in Facebook.

Facebook Settings for Pages, with Default FBML (Note: FBML here is for this blog - yours will be different)

No Conflict with other Facebook Plugins. Using multiple Facebook plugins on your WordPress blog can lead to problems, as each includes its own copy of the Facebook client libraries. This version now checks for the existence of other libraries and relies on those already present if they have been declared.

Plans for 1.0:

For the impending 1.0 release, here’s what I plan to do:

1. Make the “share” button a setting, enabling users to turn off the functionality if they choose.
2. Provide a link to the “original” version of each blog post (outside Facebook) – also optional
3. Add a small “powered by WPBook” type link to the bottom of the canvas page – with option for user to disable.

I also plan to update the page for the plugin here and at WordPress with some screenshots to accompany the documentation, but that might not happen until after the plugin is released.

The way the feature should work is that the Alfresco Share application takes the PDF a user uploads into the document library, converts it to an SWF using swftools (one frame of the SWF per each page of the PDF), and then uses the YUI framework to “play” the resulting SWF.

The problem is that for me, depending on the version of Flash installed, the preview SWF cannot be displayed. (Short version: Flash 9.0.45-47 works fine, later Flash versions just result in a spinning cursor which never resolves. The problem is Flash 9.0.45 breaks file upload, which works in later Flash versions).

Good Flash

Bad Flash

Just finding this out required a lengthy exercise including full uninstalls of Flash (using Flash uninstaller for Mac OS X, which takes forever since it is a PowerPC binary running on an Intel machine) along with installs of various versions of Flash from the 9.x archive.

It was in this context that I was so happy to see the dialogue Dion Almaer and Brad Neuberg posted at Ajaxian today: How Flash Can Join The Open Web.

The conversation began on Dion’s techno.blog(“Dion”) with The Flash Platform: How Adobe could join the Open Web to take on . . . in which he argues:

With Silverlight making a huge charge I worry about a world where you have “Best viewed in Silverlight and IE” (which in fact is “only viewed in…”) and people often ask: “But isn’t Flash just as bad?”

Adobe has an opportunity here. They can move to the right and Flash could become strongly in the Open Web camp. Then we would all be stronger as we come up against Silverlight :)

Indeed, Dion’s image, which he used to show the developer perception of Flash and Silverlight together in contrast to the Open Web isn’t that much different than this image I’ve used in previous blog posts here:

Brad responded over at coding in paradise with How Flash Can Integrate With The Open Web, in which he argues that:

Adobe (and Macromedia before it) has always been good about evolving Flash forward, including making ActionScript more like JavaScript, embracing markup language development, open sourcing Flex, and more. I’d like to see Flash continue to evolve into being a core part of the Open Web. This would be good for Flash and good for the Open Web.

As Dion points out open sourcing Flash is one big part of making this happen, but another huge aspect would be to have Flash and Flex integrate better into the web stack and be less of a ‘black box’ on the screen.

He goes on to list a number of ways that “Flash should start working like the web itself”:

• Directly push Flex and ActionScript to the browser and Embrace View Source
• Integrate with Bookmarking and History
• Don’t Be Afraid of the Browser
• Hyperlinks Are Your Friend
• Embrace REST and Readable Remoting Protocols
• Embrace SVG
• Integrate With HTML and CSS
• Make Friends With HTML 5 Video
• Support Both Documents and Applications
• Start Working with the W3C and IETF (and/or the Open Web Foundation)

Now, of course it’s not fair to blame Adobe for my troubleshooting woes of the last week – more likely something about the SWFs produced by SWFTools or the way Alfresco Share is trying to pass them through the YUI Components is to blame, and it’s just that some versions of the Flash player are more forgiving than others.

But how much easier would it be to debug such an application if the Flash plugin didn’t create such a “black box” in the middle of my web application? What if I could dive into the running Flash application the way I can dive into the document object model in firebug, and determine the states of objects and content of variables?

Like Brad and Dion, I like what Flash is capable of, but so much more great innovation could be built with Flash if it were more integrated with the rest of the evolving web stack – whether that means open sourcing all of Flash or just finding ways t work with browser makers (commercial and open source) to make the content and interactivity in SWFs more accessible to the end user.