For as long as I have been doing SharePoint, figuring out what properties to use when filtering or displaying search results in regards to people has been a challenge as the documentation in this space is somewhat lacking. I’m not sure why I haven’t done this writeup earlier, but no time like the present.
Sorry for the clickbait title. I have been meaning to write about how I think about the out-of-the-box Microsoft Search vs. the PnP Modern Search web parts for a while, so here goes.
Disclaimer: I have been working with search for 20 years, enterprise search for 15 years and SharePoint and search for almost just as long. The opinions stated are my own and they are based on my experience with search in FAST ESP, SharePoint and Office 365 over the years and are not influenced by my role as a program manager on Microsoft Search. No money or breaking of fingers were involved in writing this post :)
With SharePoint 2013, Microsoft shipped many ways to customize how search worked. Both from a technical and user experience perspective. The more important one being the ability to use arbitrary HTML, CSS, and JavaScript in custom display templates with the Search Result web part and the Content by Search web part (CSWP).
Fast forward to SharePoint Online and the release of modern SharePoint pages late 2016. Modern pages came with a new set of web parts and lacked the super-flexible CSWP. Modern pages did introduce the Highlighted Content web part (HCWP), positioned as “...the newer, simplified version of the Content Search web part.”
When customer transitioned from classic to modern a gap had been formed between the CSWP and the HCWP which needed filling. And this is where the awesome sharing in the SharePoint community comes in, put into a sharable system with Microsoft 365 Patterns and Practices (PnP).
The first version of the PnP Modern Search web parts (MSWP) were added as a SharePoint Framework sample by Franck Cornu back in October of 2017. My first contribution to the sample was made in January of 2018 to include additions needed for a customer project I had at the time.
Back then MSWP was one web part; the result web part which included an optional built-in refinement panel. The search box web part got introduced late February of 2018, with the vertical web part following later. My main reason for looking at the sample web part in the first place was the need of a roll-up web part for a project. The Highlighted Content web part (HCWP) lacked the needed templating required – and still does, and why bother develop something if it already exists? Much easier to add to a maintained code base compared to owning it completely on my own #lazyprogrammer.
And this is where I believe the PnP Modern Search web parts has its sweet spot – bridge the gap between the classic Content by Search web part and the new Highlighted Content web part. This was my opinion back in 2018, and it still is in 2020. I actually formed the opinion back in 2016. That is 4 years and counting.
The modern search page was soft launched as part of the SharePoint Home page with the May 4th event in 2016. An out-of-the-box non-configurable search page. The page itself did have a link at the bottom which took you to the classic enterprise search center, but it was indeed the start of mainstreaming the search experience. Microsoft removed the link in March this year without anyone really noticing, which leads to think it was the right thing to do :)
When SharePoint Home launched in 2016, I figured it’s time to stop creating classic display templates. I have a long history creating display templates and you can download some open source ones I started to create back in 2014 from github.com/spcsr. I call this out to emphasize I have indeed customizeded search in the past and thought it a good idea at the time. With the introduction of SharePoint Home the journey for Microsoft Search was started – one experience to work on across desktop and mobile – I changed my mind.
At Ignite 2017 the vision for Microsoft Search as you see it today was launched and the search experience from SharePoint Home made its way over to office.com. Last year, in 2019, Microsoft Search in Bing followed suit. From a slow start, Microsoft Search is hitting more and more client endpoints with the promise of a coherent search experience. Same search box everywhere, with predictable results – all driven by the same Microsoft Search backend. And this will continue to expand going forward.
https://docs.microsoft.com/en-us/microsoftsearch/overview-microsoft-search
Let us go back again four years to 2016. I don’t think myself as very good at predicting the future, but this time I got it right. My take was, if I cannot control which search box people search from with no options to customize the result page they get to, why spend a lot of time and money to create something custom?
Sure, I have the ability and skills needed to tune search both from a relevance and UX perspective to be awesome for a specific business. I ended up thinking it is not worth spending the time or money. I would rather use my consulting hours on other fun and valuable projects. Did I have to fight customers and argue my point? YES!! Many had invested in custom search solution for classic SharePoint and wanted the solution brought over as part of their cloud journey. For those who have been privy to these customers conversations they know the following to be a common Mikael statement:
“If you believe you are right and really really want to create a custom search experience, feel free to do so, but you have to get another consultant to do so. It could be my colleague, but it won’t be me.”
Hindsight I hope they see that I was right and that their money was better spent elsewhere.
If you add the personalized relevance introduced in 2017 based on the Microsoft Graph (then Office Graph) to the equation, it’s just not worth competing with it. Too hard. To me anyways.
Four years after the inception of the Microsoft Search search experience, Microsoft is finally adding capabilities customization capabilities to the search result page. You can add your own verticals, add your own refiners and limit what is returned per vertical (roadmap item 57054). Why did it take so long to get customization functionality...? Well, I do not have all the history as I joined the Microsoft Search team in June 2019. One key part is that Microsoft need to ensure the experience works in multiple clients, not only SharePoint. Therefore some of the classic SharePoint constructs (which were awesome when launched for SharePoint 2013, and still are today in terms of architecture) have to yield as Microsoft Search encompasses multiple clients and content. At the same time as classic search is being left behind I do believe we are also innovating with similar, better and certainly more cloud forward solutions from a technical perspective.
“If you’re so PRO Microsoft Search, why do you then work on, manage and promote PnP Modern Search?”
The answer is simple. Because I love to develop and I do believe PnP Modern Search has a good place in the eco-system for search driven apps, specific portal solutions, or for a more flexible roll-up web part in modern SharePoint pages. The portal/app scenario is available as a downloadable PnP provisioning template.
Did you see PnP Modern Search started to be mentioned on search roadmap slides in 2019? I might have had a finger to do here – and it is because Microsoft do see the value in providing full customization capabilities with search. For scenarios which really really really benefits from special technical and UX capabilities. SharePoint has always been a platform for those needing full flexibility, and it still is via the SharePoint Framework. For the majority of enterprise search needs I don’t believe this level of customization is needed.
Short term the PnP Modern Search web parts can potentially let someone create a better enterprise search center, and I know this happens, but it comes at the cost of educating your users to use a search box you control. An impossible task in my opinion, leading to a disconnected search experience for the end-user as users start their search journey from:
I honestly believe the out-of-the-box Microsoft Search experiences is the best way forward for most Microsoft 365 users out there, and Microsoft continues to strive to make it better. Not just for the majority of users, but also for the edge cases.
PS! I was about to lose faith in Microsoft Search back in January of 2019, but I’m back on track. Read my post The conspiracy is real! for more details.
If you believe me to be wrong and off my rocker I’m all ears for reasonable arguments to sway me over. Yes, I do acknowledge there are good reasons to control and customize enterprise search, but I find it hard to justify the investments vs. the outcome.
References:
Cover photo by Attentie Attentie @ Unsplash.
If you have comments or questions, scoot over to Tech Community and let us know.
 |
