Re: [twitter-dev] consistency and ecosystem opportunities

[Lil Peck]

> With this in mind, we’ve updated our Terms of Service:
> http://dev.twitter.com/pages/api_terms.
> The Opportunity for Developers
> Developers have told us that they’d like more guidance from us about the
> best opportunities to build on Twitter.  More specifically, developers ask
> us if they should build client apps that mimic or reproduce the mainstream
> Twitter consumer client experience.  The answer is no.
>

Reviewing the API TOS at http://dev.twitter.com/pages/api_terms, it
seems to be more generously worded than was Ryan's post.

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] consistency and ecosystem opportunities

[Raffi Krikorian]

Agreed.



On Mar 13, 2011, at 4:58, Scott Wilcox  wrote:

> Providing you don't participate in any spamming, I would think your 
> application is perfectly safe.
> 
> On 13 Mar 2011, at 11:51, Dustin Lennon wrote:
> 
>> I guess what I would like to know is since I'm a hobbyist, am I going to get 
>> my token revoked just because I write a client that is just for my use to 
>> better my skills in learning a specific programming language and share with 
>> others things I've learned.
>> 
>> -Dustin
>> This message contains confidential information and is intended only for the 
>> individual named. If you are not the named addressee you should not 
>> disseminate, distribute or copy this e-mail. Please notify the sender 
>> immediately by e-mail if you have received this e-mail by mistake and delete 
>> this e-mail from your system. E-mail transmission cannot be guaranteed to be 
>> secure or error-free as information could be intercepted, corrupted, lost, 
>> destroyed, arrive late or incomplete, or contain viruses. The sender 
>> therefore does not accept liability for any errors or omissions in the 
>> contents of this message, which arise as a result of e-mail transmission.
>> 
>> 
>> On Sun, Mar 13, 2011 at 1:22 AM, Rich  wrote:
>> Hi Raffi
>> 
>> So if I'm reading what you wrote correctly, simple clients that just
>> display a timeline, post etc are thinking too small and there is no
>> business there, something I can agree with.
>> 
>> However many of us have, what I'd call a value added client.  Sure we
>> have the basics of a client, but we have what I'd like to think are
>> added value services such as tweet scheduling, augmented reality of
>> tweeters around you, user streams, draft management, and so much more.
>> Are we to think that these are actually going to be fine for the time
>> being, so long as obviously we comply with the ToS.
>> 
>> What you guys seem to be saying though is don't build clients because
>> it won't make money, but some people seem to fail to grasp some of us
>> develop apps like this because we enjoy it... it's a hobby and a
>> passion and that doesn't always involve tons of profit. Services such
>> as Seesmic started out in the simple Client business, remember Twhirl,
>> etc. Sure they grew into something enterprise, but most of us start
>> out at the bottom and with the basics.
>> 
>> Richard
>> 
>> On Mar 13, 2:39 am, Raffi Krikorian  wrote:
>> > in reading your blog post, i think you're misunderstanding what
>> > @*rsarver*wrote.
>> >
>> > the API is open -- i personally love seeing all the innovation around
>> > getting content into twitter (/1/status/update).  there is a cafe in france
>> > who's oven tweets whenever its done baking.  that uses the platform to get
>> > content in there.  there was a NYU project that enabled your plants to 
>> > tweet
>> > when they needed water.  that uses the platform to get content into 
>> > twitter.
>> >   then there are people who match tweets to context.  seeing twitter in
>> > action with a television show, or a newspaper article, or a conference, or 
>> > a
>> > band -- that's how people really understand and get twitter.  they see it
>> > through the lens of what's happening in the world.
>> >
>> > what @*rsarver* said, effectively, was building a business around
>> > *simply*rendering
>> > /1/statuses/home_timeline was probably-not-the-best-thing-to-do.  please go
>> > still innovate.  just don't bet money on simply making an API call to
>> > grabbing a user's home_timeline and rendering it.  that's thinking too
>> > small, and @*rsarver* is telling you that.
>> >
>> > On Sat, Mar 12, 2011 at 4:29 PM, Shannon Whitley
>> > wrote:
>> >
>> > > I was hoping that Ryan was just a few weeks early for his April Fools'
>> > > post.
>> >
>> > > "Don't build clients?"  It sounds like a bad joke.
>> >
>> > > I wrote a letter to Ryan on my blog in response to this post:
>> >
>> > >http://www.voiceoftech.com/swhitley/index.php/2011/03/a-letter-to-rya...
>> >
>> > > I know you guys can't be serious about this.  Stage a mutiny if you
>> > > have to, but don't let this boneheaded decision stand.
>> >
>> > --
>> > Raffi Krikorian
>> > Twitter, Application Serviceshttp://twitter.com/raffi
>> 
>> --
>> Twitter developer documentation and resources: http://dev.twitter.com/doc
>> API updates via Twitter: http://twitter.com/twitterapi
>> Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
>> Change your membership to this group: 
>> http://groups.google.com/group/twitter-development-talk
>> 
>> 
>> -- 
>> Twitter developer documentation and resources: http://dev.twitter.com/doc
>> API updates via Twitter: http://twitter.com/twitterapi
>> Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
>> Change your membership to this group: 
>> http://groups.google.com/group/twitter-development-talk
> 
> -- 
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twit

Re: [twitter-dev] consistency and ecosystem opportunities

[Scott Wilcox]

Providing you don't participate in any spamming, I would think your application 
is perfectly safe.

On 13 Mar 2011, at 11:51, Dustin Lennon wrote:

