Raffi,

Another question came up as I was thinking about support for this in
my web-site (http://twxlate.com):

Will the <user> elements returned in the responses to API requests
include information that indicates whether or not the user has opted-
in to geo-coding of their tweets?

I would like to see this right from the get go so that client web-
sites / applications know whether or not to prompt their users for
location information to be geo-coded with a tweet that is being
created. If this isn't there, I think there will be unnecessary
confusion and possibly wrong actions taken on behalf of the user.

Please seriously consider this for inclusion in the initial
deployment, if it is not already there.

Thanks in advance.

Comments welcome and expected.

Jim Renkel

On Sep 1, 6:08 pm, Raffi Krikorian <ra...@twitter.com> wrote:
> hey jim.
>
>
>
> > 1. "the user.location is a completely separate entity (for now)"  
> > implies
> > that maybe sometime in the future it may be used, e.g., to provide a
> > default geo-coded location for a tweet. I would suggest that if the
> > user's profile location if ever geo-coded, that geo-code should be  
> > added
> > to the <user> objects returned by API calls, at least the users/show
> > method. Users will want to know what may be, e.g., added to their  
> > tweets
> > without having to generate a test tweet to find out.
>
> > 2. Having the user's profile location geo-coded and returned in API
> > calls would be very useful now. Yeh, twitter client web-sites /
> > applications can do it for themselves (Mine certainly will if twitter
> > doesn't do it.), but may come up with different / inconsistent  
> > results.
> > And, trust me, it ain't as easy to get good results as it might first
> > appear. To maximize use and consistency, it would be great if twitter
> > did the geo-coding and supplied it to everyone.
>
> these are both great ideas.  right now, the geolocation API is really  
> focused on tweet-level information -- but we're actively thinking  
> about what's next.
>
> > 3. Will twitter client web-sites / applications be able to turn the
> > geo-location feature on for their users, or do the users have to go to
> > twitter.com with a browser to do this? My concern here is that
> > twitter.com only supports two languages (English and Japanese) for its
> > UI, where my site (http://twxlate.com) supports these and over 40  
> > more.
> > Unless the user is fluent in English or Japanese, they won't be able  
> > to
> > turn it on. I've already run into similar problems as I'm rolling out
> > test versions of OAuth support.
>
> unfortunately not.  as we're pretty sensitive to our user's privacy,  
> for now, a user will have to go to twitter.com with a browser to turn  
> on the setting (remember, by default it is off).  if you have any  
> suggestions on how to make this user interaction better in the future,  
> i would be eager to hear them!
>
> > As I've written some pretty spiffy geo-coding applications for other
> > purposes, I plan on doing some pretty spiffy geo-coding stuff with
> > twxlate.com. But it needs to be usable, or users won't use it and / or
> > may be annoyed by it. I would hate for that to happen to what promises
> > to be a really neat feature.
>
> cool!  well - i hope what we're doing is usable!  if not, just keep  
> blasting me about it.  threads like these on the mailing list are  
> awesome.
>
> --
> Raffi Krikorian
> Twitter Platform Team
> ra...@twitter.com | @raffi

Reply via email to