Thoughts on technology and social web

May 29, 2009

Google Wave and Live Mesh

Filed under: Uncategorized — Ravikant Cherukuri @ 4:49 am

Google released its new communication and collaboration tool called Google Wave today. Its an exciting piece of technology that could lead the web in the way we consume and contribute to social networks. It brings together e-mail, IM and social streams together into conversations managed and consumed from a single interface. Federating web conversations from third party sites gets to where friendfeed is today and what facebook wants to be. But the integration with email makes it instantly useful.

The most interesting thing for me was the real time nature of conversations. Characters are transferred as you type, photo sharing that looks very real time with thumb nails appearing before the pictures etc make the conversation seem real. Little things that will improve user experience. Real time collaboration is really cool and surely looks like the where things are going in Web 3.0.

Friendfeed does a good job of aggregating conversations from around the web. AlertThingy friendfeed edition uses the friendfeed API to provide a cool conversation interface in a desktop app. The wave conversation reminds me of that and then some.

Though not obvious on first look, there are many similarities between Google Wave and Microsoft’s Live Mesh. Live Mesh has a platform to collaborate and communicate. It lacks a compelling application that can demo its capabilities as well as the Wave demo. An application that is similar to the Google Wave could be built on top of Mesh. Would be interesting to see if something like that comes out.

Mesh works on top of entities called mesh objects. And the mesh platform provides a pub-sub platform for changes to the mesh object. This facilitates sharing and collaboration. Google Wave has the Wave entity and the blip entity that is a change to the wave. Both of them have some kind of pub-sub infrastructure behind them. Both of them provide a good abstraction to represent higher level entities in communication that will take social networking from being able to share blurbs and links to sharing objects with context.

May 14, 2009

Browser extensions as a service

Filed under: Browser SOA — Ravikant Cherukuri @ 12:26 am

I hate browser extensions. If you do too and you don’t need any more reasons to convince you they are evil, move on to the second part of my post.

PART I : EXTENSIONS ARE EVIL

I have been using Extensions/Add-ons for a long time to customize IE and Firefox and get more out of my browser. There are many good extensions out there that provide a lot of great functionality. But there are also a lot of malicious ones that caused havoc, the result being that extensions are viewed as security holes and people are wary of them. Add to that the fact that the IE extension programming model is primitive and gives every extension that you install the keys to the kingdom. Extension are a little better on firefox but either way they have a lot of downsides.

  • [IE] No sandbox in which the extensions work. They can pretty much do as they please. Brings down the trust level. Much better in Firefox.
  • [IE] Based on ActiveX. Yuck!. Again much better in Firefox with XUL and a JavaScript based programming model.
  • [IE]Most browser crashes are induced by extensions. Once they crash, the user disables them and that’s the end of story.Again much better in Firefox. Much harder to crash Firefox from a JavaScript based extension.
  • Makes the browser slow even when you are not using the extension. Applies to all browsers.
  • Extension developers have to write multiple versions of their extension for each browser.
  • Sucks to be in the old world of installed applications. Firefox again has an auto-update feature that can keep your extension up to date with new features. But still its not as good as being a service. IE leaves it to the extension writer.
  • Extensions don’t roam. You will have to install the extensions you need to all of your machines.
  • Extensions will not work on your mobile devices. Or even if your extension developer supports your mobile device, you will have to install each on your mobile phone.

Ok with so many headaches and low trust, people end up not installing (m)any extensions. Lets ignore the ones that come factory-installed for the moment. That’s a rant for another post. And remember its easy to disable extensions and toolbars even in IE from 7.0 onwards. So, pre-installing only elevates you to a spammer status.

PART II : SERVICE ORIENTED EXTENSION MODEL

Many of the same problems have been solved when desktop installed applications transitioned to web based services. If browser extensions can be provided as a service, it will be more acceptable to the end user and extensible for the extension (service) developer. Trust, distribution, ease of use, customization, roaming, discovery etc are problems that have been solved for the web.

Greasemonkey brought a new approach to extending the browser. Install one extension and add scripts that will enhance different sites. It has the potential of customizing different sites to your liking and mashing a few of them to see what you want, the way you want it. But I always felt that the experience Greasemonkey gave you is disjoint. There all these cool script that will work if you know that they exist and how to use them. But there is no common thread that will bring all these experiences together.

Bookmarklets are generally used to write one click helpers that extract data from the current page and process it in some way. For example,

    • Press This : take text from the current page and post it to your blog.
    • Readability : format the current page for readability (really good)
    • Favelet suite : reverse engineer a web site using the bookmarklet tools

