Tips & Tricks

You may want to rethink your column names…

When I started working with SharePoint in 2003, I used multi-word names for everything–my sites, my libraries and lists, even my column names. It didn’t take me long to realize that spaces wreak havoc on my URLs. Since each space in my name causes a %20 string to appear in my URL, my URLs quickly became long and unwieldy.

Creating a new SharePoint site named Help Desk, for example, results in the URL:

https://splibrarian.sharepoint.com/Help%20Desk/SitePages/Home.aspx

If I create a new document library on that site named Sarah Haase, my new library’s URL lengthens to:

https://splibrarian.sharepoint.com/Help%20Desk/Sarah%20Haase/Forms/AllItems.aspx

And when I add the nested folders Fiscal Year 2013 > Projects > Project X > Design Documents to my document library, my URL extends to:

https://splibrarian.sharepoint.com/Help%20Desk/Sarah%20Haase/Forms/AllItems.aspx?RootFolder=%2FHelp%20Desk%2FSarah%20Haase%2FFiscal%20Year%202013%2FProjects%2FProject%20X%2FDesign%20Documents

You can quickly see how a deep nested folder structure (complete with spaces in your library and folder names) can negatively impact your user’s URL experience. But this problem is easily circumvented. If you create your sites, document libraries and lists using names without spaces (e.g. HelpDesk), you’ll avoid adding %20 strings to your URLs. Once your sites, libraries and lists are created, you can go back and update their names to include spaces. This will add “friendly” spaces back into your site, library and list names without damaging your nice (short) URLs.

But what about column names?

I recently learned that spaces in your column names can also cause difficulties. When you create a new document library or list column, SharePoint automatically sets an “internal name” for the column. This internal name is the ID for your column. You may need to know and reference this internal name as you build out new SharePoint solutions or customize the look and feel of your Content Query Web Parts (CQWPs).

So how do you find out what the internal name is for your columns? Go into your document library settings or list settings page and click on the hyperlink for your column. When the column’s detail page appears, take a look at the URL that appears at the top of the page. Your column’s internal name will appear at the end of the URL after the string Field=

SharePoint bases your column’s internal name off the “friendly name” you give your column when you first create it. If you create a new column named DocumentType, for example, your column’s internal name will be DocumentType.

If you include spaces in the name of your new column, SharePoint adds a string of additional characters to your column’s internal name. As the following screen shot illustrates, a new column named Category Type results in the internal name Category%5Fx0020%5FType

The more words you add to your column’s initial name, the longer your column’s internal name will become. If you name your column:

What is your business justification for this change

Your column’s internal name will be:

What%5Fx0020%5Fis%5Fx0020%5Fyour%5Fx0020%5Fbusiness%5Fx0020%5Fjustification%5Fx0020%5Ffor%5Fx0020%5Fthis%5Fx0020%5Fchange%5Fx003f%5F

Once your column is created and the internal name is set, you cannot change it. Your only option is to delete your initial column and re-create it.

To limit the length and complexity of your internal column names, treat your columns like you treat your document libraries, lists and sites. Keep your column names short and do not include spaces. Once your column is created and your column’s internal name is defined, you can always go back in and edit your column name and add additional words or spaces. This will make your column name more “friendly” without lengthening your column’s internal name.

And think carefully before you repurpose old columns in your lists and libraries. While you may change the name of your column an infinite number of times, the internal name for your column won’t change.

References

I first learned about internal column names during Peter Serzo’s CQWP session at SharePoint Saturday Twin Cities. For more information on the “limitless” CQWP, see Peter’s presentation.

Wes Preston recently published a blog post on internal columns and their impact on the client-side rendering functionality in SharePoint 2013.

How do I change the URL users are sent to after they fill out a New Item form?

This is a common request, particularly if your site has quite a few lists. Rather than bogging your users down with navigating into (and out of) each list, you may want to give your customers a quick and easy way to jump from your site’s landing page into your list forms and then back to your site’s landing page. The steps would look like this:

Customer comes to your SharePoint site.
Customer sees on your landing page a list of the form(s) that apply to them. They click on a link to go to the form they need.
They fill out the form and click Save.
They’re automatically returned to your SharePoint site’s landing page.

The first 3 steps are fairly straightforward, but step #4 is interesting. Normally, you are automatically taken to your list’s default view when you fill out and save a new item request. We want to change this default behavior. We don’t want our users to be taken to our list’s default view, because they don’t need to see all our list data. We want them to find their form, fill it out and then return to where they started. Fortunately, there’s a quick way to alter your user’s default path. By creating a custom link to your form and modifying the link’s HTML code, you can force SharePoint to take your end-users back to their starting point once they’ve finished filling out their form.

There are a variety of ways to modify your hyperlinks, including making customizations via SharePoint Designer. This blog post focuses on building these custom hyperlinks with out-of-the-box SharePoint web parts. Since the process differs slightly for MOSS 2007 and SharePoint 2010, I’ve included setup instructions for both platforms.

MOSS 2007 setup

First, you need to obtain the hyperlink for your list’s New Item form. Here are the steps for capturing this URL:

Go to your site’s landing page.
Click on Site Actions > Edit Page.
Click on one of the Add a Web Part buttons.
Select your list and click on the Add button. A web part for your list will be added to your site’s landing page. (Don’t worry–we’ll delete this web part in just a minute.)
Right-click on the Add new item link that displays in the bottom left-hand corner of your list view web part. When the pop-up menu appears, select Copy Shortcut.
Now you’re ready to delete this list view web part. Click on your web part’s edit link and select Delete.

Now that you have your New Item form’s URL, you’re ready to customize the URL and add it to your site’s default.aspx web part page. (Note that the steps outlined below can be used to add custom hyperlinks to any SharePoint web part page. You are not limited to adding these links to your site’s landing page.)

