Adding Geolocation Columns to SharePoint Lists

One of the cool things that came along in SharePoint 2013 was Geolocation fields in lists. Using Geolocation fields, we can display Map Views in SharePoint lists. This capability is an awesome way to add visualization to your UI and can really add value in many business processes.

Map View

Image Source: http://msdn.microsoft.com/en-us/library/office/jj656773(v=office.15).aspx

Think about it. You could show:

  • A map of your customers in a region
  • A map of your office’s location on its Intranet page
  • Deliveries you’ve made in the last 30 days
  • etc.

Unfortunately, at the present time in SharePoint 2013 on premises and SharePoint Online (Office365), “The Geolocation column is not available by default in SharePoint lists. To add the column to a SharePoint list, you have to write code.” (See How to: Add a Geolocation column to a list programmatically in SharePoint 2013)

For whatever reason, there’s no way to add a new Geolocation field via the UI. Instead you have to go through some hoops with PowerShell or script. See the following articles for great tutelage on how to do this:

As I understand it, there’s an MSI package (SQLSysClrTypes.msi)that must be installed manually on the Web Front Ends (WFEs) in an on premises installation to enable Geolocation fields, but this is already in place in SharePoint Online. Given this, we should be able to add Geolocation columns to lists via the UI without PowerShell or admin intervention.

This doesn’t sit well with me. At some of my clients, getting an admin to add something to the WFEs or run PowerShell requires an act of Congress. These Geolocation capabilities are too powerful a SharePoint feature to keep them under wraps.

To wit, I’ve created a suggestion called Adding Geolocation Fields to SharePoint Lists on the Office Development UserVoice site. If you’d like to be able to use Geolocation fields in your SharePoint solutions – at least on Office365 – head on over and cast your vote(s). Remember, Microsoft is listening!

Harvey Balls Redux – Display Templates for Site Columns by Dave Paylor

It may surprise you to know that one of my most popular blog posts has nothing to do with SharePoint, knowledge management, performance improvement, jQuery, client side coding, SPServices, or anything else you might expect. It’s one I wrote years ago (June 17, 2009, to be exact) called Harvey Balls for Office Documents. I though it was a throwaway post at the time, but it’s number 11 on the hit parade.

Title Views
Adding Script into a Content Editor Web Part (CEWP) in SharePoint 2010 32,547
Microsoft Excel Error: “There was a problem sending the command to the program.” 25,816
Adding jQuery+SPServices to a SharePoint Page: Step One, Always 23,973
Displaying Links Lists’ URLs in a Content Query Web Part (CQWP) in SharePoint 2010 22,971
Populating a SharePoint List Form with the Current User Information 20,789
Showing All Versions of “Append Changes to Existing Text” in a Data View Web Part (DVWP) 19,502
Using a DataSource in a Data View Web Part (DVWP) in a Different Site in SharePoint Designer 2010 18,904
The SharePoint 2010 “List View Lookup Threshold” and Why We Don’t Change It 18,848
Active Directory Groups vs. SharePoint Groups for User Management: A Dilemma 17,169
Working with SharePoint People Pickers with jQuery: A New Function Called findPeoplePicker 15,742
Harvey Balls for Office Documents 15,574

Harvey Balls are something that you probably have run across in one place or another. They can be used to give information about where something ranks or how far something has progressed at a glance. Consumer Reports magazine (and subsequently their Web site ConsumerReports.org) here in the US has used them for decades to rank products.

Here’s an undated example I found out on the Web:

Consumer Reports Harvey Balls

Dave Paylor (@DaveAtOBS) and I were talking at the Auckland airport after the New Zealand SharePoint Conference (an awesome conference – don’t miss it next year!) and somehow the topic of Harvey Balls came up.

Dave took our conversation as a challenge. He went home and came up with a Display Template for a SharePoint Site Column that will display that Site Column as Harvey Balls. Take a look at Dave’s post Display Templates for Site Columns – Harvey Balls.

This is an excellent example of the power of Display Templates. In the past, we would have had to deploy server-side code to create a new Field Type. I’ve seen very few people actually do that, probably because it was a relatively invasive project. Display Templates are something that can be added to a Site Collection by someone who knows JavaScript using SharePoint Designer. It’s not a non-developer task, but it’s doable by a lot of citizen developers out there.

Unfortunately, attaching the Display Template to a Site Column requires PowerShell. Dave’s added an item to the Office Development User Voice site called JSLink on Site Columns. I’ve voted for it, and if you’d like to create similar types of goodness in your SharePoint sites, you should vote for it, too. Microsoft is really watching the suggestions on that User Voice site and acting on them. If you have any other suggestions, please make them there!

Detecting the Current User’s Regional Settings with jQuery

I noticed a nice little trick going by in my Twitter feeds today.
2014-08-20_19-09-43I’ve always wanted to know how to do this. Displaying the right formats for dates and times as well as the right offset from UTC is a real challenge from the client side. There’s a fantastic library called Moment.js that I use on just about every project these days, but it only does the full job if you know the user’s locale and timezone.

The post on StackExchange gave a little snippet of script which came from an old MSDN Forums post from 2009. Kudos to Peter Holpar for the original idea.

The script basically screen-scrapes the values from the Language and Region settings page. I don’t mean that disparagingly at all; screen-scraping is how the SPGetCurrentUser function in my SPServices works. If it gets the job done and is reliable, the old art of screen-scraping – or should we call it plumbing the DOM with AJAX? – is just great.

Note that you’ll need to have jQuery loaded to use its AJAX function.

Here’s the script as-is from the StackExchange post. It was originally intended for SharePoint 2010.

