Today I decided to publish my table of contents script on github. There it will be much easier to handle all the issues and gives the global SharePoint community the possibilities to contribute to my code.
I know from many people that this script is wide spreader throughout various SharePoint installation. I’m looking forward to improve the code in near future. This table of content script has a real long history for me and I published the first version already for SharePoint 2010. It is still one of my most popular posts.
Let me share some statistics with you:
SharePoint 2010 – [Enhance Wiki Page Layout by adding a navigational Table of Contents](https://n8d.at/enhance-wiki-page-layout-by-adding-a-navgational-table-of-contents/) Page Views: 32,016
Office 365 / SharePoint 2013 – [Revised: Table of Contents for SharePoint Wiki Pages
](https://n8d.at/revised-table-of-contents-for-wiki-pages/) Page Views: 8,002
Office 365 / SharePoint 2013 -[How to use: Table of Content – jQuery Plugin](https://n8d.at/how-to-use-table-of-content-jquery-plugin/) Page Views: 2,289
From now on if you have issues or feature request simply publish them on github. If you like to contribute to this project you are also gladly welcome.
Many people recently discovered a new enhancement in Office 365 and especially SharePoint. The suite bar is now responsive if “First Release” option on your tenant is activated.
Responsive Office 365 suite bar rendered on mobile device
The first people that blogged about this responsive improvement were Wesley Hackett and Marc D. Anderson.
The current implementation works well on desktop but not on mobile devices.
Why it doesn’t make your Office 365 / SharePoint responsive?
Actually the current suite bar lacks of one important thing. The viewport meta tag is currently not implemented in SharePoint or Delve. This tag is responsible to render the page correctly. The display of modern devices has a higher pixel density than the normal desktop computer. The viewport meta tag helps the browser to scale web sites properly. Is this html tag missing in the header of the html document the website will be rendered as a desktop version, but everything is tiny and unreadable unless you pinch and zoom.
If you have a new Lumia 950 for example the pixel density is 314 pixels per inch. Desktop monitor in reality has pixel densities beyond 72 pixels per inch but thus the actual base size your browser renders the web site. All CSS values are calculated based on this.
On mobile devices without a proper viewport meta tag the web site will look like the desktop version, but really tiny and therefore unusable.
This brings us back to the new shiny responsive suite bar. A good example when a web site wasn’t tested on a real device. Works perfectly on a desktop browser but not on mobile. Someone might have forgotten to include the view port on the master page. On my phone, SharePoint will be rendered like this.
Suite bar rendered on mobile device
As mentioned earlier, it is currently only available for first release subscriptions. So currently nothing to worry about. I hope this will be fixed in the final release and we currently see an early beta version of the suite bar.
Where can the problem be spotted. Simply everywhere in Office 365. Here is a detailed list:
Missing viewport meta tag
With viewport but not responsive design
Outlook and Calendar use device detection. Some sort of Device channel to work responsive.
The only first an real native responsive apps are currently Sway and blog post on Delve. Both are equipped with a correct viewport.
The new suite bar gives a nice outlook on coming up design features. I expect to see more improvement in the near future. Currently, SharePoint in Office 365 and SharePoint 2016 is built upon XHTML 1.0 and not HTML 5. Once the doctype have been converted an all functions work on HTML5 I guess we will see more adoptions to come out faster and more reliable.
From my perspective the new suite bar is a fast shot. I also have concerns about the usability. On mobile the waffle aka app launcher is hidden behind the three dots in the suite bar. To switch between SharePoint and Mail or Calendar users have to tap twice. This forces to learn user a new behavior because the app launcher was one of the essential improvements recently.
On the tablet devices the app launcher is jumping from left to right. This is actually a no-go. User will get confused. A small resize of the window is enough to show this effect. You don’t even have to be on a tablet device.
If you think about to change the master page of SharePoint to make this work. In Office 365 editing the master page is not recommended to do so. I guess this issue will be fixed by Microsoft sooner or later.
If you have other concerns, feel free to comment on this blog post.
Microsoft has recently “removed” or at least don’t maintain the Office 365 icon font on their CDN. The location of the icon font has recently fundamentally changed.
A possible reasons
The font is still available on CDN but shouldn’t be used anymore form my point of view. The problem is that the url to the font files always had a version number included.
With every upgrade of Office365 this address has changed and your custom code have to be adapted too.
Those changing urls hindered the use in custom implementations. The latest version is still available through the CDN link.
The new font location is _layouts
To be honest to change a CDN url from time to time was not really an optimal solution. So for lab.n8d.at I had to change the url at least five times. Nearly every month.
Recently I was a little bit nervous be cause the CDN was now static for at least two month.
Just to be sure, I checked the current location of the fonts files today and recognized that this has fundamentally changed on Office 365.
Now all fonts are located in the folder “_layouts/fonts”. This is new in SharePoint and Office 365. Fair enough to check if this folder is also available in the current SharePoint 2016 version and yes it can be found there as well.
Office 365 icon font location on SharePoint 2016
Beside there are also some other fonts stored there that I will investigate soon.
I really like the fact that SharePoint on Office 365 and SharePoint 2016 will now use the same basis again. While Office 365 in the past has improved much quicker on-premises SharePoint were always a year behind.
Hopefully we will see further improvements on both platforms at the same time. Through all the hybrid scenarios, it has to be this way.
I know to have the same fonts on Office 365 and Sharepoint is just a small improvement but it makes development of custom web parts (jslink, add-in part and angularjs) easier. You can develop them once and use the same the in the same way in both worlds. It currently serves most icons you need and you are able to provide a consistent design across SharePoint.