> I guess what I would like to know is since I'm a hobbyist, am I going to get 
> my token revoked just because I write a client that is just for my use to 
> better my skills in learning a specific programming language and share with 
> others things I've learned.
> 
> -Dustin
> This message contains confidential information and is intended only for the 
> individual named. If you are not the named addressee you should not 
> disseminate, distribute or copy this e-mail. Please notify the sender 
> immediately by e-mail if you have received this e-mail by mistake and delete 
> this e-mail from your system. E-mail transmission cannot be guaranteed to be 
> secure or error-free as information could be intercepted, corrupted, lost, 
> destroyed, arrive late or incomplete, or contain viruses. The sender 
> therefore does not accept liability for any errors or omissions in the 
> contents of this message, which arise as a result of e-mail transmission.
> 
> 
> On Sun, Mar 13, 2011 at 1:22 AM, Rich  wrote:
> Hi Raffi
> 
> So if I'm reading what you wrote correctly, simple clients that just
> display a timeline, post etc are thinking too small and there is no
> business there, something I can agree with.
> 
> However many of us have, what I'd call a value added client.  Sure we
> have the basics of a client, but we have what I'd like to think are
> added value services such as tweet scheduling, augmented reality of
> tweeters around you, user streams, draft management, and so much more.
> Are we to think that these are actually going to be fine for the time
> being, so long as obviously we comply with the ToS.
> 
> What you guys seem to be saying though is don't build clients because
> it won't make money, but some people seem to fail to grasp some of us
> develop apps like this because we enjoy it... it's a hobby and a
> passion and that doesn't always involve tons of profit. Services such
> as Seesmic started out in the simple Client business, remember Twhirl,
> etc. Sure they grew into something enterprise, but most of us start
> out at the bottom and with the basics.
> 
> Richard
> 
> On Mar 13, 2:39 am, Raffi Krikorian  wrote:
> > in reading your blog post, i think you're misunderstanding what
> > @*rsarver*wrote.
> >
> > the API is open -- i personally love seeing all the innovation around
> > getting content into twitter (/1/status/update).  there is a cafe in france
> > who's oven tweets whenever its done baking.  that uses the platform to get
> > content in there.  there was a NYU project that enabled your plants to tweet
> > when they needed water.  that uses the platform to get content into twitter.
> >   then there are people who match tweets to context.  seeing twitter in
> > action with a television show, or a newspaper article, or a conference, or a
> > band -- that's how people really understand and get twitter.  they see it
> > through the lens of what's happening in the world.
> >
> > what @*rsarver* said, effectively, was building a business around
> > *simply*rendering
> > /1/statuses/home_timeline was probably-not-the-best-thing-to-do.  please go
> > still innovate.  just don't bet money on simply making an API call to
> > grabbing a user's home_timeline and rendering it.  that's thinking too
> > small, and @*rsarver* is telling you that.
> >
> > On Sat, Mar 12, 2011 at 4:29 PM, Shannon Whitley
> > wrote:
> >
> > > I was hoping that Ryan was just a few weeks early for his April Fools'
> > > post.
> >
> > > "Don't build clients?"  It sounds like a bad joke.
> >
> > > I wrote a letter to Ryan on my blog in response to this post:
> >
> > >http://www.voiceoftech.com/swhitley/index.php/2011/03/a-letter-to-rya...
> >
> > > I know you guys can't be serious about this.  Stage a mutiny if you
> > > have to, but don't let this boneheaded decision stand.
> >
> > --
> > Raffi Krikorian
> > Twitter, Application Serviceshttp://twitter.com/raffi
> 
> --
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group: 
> http://groups.google.com/group/twitter-development-talk
> 
> 
> -- 
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group: 
> http://groups.google.com/group/twitter-development-talk

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter

Re: [twitter-dev] consistency and ecosystem opportunities

[Umashankar Das]

It has got to do with the nature of the way content is used. We will also
have 'reply' to respond to the user. But, 'Discuss' is there to allow
discussion on a certain topic.

Imagine the context of the earthquake in Japan. Some user wants to know
about facilities being provided by relief agencies in Tokyo. The discussion
will be useful for a group of people who reference a particular tweet.

Regards
Umashankar Das

On Sun, Mar 13, 2011 at 9:51 AM, Raffi Krikorian  wrote:

> why would you need a brand new verb?  what's wrong with "reply"?
>
>
> On Fri, Mar 11, 2011 at 8:40 PM, Umashankar Das 
> wrote:
>
>> Dear Ryan,
>>A very direct question. Is it being said that I cannot associate a
>> brand new field like 'Discuss' with a tweet in my website?
>> Regards
>> Umashankar Das
>>
>>
>> On Sat, Mar 12, 2011 at 1:48 AM, Ryan Sarver  wrote:
>>
>>> Hey all, I’d like to give you an update about the state of the Twitter
>>> Platform and hopefully provide some much requested guidance.
>>>
>>> Since this time last year, Twitter use has skyrocketed.  We’ve grown from
>>> 48 million to 140 million tweets a day and we’re registering new accounts at
>>> an all-time record.  This massive base of users, publishers, and businesses
>>> is a giant playground for developers to build their own businesses on, and
>>> this means the opportunity has grown for everyone.
>>>
>>> With more people joining Twitter and accessing the service in multiple
>>> ways, a consistent user experience is more crucial than ever.  As we talked
>>> about last April, this was our motivation for buying Tweetie and developing
>>> our own official iPhone app.  It is the reason why we have developed
>>> official apps for the Mac, iPad, Android and Windows Phone, and worked with
>>> RIM on their Twitter for Blackberry app. As a result, the top five ways that
>>> people access Twitter are official Twitter apps.
>>>
>>> Still, our user research shows that consumers continue to be confused by
>>> the different ways that a fractured landscape of third-party Twitter clients
>>> display tweets and let users interact with core Twitter functions.  For
>>> example, people get confused by websites or clients that display tweets in a
>>> way that doesn’t follow our design guidelines, or when services put their
>>> own verbs on tweets instead of the ones used on Twitter.  Similarly, a
>>> number of third-party consumer clients use their own versions of suggested
>>> users, trends, and other data streams, confusing users in our network even
>>> more.  Users should be able to view, retweet, and reply to @nytimes’ tweets
>>> the same way; see the same profile information about @whitehouse; and be
>>> able to join in the discussion around the same trending topics as everyone
>>> else across Twitter.
>>>
>>> *A Consistent User Experience*
>>> Twitter is a network, and its network effects are driven by users seeing
>>> and contributing to the network’s conversations.  We need to ensure users
>>> can interact with Twitter the same way everywhere.  Specifically:
>>>  - *The mainstream consumer client experience*.  Twitter will provide
>>> the primary mainstream consumer client experience on phones, computers, and
>>> other devices by which millions of people access Twitter content (tweets,
>>> trends, profiles, etc.), and send tweets.  If there are too many ways to use
>>> Twitter that are inconsistent with one another, we risk diffusing the user
>>> experience.  In addition, a number of client applications have repeatedly
>>> violated Twitter’s Terms of Service, including our user privacy policy.
>>>  This demonstrates the risks associated with outsourcing the Twitter user
>>> experience to third parties.  Twitter has to revoke literally hundreds of
>>> API tokens / apps a week as part of our trust and safety efforts, in order
>>> to protect the user experience on our platform.
>>>  - *Display of tweets in 3rd-party services*. We need to ensure that
>>> tweets, and tweet actions, are rendered in a consistent way so that people
>>> have the same experience with tweets no matter where they are.   For
>>> example, some developers display “comment”, “like”, or other terms with
>>> tweets instead of  “follow, favorite, retweet, reply” - thus changing the
>>> core functions of a tweet.
>>>
>>> With this in mind, we’ve updated our Terms of Service:
>>> http://dev.twitter.com/pages/api_terms.
>>>
>>> *The Opportunity for Developers*
>>> Developers have told us that they’d like more guidance from us about the
>>> best opportunities to build on Twitter.  More specifically, developers ask
>>> us if they should build client apps that mimic or reproduce the mainstream
>>> Twitter consumer client experience.  The answer is no.
>>>
>>> If you are an existing developer of client apps, you can continue to
>>> serve your user base, but we will be holding you to high standards to ensure
>>> you do not violate users’ privacy, that you provide consistency in the user
>>> experience, and that