With a combination of JavaScript injection, HTML 5 features like DOM Storage, cross document messaging and bookmarklets, it is possible to implement “extension as a service”. What does this mean?

  • Needs no installation when used as a bookmarklet
  • Can download extension applets on demand and based on context
  • Extension code hosted as a service
  • User specific extension data stored on the service
  • Can easily roam with the user
  • Same functionality for all browsers with one code base

More on the architecture of this service in a later post.

April 30, 2009

Walled gardens

Filed under: Social Networking — Ravikant Cherukuri @ 1:58 am

Wikipedia says

“A walled garden, with regards to media content, refers to a closed set or exclusive set of information services provided for users (a method of creating a monopoly or securing an information system).”

In context of social networks, these are the networks that will want you to stay in network by locking your information in network. Social networks are dime a dozen. Some are old and some new. Some are popular and some not so much. With innovation on steroids, how would a successful network retain its user base when what the user is looking for changes faster and the want (need??) for new ways to communicate becomes stronger by the day. I will move from MySpace to facebook (facebook to some other) in a minute if I am convinced that facebook gives me more.

When is a walled garden a good thing? Not after the party moves outside.  No wonder many social networks are racing to share and inter-operate so their users can party inside their network. There is an increased capacity of small companies to successfully out-innovate (and become big) any established player. At the same time, there is very little brand loyalty. People go to wherever it is hip to go today or whatever service provides them with the best service and rightly so. Any revenue model that depends on users staying in a walled network will not work. So, what can one do to keep users in?

Innovate. A good strategy but innovation within a company cannot consistently beat the distributed innovation that happens across the many startup garages and passionate minds. This distributed innovation will always win. It takes so little to start a service. Think youtube, facebook etc.

Acquire. Leave the innovation to the small and nimble guys and acquire them to build your service. Easier said than done. These rarely work. Individual pieces are worth more than the whole. Sure, the founders will make money, the big company that takes over will make some news. The probability of success. Especially guaranteed success is low. Hotmail was a good acquisition for Microsoft and youtube might prove to be for Google. But it is sure harder to pull off.

Partner. This is the model that many networks today are shooting for. Provide a platform for the small guys to innovate on. The small guy who used to reverse engineer protocols of the walled garden is the most prized asset today. Take advantage of distributed innovation and keep the users in your network with the diversity of content. But at the same time, open API could ruin your bottom line. Fewer banner ads as people are viewing your content via a different third party client. Sure. But its better than extinction. When you partner to share the innovation, you partner to share the revenue too. The hope is that you would expand faster and live longer. Win with scale. This definitely looks like a workable model.

I am a big fan of The Innovator’s Dilemma. Its explains why the leader in one generation of technology fails to lead the next even if they invented the next generation technology. Disk manufacturers are used as one of the examples. Today with the faster pace of innovation and easier path from idea to reality, this is truer than ever. The main reason for not making it in the next generation is that the leader is busy making money in the current setup and is reluctant to rock the boat.

Keep trying to disrupt yourself. Or somebody else will. Be paranoid. Keep your boat rocking. Linear plans are for suckers (or bell companies of the 70s). In fact, if you are making any money today, somebody is already trying to disrupt you out of existence. If you succeed in convincing your users that your old service is a joke and that they should use your new service that flips the current paradigm, good! You still have your users. If somebody else convinces your users, you are extinct.

Being open interop is not an option. Its necessary to survive. At the same time, openness should be coupled with a business model that can make money in the new world. An API to expose your service and build upon is good. But compelling features that bring users to your service should go along with this.

April 24, 2009

Build for the phone and port it to desktop

Filed under: development — Ravikant Cherukuri @ 8:59 pm

I am tired of the mobile applications that look like they are struggling to fit into the form factor of my phone. Equally (if not more) hate the desktop applications that think that just because I have a 17 inch screen, try to fit every inch with stuff I rarely use. And when a desktop application wants to ride on the mobile wave, they do the unthinkable and squeeze the monster into my phone. The result is multi level menus and challenging navigation with a square inch of space in the middle that you are interested in.

Its time to invert this. Build your app for a decent mobile device. Then port it to desktop. There is nothing I cannot do on my cell phone these days if the software is rightly designed. And desktop apps should grow up and work on the same principle of respecting real estate and appearing only when user attention is needed. I think well designed mobile apps can scale to netbooks and desktops pretty well.

April 22, 2009

Social networks on desktop (and phones)

Filed under: Social Networking — Ravikant Cherukuri @ 4:57 am

