Moving from the world of SharePoint 2010 XSLT views to HTML5 and CSS world can be quite bumpy road. But, I guess it is worth to take it, as every day we experience excellent, nice looking, useful interfaces build this way. So, why not serve the SharePoint content this way?
Let’s start with Responsive Web Design which basically means that content of your page and behavior of you App should be quite good on many devices. Devices which you don’t know and have no idea what is the resolution etc. Those devices does not have to exist yet.
This part describes the idea of grid systems and how to build responsive master page for publishing sites.
Components
To make my job easier I have disassembled a Responsive Web Design (RWD) into few areas:
- Layout,
- Navigation,
- Content presentation,
- Content.
Layout
- RWD layout have to be able to resize, change or do some other magic to fit someway (or just be useful) the user device. This is addressed by so called grids – most popular are 12 columns.
- Each block can occupy one or more columns. Block width is expressed in percentage, so if you want to have two, equal width blocks, you should set the width to 50%.
- Additionally, media queries can be used to apply different CSS, for given resolution. For instance width can be set to 100% for small screen, 50% for larger one and 25% for big ones.
- Sounds pretty simple, but the HTML with CSS does not behave so simple.
- There are two basic ways of building layout: inline display (content behave like text, so goes to the next line etc.) and block display (content is displayed as “picture”, so occupies the whole line itself).
- Obviously we want the content to behave as we like, so to have 3 pictures in the same line or picture and text and so on.
- That is why some grid system were created – to better control layout of the page and how it would behave with different screen resolution.
- There are at least 4 different kind of grids which can be used.
Inline-block grid
This kind of grid is very simple, just display: inline-block should be set for block elements (e.g. div), so they start behaving like inline elements – they will just be displayed like “text” – fill the line of screen or go to the next line.
The challenge with Inline-block grid is some small space between each block caused by whitespace in HTML page code. If you have two <div> separated by space, new line or whatever, you get some space in between blocks displayed on the screen. It means that with 4 blocks set to 25% width each one, the last one would be moved to next line.
You can find-out how to approach this problem here: http://justifygrid.com/ and another new method here: http://scottkellum.com/2013/10/25/the-new-kellum-method.html.
Floats grid
This is the most popular way of building responsive grids. Frameworks like Twitter Bootstrap or Zurb Foundation use this approach. The magic in this kind of grid is to use CSS “float:left”, so the blocks will float one after another. I think, that it is explained quite well here: http://www.vanseodesign.com/css/understanding-css-floats/.
There are couple of challenges with this kind of grid, mainly block positioning, alignment etc. The main ones are listed here: http://www.vanseodesign.com/css/inline-blocks/. Additionally you can find there information about differences between inline-block and floats.
Flexbox
The challenges with previously mentioned grid systems were noticed and new ways of building flexible web layouts emerged.
The first one is flexbox grid. I am not going to describe it in details, as there is “A Complete Guide to Flexbox” – http://css-tricks.com/snippets/css/a-guide-to-flexbox/.
You can get to know more, why flexbox is so great comparing to previously mentioned ones – http://philipwalton.github.io/solved-by-flexbox/demos/grids/.
If you want to take a look how it works… – http://flexboxgrid.com/.
The major disadvantage at the moment is that, it is not supported on older browsers – e.g. IE9 – http://caniuse.com/#search=flex.
Grid
Microsoft designed it’s own way to address problems with page layouts. It is described here: http://msdn.microsoft.com/en-us/library/ie/hh673533(v=vs.85).aspx. At the moment it is only supported in IE10 and IE11, but other browser probably will support it in some time: http://caniuse.com/#search=grid.
One can say “Yeah, sure, Microsoft have to the same completely different way as others”. Well, I am not sure as I have found this article – http://hugogiraudel.com/2013/04/04/css-grid-layout/. For me, this means that flex and grid are complementary.
Media queries – px, em and rem
As I have mentioned before, the important parts of responsive web layouts are media queries, so some CSS styling is only applied for certain screen resolution.
Usually media quires use pixels – px. So, e.g. for screens smaller than 1024 px, you get a different styles.
The problem with this approach at the moment are new devices which get a small screen (e.g. 10 inches), but high resolution. So, the question is: “Should we present content on this kind of device as on large screen (desktop monitor) or small screen (tablet)?”.
To answer this question, some people suggested to make this decision based not on the screen resolution, but font size. For me it make sense, as I assume that device designer made a sane decision and made default browser font size usable.
In some grids, em or rem is used for media queries, not pixles. Em and rem are similar and 1em means basic font size, while 2em means twice as big. The difference between em and rem is that em is relative to upper level element font size, so you can get undesired, cascading font size effect, while rem are relative to main font size, so there is no cascading effect – http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/.
Media queries using pixels can also impact user experience while zooming page – http://css-tricks.com/zooming-squishes/.
That is why em or rem is used in media queries. If you don’t care about supporting IE8 and below, you can use rem. Thus you avoid abovementioned problem.
Back to SharePoint
So, how this all applies to SharePoint?
There are couple of approaches which can be taken to build RWD with SharePoint.
The first one is just to ignore completely existing SharePoint interface and take any framework, UI components and whatever you want to build user interface and exchange data with SharePoint using REST API. Pages can be hosted in SharePoint libraries, but you are on your own with e.g. page editing and number of other things.
The other approach is to use what is good in SharePoint and just improve it a bit (or a little bit more). I will describe a little bit more about this below.
As you know there are generally two kinds of SharePoint sites: publishing sites and non-publishing sites.
First let’s take a look at publishing sites.
SharePoint Publishing Sites – RWD
What I like in SharePoint 2013 and Office 365 is Design Manager. Although it is far from perfect, but enables you to build some nice design in reasonable time.
The first task is to build master page and page layouts.
Which framework to choose?
While Twitter Bootstrap and Zurb Foundation are quite popular, they bring much, much more than only a responsive grid. There is a lot stuff behind, including CSS files which conflicts with SharePoint ones. So, looking for just a responsive grid I have found Cute Grids – http://www.cutegrids.com/. This is just a grid, but CSS file is small and readable if you want to modify it. I wanted.
CSS Modifications
The first thing I did was commenting out the lines you can find in most of grid systems:
*,
*:after,
*:before {
margin: 0;
padding: 0;
-webkit-box-sizing: border-box;
-moz-box-sizing: border-box;
box-sizing: border-box
}
Those lines applies box-sizing to everything. It causes that some items are just not looking well in SharePoint. I have used something like that instead:
[class*='cute-'] {
-webkit-box-sizing: border-box;
-moz-box-sizing: border-box;
box-sizing: border-box;
}
That ensures that box-sizing property is applied only to elements with proper CSS class.
I have also modified units in media queries from em to rem.
I have also changed font size to 1 rem as SharePoint changes it to 13px, which is a bit too small and is related to size in pixels, which I don’t like:
body, .ms-core-defaultFont, #pageStatusBar, .ms-status-msg, .js-callout-body {
font-size: 1rem;
}
That is most of the basic stuff.
Create HTML page
Now you can start with building your responsive master page. I would recommend start with just tiny html page with <body> and one <div> with content.
Then you can upload it to Design Manager, wait a moment for conversion and start editing converted html page.
Now you need add few lines to converted HTML page (not to master page).
Somewhere in page head you have to add:
<meta content="width=device-width, initial-scale=1.0" name="viewport" />
and
<!--MS: <SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style Library/en-us/Themable/cutegrid.css %>" runat="server" after="SharepointCssFile">--> <!--ME:</SharePoint:CssRegistration>-->
I have decided to place CSS file in the Style Library as this way, it becomes themable CSS. It means that later on you can use some custom decorations but in line with SharePoint themes. You have to keep in mind that effect of this CSS will be visible after theme is changed in SharePoint.
The last thing is to decide how the content of master page (e.g. logo, menu, search box, header, footer) should be displayed.
For each of those parts there is a separate snippet. You can find excellent description how to use it in a book “SharePoint 2013 Branding and User Interface Design”.
Let’s suppose at the top you need Site Logo and Search box, each one occupying half of the width and below you want to have menu. At the bottom of the page you want to have full width footer.
The part of HTML page can look like below.
<div id="s4-workspace"> <div id="s4-bodyContainer"> <!-- Everything have to be placed after this div--> <div class="row"> <!-- Site logo box - full width on small devices, half width on others --> <div class="cute-6-tablet cute-12-phone"> <div data-name="SiteLogo"> <!-- Site Logo Snippet--></div> </div> <!-- Search box full width on small devices, half width on others --> <div class="cute-6-tablet cute-12-phone"> <div data-name="SearchBox"> <!-- Search Box Snippet--></div> </div> </div> <div class="row"> <!-- Top navigation --> <div class="cute-12-tablet"> <div data-name="TopNavigationNoFlyoutWithStartNode"> <!--CS: Start Top Navigation Snippet--></div> </div> </div> <!-- Content of page goes here --> <div data-name="ContentPlaceHolderMain"> <!-- PlaceHolderMain Snippet--></div> <div class="row"> <!-- Footer place - we what to hide it on small devices --> <div class="hide-phone"> <!-- Footer sinppet --></div> </div> </div> </div>
This sample pictures the basic idea of responsive SharePoint masterpage.
What is next?
At the moment you can have basic responsive frame for masterpage. Now you will need responsive logo, menu, search box and page layouts.
But as this is another long topic I will continue it a little bit later (if you like it).