Re: [twitter-dev] Some thoughts leading up to Chirp
I have much to do before my flight tomorrow so this is rough and should be read as such. Even in light of recent events Chirp is looking to be a good time that will hopefully result in fruitful dialog from all. Considering the magnitude of the issue it would have been, in my mind, pertinent to have had this email ready to go on Friday for what must have been expected pushback. Leaving the overactive imaginations of netizens to fester is rarely helpful. I think many of us understand the reasons but are now feeling threatened because space previously understood to be of little direct interest from Twitter is now very much squarely in Twitter's targets. Usability is always a concern and the explanation of Twitter has always been difficult at best, but I think there were better ways to handle this they would have resulted in less developer duress. I find it slightly ironic that some of the blame is Twitter's restrictions on the use of trademark design and terms, though I realized Twitter has it's interests to protect and so I won't fault you on that. Suddenly announcing stepping into the developer space seems like the easy fix for you. But at what cost? I've been developing on the Twitter platform for a long time and I'm not going to think twice about future projects where before I didn't. Many other new and experienced developers are along the same thought process. Maybe you should have worked with developers to smooth over the onboarding process instead. A good start would have been design documentation to present users with a more consistent experience. Here is the text you should present new users, here is the icon you should use for retweets, etc. Much could have been done without impeding the creativity of developers while still making it easier for users. Would users still get lost looking for an Official app? Probably, but I would argue it would have been a better result than the distrust now implanted in all developers thoughts. The loss of a user is the loss of a single user but the loss of a developer could be the loss of thousands of users. The communication between Twitter and developers has look more and more like this: Twitter: We are rolling out this change. Devs: Wait! What? Twitter: ... Devs: Wait! What? Twitter: ... Devs: Wait! What? Twitter: Ok. we took your feed back and will tweak it a little. Devs: But what about this? Twitter: ... Yes this is an exaggeration but the idea holds true. There has been less of an ongoing dialog and more of Twitter dictating changes. Is it Twitter's right? Yes. Is it our right to bitch and move to other platforms? Yes. Smaller issues seem to have much better dialog between individual Twitter developers working on the specific subsystem which is great but the small issues also screws less developers when things change. Sometimes I feel sorry for the platform team (who are all true hackers at heart) for being stuck between the business side of Twitter and the third-party developers. We can't seed the business side telling you no the the nifty features I'm sure you would love to developer for us. All we just see you saying no. There is a level of transparency that I want from Twitter which is understandably not an option for the majority of startups. (*cough* *cough* @dacort) That dream of transparency is reminiscent of a time when the API group felt more like an open source project where the platform team seemed more like overworked committers then employees of an multi-million dollar corporation. I would also like to point you to @funkatron's heartfelt blog post much of which holds true for me: http://funkatron.com/site/comments/my-friend-twitter/ Many of you will see me at Chirp of which I am looking forward to, but Chirp no longer has the shiny luster it once had and as Twitter overshadows the community more and more I too will look more and more to other platform and other communities. I hope we didn't use up all your minutes Ryan. :-P @Abraham On Sun, Apr 11, 2010 at 17:22, Ryan Sarver wrote: > I wanted to email everyone and share my thoughts on the acquisition > from Friday, the communication around it and where we are going from > here. We're incredibly excited about Chirp, and I think an open > dialogue going into it is important. I look forward to meeting many of > you there and continuing the discussion. > > We love the Twitter ecosystem and work hard every day to help support > you and make the platform you are building on as successful as it can > be for everyone involved. We love the variety that developers have > built around the Twitter experience and it's a big part of the success > we've seen. However when we dug in a little bit we realized that it > was causing massive confusion among user's who had an iPhone and were > looking to use Twitter for the first time. They would head to the App > Store, search for Twitter and would see results that included a lot of > apps that had nothing to do with Twitter and a few that did, but a new
RE: [twitter-dev] Some thoughts leading up to Chirp
Ryan Sarver wrote:
> [...] However when we dug
> in a little bit we realized that it was causing massive confusion among
user's who
> had an iPhone and were looking to use Twitter for the first time. They
would
> head to the App Store, search for Twitter and would see results that
included a
> lot of apps that had nothing to do with Twitter and a few that did, but a
new
> user wouldn't find what they were looking for and give up. That is a lost
user for
> all of us.
>
> [...] We will also admit
> our mistakes when they are made and the Blackberry client should never
have
> been labeled "official". It has since been changed and you won't see that
> language used with Twitter clients in the future.
The "officialness" of the Blackberry app wasn't much of a problem. The
problem was/is the name and the logo. It is confusing to users to have the
app named "Twitter" and it is confusing to see the app branded solely with
the "t" logo. The "t" mark is something that should definitely be protected,
but I think it has a lot of *functional* uses for it as an indicator or
badge that make it inappropriate as the logo for a single application on any
platform. IMO, it would be much better for Twitter in the long run to have
the "t" logo used as a badge to indicate that an app has met some
quality/security criteria--like the "Compatible with Windows 7" logo
program, the "Made for iPod," the Visa logo, etc. That would be something
that would allow you to start a process of ensuring a wide variety of
high-quality applications that are closely aligned with your business goals,
without setting the bar too high or the terms too strict for simpler
applications with a more casual connection to Twitter.
Many mobile operators and phone manufacturers have very bad policies about
supporting their products once they've been replaced with newer models. It
is very likely that, if you let mobile operators and mobile manufacturers
have exclusive uses of the trademarks on their platforms, that those
trademarks will be attached to software that becomes stale, obsolete, or
even totally non-functional on otherwise serviceable devices that aren't
even that old. It would be a big mistake to reserve Twitter's branding for
applications which don't even end up staying in the top tier of Twitter apps
on their platform in terms of quality.
Anyway, I think that everybody will soon see that "officialness" of
competing applications is a very small problem compared to issues like
degradation of UI w/ advertising or strict restrictions on how spam-ish
Twitter-provided content is filtered. I really hope that you guys have
something extremely clever planned for monetization. I have been unable to
think of many ways to make money with Twitter that didn't involve annoying
end-users with ads or encouraging end-users to annoy each other ("RT to
win..."), and AFAICT nothing is going to work unless it keeps users' home
and @mentions timelines clean with less advertising/spam than there already
is now, instead of more. I am genuinely curious to see what you guys have
come up with.
Regards,
Brian
@BRIAN_
--
To unsubscribe, reply using "remove me" as the subject.
