Lots of edits

Walkthrough Guide/03_Web_API/README.md

@@ -4,17 +4,19 @@
 
 Azure App Service is Microsoft’s fully managed, highly scalable platform for hosting web, mobile and API apps built using .NET, Java, Ruby, Node.js, PHP, and Python.
 
-As App Service is fully managed, we only need to worry about setting the maximum number of instances on which we want to run our backend app on. Microsoft will then manage the scaling and load balancing across multiple instances to ensure your app perform well under heavy load. Microsoft manages the underlying compute infrastructure required to run our code, as well as patching and updating the OS and Frameworks when required. 
+ App Service is fully managed, and allows us to set the maximum number of instances on which we want to run our backend app on. Microsoft will then manage the scaling and load balancing across multiple instances to ensure your app perform well under heavy load. Microsoft manages the underlying compute infrastructure required to run our code, as well as patching and updating the OS and Frameworks when required. 
 
 Before we can deploy an App Service instance, we need to create a resource group to hold today's services. 
 
 ### 1.1 Resource Group
 
-Resource groups can be thought of as logical containers for your Azure Resources. You may wish to create separate resource groups per location, or alternatively, you may wish to have one resource group per project.
+Resource groups can be thought of as containers for your Azure Services (Resources). You may wish to create separate resource groups per location, or alternatively, you may wish to have one resource group per project.
 
 In this workshop, we’ll be deploying just one resource group to manage all of our required services. 
 
-Resource groups are great for grouping all the resources associated with a mobile application together. During development, it means you can delete all the resources in one operation. For production, it means you can see how much the service is costing you and how the resources are being used.
+Resource groups are great for grouping all the services associated with a solution together. During development, it means you can quickly delete all the resources in one operation! 
+
+when in production, it means we can see how much the services are costing us and how the resources are being used.
 
 ### 1.2 Create Resource Group
 ![Create new Resource Group](Assets/CreateResourceGroup.png)
@@ -33,11 +35,11 @@ Navigate to the newly created Resource Group.
 ### 1.3 App Service Plan
 
 #### 1.3.1 Overview 
-In App Service, an app runs in an App Service plan. An App Service plan defines a set of compute resources for a web app to run. These compute resources are analogous to the server farm in conventional web hosting. One or more apps can be configured to run on the same computing resources (or in the same App Service plan).
+In App Service, an app runs in an App Service plan. The App Service plan defines a set of compute resources for a web app to run. These compute resources are analogous to the server farm in conventional web hosting. One or more apps can be configured to run on the same computing resources (or in the same App Service plan).
 
 When you create an App Service plan in a certain region (for example, West Europe), a set of compute resources is created for that plan in that region. Whatever apps you put into this App Service plan run on these compute resources as defined by your App Service plan. Each App Service plan defines:
 
-* **Region** (West US, East US, etc.)
+* **Region** (West Europe, South UK, etc.)
 * **Number of VM instances**
 * **Size of VM instances** (Small, Medium, Large)
 * **Pricing tier** (Free, Shared, Basic, Standard, Premium, PremiumV2, Isolated, Consumption)
@@ -52,17 +54,19 @@ From within your new Resource Group, do the following:
 
  ![Create new App Service Plan](Assets/CreateNewAppServicePlan.png)
 
- The process for creating an App Service Plan is straightforward but you have a couple of decisions to make. The first decision is where is the service going to run. In a production environment, the correct answer would be "near your end user". In development, we'd want our app running "Close to the developers". You'll have lots of options for where to deploy the plan, so give some thought about where most requests will be coming from and pick a location that's as close as possible. 
+ Creating an App Service Plan is easy but we have to consider where are users are? We want our services to be running as close to our users as possible as this greatly increases performance. 
 
  ![Create new App Service Plan](Assets/ConfigureAppServicePlan.png)
 
