REDMOND, Wash., May 6, 2003 — When Microsoft launches the Web-based collaboration environment Windows SharePoint Services this summer, it will contain a number of new functionalities that make it a highly productive platform for building Web applications. A key one is the ability to quickly develop and use Web Parts — modular, componentized Web page elements. Web Parts help increase the effectiveness and productivity of Web developers, and empower end users to create their own Web applications through the use of pre-built drag-and-drop functionalities. PressPass spoke with Mike Fitzmaurice , technical product manager, about the significance of Web Parts, how they fit in with other Microsoft technologies, and what opportunities they present for Web developers.
Mike Fitzmaurice, Technical Product Manager, Windows SharePoint Services. Click on the image for a high resolution photo
PressPass: What are Web Parts?
Fitzmaurice: Web Parts are the building blocks for creating modular Web sites. Web Parts are built on ASP.NET, a set of technologies for building Web applications found in the Microsoft .NET Framework. Their job is to provide a connection to information or an application, and display it inside a Web page in Microsoft Windows SharePoint Services or Microsoft Office SharePoint Portal Server 2003.
Much like one creates a mosaic by assembling and arranging a number of individual, pre-made tiles, a user can assemble and arrange a complete Web page out of pre-made Web Parts. Web Parts can list documents, display part of a Web page in another site, list pending invoice approvals, graph sales performance statistics, show you the results of a survey in progress, tell you the status of your e-mail server traffic — pretty much anything.
Web Parts offer significant benefits to users, developers, and IT administrators. Developers leverage the full power of .NET to build Web Parts, and their handiwork can be used over and over again on a multitude of Web Part pages on a multitude of sites. Moreover, the Web Part infrastructure lets developers focus on writing code that delivers business benefits — most of the overhead chores have been covered.
IT administrators benefit from this because they can decide on a set of approved Web Parts, load them onto the servers that serve up SharePoint sites, and the Web Parts immediately become available as part of a gallery of elements that can be dragged and dropped onto as many Web Part Pages in as many SharePoint sites as users wish. One approval and deployment yields no incremental overhead no matter how much or often the Web Part is used. Moreover, we also empower the user to choose which Web Parts will appear in a page, and how they’ll be arranged and connected to each other.
PressPass: Can you give an example of how a Web Part is used?
Fitzmaurice: Let’s say I want to be kept apprised of which purchase orders are awaiting my approval. It would be very convenient if the Web page I view most often had a section that displayed a list of outstanding purchase orders. That way, I’d only have to connect to the purchasing system when I know work is waiting for me.
The next time I browse a Web Part page on my favorite SharePoint site, I can drag and drop the Web Part onto my page and immediately create a link to access these purchase orders. That part may have been custom-developed by our in-house staff or a consultant, or purchased from an outside vendor, or supplied by the maker of our financial software. In any case, it was vetted by our server administrators and published in gallery of available Web Parts, so others within my team or my company can go out to the gallery, drag and drop the Web Part to their Web page, and immediately gain the same purchase order functionality.
PressPass: Why is the reuse of Web Parts significant?
Fitzmaurice: The whole point is to empower users to create or assemble Web pages, rather than have to build them from scratch, and diminish the need to go to a developer every time they want to make such a change. In my example, the purchase order Web Part, and the functionality it enables, could be reused throughout the organization in lots of different sites by lots of different people. I write it once, and it can be embedded in many different Web pages. This is much more efficient and productive than the alternative scenario, where, for every department in the company that has purchase orders to approve, we have 50 different developers writing the same basic code to build the functionality 50 different times for 50 different departmental Web sites. Using Web Parts, we can just write it once and make the code available to all users to drop into their Web pages as they see fit. The developer only has to develop it once, test it once, and then everybody benefits.
PressPass: What are the top benefits of Web Parts to developers?
As I’ve just described, code reuse is the top benefit. I can write my Web part, validate it, and then publish it for use on multiple pages in multiple sites by multiple users by multiple companies. For example, a Web part that displays traffic patterns — or local weather or local news feeds — could be used by hundreds of thousands of different users, each of whom would configure it slightly differently. Rather than individual users contracting with different developers all over the place to add functionality to existing pages, the code is written once, and then reused wherever it is needed. This greatly increases developer effectiveness and productivity. They’ll have more time available to build more Web Parts for their users.
Web Parts also ease deployment costs. If a developer has to write a brand spanking new Web application each time someone needs Web functionality, the IT department has to come up with a new way to deploy it each time, and may need to provide a new site and possibly procure new resources to host it. Whereas if it’s written as a Web Part, it just gets added to the available pool of Web Parts, and the people who want the functionality for their sites just add it. The resources are already there.
PressPass: It seems that the benefits of using Web Parts for creating Web pages are similar to the benefits of creating and using pre-built software components for any development project. Can you comment?
Fitzmaurice: The argument in favor of writing Web Parts is the same argument we’ve made for over a decade with Microsoft Visual Basic, and more recently with writing programs in a .NET language like ASP.NET — but with one important difference. In these situations, developers create a custom control that other developers can imbed in their applications. However, until now, the consumer or customer for controlled code was always another developer; one developer is benefiting from another developer’s handiwork. However, with Web Parts, the final consumer of the handiwork is the end user. We give the user a Web Part page, a blank slate onto which they add pre-built components that provide access to or data from a variety of sites or applications, residing in a variety of places.
Q: How will end users experience the benefits of Web pages built with Web Parts?
Fitzmaurice: User empowerment is the greatest benefit. End users are given the option to build and customize their Web pages. They can go to Web Part galleries, choose what they want to do to make their own sites more productive, and just click and drag the functionality to their Web sites. The user gets to pick and choose which elements are going to be present on their page, thereby creating custom pages out of pre-built components.
PressPass: What is the business value, such as the Return on Investment (ROI), of Web Parts?
Fitzmaurice: I’d measure the business value in at least two ways. If you’re a developer, you are measured on the quality and the quantity of your work — in this case, of writing code. If you do good work, you’ll be in demand. If your work can be reused, you’ll be able to write more new code, rather than rewriting the same thing over and over again. From the technical point of view, reusing code such as Web Parts makes a huge amount of economic sense, as IT administrators can offer users more and fully tested code in a form that is deployable by the end user. This means that IT professionals can use their time more strategically while providing end users a high level of support and options.
Also, there are simple cost advantages to writing code in the .NET Framework. Developers can draw on the services and the plumbing made available through the Web Parts infrastructure, such as built-in security tools and state management.
PressPass: How many Web Parts will be made available?
Fitzmaurice: Windows SharePoint Services will ship with a gallery of Web Parts. SharePoint Portal Server will ship with still more Web Parts. In addition, Microsoft is committing resources to working with industry partners, solution providers and the developer community to drive significant third-party Web Part development. We also encourage developers to post their handiwork, or at least links to their work, to our Web component directory (see Related Links, at right). If you’d like more information on how to develop Web Parts, we’re constantly adding more and more information to the SharePoint Products and Technologies Developer Center (see Related Links, at right), and the next quarterly shipment of the Microsoft Developer Network Library will have that information.
PressPass: How do Web Parts relate to the larger Windows SharePoint Services and Microsoft Office SharePoint Portal Server 2003 structures?Fitzmaurice: Web Parts are created out of ASP.NET technology, which is part of the .NET Framework. Web Parts are part of the package of services and functionalities delivered in Windows SharePoint Services for Windows Server 2003. When you browse a SharePoint site, you’re looking at Web Part pages. But a SharePoint site, even though it uses Web Parts as its user interface, is more than just display technology. It also provides document collaboration services, event calendars, contact lists, threaded discussions, picture libraries, surveys, announcements, task lists, issue tracking, subscription alerts, presence and instant messaging integration, and any custom list you can imagine. Put them all together and you get highly productive Web sites that are all about user productivity, team collaboration, and manageability, taking file sharing and information sharing to the next level.
SharePoint Portal Server 2003 is built on SharePoint Services, and focuses on aggregating, integrating, organizing, and presenting all information across those sites, as well as other information and applications throughout the enterprise, connecting people, teams, knowledge, and applications around business processes. SharePoint Services is all about serving up smart places, and SharePoint Portal Server is all about facilitating smart organizations.
Now, a SharePoint site is not just there to be used by a browser. Everything in a SharePoint site is also exposed as a set of Web services. Because everything in Office 2003 knows how to consume Web services, the desktop applications that make up the Office System are able to communicate with SharePoint sites and do so with Web services. Other rich-client applications from Microsoft and other software developers can do the same thing.
PressPass: What is the most important message you would like to get out to developers?
Fitzmaurice: This may sound melodramatic, but I’d like every man, woman, and child with a copy of Microsoft Visual Studio.NET to build Web Parts and post them to, or list them on, our Web Component Directory. If you’re already writing ASP.NET Web pages, you should seriously consider writing Web Parts. Add it to your repertoire of solutions. Creating a robust gallery of Web Parts means developers will have more parts to pull from and this increases the likelihood that they will find a pre-built Web Part that will suit their needs. Every time a Web Part developer writes a new Web Part, they have the potential of making hundreds of thousands of SharePoint sites more useful and productive for the entire community of users of SharePoint Products and Technologies.
