Share via

Informative and Customizable Web Parts

  • Article

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

The purpose of a Digital Dashboard is to help reduce information overload by delivering tailored information to users in a manner they can assimilate easily. While it might be tempting to create complex Web Parts that deliver large amounts of constantly changing information, Web Parts such as these might not serve their purpose. Above all, a good Web Part must display information in a manner appropriate to a Digital Dashboard.

Before you begin building Web Parts, think about the requirements of your users. Often, the best Web Parts are ones that users can customize. For example, a Web Part that shows the contents of a Microsoft® Outlook® folder must display a view that each user can customize using the Outlook View control, or a Web Part that displays a stock ticker must be customizable, so it shows only the stocks each user selects.

Customizable Web Parts have three requirements: a way for the user to provide customization information, a location for storing that information, and a method of retrieving it. To provide an interface that makes it possible for users to customize a Web Part, you use the CustomizationLink property in the Web Part schema. You can store customization information on the client, on the server, or in the Web Part itself using the PartStorage property.

In This Section

  • The CustomizationLink Property
    When specified, the CustomizationLink property contains a URL for a page that makes it possible for users to customize the content of the Web Part.
  • The PartStorage Property
    The best place to store customization information related to a Web Part is in the PartStorage property, which you can access through the Digital Dashboard Services Component.
  • Cookies
    When you create a customizable Web Part, the customization generally takes place inline in the dashboard. However, you also must make sure that other pages are supported.
  • Cookies and Non-Isolated Content
    Typical Web sites use cookies to identify the client between page requests. When a client accesses a page, the page drops a cookie associated with the site's domain that indicates the user has been validated.
  • Web Parts that Maintain a Consistent Look and Feel
    A good Web Part must have a look and feel that is consistent with other Web Parts on the dashboard. The dashboard defines a set of style classes that Web Parts inherit to make sure they render with a similar look and feel.
  • The Isolation of Web Parts from Other Web Parts
    Because the Web Parts you build are included in the Document Object Model of the Digital Dashboard along with other Web Parts, there is a high possibility of script collisions.
  • Portable Web Parts
    To be truly reusable, a Web Part must be able to be used in any Digital Dashboard. This means that Web Parts should not be dependent on other Web Parts, network connectivity, or computer configurations.