Re: [twitter-dev] consistency and ecosystem opportunities

[Raffi Krikorian]

why would you need a brand new verb?  what's wrong with "reply"?

On Fri, Mar 11, 2011 at 8:40 PM, Umashankar Das wrote:

> Dear Ryan,
>A very direct question. Is it being said that I cannot associate a brand
> new field like 'Discuss' with a tweet in my website?
> Regards
> Umashankar Das
>
>
> On Sat, Mar 12, 2011 at 1:48 AM, Ryan Sarver  wrote:
>
>> Hey all, I’d like to give you an update about the state of the Twitter
>> Platform and hopefully provide some much requested guidance.
>>
>> Since this time last year, Twitter use has skyrocketed.  We’ve grown from
>> 48 million to 140 million tweets a day and we’re registering new accounts at
>> an all-time record.  This massive base of users, publishers, and businesses
>> is a giant playground for developers to build their own businesses on, and
>> this means the opportunity has grown for everyone.
>>
>> With more people joining Twitter and accessing the service in multiple
>> ways, a consistent user experience is more crucial than ever.  As we talked
>> about last April, this was our motivation for buying Tweetie and developing
>> our own official iPhone app.  It is the reason why we have developed
>> official apps for the Mac, iPad, Android and Windows Phone, and worked with
>> RIM on their Twitter for Blackberry app. As a result, the top five ways that
>> people access Twitter are official Twitter apps.
>>
>> Still, our user research shows that consumers continue to be confused by
>> the different ways that a fractured landscape of third-party Twitter clients
>> display tweets and let users interact with core Twitter functions.  For
>> example, people get confused by websites or clients that display tweets in a
>> way that doesn’t follow our design guidelines, or when services put their
>> own verbs on tweets instead of the ones used on Twitter.  Similarly, a
>> number of third-party consumer clients use their own versions of suggested
>> users, trends, and other data streams, confusing users in our network even
>> more.  Users should be able to view, retweet, and reply to @nytimes’ tweets
>> the same way; see the same profile information about @whitehouse; and be
>> able to join in the discussion around the same trending topics as everyone
>> else across Twitter.
>>
>> *A Consistent User Experience*
>> Twitter is a network, and its network effects are driven by users seeing
>> and contributing to the network’s conversations.  We need to ensure users
>> can interact with Twitter the same way everywhere.  Specifically:
>>  - *The mainstream consumer client experience*.  Twitter will provide the
>> primary mainstream consumer client experience on phones, computers, and
>> other devices by which millions of people access Twitter content (tweets,
>> trends, profiles, etc.), and send tweets.  If there are too many ways to use
>> Twitter that are inconsistent with one another, we risk diffusing the user
>> experience.  In addition, a number of client applications have repeatedly
>> violated Twitter’s Terms of Service, including our user privacy policy.
>>  This demonstrates the risks associated with outsourcing the Twitter user
>> experience to third parties.  Twitter has to revoke literally hundreds of
>> API tokens / apps a week as part of our trust and safety efforts, in order
>> to protect the user experience on our platform.
>>  - *Display of tweets in 3rd-party services*. We need to ensure that
>> tweets, and tweet actions, are rendered in a consistent way so that people
>> have the same experience with tweets no matter where they are.   For
>> example, some developers display “comment”, “like”, or other terms with
>> tweets instead of  “follow, favorite, retweet, reply” - thus changing the
>> core functions of a tweet.
>>
>> With this in mind, we’ve updated our Terms of Service:
>> http://dev.twitter.com/pages/api_terms.
>>
>> *The Opportunity for Developers*
>> Developers have told us that they’d like more guidance from us about the
>> best opportunities to build on Twitter.  More specifically, developers ask
>> us if they should build client apps that mimic or reproduce the mainstream
>> Twitter consumer client experience.  The answer is no.
>>
>> If you are an existing developer of client apps, you can continue to serve
>> your user base, but we will be holding you to high standards to ensure you
>> do not violate users’ privacy, that you provide consistency in the user
>> experience, and that you rigorously adhere to all areas of our Terms of
>> Service.  We have spoken with the major client applications in the Twitter
>> ecosystem about these needs on an ongoing basis, and will continue to ensure
>> a high bar is maintained.
>>
>> As we point out above, we need to move to a less fragmented world, where
>> every user can experience Twitter in a consistent way.  This is already
>> happening organically - the number and market share of consumer client apps
>> that are not owned or operated by Twitter has been shrinking.  According to
>> our data,

Re: [twitter-dev] consistency and ecosystem opportunities

[Adam Green]

They should insert ads into the stream, and say we can't remove them. That
would be great. I have no problem with that, providing they treat us with
respect. Give us an appeal process with warning if they don't like what we
build. I have no problem with them wanting to make money from things I
build. I want to make money from things they give me. I want everyone to
make money.

Developers are not the problem. They are the solution. I can't help thinking
there are people at high levels who sit around saying "How do we shake off
these damned parasites?" If I'm wrong, maybe we can see a message from
management that says "Here is a new initiative or dev program that will help
you make money with the API. We love what you guys do so much we want to
reward you. We want you to be part of a partnership."

That would be refreshing.

On Sat, Mar 12, 2011 at 7:59 PM, Ellsass  wrote:

