This page includes

• Completed feature enhancements to the Social Actions API in 2010
• Rough timeline of feature enhancements to the Social Actions API in 2010
• Requested and tabled feature enhancements

Completed feature enhancements to the Social Actions API in 2010

Q1 2010

• Fixed 'no action source' error on action feeds we have 'destroyed'
  • A few months back, we added the ability to remove 'action sources' (as opposed to 'sites') from the Social Actions API.  Recently, I noticed that the actions associated with 'destroyed' feed remain in the system, and create an error message when displaying in search.socialactions.com, and when someone tries to click on them. (ie, http://is.gd/5gVq9, http://is.gd/5gVrg, and http://is.gd/5gVt6). I'm not entirely sure how to resolve the problem, but basically, we want the actions associated with 'destroyed' feeds to either be automatically blacklisted, or removed from the system altogether. Looking forward to resolving this issue to avoid the error messages and confusion, especially on click-throughs coming via third-party applications.
• Created mechanism to 'disable' all actions associated with an action sources or site

Rough timeline of feature enhancements to the Social Actions API in 2010

Q1 2010

• Provide support for spreadsheet-based aggregation of new actions
  • We'd like to offer the ability to action sources that are just starting out to provide a spreadsheet of the actions in their system (like we do for the Social Entrepreneur API and Nonprofit Management 101.  I'm wondering what would be involved in created a simple plugin that interprets the contents of a CSV file for the datapoints of the Social Actions API.
• Create a dashboard for calculating click-throughs on a per action source, per action type, and per date-range basis.
  • For several months, Christine and I have wanted to run queries on the number of click-throughs coming through the system by action source, action type, and referring site. We have not been successful in analyzing the raw CSV files or finding a developer to build an interface to this date. As a result, I'd like to add this to-do item to our priorities. I'm hoping it's just a few hours of work to create a dashboard that permits anyone to look up click-through analytics on the Social Actions API by combining action source, action type, referring site, and date-range combinations. Raw numbers followed by the click-through details in a table forma would be sufficient for now, in terms of the output of the dashboard. We can discuss the scope of this to-do on our call today, but it's something I'm very interested in prioritizing. Also, as a matter of following up, were you able to setup the cron job that updates the click-through CSV file each night?
• Temporarily switch the redirect type on the GiveIndia feed (if possible on a per action source basis)
• A way to tell when the last time sites.json and action_types.json were changed. Could that information be incorporated into the headers since Dieterich thinks it's a fairly useful thing to know.

Q2 2010

• Set up a cron that moves a daily dump to Social Actions box
  • I'm concerned that there's still no comprehensive back-up of the Social Actions API -- regularly transfered to another server. I'd like to setup a weekly cron job that moves a copy of the databases to the Social Actions dedicated box, or some such thing. Obviously, I can provide login information for the dedicated server.
• Download a snapshot of the ico file
  • This is something you mentioned as a safeguard measure at some point.
• Adjust pagination to accommodate blacklisted actions.
  • This may not actually be a problem -- I just noticed that paging corrects itself after the fact. Initially, when I blacklist actions, a place for them still appears in the pagination associated with a query, but obviously the actions don't appear for the non-logged in user. Within a day or two, the pagination seems to correct itself. Is there any way to speed up the 'reindexing' (correct word?) that occurs when actions have been removed / blacklisted.
• Draft documentation for setting up a clone of the Social Actions API
  • We'd like to provide comprehensive documentation on the wiki for anyone that may want to setup their own version of the Social Actions API on their own servers to aggregate actions and/or to customize it for another aggregation project. This wiki page will be improved overtime, but I'd like to spend a bit of time creating a stub that describes the process in broad stroaks.

Q3 2010

• TBD

Q4 2010

• TBD

Requested and tabled feature enhancements

• Expiring of actions
  • This issue will bring the API to its knees if we're not careful
  • No need to have six month old actions (in most cases)

• Revamp user interface and functionality for search.socialactions.com (Community project)
  • Add "select all" and "select none" to search.socialactions.com
• Figure out why the referrer info isn't getting captured
• "Action types are already available as part of the OA outputs. They aren't included in the search index however, but that's the same issue I'm dealing with regarding the SE-API, thus I will deal with it next week when I address that issue there."
• Plugin support for action sources that have their own APIs (needs more info on a per plugin basis)
  • Kiva API
  • GlobalGiving API
  • DonorsChoose.org API
  • VolunteerMatch API
  • All for Good API
  • MeetUp API
• Adding new fields to Open Actions XML schema and Social Actions API (2-3 hours, including deciding what fields to add)
  • Date
  • Adding location to platform and organization
  • Image field
  • RSS feed for the action field
• Limit API returns to specific data fields (3 hours)
• Shortening IDs for action sources / sites / platforms
• Search engine voting on actions (this needs more discussion, may be better suited as a third party app)
  • Add vote-up / vote-down capabilities to the Social Actions code-base;
  • Integrate the voting results into the Social Actions API;
  • Launch the action bar with voting functionality;
• API support for communitiy voting on actions
• Implementation of action bar
• Restoring the ability to determine location information from existing feeds (3 hours for planning and implementation)
  • Encourage current action sources to use GeoRSS (not Ronin)
  • Review the way in which the current action sources reference location (not Jason)