Category Archives: Dashboards

Social Media Dashboard for SharePoint


Part of my keynote at SPTechCon last week was a demo of a social media dashboard created by Marc Anderson. He was able to incorporate live feeds from Twitter and Yammer into a page while manipulating the interface so that it didn’t look like SharePoint. He also created a little magic by making it possible to send SMS messages from the tweet streams.

There has been a lot of talk since his presentation, so we decided to update the interface and present a live, online walk-through so people can hear Marc talk about how he created it and then watch him step through the construction of the page so you can try it on your own.

This will be a fast paced, fun session that will give you some new ideas on how you might manage your own SharePoint interfaces. Register for the session and we’ll send you the URL for login the morning of the event.

Looking forward to seeing you there,
Mark and Marc

JQuery dashboards to SharePoint: How To

You may also be interested in: SharePoint Solutions In-A-Box from Alcero


Editor’s note: Contributor Peter Ward is a SharePoint Solution architect. Follow him @peter_1020

This post outlines the steps to apply JQuery dashboards to a SharePoint 2010 page.

  • No coding or administration is required.
  • Skillset: Power user, you should be familiar adding content to SharePoint pages. Eg: Content Editor web parts
  • The data has to reside in lists

- For further details see Alexander Bautz post. he did the heavy lifting, this is a more step by step approach to his code.


Add these components to your Site.

  1. Copy the contents of this JS file into the Site Assets library of the site: Click here


  1. Create a list in the site called GoogleVisualization_InteractiveChartsConfig (This name has to be exact) . This list should be based from a list template called. If this templatge doesn’t exist in the site collection, email SharePoint Support and they will add it.

This is the template that needs to be added by the site collection administrator. Click here

  1. Goto the page were you want to display the charts
  2. Add 2 Content Editor web parts parts to the page where to want to display th charts

TIP: To understand how to add a content editor web part, click here.


  1. Add the following HTML code into the Chart 1 Content Editor web part

<div id="MyChart1"> </div>

  1. Add the following HTML code to the HTML footer code Content Editor web part

<script type="text/javascript">
// All charts must be represented by a container with a unique id. This container must be present in the page
arrOfChartContainers = ["MyChart1"];</script><script src="/sites/Sales_and_Trading/client_relationship_management/DashboardBoard/SiteAssets/js/jquery.min.js" type="text/javascript"></script><script src="" type="text/javascript"></script><script src="/sites/Sales_and_Trading/client_relationship_management/DashboardBoard/SiteAssets/js/ChartUsingGoogleVisualizationAPI_v2.9.3.5.js" type="text/javascript"></script>

NOTE: The path in the HTML above must correspond to the path of your site.

  1. Save content editor web part and the page.

2012-07-18-jQueryDashboards-03.pngThe HTML is now saved on the page. The chart must now be configured.

  1. Click on the download arrow of the web part.


  1. Complete the Chart configuration menu:

From this:




  1. Click Save

The chart should display:


To add additions charts to the page. Add additional content editors:
With the HTML :

<div id="MyChart2"> </div>

And make the addition to the HTML footer:

= ["MyChart1", "MyChart2"];</script><script src="/sites

Further Reading:

The API -

Graph options:



A jQuery Library for SharePoint Web Services (WSS 3.0 and MOSS): Real World Example - Part 2

Guest Author: Marc D. Anderson

In my last article, I showed how I used my jQuery Library for SharePoint Web Services to improve data quality by enhancing an out of the box form using the SPRequireUnique, SPDisplayRelatedInfo, and PreSaveAction functions. In this installment, I’ll show you how I created part of the nice dashboard-like page to display the current state of things to each Project Manager using Data View Web Parts (DVWPs). In this article, I won�t be showing any usage of the jQuery Library for SharePoint Web Services, but in a later article, I’ll show you how I use it again to enable easy bulk upload of the project artifacts.

Figure 1: Project Manager’s Dashboard

You’ll need to bear with me a little bit on this one. Because this example uses an actual client site, I’ve needed to doctor up the screenshots quite a bit. Hopefully you’ll still be able to get the general idea. In Figure 1: Project Manager’s Dashboard, you can see the dashboard for the Project Manager. This dashboard has three main components. In this article, I’m going to talk about sections A and B.