- The second decision you'll have to make is what to run the service on; also known as the Pricing tier. If you Click View all, you will see you have lots of choices. F1 Free and D1 Shared, for example, run on shared resources and are CPU limited. You should avoid these as the service will stop responding when you are over the CPU quota. That leaves Basic, Standard, and Premium. Basic has no automatic scaling and can run up to 3 instances - perfect for development tasks. Standard and Premium both have automatic scaling, automatic backups, and large amounts of storage; they differ in features: the number of sites or instances you can run on them, for example. Finally, there is a number after the plan. This tells you how big the virtual machine is that the plan is running on. The numbers differ by the number of cores and memory.
+ We also need to consider how much Compute resources we think we'll need to meet demand.
+ 
+  Clicking 'View all', shows all the different optiosn we have (it's a lot!). I wont list what their differences are as their listed in the portal, but keep it mind, with the cloud we don't need to default to over-provisioning. We can scale up later if we have to! 
 
-For our purposes, a B1 Basic site is enough to run this workshop project. More complex development projects should use something in the Standard range of pricing plans. Production apps should be set up in Standard or Premium pricing plans.
+For this workshop, a B1 Basic site will be more than enough to run this  project. More complex development projects should use something in the Standard range of pricing plans. Production apps should be set up in Standard or Premium pricing plans. 
 
 Once you have created your app service plan and saved it, Click "Create".
 
-The creation of the service can take a couple of minutes. You can monitor the process of deployment by clicking on the Notifications icon. This is in the top bar on the right-hand side and looks like a Bell. Clicking on a specific notification will provide more information about the activity. 
+The deployment of the new service can take a few minutes but you can watch its progress in the "Bell" notification area in the toolbar. 
 
  ![Create new App Service Plan](Assets/CreateNewAppServicePlan.png)
  
@@ -89,7 +93,9 @@ You should see something similar to the image below:
  ![Create new App Service Plan](Assets/AppServiceDeployed.png)
 
 ### 1.5 Deploy your own apps to App Service
- Azure App Service has many options for how to deploy our code. These include continuous integration, that link to Visual Studio Team Services or GitHub, integrations with cloud storage providers like OneDrive and the venerable but trusty FTP mechanisms. If none of those suit you, you can publish right from Visual Studio. Below you can see how I publish using the built-in Azure integrations in Visual Studio for macOS. You'll find the same is possible in Windows but the UI might be slightly different. 
+ Azure App Service has many options for how to deploy our code. These include continuous integration, which can link to Visual Studio Team Services or GitHub. 
+ 
+ We could also use FTP to upload the project, but we're not animals, so we wont. Below you can see how I publish using the built-in Azure integrations in Visual Studio for macOS. You'll find the same is possible in Windows but the UI might be slightly different. 
 
  ![Open the Web API Project in Visual Studio](Assets/VisualStudioMacWebApiProject.png)
 Navigate to **Build** > **Publish** > **Publish to Azure**

Walkthrough Guide/07_Mobile_Overview/README.md

@@ -0,0 +1,26 @@
+![Banner](Assets/Banner.png)
+
+# 1. Mobile Overview
+  The mobile app currently run on both iOS and Android devices using Xamarin.Forms. Although UWP, macOS and Linux support should technically also work but they're outside the scope of todays learnings.
+
+![iPhone App Design](Assets/AppDesign.png)
+
+### 2.1 Development SDK
+The apps have been built with [Xamarin.Forms](https://github.com/xamarin/Xamarin.Forms) targetting .NET Standard 2.0. You should find all your favourite .NET libraries will work with the both the backend (also targeting .NET Standard 2.0) and the mobile apps. We're using C#, though we could have picked F#. We opted not to, given we're terrible F# developers and we want you to learn something today. If you fancy learning a little bit of information on functional programming with Forms, then checkout the [blog post](http://www.charlespetzold.com/blog/2015/10/Writing-Xamarin-Forms-Apps-in-FSharp.html) by Charles Petzold (author of the [Xamarin.Forms ebook](https://developer.xamarin.com/guides/xamarin-forms/creating-mobile-apps-xamarin-forms/)), who writes a guide on how to get started. 
+
+### Introduction to Xamarin.Forms 
+Xamarin.Forms is an open-source cross-platform developement library for building native apps for iOS, Android, Mac, Windows, Linux and more. By picking Xamarin.Forms, we're able to reuse our previous experiance with Silverlight, WPF and UWP development to target a variety of new platforms. 
+
+Xamarin.Forms comes with 24 controls out of the box, which map directly to their native type. For example, a Xamarin.Forms Button will actually create a Widget.Button on Android and UIKit.UIButton on iOS. Forms provides a consistant API across all the platforms it supports. This allows us to ensure that functionality we call on iOS will behave the same on Android.
+
+Forms is a great way to leverage existing C# and .NET knowleadge to build apps for platforms you may have historically considered not .NET compatbile. 
+
+### 2.2 Mvvm with FreshMvvm
+We opted to use [FreshMvvm](https://github.com/rid00z/FreshMvvm) as our Mvvm library due to its small size and flexibility. Its specifically designed for Xamarin.Forms and offers lots of helpful extensions around navigation which we make full use of. 
+
+### 2.3 Architecture 
+We've tried to keep platform specific code to a mininum with the development of this app. This is because we wanted you to see how its possible to create pleasent user experiances whilst maximising code reuse.
+
+
+#### Core Project
+The core project contains our app's Pages, ViewModels (we call them PageModels), Models and network services. 

Walkthrough Guide/11_Authentication/README.md

@@ -1,7 +1,7 @@
 ![Banner](Assets/Banner.png)
 
 # Authentication 
-Although adding Authentication in workshop can be troublesome (you might not have permissions to be deploying Auth services in your Azure Subscription), its an important enough topic that we've opted to include a guide regardless. We do not intend for you to implement authentication into this mobile app 
+Adding Authentication to our app and backend is a little outside of the scope of todays workshop due to time constraints. We believe Authentication is an important enough topic that we've opted to include a guide for you to get an understanding of the key concepts required to implement any Indentity Provider in to your projects (Obviusly we'd love it if you looked at Active Directory). 
 
 ## Concepts
 One of the very first things you want to do when developing a mobile app is to provide users with a unique experience. For our field service app, this could be as simple as providing a job list for the user who is logged in. In more complex applications, this is the gateway to role-based access controls, group rules, and sharing with your friends. In all these cases, properly identifying the user using the phone is the starting point.
@@ -53,7 +53,9 @@ https://myamazingapp-staging.azurewebsite.nets
 
 This means the redirect URL would need to be set to https://myamazingapp-staging.azurewebsite.nets.auth/login/facebook/callback
 
-To test authentication in the staging slot.  
+To test authentication in the staging slot.
+
+
 
 As you can see, we now have two 
 

Walkthrough Guide/README.md

@@ -18,8 +18,26 @@ The entire solution is available to download from Github and licensed under MIT
 
 ![Cloning Solution from GitHub](Assets/CloneGITRepository.gif)
 
+## 2. Walkthrough Guides
 
-## 2. Mobile App
+1. [Setup]()    
+### Azure 
+2. [Architecture Options](02_Architecture_Options/README.md)
+3. [Web API & App Services](03_Web_API/README.md)
+4. [Data Storage & Search](04_Data_Storage/README.md)
+5. [API Management]()
+6. [Functions & Cognitive Services]()
+### Mobile App
+7. [Overview]()
+8. [Network Services]()
+9. [Anayltics & Push]()
+10. [Chatbot]()
+11. [Authentication]()
+
+
+
+
+## 3. Mobile App
 The mobile app currently run on both iOS and Android devices. UWP, macOS and Linux support should technically also work but they're outside the scope of todays learnings. 
 
 ![iPhone App Design](Assets/AppDesign.png)