SharePoint Branding and the winds of change

Not that long ago, it was quite typical to create a major SharePoint UI solution for a SharePoint intranet. It would contain one or more Master Pages, CSS stylesheets, images, JavaScript, Page Layouts etc. The solution package was deployed to the server, the feature activated and automagically the intranet got its fancy custom UI and functionalities. A slight inconvenience though, that even the smallest change or improvement in any of the shipped files required updating the whole package.

It hasn’t been too long since I last was involved in such a big intranet solution. These days such projects are more of the exception than the rule. So, what’s changed?

One thing, or maybe I should say THE thing is Office 365. Cloud is becoming more and more popular and doesn’t even allow such huge full-trust solutions. Sandbox solutions are still an option, though according to Microsoft they are not the technology of the future – they already once declared them deprecated, but actually had to take it back pretty quickly. However, apps and other alternative ways of doing things (PowerShell, Azure powered functionalities etc.) are the modern and flexible way to build stuff on top of SharePoint, while keeping it separate from SharePoint.

I believe it’s not inaccurate to say that all the rest is just a byproduct of this. While more and more companies are switching to the cloud environments and Microsoft is developing “cloud first”, it is only natural for attitudes and ways to adapt to this change. Lightweight tweaking as opposed to heavy – especially with a heavy update process – custom software development sounds quite enticing.

Years ago, when SharePoint 2010 was launched and companies started to migrate from the old 2007 environment to the shiny new SharePoint in a fast pace, the game of the day was using OOB where ever possible and doing as little customization as possible. Mostly this still meant creating easily retractable solution packages for UI and custom web parts and services, distributed as features. SharePoint wasn’t re-coded anymore as it used to be in many cases with MOSS 2007; the solutions were built on top of SharePoint without touching the OOB stuff.

Then, along came SharePoint 2013. For quite some time the development and customization story was pretty same as with 2010, up until Online made its breakthrough and started to mold the models towards the more lightweight facelifts, apps, external services etc. The process of UI customization, branding, has shrunk from a heavy solution package to creating themes, some custom CSS and maybe a bit of JavaScript.

A color theme is a rather easy and quick way to apply the company branding colors to SharePoint. It already takes you a long way – the company colors are applied to the top suite nav, links, emphasis colors, headings etc. Creating a font scheme adds to this by implementing the company font – even a custom one – everywhere with one setting. What cannot be done by a theme is changing the placement and fancier styling of page elements.

The current default Master Pages seattle and oslo are built using div elements. This means that working with them – the placement, float, etc. – is pretty flexible and easy without needing to change the HTML of the Master Page, i.e. there is no need to create custom Master Pages simply to change how and where the elements are rendered on the page. There are limits to this, but you can do a lot with CSS.

Themes and an alternate CSS stylesheet are easy to implement in the UI of SharePoint, in the site settings, and they are inherited by any subsites with publishing feature activated. Implementing them to sites without publishing feature is a bit more work. Generally, this means pushing the inheritance from the top level each time a new site has been created.

JavaScript adds its own challenge to the equation. It is possible to globally inject JavaScript to all sites in a site collection using PowerShell. However, this should then be done for each new site too, when one is created. In single pages the Script Editor Web Part works nicely, but the global injection is always a bit of an issue. Mainly the options apart from the manual PowerShell injection are adding the script links to the Master Pages or creating an Azure powered service for provisioning the sites. 

The latter option is actually something to consider. Basically the idea is that people don’t create their sites manually but order them by creating a new item into an order list. A timer job polls the list and notices a new site order and launches a PowerShell script that then provisions the site with the exact settings, stylesheets, logos, Web Parts, lists, JavaScript links that are needed for each new site. 

Add responsive design to the equation. Currently SharePoint Online offers two view for mobile devices and the possibility to switch between them. One is the mobile list oriented view, the other one the full desktop view. The list oriented view works fine in team sites where all the content is mainly in lists, but publishing sites, the informative intranet pages, need to be viewed in full desktop experience on mobile devices too – in a responsive way so that it actually is readable.

Unfortunately, responsive SharePoint is still a bit of a everyone for their own – or has been, but I have just discovered that PnP has actually come forth with an awesome fully responsive solution that is purely CSS based! Previously the options have been e.g. bootstrap (heavy version), a responsive SharePoint solution from Codeplex (kinda heavy solution too); both of these require changes to the MasterPage. A bit of a no-no. 

Be as it may, responsive design is always more expensive for a customer than the basic design only. However, as the costs of branding have come down significantly with the lighter approach, it most definitely pays off to invest in responsive design, if not go mobile first. That’s where this world is headed anyway. 

[Originally published in Finnish in our company blog]

Tip: Fix List Issues After Migration 2010 -> 2013

Once again, faced with issue after issue. There was a SharePoint intranet that was migrated from SP2010 to SP2013. There was a list in the intranet, containing crucial information that should be easily searched. However, there was no list search available. Also, none of the columns were site columns. So I set out to create a search page for the list data. Everything runs cool if you just try to search with data in the title field (or author). However, there were some other fields including data to search wih.

