Correct me if I'm wrong, but I didn't find an option to disable using Twitter's own shortening service?
As an extreme example, I find http://t.co/gpRQitG less informative than http://youtu.be/oHg5SJYRHA0. If your site is still only at 3 characters ID, unlike Youtube, having a custom shortened domain from which users can tell what it is, generally, what they're clicking on, is a much better user experience than using a universal shortener which says nothing about the content.
I know Twitter wants to have maximum trackability and extensibility for shortened links, but I think the best way to do it would be to offer a secondary API to sites that have their own identifiable shortlink domain.
Instead of just building in the tweet button, a site could hook into a Twitter shortlink API, which would let Twitter run its analytics and implement future functionality while the site continues to generate URIs through its own youtu.be, flic.kr, etc. domain.
They could actually exploit it as a business feature. Make the flic.kr domain point to Twitter's servers, who implement the shortening service, and allow the business users to view lots of interesting stats, in relation with tweets. Stuff the business on its own could never gather without access to Twitter's extensive database of tweets.
This way both win. Twitter could charge for it as well.
That's... one of the best Twitter monetization ideas I've heard.
It pushes Twitter's real-time social analytics value to businesses while obviously strengthening a company's brand on Twitter. If the Tweet Button catches on, it could be a very easy sell.
From what I recall Twitter is planning on wrapping every single URL going through their system with t.co but include the youtu.be link in the status metadata when applications pull from the API. The youtu.be URL will be displayed to users but will be sent to t.co first then redirected to youtu.be.
This is correct. Once clients adopt it (we do, at Twitterfall), this will in some ways improve how informative URLs are, as each tweet object will contain the actual URL the t.co link points to in the metadata, allowing clients to display that, essentially overcoming the 140 char limit.
Of course, you are free to use your own ahortnener; the t.co link will redirect to shortened links too (adding another layer of redirection is a bit of a pain though)
the big news imho is "Datasift" (twitter partnering with tweetmeme for):
"Scalable platform for developers to build very precise streams of data from the millions and millions of status updates sent every day.
* Tune tweets through a graphical interface or our bespoke programming language
* Streams consumable through our API and real-time HTTP
* Comment upon and rank streams created by the community
* Extend one or more existing streams to create super streams
DataSift is designed to work at scale, serving hundreds of thousands of real-time streams and processing millions of rules every second. We hope that the product will allow developers to focus on the building of amazing new user experiences and let us worry about delivering the right content to the right person."
How do you get around the problem of one of these widgets taking forever to load and slowing down your site's render time? I noticed with the "Like" button that it was, on average, too slow to use on our home page. Am I doing it wrong?
We have a "Tweet this" link above our maps that has been getting good usage, and costs us nothing in terms of YADNSLU (yet another DNS lookup).
The way I look at it is: An in-house same-domain solution's the slickest and fastest.... but you lose out on any network-effect recommendations.
That said, facebook widgets are ridiculously expensive in terms of domain lookups and requests.
But back to the topic of tweet buttons. Twitter's 3-request button beats the heck out of the Tweetmeme iframe+javascript franken-thing. I just looked on Tweetmeme's site ( http://tweetmeme.com/about/retweet_button ), and even they recommend using the twitter button: "We recommend using the Twitter Tweet Button. You can find more details about it on the Twitter goodies page."
I wonder if they're going to be doing the same sneaky tracking via cookies and iframe that the Like Button does irrespective of whether you actually interact with it or not.
AddThis (acquired by ClearSpring) is doing this as well. It goes even further by injecting an invisible Flash object that's just there to set a Flash Cookie that 99.9% of users don't know how to delete.
The shadiness of all of this tracking should give us all pause before we plaster our websites with these widgets.
Yeah. You're not the only one saying this.
Tweetmeme uses Backtype data, right? (At least when used through Posterous it seems to.)
Also, on Twitter's blog, it says Tweetmeme is now "pointing" to the Twitter button. But it's not totally, otherwise we couldn't get our counts like we are.
We (BackType) don't power Tweetmeme's button — we offer our own, more accurate one. The counts we do are also available via our API, which powers Posterous' button.
can someone explain the "business arrangement" they made with tweetmeme? will tweetmeme get their data in exchange for showing them how to build this? (they say the new code is 100% original to twitter though)....
also curious as to why twitter didn't BUY tweetmeme.
Man, this was a long time coming - but I do hope twitter will embed links smartly - as in a la facebook style preview of a page snippet or play youtube from twitter itself.
It's called a bookmarklet, and it's been around for years, and lets you share on any site, not just one(s) the website has considered it worth their time to integrate with.
There are existing 3rd party browser extensions that do this, in any case your average internet user does not use browser extensions or even know what they are.
As an extreme example, I find http://t.co/gpRQitG less informative than http://youtu.be/oHg5SJYRHA0. If your site is still only at 3 characters ID, unlike Youtube, having a custom shortened domain from which users can tell what it is, generally, what they're clicking on, is a much better user experience than using a universal shortener which says nothing about the content.