All Mod Cons

It’s a Modern World

Unless you’ve been burying your head in the sand for the past 18 months or just too busy supporting a SP2013/16 deployment to lift you head above the parapet, you can’t help but notice that SharePoint has changed. More accurately SharePoint Online has changed in that it now supports a new UI or User Experience (UX) as the Microsoft marketing team prefer us to call it. And the name of this face-lift; “Modern”. Personally, I think that this is a silly name because what do you call the next gen UX, “New Modern”? Still, I suppose it is an easy term to get to grips with and Microsoft gives us a partner term called “Classic” to help us distinguish between the 2 UIs, sorry UXs!

Modern used to be the solely the purview of SharePoint Online/O365 but with the mid-life upgrade or SharePoint 2016 and the soon to be released SP2019 it is now something that those with on-prem deployments of SharePoint should consider, or at the very least be aware of. One thing is clear, Microsoft is pushing Modern very hard and whilst they are adamant that Classic is not going away, it seems likely that little or no new investment is going to be made in Classic. So, although no one has dared to say it, Classic is, or at least is soon to be, deprecated! A cold shiver came over me as I wrote that last line.

In this article we’ll take a quick look at what Microsoft has done, why they have done it and what the implications are for you and for me.

So, what is this Modern thing anyway?

I guess we’d better start out by explaining what Modern is. Well, it’s really just a presentation layer that sits on top of the same back-end architecture but it uses client-side components to make the UX contemporary, minimising evil post-backs and supporting Responsive Design so that UI adapts the layout according to the constraints of available browser real-estate. In other words, it gives SharePoint a fresh lick of paint and proper support for users on smart phones.

That’s a little unfair because it does add some really useful and long asked for enhancements to the mix as well. These includes a new way to apply conditional formatting to columns and views, the ability to apply property updates to multiple items at the same time and my favourite, automatic trimming of multi-line text columns to a decent size so that when someone writes a 3000-word essay in a description column it doesn’t totally screw up the layout of the page when items are presented in a list view. The UI is leaner and cleaner and gone are the Ribbons, Callouts and Dialogs, although I for one will be sad to see their passing

Why do we need Modern?

It is true that the UX of SharePoint 2013 is now looking a bit dated. And, having now worked with SP2016 and taken a peek at the pre-release of SP2019, I am convinced more than ever, that no more development effort is going into Classic because it has basically not changed at all in the past 6 years! When it was first released on the world, it was bright and shiny and once we got used to it we loved it. But, the Classic UX is built on a server-based development paradigm which meant that there were an excessive number of post-backs and screen refreshes and it was built in a day when mobile was not as prevalent and all-pervasive as it is today. Although Microsoft did try to provide support for mobile with concepts such as Device Channels, they never really took off.

To stay up with the demands of the modern consumer, Microsoft needed to find a way to provide proper support for mobile and give users a client-centric UX comparable with what they get everywhere else. So, the bold strategy with Modern, is to make SharePoint a mobile-first offering. This means fully embracing client-side development, which in turn means JavaScript and a whole bunch of other supporting frameworks and technologies to give consumers this UX that they apparently demand. For this brave new world to work it means we have to ditch much of what we are used to and start over – yikes!

Personally, I don’t buy into this concept that the future for SharePoint is all mobile. Sure, it has its place but SharePoint isn’t like Facebook or Instagram or any of the social computing platforms. It’s a corporate tool for business and actually, quite often I don’t want to people to make a snap decision on their phone as they jog to the gym but rather I want them to make considered deliberate decisions when their mind is focused on their work, which for an information working normally still means sitting at a workstation with a full-size screen or at a laptop at the very least.

I’m at risk of going off on one here and so I’ll stop ranting as it seems that my perception might be a minority view. I guess we shall see. One thing is clear though, and on this I totally agree with Microsoft, SharePoint does need to provide better support for mobile and that then is the principal driving force behind Modern.

So, what’s the downside?

Sadly, this path to support mobile is not a one-way street of benefits and improved productivity. Embrace Modern, and there are some things you will have to give up or do in a very different way. Well quite a lot of things actually, so let’s take a look at the key ones.

Branding