Its getting tedious going to all these social networks to check friend statuses. If you are new to this, its a major pain point/barrier. I am used to a Instant Messaging client running on my computer and popping up for conversations. Looks like this paradigm could stretch to social networks as well. Recently I tried out different clients that do this for you. Some is a limited and simple way and some look to do a more complete integration. Its funny to see that these tools are getting some attention now. We kind of made a full circle from desktop to web 2.0 and back 🙂
Below is the list of clients and the good and bad I found in them.

Digsby
Neat Instant messaging like interface and support a whole slew of networks. The interface is simple and usable.
Social Networks : Facebook/Twitter/MySpace/LinkedIn
Instant Messaging : Windows Live Messenger/ Yahoo Messenger/Gtalk/AIM/Skype
Email : Hotmail/Yahoo/Gmail/Pop/IMAP/AOL

This biggest down side is that they store your credentials for all these services on the server side. They do claim that they are stored in a way that cannot be compromised. But still, I am not a big fan of that. These credentials hold the key to our digital lives.

TweekDeck
Works for Twitter and facebook. Simple interface and limited functionality. But works for following your friends status feeds.

Seesmic
Works for twitter and seesmic networks. Not sure about facebook. Again a simple interface with limited features. Maybe this is all we need.

ScrapBoy
Similar to Digsby. An IM like interface. Supports Orkut/MySpace/Facebook.

AlertThingy
This is the most interesting client I found. Especially the friendfeed edition. Friend feed brings all the conversations your friends are having on the web to you. And AlertThingy gives you a desktop interface to that. Very powerful but a bit too complicated to see all that in one place for non-friendfeed users.

Yoono
This falls into the digsby category. nuff said.

Fring
I have been using fring for a month now. Integrates IM very well. with tweet.im and ff.im and a gtalk account, everything is delivered to your phone. But the interface sucks. My cell phone is not a desktop. The experience should integrate into my cell phone rather than simulate a desktop IM experience. Just my 2 cents.

There is still a lot scope for improvement here and i am sure there will be a lot more innovation. Compared to the IM evolution, the SN (Social Network) started with more open APIs thus removing the barrier of entry. New clients are free to innovate with access to a lot of SNs and so can instantly become useful. Compare that with the IM networks which did not evolve in that direction and as a result missed the bus on SN. Reminds me of the hard drive manufacturers in Innovators Dilemma.

April 7, 2009

Love the bar

Filed under: Social Networking — Ravikant Cherukuri @ 4:57 am

Have you seen the DiggBar? Looks like StumbleUpon and Reddit already had it but it still looks cool. So I started using digg :). Messenger Web Toolkit has a web-bar that lets you embed the Windows Live Messenger social coolness in your site. Its very well designed and looks great!

A tiny bit of Internet Duct Tape from my side and I have a bookmarklet that lets you have the Messenger WebBar on any page that you go to. Just add the link below to your Favorite Bar in IE or Bookmarks toolbar in firefox. visit your favorite site and then click on the toolbar button. Voila you have your social network that roams with you, a messenger web client accessible from anywhere for a quick chat. Still have a few more ideas to make this more useful… maybe later.

Looks like my blog doesn’t like bookmarklet urls. So here is a page with bookmarklet link.

April 4, 2009

Micro formats and web conversations

Filed under: Social Networking — Ravikant Cherukuri @ 4:56 am

Conversations on the web happen via e-mail/IM/posts and comments/groups/social network feeds/proprietary web sites/SMS etc. The meaning of the data transmitted is understood by the sender and receiver. The medium is just a pipe for the users to communicate.

There are concepts in a conversation that are more semantic. For example, on IM, I give my address to a friend. The fact that this is an address is lost in the medium I used to transfer the data. If that was preserved, my friend could have beamed that address to his smart phone and the phone would have mapped the directions for him. There are some things in the web today that work this way. For example, if I send you an email with a Jpeg, your email reader understands that its an image. If I send you a url, it indicates to you that its clickable. We take these for granted. Micro formats extend this model to higher level concepts.

Def “Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards.”

For example, take hCalendar. This can be used to represent a calendar event. For example (from the microformats.org wiki) consider this event:

<div class="vevent">
  <h3 class="summary">XYZ Project Review</h3>
  <p class="description">Project XYZ Review Meeting</p>
  <p>To be held on <abbr class="dtstart" title="1998-03-12T08:30:00-05:00">12 March 1998 from 8:30am EST</abbr>
  until <abbr class="dtend" title="1998-03-12T09:30:00-05:00">9:30am EST</abbr></p>
  <p>Location: <span class="location">1CP Conference Room 4350</span></p>
  <small>Booked by: <span class="uid">guid-1.host1.com</span> on
  <abbr class="dtstamp" title="19980309T231000Z">9 Mar 1998 6:00pm</abbr></small>
