diff --git a/docs/GLOSSARY.md b/docs/GLOSSARY.md
index ffadb1b..ff0e3e2 100644
--- a/docs/GLOSSARY.md
+++ b/docs/GLOSSARY.md
@@ -1,5 +1,11 @@
+# XOS-GUI Glossary
+
 ## SPA
-A single-page application (SPA) is a web application or web site that fits on a single web page with the goal of providing a user experience similar to that of a desktop application.
+
+A single-page application (SPA) is a web application or web site that fits on a
+single web page with the goal of providing a user experience similar to that of
+a desktop application.
 
 ## xProto
-That's a modeling language built on top of Google's Protocol Buffer.
\ No newline at end of file
+
+That's a modeling language built on top of Google's Protocol Buffer.
diff --git a/docs/README.md b/docs/README.md
index 1391e31..29a51c9 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -3,16 +3,18 @@
 Welcome the User Manual for the XOS GUI, your visual interface to operate on XOS.
 
 ## Overview
-The XOS User Interfaced is developed as a single page application (from now on referred as SPA) 
-and the main tools used are:
- - [Angular Js](https://angularjs.org/)
- - [Typescript](https://www.typescriptlang.org/)
- - [RxJS](http://reactivex.io/rxjs/)
- 
+
+The XOS User Interface is developed as a single page application (from now on
+referred as SPA) and the main tools used are:
+
+* [Angular Js](https://angularjs.org/)
+* [Typescript](https://www.typescriptlang.org/)
+* [RxJS](http://reactivex.io/rxjs/)
+
 ## General information
 
-The XOS GUI is available trough the OpenCORD gerrit at: https://gerrit.opencord.org/#/admin/projects/xos-gui
+The XOS GUI is available trough the OpenCORD gerrit at:
+[https://gerrit.opencord.org/#/admin/projects/xos-gui](https://gerrit.opencord.org/#/admin/projects/xos-gui)
 
-> For instructions on how to get the code please refer to:
-> - https://wiki.opencord.org/display/CORD/Working+with+Gerrit
-> - https://wiki.opencord.org/display/CORD/Setting+up+and+using+REPO
+For instructions on how to get the code please refer to the [XOS Guide](https://guide.opencord.org/getting_the_code.html)
+
diff --git a/docs/SUMMARY.md b/docs/SUMMARY.md
index 83e18cb..9bd03f6 100644
--- a/docs/SUMMARY.md
+++ b/docs/SUMMARY.md
@@ -5,8 +5,8 @@
 * [Architectural Overview](architecture/README.md)
     * [Module Strucure](architecture/gui-modules.md)
     * [Data Sources](architecture/data-sources.md)
-    
+
 * [Developer Guide](developer/README.md)
     * [Quickstart](developer/quickstart.md)
     * [Tests](developer/tests.md)
-    * [GUI Extensions](developer/gui_extensions.md)
\ No newline at end of file
+    * [GUI Extensions](developer/gui_extensions.md)
diff --git a/docs/architecture/README.md b/docs/architecture/README.md
index 2ed1154..139887e 100644
--- a/docs/architecture/README.md
+++ b/docs/architecture/README.md
@@ -1,31 +1,45 @@
 # Architectural Overview
 
-This chapter will guide you trough the general architecture of the XOS User Interfaces
+This chapter will guide you trough the general architecture of the XOS User
+Interfaces
 
 ## Ecosystem
 
-The XOS GUI is design to work in the XOS ecosystem, taking advantages of some of the features exposed by it.
-As an example the application is designed to discover the models registered in XOS 
-and auto-generate CRUD views for all of them, feature that is available thanks to our xProto modeling language.
-We are also leveraging the XOS-WS component, build on top of our Redis based pub-sub system, to provide a progressive caching mechanism.
+The XOS GUI is design to work in the XOS ecosystem, taking advantages of some
+of the features exposed by it.  As an example the application is designed to
+discover the models registered in XOS and auto-generate CRUD views for all of
+them, feature that is available thanks to our xProto modeling language.  We are
+also leveraging the XOS-WS component, build on top of our Redis based pub-sub
+system, to provide a progressive caching mechanism.
 
-The GUI ecosystem in XOS is composed by a pod of 5 Docker containers that comunicate as per the following diagram:
+The GUI ecosystem in XOS is composed by a pod of 5 Docker containers that
+comunicate as per the following diagram:
 
 ![xos_gui_ecosystem](images/xos-gui-ecosystem.png)
 
-We'll talk deeper about the data flow in the [Developer Guide](../developer/README.md) but here is the main role of each component:
+We'll talk deeper about the data flow in the [Developer
+Guide](../developer/README.md) but here is the main role of each component:
 
-#### XOS-CORE
-Is hosting the entire data-model and expose a `gRPC` API layer to let other components interact with the data model.
+### XOS-CORE
 
-#### CHAMELEON
-Chameleon is reponsible to expose a description of the models stored in `XOS-CORE` and to provide the bindings between `REST` and `gRPC`
+Is hosting the entire data-model and expose a `gRPC` API layer to let other
+components interact with the data model.
 
-#### REDIS
+### CHAMELEON
+
+Chameleon is reponsible to expose a description of the models stored in
+`XOS-CORE` and to provide the bindings between `REST` and `gRPC`
+
+### REDIS
+
 It is hosting a `redis` server used as primary pub-sub mechanism in the system
 
-#### XOS-WS
-Listen to `redis` events and transform them into `web-sockets` events in order to keep `XOS-GUI` updated
+### XOS-WS
 
-#### XOS-GUI
-Is hosting the GUI SPA and exposing it to the world through a web-server, in this case `nginx`
\ No newline at end of file
+Listen to `redis` events and transform them into `web-sockets` events in order
+to keep `XOS-GUI` updated
+
+### XOS-GUI
+
+Is hosting the GUI SPA and exposing it to the world through a web-server, in
+this case `nginx`
diff --git a/docs/architecture/data-sources.md b/docs/architecture/data-sources.md
index fe60491..a9f2877 100644
--- a/docs/architecture/data-sources.md
+++ b/docs/architecture/data-sources.md
@@ -1,19 +1,30 @@
 # The Data Sources module and the observable pattern
 
-The Data Source module is the actual glue between the Single Page Application and XOS and is responsible to keep data up to date in the UI. It use a combination of REST APIs (used to fetch the initial data) and Websocket events (used to incrementally extend those data) and create a set of Observables.
+The Data Source module is the actual glue between the Single Page Application
+and XOS and is responsible to keep data up to date in the UI. It use a
+combination of REST APIs (used to fetch the initial data) and Websocket events
+(used to incrementally extend those data) and create a set of Observables.
 
-An observable is basically a sequence of ongoing events ordered in time, to know more about this topics you can start here: [The introduction to Reactive Programming you've been missing](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754)
+An observable is basically a sequence of ongoing events ordered in time, to
+know more about this topics you can start here: [The introduction to Reactive
+Programming you've been
+missing](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754)
 
 The way synchronization is achieved follow this pattern:
-- When the application is loaded we read all the core model definition from the backend
-- For each Core Model 
-    - we read the existing data
-    - we store them in an Observable
-    - we generate a configuration for tables and forms 
-- Any view that need those data require the Model Observable and the Model Configuration
-- For any Websocket event we trigger a new event in the related Observable
+
+* When the application is loaded we read all the core model definition from the
+  backend
+* For each Core Model
+    * we read the existing data
+    * we store them in an Observable
+    * we generate a configuration for tables and forms
+* Any view that need those data require the Model Observable and the Model
+  Configuration
+* For any Websocket event we trigger a new event in the related Observable
 
 ![data-source-flow](images/data-source-flow.png)
 
-You can see an example of this behavior in `/src/app/views/crud/crud.ts`.
-This view is responsible to auto-generate a CRUD interface for each model in the system.
\ No newline at end of file
+You can see an example of this behavior in `/src/app/views/crud/crud.ts`.  This
+view is responsible to auto-generate a CRUD interface for each model in the
+system.
+
diff --git a/docs/architecture/gui-modules.md b/docs/architecture/gui-modules.md
index badb066..a011f1f 100644
--- a/docs/architecture/gui-modules.md
+++ b/docs/architecture/gui-modules.md
@@ -1,7 +1,7 @@
 # GUI Modules
 
-The application is divided into Modules, each one responsible for a different topic, here is a short list of the modules and their area of focus:
-
+The application is divided into Modules, each one responsible for a different
+topic, here is a short list of the modules and their area of focus:
 
 | Module | Topic |
 |--------|-------|
@@ -10,4 +10,5 @@
 | Core | Formerly called xosNgLib, contains a set of UI components to render table, forms, ... |
 | [DataSources](./data-sources.md) | Is the actual glue between the UI and the data model. It use a combination of REST API and Websocket to return data as Observables. |
 | Extender | It is responsible to extend the application with custom extension provided by services |
-| Service Graph | It's job is to read the service definition from the backend and represent it in a visual form, both at system and subscriber level |
\ No newline at end of file
+| Service Graph | It's job is to read the service definition from the backend and represent it in a visual form, both at system and subscriber level |
+
diff --git a/docs/developer/README.md b/docs/developer/README.md
index c4b57de..49709fc 100644
--- a/docs/developer/README.md
+++ b/docs/developer/README.md
@@ -1,6 +1,10 @@
 # Developer Guide
 
 In order to contribute to the XOS-GUI you'll need to have few tools installed:
-- [Vagrant](https://www.vagrantup.com/)
-- [NodeJs](https://nodejs.org/en/)
-- [repo](https://code.google.com/p/git-repo/) You can find instructions on the [wiki](https://wiki.opencord.org/display/CORD/Getting+the+Source+Code)
\ No newline at end of file
+
+* [Vagrant](https://www.vagrantup.com/)
+* [NodeJs](https://nodejs.org/en/)
+* [repo](https://code.google.com/p/git-repo/)
+
+You can find instructions on the [wiki](https://wiki.opencord.org/display/CORD/Getting+the+Source+Code)
+
diff --git a/docs/developer/gui_extensions.md b/docs/developer/gui_extensions.md
index 52bf7f7..1808aa5 100644
--- a/docs/developer/gui_extensions.md
+++ b/docs/developer/gui_extensions.md
@@ -1,60 +1,78 @@
 # Creating a custom GUI Extension
- 
-The CORD GUI is designed to be extensible. There are two cases in which we envision an extension to be needed:
-- Provide a different view over data
-- Create custom interfaces for services
- 
+
+The CORD GUI is designed to be extensible. There are two cases in which we
+envision an extension to be needed:
+
+* Provide a different view over data
+* Create custom interfaces for services
+
 The development process for both is the same.
-  
-## Starting Development 
+
+## Starting Development
 
 ### Option 1: Use the provided Yeoman xos-gui-extension generator
 
-The provided generator in `generator-xos-gui-extension` will generate a new GUI extension for you with the name of
-your choice and demo components based on a simplified `sample-gui-extension`. No refactoring necessary.
+The provided generator in `generator-xos-gui-extension` will generate a new GUI
+extension for you with the name of your choice and demo components based on a
+simplified `sample-gui-extension`. No refactoring necessary.
 
 #### Prerequisites
-You must have the Yeoman toolset installed via npm on your system. It can be installed by running `npm install --global yo`. 
-If you encounter any issues, full detailed instructions on installation can be found at the [Yeoman website](http://yeoman.io/codelab/setup.html).
+
+You must have the Yeoman toolset installed via npm on your system. It can be
+installed by running `npm install --global yo`.
+
+If you encounter any issues, full detailed instructions on installation can be
+found at the [Yeoman website](http://yeoman.io/codelab/setup.html).
 
 #### Installation
-Once you have successfully installed Yeoman, run the following to install the generator.
+
+Once you have successfully installed Yeoman, run the following to install the
+generator.
+
 ```bash
 cd ~cord/orchestration/xos-gui/generator-xos-gui-extension
 npm link
 ```
-To run the generator, simply run `yo xos-gui-extension` from whatever location in your file system you wish to place your
-new GUI extension. The extension will prompt for a name for your extension. 
 
+To run the generator, simply run `yo xos-gui-extension` from whatever location
+in your file system you wish to place your new GUI extension. The extension
+will prompt for a name for your extension.
 
 ### Option 2: Copy over sample-gui-extension
-If you choose not to use the Yeoman generator, you can copy over the contents of `sample-gui-extension` to your desired
-destination in your file system. If you are creating a GUI extension to used with a service, we suggest creating the 
-extension in a folder named `gui` in the service's `xos` folder as follows: `orchestration/xos_services/service_name/xos/gui/`.
-When changing the name of `sample-gui-extension`, you must be wary to change all instances of `sample-gui-extension` in the 
-extension folder.
 
- 
+If you choose not to use the Yeoman generator, you can copy over the contents
+of `sample-gui-extension` to your desired destination in your file system. If
+you are creating a GUI extension to used with a service, we suggest creating
+the extension in a folder named `gui` in the service's `xos` folder as follows:
+`orchestration/xos_services/service_name/xos/gui/`.  When changing the name of
+`sample-gui-extension`, you must be wary to change all instances of
+`sample-gui-extension` in the extension folder.
+
 ## Adding an extension to the build system
- 
-To deploy your GUI extension with a cord profile you'll need to reference it in `platform-install` and `build`.
-The following steps must be followed to ensure that your GUI extension builds correctly with XOS.
+
+To deploy your GUI extension with a cord profile you'll need to reference it in
+`platform-install` and `build`.  The following steps must be followed to ensure
+that your GUI extension builds correctly with XOS.
 
 ### Adding the extension to `docker_images.yml`
 
-Open `cord/build/docker_images.yml`. Locate the section of the file with other GUI extensions, and add the following:
+Open `cord/build/docker_images.yml`. Locate the section of the file with other
+GUI extensions, and add the following:
 
 ```yaml
 - name: xosproject/gui-extension-sample
     repo: sampleRepo # should match Gerrit repo name
     path: "xos/gui" # path to find extension in the repo (i.e. sampleRepo/xos/gui/)
 ```
-Please maintain ascending alphabetical order among the GUI extensions when inserting your own extension.
+
+Please maintain ascending alphabetical order among the GUI extensions when
+inserting your own extension.
 
 ### Adding the extension to the podconfig scenario
 
-Open the `config.yml` file of the podconfig scenario relevant to your GUI extension (e.g. cord, mock, local). 
-Locate the section titled `docker_image_whitelist` and add your GUI extension.
+Open the `config.yml` file of the podconfig scenario relevant to your GUI
+extension (e.g. cord, mock, local).  Locate the section titled
+`docker_image_whitelist` and add your GUI extension.
 
 ```yaml
 docker_image_whitelist:
@@ -67,23 +85,30 @@
 ```
 
 ### Adding the extension to the podconfig profile manifest
- 
-Open the `profile-manifest` relevant to the podconfig you're working on (eg: profile_manifests/frontend.yml) and locate `enabled_gui_extensions`.
-It may appear in two forms, depending whether or not there are others loaded extensions:
+
+Open the `profile-manifest` relevant to the podconfig you're working on (eg:
+profile_manifests/frontend.yml) and locate `enabled_gui_extensions`.  It may
+appear in two forms, depending whether or not there are others loaded
+extensions:
+
 ```yaml
 enabled_gui_extensions:
   - name: sample
     path: orchestration/xos-sample-gui-extension
 ```
-or: 
+
+or:
+
 ```yaml
 enabled_gui_extensions: []
 ```
-_NOTE: if it is not there, just create it._
+
+> NOTE: if it is not there, just create it.
 
 ### Change conf export settings to match extension name
 
 To add your extension, just add it to the list:
+
 ```yaml
 enabled_gui_extensions:
   - name: sample
@@ -91,9 +116,13 @@
   - name: myextension
     path: orchestration/myextension
 ```
-_NOTE: if it was defined as an empty array you'll need to remove the square brackets (`[]`)_
 
-You must make sure that the `name` field matches the directory in which the GUI Extension is built. You can update it in `conf/gulp.conf.js`.
+> NOTE: if it was defined as an empty array you'll need to remove the square
+> brackets (`[]`)
+
+You must make sure that the `name` field matches the directory in which the GUI
+Extension is built. You can update it in `conf/gulp.conf.js`.
+
 ```js
 exports.paths = {
   src: 'src',
@@ -104,18 +133,22 @@
   tasks: 'gulp_tasks'
 };
 ```
-and replace `sample` with your appropriate name. If you used the Yeoman generator, `sample` will already have been 
-replaced with the GUI extension name you chose.
 
-The `path` field identifies the directory (starting from the CORD `repo` root), in which your extension is stored.
-Loading from external sources is not currently supported.
+and replace `sample` with your appropriate name. If you used the Yeoman
+generator, `sample` will already have been replaced with the GUI extension name
+you chose.
+
+The `path` field identifies the directory (starting from the CORD `repo` root),
+in which your extension is stored.  Loading from external sources is not
+currently supported.
 
 ## Additional Tips
 
 ### Including Extra Files
 
-Additional necessary files (such as stylesheets or config files) can be added to the profile manifest as follows, 
-with the extension's `src` folder as the root. Here, we use `xos-sample-gui-extension` as an example.
+Additional necessary files (such as stylesheets or config files) can be added
+to the profile manifest as follows, with the extension's `src` folder as the
+root. Here, we use `xos-sample-gui-extension` as an example.
 
 ```yaml
 enabled_gui_extensions:
@@ -127,11 +160,14 @@
 
 ### Generating config files
 
-During development, you may find it necessary to create separate config files in order to include other files used in
-your extension (such as images). The path to your extension may vary depending on whether you are running it locally 
-(`./xos/extensions/extension-name`) vs. on a container in production (`./extensions/extension-name`).
+During development, you may find it necessary to create separate config files
+in order to include other files used in your extension (such as images). The
+path to your extension may vary depending on whether you are running it locally
+(`./xos/extensions/extension-name`) vs. on a container in production
+(`./extensions/extension-name`).
 
-You can create separate `customconfig.local.js` and `customconfig.production.js` files in the `conf/` folder, and then edit the 
+You can create separate `customconfig.local.js` and
+`customconfig.production.js` files in the `conf/` folder, and then edit the
 following portion of the appropriate `webpack.conf.js` file as follows:
 
 ```js
@@ -143,29 +179,41 @@
     ])
 ```
 
-`webpack.conf.js` will be used in a local development environment, such as when running `npm start`
+`webpack.conf.js` will be used in a local development environment, such as when
+running `npm start`
 
-`webpack-dist.conf.js` will be used in a production container after deploying a profile.
+`webpack-dist.conf.js` will be used in a production container after deploying a
+profile.
 
 ### Handy XOS Components and Services
 
-The following XOS components and services may be helpful to you in your GUI extension development.
+The following XOS components and services may be helpful to you in your GUI
+extension development.
 
 #### XosComponentInjector
-Allows for the injection of components into the XOS GUI by specifying a target element ID. Useful IDs include:
+
+Allows for the injection of components into the XOS GUI by specifying a target
+element ID. Useful IDs include:
+
 * `#dashboard-component-container`: the dashboard as seen on the XOS home
-* `#side-panel-container`: a side panel that can slide out from the right. However, there is also a `XosSidePanel` 
-service that can make development easier.
+* `#side-panel-container`: a side panel that can slide out from the right.
+  However, there is also a `XosSidePanel` service that can make development
+  easier.
 
 #### XosConfirm
-Allows for the creation of confirmation modal dialogs to confirm whether or not to execute a selected action.
+
+Allows for the creation of confirmation modal dialogs to confirm whether or not
+to execute a selected action.
 
 #### XosKeyboardShortcut
-Allows for the creation of custom user keyboard shortcuts. See the provided `components/demo.ts` as an example.
+
+Allows for the creation of custom user keyboard shortcuts. See the provided
+`components/demo.ts` as an example.
 
 #### XosModelStore
-Provides easy access to model ngResources provided by an XOS service. Can be used as follows in your component's
-associated TypeScript file:
+
+Provides easy access to model ngResources provided by an XOS service. Can be
+used as follows in your component's associated TypeScript file:
 
 ```typescript
 import {Subscription} from 'rxjs/Subscription';
@@ -176,7 +224,7 @@
     constructor(
       private XosModelStore: any,
     ){}
-    
+
     $onInit() {
         this.modelSubscription = this.XosModelStore.query('SampleModel', '/sampleservice/SampleModels').subscribe(
           res => {
@@ -193,8 +241,11 @@
 ```
 
 #### XosNavigationService
+
 Used to create custom navigation links in the left navigation panel.
 
 #### XosSidePanel
-Makes the injection of a custom side panel somewhat easier (no need to specify a target)
+
+Makes the injection of a custom side panel somewhat easier (no need to specify
+a target)
 
diff --git a/docs/developer/quickstart.md b/docs/developer/quickstart.md
index a27c800..6e94799 100644
--- a/docs/developer/quickstart.md
+++ b/docs/developer/quickstart.md
@@ -1,63 +1,82 @@
 # GUI Quickstart
 
-_We assume that you already have the CORD source downloaded with `repo`_
+> NOTE: We assume that you already have the CORD source downloaded with `repo`
 
 ## Setting up a podconfig
 
-For front-end development, using a podconfig with your choice of CORD flavors and  the `mock` or `local` scenario is sufficient.
-`mock` will create a vagrant VM running all the necessary containers, while `local` directly creates the containers on your machine, 
-so we recommend using `mock` when developing on your own laptop/desktop.
+For front-end development, using a podconfig with your choice of CORD flavors
+and  the `mock` or `local` scenario is sufficient.  `mock` will create a
+vagrant VM running all the necessary containers, while `local` directly creates
+the containers on your machine, so we recommend using `mock` when developing on
+your own laptop/desktop.
 
-Assuming you have already downloaded and ran the `cord-bootstrap.sh` script, setup is easy:
+Assuming you have already downloaded and ran the `cord-bootstrap.sh` script,
+setup is easy:
 
 ```bash
 cd ~/cord/build/
 make PODCONFIG={CORD_FLAVOR}-mock.yml config
 make build |& tee ~/build.out
-```  
+```
 
-Further details on the mock configuration and its setup can be found at [Mock Configuration Workflow](/xos/dev/workflow_mock_single.md)
+Further details on the mock configuration and its setup can be found at [Mock
+Configuration Workflow](/xos/dev/workflow_mock_single.md)
 
 ### Login credentials
-After the mock profile finishes building, you can find the credentials necessary to login into XOS by running the following:
 
-```
+After the mock profile finishes building, you can find the credentials
+necessary to login into XOS by running the following:
+
+```shell
 cat ~/cord/build/platform-install/credentials/xosadmin@opencord.org
 // save the output somewhere
 ```
 
 ## Serving the GUI in development mode
 
-Once your basic CORD config is up and running you should be able to access the GUI at `http://192.168.46.100/xos/`.
+Once your basic CORD config is up and running you should be able to access the
+GUI at `http://192.168.46.100/xos/`.
 
-NOTE: This is not your development copy, it is the one deployed inside a container in XOS and will not change until
-the container is torn down and redeployed.
+NOTE: This is not your development copy, it is the one deployed inside a
+container in XOS and will not change until the container is torn down and
+redeployed.
 
 To launch a development copy:
-```
+
+```shell
 // back to your local system
 cd cord/orchestration/xos-gui
 npm install
 npm start
 ```
 
-It will open your default browser at `localhost:3000`, proxy your API request to the local environment and watch for file changes.
+It will open your default browser at `localhost:3000`, proxy your API request
+to the local environment and watch for file changes.
 
-**Now you're ready to start working on it!**
+Now you're ready to start working on it!
 
-To get start, login using username `xosadmin@opencord.org` and the password you previously saved,
-then pick any file and make a change, and you'll see the GUI reload.
+To get start, login using username `xosadmin@opencord.org` and the password you
+previously saved, then pick any file and make a change, and you'll see the GUI
+reload.
 
 ## Configuring the `dev` GUI
 
-There are two configuration file available in the application, and they depend on the environment. You can find the various possibilities in `conf/app`, and they regard application constants, such as `apiEndpoint`, or branding elements, such as `projectName`.
+There are two configuration file available in the application, and they depend
+on the environment. You can find the various possibilities in `conf/app`, and
+they regard application constants, such as `apiEndpoint`, or branding elements,
+such as `projectName`.
 
 To load a different configuration file you can use two environment variables:
-- `PROXY`: you can use this variable to send request to an arbitrary XOS installation (eg: `clnode022.clemson.cloudlab.us:8080`)
-- `BRAND`: to configure style constants (eg: `cord`, `opencloud`)
+
+* `PROXY`: you can use this variable to send request to an arbitrary XOS
+  installation (eg: `clnode022.clemson.cloudlab.us:8080`)
+
+* `BRAND`: to configure style constants (eg: `cord`, `opencloud`)
 
 ## Working with an existing XOS installation
 
-You can also specify a different installation of XOS as backend by using the `PROXY` environment variable.
-For example, you can connect to a remote CORD-in-a-box installation for debugging purposes with:
+You can also specify a different installation of XOS as backend by using the
+`PROXY` environment variable.  For example, you can connect to a remote
+CORD-in-a-box installation for debugging purposes with:
 `PROXY=ms1106.utah.cloudlab.us:8080 npm start`
+
diff --git a/docs/developer/service_graph.md b/docs/developer/service_graph.md
index caf076c..6b785f9 100644
--- a/docs/developer/service_graph.md
+++ b/docs/developer/service_graph.md
@@ -1,64 +1,73 @@
 # How to operate on the Service Graph
 
-The service graph enable some features to simplify operators daily tasks, 
-here is a quick guide on how to use those fetaures.
+The service graph enable some features to simplify operators daily tasks, here
+is a quick guide on how to use those fetaures.
 
 ## Adding informations to the graph
 
-The Service Graph will render by default only the `Services`, but you can augment 
-the available information by pressing:
+The Service Graph will render by default only the `Services`, but you can
+augment the available information by pressing:
 
-- `Shift + f` toggle fullscreen mode
-- `Shift + s` to add `ServiceInstances` to the graph
-- `Shift + i` to add `Instances` to the graph (this require `ServiceInstances` to be shown)
-- `Shift + n` to add `Networks` to the graph (this require `Instances` to be shown)
+* `Shift + f` toggle fullscreen mode
+* `Shift + s` to add `ServiceInstances` to the graph
+* `Shift + i` to add `Instances` to the graph (this require `ServiceInstances`
+  to be shown)
+* `Shift + n` to add `Networks` to the graph (this require `Instances` to be
+  shown)
 
 ## Define the position of the Services in the graph
 
-XOS define a model called `ServiceGraphConstraint`, 
-that let you enforce constraints on the nodes position.
+XOS define a model called `ServiceGraphConstraint`, that let you enforce
+constraints on the nodes position.
 
 Here is a basic of how it works:
 
-#### Setting the services on a line
+### Setting the services on a line
 
 ```json
 ["a", "b", "c"]
 ```
+
 will position the nodes as:
-```
+
+```graph
 a -> b -> c
 ```
 
-#### Services as a tree
+### Services as a tree
 
 ```json
 ["a", ["b", "c"]]
 ```
+
 will position the nodes as:
 
-```
+```graph
    b
   /
- a 
+ a
   \
    c
 ```
 
-#### Empty spots in the graph
+### Empty spots in the graph
+
 ```json
 [[null, "a"], ["b", "c"]]
 ```
+
 will position the nodes as:
 
-```
+```graph
       b
-      | 
+      |
  a -> c
 ```
 
-_Note that all the notes not defined in the `ServiceGraphConstraint` model will float around_
+> NOTE: All the notes not defined in the `ServiceGraphConstraint` model will
+> float around
 
 ## Events listened by the Service Graph
 
-- `xos.sg.update` will render the graph again
\ No newline at end of file
+* `xos.sg.update` will render the graph again
+
diff --git a/docs/developer/tests.md b/docs/developer/tests.md
index 9e4ffa1..04af0fa 100644
--- a/docs/developer/tests.md
+++ b/docs/developer/tests.md
@@ -2,38 +2,48 @@
 
 ## Unit Tests
 
-There is a quite extensive suite of Unit Tests that are provided along with the code to help your development.
+There is a quite extensive suite of Unit Tests that are provided along with the
+code to help your development.
 
-These tests are defined using [Karma](https://karma-runner.github.io/1.0/index.html) as test runner and [Jasmine](https://jasmine.github.io/) as assertion library. Test are defied along with the code, you can look for any `.spec.ts` file in the source tree.
+These tests are defined using
+[Karma](https://karma-runner.github.io/1.0/index.html) as test runner and
+[Jasmine](https://jasmine.github.io/) as assertion library. Test are defied
+along with the code, you can look for any `.spec.ts` file in the source tree.
 
 You can execute them in two flavors:
-- Single run (this is the same flavor that is used on Jenkins): `npm test`
-- Watch mode: `npm run test:auto`
 
-While developing the GUI we'll suggest you to run the test in watch mode, and they'll be executed anytime a file changes. It will help you in catchings bugs immediately. It also provide more information on which tests are executed.
+* Single run (this is the same flavor that is used on Jenkins): `npm test`
+* Watch mode: `npm run test:auto`
+
+While developing the GUI we'll suggest you to run the test in watch mode, and
+they'll be executed anytime a file changes. It will help you in catchings bugs
+immediately. It also provide more information on which tests are executed.
 
 ## End to End Tests
 
-There is a suite of basic end to test that are defined using [protractor](http://www.protractortest.org/#/), an AngularJs oriented version of Selenium.
+There is a suite of basic end to test that are defined using
+[protractor](http://www.protractortest.org/#/), an AngularJs oriented version
+of Selenium.
 
 These tests can be found in the `e2e` folder.
 
-_NOTE: Require protractor to be installed as a global module._
+> NOTE: Require protractor to be installed as a global module.
 
 ### Setup
-```
+
+```shell
 webdriver-manager update
 webdriver-manager start
 ```
 
-### Run the tests
+#### Run the tests
 
-_Note that this tests are designed to work with the Mock R-CORD config_
+> NOTE: These tests are designed to work with the Mock R-CORD config
 
+```shell
+protractor conf/protractor.conf.js
 ```
-protractor conf/protractor.conf.js 
-```
- 
+
 Other paramenters you can pass are:
 
 | Variable Name | Description                                                  |
@@ -41,11 +51,12 @@
 | UI_URL        | Address of the GUI (deaults to `http://192.168.46.100/spa/#` |
 | UI_PWD        | Password to login (needed only for remote connections)       |
 | TIMEOUT       | Time allowed for each test                                   |
- 
- #### Test suites
- 
- If you need to run test for only a particural suite you can use:
- 
- `protractor conf/protractor.conf.js --suite login`
- 
- Suites are defined in `cong/protractor.conf.js`
\ No newline at end of file
+
+### Test suites
+
+If you need to run test for only a particural suite you can use:
+
+`protractor conf/protractor.conf.js --suite login`
+
+Suites are defined in `cong/protractor.conf.js`
+