SharePoint 2013 : Creating a Composed Look

With SharePoint 2013, many new features has been introduced by Microsoft like Device Channels, Cross Site Publishing, App Model, JS Link and many more. Among those many new cool features, one is Composed Look which has brought a revolution around the previous concept of themes. 

Before we actually dive into the Theming engine, let us understand what themes actually are and after which we will talk about Composed Looks. 

As quoted from MSDN “Themes give you a quick and easy way to change the look and feel of any site in SharePoint 2013. They are predesigned collections of web page elements, such as fonts, color schemes, layout, and background pictures that come with SharePoint 2013.”

From an end user perspective, this is a very powerful feature as the users can select an OOTB available design and change the color, font, background image and layout etc. as well as create a new design altogether. We will get on to how to achieve this in a little while.

With the advent of SharePoint 2013, there has been great improvement around the Theming Engine. Now we are not required to make themes in the Office client anymore. A new feature has been introduced by Microsoft namedComposed Looks.  If you browse to the Site Settings > Look and Feel there you can see a link to Change the Look. Clicking on this link will land you on a page where you can see all the available composed looks that you can select from. 

In SharePoint 2013 the theming engine has been revamped keeping into consideration the power users so as to facilitate them with a simple solution in the form of an interface where they can change the theme of their SharePoint 2013 site so that it gets aligned with their corporate branding standards in terms of color, fonts etc. without investing much time into it. It is indeed a very powerful feature when it comes to the enterprise. 

With composed looks, you can offer your Power Users with a list of branded looks and also give them the flexibility to do some modifications around the layout, color, fonts and images.

To read the complete post click click on the link here

Cheers,
Geetanjali

SharePoint 2013 : An Introduction to JSLink

Client Side Rendering (CSR) is one of the new concepts introduced by Microsoft in SharePoint 2013. With the help of this new feature you don’t have to write XSLT to style SharePoint elements like list views, fields etc. Using this technique you simply have to make use of HTML and JavaScript to change the user interface.

As cited in MSDN “Client-side rendering provides a mechanism that you can use to produce your own output for a set of controls that are hosted in a SharePoint page. This mechanism enables you to use well-known technologies, such as HTML and JavaScript, to define the rendering logic of custom field types. In client-side rendering you can specify your own JavaScript resources and host them in the data storage options available to your farm solution, such as the _layouts folder.”

Client side rendering is like a templating mechanism that you use to customize the UI. 

When we talk about client side rendering, then there are two things that requires a mention here are:

1. Display Templates
2. JSLink

Display templates are used in webparts that are based upon search technology. They are used for handling the rendering of the search results on the page. We can customize how the search results will appear to the end user.

The second one i.e. the JSLink, is of our interest in the scope of this article. JSLink is one amongst the many cool features introduced by Microsoft in SharePoint 2013.
It is a property that is available on many SharePoint objects like content types, lists, views, fields and web part properties. We simply point this property to a JavaScript file that will do a magic on our page.  In other words, will simply transform our page into whatever way we want to render all at the client side.

You might have encountered scenarios where your customers have approached you to display lists with a custom look and feel without writing any piece of code. Consider for example you have a list holding contact details of the users that needs to be displayed in a card like manner as opposed to the traditional screen. And all this has to be done without writing any server side code. Though this might seem to be tricky but it can be achieved very easily using a simple mechanism and i.e. JSLink.

JSLink has tremendous power. It can transform your entire site into an attractive piece without writing any server side code.  It is like an on-off switch. If you don’t like it, you can simply remove the value of the jslink property and you will get back the original default behaviour.

To see the actual strength of this property, let us actually dig some code and cover some scenarios.

To read the complete post click click on the link here

Step by Step Guide to Configure Environment for Creating your first SharePoint Hosted App

One of the new features of SharePoint 2013 is the SharePoint App Model. Similar to the windows phone marketplace, we now have a SharePoint Store available where we can simply search for apps and download them on our SharePoint site.  In SharePoint 2013, everything is an app, be it lists or libraries.

In this article we will talk about how to configure development environment for an on-premise implementation of a SharePoint Hosted App. We will also create our first basic SharePoint Hosted Apps and talk about few possible errors usually encountered by developers while implementing their very first app. There are huge amount of reference available over MSDN to create and configure the apps but the purpose of this article is to help developers not only configure the environment but also pose before them the common challenges that they might face during their very first implementation and help them resolve those errors.

