Can they do it again?

What does it take to start blogging again? A new year? A new decade? Or the opportunity to pointlessly speculate about an as yet unannounced product?

The question that keeps coming back to me is "Can they do it again?"

Not "Can they break into a new, billion dollar market?", not "Can they redefine the way we distribute and buy apps?" but "Can they reinvent the way we interact with mobile devices?"

I remember the time before the iPhone was launched. We had an HTC running Windows Mobile in the office with a touch screen and a dinky little stylus - you could use your finger nails if you angled them just right. OK, it was a bit fiddly but it took most of the fear away when entering a long URL into the browser's address bar. But we knew there were better things coming. We had all seen those iPhone mockups - the one's with a virtual, circular scroll-wheel floating over the interface. We couldn't wait.

And then there it was ... and it had a whole new vocabulary of gestures; slides and flicks and pinches and you could type with your actual fingers and there were '.com' and '@' buttons when you needed them and the interface was simple and hidden and only came to life when you actually touched it. And before the hour was out you knew that was how it was supposed to be and when you actually got one in your hands you just smiled at how much fun it was. And the best part was nobody knew a thing.

Can they possibly do that again?

Maybe they don't have to. A tablet with the touch interface of an iPhone would be a fun way of consuming digital content - but $500-$1000 worth of fun? Surely it's got to be as good as, if not better, than the iPhone when it comes to creating content, when it comes to text entry. And the point is that if it does just what the iPhone does, it won't be better - it will be worse - because you can use both thumbs on an iPhone or you can use it one-handed and I bet you won't be able to do that with a 10" tablet.

OK, so this time they don't have to invent, and keep under wraps, a whole new way of interacting with a mobile device; all they need to do is invent a new way to allow me to write next years blog entry on a tablet. Except that inventing things is hard and rare.

Advertising on Google Local

David Galbraith has noticed Google testing out what he calls 'adballoons' on Google Local.

Searching for hotels in New York brings up a pair of blue sponsored links for two specific hotels ('W Court Hotel' and 'Courtyard Manhattan Hotel'). Clicking on these brings up the balloon on the map.

By comparison, searching for hotels in San Francisco brings up a generic sponsored link for 'San Francisco Hotels' which takes users to a new page.

Google Base doesn't like 'geotagged'

I've just tried creating an item in Google Base of a new item type Spatially Referenced Photo with:

• two details called geo lon and geo lat (I tried including the colons but it strips them out) with values of type Number
• a label of geotagged - unfortunately the label was rejected as 'misspelled'

I've asked for an exemption so here's hoping...

Update: as of Nov 21, 2005 6:42 PM Google Base does like 'geotagged', check out a Google Base item pointing to a geotagged Flickr picture of the Mill Race in Cambridge.

Tags: geotagging

Third parties indexing Google Base

So, before hard evidence comes to light, let me speculate...

I can submit structured data to Google Base for them to do with as they please. No doubt there will be a facetted-browser for users to search through that data and maybe even an API. But will third-party search engines be able to index any of it? Web sites can be crawled/scraped, blog publishing provides a pinging mechanism. Will Google Base provide a mechanism that doesn't fall foul of Google's terms and conditions of use?

Splogs

Well Google do seem to be trying to do things to limit the problem of spam blogs hosted on blog*spot. They've introduced a 'type in the letters' test when posting to a blog that looks suspicious. Of course if you're posting via the Blogger API then its just rejected.

More recently I note that the Atom feed for a blog*spot hosted blog has a <summary> tag with all the markup removed. By contrast a blog that is FTPed to an alternate host has a <content> tag with markup present.

UPDATE: seems to be back to normal - I know it just looks like I might have flipped the 'summary' switch but...

Feeds of Feeds

There doesn't seem to be many rules/conventions governing what you get when you request a feed representing the on-going results from a search. For example at the botton of a Google Blog Search page you can get an RSS or Atom feed with 10 or 100 items. With Technorati you can add a search to your Watchlists and then get an RSS feed. In Bloglines you can subscribe to a search but you never see the feed itself - or at least if you try to edit the subscription you don't.

However I am more interested in the feed itself. They all work fine if all you want to do is subscribe to them in a news reader, but what if you want to process the results further? Such feeds supply the necessary <link rel="alternate" type="type="text/html" ... but couldn't they also supply the associated third-party feed itself?

Consider the simple example of looking for 'geotagged' blog entries: its easy enough to get a set of references to blog entries which match the search engines idea of 'geotagged'. But if you want to go further and retrieve the associated location (if any) then its easier to deal with the blog's feed than it is its HTML representation.

Could this be handled by including some additional <link> with either a suitable rel attribute or infer it from the type attribute?

Villandry

CNV00014-1
Originally uploaded by acuth.

So Flickr knows how to post to Blogger!
geo: (47.3399,0.5116)
tags: geotagged

geo: (47.3397533, 0.5108643)

Check this out on mylocalguru

hReview and hContainer

