Tue 15 Apr 2008
Tags: location, fire eagle, web, web2.0
Brady Forrest asked in a recent
post
what kinds of applications people would most like to see working with Yahoo's
new location-broking service Fire Eagle (currently
in private beta).
It's clear that most of the shiny new web 2.0 sites and apps might be able to
benefit from such personal location info:
photo sites that can do automagic geotagging
calendar apps that adapt to our current timezone
search engines that can take proximity into account when weighting results
social networks that can show us people in town when we're somewhere new
maps and mashups that start where you are, rather than with some static default
etc.
And such sites and apps will no doubt be early adopters of fire eagle and
whatever other location brokers might bubble up in the next little while.
Two things struck me with this list though. First, that's a lot of sites and
apps right there, and unless the friction of authorising new apps to have
access to my location data is very low, the pain of micromanaging access is
going to get old fast. Is there some kind of 'public' client level access in
fire eagle that isn't going to require individual app approval?
Second, I can't help thinking that this still leaves most of the web out in
the cold. Think about all the non-ajax sites that you interact with doing
relatively simple stuff that could still benefit from access to your public
location data:
the shipping address forms you fill out at every e-commerce site you buy from
store locators and hours pages that ask for a postcode to help you (every time!)
timetables that could start with nearby stations or routes or lines if they
knew where you were
intelligent defaults or entry points for sites doing everything from movie
listings to real estate to classifieds
This is the long tail of location: the 80% of the web that won't be using ajax
or comet or OAuth or web service APIs anytime soon. I'd really like my location
data to be useful on this end of the web as well, and it's just not going to
happen if it requires sites to register api keys and use OAuth and make web
service api calls. The bar is just too high for lots of casual web developers,
and an awful lot of the web is still custom php or asp scripts written by
relative newbies (or maybe that's just here in Australia!). If it's not almost
trivially easy, it won't be used.
So I'm interested in how we do location at this end of the web. What do we
need on top of fire eagle or similar services to make our location data
ubiquitous and immediately useful to relatively non-sophisticated websites?
How do we deal with the long tail?
Wed 12 Sep 2007
Tags: web, web2.0, lifebits, microformats, data blogging
Following on from my earlier data blogging post, and along the
lines of Jon Udell's
lifebits scenarios,
here's the first in a series of posts exploring some ideas about how data blogging
might be interesting in today's Web 2.0 world.
Easy one first: Reviews.
When I write a review on my blog of a book I've read or a movie I've seen,
it should be trivial to syndicate this as a review to multiple relevant
websites. My book reviews might go to Amazon (who else does good user
book review aggregation out there?), movies reviews to IMDB, Yahoo Movies,
Netflix, etc.
I'm already writing prose, so I should just be able to mark it up as a
microformats microformats:"hReview", add some tags to control syndication,
and have that content available via one or more RSS or Atom feeds.
I should then just be able to go to my Amazon account, give it the url
for the feed I want it to monitor for reviews, and - voila! - instant
user-driven content syndication.
This is a win-win isn't it? Amazon gets to use my review on its website,
but I get to retain a lot more control in the process:
I can author content using my choice of tools instead of filling out a
textarea on the Amazon website
I can easily syndicate content to multiple sites, and/or syndicate
content selectively as well
I can make updates and corrections according to my policies, rather than
Amazon's (Amazon would of course still be able to decide what to do with
such updates)
I should be able to revoke access to my content to specific websites
if they do stupid stuff
I and my readers get the benefit of retaining and aggregating my content
on my blog, and all your standard blogging magic (comments, trackbacks,
tagclouds, etc.) still apply
It would probably also be nice if Amazon included a link back to the
review on my blog which would drive additional traffic my way, and allow
interested Amazon users to follow any further conversations (comments and
trackbacks etc.) that have happened there.
So are there any sites out there already doing this?
Thu 06 Sep 2007
Tags: web, web2.0, lifebits, microformats, data blogging, inverted web
I've been spending some time thinking about
a couple of
intriguing posts
by Jon Udell, in which he discusses a hypothetical "lifebits" service
which would host his currently scattered "digital assets" and syndicate
them out to various services.
Jon's partly interested in the storage and persistence guarantees such a
service could offer, but I find myself most intrigued by the way in which
he inverts the current web model, applying the publish-and-subscribe
pull-model of the blogging world to traditional upload/push environments
like Flickr or MySpace, email, and even health records.
The basic idea is that instead of creating your data in some online app,
or uploading your data to some Web 2.0 service, you instead create it in
your own space - blog it, if you like - and then syndicate it to the
service you want to share it with. You retain control and authority over
your content, you get to syndicate it to multiple services instead of
having it tied to just one, and you still get the nice aggregation and
wikipedia:"folksonomy" effects from the social networks you're part of.
I think it's a fascinating idea.
One way to think of this is as a kind of "data blogging", where we blog
not ideas for consumption by human readers, but structured data of
various kinds for consumption by upstream applications and services.
Data blogs act as drivers of applications and transactions, rather than
of conversations.
The syndication piece is presumably pretty well covered via RSS and Atom.
We really just need to define some standard data formats between the
producers - that's us, remember! - and the consumers - which are the
applications and services - and we've got most of the necessary components
ready to go.
Some of the specialised XML vocabularies out there are presumably useful
on the data formats side. But perhaps the most interesting possibility is
the new swag of microformats currently being
put to use in adding structured data to web pages. If we can blog
people and organisations,
events,
bookmarks,
map points,
tags, and
social networks, we've got halfway
decent coverage of a lot of the Web 2.0 landscape.
Anyone else interested in inverting the web?