QnA Maker

Bots and AI are all the rage these days as the next technologies promising to improve productivity, build efficiencies and capabilities that don’t exist today, change how humans engage with technology, and change the world.

You can see these technologies in play today in Alexa, Google Home, Siri, and Cortana.  These technologies have been integrated into laptops, tablets, and phones.  These same technologies have also spawned whole new families of consumer devices such as the Amazon Echo and other personal assistant devices.  These Bots and AI will eventually be deeply integrated in every device, application, and service.

The most basic and common use of bots has been developing Question and Answer solutions, such as Knowledge Base information and FAQs.  You often see this in adds for the new class of personal assistant devices…”Alexa, what’s the weather tomorrow?”, “Google, who won the Super Bowl?”, “Siri, how far is the north pole?”.  In these cases, the knowledge bases are Search Engine results, which are queried, indexed based on relevance, and read/written back to the user.

The thing about bots is that they can outperform a search engine. Search engines don’t generally give you answers to questions. They give you the source of the answer to your question. You still have to read through the sources to find the answer.  A bot, on the other hand, can actually answer the question directly, providing a link to the source for reference.

As for Office 365 and other Microsoft applications and services, they released the Bot Framework for developers to integrate into their applications.  The first service that Microsoft natively integrated bots into was Microsoft Teams (using a variation of the Bot Framework). Rest assured that it wouldn’t be long before they are integrated into all of Office 365 and other Microsoft products (including SharePoint on premises) for basic application and service based questions.

What’s most important to businesses (i.e. Office 365 customers) however is that bots will allow employees to add frequently used, business relevant and critical knowledge bases to Office 365 (including Teams, SharePoint, Outlook, etc.).  This can all but solve the age-old findability problems for most of their business-critical content, resources, and other assets without employees taking the time to search and identifying relevant results.  This is a game changer for most businesses as they can see huge productivity gains!

Up to now, implementing the Bot Framework or bots into Office 365 requires a developer to implement a bot.  This is why most organizational bot development examples thus far have been FAQs.  Although developing bots allow for big capabilities and potential for business beyond Question and Answer problem, it is a too common use case to need development efforts at each organization.  Microsoft has recognized that re-inventing the wheel here for every organization isn’t wise and has come out with the “QnA Maker” (in preview) to address this common need.  It also allows organizations to start building bots without needing development projects.

With the QnA Maker, the time-consuming part is populating the list of questions and answers to start. Once it’s set up, it’ll be smooth sailing. And you’ll save massive amounts of combined searching time within your organization.

QnA Maker

I first learned about the ‘QnA Maker’ from the good people at BIZZY.  They have SPFx solutions to integrate bots into SharePoint Online, take a look…

SharePoint 2013/Online Client Components SDK, are they the same thing???

I have been using the SharePoint 2013 Client Components SDK for more than two years now to develop console apps against both SharePoint 2013 and SharePoint Online.  This worked pretty well for me as then I could build a single console app that deploys solution assets to On-Prem Development environments and then deploy those same solution assets to Office 365 for integration, UAT, Staging, and Production environments.

As of September 2014, things changed!  All of a sudden there were two SDKs, a “SharePoint 2013 Client Component SDK” and a “SharePoint Online Client Component SDK”.  Both SDKs are named “sharepointclientcomponents_x64.msi” and sharepointclientcomponents_x86.msi” (x64 and x86 versions respectively for each SDK).  I was about to think that these are the same SDKs, but targeted for the On-Prem/Online environments only.  Then I looked at the file size and was confused…

SharePoint2013ClientComponentsSDKSharePointOnlineClientComponentsSDK

Why are these files named exactly the same name and published exactly the same date, but are different sizes???  So I started digging to find the answer…

After some searching, I found out that the version numbers of the SharePoint 2013 Client Components SDK is version 15.  This makes sense as this matches the version number of SharePoint 2013.  The publish date indicated to me that this SDK included all the changes from SharePoint 2013 Service Pack 1.  This is the same SDK I have been using all along for the past two years, but updated from Service Pack 1.

I also found out that the SharePoint Online Client Components SDK is version 16.  This is the version number for the next version of SharePoint On-Prem (SharePoint 2016 presumably).  At first I thought that was strange, but then after all the news and changes that Microsoft has been pumping out regarding the changes over the past year in Office 365 and the news that some (not all) of these changes will be pushed into the next On-Prem version, it started to make sense.

Here is what I think happened (only my perceptions from everything I could find out up to this point)…

SharePoint 2013 and SharePoint Online were using the same codebase (assemblies) up to the release of SharePoint 2013 Service Pack 1.  From that point on, SharePoint Online’s codebase version changed to 16 to reflect the new development in SharePoint Online only as promised by Microsoft when they beat us with their “Cloud First” strategy message.  The fact that the version number changed in SharePoint Online was first pointed out and documented by Gary Lapointe in his post “SharePoint 2013 Version 16.0.0.1810???”: http://blog.falchionconsulting.com/index.php/2013/08/sharepoint-2013-version-16-0-0-1810.

So what does this mean for developers and SharePoint ALM???

Well, in general we can no longer use the same codebase to deploy solutions for both SharePoint On-Prem and Online as they are likely to never be the same again (with On-Prem always lagging by a major version number).  Online development must start in a SharePoint Online development site and deployed/migrated to different tenants/site collections using the SharePoint Online Client Components SDK.

If we want to deploy the same codebase to both On-Prem and Online, then we will have to use the SharePoint 2013 Client Component SDK, but can not use any of the new capabilities of the Online version.  After reading “Evolution of SharePoint”: http://blogs.office.com/2015/02/02/evolution-sharepoint, this now makes sense.  Dan Holme did a great job explaining the news in detail on his post “The Evolution of Microsoft, SharePoint & Office 365”: http://www.itunity.com/article/evolution-sharepoint-office-365-856

Now if you do start with the SharePoint Online Client Component SDK and you want to target your solution to SharePoint 2013 (or vice versa), then you can follow “How do I run the Office 365 Developer Patterns and Practices against SharePoint 2013 On Premises”: https://github.com/OfficeDev/PnP/wiki/How-do-I-run-the-Office-365-Developer-Patterns-and-Practices-against-SharePoint-2013-On-Premises.