Prepare:http://notvention.comNotvention HTML templatesOpen notvention2.com Master Page Gallery in Explorer
SharePoint 2013contains big improvementswithregardto building public-facing websites. In the past monthsyoumight have seensomedemos presenting those new capabilities. Nothing wrong withthat but as youknowdemos are built around a particular scenario which is oftenalignedwithhow the product has been designed. The interesting question is howthose features workwhenyoutrytobuild a real-life public-facing website.
Building good public-facing websites is not trivial yet possible with SharePoint 2013. Let’s watch a short video that might give you a better idea of what you will end up with if you just start building things without considering a few things.
So how often were you asked to build that…
…and you took that…
…applied some of that…
…to achieve something like that…
…while what you were really asked to build was this?
To illustrate what the result is when building public-facing website using just the standard tools and approach I’ve built the notvention.com website. We will have a closer look at it when discussing the standard workflow for building public-facing websites.
One of the big changes with regard to building public-facing websites is the Design Manager. Design Manager offers you a simple flow for implementing custom user experiences in SharePoint. The way it works is that you first build your static HTML templates, upload them to the Design Manager which then converts them to SharePoint Page Layouts and Master Pages.While converting your templates Design Manager will add stuff to the generated Master Pages and Page Layout. With that you will end up with HTML that isn’t valid and which might make it difficult for you to implement the UX correctly.When extending the generated Master Pages and Page Layouts you can use snippets from the snippet gallery. This might be helpful but only as long as you’re using stuff available out of the box. Snippets Gallery is not extensible and with that, should you need to use custom controls, you will need to generate the awkward Design Manager markup yourself.When building Master Pages and Page Layouts with Design Manager you will be working on an intermediate format. While you will be making your changes in an HTML file, Design Manager will be converting it to a SharePoint Master Page or a Page Layout. With that it is quite inconvenient to debug things should they be wrong as it’s not always easy to track back why the generated Master Page and Page Layouts contains some stuff that isn’t there in your HTML files.To recap: Design Manager is a new way to write the old code. What we need in real-life is better and cleaner code and to be able to implement our HTML. While Design Manager could be helpful if you have no experience with SharePoint whatsoever, if you have worked with SharePoint in the past and you want to build a great public-facing website you will probably use a different approach and craft the Master Pages and Page Layouts yourself.
Notvention2.comUpload templatesConvert Master PageShow XML errorShow added stuffNotvention.comCompare page sizeShow sourceShow issue with in-attributecontrols
Search-driven publishing is a new content publishing model based on SharePoint 2013 Search. Having your content indexed by SharePoint 2013 Search you can then have it published on one or more websites in your Farm.Search-driven publishing offers great benefits from the content reuse and publishing flexibility point of view. There are however a few things to take into account.First of all Search-driven publishing is required for some of the new features, such as XML Sitemap, Managed Navigation or cross-site publishing. In other words: if you want to fully benefit of what SharePoint 2013 has to offer for public-facing websites, you need search-driven publishing.Once you choose to use search-driven publishing you will need to stop using the Content Query Web Part and use the Content Search Web Part instead. By default the Content Search Web Part uses client-side rendering. While it might seem all great and dynamic at first, you should take a closer look at how things really work.There are also other considerations that we can look at using our example notvention.com website.
When using client-side rendering, the Content Search Web Part retrieves the data from SharePoint 2013 Search and includes it as a JSON string in the HTML source of the page. From there it is rendered using Display Templates. Unfortunately that raw JSON string contains internal information such as the URL of your authoring site or account names of users. As you can imagine this is not something you might want to share on the Internet. Just look for some public websites and search the source for the OriginalPath property or for OWSUSER and see for yourself.Another thing that you should take into account is the fact that currently Internet search engines have limited support for JavaScript. Because of this Content Search Web Part detects whether the page is requested by a search crawler and if so it renders its contents using XSLT instead. Unfortunately, by default, this rendering doesn’t use your HTML and you end up with an ugly markup missing precious SEO content.
Another great improvement for build public-facing websites in SharePoint 2013 is Managed Navigation. Using the Managed Metadata Service we can model sites navigation decoupling it from the physical structure of the website. This allows us to optimize the website for public visitors and at the same time implement the content management process the way it’s understandable for the content management team.
Managed Navigation is maintained using the Term Store Management Tool. Unfortunately, it’s a generic tool for working with taxonomy and not managing site’s navigation. As a result many customers find it confusing what a ‘term’ has to do with a ‘menu item’.Term Store Management Tool leverages AJAX calls. Unfortunately, if you use different options too fast, and don’t allow for things to load, it can break your navigation settings.Challenges:- Canonical URL- Insert link from SharePoint- Related resources- Creating subpagesCombining reused terms from catalogs with websites navigation
More and more mobile devices are being used to surf the web. With that you cannot afford to ignore them and your website has to be optimized for display on mobile devices.For public-facing websites built in SharePoint 2013 there are basically three ways to optimize them for mobile devices: we can use responsive web design, Device Channels or a combination of them. Additionally we could build a whole separate mobile website or a companion app.Responsive web design is the approach that Google recommends as it simplifies their indexing process. Additionally it lessens the effort required to build a website. A downside that you could think of is that every single device retrieves the same HTML which might not be suitable for every scenario.Another alternative is to use Device Channels, either or not combined with responsive web design. While the ability to send different HTML to different devices sounds great at first there are a few things that you should consider. First of all Device Channels work based on User Agent substrings. With that, you will do device management if you choose to use Device Channels. Should a new device appear on the market that you would like to target you would need to check if it’s matched by your User Agent substrings.Another thing worth noting is that if you decide to serve different HTML to different devices you have to let Internet search engines know of this. This can be done by adding the Vary: User-agent response header. Unfortunately, given the magnitude of different browsers and operating systems, often proxy servers treat the Vary: User-Agent response header as Vary: * which prevents them from caching the output.
When implementing responsive web design in SharePoint using Design Manager you have to keep in mind that Design Manager doesn’t support media queries on link tag. Instead you have to incorporate them into a single CSS file.
In the past moving websites between environments or recovering them was straight forward. All you needed were your WSPs, installation scripts and a backup of the content database. In SharePoint 2013 however things are a little more complex. Besides the WSPs, installation scripts and the backup of the content database you also need to plan for moving the Managed Navigation which is stored in the Managed Metadata Service and you have to take into account search settings. Because even though they can be configured at the Site Collection level they are in fact stored within the Search Service Application at Farm level.Additional attention is required for catalog connection when working with cross-site publishing in DTAP environments. Often in DTAP different URLs are used for the same site in different environment and as the catalog connection uses site’s URL it has to be changed every time you move your site from one environment to another.
Towrapthings up- There are no shortcuts- Don’tjustuse stuff becauseit’sthere- Understand the capabilities but also the limitations- Buildgreat websites using SharePoint 2013