Do You Use Yammer at Work? And Why Not SharePoint?

There was a question a while back on the Microsoft MVPs LinkedIn group (YAFSN! – see below) wondering “Do you use Yammer at work?”

I’m still trying to figure out how much I want to use Yammer. As when Google+ came out, I’m trying it. I pretty much abandoned G+, and Yammer may well go the same way for most things.

I got into Yammer via an invitation into SPYam from Bjørn Furuknap with my USPJA email address. Now I’m trapped into that identity for SPYam (the network for SharePoint discussions that Joel Oleson set up – ping me if you’d like an invitation) but have to use my work email address to access the SharePoint MVP network into which Microsoft has seemingly decided to move all communications. That tying of one’s identity to a single email domain (it seems you can’t combine domains into one über identity) is my biggest beef with the Yammer platform. I’m sure they will work that out, though. (Yammer probably could have done it in a few weeks. Now that it’s a Microsoft product, maybe in Yammer 2016, and you’ll only need to add a three server farm to enable it.)

I read a constant stream of complaints about other aspects of how Yammer works in – natch – Yammer. Sure, there are some true annoyances (no Shift-Enter in post entry, no parity between clients, Adobe Air!) but I could give you a litany of similar annoyances for every single YAFSN. User interfaces seem to always have annoyances. The important thing is how fast the people who develop the platform can react to consistent complaints and improve.

Everyone seems to think we need YAFSN (Yet Another Fantastic Social Network), but each new one that comes along simply fragments the landscape further. Who has the time to check dozens of these damn things? Social in the workplace must be a performance improvement, not a detriment. (I’d argue we should hold our personal social network use to the same standard. LOL catz!) if I have to check four or five social networks constantly in order to be well-informed, that drags down my efficiency.

I’ll keep using Yammer for the MVP stuff because I don’t have any choice, of course. Gotta get all those “secrets” somehow. It really makes me wonder, though, why we don’t use SharePoint to talk about SharePoint. It seems that in the vast majority of cases, SharePointilists prefer to use a different technology to communicate about SharePoint. That, to me, raises a far more important question: “Do you use SharePoint at work?”

Oh, I almost forgot to answer the original question. As a solo practitioner, there’s only me at work, so I don’t really need Yammer. I already have excellent tools in place to enable the voices in my head to converse.

jQuery Library for SharePoint Web Services (SPServices) v0.7.2 Released

Today I’m releasing SPServices v0.7.2. If you are using an earlier version of SPServices, I suggest that you upgrade to this version, as you will most likely see some performance improvements, especially if you use multiple value-added functions on the same forms pages.

Thanks to everyone who downloaded the beta over the last month or so and provided feedback. The most important piece of feedback I received was an incompatibility with jQuery 1.8.x, which I was able to fix and get into this release.


I’ve added a caching option into this version of SPServices and it can save a decent amount of traffic back and forth with the server, depending on how you are using things. It uses jQuery’s .data() functions to cache the XML for each request which has the option cacheXML: true. This is basically brute force. If cacheXML: true, then the returned XML is saved as a data object on the body of the page with the request XML as the key. If you make the exact same call again, then the request is fulfilled from that cache. Note that it has to be the “exact same call”. This means that the request XML has to match exactly.

I’ve set the option to true for some of the internal calls to the Web Services operations to speed things up when you use functions multiple times. For instance, quite a few of the value-added functions make a call to GetList to get details about the current list, and there’s no need to make that call more than once during the page life. If you are creating more than one cascade with SPCascadeDropdowns, for example, you’ll see an immediate improvement. However, since I can’t predict how many values you may have coming back from GetListItems calls, I haven’t turned on caching pervasively. I didn’t want to break things in an effort to be more efficient. Some client machines may not have the horsepower to cache large volumes of data, etc. If you know your data and your client machine capabilities well, you can set the option to true in the defaults – $().SPServices.defaults.cacheXML = true; – which will affect all Web Service operation calls in the current page lifecycle.

You can use the cacheXML: true option with any Web Service operation in SPServices Core, though as you can imagine some operations will benefit more than others.

SPFindPeople Picker

The SPFindPeoplePicker function helps you find and set People Picker columns. These little buggers are problem enough as it is, and selecting them and manipulating them with jQuery is something that a lot of people want to do. Add to that the fact that the People Picker is rendered differently in IE than in other browsers, and you have a challenge not unlike simple vs. complex dropdowns.

