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.
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.
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.
Companion article to my session at Microsoft Ignite 2017
Thanks to everyone who attended my session at Microsoft Ignite 2017, Building Compliant Team sites (THR2057). For those who missed it, here is the recording. This article provides links to resources and additional details.
The talk was about how enterprises can manage modern SharePoint team sites in a way that makes compliance easy.
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.
In economics, a widget is a name for a generic gadget or manufactured good; on the web, a widget is a generic piece of web functionality running on a page. What makes widgets special is that, unlike controls in ASP.NET or directives in AngularJS, widgets are generally released separately from the web page that hosts them, and are often deployed by end users.
If you’re reading this blog, you probably know something about Microsoft SharePoint, and this might sound familiar. A widget is a lot like a web part, only much lighter weight. In fact, widgets can easily be hosted in content editor web parts, on a list form, in a SharePoint add-in, or outside of SharePoint. If you’re careful, you can reuse the same widget in all those contexts!
The mathematics of music isn’t as simple as you might think, and early musical instruments often didn’t get it right. Keyboard instruments were especially susceptible to this. On a particular organ, for example, the fifth interval in the key of C might sound harmonious, but the fifth above Ab might be sour and grating to the ear. These so-called “wolf” notes could spoil a whole composition. It wasn’t until the late 17th century that “well-tempered” instruments came along, a fact that was celebrated by J.S. Bach in his solo keyboard composition, “The Well-Tempered Clavier,” which includes harmonious preludes and fugues in every possible key.
Like notes on a piano, web parts (or any kind of web widgets) are combined in new and unexpected ways on a page. Yet sometimes they don’t play well together. This article will show you how to write “well-tempered” web parts that always behave appropriately, even if other versions of Angular are used on the page.
This article is reposted from my old MSDN blog. Please post comments here as I am no longer able to publish or respond to them on MSDN. Thanks!
Microsoft is cleaning house. Now that it has to maintain SharePoint for thousands of enterprises and millions of users in Office 365, Microsoft is working to clean up all the odd and messy bits of its flagship collaboration product. In a recent training course on Microsoft Virtual Academy, Microsoft urged developers to change the way they package and deploy their code in order to clean up a mess that has been building since 2003.