Conversational AI: Best Practices for Building Bots
Elaine Chang, Vishwac Sena Kannan

This session focused on the best practices to build bots at every step of the development cycle.
And breaking news, Bot development follows the same best practices as any other development!

You should define what you want to achieve with the bot. It must add value, be accessible and be effective.

You should include domain experts when designing your bot and iterate with some final users to make an effective design. Also plan how your bot should react, but do not over do it at the start. Start simple, and grow in complexity step by step later.

For example, you should plan simple interaction at first, no AI. And make sure to measure the users interaction with your bot to have successfully core features. Later you can think of adding adaptive cards for faster and prettier interactions, then move on language understanding and other advanced features.

You should also set success metrics for your bot to achieve, making sure your bot is useful to your users.

When planning your conversation dialogs, always think to add escape hatches to let your users start over, especially if your bot is doing something critical.

Finally when your bot is deployed and used, you must have some ways to monitor it and get feedback from your users.

And always take those metrics into account to enhance your bot over time.

Conversation AI: What’s New?
Chris Mullins, Darren Jefford

As a bot developer, I waited a lot from this session and wasn’t let down! So much new cool features in this BotBuilder SDK v4.

Unfortunately it also renders a lot of the BotBuilder SDK v3 obsolete. A lot of problems that I’ve tackled down with difficulties are now handled by a simple turn key feature.

New features of the BotBuilder SDK v4:

• Turnkey authentication: Just like WebApp, we now can configure authentication into the Azure portail for our bot, so that it can request the user to connect at the right time.
• New languages supported: Java and Python
• New command line tools: « msbot » (manage configuration file of the bot), « luis » (manage Luis), « qnamaker » (manage QnA Maker), « az bot » (command to create/manage bot resources on Azure – useful for automated deployment)
• LuDown and LuDown CLI – a Markdown variant to give a training sets of data to Luis. « ludown.exe parse toluis » parse the Markdown file and configure Luis with the parsed file.
• BotBuilder now runs on ASP.NET Core!
• Middleware (ex. Machine Translation Middleware that translates whatever language the user use to english for the bot to handle, then the bot speaks english but it’s translated to the user’s language through the middleware)
• Visual Studio has a new Bot Template for the BotBuilder v4

The Bot Framework Emulator has been redone entirely. It nows supports plugins and transcript files. Thanks to the Luis and QnA plugins, we can train our AIs directly from the Bot Framework Emulator based on what we tell our bot.

Luis.ai also packs a bunch of new features:

• Integrated experiences: Luis new gives others’ API data in a single call (Sentiment analysis, Automatic Machine Translation)
• Luis has been enhanced for better privacy (GDPR and such)
• New ways to recognize keywords: Patterns (I want to fly from [city:origin] to [city:destination]) / Regex / Key phrases
• Luis gives guidance to enhance its training (ex. « There’s not enough utterances for this intent – Bad training », « This utterance is duplicated/too close to another one from another intent »

QnAMaker new features:

• General Availability since monday
• Hosted by our Azure Subscription
• No more throttling of questions
• GDPR and other privacy laws compliant
• Better portal. Same Test/Inspect tools as Luis

New Dispatcher tool that connect to LUIS and QnAMaker to check if everything’s alright.

New Project Conversation Learner AI from Microsoft Research, an AI that can predict what to say based on the ongoing conversation with a very simple and user-friendly configuration portal.

New PersonalityChat feature that allows to adapt the way our bot talks to the user based on a setting (Business, Friendly, Humorous).
Ex. User: « Hello », Bot: « Hello, how are you today? »
Ex. User: « Yo », Bot: « ‘Sup »

Links:
http://aka.ms/PersonalityChat
http://aka.ms/BotBuilderOverview

C’est une évidence, mais il est important de rappeler que la collaboration entre développeurs est de plus en plus importante pour plusieurs raisons :

• On cherche à augmenter la fréquence des releases
• Les équipes sont de plus en plus distribuées
• Et on a toujours besoin de feedback à temps

Aujourd’hui on peut déjà collaborer via du partage d’écran, du contrôle de sources ou des messageries instantanées, mais globalement ça peut manquer d’interactivité ou prendre du temps en mise en œuvre. C’est là le but de VS Live Share : fournir une solution de collaboration en temps réels directement depuis son IDE !

Pour lancer une session il suffit de cliquer sur le bouton Share pour obtenir une URL à partager avec son collègue qui a juste besoin d’avoir installé l’extension sur son Visual Studio. Sans rien avoir téléchargé ni installé (ni les sources, ni le dépendances, ni les frameworks), on peut démarrer une session de pair programming :

• On peut soit suivre exactement ce que fait le développeur Host ou suivre sa propre exploration des sources
• Chacun peut éditer le code de son côté
• On partage la même session de debug
• Le Host peut aussi partager son serveur local ou sa base locale (ça ne partage pas l’écran, chacun peut par exemple ouvrir le site dans un navigateur différent)

VS Live Share fonctionne sur de nombreux langages et types d’application.

Une session Live Share est sécurisée : les invités sont authentifiés, la connexion est encryptée et le host ne partage que ce qu’il souhaite. Les fichiers du .gitignore sont masquées dans le Live Share, plus ceux listées dans un fichier .vsls.json.

Pour télécharger les extensions http://aka.ms/vsls.

Ne reste plus qu’à tester sur un projet !

Developing for Sets on Windows 10
Raymond Chen, Jason Watson

This session was about how to adapt our Win32/UWP apps to provide a great experience on Windows Sets and Windows Timeline.

Windows Sets allows to group apps together in a single window, much like a web browser do using tabs.
With this, we can group all apps related to do a single task.

For example, I have my solution opened in Visual Studio, I debug my website in Firefox, but I need to search a few Stackoverflow topics, while having my Outlook and Slack opened to stay connected to my colleagues.

I could group Visual Studio, my website and the stackoverflow posts inside a single set, while having my Outlook/Slack or anything else inside another Set.

Windows 10 can automatically restore a previous Set and/or tab from the Timeline.

In this session, we were told that in order to provide a great experience with Sets to our users we should:

• Support multi instancing: This is the default for Win32 apps, but not for UWP. Only a single manifest option is required to enable it
• User activities: We should store the user’s activities (such as interacting with an item in the app) in the Microsoft Graph. That way Windows 10 is able to display it into the Windows Timeline and provide the user with a really quick way to resume what they’ve done
• Support Window grouping: When our app need to open another app, we can specify if it should be opened in the same Set or in another one. The user can set their preferences globally in the Windows Settings
• App visuals: Our apps should customize its tab’s color and icon in the Set. Fortunately it is the exact same API than the Custom TitleBar API of UWP
• BackButton : Since Windows Sets introduces a new chrome for our app’s window. We should use the normalized BackButton provided by Microsoft

API wise: the ones for UWP are really simple.
Each bullet point is max 5 lines of code.
For Win32 (WinForms/WPF), the API is quite complex. We need to do P/Invoke call.

Links:
http://aka.ms/DesignForSets
http://aka.ms/FluentBackButton

What’s New in Xamarin.Forms 3.0
David Ortinau

In this quick session (45min compared to 75min normally), David talked both about the recent past of Xamarin.Forms, the new Xamarin.Forms 3.0 and what to expect in the future.

Past features and improvements since last year:

• First Public Roadmap: http://aka.ms/xfroadmap
• Native Forms: Embedding Xamarin.Forms inside native UI
• .NET Embedding: .NET code and Xamarin.Forms UI usable by native-native language like Objective-C
• .NET Standard 2.0 support
• Fast renderers, Layout compression, Startup optimization XAMLC, etc…

The new features of Xamarin.Forms 3.0 (available today)

• VisualStateManager: We can now apply styles to our app based on states, just like UWP. This is useful to handle different screen sizes
• Right to Left support with a single property (FlowDirection= »{x:Static Device.FlowDirection} »)
• Improved ResourceDictionaries: There’s now MergedDictionaries, hurray!
• FlexLayout: The equivalent of the CSS Flex layout. This allows for fewer UI layers and so performance boost
• CSS support: A mostly valid CSS that support currently almost all the control properties

The future of Xamarin.Forms:

• XAML Standard: Announced last year, we will have access to the first bits with Xamarin.Forms 3.1
• Compiled Binding (aka x:Bind) coming to Xamarin.Forms. That’s amazing!
• Project F100: Xamarin will take the top 100 annoyances and try to fix them. Such as the missing Border properties on all controls.

Xamarin.Forms 3.1-pre1 is available today !