Activitystrea.ms is an extension to the Atom feed format to express what people are doing around the web, as Chris Messina was quoted in Louis Gray's "It aims to be the DNA of the Future Web",
Digging into Buzz
There's only one problem.. Buzz only talks about Buzz posts (Chris Posted a Buzz Note), when in reality I posted a blog on a connected site and shared it via Buzz. Ok verbs don't really matter but even the ActivityStream object points back to the Buzz post instead of the original post and the metadata for my actual activity and blog post is nowhere to be found. This connected site post appears as if I posted "Day 48 – Arrived! | Roz Savage, Ocean Rower" on Buzz (see feed). The full blog post text, a key feature within Buzz, is gone .. replaced by only the title, with no link, no summary and no attribution. Clicking on the syndicated link would bring users to Buzz instead of the original source.
So what is going on? As many of you know, I take more of a product manager/big picture point of view when I dig into (or develop) a new tool. I try to understand all the use cases (both user and developer) and analyze the options, inputs, and outputs to determine what data/resources are available to accomplish other goals (import, sharing, syndication, search, monitoring, etc). Specs, stated goals and visions are just words, implementation is what really matters to someone actually using the tool.
Sharing via Atom Feeds (my pre-Buzz experience)
I am a huge fan of two tools, friendfeed and Google Reader and I use them to find and share content through their widgets and feeds.
Friendfeed can be used to import any feed and native posts can be added via a status update or a bookmarklet. The feed title and mediaRSS (optional summary as first comment) are extracted and the public results are output in atom format with the rel="alternate" link back to the original source (when available).
Google Reader can be used to subscribe to any feed, also has a bookmarklet/share and notes which can be added to any shared post or rarely used as a standalone status. Users can then share full post content through multiple feeds (a main shared items and by folder/tag) which are output in atom format with the rel="alternate" link back to the original source (including shared items with notes).
Note: rel="alternate" links are used to define the URL of the resource described by the containing feed element. Clicking on a feed based widget will bring you to the original source web page instead of back to friendfeed or Google Reader. In both cases the main content text/html is modified to show the full content adding notes when necessary "ChrisMyles: My note here".
Buzz's Public Feeds
When Buzz first launched, only read access to the Public Buzz activity stream was available (for syndication) and even then it felt rushed. I watched status updates "Buzz by USERNAME from Buzz" liter my social circles and a simple two minute test in Yahoo Pipes showed that the MediaRSS section was broken and geoRSS position data was missing for mobile Buzz. It was useless for my purposes (Activity summary, slide show and maps) so I stopped my investigation and waited for "Coming Soon" features.
When the Google Buzz API Debuted it was released with an expressive list of partners. I quickly tried the seesmic integration and found the lack of real-time updates of posts and comments frustrating, nothing against seesmic because the API doesn't support it natively (like friendfeed).
New API = Bad Feed for Buzz Syndication
One of the surprising unannounced "features" was a change of the default public feed from the old "API" to the new one, the only reason I noticed was a geoRSS Bug I was watching was closed. A quick check found the new titles MUCH more useful but I was surprised that none of my rich media was appearing in my two minute yahoo pipes test or as attached elements in my archived Buzz feed in Google Reader.
A deeper dive into the feed yielding some "interesting holes" that I never got to during my first analysis and led to lots of discussions in the API group and plenty of new Issues to the issue tracker.
The Problem with Developers and Specs
I've noticed two general types of developers throughout my career, those who code to (and love) specs and those who really want to understand the use cases and overall intentions first and use specs as reference to clarify. If you've ever look at any of Atom or Activity Streams you'll see extremely verbose and seemingly detailed specifications but they aren't always explicit: ex: WRT link rel="alternate"
It's clear Google has a very spec centric focus.. I've had issues marked as closed by siting a spec instead of actually running the example to see if it works correctly (like a user would). The API group responses tend to suggest a focus towards Buzz clients or those to "implement a full Buzz UI themselves" vs syndication. The problem is the meta data isn't there to duplicate the UI or syndicate it effectively and I argue that over the long run a lot more users will syndicate vs develop.
Buzz Special Cases
An even deeper dive shows that valuable meta data (previously in MediaRSS) is buried in a <buzz:attachment> and re-shares are handled by a special case <buzz:reshare>. The entire goal of Activity Streams was to solve the friendfeed problem, by making more meta data available in a standard format so that it would be easier consume by clients.
Isn't a reshare just a share of another Buzz post? The Activity Stream supports multiple objects, couldn't the photos from a blog post be another objects? Why the special casing?
Taking a quick look around at other users of Activity Streams both facebook and cliqset (example) use multiple objects to represent Note/Blog-Entry and Media. The cliqset ActivityStream Note/Blog-Entry actually points back to the original source (Kevin posted a note via twitter, Kevin shared So-and-So's note via twitter for RTs) and contains a large portion of the original <content> text when available.
Buzz can be VERY confusing with respect to capturing a users intended activities. Friendfeed treats Reader Notes as comments (to clarify) and preserves the original <title> so that it is clear what is being shared. Buzz uses a snippet of the Reader and Buzz note as the title so it is impossible to determine if I have read the syndicated article without clicking through to Buzz. This is especially true when displayed in status form on twitter. How many users will click through an interesting Note description (with a goo.gl link) only to find the same exact underlying shared post that they've already read? Most services will preserve the post title and add the extra note only when there is room.
A comparison of Reader and Buzz feeds in cliqset shows the confusion.
The top pair was a Reader share without a note (notice the difference in content), the bottom pair included a note which changes the Buzz post title obfuscating the primary action, Kevin shared a Link (what link?). The trip though Buzz adds a seemingly new activity but removes details and metadata, the object links for Reader point to the original source while the Buzz version points back to Buzz.
When am I sharing vs posting?
Native Buzz users can add text and insert a link, allowing a Buzz post to be used to post or share (prior to the share button and reshare this was the only sharing method). At what point is a Buzz post an actual post with some URLs for reference (via auto-insert from text or insert link) vs a simple clarification note like Chris shared "This is a cool post" (with a URL)? Remember the answer to this question will affect how comments flow via Salmon, notes create new end points that break the flow.
When I click on the Buzz share button I expected the primary object to be the actual post I'm sharing. Based on the activity note overview above, I shared a specific post with a note but the primary object should be the post. I certainly didn't post a note and expect the only meta data and text to point back to my Buzz note.
A good place to test activity streams is http://activitystreamstester.appspot.com, I used Kevin Mark's activity streams from Buzz and cliqset as a comparison (shown above). You can also test your own Buzz feed API output , which displays the Buzz Title, Post content text and comments but NOT rel=alternative links or other critical metadata. Note: I do not consider a link buried in the entries content metadata!!
Buzz uses Activity Streams to add more duplicated metadata about itself, while excluding the original source metadata and removing original source text! The focus should be on the primary object, not Buzz.
What about syndication?
Google has recently announced the deprecation of old-style feeds even though the new version is horrible for general syndication. There are 100's if not 1000's of services that process mediaRSS without requiring special case handling of <buzz:attachments> and <buzz:reshare>. I can't understand why Buzz wouldn't want to support open existing and proven solutions to help increase their reach and accessibility to other sites and blogs, isn't that why we are all so fired up about open protocols?
I put together a quick interactive syndication sample using the Reader, friendfeed and the two buzz feeds. Two syndicated views are available, a basic one through the Google Feed API and another more complete example which handles MediaRSS and includes a combined feed (two posts through the four feed) in addition to each individual feed. Click on the titles to see which site you visit.
The Following Buzz feed data should be fixed
I can understand how the write API feed would relate directly to Buzz, but syndication has different goals especially for aggregated shared data.
Implementation doesn't match goals
From Louis Gray's Googles Open Tools and Apis make Buzz Hum
"We are committed to open standards, and we want to build a non-siloed product at every turn," said Bradley Horowitz, vice president of product management at Google on Monday. "You will see us take all these open standards, like Pubsubhubbub, Webfinger, Salmon, and use this as a vehicle to demonstrate to the world what it means to use them."
Is the implementation of the Buzz API non-siloed (compared to Google Reader/friendfeed)? Is this how ActivityStreams were meant to be used? I don't see that at all, the Buzz implementation doesn't even match the spirit of the Activity Streams spec (for shared posts), let alone the visions of a Buzz API developer DeWitt Clinton in Designing Buzz for a Google-Free World or as great, glorious messaging bus in the sky.
Who's checking the results?
Goals, visions and specs are completely useless unless someone is actually testing the results against the release objectives with the big picture in mind, yet time and time again I've watched Google fall flat when it comes to implementation/execution. Buzz can never be just a check box list of standards with specs that you just throw at developers, someone needs to understand and monitor the releases from the customer and developers point of view. In the past I have suggested that Google needed a customer advocate (and even wrote the full job description), most developer advocates are only focused on the API side (not the complete picture) and they usually have other development responsibilities.
Is it just a bug?
If it is, it's a big one because it affects the overall "open" appearance. I've been "keeping them honest' by pointing out various special case bugs that I'm surprised no one else has noticed internally considering the depth that both Chris Messina and Dewitt Clinton investigate and point out other companies/tools flaws. It's frustrating to watch them focus on other tools because they don't seem to attack their own tool/visions with the same intensity..
From Chris Messina Understanding the Open Graph Protocol (WRT facebook)
"It’s one thing for semantic and identity layers to emerge on the web, but it’s something else entirely for the all of the interactions on those layers to be piped through a single provider"
I would be very interested to see if these Activity Stream based results match their expectations!
So where is Buzz going?
According to discussions I've seen, Salmon will be the next major protocol to impact Buzz. Salmon's goal is to allow comments to flow upstream/downstream to/from the original blog in an attempt to solve the "conversations around the content are becoming increasingly fragmented into individual silos" issue. Based on my understanding and Buzz discussions regarding salmonability, a large percentage of the current (and newly implemented) sharing features will result in new "endpoints" (especially by adding notes) which will break the commenting flow. I haven't been able to get the team to engage on existing Buzz use cases or provide any details (beyond the spec).
The roadmap and release notes are useless and the visions don't seem to match the implementation. I love rapid iteration and developing in the wild along with my customers but Google is missing the critical bidirectional feedback loop that makes this method successful.
I watch as the technologists get excited that comments flow in realtime between Buzz, Google Reader and Buzz profiles, yet the GUI refresh that makes this "feature" visible to the user isn't there, or how cool it is to post Buzz with location from their browser through a mobile buzz hack Chrome dev-release hack, yet no insight is available into Buzz's geolocation strategy (desktop, import/export) even though location was touted as a "powerful signal for relevancy" at launch.
Based on this seemly simple attempt to syndicate my Buzz, I'm very confused as to where Buzz is heading and how they will get there.
From ReadWriteWeb
Update: After a week of discussions with the Buzz Team, I'm even more confused and frustrated. No one seems to be able to discuss Buzz at the 10,000 foot level where most of the presentations and expectations have been set. They want to dive into the un-detailed Atom and Activity Streams specs for justification without looking at the other examples of both Atom and Activity Stream results from other tools. Even the Activity Stream spec clearly states what to do for implied activities and the requirements for Activity re-publishers. The missing non-Buzz post meta-data and full content has been deemed a low priority issue.
We snack on information. It may feel like overload, but the tools haven't caught up. The solution to data overload is more metadata and we are at that point where can start generating that. We take the basic construct from 1999 and weave in some additional information - data about data.It's based on a VERY simple concept of verbs, objects and types
- actor verb object (target)
Digging into Buzz
There's only one problem.. Buzz only talks about Buzz posts (Chris Posted a Buzz Note), when in reality I posted a blog on a connected site and shared it via Buzz. Ok verbs don't really matter but even the ActivityStream object points back to the Buzz post instead of the original post and the metadata for my actual activity and blog post is nowhere to be found. This connected site post appears as if I posted "Day 48 – Arrived! | Roz Savage, Ocean Rower" on Buzz (see feed). The full blog post text, a key feature within Buzz, is gone .. replaced by only the title, with no link, no summary and no attribution. Clicking on the syndicated link would bring users to Buzz instead of the original source.
So what is going on? As many of you know, I take more of a product manager/big picture point of view when I dig into (or develop) a new tool. I try to understand all the use cases (both user and developer) and analyze the options, inputs, and outputs to determine what data/resources are available to accomplish other goals (import, sharing, syndication, search, monitoring, etc). Specs, stated goals and visions are just words, implementation is what really matters to someone actually using the tool.
Sharing via Atom Feeds (my pre-Buzz experience)
I am a huge fan of two tools, friendfeed and Google Reader and I use them to find and share content through their widgets and feeds.
Friendfeed can be used to import any feed and native posts can be added via a status update or a bookmarklet. The feed title and mediaRSS (optional summary as first comment) are extracted and the public results are output in atom format with the rel="alternate" link back to the original source (when available).
Google Reader can be used to subscribe to any feed, also has a bookmarklet/share and notes which can be added to any shared post or rarely used as a standalone status. Users can then share full post content through multiple feeds (a main shared items and by folder/tag) which are output in atom format with the rel="alternate" link back to the original source (including shared items with notes).
Note: rel="alternate" links are used to define the URL of the resource described by the containing feed element. Clicking on a feed based widget will bring you to the original source web page instead of back to friendfeed or Google Reader. In both cases the main content text/html is modified to show the full content adding notes when necessary "ChrisMyles: My note here".
Buzz's Public Feeds
When Buzz first launched, only read access to the Public Buzz activity stream was available (for syndication) and even then it felt rushed. I watched status updates "Buzz by USERNAME from Buzz" liter my social circles and a simple two minute test in Yahoo Pipes showed that the MediaRSS section was broken and geoRSS position data was missing for mobile Buzz. It was useless for my purposes (Activity summary, slide show and maps) so I stopped my investigation and waited for "Coming Soon" features.
When the Google Buzz API Debuted it was released with an expressive list of partners. I quickly tried the seesmic integration and found the lack of real-time updates of posts and comments frustrating, nothing against seesmic because the API doesn't support it natively (like friendfeed).
New API = Bad Feed for Buzz Syndication
One of the surprising unannounced "features" was a change of the default public feed from the old "API" to the new one, the only reason I noticed was a geoRSS Bug I was watching was closed. A quick check found the new titles MUCH more useful but I was surprised that none of my rich media was appearing in my two minute yahoo pipes test or as attached elements in my archived Buzz feed in Google Reader.
A deeper dive into the feed yielding some "interesting holes" that I never got to during my first analysis and led to lots of discussions in the API group and plenty of new Issues to the issue tracker.
The Problem with Developers and Specs
I've noticed two general types of developers throughout my career, those who code to (and love) specs and those who really want to understand the use cases and overall intentions first and use specs as reference to clarify. If you've ever look at any of Atom or Activity Streams you'll see extremely verbose and seemingly detailed specifications but they aren't always explicit: ex: WRT link rel="alternate"
The value "alternate" signifies that the IRI in the value of the href attribute identifies an alternate version of the resource described by the containing element.Samples usually relate to basic (self-explanatory) use cases without explicit details while the more complex but common examples are missing..i.e. what happens when I share a post with images, thumbnails and a video from another person? What happens if I share an entry with a note in Google Reader or Buzz?
It's clear Google has a very spec centric focus.. I've had issues marked as closed by siting a spec instead of actually running the example to see if it works correctly (like a user would). The API group responses tend to suggest a focus towards Buzz clients or those to "implement a full Buzz UI themselves" vs syndication. The problem is the meta data isn't there to duplicate the UI or syndicate it effectively and I argue that over the long run a lot more users will syndicate vs develop.
Buzz Special Cases
An even deeper dive shows that valuable meta data (previously in MediaRSS) is buried in a <buzz:attachment> and re-shares are handled by a special case <buzz:reshare>. The entire goal of Activity Streams was to solve the friendfeed problem, by making more meta data available in a standard format so that it would be easier consume by clients.
The activity in ActivityStreams is a description of an action that was performed (the verb) at some instant in time by someone or something (the actor) against some kind of person, place, or thing (the object). There may also be a target (like a photo album or wishlist) involved.What's the Primary Object? and What action did I perform?
Isn't a reshare just a share of another Buzz post? The Activity Stream supports multiple objects, couldn't the photos from a blog post be another objects? Why the special casing?
Taking a quick look around at other users of Activity Streams both facebook and cliqset (example) use multiple objects to represent Note/Blog-Entry and Media. The cliqset ActivityStream Note/Blog-Entry actually points back to the original source (Kevin posted a note via twitter, Kevin shared So-and-So's note via twitter for RTs) and contains a large portion of the original <content> text when available.
Buzz can be VERY confusing with respect to capturing a users intended activities. Friendfeed treats Reader Notes as comments (to clarify) and preserves the original <title> so that it is clear what is being shared. Buzz uses a snippet of the Reader and Buzz note as the title so it is impossible to determine if I have read the syndicated article without clicking through to Buzz. This is especially true when displayed in status form on twitter. How many users will click through an interesting Note description (with a goo.gl link) only to find the same exact underlying shared post that they've already read? Most services will preserve the post title and add the extra note only when there is room.
A comparison of Reader and Buzz feeds in cliqset shows the confusion.
The top pair was a Reader share without a note (notice the difference in content), the bottom pair included a note which changes the Buzz post title obfuscating the primary action, Kevin shared a Link (what link?). The trip though Buzz adds a seemingly new activity but removes details and metadata, the object links for Reader point to the original source while the Buzz version points back to Buzz.
When am I sharing vs posting?
Native Buzz users can add text and insert a link, allowing a Buzz post to be used to post or share (prior to the share button and reshare this was the only sharing method). At what point is a Buzz post an actual post with some URLs for reference (via auto-insert from text or insert link) vs a simple clarification note like Chris shared "This is a cool post" (with a URL)? Remember the answer to this question will affect how comments flow via Salmon, notes create new end points that break the flow.
When I click on the Buzz share button I expected the primary object to be the actual post I'm sharing. Based on the activity note overview above, I shared a specific post with a note but the primary object should be the post. I certainly didn't post a note and expect the only meta data and text to point back to my Buzz note.
A good place to test activity streams is http://activitystreamstester.appspot.com, I used Kevin Mark's activity streams from Buzz and cliqset as a comparison (shown above). You can also test your own Buzz feed API output , which displays the Buzz Title, Post content text and comments but NOT rel=alternative links or other critical metadata. Note: I do not consider a link buried in the entries content metadata!!
Buzz uses Activity Streams to add more duplicated metadata about itself, while excluding the original source metadata and removing original source text! The focus should be on the primary object, not Buzz.
What about syndication?
Google has recently announced the deprecation of old-style feeds even though the new version is horrible for general syndication. There are 100's if not 1000's of services that process mediaRSS without requiring special case handling of <buzz:attachments> and <buzz:reshare>. I can't understand why Buzz wouldn't want to support open existing and proven solutions to help increase their reach and accessibility to other sites and blogs, isn't that why we are all so fired up about open protocols?
I put together a quick interactive syndication sample using the Reader, friendfeed and the two buzz feeds. Two syndicated views are available, a basic one through the Google Feed API and another more complete example which handles MediaRSS and includes a combined feed (two posts through the four feed) in addition to each individual feed. Click on the titles to see which site you visit.
The Following Buzz feed data should be fixed
- Missing mediaRSS data for syndication
- Missing original post content or summary
- Change link to the original (primary) source if available (Google Reader/Friendfeed example)
- Title should display original source details as primary activity (again think twitter)
- Fix basic feed bugs (post order, reshare title, max-results etc)
- Use rel="via" and rel="related" links to point to Buzz when needed (rel="alternate" for _primary_ )
- Each sharing method should provide consistent data (share, share with note, post with links, via connected sites, Google Reader with and without notes, etc)
- Consider a non-ActivityStreams aware feed optimized specifically for syndication (until AS becomes more mainstream)
- Consider twitter syndication through feedburner or provide a clearly designed status method
I can understand how the write API feed would relate directly to Buzz, but syndication has different goals especially for aggregated shared data.
Implementation doesn't match goals
From Louis Gray's Googles Open Tools and Apis make Buzz Hum
"We are committed to open standards, and we want to build a non-siloed product at every turn," said Bradley Horowitz, vice president of product management at Google on Monday. "You will see us take all these open standards, like Pubsubhubbub, Webfinger, Salmon, and use this as a vehicle to demonstrate to the world what it means to use them."
Is the implementation of the Buzz API non-siloed (compared to Google Reader/friendfeed)? Is this how ActivityStreams were meant to be used? I don't see that at all, the Buzz implementation doesn't even match the spirit of the Activity Streams spec (for shared posts), let alone the visions of a Buzz API developer DeWitt Clinton in Designing Buzz for a Google-Free World or as great, glorious messaging bus in the sky.
Who's checking the results?
Goals, visions and specs are completely useless unless someone is actually testing the results against the release objectives with the big picture in mind, yet time and time again I've watched Google fall flat when it comes to implementation/execution. Buzz can never be just a check box list of standards with specs that you just throw at developers, someone needs to understand and monitor the releases from the customer and developers point of view. In the past I have suggested that Google needed a customer advocate (and even wrote the full job description), most developer advocates are only focused on the API side (not the complete picture) and they usually have other development responsibilities.
Is it just a bug?
If it is, it's a big one because it affects the overall "open" appearance. I've been "keeping them honest' by pointing out various special case bugs that I'm surprised no one else has noticed internally considering the depth that both Chris Messina and Dewitt Clinton investigate and point out other companies/tools flaws. It's frustrating to watch them focus on other tools because they don't seem to attack their own tool/visions with the same intensity..
From Chris Messina Understanding the Open Graph Protocol (WRT facebook)
"It’s one thing for semantic and identity layers to emerge on the web, but it’s something else entirely for the all of the interactions on those layers to be piped through a single provider"
I would be very interested to see if these Activity Stream based results match their expectations!
So where is Buzz going?
According to discussions I've seen, Salmon will be the next major protocol to impact Buzz. Salmon's goal is to allow comments to flow upstream/downstream to/from the original blog in an attempt to solve the "conversations around the content are becoming increasingly fragmented into individual silos" issue. Based on my understanding and Buzz discussions regarding salmonability, a large percentage of the current (and newly implemented) sharing features will result in new "endpoints" (especially by adding notes) which will break the commenting flow. I haven't been able to get the team to engage on existing Buzz use cases or provide any details (beyond the spec).
The roadmap and release notes are useless and the visions don't seem to match the implementation. I love rapid iteration and developing in the wild along with my customers but Google is missing the critical bidirectional feedback loop that makes this method successful.
I watch as the technologists get excited that comments flow in realtime between Buzz, Google Reader and Buzz profiles, yet the GUI refresh that makes this "feature" visible to the user isn't there, or how cool it is to post Buzz with location from their browser through a mobile buzz hack Chrome dev-release hack, yet no insight is available into Buzz's geolocation strategy (desktop, import/export) even though location was touted as a "powerful signal for relevancy" at launch.
Based on this seemly simple attempt to syndicate my Buzz, I'm very confused as to where Buzz is heading and how they will get there.
From ReadWriteWeb
Messina and Smarr are huge assets in the social web space. My concern is specific to Google. With Messina, Smarr, [inventor of OpenID and more Brad] Fitzpatrick and others all working for Google, focusing on the Social Web, there is less and less incentive for Google to reach out. Google has a strong coding culture which puts running code ahead of consensus and collaboration. Now with so many bright minds in house, they are even less likely to reach out.My concern is even more basic than that.. sometimes I wonder if they even run their own code.
Update: After a week of discussions with the Buzz Team, I'm even more confused and frustrated. No one seems to be able to discuss Buzz at the 10,000 foot level where most of the presentations and expectations have been set. They want to dive into the un-detailed Atom and Activity Streams specs for justification without looking at the other examples of both Atom and Activity Stream results from other tools. Even the Activity Stream spec clearly states what to do for implied activities and the requirements for Activity re-publishers. The missing non-Buzz post meta-data and full content has been deemed a low priority issue.
No comments:
Post a Comment