adrian's wall

Speculations about developing with iCloud

2011-09-20T07:38:00.000Z

It's been three months since Apple revealed it's vision of the cloud to the world. After its introduction, much was written (e.g. It Just Works) about how iCloud compares 'philosophically' with others, most obviously Google. Now, supposedly close to launch and with iCloud in the hands of developers, there seems to be surprisingly little written about how that philosophy translates into developing a modern iOS app.

Apple promises consumers that things 'will just work'. Just keep using apps in the same way and they will magically remain up-to-date across all your devices - in truth I'm not sure more magic was promised. Apple might be making a similar offer to developers. In principle iCloud means that an ObjectiveC developer with XCode can create and distribute apps containing this magical ingredient without having to learn any new skills, without having to develop any cloud-based components at all. What's more, with relatively little extra work, they can support the Mac as well.

Of course, even within the Apple eco-system, this simplified development model is only true for a certain class of app, specifically those where the user is essentially creating/editing a document that can be synced via the cloud. Nevertheless that class can cover everything from task management apps (like iNote) to adding personalisation features such as 'favorites' to apps that consume third-party web services.

As always there is a cost: no support for Windows PCs, no support for Android devices, no support for the web.

Without direct knowledge of the iCloud API it's hard to be precise, but one can guess at some of its key features. For example it seems likely that an app developer can read or write a document at anytime - a considerable convenience over talking to a web service that may, or may not, be accessible. However a model that provides such a convenience must, necessarily, introduce some additional conceptual wrinkle elsewhere, for example some form of asynchronous updates. To help with some of these issues, the iCloud framework seems to make heavy use of the concept of versions. According to John Gruber, versions also lie at the heart of the solution of another tricky technical problem; that of handling conflicting updates. According to Gruber, iCloud will not advertise the notion of conflicts, rather it will determine it's version of 'truth' in the cloud and push it to all devices. Although managing conflicts may be less common in day-to-day, single user environments they do happen and surely some apps (at least) will be able to access conflicting versions in the cloud and allow a user to interactively manage the merging.

