I am putting together a presentation talking about UI hacks that we all need to do in order to accomplish everyday UI customizations that our customers – internal or external – require. For this one I want to limit it to SharePoint 2013 and/or SharePoint Online (Office365). Another way to think of it is how and why we brand SharePoint today on premises and in the cloud; not just things that people want cosmetically, necessarily, but stuff that is hard to do and must be done.
I’d like to collect ideas from all of you out there, which I will collate into some slides (with credit given, of course!). I posted a quick tweet about this and already got a few replies, so I figured a blog post would be a good way to gather information as well.
In thinking about this, I’ve come up with some broad buckets:
- Documentation Gaps
- Document Object Model (DOM) Changes
- Missing Functionality (Oft Requested)
I’ve already got a few items of my own in each of those categories, but I’d like the presentation to be representative of what we all have to deal with, not just me. If you think I’m missing a bucket, let me know your ideas on that, too.
Let’s use this post’s comments to capture as much as possible. If you’d rather email me directly, you can use the Contact form. When I have a decent amount of content collected, I’ll come up with a way to share it on some level. (The actual purpose of this is classified.)
Thanks for your help on this.
It’s the message SharePoint gives us that we’ve learned to love or hate or be indifferent to. But it’s a message that we cannot escape if we use SharePoint even a little bit. Yes, I’m talking about “Working on it…”
When I was in Stockholm this week speaking at the SharePoint and Exchange Forum (SEF), I noticed that the Swedish version of “Working on it…” was “Snart klart…”. According to my pal Christian Ståhl (@CStahl) at Humandata in Stockholm (the fine folks who put on SEF),
About ’Snart klart…’ this is strange translation, it’s more like ‘something will be finished soon‘ (maybe not always clear what) more than SharePoint actually doing something. Snart klart.. is more ok as an short answer to the kids that asks if the dinner will be served soon. Working on it.. is much better in a Swedish ear :)
That gave me a grin – I’m going to say “snart klart” when The Dude gets impatient with me about dinner from now on – and got me to thinking about what the message was in other languages. As with many idioms, the wording may be different and it may translate oddly as well. If you are using SharePoint with a language that I haven’t listed here yet, send me a screenshot of the message and a translation. I’ll post it here for everyone’s enjoyment and education.
Google translate: “Processing…”
Submitted by Elio Struyf (@eliostruyf)
Google translate: “We soon finished…”
Submitted by Patrick Guimonet (@patricg)
Google translate: “Is in working… This should not take long.”
Submitted by Stefan Bauer (@StfBauer)
Google translate: “Almost there…”
Google translate: “They are working on…”
Submitted by Gokan Ozcifci (@GokanOzcifci).
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.
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
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!
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.
|Adding Script into a Content Editor Web Part (CEWP) in SharePoint 2010
|Microsoft Excel Error: “There was a problem sending the command to the program.”
|Adding jQuery+SPServices to a SharePoint Page: Step One, Always
|Displaying Links Lists’ URLs in a Content Query Web Part (CQWP) in SharePoint 2010
|Populating a SharePoint List Form with the Current User Information
|Showing All Versions of “Append Changes to Existing Text” in a Data View Web Part (DVWP)
|Using a DataSource in a Data View Web Part (DVWP) in a Different Site in SharePoint Designer 2010
|The SharePoint 2010 “List View Lookup Threshold” and Why We Don’t Change It
|Active Directory Groups vs. SharePoint Groups for User Management: A Dilemma
|Working with SharePoint People Pickers with jQuery: A New Function Called findPeoplePicker
|Harvey Balls for Office Documents
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:
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.
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!
I noticed a nice little trick going by in my Twitter feeds today.
I’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";
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;
lcid = $(this).attr("value");
cultureInfo = $(this).text();
timeZone = $(this).text();
alert(lcid + "::" + cultureInfo + "::" + timeZone);