Piece of cake, I thought to myself, disregarding the fact that most of the time the pieces of cake are tough to chew when it comes to SharePoint. I created some site columns and added them to the list, positioning them next to the original ones, with the intention to simply open the list in quick edit mode and copy values from list columns to site columns. Easy enough!

However, the list being a custom list originating in SP2010, the quick view was unavailable. I contemplated on exporting the data to Excel, modifying it there and creating a new list using that sheet. Before attempting that, I decided to google just a bit in hopes of finding a solution. And I did, hurray for Saludeen Rajack!

Since I had already tried most of the tricks in the blog post, in vain, I crossed my fingers and opened the list page for editing, opened list web properties and added clienttemplates.js to the JS Link property of the web part (at the very bottom of the Miscellaneous section).

And lo and behold! First of all, the list search box appeared at the top of the list and secondly, the quick edit button became active. 

Now I could proceed with my plans properly.

Javascript world clock with automatic time zones

One would imagine that getting a world clock - real time with automatic time zones including daylight savings - wouldn't be that difficult to include on your web site. On a standalone web site it probably isn't since there are several free or low cost solutions available. But in SharePoint it wasn't quite as straightforward.

One of my customers, a global company, already has one solution implemented on their intranet site, but there are two problems with it: it only refreshes the time on page refresh and the daylight savings (i.e. offset for each time zone) need to be adjusted manually every half a year. So I began to look into the options for modernizing this world clock of theirs.

First thing I realized was that most of the ready made solutions rely on PHP. This is already a no-no in SharePoint. Then I came accross this very cool site http://www.clocklink.com/ which has built in time zones and a multitude of analaog clocks (using html5 or flash). These could be used in SharePoint quite easily per se, and I even found a pretty neat solution using a SharePoint list to create a multitude of easily maintainable clocks. Check it out at Path to SharePoint. 

However, this requires cross-domain queries and moreover, when working in e.g. SharePoint Online, queries from https to http wich pretty much is a showstopper here. 

At this point I was starting to be pretty frustrated. Being so close and still so far away from a working solution. Then along came moment.js. A life saver, so to speak. Plus a very elegantly written tutorial for creating an analog clock using javascript and html5 canvas.

Combining all this plus a little bit of jquery I finally came up with a fully SharePoint (Online) compatible world clock solution (though I actually ripped the canvas part away, as I only needed a digital time display with some additional info). So, let's do a walk through for the benefit of the next one needing to do something similar:

1) Download moment.js (or min) and the suitable version of moment-timezone (from the Moment and Moment Timezone pages). Optionally also download jquery-file to avoid any cross-domain calls.

2) Upload the js-files into a suitable library in SharePoint, eg. Site Assets on the site.

3) Create a test file for compiling all the needed code to add to the script editor web part on your page and first off, add references to the js-files in the SharePoint library.

<script type="text/javascript" src="../SiteAssets/jquery-1.10.2.min.js"></script>

<script type="text/javascript" src="../SiteAssets/moment.min.js"></script>

<script type="text/javascript" src="../SiteAssets/moment-timezone-with-data.min.js"></script>

4) Add a bit of CSS:

<style type="text/css">

.current-time {

display: block;

font-weight: bold;

text-align: center;

width: 200px;

padding: 10px;

}

.clockcontainer {

  background-color: lightblue;

  border: 1px solid blue;

  border-radius: 5px;

  float: left;

  margin: 5px;

}

</style>

5) Add the javascript logic:

<script type="text/javascript">

document.addEventListener('DOMContentLoaded', startTimer);

function startTimer() {

    setInterval(displayTime, 1000);

    displayTime();

} 

function displayTime() {

jQuery(".clockcontainer").each(function(){

var timezone = jQuery(this).attr("title");

var zonetitle = jQuery(this.firstElementChild).attr("title");

var now = moment().tz(timezone).format("h:mm:ss A");

var day = moment().tz(timezone).format("dddd MMMM DD, YYYY");

jQuery(this.firstElementChild).html(zonetitle + "<br/>" + day + "<br/>" + now);

});

}

</script>

(Note the jQuery instead of $ - in SharePoint this generally works more reliably)

6) Copy and paste all of the above to a Script Editor web part on the page where you are adding the world clocks, preferably somewhere close to the bottom of the page.

7. Add a Content Editor web part on the page where you want to display the clocks.

8) Edit the source of the CEWP content and add the clock elements (as many as you wish, but note the highlighted parts):

<div class="clockcontainer" title="Europe/London">

<div class="current-time" title="London">

time</div>

</div>

9) Modify each element to put out the correct time zone (title of the clockcontainer element) and the label for the clock (title of the current-time element). Check proper time zone names at the momentjs site.

That should be it, folks. Now, your SharePoint page should display correct times for your chosen time zones, e.g.

Momentjs offers plenty of options for time and date formatting. 

Tip: Targeting a specific SharePoint site with global CSS

