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.
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.
I just got back from Microsoft’s internal Ready conference in Seattle, and one especially inspiring session was about Professional Networking by Kevin Martins and Matt Soseman. I’m still digesting it all, but one thing Matt said stuck with me: he suggested blogging the answers to questions you get over and over. When someone asks, you can point them at the article.
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.
Some readers may already know that Scot Hillier and I are presenting an Office Developer Bootcamp focused on the SharePoint Framework on Friday, October 27, 2017 at the Microsoft office in Burlington MA. This is a great opportunity to learn SharePoint Framework development, including related technologies, Typescript, WebPack, and React. There are still openings, and it’s free! Please register here to join us!
I’m pleased to announce that we have some great sponsors for this event. Not only will they ensure that attendees are well fed, they were hand-picked as they bring key technologies that every SharePoint developer should know about!
Colleague and fellow SharePoint developer Brian McCullough asked a great question on Twitter:
This is such an important topic I thought it was worth more than a 140-character reply; hence this article. Whole books have been written on Application Lifecycle Management,and there are many facets beyond simple software deployment, but this article will focus on the baseline needs of a typical “widget” project:
- Allow reliable and repeatable movement from a development environment to test and ultimately into production potentially across dozens or thousands of SharePoint sites
- Support this not just once, but repeatedly as project versions are developed and released. If the project includes persistent data, this should be preserved (and perhaps enhanced) as part of the upgrade process
In a widget project, each “environment” may just be a couple of site collections; for example you could have site collections for dev, staging, and production all in the same tenant on farm. Since widgets run on the client side, there’s no need for them to interfere. If you’re on Office 365, you might want a First Release tenant to test your code with forthcoming updates to the platform while keeping your main staging and production environments on the standard release schedule.
or, Avoiding the BLOB (and other) caches in SharePoint Online
SharePoint was designed to work best in relatively small farms on premises. A typical configuration has 2-4 web front-ends, so caching information on the web servers is a good strategy. In SharePoint Online, however, a typical farm has hundreds of web front-ends, and is shared by many tenants. As a result, the chance of finding cached content for any given tenant on any given server is greatly reduced, and server side caching is ineffective. That changes some key best practices for building SharePoint portals; in Office 365, it’s best to avoid SharePoint features that rely heavily on server-side caching.
An excellent session at Microsoft Ignite, Learn how to build a fast, responsive SharePoint portal in SharePoint Online, focused on this and other performance considerations in SharePoint Online. This article will call out key best practices to optimize portal solutions hosted in Office 365.
This week Microsoft mapped out a bold new plan for SharePoint. Microsoft is investing heavily to modernize the product to make it work as well in the Device and Cloud era as it once did in when the Web was still shiny and new. This article will explain how these changes could affect your organization’s SharePoint plans and how you can start preparing.
If you missed the announcement, this is a good place to start. Here are some of the highlights: