PointBridge Blogs - Office 2010 Wave

Styling Web Parts in SharePoint 2010 (Add round corners via CSS)

By: Seth Broweleit Posted: December 29, 2009 at 10:41 PM

In previous versions of SharePoint it was impossible to add corners to a Web Part with just CSS (unless you were building sites for only the latest browsers). The best way was to style a container DIV on the Page Layout and put a Web Part Zone inside. Then, a Web Part in that zone would appear to have round corners. This method greatly reduces the flexibility of SharePoint because there can only be one Web part in each Zone for the effect to work.

Styling Web Parts in SharePoint 2010 has become much easier than in MOSS 2007. There are several reasons for this and I will highlight a few.

The addition of a style class on a cell that contains the entire Web Part gives a big advantage to adding styles. In MOSS this did not exist. This is helpful because now you can simply add a border, background image or color to the container cell with the class “s4-wpcell-plain” and it will be applied around and behind the body and header of the Web Part.

Another new addition is a style class on the last cell in the header of a Web Part. The one that contains the dropdown arrow for the menu. This allows you to target this cell and add a background image like a top right corner. Before you could not target this cell specifically which made it difficult to put a top right round corner image in that cell. The new class that has been added to this cell is: ms-WPHeaderTdMenu. The cell that contains the Web Part title now has a class of: ms-WPHeaderTd. There are a few more cells with the classes ms-WPHeaderTdSelection and ms-wpTdSpace but they only seen when the page is in edit mode so it is unnecessary to style these.

With these additions round corners and gradient backgrounds can easily be added to Web Parts without having to change the Page Layouts or create custom Web Parts.

Changing the background colors in SharePoint 2010 also changes the gradients

By: Seth Broweleit Posted: December 27, 2009 at 10:49 PM

The backgrounds in SharePoint 2010 were designed to allow end users to change gradients by simply picking solid colors on the settings page. For example if you choose an orange background color the result is a fade from orange to lighter orange. The change can be very subtle but is an effective way to create an attractive site. This is a significant upgrade from older versions of SharePoint where, in order to change the branding, you would have had to undertake the time-consuming task of editing all of the gradient images one by one.

This branding technique is accomplished with the use of transparent PNG images. The images do not contain the color information only the blend and are mostly transparent so any color can show through. The end result is a blend from light to dark in any color that is chosen.

The illustration below shows the “Felt” color palette on the left and the “Viewpoint” color palette on the right. In the middle is what the gradients would look like if all of the background colors were black.

How to create a Document Set using C#

By: Bob Moore Posted: October 23, 2009 at 4:47 PM

I decided to expand on one of Travis Nielson's posts called Introducing Documents Sets. Being the eternal developer that I am I decided to write a blog on how to create a Document Set using C# and the new object model for SP2010.

In trying to figure out how to do this, I though I would try the 2007 way and add a new ListItem to my test document library....well that didn't work so well. While I was looking at the code for the NewDocSet.aspx page I stumbled upon a new assembly and namespace. The assembly that I am referring to is Microsoft.Office.DocumentManagement and the namespace is Microsoft.Office.DocumentManagement.DocumentSets. Within the new namespace lives the DocumentSet class. The DocumentSet class makes it pretty easy for creating a DocumentSet. Using the same content types from Travis' blog I created a quick console application to create the DocumentSet in code. Below are the lines of code necessary to create a DocumentSet using the default content:

SPSite site = new SPSite("http://sp2010");

SPWeb web = site.OpenWeb();

SPList list = web.Lists["Proposals"];

Hashtable props = new Hashtable();

props.Add("Name", "Proposal 1");

props.Add("Description", "Proposal 1");

props.Add("Customer ID", "1234");

props.Add("Customer Name", "Customer 1");

DocumentSet ds = DocumentSet.Create(list.RootFolder, "Proposal 2", list.ContentTypes["Proposals"].Id, props, true);

web.Dispose();

site.Dispose();

If you do not want to provision default content then after you create the DocumentSet you can add the desired content by manipulating the Item property (SPListItem) of the DocumentSet.

Overview of Records Management in SharePoint Server 2010

By: Matt Morse Posted: October 19, 2009 at 8:42 AM

Note: The contents of this post are based on the SharePoint Server 2010 technical preview, and are subject to change without notice.

