Archives
February 2007
2/28/07
2/27/07
2/26/07
2/26/07
2/25/07
2/24/07
2/22/07
2/21/07
2/21/07
2/20/07
2/20/07
2/17/07
2/16/07
2/15/07
2/15/07
2/13/07
2/12/07
2/10/07
2/8/07
2/7/07
2/5/07
2/5/07
2/3/07
2/2/07
Tech Trend I - Why do we still build clients?
Friday, February 2, 2007
February at AOL is tech trends month, so I thought a good first topic should be why we still build an AIM client.
More often these days, I am asked, as to why we still build an instant messaging client here at AOL. I talk to some of my friends at our competitors and apparently they are asked the same thing too. With WebIM APIs, AIM Express, Meebo, and GTalk's AJAX-y browser client, simple client functionality can make for an awesome experience in a browser these days. But that is just it..."simple functionality"...buddy list, IMs, expressions work nicely in a browser, what about things like peer-2-peer, image sharing, etc.
So why continue down the "Web 1.0" path by writing client code? I think client development is key when you consider advanced messaging features such as peer-2-peer functionality. While Flex is a better improvement in the flash world doing file transfer using https is, in my opinion not as performant. Being able to get machine specific information like MAC Address and gateway info allow the AIM Location Services to help us locate you. Audio and video work much better in a client for similar reasons.
The main benefit of client development, I think, involves application stickiness. Starting in the early days of AIM, by default, we launched AIM when Windows starts up, we automatically signed you in when AIM starts, and we stored your password (securely). All of this led to zero user interaction to get the client online and for them to be able to send/receive IMs. Yahoo, Microsoft, Skype, etc all have the same behavior. For web apps it is definitely more of a challenge. I clear my browser cache once a month, and I have to remember to go back to sites like digg, meebo, radiusIM. Apparently one solution has been to create toolbars. Facebook, Loki, and others have all created toolbars for your browser so you can interact with their product even when you are not on their actual web pages. I think toolbars are evil, but they are an effective way for web sites to be sticky apps.
So where do I think we're headed? Clients are not going away, but more and more traditional client functionality will move to the web. It makes sense that audio and video move next, as people migrate to fiber-optic connections and CODEC/Flash support gets better.
In an upcoming blog post I will share how a couple of our partners are taking our "client" apis and using them in a web world and some of the things you can do with WIM.
gregsblog at 10:00:00 AM EST Blog about this entry |
Add to del.icio.us | 
digg this
Tech Trend I - Why do we still build clients?
Nada Surf
February at AOL is tech trends month, so I thought a good first topic should be why we still build an AIM client.
More often these days, I am asked, as to why we still build an instant messaging client here at AOL. I talk to some of my friends at our competitors and apparently they are asked the same thing too. With WebIM APIs, AIM Express, Meebo, and GTalk's AJAX-y browser client, simple client functionality can make for an awesome experience in a browser these days. But that is just it..."simple functionality"...buddy list, IMs, expressions work nicely in a browser, what about things like peer-2-peer, image sharing, etc.
So why continue down the "Web 1.0" path by writing client code? I think client development is key when you consider advanced messaging features such as peer-2-peer functionality. While Flex is a better improvement in the flash world doing file transfer using https is, in my opinion not as performant. Being able to get machine specific information like MAC Address and gateway info allow the AIM Location Services to help us locate you. Audio and video work much better in a client for similar reasons.
The main benefit of client development, I think, involves application stickiness. Starting in the early days of AIM, by default, we launched AIM when Windows starts up, we automatically signed you in when AIM starts, and we stored your password (securely). All of this led to zero user interaction to get the client online and for them to be able to send/receive IMs. Yahoo, Microsoft, Skype, etc all have the same behavior. For web apps it is definitely more of a challenge. I clear my browser cache once a month, and I have to remember to go back to sites like digg, meebo, radiusIM. Apparently one solution has been to create toolbars. Facebook, Loki, and others have all created toolbars for your browser so you can interact with their product even when you are not on their actual web pages. I think toolbars are evil, but they are an effective way for web sites to be sticky apps.
So where do I think we're headed? Clients are not going away, but more and more traditional client functionality will move to the web. It makes sense that audio and video move next, as people migrate to fiber-optic connections and CODEC/Flash support gets better.
In an upcoming blog post I will share how a couple of our partners are taking our "client" apis and using them in a web world and some of the things you can do with WIM.
gregsblog at 10:00:00 AM EST Blog about this entry |
Add to del.icio.us | digg this
