Article
11 comments

Bind JSLink overrides to certain web parts only

JSLink can only be registered on certain list templates. This works well as long as only one web part on a page will be shown. If you added multiple list views of the same list template the template override will affect all web parts and not only the one that has the JSLink File attached to. To avoid this behavior the template override needs to be able somehow to conditional format the output.

[Read more]

Article
13 comments

Case study how to use same master page in Office 365 and on-premises

This is not a tutorial how to customize the master page in Office 365. Microsoft doesn’t recommend to create your own master page because they will constantly evolve the user interface and this might break your branding.

The reason I created this case study is to show that it is yet possible to use the same master page in Office 365 and on-premises. This master page also takes into account that the Ribbon and Suite Bar are completely different in both environments.

Another important thing is to show how the master page might evolve in future so that it provides two things. Enables Microsoft to implement and add new features and allows custom branding as we currently do it on-premises.

[Read more]

Article

How to use: Table of Content – jQuery Plugin

After I’ve published the revised version of my table of contents script I got many request on “How to use” it. You asked for it and here it is the guide how to embed the script. I won’t provide a full featured step by step guide here. Instead, I will provide a small package of a page layout and a guide how to script embed directly. To make this work you need to have an Enterprise Wiki or Publishing page. The first part covers how to add a page layout containing the table of contents script. The second method shows how to add the script using code embedding. You also need to download the following file TableOfContents-PageLayoutPack that contains all the required files.

[Read more]

Article
0 comment

The future of SharePoint Branding

You cannot take a look in the future if you don’t know about your past. I started branding SharePoint in 2004. At that time I already had some years experience on developing web sites and application. Now we have 2014 and the SharePoint branding haven’t changed a lot. We still try to figure out how Microsoft built up the master pages and how we can bring them into a new form.

In SharePoint 2013 a great step forward has been made by Microsoft to improve the underlying style sheets and HTML. Tools like Twitter’s Bootstrap or Foundations and a couple of other frameworks have approach to bring responsive web design to SharePoint. Needless to say with all the benefits and downsides.

Global Experience Language by BBC

Global Experience Language by BBC

In the future we will see more and more applications (okay, okay apps) that will be integrated into our SharePoint.

Sooner or later our SharePoint will look like a patchwork of different designs. Will the future be of not branding SharePoint and use it as it is? I don’t think so we just need to find a smart way to adapt SharePoint to our visual needs and sometimes improved user experience for custom development inside the boundaries of the platform. Last but not least, how can we implement methods that helps us to adapt faster to future releases without recreating the branding from scratch as we did in the last versions.

CSS, FrameWorks, Themes

Currently, some branding like to do it the old fashioned way, just using the HTML and CSS to build up the user experience. Others prefer to use a framework and some might like to use the theming engine of SharePoint to change the look and feel.

There is no right or wrong with all these approaches. Over the last months I always asked myself the same question over and over again.

What can we do to create a smarter, better documented and future prover system than we do it today. Especially with Office 365, apps, display templates and much more everything become fluid. What worked today can be could be changed tomorrow.

For me the challenges of the future are focusing on content that lives throughout the different devices (Content Strategy). The usability that users expect on different devices. Last but not least we will see more and more different interfaces, there that access our content. May it be directly inside of an Office Application, a refrigerator, in our car or use a Xbox to manage a project.

We need to step one step back to see the bigger picture.

Design with a system

Wouldn’t it be great to have one central design system that handles all the different display forms without rewriting the code from scratch. Provide the same look and feel even user experience in SharePoint to Apps and even Office Apps. I think the key to success can be found in two concepts that are state of the art in web design today.

Design Systems

A lot of great information on design systems can be found on the web. The Laura Kalbag such system as:

“A visual design system is built out of the core components of typography, layout, shape or form, and colour.”

Another great explanation can be found in the article “Design Systems: Building for the Future”. Especially because he explains why design systems are more future proven than to use a framework in the context of a CMS.

The most inspiring article on this topic I found in a blog post called “Atomic Design” by Brad Frost. In his article he explained how to form a well structured and categorised design system for the future. He further explain how we can set up the core components (Atoms) that will be used to formulate larger components (from Molecules to Organism) that up into templates and pages. A functional demo of be found at patternlab.io

To me setting up such system has the following three benefits:

  • Better documentation of what we didIf no design system has been set in place prior the concrete implementation it will be hard to find the components that have been implemented. The consequence of this is that we might end up with code that does similar stuff, but with different classes attached.
  • MaintainabilityMost of the core components in HTML haven’t changed over decades, we just got some new. We can combine those in many different ways. The better we structure those the more maintainable the final branding will and easier to change in the future.
  • TestablityIf we know how our components look and behave in different view ports, we better understand how they function and work in the overall design. Testing smaller components is much easier to accomplish.

DRY – Don’t repeat yourself

SASS and LESS are great CSS preprocessors that allow us to write much cleaner code. Hence we can build our rich text editor styles by changing and assigning some variables instead of writing those style definitions from scratch. I know this is just a simple example, but the benefit of these technologies is that is also removes some complexity and gives us tools that are much easier to use.