Microsoft has invested in a number of areas in SharePoint Server 2010, and many of those investments are aimed at making SharePoint an even more serious contender in the ECM space. This post will be an overview of the new records management capabilities of SP2010; I will follow this with a detailed treatment of a number of the areas that are mentioned below.

A Brief Look Back

Microsoft introduced records management with MOSS 2007, and the functionality is generally fine. There is a basic but powerful routing mechanism for classification of incoming records based on content type. The mechanism for handling record metadata works well. The interface to the record center is exposed as an easy-to-use web service, and the API provides a number of straightforward hooks for extensibility (e.g. the ability to create a custom record router). Finally, the ability to put documents on a hold (or multiple holds) and have those documents exempted from any expiration or destruction policies works well.

However, the features are critically limited in a few significant areas. First, in its default configuration, a SharePoint farm supports a connection to only one record center – which, depending on data volume, can be a significant scalability problem. In addition, documents submitted to a record center make a copy of the source document; the user doesn’t have the option of removing the document from the source location. Finally, the options for declaration of a record are limited; a user can choose to manually send a document to a record center, and it’s possible to send records using custom workflows, but there’s not a way to create rules regarding record declarations (e.g. that every Contract stored in a system must automatically be a record).

As noted, the record management API works well, and it’s possible to develop rich solutions on MOSS 2007 that compensate for some of the functionality that’s not provided natively. What’s exciting about SharePoint 2010 is that Microsoft has addressed many of these limitations and the out-of-the-box experience for records managers will present a very interesting case for use of the new platform.

And now on to the new features!

In-Place Record Declaration

One of the very significant changes in approach for SharePoint RM is the addition of the capability to declare records “in-place” without moving them to a record center. This is a feature that may be activated at the site collection level. Once activated, the in-place records management feature adds capabilities to the site collection and to document libraries that allow documents to be declared as records.

Once declared a record, a doc is subject to a different set of policies (more on this below), a different set of permissions (e.g. which users may edit/delete documents), and to the standard record hold functionality.

Multiple Connections per Farm

SharePoint 2010 allows farm administrators to define multiple connections to record centers per farm – and not simply to define the connections, but to specify more detailed parameters about the behavior of those connections. In addition to the behavior that MOSS supported (which was to define an entry on the “Send To” menu for a document, then copy that document to the specified record center), SP 2010 provides the ability to move the document to the record center, or to move the document, but leave a link in the original location. It’s also possible to define a connection that does not show up on the manual “Send To” menu – but which can be used in automated record submission scenarios. The details of setting up these connections look like this:

Better Integration with Information Management Policies

