So when I saw that Loopt was going to be on all the new iPhones, I ran to try it. I love mobile apps, especially web to mobile apps. So, I installed it, right on my phone, but couldn't figure out how to see it, on the phone, I mean. (Dooh!)

So I just got a message that basically says "Reminder! You're using Loopt to share you phone's location with friends."

So you mean I just installed a tracking device on my phone for stalkers I know and this thing can't ever be shut off?

FAIL. uninstall imminemt.

"When a site designs an API, what they usually do is take their internal data model and expose every nook and cranny in it in great detail. Obviously, this fits their view of the world, or they wouldn't have built it that way, so they want to share this with everyone. In one way this is like the form-fitting lycra that weekend cyclists are so enamoured of, but working with such APIs is like being a bespoke tailor - you have to measure them carefully, and cut your code exactly right to fit in with their shapes, and the effort is the same for every site you have to deal with (you get more skilled at it over time, but it is a craft nonetheless).

Conversely, when a site adopts a standard format for expressing their data, or how to interact with it, you can put your code together once, try it out on some conformance tests, and be sure it will work across a wide range of different sites - it's like designing a t-shirt for threadless instead."

--The always wise Kevin Marks, Epeus' epigone, An API is a bespoke suit, a standard is a t-shirt

If you're interested in local, community, identity, of course you are thinking about location-based services.

Chris Messina's post on location and development gives me alot to think about and is worth a close read. Here's one snippet and then some ideas it's prompted:

"Put still another way, how would a universal "location layer for the social web" change the design and implementation of existing applications? Would it give rise to a class of applications that take advantage of and thrive on knowing where their members live, work and play, and tailor their services accordingly? Or would all services eventually make use of location information? Or will it depend on each service's unique offering and membership, and why people signed up in the first place? Just because you can integrate with Twitter or Facebook, must you? If the "location layer" were made available, must you take advantage of it? What criteria or metrics would you use to decide?"

Susan sez: Coming from an online dating service, where we did large quantities of research into safety and security, among both men and women, I'm interested in how the value of location will actually play out. 

I'd posit that there is very little need to actually tell your closest circle where you are via a device because they know anyway (let's assume you communicate multiple times a day via various channels

So then it's the second degree circle and beyond you're able to broadcast or alert where you are--a person is going to want to share that data with specific people or sorts of people at specific times (EX: I am at my kids' game, all parent friends and members of the soccer team; NOT my boss and co-workers, perhaps.)

And then there's the amazing marketing that location can drive--Example: Headed to the movie? Here's a special offer to come have pizza with us before or after! (Ugh).

I am completely interested in location awareness, but also trying to think out best fit use cases so this stuff isn't stalkery or just more annoying intrusions.

I'm still waking up, but this is a great post by one Hank Williams, whydoeseveryhingsuck?:

"It is entirely possible that before Twitter makes its first penny, it will become too important to exist in its current form, and the community will feel it has to be replaced by an open source distributed framework. This should strike fear into the hearts of anyone who decides open their API. While the Open API strategy has clearly worked in terms of adoption, it may have worked too well. In fact it may have worked so well that Twitter may be killed before it has even really made it out of the womb, by people that find it so important that they can't afford to really have it be a company."

I don't think this is going to happen to twitter, but like the concept of Open API perhaps not being enough as a big worrier for any developer.

Also think this is a good articulation of a higher-order problem.

"In the last week we deployed new code to Flickr 50 times, including 546 changes by 16 people. We issued over 2,000 new API keys, and third party developers made an average of 704 API calls per second, across 109 public API methods. We added 1 new API method, and updated 7 others. There are approximately 10,000 lines of open source code in our public subversion repository.

And our new developer site, code.flickr.com, is where you keep up with all that."

--flickr staffer kellan elliott-mccrea, writing on the flickr blog about the ongoing, useful development work the team keeps doing (oh, and there's a new developer blog here).

Susan sez: Isn't this what good web services do..keep empowering and working with their users?