The Good, the Bad and the Ugly of the new SharePoint Library Experience

My article header graphic is a little misleading, as scale usually implies that you need to weigh the pros and cons, and then make a decision. But there is no decision to be made. If it hasn’t hit your tenancy yet, it will do soon – the new SharePoint Library Experience is here!

I personally hate it when Microsoft (or anyone else for that matter) uses the term ‘Experience’ to describe an update to the User Interface (UI) – it just smacks of over interference from the marketing department. In fact UI seems to be out of vouge these days, everything is now about the User eXperience (UX). I know I am beginning to sound like Victor Meldrew (if you don’t know who that is – look him up) but why does every tweak of the UI (sorry UX) need to be proclaimed as a new “experience”.

To answer my own question, I reckon a change becomes a new UX when what you used to do simply and easily before, now seems confusing or counter-intuitive because someone has decided to move around the furniture. On that basis, I guess this new update to the SharePoint libraries does indeed qualify as a new “experience”!

To find out what has a changed, I encourage you to head on over to the Microsoft Blog at UX Updates, AI Actions & Forms in Document Libraries | Microsoft Community Hub.

Don’t get me wrong, some of these changes are great and I welcome them, but others, less so. To get my take on it – read on.

The Good, the Bad and the Ugly of it all

The layout and position of the library Command Bar has changed. Instead of it being an obvious tool bar that sits in the header above the list view, it is now less obtrusive and sits in line with the library title/breadcrumb control.

The view picker was conveniently part of the Command Bar in the old UX, but now you select views from a set of view-select button that appear below the breadcrumb .

If you select column filters – previously these where shown in their own row beneath the breadcrumb. Now these get displayed in line with the new view-picker buttons.

Compare the screenshot below. The first is of the legacy UX and the second with the new update and follow my colour coding to pick up on the differences

This next screenshot shows the new Command Bar/Tool bar experience, also with a column filter applied.

The above shows the new UX when no documents are selected but things change (much more significantly than they do with the old UX) when documents are selected.

Gone are the view picker and column filter buttons and the toolbar is no longer inline with the title/breadcrumb control but comes into its own beneath it.

The Good

What I like about this, is that does save some precious screen real estate and in general it makes the UI less cluttered in that many more elements are hidden when they are generally not likely to be needed. It makes sense (I guess) to hide the view picker and other clutter when I have selected a document in the grid, because I’ve narrowed my context somewhat, so these controls are superfluous.

When no documents are selected, I also like the ability to switch view at a click of a button. Previously, this was achieved using the drop-down picker and that’s 2 click. I save a click, and saving clicks is great right?

Another thing that I like is the one-click filters based on file type.

Often I will know the file type of the document I am looking for and having these simple click button filters is a welcome enhancement, particularly as I can set multiple filters together, so if I check the Word and the PDF icon it will return only those documents which are either in Word format OR PDFs and exclude the rest.

My only criticism is that these quick filter buttons are not context sensitive. What I mean, is that the above selected view only contains Word format documents and so showing the Excel, PowerPoint and PDF filter buttons is pointless – in fact, thinking about it, showing the Word filter button is equally pointless as clicking any of these buttons has no effect and so, in the strive for an ever increasingly parsimonious UX, why show these buttons at all, in this context?

A better UX (IMHO) would be to only show filter buttons as necessary and, as a bonus, that way I can easily tell at a glance the type of documents my view contains.

As much as I like this new feature, I think Microsoft should have extended it to support Content Types. Say I have a library configured to use Content Types for say Policies, Procedures and Guidelines an equally useful option would be have a one-click-filter filter button for each Content Type in the view. I get that we are constrained on screen real-estate but I’ve already explained how we might cut that down by having these one-click filters being context sensitive based on the documents returned by the view.

The Bad

The things that ain’t so good ☹

The Filter Panel

The filter panel, is still accessed by clicking the filter button, but this button is now in a completely different location with a new icon which doesn’t conform with the standard filter funnel icon used everywhere else, so it is decidedly unclear that this is the new filter panel button at all!

I expected the filter panel to behave like before, where the list of filter field options is based on the view in focus.

Only in the new UX, it doesn’t seem to work the same way anymore. If you look at the above screenshot – where are my one-click filters for Content Type, Product and Product Group?

To get these filter options I need to first create a column filter.

Then, and only then, do I get the options to filter by these columns in the panel.

But here’s the rub – these filter column options are not sticky! Do a hard page refresh and you are back to the default set. This is such a backward step in usability that it beggars belief!

The Create or Upload Button

In the old UX, creating/uploading folders and documents was all conveniently accessed from the + New menu button.

