Next post in this series >

Introduction

I’ve spent some time over the last few weeks doing an impact assessment of moving to the new(ish) ‘Modern UI’ in SharePoint Online. I looked at it primarily from a technical angle so that my client can decide whether to adopt it now, based on the constraints of the current technology. The conclusion I reached was that it’s not quite ready yet.

This post isn’t an attempt to bash Microsoft or poke holes in this functionality. I actually think the Modern UI is great, and completely the right direction for Microsoft to take things. But for me, it’s not quite an ‘enterprise-ready’ product yet. Hopefully this post helps other customers out there facing a similar dilemma, or at the very least frames how you can do your own assessment of whether or not to ‘go Modern’.

The post ended up getting pretty big, so I’ve split it into two parts:

1. Part One: Introduction, assessing compatibility for existing sites, and assessing constraints for future work; and
2. Part Two: Benefits of the Modern UI, and options/recommendations for how and when to adopt it.

What is the Modern UI?

Microsoft have been introducing the ‘Modern UI’ for sites in SharePoint Online over the last year or so. This new functionality provides a better user experience, cross-device compatibility, better integration with other products in the Office 365 suite (namely, O365 Groups), and a 24 TB increase in total storage space per site.

It surfaces at three ‘levels’:

• Modern Sites, in the form of Modern Team Sites (AKA Group Sites) and Modern Communication Sites;
• Modern Lists and Libraries; and
• Modern Pages.

Above: A Modern Page on a Modern Site

 

Above: A Modern Library within a Modern Site

However, Modern UI offer some drawbacks around the customisations that can be achieved. These constraints will directly affect how, where and when the Modern UI can be adopted within many organisations’ Office 365 environments.

Process for Assessing the Impact of the Modern UI in Your Environment

When I was looking at if/when the Modern UI should be adopted and rolled out in my organisation, I undertook four steps, which I will detail in this blog post. At a high-level, these steps were:

1. What compatibility problems (if any) are there for existing sites in SharePoint Online, and what do we need to do to address them?
2. What compatibility problems are there that may constrain or alter the approach for future design and development work, and how might we address these problems?
3. What requirements/use cases are there that mean moving to the Modern UI provides benefits to either the business or IT?
4. What options do we have for if/when we roll out the Modern UI, what are the pros/cons of each, and what is our recommendation?

As mentioned above, Steps 1 and 2 will be covered in this first post; Steps 3 and 4 will follow in a second post.

Step 1 – Assess Compatibility with Existing Sites

Before moving to the Modern UI, you are going to need to look at how it plays with any existing sites you have in your Office 365 tenant. There may be bits of customisation and configuration that preclude certain sites or lists from becoming Modern, and mean that you need to do some remediation work or plan for leaving some sites/areas behind in the Classic configuration.

To help with this assessment, the PnP (Patterns and Practices) team at Microsoft have provided a really excellent tool called the ‘SharePoint Modern UI Experience Scanner’. There are some solid instructions in the GitHub repository that even a plebeian like me could understand and follow, so you shouldn’t have too many difficulties getting this up and running in your environment – provided you have an admin account to set-up an app-only principle with tenant permissions.

The UI Scanner trawls through every site on your tenant and outputs a whole raft of CSV files at the end of it. These CSVs provide information on incompatible customisations and configurations at both the site level and the list level. I created a Power BI report to make the information a bit more human-readable, but you can achieve something similar in Excel (or draw your own conclusions straight from the CSV, if you don’t need to represent an impact assessment to a broader audience).

My tips to get meaningful information out of the reports are as follows:

Site-Level Customisations

IgnoredCustomisations.csv is the high-level report that tells you sites with custom Master Pages, custom CSS, or Custom Actions. These things are currently incompatible with the Modern UI.

My top tip for this report is to make sure you filter out any Publishing sites, i.e. stuff that is related to your publishing intranet rather than being a collaboration space. You might be able to do this via something as simple as which managed path a site resides under (/teams or /sites), but you may need some slightly more complicated logic to weed out the irrelevant stuff. The Modern UI cannot be used on Publishing sites anyway, so they’re kind of irrelevant for a compatibility report.

It’s also a good idea to find a way to call out any sites with no issues, so you have a clear way of knowing which sites you don’t need to refactor to get them working with the Modern UI.

My Power BI Report for Site-level customisations ended up looking like the below:

List-Level Customisations

The ModernListBlocked.csv file provides a whole heap of information about compatibility issues that might prevent you from switching on the Modern UI in certain lists/libraries. These issues fall into two broad buckets:

1. Out of the Box Issues: Areas where things outside of your control mean that the Modern UI is not available for this list/library. This includes stuff like the base list template being incompatible; the view type being incompatible; or an unsupported field type (such as geo-location fields).
2. Customisation Issues: These are areas where you, foolish developer, have caused a compatibility problem by customising something on a list or library. This includes stuff like custom list actions; JSLink; XSL; or multiple web parts added to a list view page.

I’ll discuss these limitations in much more detail in the next section, as they all need consideration, but for the purposes of assessing compatibility with your existing estate, my top tip for this report is to, again, find a way of filtering out the irrelevant publishing sites. A second tip is to find a way of categorising the type, or base template, of the list for each row. The report provides this in the format of a list base template identifier (e.g. 107, 108, 120 etc. etc.) from which you can infer the actual list type. For example, 104 is an Announcements list, 105 is Contacts, 106 is a Calendar, etc.

My Power BI Report for List-level customisations looked like the below:

How do I Upgrade?

Enabling Modern

Before you can think about when/where to upgrade, you need to enable the Modern UI on your tenant. This is simple to do, but has the potential to create a massive pain in the a**. Enabling the Modern UI is like an on/off switch. You can’t enable it at a more granular level, only across the tenant. This means you need to then script a downgrade for classic to any sites with compatibility issues, and for any sites you need to provision as Classic Sites. This is a massive pain in the neck. Once Modern is enabled (and you’ve disabled it wherever you need to disable), you can do the following:

Creating a Site as Modern Natively

Obviously, this isn’t an upgrade, but it’s worth noting here that new sites can be created as Modern natively. That said, read on to find out some of the constraints you have around provisioning Modern Sites, and other limitations you’ll experience once the site is up and running! This applies to sub-sites as well as new site collections.

Upgrading an Existing Classic Site

To upgrade an existing site in the classic configuration, you will need an admin to run a PowerShell script. This can be done against one or many sites.

Before doing this, you should – of course – have followed the guidance I outlined above around assessing the compatibility of your existing sites with the Modern UI. You might find that you need to do some remediation work before you can run any scripts.

Upgrading an Existing Classic List/Library

There are a few options as far as upgrading lists/libraries to the Modern UI goes:

1. Administrators can set the default list experience for the whole Office 365 tenant.
2. Site owners can switch lists and libraries to the Modern UI on a case-by-case basis.
3. Administrators can run a PowerShell script to programmatically change the default list experience, or upgrade individual lists across a site or many sites at once.

Again, keep in mind that fact that many list types are not compatible with the Modern UI.

Upgrading an Existing Classic Page

Unfortunately, it is not possible to upgrade a Classic web page on a SharePoint site to Modern. Pages will need to be recreated as Modern Pages.

Recommendations for Remediating Existing Sites

If you’re finding lots of team sites, project sites or other collaboration spaces with custom CSS or master pages, you should consider changing these to something more generic. The general guidance extolled by Microsoft and SharePoint experts for the last couple of years has been to avoid doing these types of customisations to collaboration sites. However, in the real world, organisations usually want – at the very least – a consistent global navigation experience with the rest of their intranet/SharePoint environment. Unless you’ve kept your SharePoint environment extremely vanilla, it’s likely you’ll have some quite extensive work to do here to get these sites ready to go Modern.

As for lists, it’s unlikely that there will be any sites that don’t have at least a couple of lists with compatibility issues. This is due to the lack of Modern UI support for some very common list view types and base templates. But for lists with customisation issues, you should look at how feasible it is to tweak these, keeping in mind that support for some of the things that cause issues with Modern Lists at the moment is coming down the pipeline.

Step 2 – Assess Constraints for Future Design and Development Work

The next step I recommend is to familiarise yourself with where and how the Modern UI constrains what you want to do in the future. To help with this, I’ve looked at a variety of things an organisation might want to do with a SharePoint site, and compared the capabilities in Modern to the existing capabilities in Classic. For anything that the Modern UI does not yet support, I’ve included a bit of detail I’ve gleaned from Microsoft’s Public Roadmap (or bits I’ve inferred from supporting information around the roadmap).

It should be noted here that this blog post is correct at the time of writing (July 2017), in terms of the items on the roadmap and where the gaps are, but it will likely become out of date. I’d also say it’s highly unlikely I’ll maintain the blog post going forwards, so I’d suggest doing some of your own research around the roadmap if you’ve come across this post more than a few months after its initial published date. But

The areas I consider are as follows:

