Sunday, 30 March 2008

Using Google to buffer and/or archive RSS

I have ended up using both Google Reader and Netvibes to monitor RSS feeds. Google Reader is great for long-term stuff whereas Netvibes is great for monitoring what has changed recently. Netvibes also offers other functionality that I find more useful than iGoogle for generating an online desktop.

Whilst learning Chinese I have found a number of things I can monitor by RSS that yield a high number of results, many of which are of no interest but there are the occasional gems. I tend to call these type of feeds "potluck" If I have time I can always trawl through them quickly and see if there is anything that interests me. One type of feed that can yield the occasional gem via online link tagging services, just monitoring the tag for "chinese" for example can sometimes give me useful new resources. Recently I started experimenting with the public universes offered by Netvibes. I also thought it would be useful to carry out the same sort of monitoring at and sadly I discovered that like many other online services, simply and ma.gnolia just do not provide good reliable real-time RSS feeds. The result was that many times my Netvibes boxes were empty. The easiest and most elegant solution to this kind of problem was simply to ensure that those kinds of feed were collected by Google Reader and then I made the RSS public from Google Reader. Now when I look at those feeds in Netvibes they are coming from Google Reader and whilst they may not be completely up to date they are never empty (Google Reader caches the information). Of course I can also combines feed and publish them as one from Google Reader.

Thanks to the new public Netvibes service I can make some of my "pot luck" feeds public, which acts as a nice way to demonstrate how this kind of RSS usage

As an aside I have often noticed that many of the less mainstream services are not consistent with the performance of RSS feeds (and searching). At the moment I wouldn't switch from to an alternative simply because nothing else I have looked at is anywhere near so reliable.

Blogged with the Flock Browser

Thursday, 20 March 2008

Email is not dead, it just smells like it.

Sometimes I think to myself there is little difference between Email and RSS (or I imagine ways in which I could manage my email in a way that might still make it marginally useful), I always come back to my senses though. Email is always going to be there and there is going to be a long tail of declining useage but I really try to interact with it as little as possible.

The real problem is seen in the use of email for communication in projects, both inside and outside of work. It really takes a lot of effort to manage email in a useful way, when discussions get multi-threaded and emails are copied, replied to, forwarded etc. etc. communication breaks down. Then of course there is the disaster that occurs when someone forgets to "copy in" someone else.

I was recently involved in a non-work project that involved communication by email and has now switched to use Basecamp already it is like a breath of fresh air.

Of course you need more than RSS to replace everything people do with Email, and elements of email can only look anything like RSS if you squint at it from a distance when very tired and forget to use one hemisphere of your brain.

Here is a tip, if someone at work sends you an urgent email, then try to ignore it for at least a day, If someone comes and actually talks to you help them as fast as you can, you can train them if you are persistent enough.

Blogged with the Flock Browser

Thursday, 6 March 2008

Blog post in a Chinesepod bottle

A short post this one but with a specific objective. The purpose of this this blog is primarily to act as a brain dump and thinking space, I am not aiming at attracting a readership (and on that measure I am succeeding admirably ;).

That being said It was interesting to note that some comments previous observations I made regarding problems with Chinesepod RSS feeds seem to have resulted in some action. I also noted a few hits from Shanghai in Google analytics. I was kind of expecting and hoping that this may be the case.

I would think that these days, if your online presence is important, then you should be spending some time peering into the dark corners of the web getting indirect feedback from discussions about you. It appears that the folks at Chinesepod have this covered.

I am curious to see if this post in an obscure corner gets read, it has some words and tags about Chinesepod, cpod and Ken Carroll that should do the trick. If somebody (anbody) from Chinesepod or Praxis reads this then please leave a comment, I will be very impressed and it will complete my experiment. The web version of the "message in a bottle" should in theory be much more discoverable than the traditional one.

Blogged with Flock

Saturday, 1 March 2008

Lies damn lies and web stats

Been a little while, but lots of things have been happening web-wise so I had better leave some thoughts here in case they fade from my mind (the main purpose of this blog is to prevent loss).

In my opinion if you have anything to do with web applications then it is absolutely vital  that your marketeers and sales people and the like are aware that web statistics are invariably generalizations, they are not exact and not usually fit to be treated in the same way as accurate financial accounts. This does not detract from their value but does mean that don't don't waste endless hours trying to account for tiny discrepancies etc.

Of course it depends what kind of analysis you do but increasingly people expect more than you get from the average server log. Many ways of getting very good information about your users are not 100% reliable, for example Google analytics provide a whole host of useful information but that depends on your visitor having JavaScript; This is not a problem if you accept that and make allowances for it.

There are many reasons why things may not sync up exactly, one that keeps haunting me is timestamps between different pieces of the system or between the database and the software application, not matching up exactly, other reasons apart from the JavaScript problem mentioned above could be down to cookie problems (or even absence of cookies), proxy servers (if you are monitoring sites accounts by IP address). data and links between data actually changing between the time of the original event and the processing of the statistics.

What can you do about it?, well if the processing is complicated and you have to tie a lot of elements together to cook your final reports, it seems that it is always more reliable to capture as much of the relevant information you need at the source, as it happens and then log that. For a simple example if you have a linking between an account and an IP address range then capture the user id and put it in your logs, as it happens. If you really have a pressing need to capture usage information 100% accurately then log each occurrence as it happens rather than trying to derive it from a url in your log.

Sometimes people treat web stats as absolute, this is not wise recently a number of people trying to sell us tools that included mailshot facilities proudly told us that their tool could track who actually opens the email you sent out 100% reliably. Of course they ended up looking a little foolish as they were talking about tracking the request of tagged images in HTML emails; which although it might be useful, is never going to be a 100% reliable method to determine if someone opens the mail you sent.

Blogged with the Flock Browser