To have a complete look at this post, refer to link over here

SharePoint Online : Working with People Search and User Profiles

People Search and User Profiles are amongst the popular topics that everyone use in their projects every now and then. With SharePoint 2013, a lot of functionality has been included in the Client API's by Microsoft. If you consider user profiles itself, in SharePoint 2010 you cannot fetch user profiles using client side object model. However, with SharePoint 2013, you have a wide variety of methods that you can use to fetch the user profile information using client object model. The search API is also expanded greatly.

Content Search WebPart is one of the important additions in SharePoint 2013. Using this webpart you can display content that was crawled and added to search index.

To have a complete look at this post refer to the link over here. 

Cheers,

Geetanjali

SharePoint Online : Export User Profile Properties Using CSOM

With SharePoint 2013, Microsoft has provided the ability to fetch User Profile information client side using CSOM API’s. User Profiles and user profile properties provide information about the SharePoint Users.

The scope of this article is to talk about how we can make use of CSOM API to fetch the user profile information on Office 365 and export profile properties to a csv file.

To read this entire blog post visit the link here.

Perform Basic Admin Operations using CSOM in SharePoint Online

This post will focus on how to make use of SharePointOnlineCredentials class to authenticate to SharePoint Online from your host machine using a console application. In this article I will give you a walk through of some of the basic administration stuff that can now be achieved using CSOM. Previously this was possible only using Powershell and SharePoint Online (SPO) commandlets but now we have CSOM as an option available as well.

Though we can use CSOM from an app but in the below scenarios I will be implementing the same using Console Application to keep things simple.

To read the entire post visit the link here.

Cheers,
Geetanjali

Hiding links in Welcome Control in SharePoint 2013

Lately, I came across a requirement around hiding the "About Me" link in the welcome control dropdown. The simplest and quickest solution that seemed to me was to play some tricks using css.
Using firebug, I tried to analyse how OOB SharePoint Welcome Control menu renders. Below is the screenshot of how it works.

Now the game is simple. As you can see in the above screenshot, the menu is rendered as ul and li.
There are two dropdown items in the Welcome Menu - About Me link and the Sign Out link each as li tags inside the ul tag.

I did some manipulation with the css and boom the About Me link got hidden.

 

Now if you have a look at the welcome menu it has the About Me link hidden.  

This might not be the best solution to do it but very simple to do. Hope it helps !!!

Navigating to different URL from Desktop and Mobile View in SharePoint 2013

Recently, while incorporating device channels in SharePoint 2013 Online site, I came across a requirement where users were to be navigated to different pages for a particular menu item in the Top navigation. We were using Managed Metadata Navigation and the Top Navigation that was getting rendered was same for both desktop and mobile view. Since it was all dynamic so as per my understanding the option we had was to change this navigation at runtime on the fly. Out of various options that might be available for this, the simplest to me seemed to be dynamically change the URL using Jquery and CSS. I did some analysis as to how the navigation is getting rendered in the Mobile and what classes are getting attached and based on that came up with the following solution 




If you look at the above code snippet which I see for my mobile device channel, every menu item , irrespective of the first level of navigation or the second level of navigation, renders as an li tag with an anchor tag. The anchor tag is having class as level1 for First Level of navigation and level2 for Second Level of navigation. Now, we can play with level1 or level2 class based upon which level of navigation we want to change and hence achieve the desired functionality.

$(".level2:Contains('Menu Item Title')").each(function () {

                    var menuItem = $(this);
                    var parentItem = menuItem.closest("a");
                    parentItem.attr("href", "Desired Navigation Url");


});

Now, what the above code snippet does is that it checks for all the menu items where the title exists that I need to change and for that menu item, it changes the href attribute to the desired navigation url. This code snippet can be placed in the mobile master page for the device channel.

Please note that the above approach is a workaround only and not a perfect solution as there are some side effects of this approach. The above jquery will fire everytime the page loads as we have written it in the masterpage and on the fly it will change the navigation url if we are using the mobile master page. Also, since these classes are OOB so if in future Microsoft changes the class names then this will not work and we need to change it accordingly. However, we can try to explore more around SharePoint ASP menu and try to apply some custom class there and see how that works. Also, for readers who want to explore more options can try to play around with taxonomy using ecmascript and see what can be achieved using that. Above approach is a quick fix and used with caution.

