P&M302 Real-life building public-facing websites with SharePoint 2013

Editor's Notes

• #2: SharePoint 2013 contains a number of new and improved capabilities for building public-facing websites. In this presentation we will walk through the different capabilities and discuss what does it mean to use them in real-world solutions.
• #4: Before we proceed let’s take a look at a quick overview of the new and improved capabilities that SharePoint 2013 offers for building public-facing websites. With SPSiteUrls we can now define multiple host headers with host-named Site Collections With Device Channels we can optimize how the website is displayed on different devices With Image Renditions we can simplify working with different sizes of images With SEO features we can optimize our website for external search engines Using the Design Manager we can build the user experience using a more HTML-centric approach With the Translation Services we can translate our content to different languages With Managed Navigation we can decouple the physical structure of the website from its navigation With Friendly URLs we can create more search-friendly URLs And finally with Search-driven publishing we can publish content from different sources on a website
• #5: In the past weeks you might have seen some demos presenting those new capabilities. Nothing wrong with that but as you know demos are built around a particular scenario which is often aligned with how the product has been designed. The interesting question is how those features work when you try to use them with different scenarios.
• #6: In the list of the new capabilities I have highlighted some of them. Does anyone know why? The capabilities highlighted with blue require Search-driven publishing to work. Image Renditions are highlighted because there are a few things to keep in mind when working with them in multi-site scenarios but more about later.
• #7: SharePoint 2013 offers two models for building public-facing websites. On one hand you can use everything you know from SharePoint 2007 and SharePoint 2010. On the other hand there is the new search-driven publishing model. In the previous versions of SharePoint the only option we had was to use the structural publishing model where the physical location of the page would determine its URL and location in the navigation. We would build content aggregations using the Content Query Web Part and the Site Collection was the boundary that we had to work with. In SharePoint 2013 next to the traditional publishing model we can use search-driven publishing. The first great benefit is, that we can use Managed Navigation to decouple the physical structure of the site from its navigation. With that we can store the content wherever we want in the site and we can even publish content stored in other Site Collections. To build content aggregations we can use the new Content By Search Web Part which not only allows us to build static content aggregations but empowers us to build truly intelligent websites (more about that in my other session tomorrow morning).
• #8: Search-driven publishing offers great benefits for building public-facing websites. First of all it allows you to separate the authoring and publishing experience. This offers you additional flexibility in configuring both environments to optimally serve their purpose. Additionally it allows you to truly embrace content-centric publishing: by creating content catalogs you can centrally manage your content and publish it to a number different sites. One of the great strengths of SharePoint 2013 Search are its analytics capabilities. With search-driven publishing you can leverage those capabilities and build personalized websites where the relevant content is displayed to users. Finally search-based publishing scales way beyond the classic publishing model what allows you to get more value out of your environment.
• #9: Although Search-driven publishing offers some great possibilities, there are a few things that you should keep in mind. Some new capabilities like cross-site publishing, friendly URLs or XML Sitemap require search-driven publishing or some parts of it to work. When working with search-driven publishing you can either have your content stored in separate catalogs or you can have it stored in the same Site Collections. When combined with Friendly URLs the latter case can have negative impact on SEO of your website as the same content will be available via two different URLs (physical and friendly). When working with Search-driven publishing the new way of building content aggregations is to use the new Content By Search Web Part. This Web Part by default uses new rendering mechanism, called Display Templates, which are based on JavaScript and are different than anything you might have known from the past. Should JavaScript be disabled on the page or there would be a JavaScript error the user would see a blank page. Additionally with Display Templates you have to take into account the browsers supported by SharePoint 2013 and verify that you won’t exclude any major group of visitors on your website. In some situations using search-driven publishing might introduce additional challenges, like when trying to retrieve related content based on some property on a page. Because the content of the page is retrieved by search it is known very late in the process what introduces additional impact on the performance of your pages. Although not obvious at first glance it is possible to use server-side XSL-based rendering with search-driven publishing. The challenge with that is however that in such case you are on your own as everything that is available out of the box uses the standard JavaScript-based rendering.
• #10: Search-driven publishing offers new scenarios and capabilities but it also offers new challenges. You can achieve great things with it but don’t expect it “just to work” for your specific scenario.
• #11: Whether you are going to use search-driven publishing or not depends a lot on your case. Either way the choice for using search-driven publishing is one of the first choices that you will have to make as it has huge impact on the whole project. First of all, on the functional level, search-driven publishing determines how you are going to organize your content: are you going to store the content in the same Site Collection or are you going to use catalogs and if so, where are they going to be located and how the publishing process is going to look like? Next you will have to decide for navigation and how that will be organized. From the technical perspective you will have to decide how many Site Collections you will need and how it will impact your solution architecture. Also, if you will need to deploy files across the different Site Collections how will you ensure for consistency once in production? Search-driven publishing offers great possibilities but for this it requires proper configuration. If you want to use search in your solution be sure that the environment will support the additional load coming from search. Last but not least, SharePoint 2013 Search is very powerful but it has to be instructed what you want it to do. The easy stuff is self-explanatory. There is however much more that you can use but first will need to learn. For the remainder of this presentation we will assume that we are using search-driven publishing to illustrate different capabilities and challenges related to that model.
• #12: One of the very cool features related to search-driven publishing is cross-site publishing, where you can have on or more catalogs somewhere in your environment and have that content published on your website. If you have seen any of the Microsoft demos recently you might have noticed that it’s often spoken of as product catalogs, but the great thing is that you can use it with any kind of structured content.
• #13: So what is cross-site publishing? It is a content publishing model based on SharePoint 2013 Search The content is stored in list or libraries Because the content is stored in a flat list in order to define its hierarchy you have to use a Managed Metadata field
• #14: When you look at catalogs out of the box you might think that it’s only for products. Partly it’s because of the Product Catalog Site Definition. In reality you don’t need to use that Site Definition at all and can use any Site Definition you want. Any list can be published as content catalog, this is including the standard pages library that you might want to use to author your content in. If you decide to use catalogs for anything else than products you will have to edit search analytics configuration for the content recommendations to work correctly. In the Search Schema you will have to edit the UsageAnalyticsId Managed Property and add to it your Crawled Property that uniquely identifies your content.
• #15: Any list or library in SharePoint can be defined as a catalog. The content is then crawled by search and made available through the Search Service Application. Because it’s based on search keep in mind that only the content (and thus not the binaries) are made available for cross-site publishing. Any assets that the content might be referring to (images, files, etc.) have to be placed in a location that is accessible from wherever the published content might be read. A sample scenario might be managing content from intranet and using search to publish it to an anonymous website on the internet. Since the intranet is not available to anonymous users you have to store all images and files somewher they can access them like in the anonymous website or in a separate assets site.
• #16: Image Renditions are one of the cool new capabilities provided with SharePoint 2013. With Image Renditions we can very easily have our images sized server-side and have SharePoint serve the small versions to optimize performance. In multi-site scenarios you are very likely to have your content stored in one Site Collection and assets in another. Should the same content be published on multiple locations this setup will allow you to centralize your assets management and maybe even improve the performance of your site. To simplify working with assets stored in another Site Collection you can add the location where your assets are stored in the Suggested Content Browser Location in your Site Collection. This will allow content authors to browse to the assets site from the asset picker rather than having to copy and paste the URL of the particular image. Similarly to other files referred to from content, in cross-site publishing scenarios, you have to ensure that everywhere where the content is published, the refered images can also be opened. One thing to take into account, particularly in multi-site scenarios, is, that Image Renditions work in the scope of the Site Collection. Image Renditions are configured on the Site Collection level and all of the UI is organized to retrieve the renditions from the configuration of the current Site Collection. However if you are reusing images from another Site Collection, what is Image Rendition ID 5 in your Site Collection doesn’t necessarily have to be the same rendition in the assets site. This will be more likely the case with multiple sites publishing and consuming content catalogs. Unfortunately out of the box there is not much you can do about this behavior. Using third party solutions however, such as the free Mavention Sized Renditions and Mavention External Image Renditions Enabler you can have Image Renditions work great in a multi-site scenario just as you would expect them to out of the box.
• #17: Another new capability, very useful for building public-facing websites, is the XML Sitemap. XML Sitemap allows you to compile an overview of the content in your site. By submitting that list to external search engine you can help it discover and index your content. Comparing to previous versions of SharePoint, in SharePoint 2013 this functionality is available out of the box. The great news is that it ‘just’ works. This is particularly great news considering how complex it is, taking into account the content stored in your Site Collection, pages with Friendly URLs and pages published from catalogs and how they are pinned in your site. To support all that the XML Sitemap is based on SharePoint 2013 Search which allows it to deal with all possible content publishing models. As for building the URLs, the XML Sitemap checks first if your site is a host-named Site Collection, and if it is, whether it has a URL associated with the Internet Zone. If it has, that host name will be used to prefix all URLs. If not, the XML Sitemap engine will try to get the URL of the Internet Zone that might be associated with the Web Application. Should that fail as well it will grab the default URL instead.
• #18: Although the XML Sitemap just works there are a few things to take into account when planning for new websites. First of all the XML Sitemap doesn’t implement all of the XML Sitemap capabilities. For example there is no way for you to define the priority or the change frequency for content on your site. Although you might argue whether it’s needed or not, the point is that should you want to use it, you can’t. What’s even worse from the platform perspective is, that the XML Sitemap is not extensible. There is no way for you to change how it works or which properties it renders. The challenge from the developer perspective is that it’s quite complicated to take into account all the different content publishing models and build a proper XML Sitemap yourself.
• #19: When using search-driven publishing one of the possible solution architectures is to use Managed Navigation and to store all of the content in the same Site Collection. In this approach you would use publishing pages and for every page you would specify a friendly URL. This would be a common approach for scenarios where you have many different pages and all of them have to appear in the navigation. The challenge with this approach is that because publishing pages are stored in the same Site Collection as where they are published, you can retrieve one and the same page using two different URLs. With this there is a risk of external search to crawl the same content using two different URLs what might result in the page rank being split in half.
• #20: One of the great capabilities of the search-driven publishing model is the REST API that allows you to easily publish the content to other systems or apps. It’s very flexible in configuration and allows you to truly reuse your content across the different areas. It’s disabled for anonymous users by default so if you want to use it you would have to enable it first. It’s not very complex and I wrote about it on my blog. The great thing that you can not only flip the switch but can control in a pretty granular way which features of search may be used through the REST API. Those features are controled using a white list so everything else that isn’t defined there isn’t allowed. REST API is not only great for publishing content through search to other system. One common usage scenario on public-facing websites is to display some related content where the relation is based on one of the properties of the current page. By default SharePoint allows you to retrieve the content related to the value of a token in the URL, a query string parameter or the value of a property of the current publishing page. If the current page is coming from a catalog however, the value of the particular property is known very late in the process making it impossible for you to retrieve related content. In such case you can use the rest API to retrieve the related content. A sample usage for this scenario can be seen on the mavention.com website where we load blog posts written by the selected person.
• #21: One of the big changes in SharePoint 2013 is how content is rendered. When using search-related Web Parts, the default rendering is based on JavaScript. In fact all of the standard functionality uses this rendering model. The JavaScript rendering model is based on Display Templates that define how the particular piece of content should be rendered. SharePoint 2013 contains quite a few Display Templates out of the box so you can see how they work and you can build great dynamic experiences using Display Templates. There are however a few things for you to keep in mind when designing your new public-facing website on SharePoint 2013. First of Display Templates are based on JavaScript. Should JavaScript be disabled in the browser or should there be an error, you will see an empty page. The engine behind Display Templates is new so will have to invest some time to get familiar with it. Another thing that you should keep in mind that Display Templates use SharePoint plumbing which is supported not by all browsers, for example IE7 or IE6 are not supported anymore. While this might not be an issue on an intranet, you should pay a close attention to the browsers used by the visitors of your website. In some markets IE7 and even IE6 are still very frequently used. On those older browsers your new site might break and there is not much you will be able to do about it. The alternative? Although it’s not obvious from the UI SharePoint 2013 uses in certain scenarios a fallback rendering mechanism which is server-side and based on XSLT. One sample scenario is using this mechanism when rendering content to search engines. A great benefit is that there are no browser dependencies so you can use this mechanism to fully control your markup. The biggest downside it, that should you choose this path, you will be on your own. There is very little functionality available out of the box in the server-side rendering mode and you will find yourself developing new stuff very quickly. This is by the way the rendering model that we are using on mavention.com mainly to comply with the Dutch accessibility laws.
• #22: In the last few years the usage of mobile devices on the internet has increased. According to some researches by 2015 more mobile devices than desktops will be used to surf the web. With that you just can’t ignore the mobile market on the Internet. There are a few ways in which you can ensure that your content is user-friendly on mobile devices. One of them is to optimize how the content is displayed. In SharePoint 2013 this can be achieved either by using responsive web design or using the new capability called Device Channels. Responsive Web Design has nothing to do with SharePoint and uses CSS media queries and optionally JavaScript to control how the website is displayed on different screen resolutions. The important thing to notice is that despite the device used, the same HTML is served. On the other hand SharePoint 2013 offers us the Device Channels capability that allows us to define a number of channels and link them to some devices. For every channel we can use a different Master Page and within Page Layouts and custom controls we can use Mobile Panels to determine what HTML should be served on the particular channel. Search Engines recommend Responsive Web Design to build websites optimized for mobile devices. Because for every single device the same HTML is served they only need to crawl and index your website once and can be sure that on every device the same HTML will apply. One thing to take into account about responsive web design is that it depends on CSS media queries which are not supported by some older browsers. In such cases you might need JavaScript and even then you might find that responsive web design is too limiting to fully optimize your website for mobile. Device Channels are based on device management: there are a number of devices that you ‘support’ and those are mapped to channels – buckets that determine how the website is displayed. For every channel you have control about the output HTML so you can apply more optimizations than when using responsive web design. When doing so don’t forget to use the Vary-By User Agent response header to let search engines know that different HTML is served to different browsers. Aside from optimizing the cross-device experiences, Device Channels can be also misused for separating the authoring and the publishing experience: something that we have done on mavention.com.
• #23: If you built a website in SharePoint 2010 all of your content was stored in the content database. The only exception was taxonomy should you use any. In SharePoint 2013 the situation is a little different as there are more moving parts. First of all the content can be a part of the publishing site but it might be as well coming from some other repository. SharePoint 2013 allows you to configure search settings in your Site Collection. Although it’s not clear from the UI, those settings are not stored in your Site Collection. They belong to the Search Service Application and should you lose it, you will lose your search settings as well as all the analytics data such as recommendations and reports. Another thing to take into account is moving sites that use catalogs to different URLs. Those connections are URL-based, so if you move the site to a different URL you will need to remap those connections. As you can see in SharePoint 2013 there are more things to take into account when planning for availability of your website. Don’t underestimate it and definitely practice restoring your site.
• #24: There is no doubt that SharePoint 2013 offers great added value for building public-facing websites compared to its previous versions. The new capabilities also introduce new design concepts and new impact that you should take into account when planning and designing for new website. Eventually I’m sure you will all achieve great results using SharePoint 2013 to build public-facing websites.