Just a little css tip, that came out handy today. Generally, with a global css (say, an alternate style sheet that is deployed throughout the site collection), you don't even attempt targeting some specific site, but go with the global styles instead. Today, however, I was struggling to display the titlerow (logo and navigation) in the enterprise search center without having it become visible in the dialogs as well.

Some Microsoft logic it is, I guess, that the search center by default hides the site collection navigation using the same class as the dialogs, the .ms-dialogHidden. And as anyone working with SharePoint CSS knows, the sites have no IDs in the body tag so that you could e.g. tell your css to display the navigation in search site but not in the dialogs. None, except for the action attribute in the form tag.

I guess it never was as big of an issue before, since I never thought of it before, but indeed, in a site collection already populated with sites, you can target one specific site by using the attribute selector for form tag in your css rule, for the form action contains the relative address of the site in it + in SharePoint, the whole page is always inside of that form tag. So here's the rule for un-hiding the titlerow for this specific search center, just as an example:

form[action*="searchcenter"] #s4-titlerow.ms-dialogHidden {

    display: block !important;

}

And, yey, the dialogs remain untouched and furthermore, there is no need to impelemnt page level css on each and every search center page.

Choosing between publishing and team sites for your SharePoint intranet

I have noticed, that the tech oriented SharePoint architects tend to prefer team sites over publishing sites for practically any purpose. I cannot remember the reason, and frankly, during my years of building SharePoint intranets I have not come accross any real reason for this - more like on the contrary. An intranet built with team sites causes more problems than not, in most cases. Let me explain.

Team sites have a much more dynamic usage philosophy behind them than publishing sites. Team sites are meant to be virtual team workspaces, where a bunch of people collaborate, manage documents, manage team tasks, chat etc. The content is highly dynamic, based on lists and document libraries rather than text and images on web pages. Thus, the need to edit pages is ususally quite small. The owner creates lists and libraries, sets up the workspace and the content starts to live.

As for the informative intranet? This is not how it works! The content is highly static - text and images on pages, maybe some centrally managed documents that are published on for the large reader audience of the pages - I say pages, for even if the intranet is built with a site hierarchy, like it most commonly is, what users see and use, are pages. 

True, that you can do the same with team sites too. Nobody says that team sites must be collaboration sites. However, using team sites to build traditional intranet sites creates a series of issues for the content managers and designers of the intranet. Issues, that the more technically oriented architects never see, since they rarely step into the boots of the end-user.

Quite many times, I as the UI "guy" and the content management "guy", am called into these situations where someone, some tech person, has built the intranet for a compnay, a Site Collection created as a team site, created a hierarchy of team sites. the customer has started to build their intranet with the blocks they have been given and they run into issues.

1) "I  made changes to this page, but they disappeared". Most of the time the publishing features have been turned on in the site collection of team sites that are meant to act as the intranet. This results in a very strange hybrid situation, where one can edit a page without checking it out, but someone can also check it out and result in loss of data. 

2) "I was trying to edit this web part, but I get this message about checking out." Even when the check out is required for the pages, the whole editing and check out is occasionally quite confusing for the content editor. In some situations, the page allows you to edit it to an extent, until it suddenly hits the editor with the "Hey, you need to check this page out first!". Again, data may get lost in the process. 

3) "Pages or Site pages and what is the welcome page of the site?" When publishing features are activated for the site collection and for the sites in it, each site has two libraries for the site pages. The Site Pages library (originial for the team site) and the Pages library (created by the publishing feature). Now, this creates another funky situation there. 

If indeed pages are created within sites, they may be in each different library, depending on how they were created. And they function a bit differently when editing, not to mention that the whole page architechture is different. More confusion for the content editor. The deafult page of the site can either be the Home.aspx from the Site Pages library or the default.aspx from the Pages library. You need to choose, and set the welcome page in the site settings.

4) "But... this page layout is not consistant and we want it to be something like this [drawing]." When using simply the welcome page of each site in the intranet site collection, the issue that the HR, PR, marketing etc. department raises when getting involved with the intranet is the layout of pages. 

True, not an issue for all companies, but a whole lot of them. There is a need to create a consistent layout for the pages and while text layout offers some options, it rarely truly fullfills the needs here. Publishing pages with the page layouts options are required. All of a sudden you find yourself creating new welcome pages as publishing pages and building them all over again with the content that already was on the home page, the wiki type page of the team site.

So in order to avoit these hybrid versions of sites and the confusion of the people who actually need to work with the pages and manage the content of the intranet, I highly recommend creating the informative intranet hosting site collection using the publishing site template. Seriously, that's why it is there! If you need blogs or wikis or even team sites within, it is all still possible. If you need calendars etc. that are not orginally part of the publishing site, the team collaboration lists feature can be activated. 

This said, if your intranet is not a traditional informative publishing intranet but a collaborative dynamic intranet instead, or if you prefer the wiki type content management, please do use the team sites to get the most out of that scenario! There is nothing to lose and a lot to gain  to actually use the most suitable SharePoint site template for each specific purpose instead of going with the idea that one glove fits all. It doesn't! All it needs is a little bit of planning and understanding the actual use case scenario of the site collection at hand.