> Scott, I don't think it's ludicrous to think that Twitter may
> eventually pull the plug on, say, statuses/home_timeline, effectively
> eliminating clients.
>
> If Twitter's concern is ad revenue, all they'd need to do is add a
> clause to their TOS specifying that all third-party clients must show
> in-line ads or the quickbar or whatever else Twitter uses to generate
> revenue. Then the issue is very clear for developers -- either
> integrate Twitter's revenue-producing content into your client, or
> don't make a client at all.
>
> The fact that they seem to be going about this a different way, and
> being a bit unclear as to what might happen to a client-only app,
> leaves open the possibility that they simply want to close down the
> market so the only access to one's timeline is via a first-party app.
>
>
>
> Scott Wilcox wrote:
> > Hello,
> >
> > For a few days now I've read what people have said in reply to the update
> from Ryan. There are some crazy reactions and responses to what Ryan has
> said. In essence, the entire reaction is my opinion is completely overblown.
> >
> > Not in any sense what-so-ever have Twitter said that you can no longer
> post updates on behalf of users. Its ludicrous to suggest so. What they have
> have said (and in my opinion - quite clearly) is that it is better to direct
> your time and effort into a product that is not just a simple client and
> does more than just provide viewing and posting of tweets. There are so many
> half-arsed clients out there that do little more than just show and post
> tweets. If by chance a user was to use these low grade applications as their
> first experience of Twitter, it would probably put them off using it in the
> long term.
> >
> > I do fully believe that is why they have released their own branded
> clients for iOS, Macs and other devices. It provides a consistent experience
> for the end-users.
> >
> > The other thing that people seem to completely overlook is that Twitter
> are providing a freely accessible API at no charge to developers. It pains
> me to see so many developers standing the moral high ground. If you were
> paying for access to a service or product and it changes, you have a very
> valid reason to complain. To complain about a service provided free of
> charge for you to use at the end of the day frustrates me to no end. No
> single developer has a god given right to have access to the API, perhaps
> that should be remembered.
> >
> > Scott.
> >
> > On 13 Mar 2011, at 00:16, Adam Green wrote:
> >
> > > Interesting that neither Ryan or anyone else from Twitter has replied
> once to any of the questions here, (way to go on showing your interest in
> the developer community, Ryan),  so I'll address this question to everyone
> else in the group. I don't read Ryan's message as demanding that apps are no
> longer allowed to send tweets on behalf of users. Is that supposed to be
> what he said? I think he is saying that apps should be more than *just*
> clients that let you read and post tweets. How to tell the difference, I
> have no idea, but I think in Ryan's mind there is a difference.
> > >
> > > I'll ask it as clearly as I can. Is it still allowed for an app to
> accept a tweet from a user and post it into their account?
> > >
> > > Is the /statuses/update api call still allowed in an app?
> > >
> > > Let's not wait for Twitter to respond, since they clearly don't want to
> any longer. Let's try and figure this out ourselves. What does everyone
> think? Can apps still send tweets?
> > >
> > > If yes, there is still a market for Twitter API developers. If not, the
> Twitter API is over. It is that simple.
> > >
> > > Maybe Ryan or anyone from Twitter can also find the time to answer
> this.
> > >
> > > On Sat, Mar 12, 2011 at 6:45 PM, Duane Roelands <
> duane.roela...@gmail.com> wrote:
> > > Wow.  "Thanks for getting so many people interested in Twitter.  Now
> > > get lost."
> > >
> > > This is appalling.
> > >
> > > --
> > > Twitter developer documentation and resources:
> http://dev.twitter.com/doc
> > > API updates via Twitter: http://twit

Re: [twitter-dev] consistency and ecosystem opportunities

[Scott Wilcox]

Highly doubtful that they would do that and they certainly haven't now.

Sent from my iPhone

On 13 Mar 2011, at 01:00, "Ellsass"  wrote:

> Scott, I don't think it's ludicrous to think that Twitter may
> eventually pull the plug on, say, statuses/home_timeline, effectively
> eliminating clients.
> 
> If Twitter's concern is ad revenue, all they'd need to do is add a
> clause to their TOS specifying that all third-party clients must show
> in-line ads or the quickbar or whatever else Twitter uses to generate
> revenue. Then the issue is very clear for developers -- either
> integrate Twitter's revenue-producing content into your client, or
> don't make a client at all.
> 
> The fact that they seem to be going about this a different way, and
> being a bit unclear as to what might happen to a client-only app,
> leaves open the possibility that they simply want to close down the
> market so the only access to one's timeline is via a first-party app.
> 
> 
> 
> Scott Wilcox wrote:
>> Hello,
>> 
>> For a few days now I've read what people have said in reply to the update 
>> from Ryan. There are some crazy reactions and responses to what Ryan has 
>> said. In essence, the entire reaction is my opinion is completely overblown.
>> 
>> Not in any sense what-so-ever have Twitter said that you can no longer post 
>> updates on behalf of users. Its ludicrous to suggest so. What they have have 
>> said (and in my opinion - quite clearly) is that it is better to direct your 
>> time and effort into a product that is not just a simple client and does 
>> more than just provide viewing and posting of tweets. There are so many 
>> half-arsed clients out there that do little more than just show and post 
>> tweets. If by chance a user was to use these low grade applications as their 
>> first experience of Twitter, it would probably put them off using it in the 
>> long term.
>> 
>> I do fully believe that is why they have released their own branded clients 
>> for iOS, Macs and other devices. It provides a consistent experience for the 
>> end-users.
>> 
>> The other thing that people seem to completely overlook is that Twitter are 
>> providing a freely accessible API at no charge to developers. It pains me to 
>> see so many developers standing the moral high ground. If you were paying 
>> for access to a service or product and it changes, you have a very valid 
>> reason to complain. To complain about a service provided free of charge for 
>> you to use at the end of the day frustrates me to no end. No single 
>> developer has a god given right to have access to the API, perhaps that 
>> should be remembered.
>> 
>> Scott.
>> 
>> On 13 Mar 2011, at 00:16, Adam Green wrote:
>> 
>>> Interesting that neither Ryan or anyone else from Twitter has replied once 
>>> to any of the questions here, (way to go on showing your interest in the 
>>> developer community, Ryan),  so I'll address this question to everyone else 
>>> in the group. I don't read Ryan's message as demanding that apps are no 
>>> longer allowed to send tweets on behalf of users. Is that supposed to be 
>>> what he said? I think he is saying that apps should be more than *just* 
>>> clients that let you read and post tweets. How to tell the difference, I 
>>> have no idea, but I think in Ryan's mind there is a difference.
>>> 
>>> I'll ask it as clearly as I can. Is it still allowed for an app to accept a 
>>> tweet from a user and post it into their account?
>>> 
>>> Is the /statuses/update api call still allowed in an app?
>>> 
>>> Let's not wait for Twitter to respond, since they clearly don't want to any 
>>> longer. Let's try and figure this out ourselves. What does everyone think? 
>>> Can apps still send tweets?
>>> 
>>> If yes, there is still a market for Twitter API developers. If not, the 
>>> Twitter API is over. It is that simple.
>>> 
>>> Maybe Ryan or anyone from Twitter can also find the time to answer this.
>>> 
>>> On Sat, Mar 12, 2011 at 6:45 PM, Duane Roelands  
>>> wrote:
>>> Wow.  "Thanks for getting so many people interested in Twitter.  Now
>>> get lost."
>>> 
>>> This is appalling.
>>> 
>>> --
>>> Twitter developer documentation and resources: http://dev.twitter.com/doc
>>> API updates via Twitter: http://twitter.com/twitterapi
>>> Issues/Enhancements Tracker: 
>>> http://code.google.com/p/twitter-api/issues/list
>>> Change your membership to this group: 
>>> http://groups.google.com/group/twitter-development-talk
>>> 
>>> 
>>> 
>>> --
>>> Adam Green
>>> Twitter API Consultant and Trainer
>>> http://140dev.com
>>> @140dev
>>> 
>>> --
>>> Twitter developer documentation and resources: http://dev.twitter.com/doc
>>> API updates via Twitter: http://twitter.com/twitterapi
>>> Issues/Enhancements Tracker: 
>>> http://code.google.com/p/twitter-api/issues/list
>>> Change your membership to this group: 
>>> http://groups.google.com/group/twitter-development-talk
> 
> -- 
> Twitter developer documentation and resources: http://dev.twitter.com/d