Branding in Classic was never perfect but it was fairly easy to give a site a character that reflected the customer’s values and image. You just had to come up with a colour scheme, a few custom logos and override some CSS on the master pages which was easy enough to do. But in Modern, master pages are gone and with it the ability to brand a site with simple CSS overrides. In fact, in Modern it’s now terribly cumbersome to get any custom CSS or JavaScript on a page at all. All that time, investment and effort you made in getting SharePoint to look just right with custom CSS is all thrown out of the window with Modern. Ok, so heavy branding was never a good idea and it broke many an Intranet but with CSS of old, you used to be able to take control of page, reposition or hide elements as required and apply those changes in a consistent way throughout your deployment. So long as you are careful there is minimal risk.

In Modern you can’t do this anymore, or at least there is no native support for it. You can still get a custom Composed Look to show up in Modern, sort of, and you can still change the colour theme and Site Logo but that’s about it. Microsoft could easily have provided us with this capability but as they chose not to, this leads me to conclude that they don’t really want us to tamper with CSS anymore.

I could live with this if Modern didn’t impose some really stupid design decisions by adding stuff to pages that I really want to hide. Mainly this amounts to the ubiquitous buttons that plead with us to provide feedback to Microsoft or download their mobile app. I’ve got the app already and this is my Intranet an I really don’t want to have my users being enticed to send Microsoft feedback on nearly every single page! Especially when they think they are sending feedback to the IT team, when they are not of course.

In response to this feedback about feedback we are now envited to run the following PowerShell command:

Set-SPOTenant -UserVoiceForFeedbackEnabled:$false

Never mind that there is no Web UI setting for this SharePoint Admin and we have to fix things with PowerShell, so long as it works. And it does, but only sort of. It makes the Feedback button disappear for Site Pages but not for system pages like Site Contents. This issue has been kicking around for way too long now and feel free to join the conversion at https://github.com/MicrosoftDocs/office-docs-powershell/issues/508#issuecomment-419209930

This solution only solves half of one of the issues in any case. We still don’t have a supported way of switching of the “Get the mobile app” link. And Microsoft’s response to this one is, “Oh the buttons are owned by different team”. Presumably, we are supposed to infer from this that one team picked it up and acted and the other team chose to ignore it. Come on, I couldn’t give flying fig about your teams, just get it sorted!

I can’t leave this section without pointing out that they have screwed us over with styling imposed on the site logo as well. They seem to have assumed that everyone wants a square block logo these days and have taken it upon themselves to put a border around the site logo as it appears on a Modern page. But what if my customers don’t want a solid square logo but instead what a transparent background. Well this is the result:

I didn’t ask for this border and I don’t want this border but ok, never mind, with a CSS override we can easily change that. But wait, we now don’t have an easy way to add CSS to the page and so we can’t do that anymore. Talk about making life difficult!

You may think I am being trivial here but the first thing I get told to do by every single customer I have worked with on modern (ok there’s only 4 of them to date) is, just turn off those “Feedback” and “Go get the app”, buttons will you, because we don’t need them.

Oh, and by the way, if you decided to do branding by JavaScript Injection as was all the rage just a couple of years ago, you can forget that as well because that won’t work on Modern either. Both JavaScript injection and setting an Alternate CSS URL apply to a master page and in Modern we don’t have a master page anymore.

So, the bottom line is if you embrace Modern you may have to start over with your branding because what worked on Classic simply won’t work in Modern. That said, if your branding needs are basic and you can put up with the draconian design decisions imposed upon us, in other words you are prepared to stay on-rails, then changing the colour scheme is a breeze.

Standard Web Parts: Microsoft Giveth and Microsoft Taketh Away!

This change to Modern is so radical that Microsoft have had to ditch all their standard web parts currently available to users in Classic mode. Some of these have been around since 2003 and haven’t change much in 15 years. I guess we can be confident that they are a proven technology. However, there is simply no way to add a Classic Web Part to a Modern Page. This is so important that you should read that last sentence again.

One would hope that for every standard Classic Web Part we lose there would be a Modern client-side replacement. In some cases there is, and the great news is that sometimes the replacements are heaps better than their Classic counterparts. For example, I totally love the new Link Web Part where I can just paste in the URL to say a blog article in WordPress and SharePoint goes and grabs me the article image, headline and blurb snippet. This alone is going to be incredibly useful. Here’s what one of my blog posts looks like as a SharePoint link in Modern and all I did was paste in the URL – totally brilliant, Microsoft giveth!

