Why iGoogle Is a Stupid Model for the Intranet Home Page


Friends don’t let friends model their intranets after iGoogle

Do you use iGoogle? I don’t. I played around with it once. I dragged a few widgets around the screen and thought, that’s kinda neat. Now, what was I searching for again?

Apparently there are some people that use iGoogle, judging by the outcry when they changed it slightly back in 2008. Maybe you use it too. But please, please, don’t use iGoogle as a model for your intranet home page. And don’t let a vendor sell you their uberpersonalizable drag-and-drop customizable widget-laden portal software. iGoogle is a stupid model for an intranet. Here’s why:

Jakob Nielsen Doesn't Like It
If Jakob Nielsen says users don’t customize, who are we to argue?


What’s that, you say? You change defaults? Okay, let me reword that slightly.


If they did, Google wouldn’t be willing to pay millions of dollars to Mozilla to be the default search engine in FireFox. Jakob Nielsen wouldn’t write articles about the power of defaults. And we wouldn’t have had to design the ThoughtFarmer Personal Home Page.

See, although people don’t change the defaults, they do have different needs, especially out of their intranet. And they have different needs even when they work at the same company. The HR manager goes to the intranet for different reasons than the accountant just down the hall, and for different reasons than an engineer in R&D or than a customer service rep in the call center.

This is where role-based personalization comes in, or audience segmentation. To deliver relevant content to each employee, the intranet manager needs to embark on a project to define the roles within the company, and then to define the content that needs delivered to each of those roles.

Our new Personal Home Page feature in ThoughtFarmer 3.6 makes implementing a role-based intranet home page a snap. And through Active Directory sync, managing the members of each role is usually a completely automated process. Watch the 69-second video demo below.

Oh, and if 95% of people don’t change defaults, why did Google come out with iGoogle? Because when you have 200 million users, that 5% is still a huge number of people. At your 1000-person company, though, invest in role-based personalization that benefits all 1000 employees, not widget-mania that serves 50.

Video: Personal Home Page in ThoughtFarmer 3.6


Join The Discussion

  1. Eric

    5% of 1000 = 50.

    iGoogle rocks. Deal with it.

  2. Chris

    @eric corrected that last sentence using your arithmetic; thanks for that. enjoy tinkering with your widgets

  3. Andre Speek

    You just nailed it right there Chris. A User friendly application is about understanding what the user needs, not about giving an overdose of functionality and hoping that the few things the user wants is included with that. Speed does not come from fancy technology but by delivering what the user needs when he needs it.

    And yes, role-based personalization is as important to any intranet application as is a remote control for your TV set; you can do without but you simply don’t want too.



  4. Steven Walling

    So I’m guessing you would extend the same thinking about iGoogle to the use of OpenSocial gadgets in other enterprise software platforms?

    I think role-based personalization is a compelling idea for the enterprise. But I can also think of more than a few enterprise software companies who’ve added customizable dashboards, both OpenSocial and not, in the last few years…

  5. Sameer Patel

    for the most part, what Chris said

  6. bex

    But that raises the question… how do you determine the optimal defaults for any specific role?

    The highly customizable portal-like interfaces do have one main benefit… if you discover better defaults later on, or a new task becomes important, it’s easier to reused what’s there.

    In other words, I’d argue that this level of personalization is best left to the “site managers” who try to create the optimal interface for users… it’s less important for users or developers to call the shots on what features they want in a personalization engine.

  7. Chris

    @bex that’s my argument exactly bex. site managers should be able to do intelligent personalization on behalf of the users, based on role. james robertson has a good piece that weighs the pros of both user personalization and audience segmentation: http://www.steptwo.com.au/papers/cmb_personalisation/index.html

  8. Carlo Aiello

    Drag and drop widget intranets are the present and future – maybe you should get busy and not miss the wave.

  9. Seth Gottlieb

    I totally agree with your points. I think that employees are even less likely to customize their intranet page than their iGoogle page. The intranet page can never compete with the amount of content and functionality that iGoogle can deliver. Plus, now that employees change jobs on average every three years, they tend to invest less energy in internal systems.

    I would also add customizable portals are more difficult to test and undermine the value of the Intranet as a communication tool (the administrators have less control over what the visitors see). Personally, I thought the internal “My Intranet” portal was a failed idea when I first implemented one back in 1999. Back then, it felt like we were hiding the lack of useful content with useless widgets like weather and stock tickers. Now, nifty AJAX technologies can only obscure the lameness of the idea for so long.

    I think a better model is to create a feed of intranet information that the employee can embed in other contexts: rss reader, gmail web clips, iGoogle… I am particularly interested in the idea of a Javascript gadget that authenticates and pulls RSS directly from the source to the browser. This way, semi-private company news can be integrated with other content on 3rd party customized portals.

  10. Chris McGrath

    Thanks for weighing in, Seth — nice to hear from someone who’s actually implemented a widgetized portal.

    ThoughtFarmer does indeed produce RSS feeds throughout, which can (at the administrator’s option) be made publicly available for embedding in other contexts. http://newtf.openroad.ca/features/feeds/

Comments are closed.