Gritter and Sharepoint: integrate nifty notifications in your intranet!

I’m working with a client on building up a project management tool in Sharepoint; one thing that’s really piqued their interest is the concept of getting short flashes of information when their staff logs into the landing page. I think it’s a lovely idea, and I’m intend on giving them this functionality – but how, you might ask? There doesn’t seem to be any Sharepoint feature for doing that!

We tend to forget that Sharepoint is, above all, a web-based solution. This means that, with a little ingenuity (and sometimes a lot of sweat and blood), you can integrate some of the latest, coolest web features into your existing Sharepoint. Fortunately, notifications are not too complicated. In this short article, we’re going to walk through creating very cool notifications using Gritter, a jQuery-based “plugin”, with Sharepoint.

Step One: Create a Sandbox

This may be as simple as creating a new page in your Site Pages repository. I seriously recommend implementing a proof-of-concept rather than work on your production page… If you’re not familiar with these libraries, the last place you want to test things out is on your production work, as easy as these implementations may seem.

Apart from your page, your sandbox will need a few extra files. These you can either place in the Site Assets repository of your PoC portal, or in the Site Assets repo of your root. The latter has the benefit of being accessible to your entire audience (or at least I assume so, it will depend on your permissions). The files that you need are the latest minified version of jQuery, the latest version of Gritter, and the latest version of SPServices (double-check these pages for compatibility issues, of course – if Gritter or SPServices tell you that they won’t work with certain versions of jQuery, don’t use those versions…)

When downloading Gritter, you’ll notice that it is a zip file that has several folders and files. I recommend that you keep those in one single place in your Site Assets. I find it’s easiest to use Sharepoint Designer to do that.

Step Two: Add Your jQuery References

Now that you have a sandbox, you can start working with it. In case you’re wondering, this section is assuming that you’re working with Sharepoint Designer to do your work.

Open your sandbox page in SPD, editing it in Advanced Mode. Locate the PlaceHolderMain placeholder and add the references to your script files:

<!– Inserted by Rick – references to jQuery scripts –>

<!– These are the references to jQuery and SPServices. –>

<script type=”text/javascript” src=”../SiteAssets/jquery-1.8.3.min.js”></script>

<script type=”text/javascript” src=”../SiteAssets/jquery.SPServices-0.7.2.min.js”></script>

<!– These are the references to Gritter: –>

<link rel=”stylesheet” type=”text/css” href=”../SiteAssets/gritter/css/jquery.gritter.css” />

<script type=”text/javascript” src=”../SiteAssets/gritter/js/jquery.gritter.min.js”></script>

<!– End Rick insertions. –>

You can test that the libraries loaded correctly by firing up Chrome, navigating to your PoC page, and opening your Console (F12). In the Console, type the following:

$
$(document).SPServices
$.gritter

If either of these return ‘undefined’, review your references, make sure the files are uploaded in the correct location.

Step Three: Setting up your notifications!

OK, now we know that all the necessary libraries are loaded. Time to develop notifications.

Always develop incrementally, testing your code one chunk at a time. To that effect, here’s code that you should insert after the above script blocks:

<!– Here’s a test notification –>

<script type=”text/javascript”>

$(document).ready( function() {

$.gritter.add({

title: ‘This is a test notification’,

text: ‘This will fade after some time’

});

});

</script>

If that works, you know that Gritter is functional for static content! Now it’s time to pull the real notifications from a list — this is where SPServices comes in. Before we proceed, we need something to pull information from: create a custom list with a single title for your PoC, “Latest Activities” for instance. Then, you will call the GetListItems function using SPServices.

The following code replaces your test notification:

<!– Code for notifications –>

<script type=”text/javascript”>

//This function throws up the notification:

function notify(curTitle, curContent) {

$.gritter.add({

title: curTitle,

text: curContent

});

}

//This retrieves the latest item of your Latest Activities.

function getLastActivity() {

$(document).SPServices({

operation: “GetListItems”,

async: false,

listName: “Latest Activities”,

CAMLRowLimit: 1,

CAMLQuery: “<Query><OrderBy><FieldRef Name=’Created’ Ascending=’False’ /></OrderBy></Query>”,

CAMLViewFields: “<ViewFields><FieldRef Name=’Title’ /></ViewFields>”,

completefunc: function(xData, Status) {

$(xData.responseXML).SPFilterNode(“z:row”).each(function() {

notify(‘For your information…’, $(this).attr(“ows_Title”));

});

}

});

}

//On document load, throw up the notification:

$(document).ready( function() {

getLastActivity();

});

</script>

Et voilĂ  — Gritter and Sharepoint notifications in a nutshell! Your page will load and, once loaded, will call the getLastActivity function. getLastActivity pulls the latest item from the Latest Activities list (we use the CAMLQuery parameter to order by create date, and the CAMLRowLimit parameter to only return one parameter), and use a callback function to call the notify() function. The notify function is what is responsible for rendering the Gritter notification.

Happy notifying!

Rick.

>Customizing your list’s look & feel in Sharepoint 2010

>I’ve been working on a Sharepoint 2010 intranet for a client; a real pain in the arse was setting up a feed with an image in the web part, customized ‘Add an item’ text and the ability to customize the look and feel via CSS. When you add the list as a web part to a sharepoint page, you’re unable to perform these customizations using a WYSIWYG editor or web part properties; however you can specify an XSL template. Here’s mine:

<?xml version=”1.0″?>
<xsl:stylesheet xmlns:xsl=”http://www.w3.org/1999/XSL/Transform&#8221; version=”1.0″ xmlns:ddwrt2=”urn:frontpage:internal”>
  <xsl:include href=”/_layouts/xsl/main.xsl”/> 
  <xsl:include href=”/_layouts/xsl/internal.xsl”/>
  
  <xsl:template match=”/” xmlns:ddwrt=”http://schemas.microsoft.com/WebParts/v2/DataView/runtime”&gt;
    <div class=”webfeed”>
      <img src=”/pages/SiteAssets/myimage.png” style=”float: right;” class=”boximage”></img>


      <xsl:for-each select=”/dsQueryResponse/Rows/Row”>
        <xsl:if test=”string-length(@Title) &gt; 0″>
          <a href=”/Lists/MyList/DispForm.aspx?ID={@ID}”>
            <xsl:value-of select=”@Title” /></a><br/><br/>
          </xsl:if>
      </xsl:for-each>




      <xsl:call-template name=”Freeform”>
        <xsl:with-param name=”AddNewText”>Add an item</xsl:with-param>
        <xsl:with-param name=”ID”>
          <xsl:choose>
            <xsl:when test=”List/@TemplateType=’104′”>idHomePageNewAnnouncement</xsl:when>
            <xsl:when test=”List/@TemplateType=’101′”>idHomePageNewDocument</xsl:when>
            <xsl:when test=”List/@TemplateType=’103′”>idHomePageNewLink</xsl:when>
            <xsl:when test=”List/@TemplateType=’106′”>idHomePageNewEvent</xsl:when>
            <xsl:when test=”List/@TemplateType=’119′”>idHomePageNewWikiPage</xsl:when>
            <xsl:otherwise>idHomePageNewItem</xsl:otherwise>
          </xsl:choose>
        </xsl:with-param>
      </xsl:call-template>




    </div>
  </xsl:template>
</xsl:stylesheet>


Normally, I *hate* color-coding anything; but since I’ve only used a few colors, it should be pretty easy to read.


I’m not going to go through the entire thing — I think the code is pretty self-explanatory (not that you should have been able to cook this shit up in your head or anything… But once you see it in front of you, it’s pretty easy to understand what each part is). However, I’ll walk through the highlights. If there’s anything you see that you don’t understand, or isn’t clear, feel free to comment!  

A customized ‘Add’ button:

Notice that one of the first things I do is include some of sharepoint’s own XSL templates — I’ve pointed these out in red.  Then, I add the ‘call-template’ section, which is highlighted in blue, at the end of my XSL. This renders the line, the + icon, and the Add text. I’ve highlighted the text you can customize in bold — you’ll have probably noted that what the code does is call a template from sharepoint XSL’s with two parameters. The first parameter is the text you want to customize; the second is a value that is computed based on the list’s type — if it’s an announcement, it’s set to idHomePageNewAnnouncement, if it’s a document it uses idHomePageNewDocument, and so forth. I generally save my images and resources in SiteAssets. Does anybody have any counter-indications there? I found it to be useful to make sure versioning is enabled for the repo; this way, if any changes in my resources mess up the layout or anything, I can revert to a previous version.

An embedded image:
The image (purple in the code) was pretty easy; notice that in order to embed it nicely in the text, I just used float: right in the style attribute. 
Additional styling:
Let’s face it: faffing about with XSL is fun, but not very practical for a web designer. I’m particularly sucky at aesthetics, so I want to make sure that I can pass off as much of that kind of work into the right hands as possible and make it as easy as I can.
Note the presence of the DIV (in green) at the beginning of the XSL: it has a class attached to it (webfeed) so that it can be customized via CSS. Same goes for the image described above (boximage). This means that you can have a CSS file in your SiteAssets repository in which you can put in any formatting specifications for both the links of the feed and the image of the feed; note that in order to apply this CSS, you’ll have to edit the portal’s master page(s) to reference it.
The benefit of having a separate CSS file from the site theme CSS is that it can be made accessible to your team’s web designer without granting the designer any particular permissions to the sharepoint server. The CSS file will be versioned, so you can quickly revert if something gets screwed up in the layout or colors, and if the file is accidentally deleted it can be restored from the Recycle Bin (rather than permanently deleted from a NetBIOS share…)
CFN!

Addendum: I’ve also been asked to modify the behavior of the link; instead of opening a new page, it’s supposed to open up Sharepoint 2010’s new modal pop-up dialog box. What at first seemed really annoying and complicated turned out to be quite easy. Substitute this line:

<a href=”/Lists/MyList/DispForm.aspx?ID={@ID}”>
            <xsl:value-of select=”@Title” /></a><br/><br/>

With these lines:

<xsl:variable name=”formLink”>/Lists/MyList/DispForm.aspx?ID=</xsl:variable>

<a>
  <xsl:attribute name=”href”>
    <xsl:value-of select=”$formLink” />
    <xsl:value-of select=”@ID” />
  </xsl:attribute>


  <xsl:attribute name=”onClick”>
    <xsl:text>javascript:NewItem2(event, &quot;</xsl:text>
    <xsl:value-of select=”$formLink” />
    <xsl:value-of select=”@ID” />
    <xsl:text>&amp;RootFolder=&quot;);javascript:return false;</xsl:text>
    </xsl:attribute>


    <xsl:value-of select=”@Title” /></a><br/><br/>

What does this do? First, it attributes the URL to a variable, $formLink. Then, it renders that variable in the ‘href’ attribute of the link. Finally, it calls an AJAX function of Sharepoint’s that opens up a modal dialog box and renders the content of the URL specified in $formLink. Presto! Instant Sharepoint 2010 panache.