• Provisioning: How sites can be programmatically created to enforce consistency of structure, look and feel, information architecture etc.?
• Branding: How can a site be configured to look and feel the way a business wants it to?
• Custom Pages: What are some of the constraints around editing custom pages on a site?
• Site Management: What needs to be kept in mind for the management of existing sites, in terms of settings, configuration, and adding new areas to the structure?
• Site Discovery: How is the discovery/findability of sites impacted by the Modern UI?
• List Views: What compatibility problems are there for specific types of list view in the Modern UI (building on what I alluded to in the compatibility with existing sites section)?
• List Customisations: What customisations can you make at the list level?

In addition to the areas I’ve considered below, there are a few extra specifics in this article from Microsoft: https://support.office.com/en-us/article/Differences-between-classic-and-new-experiences-for-lists-and-document-libraries-30e1aab0-a5cc-4363-b7f2-09e2ae07d4dc?ui=en-US&rs=en-US&ad=US

Feature Gaps and Constraints

Provisioning

While Modern sites can be created programmatically as part of a provisioning process (including all the content types and metadata fields that are required), you have no way to make the homepage of the new site look how it needs to without human interaction. Currently, you must add a new app to a newly provisioned Modern site manually, unless you create some sort of hacky UI-based execution, which has significant risk attached to it if Microsoft make updates.

Branding

Options for branding Modern sites are extremely limited, though further options akin to Master Pages and custom CSS are being rolled out as I write, and should hit General Availability (GA) in the next few months. The key takeaway here is that Modern Sites/pages will not look like the rest of your SharePoint environment if you have customised it in any way, and it is currently impossible to make them fit in look and feel-wise.

Update Sep 2017: The SharePoint Framework Extensions (the things that give you the ability to add custom Global Nav and brand a Modern Site) are now out of preview and available on first release tenants.

Custom Pages

The types of Modern Page that can be created are relatively limited, though the pages themselves are much easier to use for both end users and editors. It is also worth noting that Modern Web Parts are Microsoft’s clear strategic direction, and should become the de facto way in which custom web parts are developed in your organisation. If you’re not adopting the SharePoint Framework (SPFx) wherever possible for custom web part development, you are creating a bigger and bigger backlog of legacy stuff that will eventually need to be refactored.

Update, Sept 2017: All Modern Pages (across both Group Sites/Team Sites and Communication Sites) can now change their layout to various choices. This is actually really nicely implemented, and a lot more flexible than the old page layouts and web part zones on classic pages.

Site Management

Modern Sites are currently only designed for collaboration (team/project site) scenarios, not web content management.

There are also issues with sub-sites created beneath Modern Sites, in that the homepage of the Sub-Site will be Classic, not Modern. This is a biggie for me, as it creates terrible inconsistency and is very confusing for site owners. Again, this is something that could possibly be addressed with a bit of a hack, but that’s not an ideal solution, or indeed a supported one.

Site Discovery

Modern Sites/pages can be rolled up and presented in much the same way as Classic sites/pages, though some tweaking of the current configuration of your Content by Search web parts may be required. Also worth noting here is that it is not possible to capture metadata for a site in the property bag of Modern Sites. Some custom applications will have previously utilised the site property bag (rather than tags on pages or hiding properties away in some sort of site configuration list) in order to classify a site for rollup/discovery purposes when surfacing it through search. This is no longer an option, and if you’ve done this, you might have some serious remediation work on your hands.

They can also be attached/created as part of a new Group/Team to provide a more seamless interface with these other services in the Office 365 suite.

List Views

Some core list functionality does not work in the Modern UI, including Gantt and Calendar views which are widely used on collaboration spaces (at least in my experience). This means there will be a fragmented user experience if the site is Modern, but the list remains in classic mode. Something you must accept in the Modern UI is that there will – for the time being at least – be a degree of jumping around between Classic and Modern layouts as you move between lists. This has knock-on effects for training guidance and collateral, which must be kept in mind when you’re assessing the impact of the Modern UI (more to come on this in the next post).

Additionally, there are several field types that don’t work in Modern lists, though these are unlikely to affect the majority of sites.

List Customisations

Lists with customisations generally do not work in the Modern Experience. However, Microsoft are rolling out the ability to add more customisations to the Modern Lists experience as we speak.

Microsoft’s Roadmap

Stuff That’s on the Roadmap

So this is a summary of the things that are on Microsoft’s current public roadmap, or at least alluded to as part of the collateral supporting related roadmap items.

Update, Sept 2017: As noted above, the ‘Injecting Content’ item is now out of preview and available to first release tenants.

Stuff That’s Missing from the Roadmap

This is a summary of constraints that aren’t on the roadmap to be addressed by Microsoft:

Wrapping it Up

So that’s it for Part One of this two-part series. It’s been slightly one-sided so far, but in the next post, I’ll cover off the benefits of the Modern UI, and options/recommendations for how and when to adopt it in your organisation.

Thanks for reading.

Next post in this series >