Happy Reading :)

Mobile Panel in SharePoint 2013

In my previous post on Device Channel, I explained how to create a device channel to target different devices. In this blog post, I will explain about Mobile Panels and Device Channel Panels and why to use them. I am going to explain a scenario which me and my friend worked on in order to have an understanding on the exact need for these panels.
There are times when you want to target only specific content of a page based on devices. Most of the times you might have noticed that many websites have a whole bunch of features when you have a look at the site in the desktop mode and have filtered set of features when viewed on mobile.
When it comes to SharePoint 2013, then Microsoft has came up with the concept of Mobile Panel and Device Channel Panel to provide a similar feature. These help in targeting specific content of a page layout on mobile and desktop. Mobile Panel allows content authors to target specific content for different devices. For example, mostly you have observed a banner image coming as a feature area on the sites. Now, this looks nice on the desktop version, but on mobiles, this does not seem much relevant. So, the requirement is to show this banner only is the user is in desktop view and not when in mobile view. Device Channel Panel is also a snippet that we can add to master page or to a page layout to control what content is rendered for the channels that we create. So for the above scenario, we want to have a single page layout which should be intelligent enough to show content specific to each of these channels.

Now, the main thing here is to create a page layout which could be shared across all mobile devices as well as the desktop view. In order to do that we need to make it device enabled using Mobile Panel. The normal way of proceeding on this is to have a region where all the common webparts both for mobile and desktop should go and another region where desktop specific should go. But this is not as simple as it seemed. We started with adding device channel for desktop and added a webpart zone there so as to add our banner webpart there which was meant to be visible only in desktop version. Then outside that device channel, we added webpart zones that will hold all the webparts that were common for mobile and desktop version. But to our surprise, this did not work. This logically correct solution was not showing the behavior that we expected from it.
Then we thought of creating two device channels, one for mobile and the other for desktop each having webpart zones and then we added all the mobile specific webpart to the device channel meant for Mobile and all the desktop specific webparts to the Default Channel(which is used for Desktop view). But the results were surprising again. In the desktop view, everything seemed correct but as soon as we switched to mobile view, we observed that the banner webpart, which we had only added in the desktop view and not in the mobile view, was visible in the mobile as well. On editing the page, we saw that in mobile view, edit page is showing the webpart but in wrong zone.
After some analysis, we found that the issue is that when a webpart is added to a webpart zone in one mobile panel and if that webpart zone does not exist in the other mobile panel then that webpart will automatically move to the next available webpart zone. Therefore, when we added the banner webpart to a zone in the Desktop device channel and when the page is viewed in mobile view, then because the banner webpart zone did not exist in the mobile view, the banner webpart got added to one of the webpart zones of the mobile device channel. So, after some drilling, we came to a solution that since the availability of the webpart zones is causing an issue, what if we design the layout in a way that the desktop device channel will have webpart zones in the mobile panel and the mobile device channel will have Publishing HTML fields instead to add the webpart. Therefore, if there will be no webpart zone in the mobile view, then there will be no zone available for the banner webpart to get added to. We tried this approach and Voila it worked. Below is the code snippet for what we actually did.


Now in the above code if you see, we have added two MobilePanels, one for the desktop and other for the Mobile. Both the MobilePanels have an attribute named IncludedChannels, which tells the panel which channel to target. "DEFAULT" is used for desktop view and "MOBILE" in our case is used for targeting mobile devices.
The above solution has however the following limitations

1. User has to manually add webparts to the mobile device panel. You can however overcome this limitation by automating adding of webparts to the RichHtmlField.
2. Two copies of the same webpart will be there on the page for the common webparts. However, for example say we have written a webpart whose business logic is written in a separate js file then this does not mean that the js file will be loaded twice on the page one for the desktop and one for the mobile view. The js file will be loaded only once for each channel. So performance wise, it will not impact.

This is how you can target specific content of the page layout for different channels using MobilePanels.
Please note here that the MobilePanels are now deprecated and instead we should use DeviceChannelPanels. DeviceChannelPanels are used in the same way as we used the MobilePanels above and they offer the same functionality. 

Hope this helps somewhere. :)

Device Channel in SharePoint 2013

