Amplify/Clipmarks Shutting Down Service Immediately

I received an email today from Amplify, a Gimme Bar like service that has been around a few years (and a former client of mine), saying that the service was shutting down immediately, which is a bit ungracious. Usually a service will give users a month or two to export or transition. I tried to open my old account but access seems to be closed.

There is the hope that the closed-beta alternative Clipboard might allow transition, but it sounds iffy:

via Clipboard Blog

I am a Clipmarks / Amplify user and I want my clips preserved. What do I do?

We can’t guarantee that all of your clips will be preserved. But if you want all of your clips preserved, you’ll want to look for an email from the Amplify and Clipmarks teams, which contains an invitation to Clipboard. From the registration page, you will be able to request that your clips be migrated from Amplify or Clipmarks into Clipboard.

The Clipboard team will assess the demand for having old clips preserved. If it is sufficiently high and technically feasible, they will build a custom tool to automate the clip migration process. In the event that they have decided that there is not sufficient demand or other complicating issues, they will notify users of that outcome as well.

Ouch.

I found Amplify interesting, but annoying. For example, the tool enforced a 1000 character limit on text clips, which was arbitrary and painful.

Storify: Another Take On Stream Media

A few mentions by Scoble and I have taken a look at Storify. It is a cool tool for aggregating snippets of material into a mixin sort of post, which is delivered as a bit of embedded javascript.

Here’s a ‘story’ created using Storify:

I used the ‘Storify This’ bookmarklet to pop up an editor with bits of info for the story:

The UX of the tool is straightforward, a drag and drop means to pull elements into a storyline, and optional text sections between them.

Storify attempts to help us pull bits together we find in the stream, tie a string around them, and throw the new collation back into the flow.

You can see the result of that story here, and of course this story starts with a Storified embed as well.

The Bottom Line

Storify is a tool geared to web-based writers, in a sense like my use of Tumblr. And like Tumblr, it publishes my ‘stories’. See http://storify.com/stoweboyd. So this is a backwards entrant into the changing publishing tools space.

We are clearly moving past the days of a clear delineation between reading, writing, and commenting. In a stream based world, everything seems to start as a response to something else, and every word we post spreads out through the ether and sparks a dozen reflections.

The product Amplify tried to tap into this, and has done so to some extent, although that is too tied to the feeling of ‘bookmarks with annotations’.

Storify attempts to help us pull bits together we find in the stream, tie a string around them, and throw the new collation back into the flow.

I think that there is promise here, but I see obvious parts missing:

  • What about the collecting of bits prior to having a specific story? Storify overlaps with Instaper and Feedly style ‘read later’ functionality, which in my case might be better called ‘write about this later’.
  • Where there is javascript there much come styling: the embed works reasonably well in my blog, but that won’t be the case for all.
  • I like the feature to notify anyone who is cited in a story. I tried the Google search capability, but Storify would benefit from a Zemanta-style recommendation engine. (PS I don’t know if Zemanta can read content in the embed.)

In a perfect streaming world we could collate bits together like this, and the meta data about the existence of that collation would stream back to the components. This is like the social gestures on Tumblr, where I see a note whenever someone reblogs or likes a post of mine. And that chain of gestures continues outward, so I am informed when my post is reblogged, even from someone else’s blog.

So, Jason Calacanis should know that his tweets are appearing in my story, and I guess the response through Twitter is appropriate, since he may not have a Storify account to be notified through. But the mechanism to let him know should be more like a retweet than a mention.

In a world of information fragments, flotsom and jetsom hurtling through a streaming world, there should be a uniform way to indicate that a ‘post’ has been reused:  either in its original independent form, or as an element of a larger collation. In this case, that a tweet (or a group of tweets) were added to a ‘story’.

Just as Twitter today keeps tabs of how many times a post has been retweeted (do they?) and Tumblr indicates how many times a post has been reblogged, we need to keep the history of things that are included in others.

I did an experiment on Storify, and adding a story (my Calacanis story) to another story (my Storify story) does not lead to some more elaborate presentation — like a nesting in an outline — and does not lead to a ‘reposted’ indicator anywhere.

While it sounds complex, there reality is simple: reposting and reuse of posts in other people’s stories — tweets, blog posts, bookmarks, whatever — should be indicated on both sides of the reuse, and in a consistent fashion. This is a return to the Tumbleback idea I floated in 2009 (see Tumblebacks: A Call For Interoperable Tumbling). Since it is more general than just ‘Tumbling’ I am proposing to rename tumblebacks as postbacks, in a nod to the old blogging technique of trackbacks. Note however, the distributed history issue was never handled in trackbacks, so more work is needed.

One last thought: Storify has a minimal analytics capability set up, tracking the clicks onto stories, but I would like a more complex analytics view, showing which story bits are getting accessed.