We even get some new welcome additions like a weather web part at last (why is everyone so fixated about seeing the weather on their portal) and the Hero Web Part is as cool for today as Promoted Links (those sexy slidey navigation tiles you see everywhere) were in 2013. Here’s what the Hero Web Part look like out of the box on a new Communication Portal site.

Hover over an image and it zooms in just enough to let you know that it is in focus – very cool. The only thing I’m not a fan of is why they chose to add a random square block (coloured to the selected theme) to the lower left corner of the main image (highlighted above). This is totally bizarre. By all means give us a means to add a custom logo to be inserted here or an option to have nothing at all but please don’t force random UI design thoughts on us – again! A small point maybe but one that would be so easy to put right. Also, I’d like to see some more layout options. What comes is usable but I think they could have made it a bit more flexible. So, this one is a case of Microsoft giveth but could have giveth just a bit more.

In some other cases, we lose functionality but can sort of make do. For example, we no longer have (native) support for those ubiquitous Promoted Links navigation tiles (Microsoft taketh) but you can still add links to a page just fine in other ways, using a Hero Web Part described above for instance.

Talking of Links, we’ve lost the Summary Links Web Part of course but it has been replaced by the new Links Web Part (not to be confused with the Link (with the s) Web Part mentioned above).

The Links Web Part looks great on the page and it is very easy to place a nice Office Fabric icon next to each link. The UI helpfully gives you the URL to the page where you can find the set of available icons so that you don’t have to guess at random icon names (be nicer if it was a hyperlink that opened a new window). Only the linked page doesn’t work in Internet Explorer (really!) and the range of icons is severely limited, not nearly as many as you get with say Fonts Awesome and sadly, there’s no alternative way of adding a custom or alternative link icon, it’s Office Fabric or nothing. And whilst we’re at it, I can’t rearrange the order of my Groups or Links, they’re simply returned in alphabetical order and that’s that. If I want them in a custom order I’d have to prefix the link titles with a number as in, “01 The Ops Team” and “02 Finance” etc. That’s very ugly I’m afraid, I thought the days of such awful workarounds were well and truly in the past. And, I can’t place them in columns anymore either, it’s a single vertical column and that’s your lot. So, the Links Web Part is a case of Microsoft giveth (a little) and Microsoft taketh away (quite a lot actually).

In case the penny hasn’t dropped yet, Modern also means that you don’t have List View Web Parts anymore! We’ll that’s not strictly true, there are client-side replacements as highlighted below:

Note, at the time of writing these are both flagged as being in preview, which I take to mean “use them by all means but they might be a bit flaky”. Still, the Document Library web part seems to work just fine and even has a really excellent enhancement as you can now specify a target folder. This is useful because you might use a top-level set of folders to group documents and only want to show the contents of that folder. Of course, you could argue that you should use metadata to do this and then create a view and that’s a good point but a folder is also a security container and views are not and so there is still a place for folders, despite what you may have read elsewhere.

This folder targeting of the web part also works for Document Sets, which are really just a glorified folder in any case. But I must mention that if you use Document Sets then you’re in for a disappointment. Whilst Document Sets will work on Modern they do so by sending the user to a Classic view. This is really confusing if users are now used to a Modern library but then the UI randomly changes to Classic when in a Document Set. This has been an issue for way too long now and really should have been sorted by now. Because it hasn’t been resolved, I’m beginning to wonder of Microsoft now think that Document Sets were a bad idea and should be left to wither on the vine but as far as I know no one has made such a declaration. It would be a shame if we are forced to give up Document Sets because they certainly have their place.

What is a bit odd is that when a Web Part is targeted to a specific folder (or document set) you have no way of knowing that you are actually in a folder. By default, the web part title will be the folder name but that can easily be overwritten with something else. This means that there is no way to drill up a level to see any other sibling folders at the same level. Thankfully, if you drill into a sub-folder the web part does give you a breadcrumb navigation path to your start point – but no further. There is no Up button to move to the parent level. I can see that in some circumstances you might want this but at other times you most certainly would not.

