Tips & Tricks

Innovation Games: An Introduction

Let’s start with the obvious question–what are Innovation Games?

Innovation Games are a set of simple games you can play with your customers, your peers and your project teams to build shared understanding. There are a wide variety of Innovation Games; each game is designed to elicit a different outcome or data set. Some games can help you uncover unmet market needs. Other games are geared to driving product design, building/repairing relationships or creating strategic plans. The games themselves are just tools; a set of gaming principles and best practices you can leverage to gather qualitative information. The data gathered through Innovation Games can be used to shape strategies, gain momentum and build bridges with core constituent groups. Bottom line: Innovation Games are a fun way to engage your customers, your employees and your teams.

In September 2015, I led an introductory workshop on Innovation Games for MNSPUG (the Minnesota SharePoint User Group). The session introduced the concept of Innovation Games and highlighted how Innovation Games can help teams gather requirements, build consensus, drive strategic direction and recover broken work streams and projects. MNSPUG attendees were able to see Innovation Games at work firsthand. Don Donais, Liz Sundet, Matt Ruderman and I facilitated a live version of the Low-Tech Social Network and four separate iterations of the Speedboat game during the 3-hour workshop. Check out the pics of our completed games below.

This slideshow requires JavaScript.

If you’re interested in learning more, check out the MNSPUG session recording below. (A big thanks to the folks at Avtex for providing the recording.) To help you navigate the lengthy session, track times are outlined below.

07:48 – Kickoff of the Innovation Games session
11:29 – What are Innovation Games?
15:45 – Why use Innovation Games?
26:45 – How do Innovation Games work?
34:08 – Introduction of the Low-Tech Social Network game
44:33 – Introduction of the Speedboat game
59:00 – Summarizing the results of your game
01:15:30 – What types of other Innovation Games are there?
01:32:07 – Resources/Recommended Follow-Up Reading
01:34:00 – Video of MNSPUG attendees playing the Low-Tech Social Network game
01:35:52 – Results of the Low-Tech Social Network game
01:39:00 – Video of Sarah teaching attendees how to facilitate a Speedboat innovation game

Advertisements

How do I disable the Edit link on my SharePoint 2013 pages?

Did you know that granting your end-users Contribute level access in SharePoint 2013 enables them to edit wiki and web part pages across your site (including your site’s home page)?

Site pages are stored in the Site Pages library by default. Since this library automatically inherits its permissions from the site, anyone with read/write access to the site also has read/write access to all site pages. Users with read/write access will see the Edit link shown below whenever they navigate to a site page.

EditPage-01

So how do you grant your users Contribute (aka read/write) access to your site and ensure they don’t get an Edit link on site pages? You change the permissions for your Site Pages library. If you grant users Contribute access to your site but read-only permissions to your Site Pages library, they will be able to view all your site pages but not edit them.

Here are the steps to modify the permissions for your Site Pages library:

  1. Go to your site.
  2. Click on Gear > Site contents.
  3. Find and click on your Site Pages library.
  4. Click on the Library tab and then click on the Library Settings button.
  5. Click on the Permissions for this document library link.
  6. Click on the Stop Inheriting Permissions button on the page’s toolbar.
  7. Say OK to confirm you want to customize the permissions for this library.
  8. Modify the library’s permissions as desired.

TIP: Make sure you give users read access to your Site Pages library. This will ensure they can see and access your site’s home page.

 

Having trouble lining up your SharePoint 2013 app parts on your wiki pages?

If you’ve built any new wiki pages in SharePoint 2013, you may have experienced some issues getting your web parts to line up nicely–particularly if you’ve modified the text layout of your wiki page to have multiple side-by-side columns. The columns make it easy to line up multiple app parts side by side, but the wiki pages’ tendency to add in extra paragraph spacing above some of your app parts can make it hard to line up all your app parts on the same vertical axis point. Here’s an example of a page that is suffering from some extra paragraph spacing:

Spaces05

As you can see in the shaded yellow box, I’m getting an extra paragraph of space above my app part in the left-most column of my page. These extra spaces seem to occur on wiki pages specifically, and usually in the left-most column of my page.

I could solve this problem by creating a Web Part Page instead of a Wiki Page (since web part pages don’t throw in these extra spaces), but I still wanted to figure out how to troubleshoot this type of issue on a wiki page.

Here are the steps I followed to create the wiki page shown above:

  1. Go to Gear > Add a page
  2. Type in a name for your page. (I named mine Queue.) At this point a new wiki page is created and saved in the Site Pages library of your site.
  3. Set the text layout for the page. Go to your Format Text ribbon, click on Text Layout and select Three columns with header
    Spaces01
  4. Now you’re ready to insert your web parts. Place your cursor in your header zone, click on the Insert ribbon and select Web Part.
  5. We’re going to insert an image here, so click on the Media and Content web part category and then select Image Viewer and click on Add.
    Spaces03
  6. I’ll add in my image by clicking on the open the tool pane hyperlink in my new Image Viewer web part. Here’s our finished image:
    Spaces04
  7. Now we’re ready to add some app parts to the page to render our list data. I’m going to add 3 app parts to the page–one in each of my page’s 3 columns. Here are the steps I followed to add each app part:
    1. Click into a column.
    2. Click on the Insert ribbon and select App Part.
    3. Choose the list or library you want to use and select Add.