var url = ctx.HttpRoot+"/_layouts/regionalsetng.aspx?Type=User";
$.get(url,function(data){
    $(data).find("select[name='ctl00$PlaceHolderMain$ctl00$ctl00$DdlwebLCID']").find(":selected").each(function(){
        var lcid  = $(this).attr("value");
        var cultureInfo  = $(this).text();
    });
});

I just tested it out in SharePoint Online on Office365 and this is the version that works for me. Note that I simplified the jQuery selectors to look just for the important ending text in the name attribute. I’ve also re-scoped the variables so that they are available outside the $.get call. If you want to use this snippet, you’ll probably need to adapt it for your environment. The alert at the end is jut there to show you that it works.

var url = _spPageContextInfo.webAbsoluteUrl+"/_layouts/regionalsetng.aspx?Type=User";
var lcid, cultureInfo, timeZone;

$.get(url,function(data){
  $(data).find("select[name$='LCID'] option:selected").each(function(){
      lcid  = $(this).attr("value");
      cultureInfo  = $(this).text();
  });
  $(data).find("select[name$='TimeZone'] option:selected").each(function(){
    timeZone  = $(this).text();
  });

  alert(lcid + "::" + cultureInfo + "::" + timeZone);
});

SharePoint List Settings Issue: “Internet Explorer is required to use this feature.”

This one belongs firmly in the “things that make you go hmm…” department.

Let’s say you are a good do-be like me and you use all of the Microsoft products that you can get your hands on. You’ve got email and SharePoint running on Office 365, you use all the Office applications and tools, you’re up to date on your version of Internet Explorer… You get the picture.

Well, sometimes all that good behavior doesn’t pay. Today I wanted to edit an InfoPath form attached to a list in SharePoint 2013 on premises. (You won’t run into this problem on Office365, at least it doesn’t happen in my tenant. Office365 seems to know IE11.) I went to the List Settings and clicked on the Form Settings link. I’m using Internet Explorer 11, so I’m as up to date as I can be without getting into beta territory.

Lo and behold:

Internet Explorer is required to use this feature.

Internet Explorer is required to use this feature.

Yup. I’m using Internet Explorer and the message says “Internet Explorer is required to use this feature.” The issue is that the on premises install that I’m working with doesn’t understand Internet Explorer 11. It *should* see it as Internet Explorer, though, and give me a better message. I’m not exactly sure what patch level we’re on, but I think it’s pretty close to current.

Fortunately, there is an easy fix for this. Simply hit F12 to bring up the Developer Tools and scroll all the way down to the bottom of the left side icon list.The one you want to click on looks like this:

Emulation

That will give you access to the Emulation settings. Change the User agent string setting to Internet Explorer 10.

2014-06-18_10-21-10

Fixing the issue by changing the User agent string

The page will reload and now SharePoint will understand that you are the good do-be that you are, speaking IE10ish instead of IE11ish. After you do your work, it’s a good idea to switch back to default so that you are speaking IE11ish again.

The Emulation settings give you a bunch of other nice tools (want to act like an XBox360?), so if you have interest in testing things in different browsers types, etc., be sure to check out the rest of the settings as well.

SPServices: What About Deprecation of the SOAP Web Services?

SPServices user JSdream asked a question in the SPServices Discussions on Codeplex the other day that’s worthy of a more prominent response.

Should we, who use SPServices, be concerned at all with Microsoft recommending not to use either the ASMX web services in SharePoint 2013 (http://msdn.microsoft.com/en-us/library/office/jj164060.aspx#DeprecatedAPIs) or the owssvr.dll (I used this one a lot when doing InfoPath stuff) for development purposes?

The Choose the right API set in SharePoint 2013 article is an important one, for sure. In it, there’s pretty clear direction about which API to choose based on the specific requirements of the solution you are building. As with anything, though, there’s a strong dash of “it depends”. It depends on things like your available skills, the device the code will run on, etc.

Figure 1. Selected SharePoint extension types and SharePoint sets of APIs

Figure 1. Selected SharePoint extension types and SharePoint sets of APIs

I would say that we should all be “cautious” rather than “concerned”. The SOAP Web Services are used by many parts of SharePoint still, with the most prominent being SharePoint Designer. If you sniff around in the traffic between processes, you’ll spot other places as well.

That said, deprecated is deprecated. If you build your solutions with the data access layer separated out from the business logic layer, you should be able to replace the calls if and when it becomes necessary.

I am not aware of any official specific time frames for the SOAP services going away, and the Product Group would need to give us a good, long lead time because lots of code depends on it, SPServices or not. Many people have built managed code-based solutions which use the SOAP Web Services as well. GetListItems is a workhorse operation no matter how you build your solutions.

There are many things you simply cannot do with REST yet, though in many cases CSOM may provide better coverage. If you are using SPServices for the operations which aren’t available in REST or CSOM, obviously you’ll want to continue doing so until there is a viable replacement. The REST coverage is improving steadily. (See Overview of SharePoint Conference 2014 and new content for developers for some information.) Keep in mind, though, that the majority of improvements will end up in Office365 first and in the SharePoint Server product at some point later or perhaps not at all. So your time horizons and cloud plans are also critical decision factors.

[If I had to put my money on a horse, it'd be REST over CSOM over the long term.]

All that said, if you are starting a new project on SharePoint 2013 of any significant size, you should be considering using the App Model, CSOM, and REST. SPServices may still fit in there somewhere, so don’t toss it out with the bath water just yet. I’ll continue evolving it as long as it has people wanting to use it. I think I still have plenty of things to do.