Article
1 comment

Typography First – Make your SharePoint content readable and compelling

Typography

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 basic

The typography setup can be mainly defined by the following factors:

  • The Font
  • Font Size
  • Font Weight
  • Line Height
  • Letter Spacing

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:

  • Headline (<h1>-<h6>)
  • Paragraphs (<p>)
  • Quotes (<cite><cite>, <block quote> is decrepted with HTML 5)
  • Code, Navigation,…

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 (&lth2>-&lth3>).

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.

Font picker in composed look

Font picker in composed look

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.

@import url(http://fonts.googleapis.com/css?family=Dosis:500);
@import url(http://fonts.googleapis.com/css?family=Lobster+Two);
body{
    font-family: 'Dosis';
}
h1, h2, h3, h4{
    font-family: 'Lobster Two';
}
HTML Typographic Template

HTML Typographic Template

In SharePoint this only partially works because some elements will still have the Segoe font applied. For a full change of the body font some additional classes need to be added.

@import url(http://fonts.googleapis.com/css?family=Dosis:500);
@import url(http://fonts.googleapis.com/css?family=Lobster+Two);


body, .js-callout-body, .ms-calloutLink:link, .ms-calloutLinkDisabled, .ms-commandLink, .ms-commandLink:visited, 
.ms-core-defaultFont, .ms-core-listMenu-heading, .ms-core-listMenu-heading, .ms-tv-header, .ms-core-listMenu-verticalBox > .ms-core-listMenu-root > li > .ms-core-listMenu-item, .ms-core-listMenu-verticalBox > .ms-core-listMenu-root > li > .ms-core-listMenuEdit, .ms-core-navigation, .ms-core-pageTitle, .ms-core-pageTitle, .ms-core-pageTitle a, .ms-descriptiontext, .ms-metadata, .ms-secondaryCommandLink, .ms-secondaryCommandLink:visited, .ms-status-msg, .ms-textLarge, .ms-textXLarge, .ms-textXLarge, body, .ms-tv-header, .ms-webpart-titleText > a, .ms-webpart-titleText.ms-webpart-titleText, .o365cs-nav-header .o365cs-nav-navIcon .o365cs-nav-header .o365cs-nav-navIcon, body, .o365cs-nav-header .o365cs-nav-navItem, #pageStatusBar, a.ms-calloutLink:visited{
    font-family: 'Dosis';
}
h1, h2, h3, h4{
    font-family: 'Lobster Two';
}
Changed Typography in SharePoint

Changed Typography in SharePoint

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.

Other articles in this series

Further readings

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

Optimise HTML Output of the Rich Text Editor – “-ms-Element” explained

One big prejudice is that SharePoint is not capable to produce clean HTML output via the rich text editor. This was somewhat true with the previous versions of SharePoint. In SharePoint 2013 this has improved and can output all basic text elements without any additional style sheet classes.

How is this possible? By using the magic “-ms-element” attribute.

Element behaviour in the past

To explain how this works in the current version we need to take a look back to the rich text editor definitions of SharePoint 2010. To show I picked out the style definition for the “Header 1” element. This will be rendered as <h1 class=“ms-rteElement-H1”> .

The definition in the “corev4.css” goes like this:

H1.ms-rteElement-H1
{
    -ms-name:"Heading 1";
}
.ms-rteElement-H1
{
    font-size:2em;
    font-weight:normal;
}

The first definition is not a visible style. It is more an indication for the rich text editor that there exists a style definition for an H1 element. The label for the drop down is defined by the “-ms-name” attribute, a Microsoft specific vendor prefix. The H1 prior the classname defines the element that should be rendered.

The second style definition contains then the style that should be applied to the H1 element.

SharePoint 2010 - Rich text editor format and source code

SharePoint 2010 – Rich text editor format and source code

This worked perfect, but every single paragraph, list and headline had those classes assigned. Due this classes the file size increases.

Something to worry about? Let’s take a look how the browser handle those styles and tags.

Rendering in the browser

The most important style sheet files is the “corev4.css” in SharePoint 2010 and the “core15.css” in SharePoint 2013. Both files are huge and have a lot of design information. How will those files rendered by the browser internally?

The browsers follow a clear logic how they render all the elements and style definitions.

  1. Parse all tag styles (eg. H1, H2, P,…)
  2. Parse all class style definitions (eg. .ms-rteElement-H1)
  3. Parse all ID style definitions

“This hierarchy is the reason why sometimes ‘!important’ needs to be used because a style definition of a class gets overruled by an ID definition.”

This parsing goes all through the DOM and requires some time. Once the style is known by the browser the rendering commands will be sent to the render engine and the content gets displayed. To optimise the overall output performance, we just want to have clear HTML element with easy to identify the styles of those.

This is not so important for desktop browsers, but think about mobile devices and the bandwidth you have there. The structure of the HTML and the CSS have direct impact on the user experience, especially on older devices.

Optimise the HTML output using -ms-element

In the style sheets of SharePoint 2013 in some places a mystical new vendor prefixed attribute have been introduced. Mystical because there is a big lack of official information on this.

I research this behaviour. From my experience this attribute is responsible to render only the HTML tags instead of output it the old fashioned way like it was in SharePoint 2010. To explain how this works, let’s use the definition of the “Header 1” once again. First, we take a look at the code that can be found on various places in the “core15.css”.

/* Style 1: General definition of H1 */
h1, .ms-h1
{
	/* [ReplaceFont(themeFont:"large-heading")] */ 
	font-family:"Segoe UI Light","Segoe UI","Segoe",Tahoma,Helvetica,Arial,sans-serif;
	font-size:2.3em;
	/* [ReplaceColor(themeColor:"SubtleBodyText")] */ 
	color:#777;
	font-weight:200;
}
/* Style 2: HTML Definition to add the style to the drop down */
H1.ms-rteElement-H1
{
	-ms-name:"Heading 1";
	-ms-element:"true";
}
/* Style 3: Output optimisation */
.ms-rtestate-field h1,
h1.ms-rteElement-H1,
{
	line-height:1.4;
	/* [ReplaceColor(themeColor:"ContentAccent1")] */ 
	color:#0072C6;
}

The first part of the style shows the general definitions of all H1 tags wherever this will be used in the source code (Style 1).

The second definition (Style 2) defines as before that the editor should list “Heading 1” style in the rich text editor drop down and then there is the “-ms-element” attribute. So this means when a user browses the content only the H1 tag is included in source code. All without any additional class on the header.

The most important part is the third because it shows two different definitions. The “.ms-rtestate-field H1” definition is used for the view mode only. “.ms-rtestate-field” is the style sheet class that encapsulates the rich text editor content while H1 identifies the child tag.

The definition for “h1.ms-rteElement-h1” is the same definition as we had in SharePoint 2010 but now it will be only used for the edit mode. You will see this if you take a look at the source code during editing.

SharePoint 2013 - Rich Text Editor format and Source Code

SharePoint 2013 – Rich Text Editor format and Source Code

Now the content will be rendered differently in display and edit mode. Therefor both definitions are required to display the content correctly.

Summary

As you see now the rich text editor is able to output clean HTML code for all typographic standard elements. Every modern web content management use this. So does SharePoint. The benefit of this is that content migration from other systems is now easier because all that is needed is only plain HTML. Another benefit of this is that it has a positive effect on the SEO ranking of a public facing web site.

Customisation can be done if easily now because all that needs to be define are styles for the standard text element.

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
17 comments

Fixed width design in SharePoint 2013 – The fast way

I already provided a way to define a fixed width master page for SharePoint 2010. You might think that fixed width is not required because of all the fancy responsive web design. Mastering a fixed width design in SharePoint allow you to master responsive web design too. This is commonly known as progressive enhancements. By creating a fixed width master page first it can be easily adopted to responsive design too.

The modification are based on the seattle.html and if you haven’t done much with SharePoint Designer or master pages in 2013 I recommend you to read Master pages, the Master Page Gallery, and page layouts in SharePoint 2013 first. First I made a copy of the seattle.html because I wanted to provide the default look but add a fixed width. I also wanted to support the focus on content functionality that exists in SharePoint 2013.

Modifications in the Master Page

In SharePoint 2010 a JavaScript add the width of the current browser window to the s4-workpace element. This behavior hasn’t changed in SharePoint 2013. The good news is that applying the „s4-nosetwidth“ to the “s4-workspace” div avoids the JavaScript handler from being fired.

Before:

<div id="s4-workspace" class="ms-core-overlay">

After:

<div id="s4-workspace" class="ms-core-overlay s4-nosetwidth">

Depending on the template that will be used in another issue arises. In my case there was a problem with the float containers of an Enterprise Wiki Template. The problem with those containers is that if they haven’t been implemented properly the surrounding div will collapse and reduce its size. In worst case to height will collapse to 0px. This can be avoided by using the so-called “clearfix”. I recommend you to read all about float on CSS Tricks to get more details about this behavior.

Fixed width master page without clear fix

Fixed width master page without clear fix

So to get the fix applied I decided to use the div-clearfix method. It doesn’t hurt much and also has not much impact on the over html source. The position where I placed my div can be found at the vary end of the “s4-contentrow” right before the closing div.

                </div>
            </div>
        <div class="clearfix"></div>
    </div>
</div>
<!--SPM:<SharePoint:ScriptBlock runat="server">-->

 

Master page is done. Now we are ready to do some CSS magic. Don’t close the master page yet. We still got something to do.

Adding Style Sheet

First we need to add a style sheet to SharePoint. The most pleasant way to do this is by adding the server control named CssRegistration. First look for the CacheManifestLink element and place the CssRegistration below.

<!--SPM:<SharePoint:CacheManifestLink runat="server"/>-->
<!--SPM:<SharePoint:CssRegistration name="&lt;% $SPUrl:~sitecollection/Style Library/fixedwidth.css %&gt;" runat="server" after="SharepointCssFile" />-->

 

In my case the CSS File is called “fixedwidth.css” and is stored in the Style Library.

/*** Default setup ***/
#s4-workspace{
    /* background-color of the workspace */
    background-color: silver;
}

#s4-bodyContainer{
    /* defines 960px by using 60rem = 60 * 16px (Default Font Size) */
    width: 60rem;
    margin:auto;

    /* background color of the content */
     background-color: white;
}

/*** Fix for the dialogs ***/
.ms-dialog #s4-workspace{
    background-color: white;
}