Once I finish adding my 3 identical app parts to my page, this is what I see:

Spaces05

I tried simply placing my cursor in the extra space and hitting delete, but that deletes my app part entirely. The best way to remove this extraneous spacing is to edit the source of the page and remove the offending HTML paragraph tags. Here are the steps to perform this cleanup:

  1. Place your cursor in the extra paragraph space you want to get rid of.
  2. Click on the Format Text ribbon and select Edit Source.
    Spaces06
  3. Notice the spare paragraph tag located at the top of your HTML Source. (Shown highlighted in yellow below).
    Spaces07
  4. Highlight all the text on line 1 of your HTML Source and press your Delete key to remove it.
  5. Press OK to save your changes.

The trouble with filtering on workflow status columns…

Have you ever tried to filter a SharePoint list or document library view using a workflow status column? It’s harder than you’d think…

Workflow status columns report the current status of a workflow. A unique workflow status column is created in your list (or document library) automatically when you create a new out-of-the-box or SharePoint Designer custom workflow. Conveniently, SharePoint uses the name of your workflow as the name of your workflow status column. An example workflow status column is shown below (in yellow). This Email-notification column reports on the status of the Email-notification workflow.

wf-filtering-01

Being a savvy SharePoint user, you’d think you could use the workflow status verbiage as a filter for your list or document library view. Unfortunately, you’d be wrong. You cannot filter your list or library records using the displayed verbiage in your workflow status column(s).

Let’s take a look at an example:

I have a Team assignments list (shown below). It’s a very simple list that allows people to sign up for product areas they want to support. When a new item is created, a custom SharePoint Designer workflow runs and sends some automated notification emails. I can keep tabs on my workflows using the Email-notification workflow status column. As you can see, I currently have items in several different workflow statuses–2 of my list items are in Completed status while another 2 are in In Progress status.

wf-filtering-01

Now let’s say I wanted to create a new list view that only shows me list items that are in Completed status. I go to the List tab, click on Create View and set up my view filter to display only the items where Email-notification is equal to Completed. Sounds perfect, right?wf-filtering-02

Unfortunately, this view shows zero results–despite the fact that I know I have items whose workflow is in Completed status. Why does this happen? Because Microsoft actually uses numerical status codes to demarcate workflow states. While SharePoint displays “friendly” descriptors for their workflow states (e.g. In Progress or Completed), you need the numerical status codes to be able to filter against the workflow state. The difficult part is finding the correct numeral for the workflow state you want to filter against.

After doing some searching online, I found that the numeral 5 denotes a Completed workflow. When I update my view to filter and display only the items where Email-notification is equal to 5, my list returns the Completed workflow items I was looking for. Here’s a picture of my working filter:

wf-filtering-03

The trick, of course, is figuring out what numerals are used for the other possible workflow states. Here’s a quick list of the workflow states I typically filter against:

  • In Progress = 2
  • Approved = 16
  • Error Occurred = 3
  • Not Started = 0

For a more exhaustive list of workflow status codes, visit http://adayinsharepointv3.blogspot.com/2012/08/filter-list-view-by-sharepoint-workflow.html

Richard Harbridge presents: Why use SharePoint workflow?

I love SharePoint workflows. I believe they’re an essential building block in the routing and tracking of your business data. But understanding where (and how) to use workflows is a challenge–particularly when you’re new to SharePoint.

Richard Harbridge (SharePoint thought leader and speaker) recently published a conceptual guide to SharePoint workflows. Here’s an excerpt of his post:

SharePoint Workflow: What Should We Use It For? What Are Other People Using It For?
 
We all know that we should always aim to automate and improve our business processes more. Many organizations reap enormous benefits from improving the way they work alone or with other people through enabling technologies like SharePoint. The big question is how do we start? Or perhaps which processes or workflows should we automate and improve first? This article dives into this issue and offers advice and recommendations based on successful experiences with many customers.
 

The post goes on to 1) describe the initial scenarios and conversations many SharePoint users have about workflows, 2) define the types of workflows that can be  used and 3) explain the rules under which the workflows should be used to automate business processes. If you are new to SharePoint (or are a SharePoint advocate that wants to understand how workflows can benefit your organization), check out Richard’s post. You won’t be disappointed.

Limitations on modifying content types via SharePoint Designer reusable workflows

