I have long found Outlook a pain-in-the-butt to use and a few years ago switched back to Thunderbird (I had been a user of the Netscape Mail client in a former life…).

I find Thunderbird is much lighter and quicker at filtering mail than Outlook. There are better clients but all seem to have their own quirks which have kept me from adopting them.

The main difficulty with replacing Outlook with Thunderbird is that it lacked a good calendaring option. Incompatibility with the other Outlook stalwarts in my office meant I was forever having to ‘View Source’ on email bodies to see when a meeting was to be held so I could go and manually enter it into Google Calendar (my primary calendar which I share with my team). Fortunately I found the Lightning plugin to add a calendar to Thunderbird but I was still manually updating meetings in Google Calendar.

Now I have just come across this excellent tutorial on setting up what might be the holy-grail of calendar setups and want to share it with all Thunderbird users and frustrated Outlook users. Here is the short version of the tutorial for experienced Thunderbird users :

1. Install Thunderbird 2, RC1
2. Install the Lightning plugin so Thunderbird can read Outlook meeting requests and place a calendar in the Thunderbird interface.
3. Install the Google Calendar provider to allow Lightning to add two-way synching with Google Calendar.
4. Add the XML address for your primary Google Calendar (Found under “Calendar Settings >> Calendar Address”).

And you are done - test it by setting a meeting in the calendar within Thunderbird. You should see the meeting appear in your Google Calendar shortly (I had to manually refresh). More information at each the sites I have linked to.

Catchy title maybe; but hopefully anyone who is or will be experimenting with Twitter might consider this post and draw some value out of it.

The Steve Rubels and Robert Scobles of this blogoworld (notice its hard to refer to virtual domains, I keep choosing different ways to refer to the world of online information, I will continue to until I find one I like) are heralding Twitter’s importance via their virtual pulpits. After about a month of my own experimentation with the service I suggest tread with some caution when signing up for Twitter alerts to your phone or workplace IM.

For a basic description on Twitter see my previous post  ‘Tweets are the Ultimate in Disposable Content’.

Few of us have jobs which benefit from that much interuption and very little of the content available through Twitter currently could concievabley be relevant to our minute-to-minute activities at work. We cannot draw the same value out of the content as those whose jobs it is to evangelize web usage and cannot benefit from the immediacy of republishing new technologies the minute they hit blogland. I am not saying the hype around Twitter is necessarily wrong - there is useful or entertaining information on it but , like blogs it will be more useful to you at a time when you choose, for a task you determine.

As I covered in my earlier post, the value the author places on their own words is linked to the audience’s percieved value of the content. Lets put it this way there will never be twittershelves built for storing your favourite tweets from the Shakespeare’s and Dylan Thomas’s of our times. You will wait for them to publish a book and then you will buy that for your bookshelf because you know that a book will be the fruits of their considered thought and effort.

I think acknowledging that this will be how people value individual content items on Twitter will also will drive how people value Twitter overall. One of the key variables in the Twitter value equation is in the timeliness of the information - only timely information that truly provides value in being timely will serve the audience. This is not to say there wont continue to be a constant streams of banal chatter… it just means that this content will have an erosive impact on the audience - taking more from them than it gives.

To avoid being owned by your inflow of everyone’s presence information I’d suggest for now, switch it off. Then, have a think about what you will get out of it and how you might distill this information source down to an information flow that is there when you need it at a rate that will truly benefit you.

Steve Rubel has good suggestions about how to filter and utilize content (see his Gmail nerve center articles) however remember, he takes this stuff to the extreme. I don’t know enough about the particulars of his job to comment but for own jobs, I suggest thinking about what your job entails and determine how much of a need there really is to be up to the minute with all the comings and going of the internet.

Is this actually something you could catch up on once a week (or even a month!) and instead spend those valuable minutes or hours lost to Twitteruptions and use them to being productive in the actual tasks pertininent to you being a valuable employee (or betting on the dogs, whichever suits you best)?

I am interested in other people’s experiences with Twitter - let me know if you are using it, wont use it or stopped using it.

Following on from my previous post on the fast-food like properties of web-content I thought I would look at the service which embodies the latest acceleration in content consumption, Twitter.

For the uninitiated, a ‘tweet’ (as referred to in this post’s title) is a single message sent via the Twitter service. Twitter is a short-message system which can be accessed by numerous applications and devices; primarily, but not restricted to, web, IM and mobile. Messages are by default public and therefore you could think of it as ‘mini-blogging’ where messages can be posted as easily as sending an SMS or IM.

The rise of Twitter in the early adopting set (lets face it, it hasn’t hit mass market yet) has seen the introduction of a new, even more throw-away type of content. The plethora of states, moods and emotions punctuated by links to sometimes vaguely interesting content really leaves a faint impression. The experience lacks cohesion and any real filter determining significance or relevance of a particular content item. This gives it a sort of fun lightness and I guess the beauty of it is in the aggregate of the impressions you get from someone’s Tweets you follow.

There has been plenty of discussion on blogs about Twitter - all discussing what amounts to the same thing - does this medium have future? Not to be silent on the subject I do think it is a service which will be a place alongside other internet-mediums like blogs and IM. I think it will be in a form evolved from the one we know today - one of the reasons being that many currently heavy users of Twitter in this experimental adoption phase will stop or at least severely par back their usage of the service as they realise its capacity to cause constant distraction, fragmenting their thinking and to generally get in the way of Getting Things Done. I’ll touch more on this in a subsequent post.