The top DVWP shows basic information about the Request (remember that a Request is like a sub-Project). In this first DVWP, I’m just displaying some of the important metadata about the Project and the Request. Since the data comes from items in those two lists, I’m using an AggregateDataSource. If you want to build your applications by using lists like relational tables (ALWAYS a good idea), you’ll need to become familiar with the AggregateDataSource concept.

This code is going to look a little messy, but here’s how you specify an AggregateDataSource:

    <SharePoint:AggregateDataSource runat="server"  IsSynchronous="" SeparateRoot="true" RootName=""  RowsName="">
   <SharePoint:SPDataSource  runat="server" DataSourceMode="List" SelectCommand="&lt;View&gt;&lt;/View&gt;"  UseInternalName="True">
   <WebPartPages:DataFormParameter  ParameterKey="ListName" PropertyName="ParameterValues"  DefaultValue="SDLC Projects"  Name="ListName"></WebPartPages:DataFormParameter>
    <SharePoint:SPDataSource runat="server"  DataSourceMode="List"  SelectCommand="&lt;View&gt;&lt;/View&gt;"  UseInternalName="True">
   <WebPartPages:DataFormParameter  ParameterKey="ListName" PropertyName="ParameterValues"  DefaultValue="SDLC Requests"  Name="ListName"></WebPartPages:DataFormParameter>
   <concat  name="data source">
   <datasource  name="SDLC_Projects" id="0" Type="SPList"/>
   <datasource  name="SDLC_Requests" id="1" Type="SPList"/>

When you create a Linked Source in SharePoint Designer (SPD), this is basically the code that you get. IMHO, SPD does a horrible job formatting the code it generates, so one of the first things I usually do is to clean up the formatting of what it creates. Unfortunately, any reformatting that you do of the DataSources will not "stick"; each time you save the page, SPD will mess it all up on you again.

The important sections of the AggregateDataSource are:

  • < SharePoint:AggregateDataSource> - This simply says that you are specifying a DataSource which includes multiple sources.
  • < SharePoint:SPDataSource> - You specify an SPDataSource for each individual source. In this case, the two lists: SDLC Projects and SDLC Requests. For simplicity here, I’m grabbing all of the items from each list (SelectCommand="<View></View>") but the SelectCommand is where you would specify any CAML you need.
  • <SelectParameters> - For each source, you need to indicate where it is. You do this with <WebPartPages:DataFormParameter>s. Note that I have switched from ListID to ListName. This can be helpful if you want to refer to your lists by their text name rather than their GUIDs. This also makes your code portable, in that SharePoint will just look for a list with the name you�ve specified rather than a specific GUID, which will be different across sites, Site Collections, or Web Applications.
  • <Aggregate> - In this section, you assign working names to the individual DataSources which you then use to refer to them later in your XSL. I typically just use the list name with any spaces replaced with underscores (there can’t be spaces here).

To create the links in section B, which is actually part of the same DVWP as section A, I needed some IIS Server Variable values. Another important "set up" section of the DVWP is the <ParameterBindings> section. Here it is with a few of the garden variety bindings left out.

   <ParameterBinding  Name="URL" Location="ServerVariable(URL)"  DefaultValue=""/>
   <ParameterBinding  Name="SERVER_NAME" Location="ServerVariable(SERVER_NAME)"  DefaultValue=""/>
   <ParameterBinding  Name="PATH_INFO" Location="ServerVariable(PATH_INFO)"  DefaultValue=""/>
   <ParameterBinding  Name="ProjectID" Location="QueryString(ProjectID)" DefaultValue=""/>
   <ParameterBinding  Name="RequestID" Location="QueryString(RequestID)"  DefaultValue=""/>

Again, this is basically what the code looks like when you use the dialogs to create parameters. (At this point, I just go into Split View and write most of this myself because it’s faster for me.) There are three Server Variables I’m using: URL, SERVER_NAME, and PATH_INFO. You can find full documentation for the available Server Variables on MSDN. I’m also grabbing the values for the ProjectID and RequestID from the Query String. This is how the page "knows" what Project and Request we’re interested in.

OK, so I’ve got the DataSource set up, I’ve got the ParameterBindings set up, now it’s time for the XSL. Here are a few of the key bits.

<Xsl><xsl:stylesheet version="1.0"  exclude-result-prefixes="xsl msxsl ddwrt"  xmlns:ddwrt=""  xmlns:asp=""  xmlns:__designer=""  xmlns:xsl=""  xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:SharePoint="Microsoft.SharePoint.WebControls"  xmlns:ddwrt2="urn:frontpage:internal"><br>
   <xsl:output  method="html" indent="no"/>
   <xsl:param  name="URL" />
   <xsl:param  name="SERVER_NAME" />
   <xsl:param  name="PATH_INFO" />
   <xsl:param  name="ProjectID" />
   <xsl:param  name="RequestID" />