</div>

Which look like this in the browser:

XYZ Project Review

Project XYZ Review Meeting

To be held on 12 March 1998 from 8:30am EST until 9:30am EST

Location: 1CP Conference Room 4350

Booked by: guid-1.host1.com on 9 Mar 1998 6:00pm

 

This is human readable and machine readable. When you send this to a user in an IM, the user can read it and import it into his primary calendar with a click. Of course, the IM client can recognize that its an event and show you just the title and an icon to import or tell you if you have any schedule conflicts. There are many such micro-formats that are already defined for us to use. Like hCard for people and organizations, VoteLinks for opinions ratings and reviews etc. And you could always define your own.

One road block for microformat adoption in canned/server generated content is that traditionally content on web is treated as text and the authoring tools today don’t support (at least none that I know of) microformats. The problem is much more manageable for user generated content. When you are writing a blog you have handy tools to add images and links to your post. In an IM windows you have handy emote-icons. Why not have short-cuts to add data in microformats to the conversation. These can be saved by the consumer of the content and imported into other applications. As the microformat itself is HTML, there is always a default rendering if the receiving application does not understand the format.

Some scenarios I can think of that will benefit from this.

  • Drag and drop a outlook contact on an IM buddy. The buddy receives a vCard format data (that might look like a visiting card) that he could right click on and choose to file it.
  • On amazon.com you see a review for kindle that you want to share with your friend. You could send an hReview formatted review to your friend (without typing it yourself of course. Your browser can help you there maybe)
  • Share the location of a restaurant by sharing the geo location in the geo microformat.
  • Share a listing from craigs list with a buddy using hListing.

On the browser/IM client, tools to save and mine microformats will make it easier for users to collect these and share. Visual Studio like intelli-sense to make it each to express in terms of microformats and make it as easy as using emote icons in IM.

Interesting reading :

Microformats – Part 0: Introduction to Microformats
Microformats – Part 1: Structured Data Chaos
Microformats – Part 2: The Fundamental Types
Microformats – Part 3: Introducing Operator

March 30, 2009

Thin clients are here! yet again!

Filed under: Web 4.0 — Ravikant Cherukuri @ 4:55 am

Been a while since Oracle prophesized about the thin client and Web OS. The thin clients were supposed to be on a healthy diet of whatever the DB of that generation served as the backend. That was then. A decade of internet bubbles and innovation later here we are again. There is all the hype (and reality) about about netbooks and the iPhone. How will the cloud get into these gizmos now?

Win7? Android? OS X? The traditional OSes are scaling down for the netbooks and the cell phone operating systems are scaling up. But things on these devices or whatever the actual thin clients will turn out to be, need not be a scaled down or scaled up version of something else (more on that later). There is news that Windows 7 is scaling down to netbooks and a major effort is on from Microsoft to make Win7 run faster and better on smaller hardware. There are also rumors that android is the secret cancer curing, windows killer.

But is a scaled down or scaled up Windows/Android/Mac disruptive enough for a new world? We are seeing the cloud grow bigger each day to accommodate our computing needs. There is great innovation from the big companies (Amazon/Google/Microsoft) as well as many startups providing storage, processing power and many other higher level services to all who can consume them. Are the traditional OS paradigms, scaled right or not, suitable to take advantage of this awesome power in the cloud? There are some betting that they are not.

An OS with nothing but a browser that can run java script, a netbook with a broadband connection and a cloud full of goodies could bring in the new future if you believe in this vision. There are several OS shells that run in the browser http://g.ho.st, http://desktoptwo.com/, http://www.cloudo.com/,  etc are a few examples.

 

image   image

 

http://cloudo.com

 

http://g.ho.st

     
image   image

http://www.psychdesktop.net

 

http://desktoptwo.com

 

All of these are desktops running inside a browser with the session actually stored on remote servers. The applications provided include MP3 players, browsers (yes they run inside the desktop that runs inside your browser), RSS readers, word processors, spreadsheets and the works. By no means are these products ready for primetime. But the promise of the concept is hard to miss. And there are operating systems being worked on that would down size the OS to be Nothing but ‘Net.

All these could converge with the ever growing cloud to give us a context that roams with us from desktop to laptop to cell phone without losing productivity. Then again, this could all evaporate into hot air and we would be talking of the coming of the thin clients again in 2020. But it sure sounds like the pieces are falling into place this time around. 

« Newer Posts

Blog at WordPress.com.