Re: [twitter-dev] consistency and ecosystem opportunities

[Ellsass]

Scott, I don't think it's ludicrous to think that Twitter may
eventually pull the plug on, say, statuses/home_timeline, effectively
eliminating clients.

If Twitter's concern is ad revenue, all they'd need to do is add a
clause to their TOS specifying that all third-party clients must show
in-line ads or the quickbar or whatever else Twitter uses to generate
revenue. Then the issue is very clear for developers -- either
integrate Twitter's revenue-producing content into your client, or
don't make a client at all.

The fact that they seem to be going about this a different way, and
being a bit unclear as to what might happen to a client-only app,
leaves open the possibility that they simply want to close down the
market so the only access to one's timeline is via a first-party app.



Scott Wilcox wrote:
> Hello,
>
> For a few days now I've read what people have said in reply to the update 
> from Ryan. There are some crazy reactions and responses to what Ryan has 
> said. In essence, the entire reaction is my opinion is completely overblown.
>
> Not in any sense what-so-ever have Twitter said that you can no longer post 
> updates on behalf of users. Its ludicrous to suggest so. What they have have 
> said (and in my opinion - quite clearly) is that it is better to direct your 
> time and effort into a product that is not just a simple client and does more 
> than just provide viewing and posting of tweets. There are so many half-arsed 
> clients out there that do little more than just show and post tweets. If by 
> chance a user was to use these low grade applications as their first 
> experience of Twitter, it would probably put them off using it in the long 
> term.
>
> I do fully believe that is why they have released their own branded clients 
> for iOS, Macs and other devices. It provides a consistent experience for the 
> end-users.
>
> The other thing that people seem to completely overlook is that Twitter are 
> providing a freely accessible API at no charge to developers. It pains me to 
> see so many developers standing the moral high ground. If you were paying for 
> access to a service or product and it changes, you have a very valid reason 
> to complain. To complain about a service provided free of charge for you to 
> use at the end of the day frustrates me to no end. No single developer has a 
> god given right to have access to the API, perhaps that should be remembered.
>
> Scott.
>
> On 13 Mar 2011, at 00:16, Adam Green wrote:
>
> > Interesting that neither Ryan or anyone else from Twitter has replied once 
> > to any of the questions here, (way to go on showing your interest in the 
> > developer community, Ryan),  so I'll address this question to everyone else 
> > in the group. I don't read Ryan's message as demanding that apps are no 
> > longer allowed to send tweets on behalf of users. Is that supposed to be 
> > what he said? I think he is saying that apps should be more than *just* 
> > clients that let you read and post tweets. How to tell the difference, I 
> > have no idea, but I think in Ryan's mind there is a difference.
> >
> > I'll ask it as clearly as I can. Is it still allowed for an app to accept a 
> > tweet from a user and post it into their account?
> >
> > Is the /statuses/update api call still allowed in an app?
> >
> > Let's not wait for Twitter to respond, since they clearly don't want to any 
> > longer. Let's try and figure this out ourselves. What does everyone think? 
> > Can apps still send tweets?
> >
> > If yes, there is still a market for Twitter API developers. If not, the 
> > Twitter API is over. It is that simple.
> >
> > Maybe Ryan or anyone from Twitter can also find the time to answer this.
> >
> > On Sat, Mar 12, 2011 at 6:45 PM, Duane Roelands  
> > wrote:
> > Wow.  "Thanks for getting so many people interested in Twitter.  Now
> > get lost."
> >
> > This is appalling.
> >
> > --
> > Twitter developer documentation and resources: http://dev.twitter.com/doc
> > API updates via Twitter: http://twitter.com/twitterapi
> > Issues/Enhancements Tracker: 
> > http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group: 
> > http://groups.google.com/group/twitter-development-talk
> >
> >
> >
> > --
> > Adam Green
> > Twitter API Consultant and Trainer
> > http://140dev.com
> > @140dev
> >
> > --
> > Twitter developer documentation and resources: http://dev.twitter.com/doc
> > API updates via Twitter: http://twitter.com/twitterapi
> > Issues/Enhancements Tracker: 
> > http://code.google.com/p/twitter-api/issues/list
> > Change your membership to this group: 
> > http://groups.google.com/group/twitter-development-talk

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] consistency and ecosystem opportunities

[Ryan Sarver]

Adam, that is a totally incorrect characterization of the companies I listed
in the email. A ton of those companies -- CoTweet, Klout, HootSuite,
Socialflow -- sprung out of the ecosystem and were started on nights and
weekends with no funding. Of course they have gotten some funding now as
investors see them as great potential businesses.

Of course statuses/update is still allowed. As is statuses/user_timeline.
We've added more policies and given guidance that we don't think there is a
business in building consumer clients, but none of the APIs have changed.

--
Ryan Sarver
@rsarver 



On Sun, Mar 13, 2011 at 12:40 AM, Adam Green <140...@gmail.com> wrote:

> I agree, Scott. Ryan didn't say you can't post tweets, but everyone heard
> that. Every tech blog repeated it. Ryan should take a minute and explain
> that it isn't true. That much would help a lot. He led by saying don't build
> a client. That is where people stopped reading.
>
> I don't think he meant to tell people that apps can't tweet, but he did
> give that impression. Now he should come back and say, "Sorry guys. I gave
> you the wrong impression. Here are specifically the things you can still
> do." Don't just point to companies with $10M in VC funds each and say "No
> problem, just be like them."
>
> These are API developers. Say it in terms of the API. Exactly which API
> calls are still allowed. If he says statuses/update is still allowed, then
> that answers the question. There is no ambiguity.
>
> As for Twitter being free. Yes. The API is, but denying the value that
> products like Tweetdeck gave Twitter *for free* is denying the reality of
> how Twitter got to where it is. It is called a partnership. They give us raw
> materials, we add value to them. We all benefit.
>
> On Sat, Mar 12, 2011 at 7:28 PM, Scott Wilcox  wrote:
>
>> Hello,
>>
>> For a few days now I've read what people have said in reply to the update
>> from Ryan. There are some crazy reactions and responses to what Ryan has
>> said. In essence, the entire reaction is my opinion is completely overblown.
>>
>> Not in any sense what-so-ever have Twitter said that you can no longer
>> post updates on behalf of users. Its ludicrous to suggest so. What they have
>> have said (and in my opinion - quite clearly) is that it is better to direct
>> your time and effort into a product that is not just a simple client and
>> does more than just provide viewing and posting of tweets. There are so many
>> half-arsed clients out there that do little more than just show and post
>> tweets. If by chance a user was to use these low grade applications as their
>> first experience of Twitter, it would probably put them off using it in the
>> long term.
>>
>> I do fully believe that is why they have released their own branded
>> clients for iOS, Macs and other devices. It provides a consistent experience
>> for the end-users.
>>
>> The other thing that people seem to completely overlook is that Twitter
>> are providing a freely accessible API at no charge to developers. It pains
>> me to see so many developers standing the moral high ground. If you were
>> paying for access to a service or product and it changes, you have a very
>> valid reason to complain. To complain about a service provided free of
>> charge for you to use at the end of the day frustrates me to no end. No
>> single developer has a god given right to have access to the API, perhaps
>> that should be remembered.
>>
>> Scott.
>>
>> On 13 Mar 2011, at 00:16, Adam Green wrote:
>>
>> Interesting that neither Ryan or anyone else from Twitter has replied once
>> to any of the questions here, (way to go on showing your interest in the
>> developer community, Ryan),  so I'll address this question to everyone else
>> in the group. I don't read Ryan's message as demanding that apps are no
>> longer allowed to send tweets on behalf of users. Is that supposed to be
>> what he said? I think he is saying that apps should be more than *just*
>> clients that let you read and post tweets. How to tell the difference, I
>> have no idea, but I think in Ryan's mind there is a difference.
>>
>> I'll ask it as clearly as I can. Is it still allowed for an app to accept
>> a tweet from a user and post it into their account?
>>
>> Is the /statuses/update api call still allowed in an app?
>>
>> Let's not wait for Twitter to respond, since they clearly don't want to
>> any longer. Let's try and figure this out ourselves. What does everyone
>> think? Can apps still send tweets?
>>
>> If yes, there is still a market for Twitter API developers. If not, the
>> Twitter API is over. It is that simple.
>>
>> Maybe Ryan or anyone from Twitter can also find the time to answer this.
>>
>> On Sat, Mar 12, 2011 at 6:45 PM, Duane Roelands > > wrote:
>>
>>> Wow.  "Thanks for getting so many people interested in Twitter.  Now
>>> get lost."
>>>
>>> This is appalling.
>>>
>>> --
>>> Twitter developer documentation and resources:
>>> http:/

