Saturday, December 20, 2008

So what is this Twitter you keep going on about?

Twitter is the one social networking / micro-blogging / status update service that I fully embraced this year and used extensively. At Web 2.0 Summit in October 2007, there was a lot of talk about Twitter, so I thought I really should give it a go, and once I got into it I was hooked.

I often describe Twitter as being like the status update feature on Facebook and you can choose to follow other people's or companies status updates and to restrict who sees yours (if you want). I, in fact, also have my status update in Facebook automatically whenever I update it in Twitter (except for when I am replying to somebody else).

First off, Twitter is FREE to use. They are looking at various Revenue models, but the base service is expected to be free for the foreseeable future.

Twitter is based around the simple question of "What are you going?". In response to this you can only use 140 characters. Whilst you can just answer this question, most people use it as a way to distribute thoughts, links of interest, and inform others what is happening in their organisation or the world (e.g. check out @stephenfry - yes, it's really him and @NZQuake for up-to-date New Zealand Earthquake information). There is also the option of sending replies to other people (e.g. @gianouts Loved your blog post today. Very inspiring) or to send them a direct (private) message.

Similar to a water cooler or coffee machine in the office around which there are a variety of conversations, Twitter essentially provides a place Online for those discussions. Many organisations also provide customer support and information through this mechanism, such as Telecom New Zealand, Epic Beer, CNN and Xero.

Whilst a user can update their Twitter status via the Twitter Homepage there are also a variety of other tools people have built that makes this easier and nicer to do from a variety of operating systems, web browsers and devices. I personally use Twhirl a lot of the time from my desktop which is a client very similar to the likes of an Instant Messenger client.

CommonCraft also have a very good and short (2:25 min) explanation of Twitter.

Since you initially start off following no people you need to find other people or organisations of interest to follow. They don't need to be people you know, in fact the vast majority of people I follow I have never met. Other people also do not need to accept for you to follow them (unless they choose this as an added security feature) so you are free to follow whoever you want and this is expected practice. Following people you know in real life does imho make it more interesting.
There are a variety of ways of getting started with people to follow, including:

You can find me on Twitter at - come along, sign up and follow me.

Sunday, December 14, 2008

Keeping up with what's happening in the world

The world of technology (in particular) is moving very fast. I used to surf the web looking for what was new on key sites, but then decided that I would rather have the information come to me rather than me having to stumble across it. I then subscribed to lots of mailing lists, but once RSS feeds arrived this enabled access to even more information in a manner that meant I wasn't drowning my Inbox (or having to set up numerous auto-filter rules), so I stopped subscribing to the vast majority of mailing lists. For the past year I have been using Twitter and RSS feeds as key methods for keeping up with what's going on. I now wonder what next year will bring and how Semantic Web technologies will change relevant information makes its way to me.

The key methods I recall adopting for the past few years in terms of keeping up with what's going on:

Surfing the Web, in particular:
  • Computerworld
  • Slashdot
  • Aardvark
  • TheServerSide.NET
Mailing List subscriptions
RSS Feeds (read all)
Reading Intranet sourced information
RSS Feeds (read most)
Reading Intranet sourced information
RSS Feeds (read some)
Coffee catchups with peers
Delicious (looking at links in my Inbox)
Reading Gartner, Forrester, Yankee Group articles
Coffee catchups with peers
Coffee catchups with peersSlideshare
Reading Intranet sourced information

Reading IEEE articles
Conferences / Vendor briefings
Reading Gartner, Forrester, Yankee Group articles
Conferences / Vendor briefings
Delicious (looking through network)
Ad hoc

Reading IEEE articles
Podcasts (particularly after a conference)
Reading Gartner, Forrester, Yankee Group articles
Conferences / Vendor briefings

Technologies such as Twitter have enabled me to keep well informed about what it going on going on in the IT space, and Yammer has been great at finding out what is happening at work to throw ideas around. A lack though of decent Information filtering tools has meant that it is not easy to keep on top of the water hose of information that is available. Semantic Web technologies will become more prevalent in 2009 (probably not mainstream though) and it will be interesting to see how these assist in sourcing information that I want to read from all over the Internet and maybe even summarising it for me.

How are other people sifting their way through the large amounts of information out there, and what tools and/or processes do you expect we will be using in the next few years?

Photo Attribution: Creative Commons - Will Lion

Friday, September 26, 2008

Clarity of Roles & Responsibilities is Essential

I have observed numerous times that a number of the key challenges encountered by many projects often boil down to one key root issue: Lack of Clarity around Roles & Responsibilities.

There are many facets of Roles & Responsibilities, each of which need to be clearly communicated, including:
  • People - who is responsible for what, and what deliverables are they tasked with. This may be an individual, group or project.

  • Technology - what is the responsibility of a particular technology component (or sub component) that is to be delivered as part of the solution. This needs to be addressed from a logical component (e.g. CRM) and a system perspective (e.g. Siebel).

  • Process - From a project delivery perspective, who is doing what tasks and what are the dependencies and constraints. In terms of implementing business processes or activities, what technology component(s) will be realising this.
Of the above, I have found that People and Technology are the key areas that need to be focussed on. Process does however help to glue everything together and identify gaps, primarily because it is looking at the solution delivery from a different perspective.


I have found that addressing the People aspect from a high level "RASCI" and a more focussed "Statement of Work" perspective works well, and helps to drive increased clarity early on.


RASCI models are very useful in terms of communicating in a simple manner where different People fit in and provides a high level overview of key stakeholders. For each deliverable it is worth defining the RASCI model:
  • Responsible - Who makes it happen?
  • Approve - Who needs to approve this?
  • Support - Who provides the expertise?
  • Consult - Who can add value?
  • Inform - Who needs to know?
There should only be one person Responsible, and any more than one Approver can be troublesome and for me raises alarm bells. For the other roles it is perfectly fine to have more people.

Statement of Work

In addition to RASCI models it is a good idea to have a "Statement of Work" established with each Individual, Group or Project. The key purpose of this is to clearly articulate what your expectations of them, and when you are expecting various deliverables by. I often do this via an email message asking them to confirm that they agree. Sometimes these are for a particular deliverable, sometimes it is broader and more of an overall engagement consisting of multiple deliverables to support an outcome. Sometimes there is a bit of to-and-fro, but in the end all parties have increased clarity as to what is going on.


Understanding the role each system plays in the architecture for each release of a project is key to providing focus, identifying the right people to get on board, and is often a key input into a Statement of Work (in particular for engaging an external delivery partner).

There are many approaches that can be used to determine the roles & responsibilities of a system, but typically starting off with a logical component view and then doing a system view is a good way to reduce existing system constraints polluting the architecture. Running Use Cases through these views also helps to prove the architecture (on paper at least). It is also often just as important to be explicit about what the component or system will not do.


Who is doing what tasks, dependencies and constraints can be well represented by a Gantt chart (or similar method). This helps to provide visibility of the tasks required to complete each deliverable and where it all comes together.

Going through business requirements line by line can be a tedious task (in particular when the document is 299 pages long like the one currently on my desk) and even more tedious is providing full traceability through to each system component to show where a requirement is being delivered. Whilst this provides great visibility for which requirements a particular component has a role in fulfilling, and being able to rapidly assess the impact of requirement changes, I have yet to see this managed well either during or post project implementation. I therefore tend to adopt a less rigorous approach to business requirements mapping and tend to use it as a cross check once the solutions are quite well evolved and essentially just tick off each requirement. Maybe I should revisit this approach...

Photo Attribution: Published with permission from unplain-jane

Saturday, September 13, 2008

Yammer & Enterprise Status Updates / Microblogging

Within the last week I have started using Yammer, a version of Twitter designed for companies. Yammer is based around the question of “What are you working on?” and the concept of only allowing users from the company's domain (e.g. to signup. This provides for an interesting closed community where people are willing to ask questions and have discussions that would not be appropriate to a public community (e.g. "Simon and I are hitting the ABC requirements hard this month... any suggestions/recommendations?").

It has been interesting to watch the viral infiltration of Yammer throughout the company. As people register they are prompted to enter in who they work with @domain ; an email is then sent to these people requesting them to register. Similarly a user can add Org Chart information such as boss, staff, assistant and these people will be sent an invitation to register. Unfortunately the invites are currently marked as Spam by our email system so many people will not be finding their invite that is residing in their Spam folder, but word of mouth is helping to get people onboard.

A number of the people who have signed up to Yammer have not used Twitter or a similar service before, so the concept is new to them and they are feeling their way as to what is appropriate to "yam" (I don't know what the offical term is to send a message on Yammer, but this sounds appropriate) about. It will be interesting to see how people end up using Yammer (if at all), and then whether somebody tries to close it down as not being an official internal communication tool for the company.

The Adobe AIR based desktop client is currently a bit too limited in functionality, but according to the Yammer User Forum an updated tool is on its way. I really like Twhirl for Twitter and have been using this for a while so any other client really needs to match this imho. Ideally I would like to be able to use Twhirl with Yammer.

Some additional functionality of Yammer is available at the cost of US$1 per user / per month, which whilst this might be suitable for a small company, the cost for a larger company will possibly be hard to justify. This is Admin functionality and includes being able to brand Yammer with your company's logo, ability to restrict access to IP address ranges, implement password policies, ban users, delete any messages and delegate Admin functionality.

Another option is with Twhirl

If this cost makes you cringe or you would like to host a Twitter-like solution yourself, might be suitable for you. With the beta version of twhirl v0.8.5 is also supported as a client.

I think this makes a very attractive alternative for corporates.

The next big question in my mind is, "When will Twitter release group and company-centric functionality?"

Saturday, August 23, 2008

Adobe AIR development (from a rusty developer)

Platforms such as Adobe AIR are making the Operating System less important; as I articulated previously in "Operating Systems are becoming less important to Consumers". I decided to have a bit of a play to see how easy it was to build an Adobe AIR application.

Getting the basics going

My first stop was the very useful Adobe AIR Developer Center, which contains lots of really good information (docs, videos, downloads, ...). I had already noted from a previous search that Aptana Studio (which I had installed) had an Adobe AIR plugin, so I installed that directly from the tool. That was nice and easy and I therefore had a working IDE up and running in minutes.

Information about the features of the Adobe AIR plugin for Aptana Studio can be found here.

I simply started a new Project, went with all the standard defaults, including the incorporation of a Sandbox application. Once the Project was created, I clicked the Play button in Aptana and it worked fine. It was just too easy.

I then decided that I would like this mini app to run stand-alone in Adobe AIR, so simply chosen the Export to Adobe AIR package menu item which then packaged up the application into a .AIR installation file. I then ran the .AIR file and it installed without a problem, prompting where to install and where to put Shortcut links. Nice, and it worked too!

I was not honestly expecting for it to work so easily, without having to tinker around with the IDE a bit or find a missing library. It was a pleasant surprise.

Now for something a little bit more useful

Once I had the absolute basics under control, I decided I would try and pull a JSON (JavaScript Object Notation) feed from the Blogger Data API and format it nicely. I found some code for this very task here (also snippets included below). The URL I invoked was of the form:

where blogname is the blog you want to retrieve, and myFunc is the name of your callback function that is passed the JSON object.
I copied the code into my main HTML page from the Adobe AIR sample, and found that whilst I could populate information into a tag and display it on the screen (see the "Loading" part below), that for some reason I could not display the resulting feed that was returned through invoking the API (see "Retrieve" part below). I don't know whether there is some limitation of Adobe AIR I don't know about or whether it was due to the way I was trying to do it. For some reason the callback of listEntries was not being called. Using callback functions allows you get around some of the cross-domain security issues you might encounter in typical client side JavaScript, hence I was keen to get this working.
// Show a "Loading..." indicator.
var div = document.getElementById('data');
var p = document.createElement('p');

// Retrieve the JSON feed.
var script = document.createElement('script');
script.setAttribute('src', 'http://' + query + '' +
script.setAttribute('id', 'jsonScript');
script.setAttribute('type', 'text/javascript');
On the positive side, this did however give me the opportunity to use some of the debugging capabilities built into Adobe AIR. By simply adding the following line to my main HTML file, this enabled me to hit F12 when the application was running to bring up the introspector:
The Introspector is a very useful tool for seeing the value of DOM properties and functions in a tree view, running console commands, changing values, and lots of other stuff. Through this I was able to manually invoke the listEntries callback and it worked nicely.

This example also demonstrated the use of a dropdown list, and this functionality worked exactly as per standard HTML.


Adobe AIR appears fairly simple to develop for and to create installation packages, and if you know how to do JavaScript you're 95% there. There may be a few quirky bits that you need to learn of what doesn't work, but this may simply be due to me doing something wrong. Aptana Studio also seems to be a suitable IDE to use for Adobe AIR development. All in all, it is definitely a platform I am considering playing around with a lot more.

Monday, July 21, 2008

OpenSocial as an alternative to JSR 168

OpenSocial came onto the scene at the end of 2007 but until now I hadn't got around to delving into it and I thought it was about time.

My first observation was that its name is actually a bit of a misnomer. I expected data portability for social data, but in fact this is not what OpenSocial is about, it is instead more akin to "OpenWidget" or "OpenGadget" (as many others have pointed out). This however is not a bad thing, it is just different than what I was expecting.

OpenSocial is the expansion of Google Gadgets across platforms, with the view being that once an OpenSocial Gadget had been developed once and used on one site that it would be able to run on another social networking site and easily access friends lists and other social information on that site due to the common API that OpenSocial mandates. If this all sounds very similar to JSR 168 / 286 and the concept of Portlets then you would not be mistaken (for more on JSR 168 see my earlier post titled 'Are Portal Servers dead?'). Similarly, Netvibes tried to get some standardisation in this space with their Universal Widget API (UWA) standard but this hasn't got much (any?) traction.

I believe OpenSocial has a lot more hope than JSR 168 and other similar efforts, largely due to the weight of Google behind it, but also due to some other very big players signing up (i.e. MySpace, LinkedIn, Plaxo,, Ning, Yahoo! and many more) and the standard appears to be rapidly evolving.

OpenSocial Gadgets can be considered the Web 2.0 equivalent of Portlets; they are typically more user centric than site centric, mashups tend to occur on the web client vs server side aggregation, and from a programming perspective it appears easier and more elegant. Coupled with a servlet backend OpenSocial Gadgets appear to be able to do everything a Portlet would usually be able to do, including Gadget-to-Gadget communication.

Just like Portlets require a Portal, OpenSocial Gadgets require an OpenSocial Gadget container. To start with I used iGoogle, which was very easy to add a new gadget to. I then decided that I would like to host my own OpenSocial Gadgets so I decided to try out an open source implementation from the Apache Software Foundation called Shindig. This is apparently used by a number of people but some reason I couldn't get it working for me; I suspect it has more to do with my PC than anything.

All in all, I think OpenSocial is definitely worth further investigation.

Key sites for further information:

Wednesday, July 16, 2008

Don't change too much at once!

I have recently been working on a large Architectural diagram that a significant number of people have been looking at on a regular basis and have followed through its evolution. I have been doing some large changes to this diagram, but rather than making them all at once I have staggered the changes across a number of versions of the diagram. There are a number of reasons I have done this, including:
  1. People often get overwhelmed if there is too much that has changed.
  2. The validity of the diagram as being a trusted reference is undermined if it is significantly changed with each release.
  3. People are often much happier if they are taken on the journey.
  4. Less noise. Fewer changes reduces the areas for debate and allows them to be rapidly addressed without the confusion of other changes.

Change can be good, but too much at once is often not a good thing. I have been treating the aforementioned diagram like a brand, whereby whilst it is possible to completely overhaul it, if you make small changes to it over time, you can take people with you rather than getting them to recognise something completely new today than what they were used to yesterday.

Whilst this may seem fairly obvious, it is a common mistake that people fall into. Changes on websites are another great example of where it is often best to do it in chunks and take people on the journey. Technology Operations teams are also often strong advocates of not doing too many changes at once, since identifying the root cause is much more troublesome if there is a lot that has occurred, and rolling back can be a major headache.

Change can occur in many different ways across all facets of People, Process & Technology, but a common theme across all of these is that change is best achieved through understanding where you are (current state), where you want to be (future state) and then planning how to get there (transition plan).

Balancing up how much change to do at any one time is an art and a lot of variables will come into play. A key variable will be the number of affected people, as will the cost of having multiple steps. Going straight from current state to future state may be feasible in some scenarios, but all I am suggesting is that in many scenarios this may cause more harm than good (and it may in fact cost significantly more due to brand damage).

Sunday, July 13, 2008

Barcamp Auckland 2 Synopsis

Yesterday I attended my first barcamp / unconference; Barcamp Auckland 2. Ludwig and his team did a superb job arranging this event. It was well organised and there were lots of great sessions that stimulated lots of thought provoking discussions.

A key aspect of barcamps is participation and it is not about 1 person presenting, but more about having discussions and debates. The agenda is created on the day with people putting topics up on the board they are keen to talk about and facilitate and it just flows from there.

For further information about barcamps / unconferences, check out:

I attended a variety of different sessions which covered topics such as IE8, OpenId, Social Graph API, Privacy, Productivity, Mobile, Predictive Markets, ...

I used Twitter as my journal for the day, and my slightly edited synopsis of each session is:

Tech Productivity
  • Music can help to focus but can also distract; familiarity plays a factor.
  • Discussion re collaborative Personal Assistant's. i.e. one PA which handles multiple people
  • Meetings should be short. Consider Taking the chairs out of the room helps to achieve this.
  • David Allen's books on productivity are being highly recommended. I must check them out
  • Interesting thought re de-prioritising emails if sent to multiple people and a response is expected. Mechanical Turk as a helper?
IE8 Action Plan
  • 1/4 of users in NZ still use IE6. Interesting stat.
  • ~30% more effort required to build for IE6, ~5% more to build for IE7.
  • There are ~18k long tail web sites in NZ that are expected to be affected by IE8, due its better adoption of standards
  • Google is MS's biggest early adopter for IE8. Beta 2 is due out in August.
  • discussion re how to get IE8 being used whilst getting rid of IE6. Ideas: disks in Herald, filler with ISP bill, break IE use on TradeMe (or more to the point, force action)
  • n-1 deployment is a consideration for many companies. This will hinder deployment of IE8 for many corporates.
Using Social Graph and OpenId to make registration easy
  • Social Graph API (rel=me) being discussed. Sounds very useful for prepopulating information.
  • Social graph API looks very very powerful.
  • Open ID adoption needs to be balanced with trust. People will still have multiple IDs. Mainly for people who live and breath the web.
  • Sxipper being suggested by a number of people as an easy way to prepopulate information and signing on
  • OpenID is largely been seen as a land grab at the moment from most providers
  • Banks not expected to use OpenID for a long time due to liability etc.
Mobile Applications
  • Symbian is 75% of Smartphone market. With recent OpenSource announcement this is big.
  • The impact of iPhone vs Symbian will be interesting to watch considering the large Symbian penetration
  • Symbian is write once, run anywhere; J2ME gr8 in concept, device fragmentation; Win Mob little market penetration; iPhone?; Android?
  • iPhone is impacting more apps being acquired for Win Mob Smartphones (i.e. it is helping drive a mindset for the public)
  • Mobile OS stats vary largely by region. High CDMA use in US is a huge factor. Asia Pacific large for Smartphones.
  • Phones in Japanese market are in fact generally pretty basic, but heavy usage and how phone is used different than other markets
Politics & Web 2.0
  • 'Click here to send email to' one click campaign marketing common. Politicians obligated to reply.
  • is a New Zealand prediction market
  • Prediction markets are a bit like Wikipedia whereby the power of the crowd will normalise malicious behaviour
  • is home of the NZ Virtual Election
Privacy in distributed social networks
  • How do we express to a site how we want _our_ info used? Privacy = Control.
  • People don't read Terms & Conditions for web sites. A Common T's&C's framework is being mooted (c.f. Creative Commons)
  • User should be able to express in metadata form how they want their data used. Sounds a bit like a looser form of DRM (eg. robots.txt)
  • Privacy Commons Metadata could be applied to object, service or whatever
  • Leasing of information for a certain time period is being used by Fireeagle.
  • Being open about Privacy can be used as a selling point for a company as opposed to hiding what you're up to.
Mobile Web Stuff
  • Targeted txt advertising
  • Different SMS providers in NZ have different levels of redundancy and performance. Ensure the provider will be able to support you.
  • A SMS message can automatically load up a page, config change settings or apps can be pushed as a SMS message.I never realised the power
  • There is a standard around concatenation of many SMS messages, and most phones handle this nicely
  • Developers are wanting the ability for certain content to be zero-rated on a mobile network and to pay the mobile provider separately
Overall, it was a great day and I will definitely be back!

Saturday, May 17, 2008

Operating Systems are becoming less important to Consumers

Even a few years ago when buying a computer I was only concerned that it would run a Microsoft OS and that I could put a small Linux partition on it too. The thought of buying an Apple Mac never even crossed by mind.

A key consideration used to always be that there were lots of applications I wanted to run and that in general they were only built to run on the Microsoft OS. In today's world however I no longer think this is the case. Sure there are some apps that are only built to run on one Operating System, but with more and more services moving into the cloud, the Web browser is increasingly becoming the key application many people use.

For servers the Operating System has a larger role to play, but for standard consumer computing it is less important.

Platforms such as Adobe AIR and JRE are also aiding this shift away from the Operating System being so important. These platforms are enabling the ability for applications to be written once and run easily on multiple Operating Systems (or in some cases with a little bit of tweaking but not much).

The role of the consumer computer is changing, in many cases it is only to put "stuff" in the cloud and get "stuff" out of the cloud. With Platforms evolving that can reside on multiple Operating Systems, applications are truely becoming portable.

Familiarity, Marketing & Cost are also key factors that affect Consumer choice. It will be interesting to watch this space.

Thursday, May 15, 2008

Are Portal Servers dead?

Several years ago I was a big fan of Portal Servers (in particular for internal use), and I thought that were going to take off as the standard for public-facing sites (in particular with the release of JSR 168). This however has never eventuated.

I have therefore been asking the question for the past few years of whether the use of Portal Server technologies for public-facing sites is worthwhile, and if so for what sites (or subsets thereof). I am not questioning that the business concept of B2C, B2B, B2E, etc. portals is required, but rather whether the technology platform of Portal Servers for public-facing sites is overkill.

Portal Servers typically perform a number of primary functions (but there are other alternatives), some of which an organisation may not care about:
  • Integration with Authentication / Authorisation framework
  • Templating
  • Personalisation
  • Facilitate application/portlet reuse
  • In-context content management
  • Analytics & Reporting
  • Search
  • Ability to delegate control over part of a site / page

For intranet sites, I think Portals have a place, but I am not as convinced for other sites. So what do you think? Where do you think it makes sense to use Portal Servers (if anywhere)?

Sunday, May 4, 2008

Cultural differences

Understanding how people work and what motivates them is important to getting the most out of them and having a good working relationship.

I have been working with an offshore company for the past 6 months in New Zealand, with whom we have partnered to do some work to build a technology solution. Over these past 6 months I have observed some differences in the way they operate than what I have previously experienced working with New Zealand companies, and once I had identified these differences this has made it easier to communicate.

Having different cultures brings different dynamics to a project, which is great in terms of having people who look at a problem space from a different perspetive; these are my observations with this particular company and the people we have on the ground in New Zealand.

1. Safety in numbers.
In general, with many of the people I am dealing with (in particular the technical people, not so much with the Business Analysts), I have observed that they are not willing to voice their concerns in a 1 on 1 situation. They are however very vocal in a 1 to many environment where they can use the "power of the mob" behind them. Previously I have in fact observed the opposite with some other cultures.

2. Don't document unless it's 99% correct.
I have heard numerous complaints from the New Zealand team about lack of quality of documentation, but when I stepped back and thought about it, it became apparent that the offshore team (in general) were not willing to document anything unless it had been agreed already as being correct by:
a) the Business Owners, and
b) their Company (i.e. the Company is acknowledging they can implement it and will stand behind the solution).

I am used to Solution Architects documenting assumptions, passing this off to a Business Analyst to confirm / deny, and in parallel continuing to drive detail into the document. This is not the model which the offshore team I am currently working with adher to, so understanding this and continually encouraging them to work in this way is the current plan of attack. I have now also changed my approach to provide them with working assumptions to work to, whilst "behind the scenes" work is done to get the assumption ratified.

3. Only take something as being agreed if this has come from somebody high up the chain of authority.
Another common complaint I hear is that the same question is being asked yet again. Until this question is answered by or signed off by somebody who is deemed by them as having sufficent authority, it appears that they will continue to ask the question.

4. Only document as much as is required to keep people happy
All too often the New Zealand culture for IT projects in corporates is to document the solution up front in minute detail before commencing to build; this obviously has its pros and cons. With this particular project we are following an Agile-like methodology, and from what I have observed so far, I think they are working on the assumption that once they build something and present it back to us that:
a) we will be changing our mind about some things, and
b) testing will identify any problems.
With this in mind there is indeed a reasonable amount of detail being documented in some areas, but other areas are reasonably open for interpretation, and therefore it is expected through multiple iterations these areas will be ratified; which in many ways I think is actually a good approach.

Monday, April 28, 2008

Facebook Chat has the potential to disrupt the current IM landscape

I have used Facebook Chat a few times now and think it is only an update away from disrupting the incumbent Instant Messaging products (MSN, Yahoo!, GTalk, ...).

With the introduction of Facebook Chat I have found myself in discussions with people that I do not currently have on any of my IM clients and haven't chatted to in years other than very asynchronous messages now and then. Due to the large community of Facebook I think this has the potential to therefore really be useful to many.

Facebook Chat currently relies on a user having Facebook up and this being the current focus, but as soon as:

a) the web client is unleashed from this constraint,

b) Facebook provides an alternative desktop client and/or message alert, or better yet

c) Facebook opens up the API for all

then I think we will see a decline in IM client use or IM client vendors rapidly trying to provide a frontend for Facebook.

With Microsoft's investment in Facebook, perhaps there is already work going on behind the scenes in this space already.

Sunday, April 27, 2008

First blog post

I thought it was about time that I created a blog to ramble on about technology, trends in the Online space, Social Media, and anything else I felt worthy of writing about. Yeah, yeah, I know I've been a bit slow off the mark to create a blog, but I'm finally here!

I've written a couple of posts over at previously and will continue to use that for my postings on Food & Wine.