Also, when I want to show the contents of a library on a page I am often expecting the users to be simple consumers of the documents and so would want to hide the menu bar but there is no option to do so. Come on guys, having the ability to customise web parts to show a Full or Summary tool bar or no tool bar at all has been a feature of Classic Web Parts since day one!

The List Web Part is a disappointment I’m afraid. Currently it only allows you to view Custom lists, which it does well enough I guess but this is really of limited value. One of the main purposes of a page is to be able to set a context for the viewer. That means being able to pull together related list items and documents from different lists and libraries and make them accessible from the one place. Especially in Team Sites, I would expect to see a Document Library, a Task List maybe, a Contacts List and a Promoted Links List of navigation tiles, all on the homepage.

There is a new Highlighted Content web part which can be configured to show list items based on their Content Types but this an aggregation web part that works like the Content Query Web Part (CQWP) or the Content Search Web Part (CSWP) (of course we’ve lost both of them as well by the way), and not a view onto a specific list. Also, it can’t show any custom metadata and so it is really a poor alternative.

All of this means that you will have to rethink your strategy for how pages are constructed and their purpose. Basically, we are now compromising the experience for the user because the technology simply doesn’t support what we have been used to in Classic. So here, Microsoft giveth just a little bit but taketh away a shit load!

Without the Script Editor Web Part (SEWP) or the ubiquitous Content Editor Web Part (CEWP) we no longer have the ability to add up custom styles or JavaScript or even lovingly hand-crafted HTML. These are SharePoint staples and used somewhere in every classic SharePoint deployment I have ever seen.

The CEWP is a real loss because it is the fall back of last resort for anything that you might want to add to a page. You can of course add a new Text Area client-side web part to add formatted text to your page but gone is the ability to edit the HTML source for that special bit of hand crafting and consequently, your formatting options are severely limited. This also means that you can’t use this component to embed any CSS overrides or JavaScript on the page, so that brilliant snippet of jQuery that your ripped from the Internet and does just what you need can’t be added to your pages anymore (at least not in the same way).

Microsoft provide us with some sort of justification as to why they have not provided replacements for the SEWP or the CEWP in this article https://github.com/SharePoint/sp-dev-docs/issues/480. The argument basically amounts to Microsoft is trying to discourage us from doing this anymore as they want everything to work in a unified way across everything in O365 meaning, Groups, Teams, Planner and My Sites etc. and because these are marked as “No Script” they don’t support embedded JavaScript, but this is the main point of having these web parts in the first place – the SWEP in particular.

Personally, I think this is pretty lame and thankfully I’m not alone in this and the community has taken it upon itself to write replacements for these staples using the new SPFx development framework. If you need a CEWP or a SEWP in your Modern then check out the following:

• https://github.com/SharePoint/sp-dev-fx-webparts/tree/master/samples/react-script-editor
• https://medium.com/niftit-sharepoint-blog/add-the-script-editor-webpart-back-to-sharepoint-modern-experience-688a7b7208e4

Check out the comments and have your say on SharePoint UserVoice at https://sharepoint.uservoice.com/forums/329214-sites-and-collaboration/suggestions/17290130-bring-back-script-editor-web-part-in-modern-shar in the vain hope that someone might listen. When is comes to the CEWP and the SEWP or the CSWP and the CQWP for that matter, Microsoft just taketh!

Custom Development

SharePoint has always been a platform that supports extensibility and in a Classic world there are many ways in which you can do it. For instance, you can rip someone else’s jQuery that you found on the Internet and throw it into a Content Editor Web Part (CEWP). You can create a Sandbox solution, yes these are still supported so long as they are declarative-only with no code-behind. You can create a traditional solution package, just so long as your SharePoint is on-prem and not in O365. You can create a solution using the Cloud App Model of which there are 2 variants, the SharePoint Hosted App or the Provider Hosted App. You can use JavaScript injection to customise the SharePoint UI in a myriad of ways. If you are on-prem you can create Timer Jobs and event receivers, you can run code with elevated permissions and make system updates to items so that the version numbers don’t get updated and you can build delegate controls. Hell, you even write your own Services Application if you were so inclined. With Provider Hosted Apps you can have remote event receivers so that when something happens in the SharePoint environment a custom solution can take the necessary action.