There are alternative approaches to handling conflicts - for example you can do away with the concept of versions altogether at the expense of requiring online access whenever you wish to access a document. That approach - of having a single version of the document held in the cloud, accessed on demand and being updated at the level of every key-stroke - is already available in Google Docs. The truly dynamic nature of this approach is best demonstrated when a document is being shared and edited by multiple authors simultaneously - a feature that (based on what isn't said) isn't addressed by iCloud at all. But, just as I am sure iCloud will address shared access in time, Google is in the process of adding off-line access to Google Docs. It will be interesting to see how Google address conflicting updates.

It has been repeatedly stated that iCloud is more than just storage in the cloud; for example it involves computing deltas, pushing updates and client side version handling. Intriguingly iCloud has identified a generic set of operations that can be used across a wide range of apps. As such iCloud represents an abstraction of synchronised, cloud based app storage. It is an abstraction that presents a simple API to client based app developers on the one side and hides a complex combination of cloud based services and OS components on the other. It significantly narrows the range of technologies that an app developer needs to work with. Even the idea of having apps resolve conflicts has its merits; after all an app is particularly well-placed to present domain specific content.

if iCloud provides a useful abstraction, then I wonder how long it will be before somebody else offers an alternative, more open, implementation? Maybe it wouldn't have all of the advantages of iCloud - it wouldn't be baked into the OS and I don't imagine anybody would be offering it for free - but it could offer simplified app development while not being restricted to purely Apple products. In fact one could even envisage an HTML5 based SDK making it available to web developers. Of course Apple will have already thought of that...

Social DNA

2010-09-21T20:04:00.002Z

There has been a lot of discussion recently about whether Google has, in their DNA, what it takes to 'get' social.

Well I think I 'get' social but I'm not sure how much my life is improved by getting the news 30 mins ahead of everybody else and I'm pretty certain that I don't need to actually see people go through the arduous process of constructing a reply in real-time. So I'm well disposed to the idea of a 'social layer' that improves the processes I'm already familiar with - although a better analogy might be a 'social render' that can be used to fill in the gaps and smooth over the rough transitions.

A good test will be how Google contacts are handled.

Google contacts is a tremendous asset. With an Android phone, all you need to do is enter your Google credentials and your email, calendar and contacts are there. I've got an iPhone and, with slightly more configuration, you can do the same thing. The thing is that Google contacts was a the right place at the right time. Originally my contacts were in Outlook and then, via some complex synchronisation story from Plaxo, they ended up in Google. I can't see a compelling reason to move them. Sure I can think of some 'nice-to-haves' but most of the alternatives have fundamental flaws.

For example, could I use Facebook instead? On Facebook I don't have to worry about changes to my friends' contact details - I see the updates pretty much as soon as my friends make them. Very nice to have. But, at the moment Facebook, doesn't handle all those contacts who don't have a digital presence, and there are - and will remain - plenty of those.

On the other hand it would be nice if Google could, for those of us that have defined a profile (even if it was only to test out Buzz) provide some sort of live link to those of our contacts that have also defined a profile (and set suitable sharing options etc etc). Technically it wouldn't appear to be that hard, afterall it's a basic construct of something like Facebook. Clearly there must be hidden complexity because it wasn't built in at the start that relates to the number and range of services that Google offers. For example it was only recently that your profile could be properly tied to Picasa web albums.

Of course Google might have no intention of beefing up 'contacts'. Maybe they will build on top of the Buzz infrastructure and provide a new way to add contact info into the list of people you are following. But that would seem to increase the 'conceptual count' yet further.

Personally I'm looking/hoping for my contacts to become more intelligent and gain a social element and for that enhancement to carry across to my phone.

On an unrelated note, how does 'social DNA' compare with 'the selfish gene'?

Why do I do it?

2010-09-18T19:24:00.001Z

I don't blog much and I'm curious as to what, on those odd occasions, finally drives me over the edge.

It seems to be a desire to clear my head of some on-going irritation or a minor thought that just won't go away and needs to be expressed. Writing it down seems to be a way of exorcising it - just like writing a note to myself and leaving it on the kitchen table helps me sleep if I'm travelling the next day.

Of course blogging about it brings in the dubious advantage of turning the whole process into a public display. There is a possible upside - the right to wear an "I told you so" T-shirt when the rest of the world realises that you really did identify the crux of the problem and offered a simple "Why don't they just...." solution. The downsides seem rather more numerous and more likely; people are privy to the odd things that bother you and, worse still, you're not even right about them.

I write this because I feel a deep resevoir of irritations developing that will need release in the near future.

But, in an attempt at some level of objectivity, I need to look back at my January post. It was written just before the launch of the iPad.

T-shirt score to date : zero out of one.

The iPad did not have a revolutionary approach to content input - more importantly it didn't need one. It was already significant for being a better way to consume [various types of] content. Why wasn't that enough for me?

Can they do it again?

2010-01-18T21:01:00.002Z

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

2006-01-12T00:10:00.000Z

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'

2005-11-17T18:12:00.000Z

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

2005-10-27T23:24:00.000Z

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

2005-10-27T12:33:00.000Z

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

2005-10-17T14:06:00.000Z

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

2005-09-23T22:19:00.000Z

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

2005-06-05T12:07:00.000Z

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

2005-06-05T10:55:00.000Z

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

What Unicorn? - an hReview

2005-06-01T20:17:00.000Z

What Unicorn? - an hReview

Jun 1, 2005 by adrian cuthbert Blade Runner

★★★★★ I managed to see the director's cut of this film with an individual who asked at the end 'What Unicorn?' - you know who you are!


<div class="hreview">
  <h2 class="summary">
    What Unicorn? - an hReview
  </h2>
  <abbr class="dtreviewed" title="20050601T2121">
    Jun 1, 2005
  </abbr>
  by <span class="reviewer fn">adrian cuthbert</span>
<span class="type" style="display:none">product</span>
  <a href="http://www.imdb.com/title/tt0083658/" class="item url fn">
  Blade Runner
    </a>
  <blockquote class="description"><p>
  <abbr class="rating" title="5">&#9733;&#9733;&#9733;&#9733;&#9733;</abbr>
I managed to see the director's cut of this film with an individual who asked at the end <i>'What Unicorn?'</i> - you know who you are!</p></blockquote>
</div>

Generated using Ryan King's hReview Creator

What Unicorn?

2005-06-01T18:41:00.000Z

Blade Runner is one of my favourite films.
Tags: this_is_an_hreview_2

    <p>     <a href="http://www.imdb.com/title/tt0083658/" rev="review">Blade  Runner</a> is one of my favourite films.          <br/> Tags:           <a href="http://www.technorati.com/tag/this_is_an_hreview_2" rel="tag">this_is_an_hreview_2</a>    </p>

A Review of hReview

2005-05-06T16:49:00.000Z

microformats may well represent a path from where we are today to the [lowercase] semantic web. If so, one of the first waypoints along such a path could be the emergence of aggregators capable of taking advantage of suitably marked-up content.

Applying a 'microformat' approach to tagging, Technorati introduced the rel="tag" approach to marking-up tags. Technorati also supply the corresponding aggregation service, e.g. see posts tagged with microformat. Given this minimalist approach to tagging, the hReview specification comes as something of a surprise. It seems to represent a format developed independently of the environment in which it is most likely to be used.

The rel="tag" approach makes a major, simplifying assumption. This is that the tag refers 'to a major portion of the current page (i.e. a blog post)'. I am assuming that it could apply equally to a blog entry in an RSS/Atom feed. Thus an aggregator can associate a tag with two pieces of metadata obtained from its context, namely:

title: the title of the web page/blog entry
permalink: the URL for a web page or the 'alternate' link for a blog entry

This approach can be extended in a minimal way to support reviews, all that is required is:

review: a mechanism to indicate this web page/blog entry is indeed a review.
review-target: a mechanism to identify what is being reviewed.

The first requirement could be handled with a tag. Obviously not the hreview tag itself, but maybe a this_is_an_hreview_2(*) tag. I've added the '_2' because clearly this doesn't represent an hReview in any formal sense. With such an approach the underlying assumption is that the review is the enclosing web page/blog entry. However the hReview specification wants to identify the limits of a review far more explicitly by having an enclosing element with a class="hreview" attribute. Although this permits multiple reviews per web page/blog entry, it seems to raise the bar unnecessarily.

The second requirement is more complex. The hReview specification says that a "universal object identifier" is out of scope. I can understand the reluctance to get into the quagmire of trying to define a universal identification scheme, but it does seem essential to the entire process. Furthermore a 'good-enough' solution to get things started would appear to readily at hand: by adding rev="review" to a hyperlink, a web page/blog entry indicates that the destination of that hyperlink is the subject of the review. The linked page SHOULD exist and it is the linked page that identifies the reviewed item. The link label provides an optional human readable version, e.g.

<a href="http://www.imdb.com/title/tt0083658/"
   rev="review">Blade Runner</a>

<a href="http://www.amazon.com/exec/obidos/ASIN/0345404475/"
   rev="review">Do Androids Dream of Electric Sheep?</a>

<a href="http://developers.technorati.com/wiki/hReview"
   rev="review">hReview</a>(*)

If one wanted to pursue the tagging parallel to its own English-contorting conclusion then you could use rel="review-target" instead, thanks to Edward O'Connor for putting me straight on this.

Obviously reviews of the same item should link to the same page. Providing a general purpose solution to this problem is not trivial. However offering a set of conventions that cover a large percentage of cases is very much easier, especially if we are prepared in the short-term to single out and use indexes such as Amazon and IMDb. Looking forward, some of the 'value-add' of an aggregator would be their ability to identify 'related' review items.

The hReview specification goes on to detail a good number of the components typical to a review, including a star rating scheme. All of this builds on other microformat work where possible. For example the reviewer is identified using an hCard. But it also seems to be reinventing some mechanisms. Permalinks are implemented by using a rel="self bookmark" attribute on a hyperlink that exists somewhere inside the class="hreview" element that points back to itself. While this opens up publishing reviews in simple web pages, it seems overkill for blog entries where a permalink mechanism already exists.

Obviously we all expect 'review' tools to be folded into blog authoring software once a consensus emerges. For example a separate field to input the name of a film/book/album that determines and validates a 'universal object identifier' before the review is published. See Alf Eaton's rvw! tool that posts reviews to del.icio.us for a taste of things to come. Nevertheless I can't help but think that I should be able to trivially publish a review today with my current blog authoring software if I'm prepared to add a few angle-brackets here and there. By way of experiment I have generated an example of a minimal hReview according to the approach outlined above. I'm not sure I would be able to do the same thing with the proposed hReview specification except with considerably more effort.

(*) obviously this post contains components sufficient to represent a review.

SmartLink Test: Event

2005-04-19T17:34:00.000Z

This is a test post in support of SmartLink of which more later...

I've encoded an event based on hCalendar, namely Web 2.0 Conference: October 5-7, at the Argent Hotel, San Francisco, CA

An example of a page with more events encoded in hCalendar can be found here

SmartLink Test: UK Address

2005-04-19T17:00:00.000Z

This is a test post in support of SmartLink of which more later...

Without giving away too much, here is my UK test address CB4 0WS.

SmartLink

2005-04-17T16:46:00.000Z

In a previous post I tried to describe how I thought technologies like SmartTags and AutoLink ought to behave. With greasemonkey in Firefox I've been able to build a proof-of-concept demonstrator. For the moment I'm calling it Smart~~Tag/Auto~~Link.

SmartLink is based upon the idea that content authors should mark-up content that can be 'smart-linked', using standard XHTML constructs. This has two advantages:

it effectively provides an 'opt-in' mechanism for content providers
it doesn't require 'magic' to identify what can be smart-linked and thus provides a much more extensible approach.

of course there is one fairly major disadvantage:

there isn't any suitably marked-up content out there, with the exception of some test posts I've put together for the purpose.

Getting Started

If you want to know a bit more about SmartLink then click here. Alternatively if you want to see how SmartLink behaves and you're using Firefox then you need to follow these steps:

If you haven't already, install the excellent greasemonkey Firefox extension. I'm running 0.3b, you need a version with the GM_log and GM_xmlhttpRequest objects.
Open up this user script (in Firefox).
From the "Tools" menu, select "Install User Script.." and confirm all of the various prompts
Check out this test post. You should see an icon at the bottom of the page with a link labelled New! SmartLink. Selecting this link will bring up a page allowing you to select how you want to view 'address like' smart-links. To see a smart-link select any option other than 'ignore' and click on "Update".
Now go back to the test post and wait a moment. There should now be two icons on the page, one at the bottom with a link labelled configure SmartLink and one next to a newly visible smart-link. Click on the latter to see a map.
Try it on additional test pages here (books + films), here (address + stock), here (address + stock again), here (UK address) and New! here (event - using hCalendar)

Note that preferences are stored in a 'SmartLinkPrefs' cookie with host http://www.myjavaserver.com/. [Please be patient, MyJavaServer can be slow. I know, I know...it could have been written in a couple of lines of Python but not by me.] Greasemonkey's ability to call out of the usual Javascript sand-box makes it possible to centralise the preferences this way. In addition, having a server-side component means that it is easy to add new types of smart-link and new options for existing types.

SmartLink Test: Company Profile 2

2005-04-17T16:44:00.000Z

This is a test post in support of SmartLink of which more later...

Apple

I found this address on their web-site:

95014

There are listed on the Nasdaq with a stock symbol of AAPL.

SmartLink Test: Company Profile 1

2005-04-17T16:38:00.000Z

This is a test post in support of SmartLink of which more later...

Google

I found this address on their web-site:

94043

There are listed on the Nasdaq with a stock symbol of GOOG.

SmartLink Test: Address

2005-04-17T16:34:00.000Z

This is a test post in support of SmartLink of which more later...

I've never lived in the States so when I'm short of a test address I always resort to Beverley Hills 90210, how sad is that?

SmartLink Test: Books and Films

2005-04-17T16:27:00.000Z

This is a test post in support of SmartLink of which more later...

One of my favourite films is Blade Runner, I'm pretty sure I prefer it to Do Androids Dream of Electric Sheep? from which it is derived.

Trying to understand Technorati

2005-03-11T09:12:00.000Z

So here's my Technorati Profile

AutoTag: AutoLink/SmartTags done right

2005-03-08T18:05:00.000Z

In all the debate about Google's AutoLink feature I've seen virtually nothing about how the AutoLink/SmartTag (AutoTag anyone?) concept could be made to work better with the notable exception of Don Park who was right on the money weeks ago Fixing AutoLink. Obviously there are points of principle that need to be debated; the right of an author not to have their content altered and allowing users to escape from a mass of inward-looking links.

But rather than complaining and hoping the problem will go away, how about trying to address these issues by building a better AutoTag?

Require authors to opt-in by requiring them to make their content explicitly auto-taggable. For example have them mark-up such content [see previous post]
```
<span class="autotag" type="address">
This is an address
</span>
```
The first time auto-taggable content of a particular 'type' is found, ask the user if (a) they want such content auto-tagged and if so then (b) which of a selection of services do they wish to link to.

An additional benefit of (1) is that it can be easily extended to handle different types of content - no need to code the magic required to identify content and its 'type'. Consequently it would be possible to identify both books and films by name.

With respect to (2) it should be noted that Google already provide access to a variety of mapping services, but they default the service to their own.

From my perspective as a user, there is a lot to be gained from AutoTag functionality done right. And it doesn't stop at linking up to remote web services. The same approach can be used to link from web pages to desktop applications. For example it is frustrating to have to cut information from a web-site and then paste it piece-meal back into a form to update contact/event information, especially when there are perfectly good machine readable formats to do the job.

Clearly it is unreasonable to expect a lone web-site author to do the work required to convert the human-readable information they have at hand into the arcane machine-speak required to talk to Outlook, let alone a range of desktop and service based apps. But perhaps the same author could be persuaded to wrap a few angle-brackets around what they know to be the crucial information. The problem could be solved with the help of a few remote 'helper' services that could accept text fragments, parse them and return suitably formatted and mime-typed responses.

I don't know how difficult it is to write an IE toolbar or a Firefox extension, but I'm hoping/guessing that most of the heavy-lifting is being done by the services that are being linked to. Thankfully there are mapping services that can deal with addresses and don't have to be talked to politely using coordinates.

What we need is a neutral switch embedded in the browser that can route auto-taggable content from the web-pages we view to the services of our choice.

Technorati tag: autolink

Semantic Markup and AutoLink

2005-02-28T18:45:00.000Z

RSS/Atom is the proof that, given the right incentive, people/systems can be developed to publish semantically marked-up content. Building the semantic web, however, seems to have fractured into two; build it using the correct technologies (RDF + OWL) or bootstrap it by encouraging people to semantically mark-up some of their content. Jon Udell, as far as I understand the argument, has been consistent and imaginative in his support of the latter. He has suggested that what is needed is some mechanism to reward those people that go through the pain of marking-up their content. I just wonder whether an appropriately implemented 'AutoLink' capability could do that?

The need for an 'appropriate' implementation is, in part, a response to the furore that has arisen from Google's toolbar (e.g. Dave Winer's Google's toolbar and content modification). IMHO this isn't a question of whether the reader is prepared to accept having the content they are reading modified, it's a question of whether the author is prepared to allow their content to be modified. One approach is to have authors explicitly opt-in by marking-up content that can be 'auto-linked'. For example:

 
<p>This is a small post that contains an address. 
I found the address on Google's web-site:</p>

<ul>
Google Inc.
<span class="autolink" type="address">
1600 Amphitheatre Parkway
Mountain View, CA 94043
</span>
USA
</ul>

(taken from Testing Google's AutoLink)

To quote Jon Udell's The Social Life of XML, this uses CSS to smuggle in the metadata. Explicitly marking-up the content to be auto-linked and giving it a 'type' has the desirable consequence that the author is adding some semantic content. The explicit 'type' attribute also has the significant advantage that the approach is extensible beyond the point where Google's magic is able to identify a context. For example films, books and companies could all be identified by name.

Adding new types of auto-link could be reduced to the code required to manipulate the marked-up content into a suitable query string and the URL of an appropriate 'helper' service. Nor would it be anymore difficult to add support for alternate 'helper' services for the same type of auto-link (as Google already does for mapping street addresses). Of course having services work more or less directly with the sort of content that an author has access to is the genius of the whole thing. For example street addresses are a lot easier to come by than lat/long coordinates.

Testing Google's AutoLink

2005-02-28T18:30:00.000Z

This is a small post that contains an address. I found the address on Google's web-site:

94043

My question is will people be able to auto-link it?
And the answer is YES!

Where is my Apple remote control? Ask Sony!

2005-02-05T11:58:00.000Z

In some quarters speculation has been running rampant about 'What is the hidden intent of the Mac mini?'. Some have pointed to the appearance of Mr Ando of Sony at MacWorld as being significant.

To my mind the missing ingredient of any truly distributed home entertainment system is the remote control. Using a remote to manipulate menus on your TV is just plain silly if you are trying to get music stored on your 'digital hub' to play on speakers in the kitchen. The remote needs to have a screen.

As well as a screen, it needs just a few controls to manipulate the menus - not a tabletPC, not a PDA with a stylus and not a mobile phone. Enter the gaming consoles. Who has user interaction with screen-based, domestic mobile devices sorted out better?

A Wi-Fi enabled PSP might be overkill but it would be a start. With a price in excess of $249 for the Wi-Fi option it also looks pricey, until you see what Sonos is all about and how much they charge for a remote (answer: $399).

What is a richer browser?

2004-12-03T17:10:00.000Z

In a recent Info World article Jon Udell makes the point that Firefox's success may persuade people to reconsider how they can build richer applications without throwing the baby out.

If part of the problem is 'managing complex interaction on the client' then perhaps the place to 'selectively and strategically enrich the browser' is at the level of an application controller? Something that can maintain client state between a pages.

Questions about embedding microcontent in an Atom feed

2004-08-25T17:12:00.000Z

Imagine I wanted to write a new type of aggregator that could extract microcontent from feeds and then present that content in a way different from a normal 'news' aggregator. For example I might want to allow people to include 'event' information in their feeds and have my aggregator provide a calendar-like view onto all the events it had encountered.

Does the Atom Syndication Format help me do that?

Lets make the simplifying assumption that there is some well-defined, commonly-used way of representing a calendar event in XML with its own mime-type (lets postulate text/vcalendar+xml). I want to include both this 'structured' microcontent as well as my usual 'unstructured' ramblings into a single entry. My question is how is such hybrid content supposed to be included in an Atom feed?

AFAICT entries in Atom may have multiple <content> elements. Thus you could include the calendar event information and the wordy bits in separate <content> elements, each with the appropriate type attribute. However my understanding of things I have read elsewhare (but I can't find them now so this may be madness <UPDATE> more below </UPDATE>) is that under such circumstances the aggregator should pick a single content element to deliver. A possible example might be an aggregator that is delivering to a mobile device with limited capabilities. Under such circumstances content of type 'text/plain' might win out over content with type 'application/xhtml+xml'. What it would do faced with 'text/vcalendar+xml' and 'application/xhtml+xml' is anybody's guess.

However the multiple <content> element route has other issues. For example I suspect most blog authoring software does not make it easy to deliver multiple content elements. Finally, even if they did, how does this approach handle the situation when the entry needs to reference a pair of calendar events? (or is the 'rel' attribute is available on the 'content' element?)

So I am driven to ask the question whether it is possible/legal/good manners to put structured microcontent directly into the XHTML content?

I have just found some words about consumers of Atom only rendering a single content element. However this is based on a content element with type 'multipart/alternative'. Taken from IETF Draft of the Atom Syndication Format:

If @type="multipart/alternative", @mode MUST NOT be specified, and content element MUST contain 1 or more content elements. These content elements MUST NOT specify @type="multipart/alternative" (i.e. only one level of nesting is allowed). Consumers SHOULD look at all alternative content elements and determine which one is most suitable, based on which @type and @mode the consumer supports, and preferences specified by the end user (if any). Consumers SHOULD NOT render more than one content alternative.

A remote control from Apple

2004-07-18T15:22:00.000Z

With AirPort Express Apple really have begun to show how a Mac sitting somewhere in the house could be a 'digital hub'. Music stored on iTunes syncs to a portable iPod or is beamed wirelessly to the audio system in the lounge. But I've got to go into another room to select a different album! So what I want from Apple this Christmas is a remote control

It could be boring; iPods already show how to control music on-the-move. So just put the same interface on some Wi-Fi enabled remote or maybe even provide some Wi-Fi add-on for an existing iPod. Alternatively...

Invent a new category of mobile device; a Wi-Fi enabled mobile client. Sure its got to be small and mobile, but if its use is restricted to 'in the home/office' it doesn't have to have the form-factor of a mobile phone that can be hidden in a smart suit, it could be more like a PDA - even a bulky PDA. But it doesn't have to operate standalone like a PDA. For a device that can be assumed to be always Wi-Fi connected, then lets make the simplifying design decision that it carries no specific user data at all. No more syncing, just access the data when you need it.

What would run on this mobile device? Obviously some cut-down iTunes controller/gadget, a way of reading my email, Spotlight to find stuff, a mobile version of Preview to read stuff, maybe even a VOIP client but also, I would hope, some sort of browser.

Although browser's don't offer the full richness of a desktop application, they do provide a remarkably flexible, good-enough solution to deliverying information. For example I would want access to the data in Address Book and iCal. People already have multiple interfaces to such data via the desktop, the .mac web-interface and even via an iPod. A web-like interface, albeit mindful of the reduced form-factor, is not impossible. Indeed Apple have precisely the sort of experience required to make a go of it. A browser-like environment might also give acess to some subset of all those gadgets that are going to be built for Dashboard.

Did I say 'No more syncing'? Well, not quite. Apple have done remarkable things to make syncing as seamless and painless as possible. Syncing to a .mac account offers both security and remote access. Maybe our Wi-Fi enabled mobile client could talk securely to a .mac account through any Wi-Fi hot-spot.

So, ideally before Christmas 2004, new hardware and an operating system to run on it, a number of new apps and 'small' web versions of others and integration with .mac. Doesn't seem too much to ask.

Architectures for 'richer' web applications

2004-07-01T21:14:00.000Z

Now that JavaOne is over (not that I got to go) and we are all more up-to-date with where Java is going, I have a simple question: as Java developers are we in a better position to develop web applications that offer a richer user experience? To this end I have developed a simple test scenario:

test scenario

I have a service that can provide the metadata for several thousand items (id, title, creation date, status, etc) and a service that can deliver an HTML description giving further details of an item specified by its id. I want to develop a web application that displays the metadata in a table on the left (allowing the user to resize, reorder columns etc) and the HTML description of a 'selected' item on the right. When the user selects a row in the table, the HTML description on the right is updated. As a complication the description may also reference zero or more other items. Selecting one of these links should update the both the description and reset the selection in the table.

I can imagine a number of responses:

Java WebStart: create a WebStart application using the JDNC table component and the JDIC browser component. The interaction between the two components would be defined in Java. While I have no doubt this would provide a fine user interface, I suspect that WebStart solutions are just not percieved as being 'standard' web apps.
JSF: create a web app using some [yet to be developed?] table JSF component. Altough a JSF table may be able to handle the reodering of columns and the like, the concern is round-tripping to the server each time to deliver a large table.
something else... my preference would be for a JDNC table component embedded in one frame (as an applet) and the item's HTML description displayed in a second frame and have the interaction between the two defined in Javascript.

Currently the last solution is not possible because JDNC components cannot be scripted. My understanding is that the resources were not there to both develop the components and a scripting solution. This post is something of a test to see whether there is any interest in trying to plug that gap.

WebStart and Web Browsers

2004-06-29T07:28:00.000Z

I posted the previous post (JDNC and Rich Internet Applications) to the JDNC forum and got a timely and well-considered reply from Mark Davidson. It has made me realise that I have completely failed to articulate what I find so attractive about the browser metaphor and, by extension, my perception of what a RIA should be.

RIA is an acronym I saw first used by Macromeduia in conjunction with its Flex product. But I have seen it more generally used by those with a server-side Java perspective, trying to describe what are essentially web applications but with a richer interface. There are a variety of technologies for doing this but most share a common architecture. Rather than delivering HTML, the server-side is responsible for constructing an XML payload (which typically includes both declarative and procedural elements) that is delivered (sometimes via a proxy) to the browser. The browser (or a plug-in hosted by the browser) then presents the application to the user.

To recap: as a server-side Java developer I swap all the capabilities of the user's browser (its handling of D/X/HTML, CSS, DOM, Javascript, plugins...) for somebody's proprietary XML dialect and hope for the best? Perhaps - if the company is big enough and has the resources and is spending the time (Microsoft, 2006+, XAML anybody?). If I had to categorise WebStart I would have to put it into this camp. The differences are that it is honest enough to do away with the browser and Java provides a hugely rich environment.

If I look at the applications I use day-in/day-out, there is a spectrum to how complex and interactive they are. What I am struck by is how many of them are now 'browser-based', despite all the compromises that must bring. Obviously this is also a matter of taste, but I am with those that do not believe that the browser has reached the end of its development. For the record, here is a list of things I use a browser for:

browsing ;-)
blogging (Blogger & Bloglines)
documentation/design (Twiki)
bug tracking (Bugzilla)
filling out my tax form (something from the UK tax office)

...and here is a list of things I don't do with a browser:

email (Outlook)
music (iTunes)
cutting code (Eclipse)
presentations (PowerPoint)

Obviously I don't always choose a browser-based solution for its user-interface. For example Bloglines has the advantage that it can keep track of what I've read, irrespective of where I've read it. Many of these browser-based solutions would benefit from a richer user-interface. Blogger, Twiki and Bugzilla would benefit from some form of 'text-editor' component, Bugzilla from a 'table' component and Blogger from a 'calendar' component.

There is an inherent attraction of having a number of browser-based applications; they can be seamlessly tied together. Its not just because its trivial to put a link on a page, but also because these aplications live in the same environment and follow the same rules (eg I can go back to that page, I can bookmark it, I can send a link via email, I can open it in a new tab). Finally browser-based applications often just plain look better. In an application where most of the information is read-only, the ability to easily control how that information is rendered is a big plus.

My problem is what is the way forward for a Java developer who wishes to offer a richer user-experience while retaining the benefits of a browser-based solution?

JDNC and Rich Internet Applications

2004-06-27T18:09:00.000Z

It seems impossible to find out whether JDNC (JDesktop Network Components) are really designed to contribute to the development of RIA or not. When used in a web-page, JNDC are essentially applets but they can be configured with the same XML configuration files as their desktop equivalents. Futhermore the components, because they are 'network' aware, can fetch their data from the originating web-site. Thus they have precisely the characteristics to make them a valuable component on a web-page.

But the documentation seems only too keen to point out the problems with using them on web-pages (variable Java support, longer load times, the need to reload after a page refresh). JDNC demos are all WebStart based and nobody is saying anything about scripting JDNC or allowing them to interact with other page content, be it HTML content accessible through the DOM or a Flash component. While it might be possible to drive JDNC components with Javascript (just because it can already speak to applets) the real question is whether they are designed to be scripted. For example can Javascript be used to scroll a JDNC 'table' component to a selected row or, more revealingly, can a row selection in a JDNC 'table' component trigger some Javascript?

With JDNC and JDIC Sun is obviously making a renewed effort on the desktop. But from the 'vision thing' point of view the most significant thing would seem to be Java WebStart. This brings many, if not virtually all, of the deployment advantages of pure web applications to the desktop. Whereas initiatives like JDNC and JDIC are [just] new tools for building conventional desktop applications in Java, albeit far more productively. But web deployable, desktop applications are not RIA. Where is the 'vision thing' for Java and RIA? It would have to be something that acknowledges the existence and importance of the web-browser as a primary tool of user interaction. With the web-browser comes a set of expectations related to choices and technology and the ability to combine them. If JDNC is part of a Java/RIA vision then it has to acknowledge that Java-based components, no matter how functional and how rich they are, are just that; components to be mixed and matched with any other Internet capable component.

[UPDATE] a reply to this post from Mark Davidson has prompted me to try an articulate things better in another post.

clevercactus share

2004-06-21T19:42:00.000Z

Congratulation to the people at clevercactus, there is now a public release of clevercactus share, described on the site as:

clevercactus share is a private and secure environment to share files with people you know.

clevercatcus takes something we all thought we understood, namely the internet, back to basics. Make it possible for pairs/groups of people to communicate directly with each other. No need for DNS, no need for FTP servers, no need for special handling of firewalls and the like. Just secure, ad-hoc, point-to-point connections between machines out on the edge.

the technology

Its Java based [UPDATE] using their own P2P framework, not JXTA, and they have gone to great lengths to provide a quality desktop look and feel. clevercactus has both desktop and web components. The desktop component installs itself nicely into your 'whatever it is called - bottom right on windows' bar. [UPDATE] It also updates itself, like JWS, but they've done it themselves and it looks much better.

the design

I'm intrigued if they ever considered an architecture with a WebStart deployed 'share' engine which installed itself on the bar with a basic start/stop popup-menu interface and then have the engine able to project a web-interface. That way they could have unified the web+desktop components. Maybe it was an issue of expertise, they certainly have worked very hard at providing a pretty Swing interface.

the niggles

I've used two versions of 'share' to coordinate data at home and work. However my current version (v1.38 beta) seems to show up some oddities of my office environment, maybe a flakiness of the internet connection. The problem is that 'share' looses its connection and doesn't seem to be able to enable it again - maybe this version doesn't try.

wishlist

There would appear to be a trend towards people having an excess of diskspace (I'm not storing movies yet) and a surplus of connection bandwidth (at least when averaged over 24hrs). This would support an alternative mode of sharing; basically synchronising a folder amongst a group of people. Rather than have people search and pull back from a shared folder on demand, assume that everything is wanted and pull it across when it comes available. A new person joining the group would come back n hours later and find the entire folder copied over. clevercatus share already seems to do much of the complicated stuff, retrieving a folder repeatedly over a number of days seems to keep it correctly synchronized and minimises the files transferred.

At last....

2004-06-02T08:24:00.000Z

At last Sun has released something that acknowledges the need for a Java response to rich internet applications. The article introducing Java Desktop Integration Components talks of a desire to bridge the gap between 'browser-based applications' and 'rich desktop applications'.

JDIC is just one of a number of Java technologies that can deliver on the desktop, Java Desktop Network Components is another. What is still missing is a clear vision of how all these parts are supposed to be used together for different types of application.

For what its worth, my own preoccupation is with RIA - a possible convergence of 'browser-based' and 'rich desktop' apps accessed through a browser. Sun has seeded the JDIC project with an HTML rendering component and that ought to make a difference, but it has kept to its WORA principles (will the Java Desktop ever get a preferred status?) Consequently the level of control offered is very high-level. Making an HTML canvas available to a Java app, rather than making Java available to the browser still seems to be 'inside-out'.

RIA and Mozilla

2004-05-11T09:21:00.000Z

With Longhorn, Microsoft are busy building a richer environment for delivering applications to the desktop. In the meantime some in the non-Microsoft world have been busy pushing the concept of Rich Internet Applications. Two of these (Laszlo System's presentation server and Macromedia's Flex) leverage the ubiquity of Flash. But the gamble that Microsoft is taking is that you really need to extend the browser. Microsoft need to deploy XAML compliant browsers to support their approach. In the same time-frame couldn't an open-source browser like Mozilla be extended to make it the preferred target for advanced RIA? Afterall it already contains functionality that has no equivalent in IE (e.g. XUL). And just how long will it be before there are more XAML capable browsers than Mozilla?

I don't want to tread on anybody's definition of what a RIA is - or how they compare to what Microsoft is planning to do - so let me just be clear about what I would like to see from a future Internet application as a user:

Easy deployment: I can access/invoke the application through a browser. A RIA may download/install software, ask for access to local resources etc. but the starting point is my everyday browsing experience. The more transparent it is, the better
A richer experience: this is probably more about removing some of the limitations that afflict pure web-based applications, rather than an absolute requirement for more 'richness'. Such limitations include;
- a lack of responsiveness - some essentially trivial but uncommon validation tasks require a round-trip to the server,
- difficulty in being able to dynamically update parts of a page,
- a limited set of standard 'widgets' available to forms builders.
An uninterrupted experience: ideally I should be able to continue accessing the application through the browser from which it was originally invoked.

and two 'nice to haves'...
Roaming personalisation: if the application supports some level of personalisation, then ideally it will move with me even when it is accessed from a different browser on a different continent.
Unfettered access: if the application deals with remote resources, then ideally it should be able to access them anywhere on the Internet and not be restricted to the source location of the application itself.

I feel a bit churlish writing this, I'm using the new Blogger web interface which has a 'Preview' function that works instantly and doesn't require a server round-trip!

I've been involved in some sizable web applications in my time. Although Laszlo and Macromedia offer to hide much of the plumbing and reduce my job to delivering LZX/MXML, I can't help but feel you cannot hide the browser/server connection. It has to be recognized for what it is. My preferred architecture probably borrows more from a desktop application. My version of an Internet application would be a browser download that:

takes responsibility for handling 'session' state,
interacts with the browser via events directed to it from the page, and an ability to inspect/manipulate the content of the page,
talks to remote web services.

Standards exist for much of this (DOM, update via DHTML, communication with web services via SOAP), the big problem is downloading an application into the browser. Essentially this is a downloadable application that uses a browser to present its user-interface rather than building its own. Compared with other browser downloads, the distinction is that it runs in the browser itself, not in an individual page. It's job is not to do simple things like validate user-input before passing control back to a server. It's job is to be responsible for the application as a whole, coordinating the various steps in the process, calling upon web services as and when they are required. These services can themselves be simplified; for example they may no longer need to handle state or presentation details, making them more usable across a range of applications.

I must now declare myself a frustrated Java developer. I've managed to prototype some of these ideas but there has always been a piece missing, a technical hurdle that is way too high. Java has an evolving story about talking to remote web services, and it just gets better. Java Web Start, IMHO, does a good job of downloading application code but then more or less forces you to use Swing for the user-interface. This would be better if you could include components that can handle HTML. However a better solution would be to have Java running inside the browser. I've built pages that dynamically fetch new data to update parts of themselves by calling upon the services of a featureless Java applet running in a separate frame, but the applet is sandboxed and cannot talk to the whole web. I might have been tempted to use James Gosling's JNN more (a minimal RSS reader with some nice layout and drag-and-drop features) if I didn't have to manage both its window and the browser window that needs to accompany it.

Is it possible to build Internet applications this way? Does anybody else want to?

What is the best way to coordinate data over the Internet?

2004-04-25T16:06:00.000Z

I've recently been subject to spam-like levels of Plaxo requests. Although Plaxo does some things I like (provides a remote copy of my contacts and a way to sync work and home contact lists) I would like to think there were alternative ways to handle the coordination aspect of what they do, i.e. keeping your contacts updated automatically.

If a number of users wish to coordinate data over the Internet, what tools are available to them? There are various ways in which a casual user can serve data; they could set up a web-site/web-service or join some P2P network. However if the problem is simplified to merely becoming a source of data then they can send it out as messages, the most obvious form being email.

I've seen estimates suggesting there are about 25 million web-sites out there, about 2 million users of some file-sharing network and goodness knows how many virus infected PCs that could act as servers to somebody. But Plaxo relies on messaging; you install an Outlook plugin which can update things automatically based on the content of Plaxo generated emails.

Is that really the best way to do things? Windows and Outlook is not for everybody, and requiring a plugin reduces the numbers even more, but that combination must rank pretty high in terms of numbers.

Somehow I find all that a bit depressing...