Re: [twitter-dev] consistency and ecosystem opportunities

[Adam Green]

I agree, Scott. Ryan didn't say you can't post tweets, but everyone heard
that. Every tech blog repeated it. Ryan should take a minute and explain
that it isn't true. That much would help a lot. He led by saying don't build
a client. That is where people stopped reading.

I don't think he meant to tell people that apps can't tweet, but he did give
that impression. Now he should come back and say, "Sorry guys. I gave you
the wrong impression. Here are specifically the things you can still do."
Don't just point to companies with $10M in VC funds each and say "No
problem, just be like them."

These are API developers. Say it in terms of the API. Exactly which API
calls are still allowed. If he says statuses/update is still allowed, then
that answers the question. There is no ambiguity.

As for Twitter being free. Yes. The API is, but denying the value that
products like Tweetdeck gave Twitter *for free* is denying the reality of
how Twitter got to where it is. It is called a partnership. They give us raw
materials, we add value to them. We all benefit.

On Sat, Mar 12, 2011 at 7:28 PM, Scott Wilcox  wrote:

> Hello,
>
> For a few days now I've read what people have said in reply to the update
> from Ryan. There are some crazy reactions and responses to what Ryan has
> said. In essence, the entire reaction is my opinion is completely overblown.
>
> Not in any sense what-so-ever have Twitter said that you can no longer post
> updates on behalf of users. Its ludicrous to suggest so. What they have have
> said (and in my opinion - quite clearly) is that it is better to direct your
> time and effort into a product that is not just a simple client and does
> more than just provide viewing and posting of tweets. There are so many
> half-arsed clients out there that do little more than just show and post
> tweets. If by chance a user was to use these low grade applications as their
> first experience of Twitter, it would probably put them off using it in the
> long term.
>
> I do fully believe that is why they have released their own branded clients
> for iOS, Macs and other devices. It provides a consistent experience for the
> end-users.
>
> The other thing that people seem to completely overlook is that Twitter are
> providing a freely accessible API at no charge to developers. It pains me to
> see so many developers standing the moral high ground. If you were paying
> for access to a service or product and it changes, you have a very valid
> reason to complain. To complain about a service provided free of charge for
> you to use at the end of the day frustrates me to no end. No single
> developer has a god given right to have access to the API, perhaps that
> should be remembered.
>
> Scott.
>
> On 13 Mar 2011, at 00:16, Adam Green wrote:
>
> Interesting that neither Ryan or anyone else from Twitter has replied once
> to any of the questions here, (way to go on showing your interest in the
> developer community, Ryan),  so I'll address this question to everyone else
> in the group. I don't read Ryan's message as demanding that apps are no
> longer allowed to send tweets on behalf of users. Is that supposed to be
> what he said? I think he is saying that apps should be more than *just*
> clients that let you read and post tweets. How to tell the difference, I
> have no idea, but I think in Ryan's mind there is a difference.
>
> I'll ask it as clearly as I can. Is it still allowed for an app to accept a
> tweet from a user and post it into their account?
>
> Is the /statuses/update api call still allowed in an app?
>
> Let's not wait for Twitter to respond, since they clearly don't want to any
> longer. Let's try and figure this out ourselves. What does everyone think?
> Can apps still send tweets?
>
> If yes, there is still a market for Twitter API developers. If not, the
> Twitter API is over. It is that simple.
>
> Maybe Ryan or anyone from Twitter can also find the time to answer this.
>
> On Sat, Mar 12, 2011 at 6:45 PM, Duane Roelands 
> wrote:
>
>> Wow.  "Thanks for getting so many people interested in Twitter.  Now
>> get lost."
>>
>> This is appalling.
>>
>> --
>> Twitter developer documentation and resources: http://dev.twitter.com/doc
>> API updates via Twitter: http://twitter.com/twitterapi
>> Issues/Enhancements Tracker:
>> http://code.google.com/p/twitter-api/issues/list
>> Change your membership to this group:
>> http://groups.google.com/group/twitter-development-talk
>>
>
>
>
> --
> Adam Green
> Twitter API Consultant and Trainer
> http://140dev.com
> @140dev
>
> --
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker:
> http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group:
> http://groups.google.com/group/twitter-development-talk
>
>
>  --
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.

Re: [twitter-dev] consistency and ecosystem opportunities

[Scott Wilcox]

Hello,

For a few days now I've read what people have said in reply to the update from 
Ryan. There are some crazy reactions and responses to what Ryan has said. In 
essence, the entire reaction is my opinion is completely overblown.

Not in any sense what-so-ever have Twitter said that you can no longer post 
updates on behalf of users. Its ludicrous to suggest so. What they have have 
said (and in my opinion - quite clearly) is that it is better to direct your 
time and effort into a product that is not just a simple client and does more 
than just provide viewing and posting of tweets. There are so many half-arsed 
clients out there that do little more than just show and post tweets. If by 
chance a user was to use these low grade applications as their first experience 
of Twitter, it would probably put them off using it in the long term.

