Skip to main content

Information Overload - A parallel

So many feeds, so many blogs, so many web sites. And what do I face???? … an information overload!!!!

 

Trying to find out how to clean up the clutter, I came up with many suggested solutions. (Eg. Meme s, follow/track using twitter, Yahoo! Pipes, lifestreams, etc.)… and again I messed up.

I realized that the problem I faced is of “missing out something important”. i.e. I keep getting the feeling that if I don’t follow a particular topic/person using one or many of the above technologies, I may miss out something.

 

Pondering for some time made me realize that there is another similar scenario where information overload has occurred.

 

Consider journalists. They have been collecting decades, if not centuries of news items, information pieces which may or may not have been published. But kept with the hope that they may be useful at a future point of time. So they have gigabytes (or petabytes?) of information. This information is sometimes back tracked, images previously used have to be re-used. So they need to have these at the tips of the fingers.

So many companies such as Reuters must have faced this information over load previously.

 

Just a thought: Why can’t the tools used by these news companies be re-used to organize the information overload that we face?

 

Conclusion: Solve one of the problems, and we get a better understanding of the other problem.

 

By the way, does anyone know of the softwares used by news organizations? Parallel

Comments

Popular posts from this blog

So you have your website deployed in PROD ... now what ??

Posting on behalf of Usr.Web.Speed - My previous job had been to architect and develop websites for various customers. During that time my team and I have architected and developed various web applications mainly for enterprises. (But below info is not restricted to enterprises) Other than the usual development and testing tasks involved, our focus area was to abide by multiple SLAs. One of the primary SLAs was to provide the users of our websites a very low (usually subsecond) response time (or page load time). To adhere to this SLA, we did multiple activities, in code, process as well as infrastructure. These include (but not limit to) - Using best practices including (http://developer.yahoo.com/performance/rules.html) Determining the optimum number of calls to the databases, open connections, etc. Providing the fastest mechanisms to download associated content (such as stylesheets, JS files, etc. over CDN) And debugging the reason for the slowness of the websites, when ...