| My very own Microsoft Search t-shirt and shoe laces! |
My colleague Tarald recently discovered that when looking at the managed property CreatedBy for modern pages where you have filled in the author byline, it will show the primary e-mail address, display name, and claims token for that user (and the claim includes the user principle name).
foo.bar@contoso.com | Bar, Foo | 693A30232E667C6D656D626572736869707C666F6F2E62617240636F6E746F736F2E636F6D i:0#.f|membership|foo.bar@contoso.com
Maybe not a big deal, but since forever, this managed property has contained only the display name of the user, nothing else. I’m not saying it’s a bad thing to give all the data as that disambiguates people with the same name, but what’s bad is changing default behavior which has been consistent for a long time.
The culprit to it all is that Microsoft has decided to map the crawled property ows_q_USER_AuthorByline as the first property when populating the managed property CreatedBy. The same mapping is done to the AuthorOWSUSER managed property, which is ok, as this property always had all data included.
The best option in my opinion is for Microsoft to remove this mapping, and create a new AuthorByLine managed property instead. That’s the way SharePoint developers have been taught to do when introducing new values. You can also change the mapping yourself, but that might mess up some oob web parts.
I’ve recently been tasked to optimize a search result page for a customer, as they have a “feeling” it’s not working out. For the record, I did not create the existing layout; if I did I would not write this post :)
The lesson to be learned is: Keep your UI clean, remove the clutter, and stick to science
I’ve long learned long ago that UX is very subjective and often emotionally loaded, and I do now want to force my views onto others without some backing. First off I got hold of the web server logs and wrote a small utility to parse out all the search queries going back a couple of months. By looking at the query strings I could easily pinpoint where in the UI people were clicking, thus providing me documented metrics on what parts of the current UI works, and which ones doesn’t.
Note: There is no out-of-the-box way of measuring where a user click in SP2010 or SP2013 search, so you have to figure out a way to do this yourself by either adding script and custom logging to the page, or parse the IIS logs as I did.