I do fully believe that is why they have released their own branded clients for 
iOS, Macs and other devices. It provides a consistent experience for the 
end-users. 

The other thing that people seem to completely overlook is that Twitter are 
providing a freely accessible API at no charge to developers. It pains me to 
see so many developers standing the moral high ground. If you were paying for 
access to a service or product and it changes, you have a very valid reason to 
complain. To complain about a service provided free of charge for you to use at 
the end of the day frustrates me to no end. No single developer has a god given 
right to have access to the API, perhaps that should be remembered.

Scott.

On 13 Mar 2011, at 00:16, Adam Green wrote:

> Interesting that neither Ryan or anyone else from Twitter has replied once to 
> any of the questions here, (way to go on showing your interest in the 
> developer community, Ryan),  so I'll address this question to everyone else 
> in the group. I don't read Ryan's message as demanding that apps are no 
> longer allowed to send tweets on behalf of users. Is that supposed to be what 
> he said? I think he is saying that apps should be more than *just* clients 
> that let you read and post tweets. How to tell the difference, I have no 
> idea, but I think in Ryan's mind there is a difference. 
> 
> I'll ask it as clearly as I can. Is it still allowed for an app to accept a 
> tweet from a user and post it into their account? 
> 
> Is the /statuses/update api call still allowed in an app? 
> 
> Let's not wait for Twitter to respond, since they clearly don't want to any 
> longer. Let's try and figure this out ourselves. What does everyone think? 
> Can apps still send tweets? 
> 
> If yes, there is still a market for Twitter API developers. If not, the 
> Twitter API is over. It is that simple. 
> 
> Maybe Ryan or anyone from Twitter can also find the time to answer this. 
> 
> On Sat, Mar 12, 2011 at 6:45 PM, Duane Roelands  
> wrote:
> Wow.  "Thanks for getting so many people interested in Twitter.  Now
> get lost."
> 
> This is appalling.
> 
> --
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group: 
> http://groups.google.com/group/twitter-development-talk
> 
> 
> 
> -- 
> Adam Green 
> Twitter API Consultant and Trainer
> http://140dev.com
> @140dev
> 
> -- 
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group: 
> http://groups.google.com/group/twitter-development-talk

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] consistency and ecosystem opportunities

[Brainewave Consulting]

Would it be possible to get a set of user interface guidelines, like those that 
Apple provides to application developers, so that value add applications (such 
as TweePLayer.com) can conform consistently to the mainstream experience?


Mike Caprio
Principal and Lead Consultant

Brainewave Consulting
402 Graham Avenue PMB 211
Brooklyn, NY  11211
p: +1-347-269-0558
@brainewave







-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Re: [twitter-dev] consistency and ecosystem opportunities

[Umashankar Das]

Dear Ryan,
   A very direct question. Is it being said that I cannot associate a brand
new field like 'Discuss' with a tweet in my website?
Regards
Umashankar Das

On Sat, Mar 12, 2011 at 1:48 AM, Ryan Sarver  wrote:

> Hey all, I’d like to give you an update about the state of the Twitter
> Platform and hopefully provide some much requested guidance.
>
> Since this time last year, Twitter use has skyrocketed.  We’ve grown from
> 48 million to 140 million tweets a day and we’re registering new accounts at
> an all-time record.  This massive base of users, publishers, and businesses
> is a giant playground for developers to build their own businesses on, and
> this means the opportunity has grown for everyone.
>
> With more people joining Twitter and accessing the service in multiple
> ways, a consistent user experience is more crucial than ever.  As we talked
> about last April, this was our motivation for buying Tweetie and developing
> our own official iPhone app.  It is the reason why we have developed
> official apps for the Mac, iPad, Android and Windows Phone, and worked with
> RIM on their Twitter for Blackberry app. As a result, the top five ways that
> people access Twitter are official Twitter apps.
>
> Still, our user research shows that consumers continue to be confused by
> the different ways that a fractured landscape of third-party Twitter clients
> display tweets and let users interact with core Twitter functions.  For
> example, people get confused by websites or clients that display tweets in a
> way that doesn’t follow our design guidelines, or when services put their
> own verbs on tweets instead of the ones used on Twitter.  Similarly, a
> number of third-party consumer clients use their own versions of suggested
> users, trends, and other data streams, confusing users in our network even
> more.  Users should be able to view, retweet, and reply to @nytimes’ tweets
> the same way; see the same profile information about @whitehouse; and be
> able to join in the discussion around the same trending topics as everyone
> else across Twitter.
>
> *A Consistent User Experience*
> Twitter is a network, and its network effects are driven by users seeing
> and contributing to the network’s conversations.  We need to ensure users
> can interact with Twitter the same way everywhere.  Specifically:
>  - *The mainstream consumer client experience*.  Twitter will provide the
> primary mainstream consumer client experience on phones, computers, and
> other devices by which millions of people access Twitter content (tweets,
> trends, profiles, etc.), and send tweets.  If there are too many ways to use
> Twitter that are inconsistent with one another, we risk diffusing the user
> experience.  In addition, a number of client applications have repeatedly
> violated Twitter’s Terms of Service, including our user privacy policy.
>  This demonstrates the risks associated with outsourcing the Twitter user
> experience to third parties.  Twitter has to revoke literally hundreds of
> API tokens / apps a week as part of our trust and safety efforts, in order
> to protect the user experience on our platform.
>  - *Display of tweets in 3rd-party services*. We need to ensure that
> tweets, and tweet actions, are rendered in a consistent way so that people
> have the same experience with tweets no matter where they are.   For
> example, some developers display “comment”, “like”, or other terms with
> tweets instead of  “follow, favorite, retweet, reply” - thus changing the
> core functions of a tweet.
>
> With this in mind, we’ve updated our Terms of Service:
> http://dev.twitter.com/pages/api_terms.
>
> *The Opportunity for Developers*
> Developers have told us that they’d like more guidance from us about the
> best opportunities to build on Twitter.  More specifically, developers ask
> us if they should build client apps that mimic or reproduce the mainstream
> Twitter consumer client experience.  The answer is no.
>
> If you are an existing developer of client apps, you can continue to serve
> your user base, but we will be holding you to high standards to ensure you
> do not violate users’ privacy, that you provide consistency in the user
> experience, and that you rigorously adhere to all areas of our Terms of
> Service.  We have spoken with the major client applications in the Twitter
> ecosystem about these needs on an ongoing basis, and will continue to ensure
> a high bar is maintained.
>
> As we point out above, we need to move to a less fragmented world, where
> every user can experience Twitter in a consistent way.  This is already
> happening organically - the number and market share of consumer client apps
> that are not owned or operated by Twitter has been shrinking.  According to
> our data, 90% of active Twitter users use official Twitter apps on a monthly
> basis.
>
> In contrast, the number of successful applications and companies in the
> Twitter ecosystem that focus on areas outside of the main

Re: [twitter-dev] consistency and ecosystem opportunities

