James McKinney’s- Web Development News











Many web masters frequently state that Yahoo can’t make money from their traffic because only search gives you a way to effectively target advertising. Michael at TechCrunch recently got sucked into this idea too.
It’s a nice theory – just a pity it’s totally wrong. Yahoo (and other portals) don’t make much money from their traffic because they are obsessed with copying Google’s search-based advertising model. What they should have done was build a advertising system based around personalization – so they it shows ads to people based on the links they had previously clicked and emails they had previously read. That would play to their strengths rather than meaning they have to try & catch Google in search traffic.

Personalized advertising systems aren’t new. Amazon Omakase is probably the most widely deployed, but Amazon doesn’t really have the traffic base to make this super-effective, and Omakase is just used to advertise Amazon products. Personalization guru Greg Linden also built his own, similar system for Findory, also based on Amazon advertising inventory.



There’s the fact that the experienced internet users are unlikely to install the Comscore kind of software.

Shared computers are a big problem, too: Comscore keeps registration of the characteristics of the user who registered and installed the software. That means the usage patterns of families with shared computers cannot be reported on reliably. However, the fact is that there isn’t really a good way of measuring this kind of thing. Hitwise gets fairly accurate traffic data by buying traffic logs from ISPs, but that can’t show the characteristics of the individual users. However, I tend to trust the Hitwise traffic data more than other sources for general traffic trends. I tend to regard Comscore & Alexa data as “possibly indicative but not definitive, and always requiring further analysis”.



{March 20, 2009}   Comscore

Comscore is a media measurement site similar to Hitwise or the Alexa site rankings. They do a decent job, but people are beginning to take their data way too seriously for the accuracy that their methodology delivers.

Essentially, they (like Alexa) rely on users installing software which monitors which sites they visit.

That methodology means your samples are not (and cannot be) representative of internet usage.

For instance, most workplaces, schools and colleges have policies and security settings prohibiting the installation of this kind of software. That’s already knocked out a very large proportion of internet users from the sample.



Google Custom Search has recieved a lot of attention since its release. One thing I discovered while developing an implementation at work was exactly how customisable it is. It isn’t clear from the simple examples, but some of the more advanced examples and the documentation show how it is possible to do facet-based navigation of search results, refinement based on lables and more.

The other interesting development is its integration with Google’s AJAX search APIs. This means that it is possible to deeply customize the search results display. It also means that advertisments won’t be displayed (which may or may not be a good thing, depending on the application).



{March 10, 2009}   Dapper

Dapper is the newest of the tools I’m looking at today. I first became aware of it via a rave review on TechCrunch. Dapper is a tool which allows you to create an API for any website, and then combine it with other of these APIs (called “Dapps”) to build applications.

This is a very interesting tool: the ability to create APIs easily is a wonderful feature. It doesn’t yet have the ability to do “spreadsheet-like” features like adding columns of data, though.



{March 7, 2009}   Dabble DB

If you haven’t seen the DabbleDB 7 minute demo video it’s worth seeing, if only to make you wonder why traditional applications aren’t as easy to use.

While DabbleDB enables “citizen programming” it has only just begun to add the features to enable deep API integration with other sites.

There is a screencast showing their work in this area.

DabbleDB is currently using Microsoft’s Simple List Extensions to transport extra data in RSS feeds. GData also provides some of the structure richer APIs requires,, and I expect that the DabbleDB team would be well aware of that option.



{March 5, 2009}   “Mashup” applications

Current “Mashup” applications built using APIS provided by Google, Amazon, Yahoo etc do provide some of this functionality, but I’d still argue that:

a) The programming skills needed to build a mashup are far beyond what is required to build a spreadsheet, and

b) Mashup don’t typically feature the deep data integration that gives Excel its value.

I’m not claiming that going from mashups to deeper, easier integration tools is a paradigm shift, but I do think that if a mashup is the typical Web 2.0 applications then perhaps the ability for non-programmers to compose online applications themselves could be dubbed Web 2.1.



One of the reasons I started this blog was to explore some more speculative ideas. Online Application Composition (OAC) is one of these ideas.

To some extent this idea this is inspired by Chris Anderson’s post on embedding Google Spreadsheet in a webpage. The real trigger, though, was Google’s release of the GData API for Google Base. That got me thinking about the quantity of data which is likely to be stored in Google Base.

Once that data is there, though, wouldn’t it be great if it was usable to “citizen programmers” – those people who build towering applications powered by sheets of Excel spreadsheets. Sure – there are problems with applications built this way, but wouldn’t it be nice to have the option to do something like that on the web?



{February 21, 2009}   Enterprise 2.0: Data Syndication

While Web 2.0 technologies have become very wide spread in consumer-facing websites, many enterprise developers have struggled to find anything relevant to their requirements (apart from some AJAX based UI improvements).

We all know how useful Firefox live bookmarks are for keeping track of online documents.

I think this is the future for enterprise 2.0 – feeds get chopped up into standalone datapackets which are filtered, sorted, re-aggregated and subscribed to. Tools like ROME.Mano are already beginning to provide support for this kind of functionality.



{February 7, 2009}   Paging query results

It is often assumed that most users will not page through result sets. Preliminary analysis of these results shows that this assumption is not generally the case. 42.27% of all queries logged were “next page” requests. I was very surprised at this number, but some reading shows that it is possible this is correct. For instance, “Analysis of a Very Large Web Search Engine Query Log” looks at 1998 data from AltaVista. In that sample 32% of queries were for the “next page” of the result set.



et cetera