Modern SharePoint is catching on, and sites are looking better than ever right out of the box. With mobile-ready pages and easier editing, customers and partners are starting to ask for it. And as SharePoint 2019 brings the modern experience on premises, the demand is likely to grow even more.
Yet even as sites look better than ever “out of the box”, there are constraints on how they can be customized. Partners and customers who want to completely change the look sometimes run into these boundaries and get frustrated.
This article is the sequel to Swooping into SharePoint Site Designs, in which I related my experience working behind the scenes on the world’s first SharePoint reality show! This time I’ll explain the code so you can build similar solutions if you so desire.
The sample shows how to build a site design and script for a simple department site, as created in the SharePoint Swoop video. A team of experts worked to redesign an Intranet site in just three days. This site design was developed behind the scenes to provide a template for all the company’s department sites.
A few months ago a group of SharePoint MVPs gathered to film a new kind of reality TV show and remake a company’s Intranet. You may have seen it – SharePoint Swoop!
This is a story from behind the scenes,in which I got to make their work reusable with SharePoint Site Designs and Scripts. It was quite a thrill to be involved, even though I wasn’t there in person! I’ll start with the story, then dig into the details of Site Designs and Scripts.
Traditionally, our collaboration tools have been divided into silos based on the mode of communication. In the Microsoft space, we’ve used Outlook and Exchange for persistent messaging, Skype for Business for real-time communication, and SharePoint to provide a place to share documents and other information.
These tools work together to provide for our communications needs, whether they’re real-time, message based, or documents and other content. They work well together, but they’re still separate programs we have to run, and constantly flip between. As we do, the information is organized differently in each tool: most of us view email by date, Skype by person, and SharePoint by project or team. That’s a lot of context switching. Of course we’re all used to this, and probably don’t even notice how much of our attention goes into it.
A lot of people have asked for “private channels” in Microsoft teams. Microsoft has stated publicly that they’re working on it; there’s even a page in the documentation all ready for when it comes along!
In the meantime, a question came up about using SharePoint permissions to restrict the level of access to channel files. Recall that every Team has a SharePoint site, and the files in the Files tab land in a document library on that site. Each Teams channel gets a folder in that site. (For more details see this article by Matt Soseman.)
So is it possible to make a “semi-private” channel by simply modifying the folder permissions in SharePoint? The idea is that while the conversation might be open, the files are only available to a subset of team members.
This article builds on an earlier one, Building Headers and Footers that work on Classic and Modern sites. That article, with associated sample code, was about how to create a top menu and footer that work on both modern and classic SharePoint pages. On modern pages, the solution is a SharePoint Framework extension; on classic pages, it’s a stand-alone solution that just happens to use SharePoint Framework tooling like TypeScript, WebPack, and React. That allows a very high degree of common code between the classic and modern implementations.
The good news is that my POC was successful, and the partner and their customer liked it!
The sample code has moved! It’s now in the SharePoint Framework Extensions repo.
I skipped over one key capability in my project, which was localization. The customer in this case is a large multi-national company, so it’s not too surprising they would want to show some information in the user’s preferred language.
I just read and reviewed 250 conference submissions and boy are my eyes tired! There were a lot of excellent submissions, and it will be an awesome conference for sure, but that’s not what I want to talk about. I want to talk about the submissions that I didn’t recommend, the ones that missed the mark in some way that might easily have been improved.
One of the partners I consult for is migrating a Fortune 500 financial services company to SharePoint Online. The company wants to take advantage of modern team and communications sites, yet where they need features that aren’t available in modern SharePoint, they’ve decided to stick with classic Publishing sites.
The challenge is: how to build global navigation and footers that will work on both classic and modern sites. There are a few reasons this is important:
- It provides common navigation across all kinds of sites, making the Intranet easier to use
- It provides a common footer across all kinds of sites, ensuring compliance messages are delivered consistently
- It reduces coding and maintenance, because one set of code is used across old and new sites
So I undertook a little Proof of Concept, and here are the results. The solution is usable as-is if your needs are simple. The real intent, however is to prove out a pattern for developing any header and footer that will work on both modern and classic sites.
The question I get the most these days is, “what is this modern SharePoint you keep talking about?” It might sound like an oxymoron! All my SharePointy friends know about it, and debate the finer points over beer at SharePint, but to the casual user, or someone who’s been working on premises, it may be a bit of a mystery. It’s only available online (at the time of this writing anyway), and is slowly being phased in as developers build it out.
So here it is: Microsoft is on a mission to modernize SharePoint, to save it from fading into obscurity as a once innovative but now persnickety old war horse of a product. This article will explain how they’re doing it, and why you might want to take a fresh look on this stalwart collaboration product.
Client-side solutions have been de rigueur for a few years now: they’re cloud friendly, and are generally much easier to deploy than server-side code. SharePoint is an enterprise class content management tool, so it’s only natural to store the client code in SharePoint. That was all well and good until Office 365’s large farm sizes rendered SharePoint’s BLOB cache useless, which makes loading static files much slower online than on premises.
So lately Microsoft has been encouraging – and helping – us all to use a proper Content Delivery Network (CDN) for static content. CDN’s are designed for speed and volume; they even address the speed of light problem by fetching files from a data center that’s near the client. This will help your client-side solutions to load noticeably faster, as seen in this chart.