Using Yammer Embed in SharePoint Online

One of the use cases for Yammer Embed is to provide a commenting system for SharePoint pages. This can be achieved using the Yammer Embed Open Graph method. It is possible to generate the necessary code for this using the Yammer Widget (which is my preferred way as you can test the options as you go) or code from scratch using the published documentation. An example code snippet is shown below:

<script type="text/javascript" src="https://c64.assets-yammer.com/assets/platform_embed.js"></script>

<div id="embedded-feed" style="height:500px;width:500px;"></div>

<script>
yam.connect.embedFeed({
 container: '#embedded-feed'
 , network: 'your_network_name.com'
 , feedType: 'open-graph'
 , config: {
 header: false
 , footer: false
 , showOpenGraphPreview: false
 , promptText: "Comment on this page"
 , defaultGroupId: 4191007
 }
 });
</script>

I recommend playing with the Yammer Widget to test the configuration options.

Using Yammer SSO and Yammer DSync?

If you are using Yammer SSO and Yammer DSync in your environment then you will need to adjust your code by adding the use_sso: true element to the configuration section. You will also need to be very aware that Yammer SSO and Yammer DSync are being deprecated and will stop working after December 1st, 2016. You will not be able to set up new configurations with Yammer SSO and DSync after April 1st, 2016. An example code snippet is shown below:

<script type="text/javascript" src="https://c64.assets-yammer.com/assets/platform_embed.js"></script>

<div id="embedded-feed" style="height:500px;width:500px;"></div>

<script>
yam.connect.embedFeed({
 container: '#embedded-feed'
 , network: 'your_network_name.com'
 , feedType: 'open-graph'
 , config: {
 use_sso: true
 , header: false
 , footer: false
 , showOpenGraphPreview: false
 , promptText: "Comment on this page"
 , defaultGroupId: 4191007
 },
 "objectProperties": {
 "url": location.href,
 "description" : " Comments feed for page ",
 "title": document.title + " (captured with document.title)",
 "image": "https://mottmac.sharepoint.com/sandpit/Documents/CompassIcon_100.jpg",
 "type": "page",
 }
 });
</script>

Adding the code to SharePoint Online

There are a couple of options for adding the embed code to SharePoint Online and I’ll cover them in detail in another post. If you wish to test out your code, simply paste it into a Script Editor Web Part. The result will look something like this:basic commentsCreating a comment using the feed will send details of the page to Yammer which would then create a specific Yammer page to hold the comments. The result in Yammer will be:

basic page in yammer
In my opinion, the outcome is less than optimal and to understand why we need to go behind the scenes.

What is happening behind the scenes

When you post using Yammer Embed, it attempts to resolve information about the SharePoint page using a behind the scenes Yammer service (which was previously Embed.ly.) It then uses this information to set items like the name of the page in Yammer and the descriptive text. However, this service does not have the ability to resolve metadata from a page that requires authentication to access, is located behind a firewall etc. This inability includes pages in SharePoint Online as they are located behind an exterior ‘Sign in to Office 365’ sign-in page. When the service attempts to resolve information, the ‘Sign in to Office 365’ page gets in the way. The result is the incomplete capture of information and pages in Yammer sharing the Title ‘Sign in to Office 365’ and Descriptive text ‘It looks like you are on a slow connection. We’ve disabled some images to speed things up…’. Each page is unique as it uses the URL from the SharePoint page but the experience is sub-optimal, for example, searching for a particular page will result in many identical search results.

A solution

The solution is to include the information Yammer needs to help the service resolve the page information. This is achieved using objectProperties in the Embed code. Unfortunately, you cannot use the Yammer Widget for this – though I hope in the future they can provide some common examples. In the case of SharePoint, you will also need to know some SharePoint properties so you may need to enlist the help of your friendly developer. The method is to add a section to the Embed code that provides the Open Graph metadata for consumption by Yammer (which in turn it will use to create the page). An example code snippet is shown below:

<script type="text/javascript" src="https://c64.assets-yammer.com/assets/platform_embed.js"></script>

<div id="embedded-feed" style="height:500px;width:500px;"></div>

<script>
yam.connect.embedFeed({
 container: '#embedded-feed'
 , network: 'your_network_name.com'
 , feedType: 'open-graph'
 , config: {
 header: false
 , footer: false
 , showOpenGraphPreview: false
 , promptText: "Comment on this page"
 , defaultGroupId: 4191007
 },
 "objectProperties": {
 "url": location.href,
 "description" : " Comments feed for page ",
 "title": document.title + " (captured with document.title)",
 "image": "https://your_sharepoint.com/sandpit/Documents/CompassIcon_100.jpg",
 "type": "page",
 }
 });
</script>

Note the comma that has been added at the end of Line#16. The code will fail if the comma is omitted. The result in SharePoint will look something like this:

feed in SPO after

With the corresponding page in Yammer:

feed in yammer

What the code is doing

The purpose of each item in the snippet is as follows:
[Line #18] “url”: location.href this sets the URL property used in the Yammer page to that of the Page in SharePoint. (location.href is a SharePoint property)
[Line #19] “description” : ” Comments feed for page “ this sets the description text that will appear on the Yammer page. In this example I have used text but you can use a SharePoint page property, for example if you are using a Byline property in the page or use a combination of property and text (see next item for an example).
[Line #20] “title”: document.title + ” (captured with document.title)” This sets the Yammer page title to that of the SharePoint page and appends an additional snippet of text to the title. A potential gotcha with this is if you change the Title of the SharePoint page after it is created. The Title field will use the original name unless you edit it. (I’ll cover changing this in another post.) As with other items you could use a different SharePoint page property to populate this item. (document.title is a SharePoint property)
[Line #21] “image”: https://your_sharepoint.com/sandpit/Documents/CompassIcon_100.jpg This sets the image shown in the page header of the Yammer page (very much like a Group icon). In this example I have set it to use our Intranet icon.
[Line #22] [ “type”: “page” ] This tells Yammer that the object is a page. If you were using this solution say for Office 365 Video you might set this to “video”.

Wrap up

And there you have it, a way of using Yammer Embed in SharePoint Online. In future posts I’ll cover methods of managing instances of Yammer Embed in SharePoint Online as well as items like renaming of SharePoint pages.

Advertisements

How we monitor and react to change in Office 365

evergreen_shipping_liner_insight_the_loadstar_600_400

Let’s start with an analogy

It’s one I use when explaining how change occurs in Office 365. It might need some polish!

The super-freighter in the image moves deceptively quickly and it will cross the Atlantic in around 10 days. Whilst though it is slow to start, it takes a long time to change direction and often needs help doing so.

The vessel runs on a schedule and its movements within controlled waters are published so all mariners are aware

When out at sea, normal waves have no impact upon it and radar is constantly scanning so icebergs and other debris are foreseen and avoided.

The containers it carries change regularly and very occasionally a “reefer” falls off and is lost at sea.

Now consider Office 365 to be the super-freighter, the containers a mix of product features.

The service is evergreen – that is Microsoft updates it on a monthly cycle. Some of their Roadmap is published (schedule), some of the changes are communicated (published shipping movements), some of the changes are just imposed (containers fall overboard), new features are added whilst others are taken away (containers are loaded and others unloaded.)

As a consumer, the bulk of this is out of our control. In addition, A/B testing can temporarily add / remove functionality for specific users (or in freight terms, a container gets temporarily misplaced).

How do we monitor and react to change

To stay agile and proactive, we have established our Ships Bridge in yammer and have created an O365 Change and Strategy Group. Members of the group are encouraged to #workoutloud in order to share their thoughts, observations, alerts as quickly and as honestly as possible. The group contains key stakeholders from across the IT service and we can invite others in as the need arises. We monitor and react to change by:

1. Identifying the potential changes

For this we have a network of inquisitive radar operators. We use a combination of:

  • the Microsoft Monthly Service Update ‘newsletter’ (which is issued by our Microsoft Technical Account Manager)
  • weekly reviews of the Message Centre
  • conversations with companies that we are working with
  • a near constant eye on the Office 365 Yammer Network
  • the Office 365 Roadmap (which some of us consume using a RSS feed)
  • plus some other sources that we’d not like to reveal

All of the knowledge is discussed in the dedicated Yammer Group and when we know the MSG ID (from Message Centre postings) we tag the conversations with it (as well as adding links to threads on the O365N etc.). We also maintain a tracking spreadsheet (as you’ve got to have a spreadsheet). To be honest it is too much like hard work and Yammer and Microsoft should make this easier.

2. Discuss the potential changes

We have an allocated slot in our weekly team meetings to discuss roadmap items and how we intend to tackle them. Significant items are reviewed with projects and/or change tasks created.

The tricky part is not knowing exactly when the change will arrive. I usually take actions to try and get more information. For example, Yammer announcements are usually pretty light on actual detail. What really helps is the Change Alerts group in the O365N as customers typically in North America get the change days or weeks before it arrives in our UK tenants. By following that group, we get an early warning of impact, mitigation and customers we can talk to.

3. Test the change

Fingers crossed it arrives in our First Release* tenant. At that point we play and test it, grab screenshots and prepare the communications for it. Every Office 365 feature has a dedicated space in our Intranet. We typically prepare a new page that describes the feature and briefly explains how staff might use it.

An exception to the rule is Yammer as from this day to the next and one user to another we sometimes do not know what is an A/B and what is a feature release as they seldom use the Message Centre (though I understand plans are evolving to improve that).

4. Communicate the change

Obviously the greater the impact the more we do. Massive change means staff briefings, board meetings etc. The bulk of changes are communicated using our Intranet – we use the page created in step 3 as the news item. We also push news out across yammer – again with links back to the article. Sometimes a targeted email blast is employed and we have a dedicated service alerts banner that we can enable in our intranet. In time we will start to surface the service announcements from the Office 365 Admin Centre within our Intranet using the Office 365 Management API.

 

 

* As an aside, we operate a second tenant with a small amount of content in full First Release mode and our Production tenant has Selective First Release for named users – sometimes the change is hard to test as we do not have enough content or numbers of users in our test tenant – we are looking at using ShareGate to snapshot our production instance and replicate the content in test, though this will not replicate the number of users which is vital for testing items like people search and profiles