To hide the tool part of a web part is pretty easy. You just need to edit the settings and set them to “No Toolbar” and you are done.
Today I needed to do this programmatically. After I debugged the list view web part an haven’t found a setting for this I took a look into the “clienttemplates.js”, which is mostly responsible to render the views correctly and voila I found a solution how to hide the toolbar.
Toolbar vs. Hero Buttons
SharePoint 2013 still supports the classical list view toolbars but whenever you see the “New Document or Edit” then you will see the hero button. So why is this important? If you like to change the behaviour of a list view the hero button needs to be enabled.
Just as most of the new things this cannot be done with server side code. This needs to be done during the client rendering and after a while try to manipulate the toolbars I gave up and focused on the file called “clienttemplates.js”. This is the main file that handles how the views will be rendered.
Override for enabling / disabling the hero buttons
The JSLink that allows to manipulate the display of the hero button is pretty simple. All that needs to be done is to manipulate the render context object. The following script contains all that is needed.
The result of this should look like this.
The strange thing about the hero button is that this cannot be set via the web part settings, while the view setting and the search box can be configured directly. Another thing that is strange that those configuration option not show up when the view previously was set to “Server Render”.
Recently I have tried to use more and more SVG in web projects, because they are more flexible to use in responsive web projects. The most common file formats that are used in SharePoint as a site logo are GIF, JPEG or PNG. I wondered if Sharepoint SVG supports as a site logo, I tried it out and it worked charmingly.
By using SVG you get a great new opportunity to use in SharePoint projects without modifying the master page.
What is SVG?
SVG is a graphic markup for the web defined by the w3C. SVG allows to create complex graphics by just by using code. The browser interprets the code and renders beautiful graphics and illustrations.
The fact that it is not a binary file format like JPEG, GIF or PNG makes it more efficient and easy to use in responsive design projects. It works independent of screen size and pixel density.
The web nowadays is full of SVG used for icons, fonts and all kinds of illustrations. SVG can be styled with CSS and animated trough CSS3 animations. For more information on animated SVG take a look at some amazing in depth information on A Guide to SVG Animations (SMIL)
Add SVG as a site logo
Enough about this file format, let’s get the hands dirty with SVG in SharePoint. I choose a hipster logo to be used.
This SVG Logo can be simply uploaded to SharePoint via the standard SharePoint dialog.
Once this has been done Sharepoint scale the logo correctly and display this SVG as a site logo. What I’ve out is that the dialog the logo doesn’t scale the SVG always right, but as wrong as the logo might look in the site logo dialog it looks correct at the right place.
As mentioned before, every responsive web design should make more use of SVG because it saves a lot of headache. Scalable vector graphics always look good and sharp independent of the device and resolution you are looking at the logo.
The last thing to mention. Don’t try this with IE8 because it only supports IE 9 and higher. To see the full browser coverage take a look at can I use / svg .
Be careful when you change the title or the description in SharePoint you might set a logo url. Even if you don’t need to set one. Recently I found a strange behaviour in SharePoint during a branding project. The project included three site collections where each of those should have a different logo.
Somehow the logo couldn’t be changed in the complete site collection. A changed logo in the root of the site collection was not reflected on the sub site. Strange behaviour thou, because SharePoint has something that I call logo inheritance.
Break logo inheritance
So by default the sub sites inherit the logo from the root web of a site collection.
Any change on this dialog will apply the logo to the sub web instead of taking it from the site collection. If accidentally this dialog was opened just-to-look. The OK-Button will store the image url in the sub web.
Avoid custom web logos on sub sites
Whenever a change of title or description is needed. Make sure that the address field was cleaned and empty.
Don’t worry if you do this. The logo will be replaced in the dialog to the default on. After the properties was committed to the server. The correct logo, the one of the site collection, shows up again.
For branding solutions
The same thing applies if you develop a branding solution or feature stapling. Never set the logo url on a sub site in case you like to change it afterwards. If you take a team site for example. This kind of web template doesn’t inherit anything. You can inherit the branding of the root web site with the following lines of code.
The last part of empties the logo url. This makes sure that the logo was taken from the parent website.
Fix Messed up site logos
If you are not sure and like to change the logo of an existing site collection you can use the following PowerShell script.
This script can also be applied when the logos of the sub site should be simply reset.
Imagine you have a team site that provides curated information. Only a few people are allowed to update the content. The rest of the people only have view permission. To spread the word you like to make use of the Newsfeed web part for two reasons. People who follow this page will get updates on their Newsfeed. The other reason is that the viewers should be able to give feedback to your updates. Seem to be a pretty good solution and this is what the Newsfeed web part is actually being made more.
The problem is that this web part is by design only for users that have at least contribute permission. With some simple steps this behaviour can be changed and allow everyone reply to the Newsfeed.
First, let’s take a look where the data of the Newsfeed will be stored.
The Newsfeed web part and the stored data
Whenever a new entry or a reply to the Newsfeed will be adding the content is stored in a list named “Microfeed”. I’m not sure why this list is visible to anyone. The data stored there are not readable for an end user.
As expected the Microfeed list inherits the permissions from the website. This means that this is the reason why user that have less permission than contribute are not allowed to add comments to the Newsfeed.
Create permission level for viewers
To allow a normal viewer to add comments and new entries I would recommend to create a separate permission level for the visitors. This gives you better control over the permission and you will be able to disallow the normal visitor to delete posts or replies for example. To add a permission level go to the root of the site collection and navigate to the site permissions.
In the ribbon you will find on the left end the configuration for permission levels. Now I would recommend you to use the “contribute” permission level as a starting point for further customisation.
To copy the “contribute” permission level you need to navigate to the bottom of the page. There you will find the “copy permission level” button.
Define a name and you are ready to customise the permission. In my case I named the new permission level “Newsfeed Participation”. The least customisation I would suggest to do is to uncheck the “Delete item” permission. Otherwise, every visitor that is able to browse to the list “MicroFeed” will be able to delete existing entries in the list.
Save the permission level you are ready to allow visitors to add entries to the Newsfeed.
Assign permission levels to visitors in MicroFeed list
To make use of the newly created permission level navigation to the MicroFeed list permissions. Stop the inheritance of permissions, edit the Visitors group and assign the “Newsfeed participation”permission level.
Now the next time a visitor tries to like a reply a Newsfeed item the user has the appropriate permission.
The design of the Newsfeed is to increase the team internal communication, but is not considered to used in intranet scenarios. Especially when you a large amount of the content is read-only.
With this little permission tweak the Newsfeed can use even on read-only areas of a portal or intranet. If you like to use the Newsfeed web part on sub websites too. This permission change needs to re-applied again.
It’s more then two years ago when I first wrote a table of contents script to enhance wiki pages in SharePoint. Time to release a new version and this time it’s a jQuery plugin. This new version will work potentially work with all versions of SharePoint and Office 365. I just have tested it in SharePoint 2013 and Office 365.
Now I also included support to for all levels of headlines (<h1> – <h6>).
This is possible because a found a good old part in the jQuery Documentation
This selector is not supported by css but jQuery adds support of this pseudo selector. It is a really handy extension because you can select all headlines on a page or just the headlines in parts of your page, for example an article. The support of this pseudo selector was added in jQuery 1.2 almost seven years ago.
// Selects all headlines
// Selects only headlines only inside #myElement
The first code snippet selects all headlines on a page. The second only for example in an article.
Table of Content – jQuery plugin
To make all the code reusable for SharePoint I decided to write a jQuery plugin calls “sp.tableOfContents.js”. This plugin has several option that helps you to configure the table of contents easily.
headlineText:"Table of Content",
orderedList: Defines if the output should contain <ul> (false) or <ol> (true) customStyle: adds a custom style sheet class to the table of contents menu attachTo: defines the element where your table of content should be added to use ID or class selector prepend: defines if you like the table of content to be prepended (true) or appended (false) to the previous defined element headlineText: gives your table of contents nice looking label
To use this script make sure that jQuery and my table of content jQuery plugin is registered in your SharePoint Pages, on an article page or page layout.
The code to make it work looks like this:
// Change this options to your need
// Initialize table of contents for the rich text editor
I haven’t added all the options in the sample script above but feel free to play around with it. Additional improvements to this scripts are also welcome.
Display templates can only be stored in several places of SharePoint to get loaded. I was wondering if I will be able to inject this mechanism or if I will be able to provide a display template directly out of a provider hosted app.
Normally Display Templates will be uploaded to every site collection inside the master page catalog, but with a little tweak those can be loaded from everywhere in the world as long they are accessible via a web server.
The local display template
Display templates will be executed not on the server, but on the client. Embedding remote scripts is something we do all the day. If we use jQuery or SPServices, for example.
To load a display template we just need to use the function:
At the end of this snippet all I defined the locations where the remote display template is located. In my case it is on my local web server. The only thing we do now is to upload this script to the display templates instead of the code for the display template.
This script we reference in the JSLink property of a list view web part, for example.
In my case the path is “~sitecollection/_catalogs/masterpage/display template/loadExternal.js” .
The remote display template
Next up we need to add the code for the “real” display template. The following snipped just register a custom action on a document library.
Now let’s see if the custom display template is loaded.
There you go the custom action is loaded from the remote web site to the SharePoint site and it is registered correctly.
I think this remote loading of display templates is pretty useful during development or if you like to create a display template repository within your organisation. Those remote display templates are simply easier to maintain.
For me it speeded up the development process, but keep an eye on possible security issues. As cool as it is. Scripts can be easily hacked and replaced by malicious code if you embed it directly from the internet.
The first thing when I start a new branding project I first make myself familiar with the fonts I want to use. This is because I want to see how they work on some basic text elements an if the text is readable.
In general the overall typography is the most important factor to success of any information system or web site. 90% to 95 % on a website is dominated by text. Becoming a master on typography means you become a better web designer or SharePoint brander, but it is no easy topic and I just want to scratch the surface here but provide some good links for further information at the end.
The typography setup can be mainly defined by the following factors:
In other words, these are our core ingredients how we can manipulate the text. For example, some fonts look great with the predefined letter spacings while others require a little bit more space in between the characters. You can also use the letter spacing to make a special effect on headlines. For some examples that a look at Helvetica, Bold, Big, Negative Letter-Spacing.
How many fonts should I use?
In general when, you plan a design it is common practice that you don’t use more than three to four different fonts. Those different fonts can be defined for:
Quotes (<cite><cite>, <block quote> is decrepted with HTML 5)
When we take a look at the out of the box design of SharePoint 2013 at least 3 different fonts was used. Those fonts are Segoe UI (for smaller text), Segoe UI Light (for large text such as headlines) and Segoe UI Semilight (<h2>-<h3>).
The fonts are part of the same font family, but have a different font weight, which is indicated by “Light” and “Semilight” and those fonts are slightly different. The typeface was adapted to the weight and are not only bold and “not so bold”. The reason why Microsoft used those different font faces was that they look great in there specific use case. Improved the readability and the overall design.
When a theme is used in SharePoint the fonts can be changed to only a maximum of two fonts. Mostly Segoe is used for the regular text as used in a paragraph, navigation, and so on because of its good readability. The larger font in the font picker will be applied to the headlines only.
Reset and Reapply fonts using CSS
When a web design is created from scratch it is fairly simple to reset the fonts. All that needs to be done is to apply a base font to the body tag and additional fonts for the headlines.
So we now have two different styles that need to be applied differently to the Apps (first snippet) and SharePoint (second snippet). Both are probably stored in different style sheet files and we still don’t have any additional properties such as line height, font size or font weight applied to the fonts.
Finally and whats next
The two different style definitions cry for something more flexible and yes we can do this in SASS. By assigning variables we will be able to define the typography as global settings that are easy to change. Then we don’t have to care or worry about those style sheet classes.
In the meantime, you can do a test run and add the SharePoint Style Sheet from this blog post to your master page. If you want to get a little bit deeper into typography you can read the following resources.
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.
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.
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.
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.
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
What the update recently in Office 365 did was to change the rendering of the field. Previously it look like this:
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)
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.
/* Handles the field of the form */
Fieldname:,// Stores all the display names of the field
Fields:,// Stores the complete field configuration
// This function formats the list schema for easier acces
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.
As you see the value was written to the form
A Look to the future
Convenience is not everything better go an extra mile to be safe.
Art, Design, Media, Web & SharePoint … by Stefan Bauer