[M. Edward (Ed) Borasky]

On Fri, 11 Mar 2011 13:18:24 -0700, Ryan Sarver  
wrote:

THE OPPORTUNITY FOR DEVELOPERS



Some key areas where ecosystem developers are thriving:
 - PUBLISHER TOOLS.  Companies such as SocialFlow [2] help
publishers optimize how they use Twitter, leading to increased user
engagement and the production of the right tweet at the right time. 
 - CURATION.  Mass Relevance [3] and Sulia [4] provide services for
large media brands to select, display, and stream the most 
interesting

and relevant tweets for a breaking news story, topic or event.  
 - REALTIME DATA SIGNALS.  Hundreds of companies use real-time
Twitter data as an input into ranking, ad targeting, or other aspects
of enhancing their own core products.  Klout [5] is an example of a
company which has taken this to the next level by using Twitter data
to generate reputation scores for individuals.  Similarly, Gnip [6]
syndicates Twitter data for licensing by third parties who want to 
use

our real-time corpus for numerous applications (everything from hedge
funds to ranking scores).  
 - SOCIAL CRM, ENTREPRISE CLIENTS, AND BRAND INSIGHTS.  Companies
such as HootSuite [7], CoTweet [8], Radian6 [9], Seesmic [10], and
Crimson Hexagon [11] help brands, enterprises, and media companies 
tap

into the zeitgeist about their brands on Twitter, and manage
relationships with their consumers using Twitter as a medium for
interaction.
 - VALUE-ADDED CONTENT AND VERTICAL EXPERIENCES.  Emerging services
like Formspring [12], Foursquare [13], Instagram [14], and Quora [15]
have built into Twitter by allowing users to share unique and 
valuable

content to their followers, while, in exchange, the services get
broader reach, user acquisition, and traffic.  


There's a common thread in most of the businesses you've listed as 
"thriving" above. Nearly all of them interface with *multiple* networks 
- Twitter, yes, but also Facebook, LinkedIn, and even MySpace. 
HootSuite, for example, connects to Twitter, Facebook, LinkedIn, 
MySpace, Ping.fm, WordPress, Foursquare and mixi. There's also Google 
Buzz / Latitude, Tumblr, Posterous, Gowalla, Yelp, and I'm sure many 
others. In short, I'd say there seem to be few businesses "thriving" 
that have focused only on Twitter.


Last time I looked at the Alexa site rankings world-wide, Twitter was 
number nine. It's a long climb to the top IMHO - Twitter needs to pass 
Wikipedia and Baidu just to get to the point where Google, Yahoo!, 
Microsoft and Facebook are in sight. Twitter is still growing, for sure, 
but there are clearly some challenges for developers who only develop 
for Twitter.

--
http://twitter.com/znmeb http://borasky-research.net

"A mathematician is a device for turning coffee into theorems." -- Paul 
Erdős


--
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

[twitter-dev] consistency and ecosystem opportunities

[Ryan Sarver]

Hey all, I’d like to give you an update about the state of the Twitter
Platform and hopefully provide some much requested guidance.

Since this time last year, Twitter use has skyrocketed.  We’ve grown from 48
million to 140 million tweets a day and we’re registering new accounts at an
all-time record.  This massive base of users, publishers, and businesses is
a giant playground for developers to build their own businesses on, and this
means the opportunity has grown for everyone.

With more people joining Twitter and accessing the service in multiple ways,
a consistent user experience is more crucial than ever.  As we talked about
last April, this was our motivation for buying Tweetie and developing our
own official iPhone app.  It is the reason why we have developed official
apps for the Mac, iPad, Android and Windows Phone, and worked with RIM on
their Twitter for Blackberry app. As a result, the top five ways that people
access Twitter are official Twitter apps.

Still, our user research shows that consumers continue to be confused by the
different ways that a fractured landscape of third-party Twitter clients
display tweets and let users interact with core Twitter functions.  For
example, people get confused by websites or clients that display tweets in a
way that doesn’t follow our design guidelines, or when services put their
own verbs on tweets instead of the ones used on Twitter.  Similarly, a
number of third-party consumer clients use their own versions of suggested
users, trends, and other data streams, confusing users in our network even
more.  Users should be able to view, retweet, and reply to @nytimes’ tweets
the same way; see the same profile information about @whitehouse; and be
able to join in the discussion around the same trending topics as everyone
else across Twitter.

*A Consistent User Experience*
Twitter is a network, and its network effects are driven by users seeing and
contributing to the network’s conversations.  We need to ensure users can
interact with Twitter the same way everywhere.  Specifically:
 - *The mainstream consumer client experience*.  Twitter will provide the
primary mainstream consumer client experience on phones, computers, and
other devices by which millions of people access Twitter content (tweets,
trends, profiles, etc.), and send tweets.  If there are too many ways to use
Twitter that are inconsistent with one another, we risk diffusing the user
experience.  In addition, a number of client applications have repeatedly
violated Twitter’s Terms of Service, including our user privacy policy.
 This demonstrates the risks associated with outsourcing the Twitter user
experience to third parties.  Twitter has to revoke literally hundreds of
API tokens / apps a week as part of our trust and safety efforts, in order
to protect the user experience on our platform.
 - *Display of tweets in 3rd-party services*. We need to ensure that tweets,
and tweet actions, are rendered in a consistent way so that people have the
same experience with tweets no matter where they are.   For example, some
developers display “comment”, “like”, or other terms with tweets instead of
 “follow, favorite, retweet, reply” - thus changing the core functions of a
tweet.

With this in mind, we’ve updated our Terms of Service:
http://dev.twitter.com/pages/api_terms.

*The Opportunity for Developers*
Developers have told us that they’d like more guidance from us about the
best opportunities to build on Twitter.  More specifically, developers ask
us if they should build client apps that mimic or reproduce the mainstream
Twitter consumer client experience.  The answer is no.

If you are an existing developer of client apps, you can continue to serve
your user base, but we will be holding you to high standards to ensure you
do not violate users’ privacy, that you provide consistency in the user
experience, and that you rigorously adhere to all areas of our Terms of
Service.  We have spoken with the major client applications in the Twitter
ecosystem about these needs on an ongoing basis, and will continue to ensure
a high bar is maintained.

As we point out above, we need to move to a less fragmented world, where
every user can experience Twitter in a consistent way.  This is already
happening organically - the number and market share of consumer client apps
that are not owned or operated by Twitter has been shrinking.  According to
our data, 90% of active Twitter users use official Twitter apps on a monthly
basis.

In contrast, the number of successful applications and companies in the
Twitter ecosystem that focus on areas outside of the mainstream consumer
client experience has grown quickly, and this is a trend we want to continue
to support and help grow.  Twitter will always be a platform on which a
smart developer with a great idea and some cool technology can build a great
company of his or her own.  And, with record user growth, there has never
been a better time to build into Twitter.

Some k