.ms-dialog #s4-bodyContainer{
    margin: 0px;
    width: auto;
}

.ms-dlgContent #s4-bodyContainer{
    width: auto;
}

/*** clear fix ***/
.clearfix{
    clear: both;
}

I hope that the comments in the style sheets are descriptive enough for you. Otherwise please post a comment with your questions. In the end the result should look like this.

Final fixed width master page

Final fixed width master page

You will also find he download link at he end of this article.

Finally let’s take a closer look at the em, rem and pixel values.

em, rem instead of px

Using pixel in style sheets is something from the past. You still can use it but to be more flexible it’s recommended to use relative units like em, rem or percent.

Assume you have set the font size of a div element in your design to be 12px and like to have a total width of 60px for this element. Then you can simply assign a width of 5em.

12px * 5em = 60px

If you increase the font size of that element the width will scale in proportion. Setting the font size to 14px then the width of the element will be 70px.

14px * 5em = 70px

The downside of this is that you need to know every font size of every element to assign the proper value. The good news is there is the rem unit.

Instead of referring to the current element the rem, also called root em, refers to the font size of the body, which is a static value. The default value of the body is 16px. Now if you like to get a total width of 60px all you need to do is to divide the width with the font size.

60px / 16px = 3.75rem

That is the whole concept explained in short.

