Article
2 comments

Apply grid system to SharePoint using SUSY

As promised in my blog post “What is inside your SharePoint CSS” I like to show how it is possible to add a grid system to SharePoint without using Bootstrap or edit the master page.

Grid systems for web sites were popular long before Ethan Mascotte wrote his famous article about “Responsive Web Design” back in 2010. The first grid system I ever used was the 960.gs. It was released in 2008.

[Read more]

Article
2 comments

Enhance suite bar for your responsive experience

Over the last year I did more branding projects on Office 365 than on on-premise. Since the first call by Microsoft to avoid modifications of the master page I played around with certain scenarios and patterns to reduce or avoid such modifications.
One common issue is that the suite bar is responsive (everything that resize is responsive) but not well optimized for mobile. Without any enhancements this part of SharePoint shows only half of the content. With some small CSS only modifications the suite bar looks great on nearly any device.
The following blog post use SASS pre-processed CSS the compiled CSS can be found too at the end of this post.

[Read more]

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
0 comment

Responsive vs. Adaptive Web Design – What about Device Channels?

Three years after responsive web design was introduced by the “A list apart” – article – “Responsive Web Design” by Ethan Macotte. The reason why people love this is because it can be easily implemented. You just need to have a browser that supports CSS3 and HTML and you are ready to go. Is it really like this?

Currently web design is in a state that we code against the gray. We don’t know the devices that might access our web site.  A resolution of a screen doesn’t give any information about the device.

This is the main problem from my point of view. We care too much about device resolution but neither the user nor the context the device is being used. Using a tablet – the user might want to have the same user experience as reading a book or magazine. Using a phone – the user might in a hurry and just want to get a brief introduction to read on a tablet or desktop later on.

In the following presentation I try to sum up Responsive and Adaptive Web Design and what SharePoint 2013 has to offer to connect the users, their context and the content.

The truth is that the consumer of your content doesn’t care if something is done on the server or on their client as long as they feel comfortable with the content and their context.

I held this presentation during ShareCamp Vienna (7.9.2013). Special thanks to organize this event: Thorsten Hans, Christian Glessner, Martina Grom, Toni Pohl, Hans Bender and everyone else who was involved in the organization of this event.

Finally I want to thank Brad Frost for the ongoing inspiration and lending me some slides.

Additional feedback on this presentation can be found on SPYam.
Feedback is always welcome.

Article
21 comments

Encode and decode field names from display name to internal name

In this article you will learn how fields in SharePoint can be encoded from a display name to an internal field name. The problem with the difference between internal field names and display name is that, SharePoint won’t have any built in function that is available to use in your code. If field names are only defined in English you might not have such problem. My mother tongue is German and we have some special characters that needs to be special treated and encoded.

The basic

Lets’s create a field called “Project Number”. The internal name for this field then will be “Project_x0020_Number”. The “_x0020_” in the field name is the urlencoded representation of the space in between of both words. To be more precise it is a form of unicode url encoding. The Unicode encoding of the space is “%u0020” but for fields “_x0020_” is required. To transform the encoded field name to a proper SharePoint internal field name we need to transform the encoded space somehow.

Another point that need to be considered is that SharePoint 2010 has a maxium length for internal field names is limited by 32 characters. By encoding the string we will get a much more longer string than the display name is. SharePoint handles this by truncating the field name and if multiple field names will be produced an additional index will be added as character number 33.

The good news is that this has been improved in SharePoint 2013. Now you can use display names with a length up to 255 characters. The limitation of the internal field names doesn’t exists anymoure. It seems that the limitation of the internal name is now raised to 1024 characters. In some test cases I got fields with an internal name length of more than 600 characters.

From display name to internal field name in C#

As mentioned before somehow SharePoint doesn’t have an out of the box function to convert a field name from the display field name to an internal field name. At least as far as I know.

There is one method that works for field names in English, but it doesn’t work for non ASCII characters and punctuation marks. The method which was recommended by Hugh Wood (@HughAJWood) is to use XmlConvert.EncodeName for encoding and XmlConvert.DecodeName for decoding the field names. What I have experienced with this is that it cannot considered to be a save approach to encode the display name strings. To give you an example “Österreich”, the german name of the country where I live in, will be encoded to “Österreich” but a field with this label in SharePoint will be encoded as “_x00d6_sterreich”. This is because the letter “Ö” is valid UTF-8 character to be used in a XML but somehow it’s not save enough for SharePoint.

My approach is a little bit different, might not the fastest, but save in a manner of SharePoint. So what I do to create a valid encoding, is to encode every single character of the display name using the method HttpUtility.UrlEncodeUnicode.