In this top part, I’m just declaring the stylesheet and specifying the xsl:params I built up in the ParameterBindings section. This makes their values available in the XSL as well.

Next comes the initiation template. I don�t actually know what this is really called, but I think of it as kicking off the whole process. It calls my first real working template, SDLC_Requests. SPD by default uses template names like dvt_1, dvt_1.body, etc., but I replace those names with names that match what list or data I’m working with to make it easier to follow.

<xsl:template match="/"  xmlns:asp=""  xmlns:__designer=""  xmlns:SharePoint="Microsoft.SharePoint.WebControls">
   <xsl:call-template  name="SDLC_Requests"/>

In the SDLC_Requests template, I simply grab the item from the SDLC_Requests list I want, and start building the table I want to display. (Think of xsl:templates as being sort of like subroutines.) I create a variable called Rows and select all of the items in the SDLC_Requests list which have a Title (I’ve repurposed the Title column for the RequestID) which matches the values on the Query String. If you remember, in the last article I made sure that the RequestID is unique per item. Next I call the SDLC_Requests.rowview template to generate the table rows.

<xsl:template name="SDLC_Requests">
   <xsl:variable  name="Rows"  select="/dsQueryResponse/SDLC_Requests/Rows/Row[@Title =  $RequestID]"/>
   <table  border="0" width="100%" cellpadding="2"  cellspacing="0">
   <xsl:for-each  select="$Rows">
   <xsl:call-template  name="SDLC_Requests.rowview" />

The SDLC_Requests.rowview template is where the action is; this is where I output the actual values from the appropriate list items. I won’t show all of the XSL, but here are some of the interesting pieces.

At the top of the SDLC_Requests.rowview template, I set up some xsl:variables. For each of these three variables, I’m grabbing a value from the parent SDLC_Project’s item based on the ProjectID in the SDLC_Requests item�s ProjectID column. (Again, I’ve repurposed the Title column in the SDLC Projects list for the ProjectID.)

<xsl:template name="SDLC_Requests.rowview">
   <xsl:variable  name="Methodology"  select="/dsQueryResponse/SDLC_Projects/Rows/Row[@Title =  current()/@ProjectID]/@Methodology"/>
   <xsl:variable  name="Applications"  select="/dsQueryResponse/SDLC_Projects/Rows/Row[@Title =  current()/@ProjectID]/@Applications"/>
   <xsl:variable  name="BusinessGroup"  select="/dsQueryResponse/SDLC_Projects/Rows/Row[@Title =  current()/@ProjectID]/@Business_x0020_Group"/>

The next part shows how I output the header for the DVWP. I wanted it to look just like the normal page header, so I used the same CSS class. The call to ddwrt:IfNew lets me display the usual New! Icon if the Request was created recently.

   <td  class="ms-webpartpagedescription" style="padding-left:0px;"  colspan="2">
   <xsl:value-of  select="@Request_x0020_Description"/> (<xsl:value-of  select="@Title"/>)
   <xsl:if  test="ddwrt:IfNew(string(@Created))">
   <IMG  SRC="/_layouts/1033/images/new.gif" alt="New" />

Next I start outputting the column values for the Request. For each row, I’m using the same CSS classes which are usually used on the DispForm.aspx page. I like to try to keep the formatting consistent across pages. I’m using conditional formatting for the Methodology column so that I can show a message if the value is blank. (A blank value here is a problem because the artifact requirements are driven by what the Methodology and Request Type values are.) I’m only showing a few of the columns here; the rest of the XSL looks pretty similar.

   <td  class="ms-formlabel" width="25%">
   Request Type
   <td  class="ms-formbody">
   <xsl:value-of  select="@Request_x0020_Type"/>
   <td  class="ms-formlabel" width="25%">
   <td  class="ms-formbody">
    <xsl:when  test="string-length($Methodology) > 0">
    <xsl:value-of  select="$Methodology"/>
   <i>No  methodology specified.</i>

