formatting changes

quickstarts/about-quickstarts.md

@@ -9,14 +9,14 @@ It focuses on the **hero feature** of the product and helps your users to start
 
 A good quickstart answers the following questions:
 
-+ What can this software/application do? Purpose of this quickstart
-+ Where can I find the product. It can point to a web address or a download link.
-+ How to get any required access keys or authentication credentials?
-+ How can I install/setup this software?
-+ How to configure the product? For a developer-focused product, this usually involves creating a hello world application. For an end-user product, this may mean setting up a corporate or user profile and choosing other preferences.
-+ How can I get started with the product? This is often a walkthrough of a simple but common use case, that helps the user learn the patterns of the product
-+ What other options (advanced features) are available for the user to explore in the product?
-+ What should the user do if something does not work (Link to troubleshooting guide or any support email ID)
+* What can this software/application do? Purpose of this quickstart
+* Where can I find the product. It can point to a web address or a download link.
+* How to get any required access keys or authentication credentials?
+* How can I install/setup this software?
+* How to configure the product? For a developer-focused product, this usually involves creating a hello world application. For an end-user product, this may mean setting up a corporate or user profile and choosing other preferences.
+* How can I get started with the product? This is often a walkthrough of a simple but common use case, that helps the user learn the patterns of the product
+* What other options (advanced features) are available for the user to explore in the product?
+* What should the user do if something does not work (Link to troubleshooting guide or any support email ID)
 
 
 A Quickstart guide is often confused with a Getting Started guide. Though both these documents help the users get acquainted with the product 
@@ -33,18 +33,18 @@ The table below gives quick differences between the two:
 ## Why do I need a Quickstart?
 Quickstarts are key to helping your users get started with the product as quickly as possible. 
 A good quickstart can improve customer experience and help to reduce costs by lowering the number of support requests. As a result:
-+ Make users comfortable using the product
-+ Lead to the willingness to handle complex workflows
-+ Explore more product features
+* Make users comfortable using the product
+* Lead to the willingness to handle complex workflows
+* Explore more product features
 
 ## Tips for writing a Quickstart
 
-+ Highlight the main (hero) feature of your product.
-+ Document the quickest/easiest way to implement the main (hero) feature  of your product.
-+ Pick a use case that the user can complete within 5-20 mts with a preference for a shorter time.
-+ Do not complicate the quickstart by including error scenarios/complex use cases
-+ Lengthy quickstarts can overwhelm users. Consider condensing or removing steps or reevaluating the scope of the quickstart.
-+ For code samples, ensure that you include:  
+* Highlight the main (hero) feature of your product.
+* Document the quickest/easiest way to implement the main (hero) feature  of your product.
+* Pick a use case that the user can complete within 5-20 mts with a preference for a shorter time.
+* Do not complicate the quickstart by including error scenarios/complex use cases
+* Lengthy quickstarts can overwhelm users. Consider condensing or removing steps or reevaluating the scope of the quickstart.
+* For code samples, ensure that you include:  
 	- Any required `import` or `using` statements
 	- Code comments that explain what the code does
 
@@ -53,10 +53,10 @@ A good quickstart can improve customer experience and help to reduce costs by lo
 
 Use this section to provide:
 
-+ Short description of your product and its purpose
-+ Describe what the user will accomplish in this quickstart
-+ Intended audience for this document 
-+ Basic knowledge that you expect the user to have before using this quickstart.
+* Short description of your product and its purpose
+* Describe what the user will accomplish in this quickstart
+* Intended audience for this document 
+* Basic knowledge that you expect the user to have before using this quickstart.
 
 Defining the audience right in the beginning will help the users identify if the quickstart is relevant for them or if they should continue searching.
 
@@ -68,9 +68,9 @@ For easy understanding, we recommend that you classify the prerequisites into di
 ## About the "Installation" section
 
 Use this section to provide:
-+ Basic instructions/commands to install your product
-+ Alternatively you can provide a link to the Installation guide
-+ For common software installation instructions provide links to the upstream docs
+* Basic instructions/commands to install your product
+* Alternatively you can provide a link to the Installation guide
+* For common software installation instructions provide links to the upstream docs
 
 > **Note:**
 > Some quickstarts may not require Installation instructions, in such scenarios, you can use this section to provide steps to tell the users 
@@ -83,11 +83,11 @@ This template breaks down the quickstart into **parts**. One part of the quickst
 You're welcome to follow this structure or use the step headings on their own.
 
 **Tips for writing steps in a quickstart**
-+ Start the heading with a verb and express the step/part headings as a complete thought. For example, you could use the heading Connect to the VM instance instead of just Connect. Avoid  
-+ For each step, provide some background information about the task so users know what they're about to do and why.
-+ Remember to orient your users when walking them through each step. If they need to open a particular file or dialog to complete the task, provide that information first.
-+ Use plain language and define the terminology of any technical term next to it.
-+ Include just one action in a step.
+* Start the heading with a verb and express the step/part headings as a complete thought. For example, you could use the heading **Connect to the VM instance** instead of just **Connect**.   
+* For each step, provide some background information about the task so users know what they're about to do and why.
+* Remember to orient your users when walking them through each step. If they need to open a particular file or dialog to complete the task, provide that information first.
+* Use plain language and define the terminology of any technical term next to it.
+* Include just one action in a step.
 
 > **Note:**
 > For additional tips on writing steps, see [Writing Procedural Steps](writing-tips.md#writing-procedural-steps) from **The Good Docs Project**.
@@ -96,7 +96,7 @@ You're welcome to follow this structure or use the step headings on their own.
 ## About the "Next Steps" section
 
 Use this section to provide links to other tutorials/articles that the users can try after completing the quickstart. 
-Consider the logical use case from the current quickstart that can act as a basis for your users’ next learning.  
+Consider a logical use case from the current quickstart that can act as a basis for your users’ next learning.  
 Optionally you can provide links to relevant resources, like blogs, reference docs, videos, how-tos, and so on under a new heading **See Also**.