Navigation goes managed in SharePoint 2013!

Out of box navigation in SharePoint was always bound to site hierarchy until now and implementing a custom navigation around another logical structure or business concept such as hierarchy of units in an organization, categories of product or any custom hierarchy was challenging. Creating a custom source for navigation and maintaining it was even more challenging as adding, moving or deleting a page must be reflected in the navigation source. Sometimes that was done by writing a custom navigation provider, manually updating a source or both.This didn't make much sense as most of the contents were already classified with terms in SharePoint 2010. Finally SharePoint 2013 solves this challenge by allowing you to create a managed navigation. The concept is simple: Build a logical hierarchy using terms that suits to your business concept and then use it for navigation. Not only that SharePoint 2013 allows you to specify the intended use of the hierarchy you create but also choose to use the same hierarchy for multiple purposes. For instance same hierarchy can be used to refine the search results. This certainly offers higher degree of flexibility without moving site content just to build navigation.

Specify an intended use for a term set

Cross site collection navigation:
Another challenge was to extend navigation beyond site collection. Site collection is a vital abstraction in SharePoint and many SharePoint features including Navigation, Security, Content Database are built around it. However that poses another challenge as most real world solutions comprises of more than one site collection for various reason from isolation, architectural boundaries and other limitations. Whatever be the reason, storing everything in one site collection isn't practical for large implementations. As navigation is confined within the boundaries of a site collection, building site wide navigation was a complex undertaking in earlier versions. In SharePoint 2013, Managed navigation combined with pinning and cross site publishing makes it possible to scale navigation beyond a site collection. Pinning allows you to reuse terms defined in another site collection. You may create a term set in authoring site collection and use that hierarchy in one or many site collections. Neat aspect of pinning is that when a term is updated or moved, it is automatically reflected at all places where it is used. Pinning was existent in SharePoint 2010 but had of little use because of the change wasn't applied automatically. Automatic update is possible in SharePoint 2013 because terms are read only when they are pinned. Pinning is also useful when creating multilingual sites using variations. Entire term hierachy can be translated in all languages used for variation labels. Private term sets Sharing of term set can be restricted only to a specific site collection by creating a local terms set. Creating global term set makes it available to all site collection connected to managed metadata service SEO friendly URLs Nice side effect of using terms for navigation is neat, shorter, extension free, SEO friendly URLs. Courtesy to managed navigation provider, URL are rewritten behind the scene.

Read More

Branding and Customization - SharePoint 2013 style!

Customizing look and style of a SharePoint site is much different from traditional web site and anyone who did brand a site earlier with SharePoint 2007 or SharePoint 2010 would quickly agree with it. One must possess knowledge of master pages and page layouts, different placeholders a master page has and the default styles a master page uses to style elements. And it always imposed a learning curve for a designer new to SharePoint world. In SharePoint 2013, branding and customization tasks are significantly simplified with the help of Design Manager. Think of it as a place to,

1. Manage branding assets - master page, page layouts, ribbon, custom components css, images, JavaScripts etc
2. Preview your design
3. Convert an entire design to html and an html to functioning design

Design Manager

Design Experience
Previewing a site in progress is the biggest addition. Not only you can preview with design manager but also with your favorite client side editor. Just map your SharePoint site ({your site}/_catalogs/masterpage/ - for instance, http://sp2013/publishingsite/_catalogs/masterpage/) to a network drive and then you are all set to design with a client side editor. Please note, it doesn't include any of master page or page layout elements. Just pure HTML. Designer can continue working on HTML and can save HTML version of the maste page. SharePoint 2013 will take care of updating your changes into master page. This enables a designer to work on SharePoint 2013 site without stepping into realm of a SharePoint developer.

View and edit master pages with Design Manager

 

Packaging Experience
All branding elements can be bundled into a single package(.wsp) and then saved to hard drive. Later this package can be imported to other site collection to give a new look. This process may sound similar to existing process in SharePoint 2010 but unlike SharePoint 2010, you are not required to add this solution to solution gallery and deploy it. Instead you just import a package using Design Manager.

Design manager let you export all customized content

Import a design package

 

You can examine the contents of the package simply renaming its extension from .wsp to .cab.

Content of exported package

  Overall I feel Microsoft did a great job by clearly segregating the tasks of developing master pages and page layouts from rest of the branding tasks and keeping them for SharePoint developer instead of designer.

Few notes:

1. Design Manager is available only in publishing sites.
2. Like earlier versions of SharePoint, you can pick any master page to start with so you don't have to start from scratch. It's always better to copy the HTML file associate with the master page so you still have original master page.Copying HTML, copies associated master page automatically for you.

Read More

SharePoint hosted Apps with "Napa" & Visual Studio 2012

As discussed in the post earlier, SharePoint 2013 allows you to write Apps which can extend the functionalities your SharePoint website provides. Primarily an App can be divided into two categories depending upon where its components reside:

1. SharePoint hosted App – Major pieces of an App are on SharePoint server with business logic and presentational pieces in form of JavaScript/CSOM and HTML executed at the client respectively executed on the client. Please note that such App doesn’t run any custom code on SharePoint server
2. Cloud hosted App – Some or all of business logic and presentation reside in cloud or on premise server different from the SharePoint server. The custom code doesn’t have to be in SharePoint or .Net, it could be anything that can be consumed through common web standards.

In this post, I am going to solely focus on how start building a SharePoint hosted app while internals of cloud hosted apps that require understanding complex multi-party authorization will be covered in subsequent posts.

Development tools that you need for building SharePoint hosted apps: “Napa” Office 365 development tools,

• If you are developing an app targeted for Office 365 environment, you don’t need to download anything on your development machine not even Visual Studio. In fact, all you need is just a standard browser and “Napa” Office 365 development tools which requires a subscription to Office 365, free during SharePoint 2013 preview. “Napa” provides you a web-based interface to author, test and deploy your Apps.

 

• If you find “Napa” web tools limiting, you may download a Visual Studio 2012 and install on your development machine followed by installation of Office Developer Tools and SharePoint client components. Visual studio allows you build your app locally and then deploy and test on Office 365 developer site. Office 365 provisions a separate web site solely for deploying and testing called developer site. You aren’t allowed to deploy your app to any other site in Office 365.

Alternatively, you may build your own development environment that hosts SharePoint 2013 preview and Visual Studio 2012 preview and other necessary prerequisites. You must also configure isolated app domain for your App (discussed below). Find more details on installation here.  

Scope and Isolated App domain: When App is installed, a separate site(SPWeb) called AppWeb is created within the hosting site often referred to as Host web. An App can be scoped at web level or tenant level. Unlike Cloud hosted apps, SharePoint doesn’t support tenant scoped apps which may contain data for multiple tenants so SharePoint hosted Apps are always scoped at web level and cannot exchange information with other apps. AppWeb has a unique address which in turn uniquely identifies an App.     When App is launched, observe the long URL in the address bar. First thing between two forward slashes and a hyphen is the tenant name when the site was provisioned. 14 digit unique identifier before the domain name (in Office 365, an address always ends with sharepoint.com) which identifies the app installation in that tenancy and make App domain unique. The content in green box is the name of the SPWeb where the app is installed. Deploying an app in isolated domain helps

• Blocking cross site scripting attacks
• Enforcing App permissions when App talks back to SharePoint using CSOM.

When using Office 365, you don’t need to worry about configuring App isolation domain as it’s already configured for you when the instance was provisioned. In next post, we will walk through series of steps to create SharePoint hosted apps using Napa and Visual Studio 2012.

Read More