Finally, I output the links in section B. You’ll see that I’m building up rather complicated links so that I can both pass the values I’ll need on the other end as well as be ensured that I’ll be passed back to this page with the needed values for ProjectID and RequestID when I return.

   <td  colspan="99">
   <table  style="width: 100%">
   <td  class="actiontext">
   <a  href="Lists/SDLC%20Requests/EditForm.aspx?ID={@ID}&amp;Source={$URL}?ProjectID={$ProjectID}%26RequestID={$RequestID}">Edit  the Request</a>
   <td  class="actiontext">
   <a  href="Default.aspx?Group={ddwrt:UrlEncode(string($BusinessGroup))}">Go  back to <xsl:value-of select="$BusinessGroup"  disable-output-escaping="yes"/> projects</a>
   <td  class="actiontext">
    <a  href="/sites/CSO/KR/SDLC%20Artifact%20Repository%202010/Forms/AllArtifacts.aspx?RootFolder=%2fsites%2fCSO%2fKR%2fSDLC%20Artifact%20Repository%202010%2f{translate($RequestID,  ':', '-')}">View All Artifacts for this Request</a>
   <td  class="actiontext">
   <a  href="ArtifactsMatrix2010.aspx?RequestType={@Request_x0020_Type}&amp;Methodology={$Methodology}&amp;ProjectID={$ProjectID}&amp;RequestID={$RequestID}">View  Artifact Requirements</a>
<p>  </xsl:template></p>

In the next article, I’ll show what�s going on in the DVWP in section C, followed by what happens behind the scenes when the Project Manager decides to click on one of the Upload links to add artifacts to the repository.

Guest Author: Marc D. Anderson

Marc D. Anderson is a Co-Founder and the President of Sympraxis Consulting LLC, based in Newton, MA.  He has over 25 years of experience as a technology consultant and line manager across a wide spectrum of industries and organizational sizes.  Marc has done extensive consulting on knowledge management and collaboration and what makes them actually work in practice.  Marc is a very frequent "answerer" on the MSDN SharePoint - Design and Customization forum.


3 Minute Screencast: Create support links in a SharePoint WSS Dashboard

One of the recommendations I give in all of my SharePoint Site Administration Workshops is for every site to have contact information for the site manager in the top, right corner of the entrance page to every site. In this screencast, I show how to use LyteBox functionality to open a support contact page without losing the context of the underlying page.

Embed this screencast on your site.

(Insert Screencast)


Access to support pages, the use of LyteBox, and other techniques for creating dashboards in WSS, are included in the Tuesday, June 30 live online workshop, Case Studies in SharePoint WSS Dashboards. The workshop is a three hour, live online, hands on session where you are given your own SharePoint sandbox to practice implementing the dashboard solutions.

1 Hour Screencast: Build a Project Management Dashboard w/ SharePoint

I was able to hang out with my good friend Dux Raymond Sy at SPTechCon last week. When I walked into one of his sessions, he stopped his presentation to ask "What are you doing here? You’ve seen this SO many times!" Well, Dux, it’s good stuff! So good in fact, let’s take a look at his recorded screencast to see what techniques he uses when building a Project Management Dashboard w/ SharePoint.

(Insert Screencast)

Visual status indicators, and other techniques for creating dashboards in WSS, are included in the Tuesday, June 30 live online workshop, Case Studies in SharePoint WSS Dashboards. The workshop is a three hour, live online, hands on session where you are given your own SharePoint sandbox to practice implementing the dashboard solutions.

4 Minute Screencast: Dashboard Indicators in SharePoint WSS

One of the limitations of WSS is the lack of KPI and visual status indicators. In this screencast, I show a technique for displaying status information as a bar graph within any SharePoint list or library. Thanks to Christophe Humbert from Path to SharePoint for the original idea.

Embed this screencast on your site.

(Insert Screencast)


Visual status indicators, and other techniques for creating dashboards in WSS, are included in the Tuesday, June 30 live online workshop, Case Studies in SharePoint WSS Dashboards. The workshop is a three hour, live online, hands on session where you are given your own SharePoint sandbox to practice implementing the dashboard solutions.

Add Twitter to your SharePoint Site

Adding a Twitter feed to your SharePoint 2007 My Site or entrance dashboard is a quick and easy way to keep your co-workers updated regarding what you are working on.

Quick Twitter updates allow virtual team members to feel more a part of a group, while providing updates on the work being produced, avoiding potential duplication. This becomes increasingly important for virtual team environments, as it has been shown that virtual team members prefer to know what other members of the team are working on.

Add Twitter to your SharePoint Site