Worried about the browser that understands root em? Internet Explorer 8 doesn’t understand this value but you can define a simple fallback for that. This looks for the s4-bodycontainer like this:

#s4-bodyContainer{
    /*** only for IE8 and below ***/
    width: 960px;

   /**** for the future ***/
    width: 60rem;
    margin:auto;
     /* background color of the content */
     background-color: white;
}

To get a detailed overview of browser that support rem you can browse caniuse.com.

Download fixed width master page FixedWidthMasterPage.zip

Article
68 comments

Build a flexible mega drop down navigation for SharePoint

I’ve read a lot of good articles about mega menus or mega drop in the past. They all were from a technical point of view correct and useful introduction about the basics behind. When it comes to SharePoint you should always consider the user and how they can administer or change the design on their own. This is one of the strengths in SharePoint and the user should always be in the center of every solution. For a mega menu it doesn’t take much to accomplish. This can be done easily in SharePoint Designer or Visual Studio. Choose your weapon of choice and spend 30 Minutes to build up a simple but powerful mega menu.

The ingredients and how they work together

In general a mega menu is nothing more than an HTML Snippet that will be loaded when a user hover over a navigation item. This can be the top navigation or in SharePoint terms the quick launch navigation. For embedding to the quick launch the code only needs to be slightly changed.

The base of the mega menu is a customized article page that has a web part zone for the drop down content. The navigation is the out of the box navigation that should be extended for the following tasks

  • Hover over a navigation item
  • Grab the link URL
  • Load the linked page
  • Cut out the required web part zone
  • Add it to the page as the content of the mega drop down

To accomplish those tasks the well-known JavaScript library Jquery will be used.

The article page

In general to define the content of the mega menu any mega menu can be used as a starting point. The only thing that needs to be done is to encapsulate any web part zone into a <div> element.

Mockup Mega Drop Down Article Page

Mockup Mega Drop Down Article Page

