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