Only, when you embrace Modern you can’t. I mean you can’t do any of that stuff using any of the above listed techniques and proven methods to build on the UX. In the interest of fairness, I should point out that SharePoint Apps that provide their own UI or do background jobs that don’t really require surfacing in the SharePoint Modern UX should not be affected. But if your current environment relies on UI elements built for a Classic world then you’re out of luck.

If, like many businesses who have been on SharePoint for a while, you have invested in some level of custom development or procured a 3^rd party product that use these methods then you can’t use them in Modern because they simply won’t work. If you’re a greenfield customer then you won’t have invested in Classic development and so you won’t know what you’re missing and that’s just fine, but I don’t come across so many greenfield sites these days (most of my customers are either still trying to get off SP2010 or make the leap from SharePoint on-prem to O365).

So, if you have any custom development at all that affects the UI then embracing Modern means that you have 2 choices:

• Ditch what you have and start over.
• Mix Classic with Modern

I’ll pick up on the 2^nd option later but let’s focus on option 1 here.

If you have invested in any 3^rd party vendor products then you might be lucky in that they will have seen this coming and will already have come up with a pathway to Modern. But that is no way guaranteed and even if they promise you that support for Modern is on its way, it will be on their timeline and not yours.

Rebuilding all those custom web parts is not going to be an easy option. First, you will need to evaluate whether it is even feasible to rebuild them to support Modern, let alone the time and cost involved. And in Modern, the UI elements are all constructed using an entirely new paradigm (for traditional SharePoint developers at any rate) called the SharePoint Framework (SPFx). New means that not so many developers have gotten on board with it yet. If you believe Microsoft, a major rationale for modern was to open up SharePoint development to the wider world of client-side developers and so making the platform more accessible. Sadly for Microsoft, I suspect not very many of these script hackers are that interested in SharePoint and are perfectly happy building plug-ins for Facebook or WordPress or apps for the iPhone or whatever. In fact, a good chunk of them have anti-Microsoft DNA woven into their genes and so won’t be touching O365 on principal.

My point is that even if you are client-side developer who is willing to rise to the challenge using JavaScript and jQuery and React or Knockout or Angular or whatever, you still need to understand how SharePoint works and few of them do. Added to this, Microsoft have recognised that JavaScript has been bastardised to be something it was never intended to be and so to add some rigour to the development process that have invented a meta-language called TypeScript. If you’re a script jockey, there is quite a steep learning curve with TypeScript and I don’t think many have been enticed to make the climb.

An unintended consequence of all of this is that both client-side JavaScript stack developers and traditional SharePoint developers will have to make an investment in time and energy to learn to develop with the SPFx and until fairly recently not many in either camp have been compelled to do so.

I’ll come back to what has changed recently in a moment but first I want to address the bad idea of a mashup.

How about a mashup?

If you can’t do without your custom Web Parts then mixing Classic with Modern might seem appealing on paper.

You could embrace Modern wherever you can and then resort to Classic only when you need to. The problem with this strategy is that you end up with a really ugly mess. One team is on Modern another has to stay Classic, some pages on the same site are Classic whilst the rest is Modern. Not only does it look really ugly it confuses the hell out of users because the UX is so different. Just little things, like how you have to access List Settings or Site Settings for that matter, are different and so a Modern/Classic mashup is hardly conducive to efficient working.

Just on an aside, as I can’t let this drop, in Classic we used to access Site Settings straight from the Site Actions menu, simple as! Now in Modern we have to hop through the Site Information panel to get to Site Settings as highlighted below:

It’s only one extra click I know but it gets in the way of my productivity a hundred times a day and for no added benefit as far as I can see. Worse still, the one action that really should be hidden away for protection, “Delete site” is linked directly below “View all site settings” making it incredibly easy for dopy me to delete my entire site by mistake. What were you thinking?

Anyway, a mashup is not the answer. Don’t do it, because if you do you will surely regret it! My recommendation is to take the “all or nothing” approach. Embrace Modern all the way if you can but if you can’t then stick with Classic until such time as you can suck it all up.

Modern all the way