Another benefit is that especially SASS allows to compile different CSS files based on the same code. For example, you create one in the context of SharePoint and one for a SharePoint Apps.

If you cannot wait for my next blog post. I can only recommend to read the blog post about DRY-ing Out Your Sass Mixins.

Finally and whats next

Those theories sound nice I know but how can we get started. I tried some things out over the last weeks and I will publish my findings over the next weeks. So stay tuned.

If I’m not completely wrong some people struggle with the implement a corporate wide branding. Though the changes in the app model we are not in the “SharePoint Exclusive Club” anymore. Sooner or later we need to move forward and take a closer look what other web developer do and what they are struggling with.

As Jeremy Thake said at the SharePoint Conference in Barcelona there are many of web developer out there that will be sooner or later able to build up Office Apps and SharePoint Apps.

If you like to follow my journey I would be pleased. Have comments on this, please feel free to comment. I hope at least for some it will be an interesting journey to the future of SharePoint Branding.

Other articles in this series

Typography First – Make your SharePoint content readable and compelling

Article
6 comments

Safer request form fields in list forms using JQuery

Mark Anderson published today an article on his blog concerning an issue that currently exists in Office 365 and is called “Office 365 Update Changes ‘Display Name’ on Required Fields”. In this article he described that the rendering of fields recently have been changed in Office 365. I will take a look what can be done to solve this probably.

The cause of the problem

The title attribute of list fields have been widely use to customise forms in SharePoint using JavaScript, JQuery or SPServices. I used this attribute sometimes too do address fields by the display name. But somehow I always had a bad feeling about this. Why? Well, the ID attribute of the field is the only real unique identifier in the form. The downside using the ID is that you need to have some information about the field to generate the ID. But I will explain this later.
What the update recently in Office 365 did was to change the rendering of the field. Previously it look like this:

<select id="Region_59566f6f-1c3b-4efb-9b7b-6dbc35fe3b0a_$LookupField" title="Region">

Now it has changed to this:

<select id="Region_59566f6f-1c3b-4efb-9b7b-6dbc35fe3b0a_$LookupField" title="Region Required Field">

As you see now the title has additional parts such as required or field. This means that you haven’t in this attribute the display name of the field alone and you will fail if you query by title.

Safer approach to request fields

As mentioned before the ID property is the only one that is unique in the whole page. The ID is formatted in the following form:
Field name + ”_” + Guid of the field + ”_$” + Type of the field.
As seen in the previous section the ID looks like this:
Region_59566f6f-1c3b-4efb-9b7b-6dbc35fe3b0a_$LookupField
So if you like to be absolutely sure and like to generate this ID by yourself you need to do a request to the list and read the fields. The you will be able to find the name by the display name, the id and the type. This will make some lines of code that you can reuse in your projects. I haven’t seen any ready made code yet but I’m sure it can be found somewhere over the internet. (If you have would be great to post that in the comments)
I looked into this problem and what I found was that SharePoint does that job for you and stores it on the form in the JavaScript variable “WPQ2FormCtx”.

Console output of WPQ2FormCtx Object

Console output of WPQ2FormCtx Object

This context is somehow new in SharePoint 2013 and Office 365 This somehow represents the so called form context with a lot of information. Also included in this variable is the list schema which we can use without loading any additional information from the list.
So what I did is that I created a small javascript object that loads the information and allow me to generate the id of the field. The tricky part i currently not have implemented is the type part because this is a little bit tricky and the value changes with the different configurations of the fields. I hope that the following code give you an example how this works.

<script>
/* Handles the field of the form */
var fieldDefinitions = {
  Fieldname: [], // Stores all the display names of the field
  Fields: [], // Stores the complete field configuration
  // This function formats the list schema for easier acces
  ParseSchema: function(formContext){
  		var schema = formContext.ListSchema;
    	for(var field in schema)
    	{
			this.Fieldname.push(schema[field].Title);
    		this.Fields.push(schema[field]);
    	}
  },
  // Genereate the Fieldname and Field Guid Part
  GetIdByTitle: function(title){
	var index = this.Fieldname.indexOf(title);
	var currentProp = this.Fields[index];
	console.log(currentProp);
	// return the beginnng of the ID in the format 
	// FieldName (encoded) + "_" + Guid of Field
	return currentProp.Name + "_" + currentProp.Id; 
  }
};

$(document).ready(
    function () {
		// Reformats the form context   	
		fieldDefinitions.ParseSchema(WPQ2FormCtx);
		// returns the calulated ID of the field
		var fieldID = fieldDefinitions.GetIdByTitle("Region Field");
		// Wildcard request to the field 
		// sets the value of the Region Field
		$("input[id^="+fieldID+"]").val("Works");
    }
)
</script>

To this script the last part needs to be added to be 100% sure. Think about the fill in option for example this will start with the same id but I’m sure there will be added a special type.

Field after update via JS

Field after update via JS

As you see the value was written to the form

A Look to the future

I will never use the title field again. I write this now 100 times to keep it in mind. But not here in this blog post. In future I will reuse my little helper object for a simple reason. If Microsoft changes the format of the ID attribute I only need to change it at a central location instead of search and replace all my jQuery / JavaScript code.
Convenience is not everything better go an extra mile to be safe.