Clean, simple, obvious and intuitive!

In the new UX, its far from obvious. If I click the drop down for the breadcrumb I get the option to create a new folder, and to upload files or folders, but where is my option to create a new document?

I do get the option to + Add Template and so thinking that might allow me to extend this menu I used it to add a document template but to no avail, which (to me at least) is downright confusing!

To add a new document we now need to use the + Create or upload button which is (inconveniently) located on the far right or the page.

In my view, not only is the geographical location of this button wrong, but the button itself would be entirely unnecessary if the breadcrumb dropdown displayed the full menu of options instead of a skinnied down version – although it is hardly obvious that the dropdown contains a menu. A much better design would have been to just add a nice and succinct + New button like before and intuitiveness would be restored!

A recent commenter on the Microsoft blog picked up on another poor design choice. Although the article devotes a whole section to explaining why the new breadcrumb control us better, I agree with critic, this is not an enhancement.

The breadcrumb navigator previously showed the full folder path, allowing users to conveniently jump back to any higher-level folder or back to the root in a single click. Now however, if we have a folder structure a few levels deep, the breadcrumb gets truncated and we are left to figure out that we need to click on the folder navigator button to jump to a higher level folder – we now get this:

When previously we got this:

The original is simply better and more intuitive. I guess that the chopped version in the new UX is to provide the space required for the new command bar.

Personally, I can live with this change, and don’t see it as much of a big deal as the above mentioned critic. In any case, I advise my customers not to go any more than 2-levels deep in their folder structure – wide and shallow is better than narrow and deep for all sorts of reasons that I won’t go into here.

Document Forms?

The Microsoft article proudly announces a new feature which supports document submissions with enforced metadata capture using a custom form, built using MS Forms, in the same way as can already achieved with lists.

Only I can’t find the Forms button anywhere! According to the article, I should be able to “click the ‘Forms’ button that now appears in the command bar”. Only it doesn’t, not for me at least and I have tried to find the elusive Forms button on 3 tenancies and it just ain’t there on any of them.

Now, I do live and work in Australia (as do all the tenancies I have access to) and it could be that the new UX has not been fully deployed yet – I guess that the Forms button might just magically appear one day. If this phased roll out is expected and is by design, then it would be nice to be told about it.

On the other hand, I might just be missing the Forms button because I am not looking for it in the right place. But the article says it should be readily available from the command bar and this is a screenshot of my command bar and I just can’t see it anywhere – can you?

Another commenter asks in the Microsoft blog whether this new Forms feature works for Document Sets. Microsoft explain that it doesn’t – not yet at least.

I am wondering how this new Forms concept will cope with Content Types. Hopefully, it will simply deals with libraries that have been configured to use custom Content Types with aplomb but without access to the Forms button I have no way to checking this out ☹

I also question why extending libraries with Forms is needed and whether it is actually a good idea. Personally, I have never needed to jazz things up a bit, so what does this new concept offer – here’s what the Microsoft article says:

Looking at these ‘benefits’ in turn:

Bypass Library Permissions

Excuse me! This introduces a means to allow users who don’t have access to the library/folder to add items to the library/folder. In other words it creates a backdoor in our security architecture. Am I the only one who sees this as a terribly bad idea. I suppose niche scenarios for this might potentially exist but in nearly 25 years of doing SharePoint I have never come across one.

Consistent Metadata

Mmm, back in the day (SharePoint Classic that is), if you dragged or uploaded a document into a library, which was configured with a required column, SharePoint would throw up a properties dialog which alert you to your obligation to tag the document with the missing attributes. When you do the same in SharePoint Modern (current or new UX) this no longer happens – which I think is a shame because it did provide an immediate and obvious way to alert users as to their tagging obligations.

So, Forms is pitched as the way to ensure upfront tagging. If users don’t complete the mandatory fields then they can’t submit the document. Seems like a good idea doesn’t it, and some cases it is, until, that is, you realise how (some) customers use this in the real world.

When I deliver SharePoint training, I commonly tell the story of a customer (who I decline to name) who insisted that users tag all documents with 14 mandatory metadata attributes! The problem was that for many of these attributes, users didn’t know what values they should be applying, but the system forced them to provide a value for all 14 properties. This resulted in users just throwing in any old value, just so they could get their documents uploaded.

The intended outcome was to end up with a nicely ordered set of documents with useful metadata to aid with sorting, filtering, search and to enhance information discovery. The actual outcome was a mess:

A required “Description” column nearly always contained garbage text.
A required “Expiry” date column that was nearly always set to the current date when the user uploaded the document.
A required “Owner” user column that was assigned to a colleague at random.