I mentioned earlier that something had changed recently that now meant that SharePoint developers suddenly had to pay attention and get on board with the SPFx or risk being left behind. Up until recently Modern was really a bolt-on to a Classic Site. Meaning that Team Sites and portals were created in the same Classic way, with Site Pages libraries which were Classic. You could of course add a new Site Page to the Site Pages library and you had a Modern page at your disposal and you could change the switch the UX of every list and library over to Modern but that’s not how it worked. Basically, most people just carried on with Classic and Microsoft made this awful mistake of trying to turn people on to Modern by randomly switching the UX for lists and libraries over to Modern. It was as if SharePoint was saying, “go on try me, I’m modern, I’m better, you know you want me”. The only problem was that by doing so it made nearly every site one of those ugly mashups which, as I have just explained are a totally bad idea. As a consequence, we all told our admins to disable Modern or we reset our Lists and Libraries to be Classic mode only.

What’s changed is this. About 6 months ago Microsoft released 2 new Modern first site templates, one for a Communication Portal and one for a Team Collaboration Site. These are game changers because sites based on these templates are Modern from birth! In other words, Microsoft flipped things around. Instead of starting out as Classic and needing to be Modernised, sites build from these templates are Modern all the way through their DNA.

And what’s more they look good. They look fresh, they look – well Modern! Now Modern is front and central and customers are seeing it anew and are now asking for it and that means that consultants and developers have to service that craving, meaning they have to now get on board with the SPFx.

I feel obliged to point out…

Before I leave you, I feel obliged to point out a few things that will still cause some friction about making the transition to these Modern templates. Please do read this tuff because it is important in helping you decide if now is the right time to embrace Modern for you or your customers. You might even find a show stopper in here.

Site Templates – No More

This is a big one, at least for me. When I work with a customer on their collaboration work spaces I don’t just through them out a Team Site, Community Site or Project Workspace based on what Microsoft provide as standard templates. No, I work with the customer to figure out what will work best for them, what Features they need, the layout of their site homepage etc. Then I save a prototype site as a custom Site Template and provision all sites in that space using this custom start point.

This has been an integral part of every SharePoint architecture since 2003. Yes, I know there were restrictions such as you can’t save a site as a template once the Publishing Infrastructure has been enabled and I also know that in SharePoint Online Microsoft have for some reason been discouraging the practice by hiding it in the UI but it still worked, you just had to assemble the URL yourself to access the page to save the site as a template.

Well in the Modern templates, you guessed it, this capability is gone! I don’t mean it’s hidden, I mean it just does not exist! This means that the start-point for every team site I create looks like this:

But what if I don’t this to be my start point. I mean at the very least I would want to customise the New item and the Quick Links. And if this were a site I wanted to use to manage a project then I’d want a Task list at least. I now have a lengthy, cumbersome and error prone process ahead of me to configure this standard offering into something I want. As a one-off I can live with it but if I want to provision 20 team sites a dozen community sites an what to generate let’s say 3 new project sites a week, this some becomes painful task. Too painful for someone not to have come up with a solution and so they have.

The recommended approach is to use the Patterns and Practices Provisioning Engine. This marvel of software engineering does indeed allow you to export a configuration of as source site out to XML or JSON and enables you to apply those configuration settings to a newly created site as post provisioning action. However, this can only be done via PowerShell or custom code and so is not something I can put in the hands of end users like I used to.

Whilst this approach may be great as a one-off tool for say platting out my 20 team sites it’s very constraining as an ongoing routine provisioning tool. Every time the PMO need a new project they have to wait for the IT department to get around to running a script for them. I thought those bottleneck days are over – seems not. Yes, you can buy 3^rd party tools that provide this capability but surely, we shouldn’t need to shell out more money to be able to do this, should we? So, whilst the PnP Provisioning Engine has its place it just doesn’t cut it – sorry

List Templates – No More

This one is just as painful, if not more so, I’m afraid. The new Modern Templates don’t allow lists or libraries to be saved as templates either. If you need add half a dozen or so libraries to be added to a site and they all need to be configured basically the same way then what you’d normally do is configure one of them and save it as a list template and base the other 5 on that template saving you potentially hours of work. You can still do this on Classis Sites which support Modern but you can no longer do this on sites based on the new Modern templates.

I can’t begin to explain how much of a drawback this is. Your options are:

• Bit the bullet and just accept that this is missing and get over it
• Procure a 3^rd part tool that does do this – I’m sure they exist
• Resort to the PnP provisioning model as described above
• Write a custom solution yourself (I guess)
• Look for a hack and so do exist like this one https://sharepoint-specialist.nu/save-list-as-template-on-modern-team-site-not-available-in-sharepoint-online-e85c25a12943 but proceed at your peril and they are not necessarily supported.
• Give up on SharePoint and look for another product

Audience Targeting – No More

In Classic you are able to control the visibility of certain UI elements such as navigation links and views to specified Audiences. This way you can tailor the UI so that it better meets the needs of different types of users accessing the site. There is no point having a navigation link to a secure library that is intended for just the management team as anyone who clicks on that link, who does not have access will simply get an access denied message. Similarly, you can set a target audience for many Classic Web Parts such that they only get rendered if the viewing user is part of the part of the designated audience.

Only in Modern it’s gone and there is currently no replacement on the road map. The navigation doesn’t support audience targeting and neither do any of the client-side web parts. Suck it up princess!

Publishing Infrastructure – No More

The Publish Infrastructure (PI) feature is simply not supported in Modern. You can switch the PI on for a Classic Site with Modern tendencies but try and do this for one a site based on the Modern templates and whilst the PI feature is still listed, any attempt to enable it results in an error screen.

The PI gives us publishing pages with Page Layouts which were undoubtedly easier to work with than bog standard wiki pages and with the Modern pages you can argue that because the whole page architecture has changed then page layouts are irrelevant – fair enough. But the PI also brought us page support for publishing approval. That’s gone although there does seem to be a replacement for this on the horizon

Metadata Driven Global Navigation – No More

In Classic we can use the Managed Metadata Service (MMS) to set specify a global menu navigation system. To be honest, it was imperfect in that each MMS menu structure could only have a scope within a single site collection rather than being reusable across say an entire Web Application. Still, it was a useful tool in your toolkit. Sadly, no more as in Modern you have to set the menus manually.

Still an ugly mashup

Even though the new Modern templates have flipped thing around they are still not totally modern. For example, create a new Task list in a Modern Team site and it gets created in Classic mode, leaving you manually set the UI to Modern. Worse, some of the view, such as the Gantt Chart view are not supported in Modern yet and so the UX reverts to Classic. SO the bottom line here is that it’s still an ugly mashup, only not quite as ugly as it was before!

Conclusions

There is more of course but this has been an incredibly long post and I’m tired and if you’re stayed with me this long then you’re most probably tired too. However, I feel as though I need to reach some conclusions for all of this and I guess they amount to the following:

• Sad as I am to see it’s passing, Classic is all but deprecated in name and Modern is the future
• It will be a painful and expensive transition for some customers and software vendors to make this transition
• As it will be a painful and expensive transition it will be a quite a long drawn out process, mostly likely taking years rather than months
• If you’re are a consultant or software developer who is still looking only at the Classic world then you’ll be fine for a while yet but you have got to get on this train at some point
• Embrace Modern now and there are things that you are just going to have to give up. Some of these you may be able to live with but others might be show-stoppers
• Be ready to accept that some of your trusted web parts simply don’t have an adequate replacement
• Where Microsoft has taken away something that users can’t do with out then someone somewhere is working on a fix
• Microsoft are truly improving things and the release of the new Modern Templates has gone a long way to driving adoption
• Some of the new UI enhancements are really good and will result in lots or oohs and ahs from many users
• I do wish that Microsoft had not imposed on us design patterns of their choosing or at least provide us with a support and standard switch such things on and off
• Taking capabilities, that people have relied upon for years, away from the UI of core product and saying you can still do this but its through a custom PowerShell script is not an acceptable answer and we should rage against it

The bottom line for me is that providing my customers can live with the changes or simply don’t know what they may be missing out on then, then Modern is the way to go. The UX is fresh and a proper Responsive Design is what users on mobile devices expect.

This is a big change for SharePoint and a brave move by Microsoft who seriously risk alienating many of their loyal user base but at the same time maybe attracting some new fans. Let’s hope they don’t stuff this up. So long as the listen to users and realise the real issues that business face father than the perceived and assumed issues which may be important to some but aren’t really mission critical then they should be alright.