The code for this is simple and looks like this:

...
<ContentTemplate>
 <div class="article article-right">
 <PublishingWebControls:EditModePanel runat="server" CssClass="edit-mode-panel">
 <SharePointWebControls:TextField runat="server" FieldName="Title"/>
 </PublishingWebControls:EditModePanel>
 <div class="n8d-dropdown" id="megadropdownitem">
 <WebPartPages:WebPartZone runat="server" AllowPersonalization="false" ID="TopZone" FrameType="None" Title="<%$Resources:cms,WebPartZoneTitle_Top%>" Orientation="Vertical" />
 </div>
</ContentTemplate>
...

 

The script that performs the mega menu magic will simply grab the defined <div> element with all the content in it and adds it to the navigation. Then the author will be able to add content to their demand or change existing content without any single line of code. The only thing that needs to be defined is styled to show the content in a proper way.

The master page

The second thing that is required for this solution is a master page. This is only needed to register the required styles and Jquery scripts. In the default configuration of the master page SharePoint already have a fly out navigation.

....
 <script src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.8.2.min.js" type="text/javascript"></script>
 <script src="/_layouts/n8d.MegaMenu/MegaMenu.js" type="text/javascript"></script>
 <link type="text/css" href='/_layouts/n8d.MegaMenu/MegaDropDown.css' rel="stylesheet" />
...

To avoid possible conflicts with the script, the navigation control needs to be modified. This can be done by changing the properties for the MaximumDynamicDisplayLevels. It needs to be set from the default value which is 1 and needs to be set 0. This means that no dynamic children will be rendered.

...
<asp:ContentPlaceHolder id="PlaceHolderHorizontalNav" runat="server">
 <SharePoint:AspMenu
 ID="TopNavigationMenuV4"
 Runat="server"
 EnableViewState="false"
 DataSourceID="topSiteMap"
 AccessKey="<%$Resources:wss,navigation_accesskey%>"
 UseSimpleRendering="true"
 UseSeparateCss="false"
 Orientation="Horizontal"
 StaticDisplayLevels="2"
 MaximumDynamicDisplayLevels="0"
 SkipLinkText=""
 CssClass="s4-tn" />
   <SharePoint:DelegateControl runat="server" ControlId="TopNavigationDataSource" Id="topNavigationDelegate">
     <Template_Controls>
       <asp:SiteMapDataSource
        ShowStartingNode="False"
        SiteMapProvider="SPNavigationProvider"
        id="topSiteMap"
        runat="server"
        StartingNodeUrl="sid:1002"/>
     </Template_Controls>
   </SharePoint:DelegateControl>
</asp:ContentPlaceHolder>
...

Now that the base setup is done it’s time for some JQuery magic.

The Mega Menu Script

As mentioned before the script doesn’t do much. So when the page is loaded JQuery grabs all URL from the top navigation and looks for content that should be added to the navigation. This will be done by inserting a new <div> element directly on every item of the top navigation. This will be done by the following function.

var loadingData = function(){

    var navigationElement = $(this);
    var link = $(this).attr("href");
    var text = $(this).find(".menu-item-text").text();
    $(this).attr("linkname", text);

    $.ajax({
            url: link,
            async: false,
            dataType: "html",
            success: 
                function (data) {
                    content = $(data).find("#megadropdownitem");
                    
                    if(content.html() != undefined){
                        // fix content for calender
                        content.find(".ms-WPBody").each(function () {
                            $(this).removeAttr("webpartid");
                            $(this).removeAttr("class");
                            $(this).removeAttr("id");
                        })
                        newContent = "<div class='mdd-itemcontent'><div class='mdd-innercontent'>"+content.html()+"</div></div>";
                        navigationElement.parent().prepend(newContent);
                    }
                }
    });

}

For the animation of the flyout i simply added a hover binding to all of the navigation items.

$(document).ready(function(){

    var pageMode = $("#MSOSPWebPartManager_DisplayModeName");

    if(pageMode.val() == "Browse"){
        $(".s4-tn li.static a.static").each(loadingData);
        $(".s4-tn li.static").hover(showFlyOut, hideFlyOut);
    }
});

var showFlyOut = function(){
    if($(this).children(".mdd-itemcontent").html() != null){
        $(this).children(".menu-item").toggleClass("hover");
        $(this).children(".mdd-itemcontent").slideDown("fast");
    }
}

var hideFlyOut = function(){
    if($(this).children(".mdd-itemcontent").html() != null){
        $(this).children(".menu-item").toggleClass("hover");
        $(this).children(".mdd-itemcontent").slideUp("fast");
    }
}