Looking over my previous post on hReview, I have to confess that it doesn't look as supportive as I had intended. So here - with my apologies - is a mark two...

hReview defines a microformat that can be used in both traditional web pages and blog posts. It can do this because it is essentially self-contained and makes no assumptions about how the content is published. This post considers the question of whether microformats, in general, should take advantage of different publishing techniques and, if so, how.

I start with the observation that a number of the elements of hReview would appear to mimic elements familiar to typical a blog publishing environment. For example comparing hReview with Atom (0.8):

hReview	Atom
summary	title
reviewer	author contributor
dtreviewed	published updated
permalink	id

where required fields are shown as field-name.

The question arises about what should happen if an hReview is published as [part of] a blog post? For example what happens if the summary and permalink fields are not present; could or should some review indexer use the blog equivalents? Obviously the answer is no if a blog post contains multiple hReviews. But, for the moment, lets consider what I would consider to be the more common situation when there is a single hReview in a blog post.

I would suggest modifying the rules of how a review indexer should obtain metadata about a review; some metadata comes from markup in the review itself and some comes from its context. In the context of the blog post, the extent of the review is merely the extent of the post. Thus there is no need for an enclosing element with class="hreview". It would be sufficient to mark the entire blog post with a suitable tag, for example:

<a href="http://www.technorati/com/tag/hreview_instance"
  rel="tag">hreview_instance</a>

For an hReview published as a blog post the only required elements would be the hreview_instance tag and the item info field. For an hReview published as a standard web page, the requirements could be the same provided there is a way of establishing the context, most obviously defining the extent of review. Rather than use an hReview specific class="hreview" element, the review extent could be defined by a generic container that can carry the same information as a blog post context. I would propose an hContainer which could be reused in this role across multiple microformats that must define an extent.

Thus the review:

<div>
 <span>5 stars out of 5 stars</span>
 <h4>Crepes on Cole is awesome</h4>
 <span>Reviewer: <span>Tantek</span> - 
 April 18, 2005</span>
 <blockquote><p>
  Crepes on Cole is one of the best little 
  creperies in San Francisco. Excellent food 
  and service....
 </p></blockquote>
 <p>Visit date: <span>April 2005</span></p>
 <p>Food eaten: <span>Florentine crepe</span></p>
</div> 

becomes:

<div class="hcontainer">
 <span>
  <span class="rating>5 stars out of 5 stars</span>
 </span>
 <h4 class="title">
  <span class="item fn">Crepes on Cole is awesome</span>
 </h4>
 <span>Reviewer: 
  <span class="author fn">Tantek</span> - 
  <abbr class="updated" title="20050418T2300-0700">
   April 18, 2005
  </abbr>
 </span>
 <blockquote class="description"><p>
  Crepes on Cole is one of the best little 
  creperies in San Francisco. Excellent food 
  and service....
 </p></blockquote>
 <p>Visit date: <span>April 2005</span></p>
 <p>Food eaten: <span>Florentine crepe</span></p>
 <span style="visibility:hidden;">
  <a href="http://www.technorati/com/tag/hreview_instance" 
   rel="tag">hreview_instance</a>
 </span>
</div> 

This is essentially the same as the current hReview proposal, except that some of the field names have been changed to make them more generic and the hreview_instance tag has been added.

Tags: hreview

Search and Bloglines

I'm glad to see that Bloglines intends to do something about search this summer. Afterall web-based news aggregators have such potential; they have a far more intimate understanding of what a person is interested in than any web-based search engine and they have access to a far more complete set of data than any desktop-based news aggregator.

Clearly some of it is going to relate to improving the results that come back from the 'search' box. Here's hoping that includes a personalised component. By their very nature news aggregators make use of a user profile; specifically a personalised list of subscribed feeds. Furthermore a feed seems to be a new and useful unit to work in. There are things I can say about my relationship to a feed that I cannot say of individual posts.

For example I might wish to say 'ignore any unread posts more than two days old' for some feeds. Obviously such an ability would not only relate to search, it would have a direct impact on the everyday user experience of a news aggregator. But it is precisely that streamlined user experience that made news aggregation so much better than its predecessor. As news aggregation becomes ever more successful, that streamlined user experience is itself beginning to be a bit more of a chore. What is needed is a way of pruning out some of the posts without throwing out that delightful 'a-ha' discovery moment.

Consider another example; I think I could easily categorize my subscribed feeds into those representing 'though-leaders', those that should be 'watched' and 'others'. The idea is that 'watched' feeds only occasionally contain something that interests me - I don't want to be informed about every new post. The criteria for bringing a post to my attention is that it has been referenced by two or more posts from 'though-leaders'.

Getting the user to provide additional information explicitly to a news aggregator (more than just a set of subscribed feeds) may seem old-fashioned compared to those efforts that seek to glean more information about the user from their behaviour. However it appears to me to build upon one of the things that set news aggregators apart in the first place. Furthermore the concept of a 'feed' provides the necessary high-level construct about which to collect such information.

Tags: bloglines