private string EncodeToInternalField(string toEncode)
{

    if (toEncode != null)
    {
        StringBuilder encodedString = new StringBuilder();

        foreach (char chr in toEncode.ToCharArray())
        {
            string encodedChar = HttpUtility.UrlEncodeUnicode(chr.ToString());

            if (encodedChar.StartsWith("%"))
            {
                encodedChar = encodedChar.Replace("u", "x");
                encodedChar = encodedChar.Substring(1, encodedChar.Length - 1);
                encodedChar = String.Format("_{0}_", encodedChar);
                encodedString.Append(encodedChar);
            }
            else if (encodedChar == "+" || encodedChar == " ")
            {
                encodedString.Append("_x0020_");
            }
            else if (encodedChar == ".")
            {
                encodedString.Append("_x002e_");
            }
            else
            {
                encodedString.Append(chr);
            }

        }
        return encodedString.ToString();
    }
    return null;
}

I tested this helper with the Japanese word for Austria, which is written like “オーストリア”. In this case the XmlConvert. EncodeName method will fail too, but mine do the encoding right. I mean I cannot read this Japanese word but I think you will get the point here. The only thing the helper not support is the truncation of the field names but I think this won’t be that hard to do.

Decoding the field name is pretty much straight forward all that needs to be done is to replace all “_x” with “%u”, remove all remaining underscores and use HttpUtility.UrlDecode and here is the code.

private string DecodeInternalField(string toDecode)
{
    if (toDecode != null)
    {
        string decodedString = toDecode.Replace("_x", "%u").Replace("_", "");
        return HttpUtility.UrlDecode(decodedString);
    }
    else
    {
        return null;
    }
}

From display name to internal field name using Javascript

If you use SPServices or the Javascript Client Object model, then you might need the same functionality that I previously presented in C# in Javascript. The encoding and decoding can be used in CAML Queries for example. This javascript encoder and decoder follow the sam pattern at the c# methods. I do the same, encode every single character by using the “escape” function for encoding and “unescape” for decoding. The finished code looks like this.

// Encode Fields
var SPEncode = function(toEncode){

    var charToEncode = toEncode.split('');
    var encodedString = "";

    for(i = 0; i < charToEncode.length; i++)
    {
        encodedChar = escape(charToEncode[i]).toLowerCase();

        if(encodedChar.length == 3)
        {
            encodedString += encodedChar.replace("%", "_x00") + "_";
        } 
        else if(encodedChar.length == 5)
        {
            encodedString += encodedChar.replace("%u", "_x") + "_";
        } 
        else 
        {
            encodedString += encodedChar;
        }
    }

    return encodedString;

}

// Decode Fields
var SPDecode = function(toDecode){

    var decodedString = toDecode.replace("_x", "%u").replace("_", "");
    document.write(decodedString);

    return unescape(decodedString);

}

To use this you just need to call the functions. In the code you also should consider the length of the the field names of SharePoint.

Conclusion

In SharePoint you cannot prevent that end user will create field names with special characters. I also think that it is not useful to deploy any column by using code or the declarative approach. One big advantage of SharePoint is that the end user is able to customize the platform to their needs, without asking a developer.

Both approaches, JavaScript and C#, show how to handle the SharePoint encoded field names, no matter if you use SharePoint 2007, SharePoint 2010 or SharePoint 2013. I also think that the JavaScript solution will become more and more important in future implementations. One reason is the new JavaScript API available in SharePoint 2013 or one of my all time favorite SPServices, if you like to access SharePoint via JavaScript and Web Services.

At the end I like to thank Marc D. Anderson (@sympmarc), James Love (@jimmywim) and Hugh Wood (@HughAJWood) for a great discussion on twitter prior this blog post.

If you have any enhancements to the provided code or like to give me a general feedback, please feel free to add a comment.

Article
0 comment

Embed everything in SharePoint 2013 Rich Text Editor

One of the new features in the SharePoint rich text editor is that now it is possible to embed external sources like Bing Maps, Vimeo videos, YouTube videos and other resources directly to the HTML content on an article page. In SharePoint 2010 html form web part or other special web parts needs to be used.

How it works

In the ribbon two buttons can be found to access the embedding feature. One can be found in the “Add audio and video” section the other is labeled with “Embed code”, both in the “Insert” group of the ribbon.

Embedding buttons in the ribbon

Embedding buttons in the ribbon

No matter which button will be used for embedding a YouTube, a modal dialog opens where the code for the embedding can be posted. Once the code has been added SharePoint provides a preview of the content that should be embedded.

Embedding dialog with preview

Embedding dialog with preview

After the submission the source will be added to the rich text editor as a so called “Snippet” that allows the position of the media or change the source of the embedded media.

Embedded sippet

Embedded sippet

As you see it’s now really easy to add external source to the content, but can be really embedded everything?

Embed everything or embed only allowed sources

Basically this new feature allows every iframe to be embedded, but allowing any iframe can lead to potentially scripting security problems. The good news here is that the allowed sources can be configured by a site collection administrator. The setting for this can be found in the site settings under site collection administration and is labeled as “HTML Field Security”. This offers the following configuration options:

  • Do not permit to add iframe from external external domain
  • Permit to add iframe from any external domain
  • Permit to add iframes from only the domains below
html field security settings

html field security settings

I think the last option is the most appropriate because it allows to manage what can be embedded. If something is missing from the list can be extended to support only trustful web sources.

Overall I think this is a great new feature for web content management and collaboration portals.