Man's hand tied  limitation with a rope. On a white background.If you’ve read my blog post on using content types to modify your NewForm.aspx and EditForm.aspx pages, you know how fond I am of using SharePoint Designer workflows to flip the values in my Content Type fields. Since content types control which fields are displayed on your forms, they provide an easy way to customize the input forms for your lists and libraries. The trick is building SharePoint Designer workflows that automate the transitions between your content types. By flipping the value in your Content Type field via workflows, you make your list and library forms look dynamic–all without the effort of building custom ASPX pages.

Unfortunately, I hit a major snag this week while trying to modify the Content Type field in a reusable workflow in SharePoint Designer 2010. No matter how I set up my reusable workflow (e.g. assigning the workflow to work with one content type or ALL content types), I couldn’t use the Set field to… action in SharePoint Designer to reset the value in my Content Type field. Neither the Content Type nor the Content Type ID field appeared in the list of columns I could select to update. And I couldn’t add the Content Type or Content Type ID field as Associated Columns either.

reusable-workflow-01

I did some research, talked with a few smart folks and finally figured out why the Content Type field cannot be modified via a reusable workflow. Unlike “normal” list workflows, reusable workflows aren’t tied to a specific document library or list when they are created. Reusable workflows are built and published independently so they can be ported–or assigned–to any of your site collection’s libraries or lists. Unfortunately, the portability that makes the reusable workflows so useful also inhibits the workflow’s ability to modify the Content Type field.

When you associate a content type to a document library or list in SharePoint, the document library or list sees and recognizes the new content type’s ID. Because it knows the content type IDs that are associated to your list/library, SharePoint Designer allows you to query against the content type and update it via a workflow. Reusable workflows aren’t associated with document libraries or lists until after they’re published. As a result, SharePoint Designer can’t see or obtain any relevant content type ID(s) during workflow creation. This is why SharePoint Designer locks out the Content Type and Content Type ID fields from being updated via reusable workflows.

The only ways I’ve found to work around this issue are:

  1. Use list workflows instead of reusable workflows.
  2. Use reusable workflows, but leave out the Content Type field flipping. Your users will just have to reset the Content Type field by hand.

Anyone have additional ideas?

You may want to rethink your column names…

Depositphotos_2506386_mWhen 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=

column-internal-names-02

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

column-internal-names-03

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.

column-internal-names-06

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:

  1. Customer comes to your SharePoint site.
  2. 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.
  3. They fill out the form and click Save.
  4. 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:

  1. Go to your site’s landing page.
  2. Click on Site Actions > Edit Page.
  3. Click on one of the Add a Web Part buttons.
  4. 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.)
  5. 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.
  6. 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.)

  1. Go to your site’s landing page.
  2. Click on Site Actions > Edit Page.
  3. Click on one of the Add a Web Part buttons.
  4. 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.
  5. 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.
  6. When the web part pane appears, click on the Source Editor… button.
  7. 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.
  8. 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:

  1. Go to the list you want to create a custom hyperlink for.
  2. 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.
  3. Open a new browser window.
  4. Go to the address bar and do a Ctrl+V to paste in your newly copied URL.
  5. Press Enter. You will automatically be redirected to your list’s New Item page.
  6. 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.)

  1. Go to your site’s landing page.
  2. Click on Site Actions > Edit Page.
  3. Click on the Insert subtab.
  4. Click on the More Web Parts icon.
  5. Click on Forms, select the HTML Form Web Part and click on the Add button.
  6. 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.
  7. When the web part pane appears, click on the Source Editor… button.
  8. Delete the text that appears in the text entry box.
  9. 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.
  10. 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:

  1. Understand your business requirements.
  2. 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:

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

  1. 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.
  2. 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.
  3. 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.)
  4. 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.
  5. 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>"
  6. 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.
  7. When you return to your list view, you’ll see your new calculated column displaying with <DIV> tags. Not very attractive.
  8. To correct this issue, we’re going to add our HTML script to the page. Click on Site Actions > Edit Page.
  9. Click Add a Web Part and add a new Content Editor Web Part to your page.
  10. 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.
  11. Click on the CEWP’s open the tool pane hyperlink.
  12. 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

  1. 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.)
  2. 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.
  3. 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>"
  4. 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.
  5. When you return to your list view, you’ll see your new calculated column displaying with <DIV> tags. Not very attractive.
  6. To correct this issue, we’re going to need to modify this new calculated column. Open your site in SharePoint Designer 2010.
  7. 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.
  8. 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.
  9. 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.

  10. Hover over the <xsl:value-of> tag until a black dropdown arrow appears. Click on the dropdown arrow and select Edit Tag…
  11. 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”
  12. Your Quick Tag Editor box should now read like this:
  13. 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!
  14. Click File > Save 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 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:

  1. 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
  2. Once you find a new color you’d like to use, note the color’s name.
  3. Go to your SharePoint list’s List Settings page.
  4. Find and click on your new color-coded calculated column.
  5. Look at your field’s formula and find the words redorange 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/