The functions showFlyout and hideFlyout will show and hide the mega menu / flyout and also the class of the current selected navigation item will be toggled for a better styling. The last step was to add the design for the menu. After that the mega menu looks like this.

Finished look of the mega drop down

Finished look of the mega drop down

Let me show you how the solution works in the following video.

How to create a mega menu navigation in SharePoint from Stefan Bauer on Vimeo.

As seen in the solution the content of the mega drop down is flexible. Static or dynamic content can be added without changing the core functionality. No server side code is required, which makes it easy to adapt for SharePoint 2013. By changing the style sheets the form of the drop down can be easily adapted. While I used visual studio to deploy my solution this functionality can be added by using SharePoint Designer too. I think the most time consuming task in my mega menu solution are the design adoption but a simple drop down menu can be accomplished in 30 minutes. Would be great if you can share your experience with my solution. Finally what’s left to say have fun in creating you own variations.

Update Nov 19, 2013: Bugfix Calendar Web Part

As David Foster and Scott McLeod pointed out in the comments there is an error when a calendar will be used. The items were delegated to the mega menu instead of the list web part. The solution below is updated and contains the fixed version.

Download Visual Studio Solution

Article
0 comment

A little story about web design and what designer should know about IE9

So this blog post is the result of a funny story happened today. Since the last couple of weeks I daily check out awwwards and css design awards both sites present all the latest and best web designs in the web. Today the site of the day was deep time by Jamie Brightmore (@jaybee). The site is a really great user interface and shows the possibilities in current web design. Deep Time is an interactive info graphic built for the modern web and iPad. It offers a visual way to explore the various stages of the Earth’s history using a 12 hour clock analogy.

I liked the design and so I published it to Facebook. A couple of minutes later I was messaged by a friend that the web site won’t open in IE9. I was not really amused because awwwards and css design awards nominated web sites normally work in all mayor and latest version of browser. I wrote a comment about the deep time web site at awwwards and twittered Jaime Brightmore that I don’t like when site were nominated that don’t support all latest browser versions.

Jaime replied that he have tested it in IE9 and the animation there was quite slow and svg wasn’t loaded correct. The problem Jaime had is one that many people have and especially when they are not using windows every day. It is also easy to solve.

Jaime as a web designer and developer use a make and made the testing in a VmWare and used IE9, but not the 32-bit Version he installed and tested it in 64 bit. The 64 Bit Version is not intended to be used to browse the web it is for development purpose the same way it behaves like with Microsoft Office. The intention behind the 64 Bit Versions is to allow developer all around the world to upgrade their add-ons and plugins to 64 Bit.

In Windows the 64 Bit Version of Internet Explorer 9 is not intended to be used for normal web surfing. Eric Law from Microsoft has a Q&A for IE9 64 bit vs. 32 bit which is worth reading. The 32 Bit Version and the 64 Bit Version are both installed on Windows but the 64 Bit version is hidden to normal users with reason.

At the end I told Jaime that I wanted to give it a try on IE9 and test his web site. He sent me a link because he blocked IE Browsers completely because of the poor performance and different false look. The result was that all worked the same way as it worked in Google Chrome or Safari. Not one pixel was different in IE compared to other browsers and the performance was really amazing. All was tested with the 32 bit version of the Microsoft Browser and at the end he removed the blocking of IE9 and changed it to IE8 which somehow makes sense.

Before you develop a new web project consider the following things that you should know:

First of all for testing only use the 32 Bit Version of Internet Explorer. By pressing the F12 key the developer tools will be shown and the Browser Version can be configured to IE9, IE8 and IE7. That switch will render the site natively in the older versions and the tests matches one to one with the older versions.

Change Browser Version to IE7 and IE8

Change Browser Version to IE7 and IE8

The new developer tools are really handy and let fire bug to look old, but still cannot compete to the Safari Developer tools what I like most.

I think Microsoft has done a great job on the new version of Internet Explorer. Internet Explorer is much better than its reputation.

Article
15 comments

Use @font-face in Rich Text Editor of SharePoint 2010

In modern web design many sites use web fonts. Nearly since the beginning of the Internet there were always intentions to bring desktop fonts to the web. Nowadays the support for web typography in modern browser is in really big. Netscape introduced the <font> Tag in 1995 as a first attempt to bring different fonts to the web. Internet Explorer 4 was the first browser as far as I know that allows font embedding back in 1997.

In general some really good articles about web typography can be found on http://www.alistapart.com/topics/design/web-fonts/ which is worth reading to deep dive into web typography.[Read more]