One thing that stands out about the new features provided by Microsoft for records management is their pervasive nature. While in MOSS records management sort of sat off to the side (with a connection only via the '”Send to” menu), in SharePoint 2010, records management functionality can be found sprinkled throughout the product. This is good thinking on the part of Microsoft, as it is reflective of the perspective of records managers at organizations. Solid records management isn’t an afterthought: it’s something that must be incorporated into day-to-day business processes.

Perhaps this is seen most clearly in the incorporation of records rules into SharePoint’s information management policies – and specifically the policy around retention (renamed from “expiration” in MOSS). (Note: the retention policy logic itself has been vastly upgraded in SP 2010. That’s beyond the scope of this specific post, but it’s worth exploring if you’re interested in automated retention rules.) We see the change in direction first in that retention policies now allow two separate rule sets – one for documents that are not declared as records, and one for documents that are declared records.

The second major integration point with information management policy is that there are now pre-defined actions related to records management. In the example below, I can configure my policy to automatically submit a document to a record center at a specific time – in this case, two years after the Contract Date.

There’s also an action that will declare a document as a record without submitting it to a record center, leveraging the new in-place RM features.

In short, it’s now possible to merge a record declaration and organization strategy with the retention and management policies of the front-end systems. Like many of the other items mentioned here, this is functionality that is possible in MOSS only with significant development effort.

Routing Rule Processing in Record Center Sites

There are a number of improvements in the processing of routing rules within record center sites, but I will focus on three here.

First, there’s now an ability to have a routing rule match on a set of logic, rather than just the document type itself. For example, you might want to send Contracts for a specific vendor to a different location than Contracts for another vendor. The only way to have done this in the past was through the use of separate content types. Now, the routing rule configuration in the record center allows for rules to be evaluated on the metadata of the item being received. In the example below, there’s an “Amount” column on the incoming content type. This rule will only be applied if the value in that column is greater than or equal to 10,000.

A second significant improvement to the routing rule configuration is the ability to route to locations outside of the current record center site. In MOSS, default routing rules can only send documents to libraries within the current site. (You can extend that functionality by creating a custom record router, but that involves some development.) In SP 2010, the destination location may still be a local document library – or it may be any other site within the site collection that has a content organizer specified. (More on content organization in a future post.) Note the “Browse” button in the image below.

The third significant change is the ability to have more control over the folder naming when documents are placed into document libraries. In MOSS, folders are named somewhat randomly based on the date of submission to the record center. This ensures that the number of documents in a given view is kept low, but doesn’t provide a logical structure for navigation. In the image above, you can see the option to specify a foldering strategy based on the values provided in the metadata. So in the Contract example, I can choose to have all contracts with the same client end up in the same folder; when a new client contract comes along, a new folder with that client’s name will be created automatically. This has positive implications not only for visual navigation, but for search relevance, as well.

And there’s more…

There are many additional detailed features related to records management. I believe I’ve hit the highest points here, but there are a number of additional details

Ability to serialize documents by a unique document ID, then find documents by that ID.
Ability to declare sets of documents together as a record. (See an introduction to document sets here.)
Ability to export a summary file plan spreadsheet from a record center summarizing the rules in place there.
Ability to copy documents on a hold to a specific SharePoint location.

I’ll cover many of these details in future posts.

Summary

Microsoft has invested heavily in Records Management in SharePoint 2010, and organizations who have an investment in SharePoint would do well to evaluate its capabilities. I don’t think it will outperform point solutions on a feature-by-feature basis in the RM space, but there is significantly more functionality than was present in the SharePoint 2007 version – enough that I think it will meet the standard needs of many companies. After all, one significant benefit of SharePoint is precisely that it’s not a point solution, but rather a platform that provides a breadth of solutions common to many organizations. It may not be the strongest option in each specific area, but the sum of the options that it provides makes it a great value for small offices and enterprises alike.

Introducing Document Sets

By: Travis Nielsen Posted: October 18, 2009 at 11:51 PM

In my previous posting about the many enhancements to workflow created in SharePoint Designer 2010, I mentioned that approval processes can be applied to both documents and document sets. Seeing how the latter case is a new feature in SharePoint 2010, I thought it might be a good idea to at least explain the basic principles of document sets.

The Basics

As the name implies, a document set represents a collection of closely related documents. In SharePoint 2010, document set functionality is a Site Collection feature that must first be enabled. Here, I’m enabling it and the Document ID Service feature.

After this is done, the Document Set content type is enabled and can be created like any other traditional content type.

After this is done, you can assign other content types to be part of the document set. In this example, my “Proposal” document set will contain both a Statement of Work and Project Estimation Sheet as members. To add them, document set content types have a special “Document set settings” option.

From there, you can add other content types to be included in the set and (optionally) set them to be populated within a new set by default.

If you add supplemental Site Columns to your document set, you can include them in the “welcome page” of the set. As the description states, the data contained within these columns are synchronized with all documents within the set. In addition, components of the document set Welcome Page can be customized with web parts and the like. At the time of this writing, this feature does not appear to be implemented yet. At least not without cracking open SharePoint Designer 2010.

Adding the document set to a document library is handled in the same manner as adding a regular content type. However, when users go to create a new document in the library, they see a slightly different icon.

Then, users are prompted to enter required metadata about the set.

Once this is done, voila! The set appears and documents are pre-provisioned. Very cool.

And since I had configured the Document ID feature, the document set and all subordinate documents are assigned a unique number by the Document ID service.

Approval Process

So what about the approval process? Well, this can be done in SPD 2010 using the following action:

Unfortunately, I wasn’t able to get the rest of the process to work from here. I’ll be looking at this more when the full beta comes out and will be interested to see how a streamlined, easy-to-use process can be developed to handle approval for document sets like this.

Conclusion

Document Sets are just one of many new document management features that SharePoint 2010 is bringing to the table. And don’t think this is just a new type of folder. The ability to synchronize metadata between documents and relate them to each other in this way goes far beyond that concept. This mirrors the real world well. I’ve been on a couple of projects where customers had business processes that involve not just one, but several tightly-coupled documents that needed to be handled synchronously. I think the Document Set feature holds quite a lot of promise.