Go to your site’s landing page.
Click on Site Actions > Edit Page.
Click on one of the Add a Web Part buttons.
Scroll down the list of web parts until you find the Content Editor Web Part. Select this web part and click on the Add button to add it to your page.
When the web part gets added to your page, it will appear with an open the tool pane hyperlink. Click on the hyperlink to configure this new web part.
When the web part pane appears, click on the Source Editor… button.
When the text entry box appears, key in the HTML code shown below. Replace the text highlighted in yellow with the URL for your new item form. Replace the text highlighted in blue with the verbiage you want displayed as your link. Leave the text highlighted in pink–this is the magic code that will make your hyperlink return users back to your site’s landing page after they submit their form.
Click Save to save your changes.

That’s it! Your first HTML link is ready to go. Test it out and validate that it is working as desired.

You may want to pretty up your Content Editor Web Part a little bit (e.g. change the name of the web part and add additional form links), but otherwise you are ready for business. Here’s a picture of my finished page:

And here’s a picture of my final Source Editor code:

Note that I added some additional HTML tagging around my links–just enough to create a bulleted list for my form links. You can add in as much (or as little) HTML tagging as you want.

SharePoint 2010 setup

First, you need to obtain the hyperlink for your list’s New Item form. Here are the steps for capturing this URL:

Go to the list you want to create a custom hyperlink for.
Right-click on the Add new item hyperlink that appears at the bottom of the list view page. When the pop-up menu appears, select Copy Shortcut.
Open a new browser window.
Go to the address bar and do a Ctrl+V to paste in your newly copied URL.
Press Enter. You will automatically be redirected to your list’s New Item page.
Copy the updated URL that appears in your address bar–this is the URL you’ll be using to create your custom hyperlink.

Now that you have your New Item form’s URL, you’re ready to customize the URL and add it to your site’s Home.aspx web part page. (Note that the steps outlined below can be used to add custom hyperlinks to any SharePoint web part page. You are not limited to adding these links to your site’s landing page.)

Go to your site’s landing page.
Click on Site Actions > Edit Page.
Click on the Insert subtab.
Click on the More Web Parts icon.
Click on Forms, select the HTML Form Web Part and click on the Add button.
Once the new HTML Form Web Part is added to your page, click on the chevron for the web part and select Edit Web Part.
When the web part pane appears, click on the Source Editor… button.
Delete the text that appears in the text entry box.
Key in the HTML code shown below. Replace the text highlighted in yellow with the URL for your new item form. Replace the text highlighted in purple with the verbiage you want displayed as your link. Leave the text highlighted in pink–this is the magic code that will make your hyperlink return users back to your site’s landing page after they submit their form.
Click Save to save your changes.

That’s it! Your first HTML link is ready to go. Test it out and validate that it is working as desired.

You may want to pretty up your HTML Form Web Part a little bit (e.g. change the name of the web part and add additional form links), but otherwise you are ready for business. Here’s a picture of my finished page:

And here’s a picture of my final Source Editor code:

Note that I added some additional HTML tagging around my links–just enough to create a bulleted list for my form links. You can add in as much (or as little) HTML tagging as you want.

Modifying calculated column formulas based on values selected in other metadata fields

I am a librarian, NOT a developer. But today I built a very cool formula that examines list metadata fields and dynamically applies formulas to calculate project milestone completion dates. Here’s my business scenario:

I have a SharePoint list that is used to track project tasks for my documentation department. The list has a variety of fields, including:

Project name
Project manager
Task type – a Choice field with the following valid values:
- Design documentation
- Write documentation
- Proofread
Task description
Technical writer assigned
Task due date
Task start date (this is the field I want to auto-calculate)

Project managers will come to this list to enter documentation tasks that need to be completed for upcoming projects. Many of the tasks may be logged early on in the project, but may not need to be started (or completed) until later in the project’s lifecycle. To help ensure that each task is kicked off in a timely manner, the project managers want to automate the calculation of task start dates. When the project managers log each task, they’ll identify the task type and the task due date. They then want SharePoint to look at the task type, deduce how much lead time will be needed to complete the task and automatically specify a task start date.

I’ve built this type of solution before, but have always used custom SharePoint Designer workflows to make my calculations for me. This wasn’t an option in this case, as the project managers wanted to avoid any SharePoint Designer customizations. And while I knew that Calculated columns offer a huge amount of functionality, I was unsure how I (the librarian) was going to figure out how to create the necessary formulas.

I started out reviewing Calculated column formula help guides, including http://msdn.microsoft.com/en-us/library/bb862071.aspx. From there I started experimenting with a basic formula that would look at the Task type field. When it found a list item whose Task type field was set to Design documentation, it would take the value in the Task due date field, subtract 52 days and report the results. Here’s this starter formula:

=IF([Task type]=”Design documentation”,[Task due date]-52)

And here’s how my calculated Task start date column looks, now that I’ve inserted this formula:

Let’s check out how this new field works. When you look at my list below, note that the top list item has a Task type of Design documentation. And just as we wanted, this task’s start date is automatically set to 52 days prior to the recorded task due date. Perfect!

There is a problem, however. All of my list rows that have a Task type not equal to Design documentation have a task start date value of 0. This is clearly not what we were hoping for. So I went back to the drawing board to create a formula that would work for binary fields (aka fields that have 2 possible valid values). Here’s the result:

=IF([Task type]=”Design documentation”,[Task due date]-52,[Task due date]-10)

Notice that this field includes 2 calculations–one for subtracting 52 days and another for subtracting 10 days. This formula will examine each list item’s Task type field. If it finds a value of Design documentation, it will subtract 52 days from the Task due date. If it finds any other value in the Task type field, it will subtract 10 days from the Task due date.

This is a bit better than our first option, but it won’t scale if our field has more than two options. I also don’t like how non-specific this formula is. It treats every value other than Design documentation identically.

After some trial and error, I evolved the formula again, this time modifying it so I could explicitly call out each possible field value and the corresponding date calculation to be made:

=IF([Task type]=”Design documentation”,[Task due date]-52,IF([Task type]=”Write documentation”,[Task due date]-40,IF([Task type]=”Proofread”,[Task due date]-10))

This new formula has 3 clauses, each of which specify a Task type value and the corresponding number of days that should be subtracted from the Task due date to determine the Task start date. Here are each of the clauses, broken out into different lines for easier viewing:

IF([Task type]=”Design documentation”,[Task due date]-52,
IF([Task type]=”Write documentation”,[Task due date]-40,
IF([Task type]=”Proofread”,[Task due date]-10))

Here’s how my calculated Task start date column looks, now that I’ve inserted this formula:

And here’s the final result:

Nice! Now my Task start date field automatically reads the type of project task and determines the date when the task should be started. I should also mention that this solution works for both SharePoint 2010 and MOSS 2007.

Using calculated columns to add color coding to your SharePoint lists

There are a variety of ways to add color coding to your SharePoint lists and document libraries, from embedding custom code on your page to creating data view web parts with conditional formatting in SharePoint Designer. The trick is determining which method works best in your situation. Not sure how to do that? Start with the basics:

Understand your business requirements.
Build your user adoption strategy.

You have to start with your basic business requirements. You need to determine what data you will be storing, how you will be storing it and when you will be surfacing it to key audiences. Since many of these questions may impact your use of color coding and conditional formatting, they’re critical to understand.

You also need to know how dynamic your users want their solution to be. Do they want to be able to tweak the specific shades of green you’re using? What if they decide that they no longer want to demarcate completed items in grey–instead opting for a nice shade of puce? If you build your color coding solution using custom code or a SharePoint Designer add-on, your average business users will (most likely) not be able to make color modifications on their own.

Once you have the basic business requirements down, you need to figure out what add-ons and additional features your users are dying to get their hands on. Do they get excited about having high-priority items display in red text? Do they want all the completed items in their weekly project tracker to show up in light grey font? Or are they color blind and see no value in having any color differentiation of their SharePoint data? If your users have a wish list of desired functionality that includes color coding a document library, list or calendar, you should be running (not walking!) to find any and every solution that will make their dreams come true. Delivering on your users’ wish list items will ensure smooth user adoption and easier change management.

I’ve used a variety of methods for color coding my SharePoint lists and document libraries. I’m using this blog post to share one of my color-coding favorites–the Path to SharePoint solution that uses embedded HTML strings in SharePoint calculated columns to apply color coding. Here’s an example of the types of color coding you can do with this solution:

(image source: Path to SharePoint, http://blog.pathtosharepoint.com/2008/09/01/apply-color-coding-to-your-sharepoint-lists/)

Setting up this type of color coding is fast–literally 5 minutes of work per list view you want to customize. But navigating the steps for the first time can be daunting. This blog pulls all the steps together in one easy-to-follow process. We’ll start with a business scenario, then move on to setup in both MOSS 2007 and SharePoint 2010. We’ll finish things off by discussing ways you can customize your new color coding.

Business scenario:

My company uses a SharePoint issue tracking list to store help desk support requests. All SharePoint users have the ability to go to this list and create new support requests as needed. When they go to the list and click on the Add new item link, they get a New Item form with the following basic input fields:

Title
Description
Priority
Due Date

When a user fills out the New Item form and clicks OK, the help desk ticket information is automatically routed to our help desk team for resolution. To ensure that high priority help requests are easily visible, our help desk manager wants the Priority field in our SharePoint list view to have automated color coding. He’d like all support requests that are High priority to display with a red icon. All Normal priority requests should display with a yellow icon and all Low priority requests should display with a green icon.

And while the team is currently using MOSS 2007, they have plans to upgrade to SharePoint 2010 in the next 3 months. So any color coding solution(s) that we build must work in both platforms.

Solution:

There are a few ways to get this done–including building custom data view web parts in SharePoint Designer. But since our help desk manager wants to modify the colors of his priority icons on the fly (without using SharePoint Designer), we’re going to build out these custom color indicators using HTML encoding embedded in calculated columns. We’ll be using the Priority column that comes with the default Issue Tracking list as the trigger for our color coding. (In other words, the value set in the Priority field will determine whether green, yellow or red color coding is applied to our new calculated field.)

While this solution works in both MOSS 2007 and SharePoint 2010, the setup is a bit different in each platform. Here are the required elements for both platforms:

MOSS 2007 required elements	SharePoint 2010 required elements
HTML script file (provided by Path to SharePoint) that will render your new HTML tags Document library to house the HTML script file SharePoint list with a Priority column Content Editor Web Part (CEWP)	SharePoint list with a Priority column SharePoint Designer 2010

The remainder of this blog post outlines MOSS 2007 setup steps, SharePoint 2010 setup steps and cool ways to customize your new color coding.

MOSS 2007 setup

Go to http ://pathtosharepoint.com/Downloads/Forms/AllItems.aspx, expand the HTML Calculated Column group header and download a copy of the TextToHTML-v2.1.1 text file.
Upload the HTML script file to a document library on your site. As you can see in the screen shot below, I uploaded my file to a document library named Site config files. It doesn’t matter what document library you use to store your file, but make sure all site users have at least read-only access to the library you use. This will ensure the HTML script file can be accessed to render the color coding you’re going to set up.
Validate that the SharePoint list or document library that you want to color code is set up with a Priority field with the following basic settings. (Note that these settings come with the out-of-the-box Priority site column, which you can add to your list or document library.)
Browse the color formatting options at http ://blog.pathtosharepoint.com/2008/09/01/apply-color-coding-to-your-sharepoint-lists / and determine which option (e.g. traffic light indicator, font color shading, background shading, KPI icon indicator) you’d like to implement.
Copy the formula provided for your desired formatting. In my case, I’m looking to implement a traffic light indicator so I copied the following formula:
```
="<DIV style=’font-weight:bold; font-size:24px; color:"&CHOOSE(RIGHT(LEFT(Priority,2),1),"red","orange","green")&";’>&bull;</DIV>"
```
Add a new calculated column to your SharePoint list. Paste the HTML formula string you copied into the new column’s Formula field. Click OK to save your changes.
When you return to your list view, you’ll see your new calculated column displaying with <DIV> tags. Not very attractive.
To correct this issue, we’re going to add our HTML script to the page. Click on Site Actions > Edit Page.
Click Add a Web Part and add a new Content Editor Web Part to your page.
Move your new Content Editor Web Part (CEWP) to the bottom of the page. You need it to display below your list view web part.
Click on the CEWP’s open the tool pane hyperlink.
When the web part configuration panel appears, place your cursor in the Content Link field and enter the location where you stored your HTML script file. Click OK to save your changes.

That’s it! Your formatting is applied and your page should now display your new color coded field. Here’s a screen shot of my finished view, complete with a Priority Indicator column that displays red, yellow and green traffic lights that correlate with the priority level of each help desk request:

Now that you’ve set up color coding on one list view, you can continue adding more color coding to this view or add color coding to other views. Note that you will need to add one CEWP to each list view page that you want to color code. There is no limit, however, to the number of calculated columns with HTML encoding you can add to your list.

SharePoint 2010 setup

Validate that the SharePoint list or document library that you want to color code is set up with a Priority field with the following basic settings. (Note that these settings come with the out-of-the-box Priority site column, which you can add to your list or document library.)
Browse the color formatting options at http ://blog.pathtosharepoint.com/2008/09/01/apply-color-coding-to-your-sharepoint-lists / and determine which option (e.g. traffic light indicator, font color shading, background shading, KPI icon indicator) you’d like to implement.
Copy the formula provided for your desired formatting. In my case, I’m looking to implement a traffic light indicator so I copied the following formula:
```
="<DIV style=’font-weight:bold; font-size:24px; color:"&CHOOSE(RIGHT(LEFT(Priority,2),1),"red","orange","green")&";’>&bull;</DIV>"
```
Add a new calculated column to your SharePoint list. Paste the HTML formula string you copied into the new column’s Formula field. Click OK to save your changes.
When you return to your list view, you’ll see your new calculated column displaying with <DIV> tags. Not very attractive.
To correct this issue, we’re going to need to modify this new calculated column. Open your site in SharePoint Designer 2010.
Click on Lists and Libraries in your SharePoint Designer 2010 navigation bar. When the list of your site’s document libraries and lists display, click on the list or document library we’re working on.
When the list or document library details page displays, look for and click on the name of the view you’re applying color coding to. In my case, I am updating the All Issues view.
Once your view opens, click on of the fields that are displaying those ugly

tags. Notice that the <xsl:value-of> tag in the bottom right-hand corner of your screen lights up in yellow once your field is selected.
Hover over the <xsl:value-of> tag until a black dropdown arrow appears. Click on the dropdown arrow and select Edit Tag…
A dialog box will pop up with the following text:
Place your cursor between the last quotation mark and the closing > bracket. Now type the text disable-output-escaping=“yes”
Your Quick Tag Editor box should now read like this:
Click on the Quick Tag Editor box’s green checkmark icon to save your changes. Your SharePoint Designer page will refresh and your color coding will appear!
Click File > Save to save your changes.

Now that you’ve set up color coding on one list view, you can continue adding more color coding to this view or add color coding to other views. Note that you will need to modify the <xsl:value-of> tag for each column you want to display in HTML format. There is no limit, however, to the number of calculated columns with HTML encoding you can add to your list.

Cool ways to customize your color coding

Now that you have your fields set up, you may want to start customizing the look and feel of your new color coding. Changing out the colors that display is quick and easy:

Find the new color(s) you want to use. A wide variety of HTML color choices are available. Here is a site that features a variety of HTML colors that are supported in all browsers: http://www.w3schools.com/tags/ref_colornames.asp
Once you find a new color you’d like to use, note the color’s name.
Go to your SharePoint list’s List Settings page.
Find and click on your new color-coded calculated column.
Look at your field’s formula and find the words red, orange and green. These are HTML color names that are currently being displayed on your SharePoint site. To modify these colors, all you need to do is replace these color names with the new color names you want to use. If, for example, you wanted to change the color orange to the HTML color Violet, all you need to do is highlight the word orange and replace it with the word violet. Then click OK to save your changes.

Here’s a picture of my list view now that I’ve changed orange to violet. Notice that my “normal” priority items are displaying a violet icon:

But what if you want to make other changes–like using a different trigger field? It is quick and easy to change the name of the field you want to trigger your color coding from. Just go to your calculated column, find the word Priority and change it to the name of the field/column you want to use.

The more difficult bit is changing the valid values that you want to trigger off of. The color coding formulas provided assume that you have a choice field with valid values of:

(1) High
(2) Normal
(3) Low

If you want to trigger color coding off of different values, you will need to tweak your calculated column formula. Fortunately, the fantastic folks at Path to SharePoint have already anticipated this need and have written a follow-up blog post with more formula examples. Take a look – http://blog.pathtosharepoint.com/2008/12/09/color-coding-more-examples/

Broken web part hosing up your web part page? The 30-second fix.

Ever had a broken web part that was preventing your web part page from rendering? A nasty problem. Fortunately, there’s a quick and easy fix:

Go to your broken web part page.
Place your cursor at the end of your page’s URL string.
Type ?contents=1 (as shown in the example URL below).
Press Enter.

Example URL: https://splibrarian.sharepoint.com/SitePages/Home.aspx?contents=1

A web part maintenance page will appear (as shown below). It will include a listing of all web parts currently configured as part of your web part page. Just select the web part(s) that are broken and click Delete to remove them from your page. Once the faulty web parts are deleted and your page is rendering again, you can re-add your web parts. (Hopefully without any future breakage.)

A great trick. And yes, it works in MOSS 2007 and SharePoint 2010.

Connecting web parts with a selector and a detail pane (SharePoint 2010 version)

I measure my SharePoint progress by the exciting moments when I finally figure out how to make something work. And I felt like a SharePoint superhero when I discovered how cool (and easy) it was to connect web parts on a web part page.

This blog posts explains how to connect list view web parts. But it goes a step farther, showing how you can build a list view selector that works just like the reading pane in Outlook. So when you select a list item, the corresponding item details will display in a detail pane. If no item is selected, the detail pane remains blank.

Business scenario:

We use a SharePoint list to store help desk support requests. All SharePoint users have the ability to go to this list and add their support request as a new item. Once they submit their request, the support reps take over ownership of the list item. Support reps, help desk customers and their managers need to be able to look at existing help desk tickets, however. There are a variety of ways to search on help desk tickets (by ticket number, by requestor, etc.), but one of our teams wanted an easy selector screen to see help desk ticket details. To support this request, we built a web part page with connected list view web parts. Here’s what the basic solution looks like:

(click on the image to see a larger view)

When you click on the radio button next to a help desk ticket in Web Part 1, the corresponding help desk ticket details display in Web Part 2. Neat! Now I want to take this one step farther…I want Web Part 2 to appear blank (without any issue details displaying) until a help desk ticket is selected in Web Part 1. Sound useful? If so, keep reading for details on how to build this out.

Solution:

This solution took quite a bit of work to build in MOSS 2007. (See Connecting web parts with a selector and a detail pane: MOSS 2007 version for details.) The whole things is much easier to construct in SharePoint 2010, with only a few required components:

SharePoint list (can be virtually any type of list, but this example was built with an Issue Tracking list)
Out-of-the-box list view web parts
SharePoint 2010 web part page

Ready? Let’s start building!

Part 1: Create your SharePoint list

You can’t build a SharePoint mashup without some data. Make sure you have one or more lists created and seeded with test data.

In my case, I built an Issue Tracking list and populated it with some example help desk tickets.

Part 2: Create your web part page

Click Site Actions > More Options.
In the left-hand nav bar, click on the Page link to filter by types of pages.
Select Web Part Page and click the Create button.
Specify a name for your new page. I named my new page Dashboard.
Select the formatting/style of web part page you want to use. (This example was built using the “Header, Footer, 3 Columns” web part page.)
Choose which document library you want the new web part page to be stored in and click Create.

Part 3: Add web parts to your new web part page

Go to your web part page.
Click on the Page tab and select Edit Page.
Find the Left Column of your web part page and click its Add a Web Part link.
To find your list view web part, click Lists and Libraries from the Categories list on the left-hand side of your screen. Then find/select your web part from the list provided in the center of your screen and click on the Add button.
Find the Middle Column of your web part page and click its Add a Web Part link. Repeat step 4 above and add a second list view web part to your web part page.

Now you have 2 identical list view web parts displaying on your web part page. Note that from this point on we’ll call the left-hand web part Web Part 1 and the right-hand web part Web Part 2.

Part 4: Configure your web parts

Click on the black dropdown arrow for Web Part 1 (as shown below). When the web part menu displays, click Edit Web Part.
When the web part editor configuration box appears, click Edit the current view.
Configure your web part, selecting the field(s) you want to display, the sort order, the filters to apply, etc. Press OK to save your changes.
Go back into the web part edit screen and make any other desired changes (e.g. change the web part title, the chrome state, the toolbar type, etc.).
Repeat steps 1-4 for Web Part 2.

Part 5: Connect your web parts

Click on the black dropdown arrow for Web Part 1 (as shown below). When the web part menu displays, click Connections > Send Row of Data to > Name of your second web part.
If you have pop-ups enabled, a connection dialog box will display. (If you don’t have pop-ups enabled, enable them and repeat this step.)
When the “choose connection” dialog box appears, set the Connection Type to Get Filter Values From and click on the Configure button.
When the “configure connection” dialog box appears, select the fields you are using to sync your two web parts. (In my case, I’m using the Title column to sync my web parts so I selected Title in both the provider & consumer field name drop downs.)
Click Finish to save your connection settings.
You will be prompted to confirm that you want to sync on that column in both lists. Click Next again to confirm.

Congratulations! You have just synced your web parts. If you stop editing your page and select an item from Web Part 1, the corresponding record will display in Web Part 2. Here’s what my web part page looks like after finishing these steps:

(click on the image to see a larger view)

Part 6: Make Web Part 2 display as “blank” until an item in Web Part 1 is selected

In MOSS 2007, this step was a doozy–complete with required setup of a data view web part, parameters, web part properties, etc. Fortunately, Microsoft has made this step quite easy for us in SharePoint 2010. Check it out:

Click on the black dropdown arrow for Web Part 1 (as shown below). When the web part menu displays, select Edit Web Part.
Open the Miscellaneous tab and de-select the “Send first row to connected Web Parts when page loads” option.
Click OK to save your changes.

That’s it! We now have a web part page with 2 connected web parts. When a selection is made in the left-hand web part, the corresponding list item details will display in the right-hand web part. If nothing is selected, the right-hand web part will remain blank.

Here’s what my final web part page looks like:

(click on the image to see a larger view)

But remember, this is only the beginning! Think of how else you can bling out your web part page using data view web parts, conditional formatting, etc.

Connecting web parts with a selector and a detail pane (MOSS 2007 version)

Business scenario:

(click on the image to see a larger view)

When you click on the radio button next to a help desk ticket in Web Part 1, the corresponding help desk ticket details display in Web Part 2. Here’s what the page looks like when issue ID #1 is selected:

(click on the image to see a larger view)

Neat! Now I want to take this one step farther…I want Web Part 2 to appear blank (without any issue details displaying) until a help desk ticket is selected in Web Part 1. Sound useful? If so, keep reading for details on how to build this out.

Solution:

While this solution can be built out in MOSS 2007 and in SharePoint 2010, the MOSS version does require a bit more leg work. Here are the MOSS 2007 components you’ll need:

SharePoint list (can be virtually any type of list, but this example was built with an Issue Tracking list)
Out-of-the-box list view web parts
MOSS 2007 web part page
SharePoint Designer 2007 (required to set up/configure parameters for passing data)

Ready? Let’s start building!

Part 1: Set up your web part page with connected list view web parts

Create the list that will hold the data you want to connect/display.
Create your web part page by going to Site Actions > Create> Web Part Page.
Select the formatting/style of web part page you want to use. (If you’re unsure which format to use, try the “Header, Footer, 3 Columns” web part page. This is the format I used for this example.)
When your new web part page appears, click on Add a Web Part button in the Left Column.
Select the list you created in step 1 above and click Add. You’ve now added Web Part 1 to your page.
Now click the Add a Web Part button in the Right Column.
Select the list you created in step 1 again and click Add. You’ve now added Web Part 2 to your page.
Now it’s time to go into each list view web part and select the columns/fields you want to display in that web part. Click on the edit menu for Web Part 1 and select Modify Shared Web Part.
When the web part config panel displays, click Edit the current view.
Select the field(s) you want to display in Web Part 1. As you can see in my example, I opted to display my ID and Title fields in Web Part 1 and Title, Priority, Category, Assigned To, Due Date, Created and Created By fields in Web Part 2. Note that you must have at least one column that displays in BOTH web parts. This will be your “syncing” column.
When you’ve finished making all your changes, click OK.
For best visibility, also change the Toolbar Type setting. Go to Modify Shared Web Part and set the Toolbar Type dropdown field to “No Toolbar.”
Repeat steps 8-12 for Web Part 2.
Click on the edit menu for Web Part 1 and select Connections > Provide row to > Name of Web Part 2.
If you have pop-ups enabled, a connection dialog box will display. If you don’t have pop-ups enabled, enable them and repeat this last step.
A connection configuration pop-up box will display. Click on the Column dropdown field and select the field you want to use to sync your web parts. Note that the field you choose MUST display on both of your web parts. In my example, I am using the Title field.
Click Next.
Click Next again.
Click Exit Edit Mode to stop editing your page. (If you can’t find the Exit Edit Mode link, look right under your Site Actions button.)

Congratulations! You have just synced your web parts. Now when you select an item from Web Part 1, the corresponding record will display in Web Part 2.

Here’s what my web part page looks like after finishing these steps:

Part 2: Make Web Part 2 display as “blank” until an item in Web Part 1 is selected

To make this happen, we need to pass data between the two web parts via parameters (instead of the “get filter from” connection option). In other words, we’ll force Web Part 1 to send its selected row of data to a data view parameter we’ll create for Web Part 2. We’ll also add a filter to Web Part 2 so it only shows data when Web Part 1 has a selected value. When your page loads, SharePoint will automatically filter out all the records in Web Part 2 since no record will have been selected in Web Part 1 yet. Sound complicated? It is. But don’t worry, the steps are all outlined below. Please pay close attention to the sequence of steps, however. All steps must be followed in the order outlined or the parameters and filter will not work correctly.

Open your web part page in SharePoint Designer 2007.
Highlight the web part that you want to display with zero results on initial page load. (In this case, that’s Web Part 2.)
Right-click the highlighted web part and select Convert to XSLT Data view. You’ll be prompted to convert that you want to make this change. Say OK.
Give your page a minute to refresh. You’ll notice a subtle change in the formatting of Web Part 2. It has now been converted into a data view web part.
Click in the upper right-hand corner of your new data view web part and find the > smart tag for the web part. (shown below)
Click the > smart tag (aka chevron) and select the Parameters… option.
Click on the New Parameter button.
Specify a name for your new parameter. You can use whatever name you like; just make sure the name is something you’ll remember (for at least the next few minutes) and make sure the name doesn’t contain spaces.
Keep all parameter defaults and click OK. The parameters screen should look roughly as follows:
You’ll be returned to your data view web part. Click on the > chevron and select Filter.
You want to set up a new filter rule that says Field = New parameter, where “Field” is the column you used to sync your connected web parts in Part 1 above and “New parameter” is the parameter you named in step 6. You will pick your field name and your parameter from the dropdowns provided. (Note that your new parameter will appear near the bottom of the Value selection list.) The screen shot below shows my completed filter. As you can see, I used the field Title to sync my web parts and I named my new parameter Param1.)
Click OK to save your new filter.
You’ll be returned to your data view web part. Click on the > chevron and select Web Part Connections…
When the Web Part Connection Wizard dialogue box opens, reset the action dropdown field to “Get Parameters From” as shown below:
Click the Next button repeatedly until you get to the screen shown below. When you get to this dialog, select the following options:
- In the middle row of the left column, select the column you used to sync your web parts. (In my case, this was the Title field.)
- In the middle row of the right-hand column, select the new parameter you created in step 6. (In my case, this was the Param1 parameter.)
Click on the Next button.
Click Finish to close out the web part connections dialog box.
You’ll be returned to your data view web part. Click on the > chevron and select Data View Properties…
Go to the General tab and click on the checkbox that says Display text if no matching items are found. In the provided text box, specify the default text you want to display when Web Part 2 is empty. Here’s what my text looks like:
Click OK to save your changes.
Save your web part page in SharePoint Designer. If you are prompted to confirm your changes, say yes.
Preview your changes in the browser.

My final solution looks like this:

We’re off to a great start, but there is so much more that you can do. At this point you have Web Part 2 set up as a data view web part (DVWP). Bling out that DVWP to display conditional formatting or to build editable fields right on your web part page. Let your imagination run wild–this is only the beginning!

Epilogue on having a “customized” or “unghosted” page

As you complete the steps outlined above and turn Web Part 2 into a data view web part, you are effectively customizing (or unghosting) your web part page. There is some debate in the community about unghosting pages, with some calling it a bad practice while others say it is called for on some occasions. I’m going to leave that debate up to the experts, but do want to call out that in some situations unghosted web part pages can lead to upgrade difficulties. To avoid this issue, you can export Web Part 2 from its current web part page and import it onto a clean, new web part page. Once you add Web Part 1 to your new web part page you can connect your web parts again. (This time, however, you will have the option of sending your data via parameters.) Exporting/importing your DVWP won’t affect the functionality of your connected web parts–it will merely ensure that your new (final) web part page won’t be customized or unghosted. Once you’ve completed this export/import process, you can then go back and delete your initial web part page.

There are some excellent blog posts that outline the steps for exporting/importing data view web parts. Check out http://www.wictorwilen.se/Post/How-to-export-and-reuse-the-Data-View-Web-Part.aspx for step-by-steps.

Using calculated fields to prioritize your SharePoint projects

I have to admit it…as a SharePoint practitioner I’m often guilty of overthinking. It’s easy to get drawn into designing complex solutions while overlooking simple features that generate a lot of user interest. I think this is a predictable problem, though. As we gain expertise in understanding how a platform like SharePoint works, we often gravitate to looking at complex, highly detailed solutions rather than focusing on the quick wins using “simple” functionality.

This blog post is all about the quick win, though. If you’ve seen me present at conferences or SharePoint user groups before, you know I’m passionate about documenting ROI for SharePoint projects. I follow up and formalize the business value of all my implementations (see my previous blog post I need some ROI…but I have no idea where to begin! for details). But I use ROI as more than just a means to summarize the value of projects I’ve completed. I start capturing ROI data during requirements gathering and rely on ROI estimates to prioritize my SharePoint project queue. This blog post walks through the simple SharePoint solution I built to use ROI estimates to auto-prioritize my projects.

First, let’s look at the completed solution. In the screen shot below, you can see a “SharePoint Requests” web part that displays my SharePoint project queue. Notice the Priority column. This is a calculated column that automatically assigns a low/medium/high priority to each project based on an automated ROI calculation. I use this priority rating to manage my queue of projects and determine my build/deploy schedule.

Here are the steps to build out this project prioritizer:

Create a new custom list in SharePoint.
Add in the fields you need to track your Sharepoint requests. My list contains the following fields:
- Project name – text field
- Requestor(s) – person/group field
- Request type – choice field
- Team – text field
- Request date – date field
- Status – choice field
- Collaboration owner – person/group field
- Estimated ROI per year – currency field
- Estimated hours to implement – number field
- Start date – date field
- Due date – date field
- High-level goals – multiple lines of text field
- Detailed requirements – multiple lines of text field
NOTE: The Estimated ROI per year and the Estimated hours to implement fields must be set up in your new list. They will be essential for the priority calculation.
Now that your base list is ready, you can set up your automated priority calculation. Go into your List Settings and create a new Calculated column named Priority (raw). Copy and paste the following text into the column’s Formula field:

=IF(ISERROR([Estimated ROI per year]/[Estimated hours to implement]),”-“,[Estimated ROI per year]/[Estimated hours to implement])

Specify that the data type returned by this formula be a number and press OK to save the settings for this new field.
Now you have an automatic calculation for your project priorities. But as you start entering data into your list, you’ll see that these numeric results aren’t terribly helpful. Depending on the values you enter into the Estimated ROI per year and the Estimated hours to implementfields, you may end up with raw priority numbers like 6,250 or 71.428571428571.
I’m no math whiz, but I know I can’t make sense of these numbers. In fact, their only inherent value is their position relative to each other. Fortunately, we’re not done yet! There’s still one more calculated column to set up…
Go into List Settings and create a second Calculated column named Priority. Copy and paste the following text into the column’s Formula field:

=IF([Priority (raw)]=”-“,”-“,(IF([Priority (raw)]<650,(IF([Priority (raw)]<300,”Low”,”Medium”)),”High”)))

Specify the data type returned by this formula to be a Single line of text and press OK to save the settings for this new field.
View your results. As you enter new projects and specify their estimated annual ROI and estimated hours to implement, you will see a raw numerical priority value and a subsequent priority ranking of Low, Medium or High.

If you like, you can even change the default numerical thresholds that translate your Priority (raw) values into Low, Medium or High rankings. Just tweak the “650” and “300” numerals in the Priority field’s formula to alter the default thresholds and find the specific differentiators that will best meet your needs.

Next steps I’ve been meaning to try include color-coding my prioritizations and building a fancier dashboard. But that’s for a later blog post 🙂

Storyboarding–the quick and the easy

Information architecture is not optional. And in a perfect world we’d all have adequate time for a formalized, thorough information architecture evaluation process at the beginning of each SharePoint solution cycle. But what if you have limited resources and need to provide a quick–yet effective–information architecture review? What are the essential steps you should be taking? This blog post summarizes my quick and easy information architecture/storyboarding methodology. It may take a bit of work to tweak this for your environment and shorten up the evaluation steps, but the framework should give you a good starting point. Enjoy!

We hold these truths to NOT be self-evident…

Before we begin, a couple of universal user truths:

Users (even the well-intentioned ones) will generally take the path of least resistance. They will create content and take the time to store it, but will often opt for familiar folder storage structures. While these structures make sense to the content creator, they are often difficult for others to navigate.
Users will be interested in functionality that can improve their lives. But they often won’t have the time to investigate this functionality on their own. They need information architects and designers to paint the vision. Often I throw out 15 ideas for each individual idea my business users choose to implement. There’s nothing wrong with a 15:1 ratio. The key is to keep offering ideas that will maximize user opportunities. Even if they don’t implement your ideas right away, they will likely circle back to consider some of the ideas again later.
If information architecture is optional, users will opt out. You need a carrot and a stick to get their attention. If you can offer SharePoint planning services free of charge and have a good reputation for delivering top-notch solutions, that will be all the “carrot” you need. If you can require team members to work with you in order to have a SharePoint site or site collection created, you have your “stick.” Again, if this model doesn’t work in your organization you’ll need to improvise. Just remember to include both the carrot and the stick.

The storyboarding process

I log my projects against the following SharePoint lifecycle stages:

Stage 1 (Initial request received)
Stage 2 (Storyboarding in process)
Stage 3 (Site/function development)
Stage 4 (Iterative review)
Stage 5 (Launched)
On hold (Waiting on business requestor; funding deferred)

Most of these stages are self-evident. Stage 1 begins when a SharePoint request is received. These can be requests for a new SharePoint site or enhancement requests for an existing site. Both “new” and “enhancement” requests follow the same storyboarding process.

First, I set up some one-on-one time with the business requestor. Since I work in the same geographical location as my customers, I have the luxury of setting up in-person meetings. Here’s the agenda I follow for these initial storyboarding meetings:

Introduce my role and explain our SharePoint methodology. This gives me an opportunity to explain how the “carrot and stick” works in my department while also enabling me to explain how our SharePoint site collections are structured.
Ask about their “vision” for the future. This question is intentionally vague. It is intended as a baseline, and won’t be the final vision statement for your SharePoint design. Usually, users will answer this question with a general statement saying they “want a site like Jane Doe has.” There’s nothing wrong with a broad answer here. Capture whatever the customer says and move on to the next step.
Ask what the business need(s) are they are trying to solve. In some cases, users will already have their scope defined. Generally, though, users are confused by this question. Again, don’t worry about a lack of detail in their answer. Capture the response and move on to the next step.
Get details on the current work process, including highlights, pain points and bottlenecks. Here’s where the deluge starts. Many users may have difficulty outlining a scope or vision for SharePoint, but most can wax poetic on pain points and bottlenecks in their common work processes. Encourage them to whiteboard their current pain points and allow them to dive into details. You’ll want to capture the broad strokes of this content and along the way identify opportunities where SharePoint can provide key wins. I try to capture several types of information during this step:

Key steps in the current process that can be automated using SharePoint.
Key pain points and bottlenecks. These will turn into the critical success factors for the future SharePoint solution.
“Soul crushing” work that can be eliminated or automated. These are the wins that will act as change management agents. Eliminate work that everyone hates and you’ll automatically build support for SharePoint
A rough percentage of time that can be shaved off the existing work process. This will help me capture a SWAG return on investment (ROI) for this solution.

Get a wish list of things they dream about. Tell them to think big and ask for the world on a stick. Don’t worry about keeping them “in scope”–just capture their answers. (Note that at this point many users won’t have any idea what SharePoint can do so their wish list may shoot too high or too low. Don’t sweat these details.)
Provide a demo of “similar” functionality already launched. At this point, I have a fairly good idea of the pain points and potential SharePoint solutions that could be built. Now it’s time to give the business requestors some idea of the possibilities. I provide a 15-minute targeted demo of existing SharePoint sites/functions that most closely align with their potential needs. For example, if the customer is in dire need of an optimized issue-tracking solution I’ll demo issue trackers with automated email and reporting that are already in use by other teams. If the customer needs help with document retrieval, I’ll demo a content type-based metadata tagging scheme that enables easy document upload/tagging.The key is to demo live sites that are already in use and have granularity levels or functions that mirror what the new customer needs. If you don’t have any existing SharePoint sites that apply, take them on a survey course of SharePoint wins you’ve already delivered for other teams. If this is your first SharePoint project and you don’t have any production sites to demo, start drawing out possible solutions on a whiteboard.The objective is to “blow the lid off” the customer’s expectations and get them “thinking big” about what SharePoint can do. You’ll know you’re hitting the right note when users start getting visibly excited and start tossing out additional ideas for how SharePoint can help optimize their business. Encourage them to brainstorm–the more ideas on the table the better!
Connect them with business owners that are already on their way. You are not objective. Clearly you are enthralled with SharePoint and have a vested interest in its success at your organization. In order to give your customers a fair (unbiased) view, recommend they touch base with other business owners that have already implemented SharePoint solutions. When these other business owners recommend SharePoint (and you), your customers will be doubly impressed.
Revisit the goals and wish list. Before you close out your meeting, revisit steps 3 and 5 to see what your customers updated goals and wish list items are. By this point, your customers should have a much broader list of features and functions they want to deploy. Capture as much of this information as you can. You’ll have the chance to map these goals and wish list items into project implementation phases at a later point in time.

Note that the timing for each of these eight steps is fluid. Depending on the size and scope of your project you may need to allocate 2 hours, 4 hours or even a full working day to get through all these steps. Over time I’ve been able to wean these steps down to a 1-2 hour meeting for small projects (aka projects that result in a 4-40 hour development effort). As the size of the implementation expands so will the amount of design time that is needed.

Also be aware that you may need to schedule follow-up meetings to dive deeper into one or more of these eight steps. Be targeted about these follow-up meetings. The key is to take up as little time as possible for information architecture. If we make the architecture process too painful, users will opt out and you will lose a SharePoint deployment opportunity.

Once you have enough raw material gathered, start designing your SharePoint vision for success. Tailor your vision to your audience. If your customer is informal and buys into your vision readily, you may be able to meet with them in person and present your vision for the future using whiteboard diagrams. If your customer is more formal or requires executive sign-off, you will need to create wireframes. Consider using Balsamiq (http://www.balsamiq.com/) or another quick wireframing tool to illustrate your vision. The key is to effectively illustrate your vision without taking the time to build out a robust system before gaining customer approval.

Once your requirements are documented and you get management sign-off you are ready to build out the solution!

#11 on the list of things I wish I’d known a long time ago…

Have you ever tried to open a data view web part (DVWP) in SharePoint Designer only to discover the page won’t load because it has too many records to try and display? Frustrating.

SharePoint Designer has an incredibly handy “Show with sample data” option that is intended to solve this problem. When you check this option, your DVWP will refresh and appear with 5 sample records. These sample records enable quick and easy rendering in SharePoint Designer but do not impact storage of your actual DVWP data.

But what if you don’t have “Show with sample data” turned on AND you can’t get your DVWP to load in SharePoint Designer because there are too many records? I ran into this issue several times before discovering that you can quickly and easily turn on the “Show with sample data” feature in code view. Since code view doesn’t display actual DVWP records (only the underlying code for your DVWP), it isn’t hampered by having too many list items to display.

Here are the steps to resolve this issue:

Go into SharePoint Designer and open your DVWP.
Click on Code view (available as a selection option at the bottom of the ASPX page view).
Do a Ctrl+F and type in the search term sampledata.
You will find the tag ShowWithSampleData=”False”
Replace the word False with the word True and save your changes.
Click on the Design view. Your DVWP will display with sample data.