I agree, the API does make it very easy to never see the t.co links, but for
those of us on the website (particularly 'old' twitter) it can be a pain.
I totally get that Twitter want to make their own shortener, and the 'new'
twitter website does at least show the domain to where links go, but I just
really wish they had the same info '+' pages which bit.ly urls have too.
The lack of these features only serves to make us feel like we're giving
them the data without getting the info on the traffic etc. - aside from the
obfuscation issue.
K
On 11 June 2011 02:12, Tom van der Woerdt i...@tvdw.eu wrote:
What they do in the background is irrelevant for the general public and
for the purpose of this discussion.
I very much disagree on that it's not relevant. If Twitter clients
implement t.co properly, it's nothing more than a background process. I
haven't seen a t.co link in days, as I finally implemented automatic
unshortening of t.co links in my client - just like a lot of other clients
do.
If a link gets automatically unshortened on display, it's effectively
nothing more than a background process.
Tom
On 6/11/11 3:03 AM, Mo wrote:
The shortened links I originally saw were all in HootSuite. I've since
logged out and logged back in and the T.CO shortened URLs went away.
However, my original question was never answered. Is there a process
for getting on a list of approved shortened URLs?
Ben, your screenshot and the tweet page do not have the same content
in the mouseover.
John, you're smoking something. I just checked Google, Facebook, Bing,
and Yahoo with a search of the term PHP. None of the exposed URLs are
shortened. What they do in the background is irrelevant for the
general public and for the purpose of this discussion.
Kosso, I'm with you on the unexpected destinations.
In short, whoever is in control at Twitter is either not in direct
communication with users and developers in regard to this or is simply
not listening.
-Mo
On Jun 10, 2:23 pm, Ben Wardbenw...@twitter.com wrote:
On Jun 10, 2011, at 1:21 PM, Kosso wrote:
The massive trouble I have with all this is that I like to know what the
hell I'm clicking on before clicking a link.
It's kind of my right as a citizen of the web.
I personally can't stand it when, for example a link fires up iTunes or
goes
to some site I don't want to waste (possibly mobile and limited)
bandwidth
on. I like to choose WHO I give MY visit/traffic to.
To be clear, the API returns all the information for all clients to
display the original short URL, and navigate via t.co. We also look up
the full destination URL and return that too, allowing even clearer
navigation of where you as a user will end up when following a link. You can
see this implemented on twitter.com today:
https://twitter.com/joshtpm/status/79283124747501568
* The URL destination points to t.co
* The displayed text of the URL is a cropped and shortened version of the
real URL
* The title (tooltip) of the URL displays the full address of the
destination.
I've further illustrated it with a screenshot here:
https://skitch.com/benward/frff8/
The documentation for the URL entities that provide all of this
information in the API response is here:
http://dev.twitter.com/pages/tweet_entities
Ben
--
Platform Developer, Twitter
--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker:
https://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
https://groups.google.com/forum/#!forum/twitter-development-talk
--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
https://groups.google.com/forum/#!forum/twitter-development-talk