Something I haven’t heard much in the current conversations about Twitter and that I think is important is that one of the key strategic strengths of the service is infrastructural - the link between IM and mobile network messaging and the web is a useful one which many applications will build upon. I think one of the players in the industry, whether Twitter or Jaiku or a new player to come (and regardless, likely to be acquired by one of the big companies) will benefit from owning a reliable set of gateways maintaining these links.

The direction the presence products will expand will be in their ability to filter and summarize the content they deliver - experimentation with Twitter and Pipes will be interesting as the service will need to overcome its procrastinatory qualities. With the internet already being the procrastinators achilies heel the last thing we need (and I am assuming I might be representative of at least some of us in this) is a stream of random information flashing on GTalk or our mobile phones constantly to distract us from what we are actually doing.

Where Twitter-like applications could come into their own is if they can combine the users current geo-location, mood or other information to tailor very relevant alerts to them. Currently however its like trying to work with firehose to the side of your face.

In the realm of written content there has always been a relationship between how much work went into the piece and the depth to which consumers engage with it. Now I know this may sound like a gelatinous concept but bear with me as I explain.

Books generally render deeper, more memorable experiences than magazines; magazines more than newspapers; newspapers more than pamphlets etc. But even these pulpier written forms will yield more attention (and retention) from the reader than content on the web.

The rise of the blog has introduced an even faster medium which is more catered to scanning and bulk consumption - sort of like reading’s equivalent of fast food.

The active nature of computer screens mean reading from them is tiring and the sheer amount of content available without the physical restrictions of the real universe mean content can be shifted and consumed much quicker. We write content so it can be easily scanned - we try to remove anything that might cause friction with the user getting our core messages. The messages themselves can be delivered in many ways, in bite-size chunks. You do not interact the same way with this information as you would a book or magazine.

To help picture what I mean - imagine working your way through the same amount of individual texts as you have in your most recent blog reading session and then imagine doing that using a paper-based media. You are in a bookstore, tearing through page after page, jumping from book to book like a maniac, leaving a wake of cast-aside material trailing behind you. You move through content like pacman through pellets.

The atomicised web-based content accelerates our desire to move through content quickly looking for small morsels of cerebral nourishment, each nugget of which can excite a brief sensation of satisfaction. These small rewards encourage a desire for more as well as an impatience with content that doesn’t instantly satisfy.

This is not to say that there is not great content on the web, there is plenty, but the best content knows what it is, it knows how much attention the user has to give - for similar reasons, McDonalds never tried to sell you McCaviar.

My prefered editor for Javascript is Aptana. I put up with the occasional slow performance of the Eclipse Platform which underlies it (it seems to hate dealing with windows network shares and vpns) because the IDE is very well thought out and works with me rather than against me.

That Javascript has an IDE at all shows that it has matured much since the early days of its inception where it primarily validated web forms, generally badly. With maturity in a programming language comes other things such as documentation. The preferred method of documenting API information these days is the *doc family of specifications and Javascript, through the efforts of the people behind Aptana I believe, has ScriptDoc.

ScriptDoc support is integrated into Aptana and helps the IDE make more sense of the very flexible syntax that Javascript supports - I certainly don’t envy the Aptana teams’ task of programmatically wading through the sea of anonymous functions, literals, prototypes in order to facilitate their IDE’s syntax highlighting, autodocumentation and outline capabilities.

Reading through the forums on the ScriptDoc site and through the specification I can see there is room for a lot more growth and development of this specification.

Something that we have found in our own Javascript development at Hitwise that we feel would be a valuable addition to the specification would be the ability to explicitly declare what the value of ‘this’ would be for a given function (or more specifically, method where a function is part of an object prototype). I will explain my rationale.

One of the ‘quirks’ (from an OOP perspective, anyway) of JS which is exploited to (sometimes) good effect by many of the key libraries about these days is the mutable nature of the keyword ‘this’.

For example, events (depending on whether they are native or ones augmented by a framework such as YUI) will define ‘this’ to be something other than the object prototype that you may have attached your handler function to. This means that ‘this’ can have different properties within callbacks to every other function you have defined for an object and can be therefore confusing (particular to those with OOP experience in other languages).

Indeed YUI and likely each other major library even allows you to explicitly define what the scope will be - they do this using some tricky closure syntax - I will often use this functionality to redefine ‘this’ back to the instance of the object where my event handler is housed to give ready access to the objects properties.

Of course sometimes, if there aren’t many properties you need to access it can be more convenient to access the element where the event occured through ‘this’ or in other circumstances even access some other arbitrary object and it is this reason that you are likely to see variation in what ‘this’ actually is!

When looking at a function and its documentation, you want to readily know what the available variables in the function scope are set to. The parameters can be easily documented and documentation for this across languages is almost universal. You also know that certain globals may be available and of course ‘this’. And most times you even know what ‘this’’s properties will be.

But if you are writing a callback for an XHR call or an event handler then you can’t be sure what it will be. If you are calling an existing callback which may have dependancies it would be great to avoid looking at the code and go to the API documentation to see what the callback would like ‘this’ set to. You could achieve this by defining an additional parameter or a custom ‘@this’ comment definition for your function could save you or your colleagues time in the future and make your Javascript API docs easier to grok. Standardisation of such a property would allow IDE’s such as Aptana to use this information in its code insight functionality to inform you of this requirement as you write your call.

With the general level event-driven programming required in most web development these days this would be a welcome time-saver and reduce the mental switching required to determine what ‘this’ will be.