Web Parts ⊃ Portlets

To say “Web Parts are Microsoft’s ASP.NET technology for implementing portlets” would be correct, but grossly incomplete.  One key facet of Web Part technology is that we do not intend for them to be for portals and portals alone.  Our sights are set much, much higher than that.

Web Parts are there to give the user the power to put what they want, the way they want it, and a lot of applications can benefit from it. We already go beyond portals today by putting Web Parts into Windows SharePoint Services.  We’ll go far beyond that soon when Web Parts become available to any ASP.NET-based application. 

A standard means of site customization should be a basic right for users and developers alike — we certainly think so.

Conversely, if Web Parts are for every app, then a page full of Web Parts isn’t a portal.  A portal is a special kind of app that locates, aggregates, organizes, and presents resources (people, teams, knowledge, applications).  There are a lot of services and facilities in SPS designed to do just that (even moreso in “v3”). 

We’ve been very fortunate to have a happy working relationship with the ASP.NET team, and they’re going to try very, very hard to resist the temptation to call a page full of Web Parts as a “portal”, too.  They, and we, will be telling you that you can use Whidbey to build a portal, but you’ll need to do a lot more than write pages full of Web Parts.

Comments

• Anonymous
  April 04, 2005
  The Workplace Client Technology from IBM is an attempt to provide a similar solution to the concept you describe, but with support to Smart Clients. Where is Microsoft in the Smart Client?