The next stop of Search Explained Roadshow 2017 is New York City, NY!
Date: May 15-16, 2017
Venue: Avanade Innovation Center, 155 Avenue of the Americas, 6th floor, New York, NY
You have heard that SharePoint can find anything, but you are not seeing those results. You have important content that you want to find in the SharePoint Search center either in Office 365 or SharePoint on-premises. In this presentation Matthew will demonstrate how to run a search project for a specific kind of content, like Invoices, Templates, Sites, Contracts, Resumes, or whatever it is that you need to find. This session will outline the steps required for a successful search project and then demonstrate how to configure the content, the site, and the search center to deliver actionable results for your end users.
Come spend an hour and discover what you have been missing in SharePoint Search.
“Advanced Search” is a great feature, although not utilized in many cases. Out-of-the-box, it provides a default set of available options, which are too general for most businesses. However, it can be enhanced with some easy customizations.
In this post, I’m going to demonstrate one of the most powerful configurations of “Advanced Search” in SharePoint 2013/2016 and Office 365: how to add our custom property filters.
When it comes to the search experience, the look-and-feel of the search results are always a big question. In most cases, the out-of-the-box “ten blue lines” experience is not enough, creating custom Display Templates is almost always required.
During most of my career, I’ve been working as a consultant.
My 10+ years experience is that being responsible for Search is a huge challenge in every organization. First and foremost, because Search is challenging itself. Second, because each organization is unique, therefore needs a unique approach. There are too many components to make fit together.
Recently, Microsoft announced a new service, Azure Search.
The announcement says:
“Azure Search makes it easy to add powerful and sophisticated search capabilities to your website or application. Quickly and easily tune search results and construct rich, fine-tuned ranking models to tie search results to business goals.” Read more…
A couple of months ago, I wrote a post on the “Big Picture” of Search. This post describes how the logical concept of SharePoint 2013 looks like, how the components interact with each other and what is the relationship between them.
This, more technical post has driven several people to ask me about the business background of Search Based Applications. How to start? What to do? What to expect? How to plan for a Search Based Application project?
Here are some tips and best practices of mine.
First of all, let me clarify the definition of Search Based Applications. The main characteristics of SBAs are:
SBAs usually fit into more characteristics of the above, if not all. In a nutshell: we use a search engine to collect the data from various systems (crawling & indexing). The User Interface gets the data not directly from a database or storage but from the Search index, where we store structured and unstructured data together, from various content sources, with various data schemas. The UI is responsible to present this wide variety of information to the users, meeting their intents, expectations and need, while supporting their everyday job as much as possible.
First of all, one has to identify the pain points to get rid of, the needs and requirements of the business to fulfill. Implementing a Search Based Application is a project where you have to know the goals. For example, initial requirements of a Customer Dashboard:
As every project, creating a Search Based Application needs a team as well. Of course, this means the group of people who work on the implementation, but also a lot of others. You need someone who is the owner of Search in your organization. Who doesn’t own the SBA project only, but who is responsible for the continuity of the Search service, who analyzes the reports, collects the suggestions, suggests improvements to the business stakeholders, etc. As I usually say, Search needs gardeners. Planting the nicest trees and flowers is not enough. You need to garden them to keep the beauty of your yard while it grows and changes continuously.
You also need to have a plan for this growth. This is where Search Governance comes into the picture.
Once you defined the goals, it’s time to think about the UI. What users are the target group of this application? How your users will get the most out of this application? What they want to see? How they do work? What information they need, on what views, in which order? Etc. Etc.
You have to know the elements of the Search Experience in SharePoint to be able to talk about it. Some examples, still for the Customer Dashboard:
Besides these out-of-the-box elements you might need some custom components as well. For example, a map to display location information. Or a component for diagrams and charts. The limit is the sky…
Of course, it’s possible (and very likely) to define more than one search page in the application, in order to target the intent of users from different viewpoints. In this case, you have to identify the desired UI elements for each page. It’s very useful to create mockups for each and discuss them with the stakeholders.
Once you identified your goals and who will do what with the new application, it’s time to define the content sources that you want to work with now and later. Last summer, I wrote a post on Content Sources Best Practices, please use this for your reference here.
Besides crawling and indexing the various content sources, you have to be aware that Search Based Applications can use one or more Remote Search Indexes as well. For example if you would like to provide a “Related News” part on your Customer Dashboard, it might make sense to get the news from public sites like CNN or Financial Times. You might have customers who turns up in these news. The point here is to aggregate search-driven content into your application that you either don’t want or cannot crawl & index.
You can use a remote SharePoint (or FAST Search for SharePoint 2010) index this way, too. For example, if you have multiple farms in your enterprise.
Besides the special requirements of Search Based Applications, the implementation can be very similar to any common project. Deliverables make it to be special. If you prefer, it’s always good to follow an iterative, agile process where the business can follow the progress where everything is and can be really proactive. I really like this way of working.
It’s also important to talk about the performance. Usually, on the backend-side (crawling & indexing), a SBA application doesn’t need any more resources than any other search solution. These components don’t really care what we’ll do with the data stored in the index.
What might need more resources is the front-end: the WFE of SharePoint and the Query Processor. Maybe even the Analytics component.
What I would like to highlight in this post is three things: planning and gardening. Be prepared, plan your application, and don’t forget about the life “after”.