I could go on, but you get the idea.

And the moral of this story is to be very careful when you make metadata attributes mandatory because you may well end up with inaccurately assigned values which can make the whole exercise worse instead of better. My point is that bad metadata is worse than missing metadata.

The answer to this is of course end user training. We all know that metadata is a chore but users (when trained) do understand that it is important and that it is for their benefit ultimately. You just need to get the balance right – ask them to provide the essentials and never ask them to provide values that they might not reasonably be expected to know!

Controlled Submissions

According to the article, we can use Forms to control the type of documents users can upload, say to PDFs or images or maybe videos (wait that’s not a good idea because video clips might easily be above the 256MB file size limit imposed by Forms).

I suppose this might potentially be useful but I have never needed this capability.

Isn’t this why we have Power Apps?

My point about Forms is that is not so much a bad idea but that I can foresee no circumstances in which I would need to use it. If I did have a scenario where I needed users to submit documents as part of a business process, where I needed the sort of control that the Forms concept promotes as a good idea, then I don’t think Forms would cut it. If our process needs this sort of control, it seems likely that we would need more control than Forms would or could provide and we already have a tool at out disposal that can do this – it’s called Power Apps.

The Ugly

Some gripes that don’t really fall into the “bad” category but certainly don’t count as “good”, so I can only assign them as “Ugly”.

Field Customizers

If you are not familiar with Field Customizers, these provide a way to extend the standard capabilities of SharePoint, using the SharePoint Framework (SPFx), so that you have total control of how a field (a column cell in a SharePoint list view) is rendered in the UI.

Field Customizers are so much more powerful than the simple format overrides you can do (somewhat painfully) in the UI, but take a look at my screenshot of a library that is configured to use a couple of Field Customizers.

It renders in the old UX, even though my site, and all the other libraries in it, get the new UX.

This is because the new UX (for some technical reason Microsoft decline to explain) does not render Field Customizers (they still don’t work with the List UX uplift either that happened several months back).

Microsoft’s initial plan to resolve this issue was to drop Field Customizers! Seriously, Microsoft techies and product managers must have sat round a table (virtual or otherwise) and someone must have said – “You know, trying to get the new UX to support Field Customizers, is proving a challenge, let’s just drop them and hope no one complains”.

Fortunately, as soon as Microsoft announce this, people did complain and complain loudly (me amongst them) and so FCs have a stay of execution (for now at least). But rather than solve the problem i.e. get FCs to work with the new UX, Microsoft has taken the ugly route and simply chosen to render the old UX (the one that works with FCs) when it detects that the library has an FC.

This means we now have inconsistency. Some libraries in the site have the new UX and some the old – hardly the best scenario for things like user training etc.

But wait, it gets worse (how can it get worse you may be thinking)! This inconsistency is not tied to the library, but rather it is tied to the view. Meaning that we don’t even have consistency in the same library.

The screenshot below is of the same library as above but this time there are no FC columns in the view.

As can be seen, the All Documents Flat 2 view renders in the new UX. But worse still, when I switch back to All Documents Flat, the original view, I am initially stuck in the new UX where my FCs don’t render as expected.

I must do a couple of hard page refreshes before the system figures out that I am now wanting to use FCs again and should switch to the legacy UX.

I’m sorry Microsoft but this is pants and you need to do better. First and foremost, fix the new UX so that it works with FCs as expected – and whilst you are at it do the same for lists! Come on, you can do it, I know you can!

If that takes a while, give us a switch at either the site or library level so we can decide whether the pain of the new UX is worth the gain – until such time that you have resolved this issue at least. Surely that’s not too much to ask.

Inconsistency with the List UX

You Microsoft guys had a great opportunity to make the new Library UX come into line with the new List UX – but that seems to have slipped by.

Here we have a full command bar and quick filter buttons like the old library UX but the view picker is now a set of tabs and the filter panel button uses a funnel icon.

My point is that there is obviously greater consistency between the old library UX and the new list UX than there is between the new library UX and the new list UX – resulting an greater inconsistency overall.

So unless, the plan is to upgrade the new list UX to a new, new list UX that is closer to the new library UX then what you have done amounts to a step backward in UI consistency. Read that sentence back to yourself and it does make sense (I think).

In Summary

Microsoft have done their usual trick, by:

Providing a UX upgrade that no one really asked for,
Providing some useful enhancements, granted,
But at the same time introducing side effects that either add complexity or reduce functionality in other areas,
Without giving us an option of choosing whether to stick with the old UX – at least for a while until we have parity of functionality and some greater level of consistency in the UX.