Archive for Tag ‘facebook‘

Social Commerce Presentation from Magento Imagine Conference

I shared the slides from my social commerce talk at the Magento Imagine conference earlier, but now the video has been posted:

I’ve also taken the audio from that video and converted the SlideShares slides into a screencast, which syncing the audio to the slides:

It’s much more useful this way than just the slides were.

WPBook 2.2.1

Try Again (Photo by Samantha Marx, cc-by license, http://www.flickr.com/photos/spam/3355834452/)

Spent some quality time this weekend with WPBook. As a result, I just released version 2.2.1. (There was briefly a 2.2 release, but something was corrupted in that version of the SVN repo, so use 2.2.1 instead).

Included in 2.2.1:

  • Read More is back. Re-enabled the “Read More” action link. Unfortunately, because of a Facebook API bug wpbook can’t add more than one action link to a post, so no “share” button on wall posts until that is fixed. (Facebook doesn’t add the Share link automatically to posts from the Graph API and there’s currently no way to make that happen other than manually adding it as a link, but I think the “Read More” link is more important.)
  • Post to Group Walls. Added posting options for Group walls, and comment import form Group walls. Because of the way the Facebook API has changed, posting to a Group feed is distinct from posting to a Page’s feed, and requires different syntax.
  • Controlled debugging. Limit the size of debug files created to 500k, so that users who enable debugging and then forget won’t have an unlimited file growing every hour. Also made the debug constant more specific to WPBook so as not to interfere with other plugins potentially using DEBUG as a constant
  • Fopen errors. Clean up DEBUG for cases where permissions fail or file is not writeable
  • Facebook::$CURL_OPTS . Made “disable ssl verification” an option so that only users who need it will have it and others won’t get conflict
  • Required fields are required. Cleanup to the admin screens in general, more clarity around what is required and better language on the admin screens about what is being checked. (Thanks BandonRandon for patches)
  • Better check permissions. Improved “Check permissions” page, to show what options mean and enable links to view profiles, pages, links to validate IDs are correct.
  • Added wpbook logo which had been missing
  • Fix for get_themes() issues with WordPress 3.0.1 through 3.0.5

I realize from the activity in the forums that many users are having trouble with the 2.1 and later WPBook – but I believe all the known errors have been fixed, and most are due to misconfiguration.

A few configuration notes that might help:

  1. Your application ID, secret, canvas URL, and Profile ID must be correct or nothing else is going to work. If you load your application canvas page and you don’t see the WPBook theme, but see just your blog in an iframe (unchanged), then something is wrong in your Facebook Application setup, your WPBook setup, or in a plugin conflict.
  2. Your personal FB profile is absolutely required, even if you don’t plan to publish to your profile’s wall. It is through the FB profile that the access_token for publishing to pages is retrieved. If your FB profile ID is wrong, nothing else is going to work.
  3. Any time you change the Profile ID, the Page ID, or the Group ID to which you are trying to publish, you must visit the Check Permissions page and will most likely need to regrant permissions. Again, if permissions aren’t working, nothing else is going to work.

If you’re stuck, please open a new thread in the wordpress forums and provide the following debugging info:

  • The URLs of your Facebook Application and your blog outside FB
  • The contents of your check permissions page – verbatim
  • What you are trying to publish to – profile, page, group – by ID and by URL
  • What error messages you are seeing, in the WordPress interface and/or in the PHP error log

With the right information, we will be able to get it working.

Thanks

WPBook 2.1.4 Released

Code Bug (Photo by Guilherme Tavares, cc-by license, http://www.flickr.com/photos/guitavares/1703252007/)

Just released WPBook 2.1.4.

Two key bugfixes in this release:

  1. Comment Imports. In changing to the Graph API I needed to add an access_token to the FQL calls I’m using to retrieve comments from non-public streams.
  2. Facebook Avatars for Pages. Given that you can now comment on wall posts as a page (by using the “use Facebook as page” option if you are the admin of a page) some of your comment authors in FB might be pages themselves. This fix will get the right FB avatar for them, eliminating what was otherwise a broken link image.

There should not be any need to regrant permissions or change any Facebook settings in this release.

Thanks to all the users who’ve provided feedback (and debug files!) in the forums.

WPBook 2.1.2 Release

Quick update – just tagged and released WPBook 2.1.2 – should show up in the repository shortly.

Note that if you’ve already made the changes described in upgrading from 2.0.x to 2.1 you do not have to redo them, though you will have to regrant permissions (in order to fix #s 1 and 2 below).

Three significant bug fixes:

Read more…

The Problem with Time on Site

Time is Running Out (Photo by Andrea Zamboni, cc-by-nc license, http://www.flickr.com/photos/zamboniandrea/170324255/)

In a previous post (Metaphors That Mislead Us: User, Audience, Visitor, Shopper?), I discussed the way in which the terms we use to describe the people who interact with our web-based applications can shape our thinking, encouraging some approaches and limiting or making others highly unlikely.

Another way in which the language we use to talk about web applications fails us is in the notion of “time on site” which analytics vendors have led us to believe means something other than what it really means.

Time on site (or Time on Page) really means something more like:

Time elapsed between multiple HTTP requests in a sequence from a single IP address within a given period of time.

Nothing more, nothing less. The “given period of time” is the session length, which is configurable but is commonly 30 minutes or an hour.

In other words, if I request one page, and only one page, from your web application/page/site, my “time on site” is exactly 0 (or undefined). Doesn’t matter if I spend 20 minutes reading the article, if I don’t request a second page, the web analytics software has no way to know how much time I spent “on” that page.

If I request a page – but open it in a background tab, as I often do, along with 10-15 other things I’m going to read throughout the day – and the view that browser tab 25 minutes later, and click on a link within it, requesting a second page – this will register as me having spent 25 minutes “on” the original page.

What web analytics software knows what URLs have been requested in a browser from an IP address. (If I use multiple browsers, each of them is treated by analytics as a distinct user, because each browser gets a unique cookie, though multiple windows or tabs in a single browser is treated as one user). The software has no knowledge of what the user behind the browser is actually doing during that time.

This doesn’t mean “time on site” is meaningless, precisely – just that it needs to be carefully considered in a broader context and with an understanding of what the label conceals.

The most common misuse of this, in my opinion, is the discussion of Facebook, and the amount of time users spend each day “in” or “on” Facebook. One of the reasons retailers are so excited about F-Commerce is because of the amount of time potential shoppers spend “in” or “on” the site, because they’re imagining Facebook as a location – as though there’s a giant Mall of the World (even bigger than Mall of America) with 600 million plus people trapped in it for 4 hours a day, yearning to spend some money.

Mall of America (Photo by jpellgen, cc-by-nc-nd license, http://www.flickr.com/photos/jpellgen/778968733/)

But are people really in Facebook in the way this suggests?

I’m in danger here of assuming my own experience is representative, but I know for myself and everyone I’ve talked to about this Facebook is just one among many things open and active on my laptop (or iPad, or phone) at a given time. The average user often has Facebook open in multiple tabs as she reads links friends have sent her, engages in comment threads, and jumps between webmail and other applications. Add them all up, and we’re all certainly spending significant time during the day engaging with Facebook (requesting urls from facebook.com). But we’re not stuck there: we’re skipping in and out – switching to other web pages, tabs, and windows, interacting with other applications on the same machine, and even (shocking, I know) stepping away from the keyboard from time to time.

Sometimes those interactions will be within the session window (a fairly arbitrary window, to be clear) and count as one visit with a long duration. Sometimes those interactions will be across session windows and count as multiple visits of short duration. Neither’s really entirely accurate, but in the aggregate it seems to me the latter is probably more accurate.