SPFindPeoplePicker allows you to get or set the values for People Pickers. When you call it with the DisplayName of a People Picker, the function returns an object which contains information about the People Picker’s structure nd current value. For instance, calling the function like this:

var salesRep = $().SPFindPeoplePicker({
  peoplePickerDisplayName: "Sales Rep",
  valueToSet: "APPTIXemullerbeck53"

returns an object which contains the following:

SPFindPeoplePicker Object


The DisplayName of the People Picker in the form.


This is reference to the table row which contains the People Picker. This can be useful if you want to hide or show the row conditionally based on some user action.


The full contents of the div[name='upLevelDiv'] element.


The current value set in the People Picker. If you pass a value into the function, it will be set and returned in this string. If there are multiple people specified, they are returned separated by semicolons, as in the People Picker display.


This is a reference to the checkNames img tag in the People Picker. It’s used by the function to initiate resolution of a Person or Group value by firing the click event on it. Once you have this reference, you can do the same.


If the browser is Internet Explorer, then this object will contain the full dictionary entry values for each user or group in the People Picker value. If the browser is not IE, then the function calls GetUserInfo to retrieve similar values to mirror the dictionary entry structure.

Other Release Notes

There are other goodies in this release, and you can see the full list of enhancements and improvements on the download page. Note the link to the Issue Tracker items for this release.

For posterity, the release notes are included below. You can check out all the changes (the release pages have a character limit for the release notes) in the Issue Tracker.

New Functionality

Alpha Issue Tracker Item Function Operation Description
ALPHA1 10071 $().SPServices.SPXmlToJson NA Enhanced userToJsonObject for use when ExpandUserField = True
ALPHA3 10074 $().SPServices.SPFindPeoplePicker NA Add SPFindPeoplePicker Function
ALPHA4 10070 $().SPServices.SPXmlToJson NA SPXmlToJson – calculated fields and “blank” xml attributes
ALPHA5 9969 $().SPServices.SPGetStaticFromDisplay and $().SPServices.SPGetDisplayFromStatic NA Getting multiple columns in one SPGetStaticFromDisplay call

ALPHA3 – Added caching capability to the SPServices core AJAX function to make it available across all SPServices value added functions and Web Services operations.

ALPHA7- Fixes to SPFindPeoplePicker to work with non-IE browsers.

New Operations

Alpha Web Service Operation Options MSDN Documentation Issue Tracker Item
ALPHA1 Diagnostics SendClientScriptErrorReport message, file, line, client, stack, team, originalFileType SharePointDiagnostics.SendClientScriptErrorReport Method 10028
ALPHA2 People ResolvePrincipals principalKeys, principalType, addToUserInfoList People.ResolvePrincipals Method 10062
ALPHA5 Lists AddListFromFeature listName, description, featureID, templateID Lists.AddListFromFeature Method 10064
ALPHA5 SpellCheck SpellCheck chunksToSpell, declaredLanguage, useLad SpellChecker.SpellCheck Method 10063
ALPHA5 Lists various NA see work item 9884

ALPHA2 – Added these Sites Web Service operations: CreateWeb, DeleteWeb, GetSite, GetSiteTemplates

Bug Fixes and Efficiency

Alpha Issue Tracker Item Function Description
ALPHA1 10061 $().SPServices.SPDisplayRelatedInfo Not Properly Handling UserMulti Columns
ALPHA1 9926 $().SPServices.SPCascadeDropDowns ‘&’ symbol values
ALPHA1 9925 NA dropdownCtl bug in Italian Sites
ALPHA5 9931 $().SPServices.SPGetLastItemId missing reference

SharePoint Designer 2013′s Missing Design View – More Thoughts

I’ve written previously about SharePoint Designer 2013′s Missing Design View here on my blog as well as on the Microsoft forums and elsewhere.. My goal in writing about this and making a lot of noise about it is not to simply complain. (We have way more complaining about everything out here on the InterWebz than we already need.) People need to understand what not having the Design or Split View in SharePoint Designer means if they upgrade to 2013 so that they can make good decisions.

At this point, I’m going to be going with the assumption that the net-net  answer is “hire more developers”. (Note: Assumption)

If the Code View is the only available view in SharePoint Designer, and existing functionality has been implemented with XSL-driven Web Parts, such as Content Query Web Parts (CQWPs) and Data View Web Parts (DVWPs), then there are two main options:

  1. Maintain the DVWP in Code View, which requires an XSL able developer. This is not at all easy. The XSL that SharePoint Designer generates – it is essentially playing a code generator role here – is horrible. There are some reasons for this that are legitimate: in order to be prepared for that next button you click on to change what you want to display in a DVWP, SharePoint Designer includes all sorts of stubs in its XSL For years, I’ve simply thrown away most of the SharePoint Designer -generated XSL and written my own because of this. However, altering existing DVWPs that have been implemented by power users become a development task going forward with 2013 even if a developer wasn’t needed before. It’ll have to be direct customization of the XSL in the Code View.
  2. Rearchitect the solution to use client-side processing. This is where Microsoft is clearly heading. The client-side push that started in SharePoint 2010 continues in 2013. Microsoft has expanded the Client Side Object Model (CSOM) and the REST Services. In many cases, the exact same functionality we have used DVWPs to build can be built with this new paradigm, but there will, of course, be cases where we have to make some trade-offs. Regardless, it becomes a developer task, as I can’t see many power users choosing to learn scripting.

If you follow me at all, you know that I love using client-side processing.with SharePoint to greatly improve the user experience (UX). The tools of the trade here are CSS, JavaScript and the many things that people have built to provide extended functionality, like jQuery, SPServices, and so many libraries, plugins, and add-ons it’s impossible to count. This is a great thing for SharePoint. As I’ve been saying for years now, it opens up SharePoint development to herds of new people who already have those Web development skills

But I also see a huge downside to this rush to client-siide development. The reason I coined the term “SharePoint’s Middle Tier” (OK, OK, I know most people hate the name – I can’t say it without the disclaimer) is that we do processing on the server *and* the client. We choose what makes the most sense in load distribution and put each chunk in the right place. Using a DVWP to do the heavy lifting of getting the initial load of data onto the page often covers a high percentage of use cases. Then we layer script (the other code) onto the page to provide behaviors and interactivity with the data without postbacks. By pushing for client-side processing exclusively, we lose that capability to architect well-balanced solutions (without cracking open Visual Studio – which Microsoft has started to discourage).

The biggest issue here is that we go from minimal error assistance – which is only shown in the Design or Split Views – to zero error assistance. Even a well-trained XSL developer or an XSL monkee like me will get zero error messages other than the essentially useless

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Windows SharePoint Services-compatible HTML editor such as Microsoft Office SharePoint Designer. If the problem persists, contact your Web server administrator.

error message in the browser and have to figure out what error we’ve introduced by feel.

Design and Split View for most of us who do this kind of work has nothing to do with “design”. The argument that SharePoint 2013’s new Design Manager allows us to design with something like Dreamweaver is somewhat specious. Instead, we use SharePoint Designer to develop real solutions using markup, DVWPs, script, etc. The Design View is where SharePoint Designer shows us what is going on. When I intentionally created a error in a DVWP to get the text for the error above, SharePoint Designer was telling me “This Web Part does not have a valid XSLT stylesheet: Error: A name was started with an invalid character. <<< “. That’s useful – I had added a couple extra < signs and it told me that I had. We totally lose that with no Design or Split View. The upshot of this is that there will be no reasonable way to build this type of solution or maintain existing ones. QED

Thus, we end up at option 2, which is a rearchitecting all the existing solutions which rely on development using the Design or Split Views. IT shops have used these methods as much as power users, at least at my clients, so it is my firm belief that this issue is going to be big and pervasive.

So, what’s the upshot of all of this? Well, if you plan to upgrade to SharePoint 2013 and have used the development methods I talk about here, then keep your eyes open to the level of effort it may require. Do a very careful inventory of solutions that you already have in place that were built using SharePoint Designer and think about what you will do with them in 2013. It’s not hopeless, but it’s going to be a lot of work.

Error Deleting a Content Type – “The content type is in use”

Are you as annoyed by this “The content type is in use” error as I am?

Error Deleting a Content Type

Error messages like this that don’t give you a way to solve the problem are a sign of the devil to me. That Correlation ID does us no good (try to find the administrator in a large organization to help you out in a timely way) and there’s no good way to find out where the Content Type is in use.

In many cases the Content Type may be in use with real content. However, in the instance where you are prototyping something and delete the list where you were using the Content Type, you know that it’s not in use anymore, right?

Well, it’s still in use, actually, but only sort of. When you delete the list, it goes into the Site Recycle Bin, so it actually still exists. It’s a great safety feature, but in this case, it’s getting in our way.

You need to delete that list from the Site Recycle Bin as well as the Site Collection Recycle Bin. The former is easy: you deleted the list so you have permission to delete it from the Site Recycle Bin.

Site Recycle Bin

The latter is only available to you if you are a Site Collection Admniistrator, so you may need to find someone who has that permission to help you out.

Site Collection Recycle BinOnce you’ve deleted the list from both Recycle Bins, you’ll be able to delete that pesky Content Type. Of course, you can also wait the requisite 60 days until the list is deleted from the Site Collection Recycle Bin automatically (by default – your settings may vary), but who will remember that far into the future? And we all know that a clean Site Collection is a good Site Collection.

Generic Error Handling in SPServices

Recently, I got this question in the SPServices Discussions:

I’m new to SPServices, and I was wondering if it is possible to define some kind of out-of-the-box error handling procedure, like this:

$().SPServices ({
operation: "DoSomething",
[option1: value1],
[option2: value2],
    // ...
success: function (xData) {
        alert ("The operation has been completed!");
        // some processing code ...
fail: function (jqXHR) {
        alert ("Something went wrong!");
        // some fallback code ....

The only thing I am aware of is that you can do something like this:

completefunc: function (xData, Status) {
    if (Status == "Success") {
        alert ("The operation has been completed!");
    } else {
        alert ("Something went wrong!");

However, this solution will also execute the success-branch when the server returns an XML-document containing error messages. Above that, I don’t think it’s that elegant because you would have to check the Status == “Success” every time you define a new request, which looks a little bit like overkill.

Any suggestions?

By the way: really love this project!

I was on vacation with only my iPhone (my first laptop-free vacation in probably 10 years!) so I waited until I returned to answer. The question is similar to many others I’ve received since I started working on SPServices.

Oh, I’d love to add something like this! Unfortunately, it’s not that simple.

There are two main layers where an error can occur:

  1. In the AJAX call itself. This really only occurs if the endpoint (SharePoint) isn’t responding, almost always due to the servers being down. SOAP may be an old, crufty standard, but it’s damn reliable.
  2. In the Web Service itself. Unfortunately there is almost zero consistency in the implementations. No two operations respond in quite the same way, and there’s really very little in common across the Web Services. Some operations return only one error message regardless what you’ve done wrong, and others return 5 or 6, but inconsistently. Some responses contain heavily nested XML while others contain a single element with many attributes. The only real commonality is that they return XML.

In all of my use of SPServices, I’ve found a few truths.

  1. SharePoint always responds if it’s up and running.
  2. The only time a Web Service call fails is if you pass it bad data or poorly formed XML.
  3. If you get a valid response, then the operation succeeded.

Early on I decided that my job in SPServices is to reduce the likelihood of 2. By eliminating the need to construct the SOAP envelopes, SOAP headers, etc., a huge number of errors simply never happen. It’s up to you to test the XML coming back to see if it contains what you expect.

While I could add error handling for some of the core operations, I would have to assume quite a few things about what you are doing. For instance, you might be calling GetListItems specifically to see if you get zero items back, and that might be a success to you.

What I *have* done is to add the debug mode to many of the “value-added” functions. Because I know what ought to be coming back when I make calls to the various Web Services, I can reasonably provide some error messages that are useful for you to use in setting things up. Things like this debug message:

SPCascadeDropdowns Debug Message Example
Which brings me to another important point: what should we do when there is an error? I’ve vowed to myself never to write an error message like “An error has occurred. Please contact your administrator.” (What error? Is it important? Do I need to do something to fix it? Who’s my administrator? How do I contact them? What do I tell them?) Even something with a correlation ID which can only be deciphered by an administrator is too obtuse. It’s the user who needs to know what to do if there’s a problem.

Given the myriad ways people use SPServices, I can’t possibly predict what they are building or how it should behave. It is first a toolkit and second a power user tool. The core of SPServices should give a developer lean tools that can use how they see fit. Generic error handling isn’t going to help them much because some of the edge conditions are good in some cases and bad in others. In the value-added functions, I intend the debug mode to help power users to get things set up, and then things should be humming and they should turn it off.

But what do we tell the user if there’s a problem? “I couldn’t write that item. Please try again”? Remember that the SOAP Web Services are *extremely* reliable. I can’t even recall an instance where I’ve seen a call to an operation fail when it’s passed good data and the servers are awake. We can assume that calls are going to work.

What do you think about all of this? How would you suggest I improve SPServices error handling?