Changes to grammar and formatting, with minor technical changes. (#2525)

* Changes to grammar and formatting, with minor technical changes.

Aside from grammatical and formatting changes, made some changes to the section discussing dialogs.

* Update articles/bot-service-design-conversation-flow.md

Co-authored-by: Jonathan Fingold <[email protected]>

* Update articles/bot-service-design-conversation-flow.md

Co-authored-by: Jonathan Fingold <[email protected]>

* Update articles/bot-service-design-conversation-flow.md

Co-authored-by: Jonathan Fingold <[email protected]>

* Update articles/bot-service-design-conversation-flow.md

Co-authored-by: Jonathan Fingold <[email protected]>

* Update articles/bot-service-design-conversation-flow.md

Co-authored-by: Jonathan Fingold <[email protected]>

* Update bot-service-design-conversation-flow.md

* Update bot-service-design-conversation-flow.md

Co-authored-by: Jonathan Fingold <[email protected]>

articles/bot-service-design-conversation-flow.md

@@ -17,41 +17,41 @@ ms.date: 11/19/2019
 In a traditional application, the user interface (UI) consists of a series of screens, and a single app or website can use one or more screens as needed to exchange information with the user.
 Most applications start with a main screen where users initially land, and that screen provides navigation that leads to other screens for various functions like starting a new order, browsing products, or looking for help.
 
-Like apps and websites, bots have a UI, but it is made up of **messages** rather than screens. Messages may contain buttons, text, and other elements, or be entirely speech-based.
+Like apps and websites, bots have a UI, but it is made up of _messages_ rather than screens. Messages may contain buttons, text, and other elements, or be entirely speech-based.
 
 While a traditional application or website can request multiple pieces of information on a screen all at once, a bot will gather the same amount of information using multiple messages. In this way, the process of gathering information from the user is an active experience; one where the user is having an active conversation with the bot.
 
-A well designed bot will have a conversation flow that feels natural. The bot should be able to handle the core conversation seamlessly, and be able to handle interruptions or switching topic of conversations gracefully.
+A well-designed bot will have a conversational flow that feels natural. The bot should be able to handle the core conversation seamlessly and be able to handle interruptions or switching topics gracefully.
 
 ## Procedural conversation flow
 
-Conversation with a bot is generally focused around the task a bot is trying to achieve, which is called a procedural flow. This is where the bot asks the user a series of questions to gather all the information it needs before processing the task.
+Conversations with a bot are generally focused on the task a bot is trying to achieve, which is called a procedural flow. This is where the bot asks the user a series of questions to gather all the information it needs before processing the task.
 
-In a procedural conversation flow, you define the order of the questions and the bot will ask the questions in the order you defined. You can organize the questions into logical *modules* to keep the code centralized while staying focused on guiding the conversational. For example, you may design one module to contain the logic that helps the user browse for products and a separate module to contain the logic that helps the user create a new order.
+In a procedural conversation flow, you define the order of the questions and the bot will ask the questions in the order you defined. You can organize the questions into logical groups to keep the code centralized while staying focused on guiding the conversation. For example, you may design one module to contain the logic that helps the user browse for products and a separate module to contain the logic that helps the user create a new order.
 
-You can structure these modules to flow in any way you like, ranging from free form to sequential. The Bot Framework SDK provides several libraries that allows you to construct any conversational flow your bot needs. For example, the `prompts` library allows you to ask users for input, the `waterfall` library allows you to define a sequence of question/answer pair, the `dialog control` library allows you to modularized your conversational flow logic, etc. All of these libraries are tied together through a `dialogs` object. Let's take a closer look at how modules are implemented as `dialogs` to design and manage conversation flows and see how that flow is similar to the traditional application flow.
+You can structure these modules to flow in any way you like, ranging from free form to sequential. The Bot Framework SDK provides a dialogs library that allows you to construct any conversational flow your bot needs. The library includes [waterfall dialogs](/azure/bot-service/bot-builder-concept-waterfall-dialogs) for creating a sequence of steps and prompts for asking users questions. For more information, see [Dialogs library](/azure/bot-service/bot-builder-concept-dialog).
 
 ![Application GUI flow compared to bot conversation flow](./media/designing-bots/core/dialogs-screens.png)
 
-In a traditional application, everything begins with the **main screen**.
-The **main screen** invokes the **new order screen**.
-The **new order screen** remains in control until it either closes or invokes other screens, such as the **product search screen**.
-If the **new order screen** closes, the user is returned to the **main screen**.
+In a traditional application, everything begins with the _main_ screen.
+The main screen invokes the _new order_ screen.
+The new order screen remains in control until it either closes or invokes other screens, such as the _product search_ screen.
+If the new order screen closes, the user is returned to the main screen.
 
-In a bot, everything begins with the **root dialog**.
-The **root dialog** invokes the **new order dialog**.
-At that point, the **new order dialog** takes control of the conversation and remains in control until it either closes or invokes other dialogs, such as the **product search dialog**.
-If the **new order dialog** closes, control of the conversation is returned back to the **root dialog**.
+In a bot that uses dialogs, everything begins with the _root dialog_.
+The root dialog invokes the _new order dialog_.
+At that point, the new order dialog takes control of the conversation and remains in control until it either closes or invokes another dialog, such as the _product search dialog_.
+If the new order dialog closes, control of the conversation returns back to the root dialog.
 
-For examples of how implement conversation flow, see how to [create your own prompts to gather user input](./v4sdk/bot-builder-primitive-prompts.md) and use dialogs to [implement sequential conversation flow](./v4sdk/bot-builder-dialog-manage-conversation-flow.md).
+For an example of how to implement a conversational flow using the dialog libraries, see [Implement sequential conversation flow](./v4sdk/bot-builder-dialog-manage-conversation-flow.md).
 
 ## Handle interruptions
 
 It may be tempting to assume that users will perform procedural tasks one by one in a neat and orderly way.
-For example, in a procedural conversation flow using `dialogs`, the user will start at root dialog, invoke the new order dialog from there, and then invoke the product search dialog. Then the user will select a product and confirm, exiting the product search dialog, complete the order, exiting the new order dialog, and arrive back at the root dialog.
+For example, in a procedural conversation flow using dialogs, the user will start at the root dialog and invoke the new order dialog. From the new order dialog, they invoke the product search dialog. Then when selecting one of the results listed in product search dialog, they invoke the new order dialog. After completing the order, they arrive back at the root dialog.
 
 Although it would be great if users always traveled such a linear, logical path, it seldom occurs.
-Humans do not communicate in sequential `dialogs`. They tend to frequently change their minds.
+People do not always communicate in sequential order. They tend to frequently change their minds.
 Consider the following example:
 
 ![User asks a question in response to a question from the bot](./media/bot-service-design-conversation-flow/stack-issue.png)
@@ -64,24 +64,23 @@ How should your bot respond?
 - Disregard everything that the user had done previously, reset the whole dialog stack, and start from the beginning by attempting to answer the user's question.
 - Attempt to answer the user's question and then return to that yes/no question and try to resume from there.
 
-There is no *right* answer to this question, as the best solution will depend upon the specifics of your scenario and how the user would reasonably expect the bot to respond. For more information see [Handle user interruption](v4sdk/bot-builder-howto-handle-user-interrupt.md).
+There is no *right* answer to this question, as the best solution will depend upon the specifics of your scenario and how the user would reasonably expect the bot to respond. See how to [Handle user interruptions](v4sdk/bot-builder-howto-handle-user-interrupt.md) for a bot that is designed to handle some types of interruptions.
 
 ## Expire a conversation
 
-There are times when it is useful to restart a conversation from the beginning.  For instance, if a user does not respond after a certain period of time.  Different methods for expiring a conversation include:
+There are times when it is useful to restart a conversation from the beginning.  For instance, if a user does not respond after a certain period of time.  Different methods for ending a conversation include:
 
 - Track the last time a message was received from a user, and clear state if the time is greater than a preconfigured length upon receiving the next message from the user.
-- Use a storage layer feature, such as CosmosDb Time To Live, to clear state after a preconfigured length of time.
+- Use a storage layer feature, such as Cosmos DB's [time-to-live](/azure/cosmos-db/how-to-time-to-live) feature, to clear state after a preconfigured length of time.
+
 <!--
 NOTE: in the future, provide guidance on an azure function queue or time trigger
-
 - Track the last time a message was received from a user, and run a Web Job or Azure Function to clear the state and/or proactively message the user.
 -->
 
-For more information see [How To: Expire a conversation](v4sdk/bot-builder-howto-expire-conversation.md)
+For more information see how to [Expire a conversation](v4sdk/bot-builder-howto-expire-conversation.md).
 
 ## Next steps
 
-Managing the user's navigation across dialogs and designing conversation flow in a manner that enables
-users to achieve their goals (even in a non-linear fashion) is a fundamental challenge of bot design.
-The [next article](~/bot-service-design-navigation.md) reviews some common pitfalls of poorly designed navigation and discusses strategies for avoiding those traps.
+Managing the user's navigation across dialogs and designing a conversational flow in a manner that enables users to achieve their goals (even in a non-linear fashion) is a fundamental challenge of bot design.
+The [Design bot navigation](bot-service-design-navigation.md) article reviews some common pitfalls of poorly designed navigation and discusses strategies for avoiding those traps.