Amongst many new features introduced in SharePoint 2013, one of the key features is Device Channel. With the continuous growth in the mobility sector, mostly smartphones are being widely used to  surf net. As a result, it is very important to provide a user friendly experience to any user visiting your website on mobile.

Microsoft has come up with the concept of Device Channels in SharePoint 2013. For all those who have not heard about Device Channels, let me explain it briefly.

Device Channels allows you to target your SharePoint site (Device Channels are available only if publishing feature is activated.) on mobile devices. It helps you in setting different master pages and css for different devices like Tablet, Windows Phone, iPhone etc. As a result, you can have a user friendly experience for your website when viewed on mobile device.

The very first thing that needs to be done is to create Device Channel for your site. In order to do the same, you need to go to the Site Settings > Look and Feel section and click Device Channels link.

 

 

After clicking this link, you will be directed to the list that contains all the device channels. By default you will see one device channel created for you already. It is the default channel which will be visible when no other channels are active or when the device's user agent string does not match the device inclusion rules for any active channel.

 

 

 

 

When you try to create a new device channel for your devices, you need to specify a few important parameters i.e. Alias, Device Inclusion Rules and Active.

Alias is the unique ID that helps in determining the device channel in the code. This comes handy when working with Device Channel Panel (will come on this a little later).

Device Inclusion Rules contains the user agent substring such as Windows Phone OS. This substring will be matched against the browser's user agent string in the device and based on that master page will be applied.

Active checkbox enables the device channel if it is checked.

 

The next thing that is required to be done is to associate a master page to the newly created device channel. To do this, go back to the site settings Look and Feel section and click on Master Page link.

 

 

There you can configure a master page for your newly created Device Channel.

 

After setting the master page for your device, now if you view the site in the device, you will see the device channel applied. 

In case you directly want to test the changes, you can do it by appending the following to the url in the browser.

?DeviceChannel=Alias

eg http://somedomain.com?DeviceChannel=mobile

Hope it gives you a brief idea about what device channels are and how they can be configured. In my next post , I will explain about Device Channel Panels. Till then stay tuned. :)

Happy SharePointing :)

 

 

A subsite cannot be created inside an app web

For all those who have started exploring SharePoint 2013 must be by now aware of the term App Web. Recently , I did a small POC to see how we can provision a subsite inside an app web. Now on first glance it seems to be a quite simple requirement as you are simply going to create a subsite. But this is not the case.
For App's things are a bit different. After some struggle to create a subsite inside an APP Web, I got an error message stating that "A subsite cannot be created inside an APP Web" .
For all those who wants to drill down further as to how this message came, please have a look at the below code snippet that gave the above result.

var hostweburl,appweburl;
jQuery(document).ready(function () {
    hostweburl = decodeURIComponent(
                getQueryStringParameter("SPHostUrl")
        );
    appweburl =
        decodeURIComponent(
            getQueryStringParameter("SPAppWebUrl")
    );

    
    jQuery("#btnSubmit").click(function () {
 
        createSite();
        
    });

});

function getQueryStringParameter(paramToRetrieve) {
    var params =
        document.URL.split("?")[1].split("&");
    var strParams = "";
    for (var i = 0; i < params.length; i = i + 1) {
        var singleParam = params[i].split("=");
        if (singleParam[0] == paramToRetrieve)
            return singleParam[1];
    }
}

function createSite() {

        context = new SP.ClientContext(appweburl);
        currentWeb = context.get_web();

        context.load(currentWeb);
                   context.executeQueryAsync(onCreationSuccess, OnFailure);
    }

    function onCreationSuccess() {

        var appInstanceID = currentWeb.get_appInstanceId();

        var webCreateInfo = new SP.WebCreationInformation();
        webCreateInfo.set_description("This site created from ECMA script");
        webCreateInfo.set_language(1033);
        webCreateInfo.set_title("Test");
        webCreateInfo.set_url("Test");
        webCreateInfo.set_useSamePermissionsAsParentSite(true);
        webCreateInfo.set_webTemplate("APP#0");

       web = currentWeb.get_webs().add(webCreateInfo,false,appInstanceID);

        context.load(web);
        context.executeQueryAsync(onSuccess, OnFailure);
        
    }

    function onSuccess() {
        alert("Web created");
    }

    function OnFailure(sender, args) {
        alert(args.get_message());
    }