Raffi,

I fully understand the concern about privacy. To that end, here's
something you may want to consider:

Have application / web-site "over-rides" of the geo-code enable be
another option on OAuth. This way a user can control the creation of
geo-coding in their tweets on a finer grain basis.

The profile and OAuth enables would be ANDed: the user has to both
grant permission in their profile and via OAuth to allow a client to
create tweets with geo-coding for them.

If this is done, it may then be reasonable to have the profile default
be enabled rather than disabled, with the OAuth default being
disabled. The user would have explicitly check a box or something
during their OAuth dialogue to grant the client permission.

Just a thought. Comments welcome.

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