Note that this page details our proposal of how to handle authentication.
+Comments welcome.
+
+
We understand it may be necessary to authenticate the entire auspice website, or certain datasets.
+Our proposed solution to this is to perform all authentication on the server (remember that custom server handlers are already part of the auspice extension framework).
+This relies on cookies being available to the server on each and every request made from auspice, which should happen automatically.
+
Logging in / authenticating:
+
The intial request (which currently serves ) shall check that the user is authenticaed.
+If so, it can deliver the auspice index.html.
+If not, it can redirect to a login page which will set this cookie.
+Note that this login page is deliberately not part of auspice.
+
The login details (e.g. username) could be available to auspice via the getAvailable request (to explore).
+We will design a (customisable) login button / logged in user for auspice.
+It may be that the "login" button redirects to /login which is handled by the server as above.
+
Restricting datasets:
+
The datasets which are "available" to the client can be controlled by the server, such that only those with sufficient permissions are returned when the getAvailable request is processed.
+Likewise, requests for getDataset can be checked against the current cookie.
\ No newline at end of file
diff --git a/docs/customisations/authentication/index.html b/docs/customisations/authentication/index.html
new file mode 100644
index 000000000..e85f4bb02
--- /dev/null
+++ b/docs/customisations/authentication/index.html
@@ -0,0 +1,52 @@
+Authentication · Auspice
Note that this page details our proposal of how to handle authentication.
+Comments welcome.
+
+
We understand it may be necessary to authenticate the entire auspice website, or certain datasets.
+Our proposed solution to this is to perform all authentication on the server (remember that custom server handlers are already part of the auspice extension framework).
+This relies on cookies being available to the server on each and every request made from auspice, which should happen automatically.
+
Logging in / authenticating:
+
The intial request (which currently serves ) shall check that the user is authenticaed.
+If so, it can deliver the auspice index.html.
+If not, it can redirect to a login page which will set this cookie.
+Note that this login page is deliberately not part of auspice.
+
The login details (e.g. username) could be available to auspice via the getAvailable request (to explore).
+We will design a (customisable) login button / logged in user for auspice.
+It may be that the "login" button redirects to /login which is handled by the server as above.
+
Restricting datasets:
+
The datasets which are "available" to the client can be controlled by the server, such that only those with sufficient permissions are returned when the getAvailable request is processed.
+Likewise, requests for getDataset can be checked against the current cookie.
\ No newline at end of file
diff --git a/docs/customisations/client/componentInterfaces.html b/docs/customisations/client/componentInterfaces.html
new file mode 100644
index 000000000..fdd500236
--- /dev/null
+++ b/docs/customisations/client/componentInterfaces.html
@@ -0,0 +1,70 @@
+Injecting custom components · Auspice
These interfaces are very experimental and will change frequently.
+Documentation is somewhat incomplete.
+Please contact us (links at the bottom of the page) if you are using these customisations as we would like to develop them in a collaborative fashion.
+
+
One way to extend auspice is by replacing react components with your own custom components.
+These custom components will receive props defined here, which can be used to update the rendering of the component using the normal react lifecycle methods.
+Right now this is only available for the splash page and nav-bar components, whose interfaces are defined here.
+
Each component must be the default export of a javascript file which is specified in the (client) config JSON passed to auspice at build time (auspice build or auspice develop).
+
Splash component
+
Build config property:
+
{
+ "splashComponent": "<javascript file>"
+}
+
+
Available Props:
+
+
isMobile boolean
+
available available datasets and narratives
+
browserDimensions broswer width & height
+
dispatch callback
+
errorMessage callback
+
changePage callback
+
+
Nav-bar component
+
Build config property:
+
{
+ "navbarComponent": "<javascript file>"
+}
+
+
Available props:
+
+
narrativeTitle string
+
sidebar boolean. Is it to be displayed in the sidebar?
+
+
The navbar also receives the (possibly customised) sidebar theme which can be used to style components.
\ No newline at end of file
diff --git a/docs/customisations/client/componentInterfaces/index.html b/docs/customisations/client/componentInterfaces/index.html
new file mode 100644
index 000000000..fdd500236
--- /dev/null
+++ b/docs/customisations/client/componentInterfaces/index.html
@@ -0,0 +1,70 @@
+Injecting custom components · Auspice
These interfaces are very experimental and will change frequently.
+Documentation is somewhat incomplete.
+Please contact us (links at the bottom of the page) if you are using these customisations as we would like to develop them in a collaborative fashion.
+
+
One way to extend auspice is by replacing react components with your own custom components.
+These custom components will receive props defined here, which can be used to update the rendering of the component using the normal react lifecycle methods.
+Right now this is only available for the splash page and nav-bar components, whose interfaces are defined here.
+
Each component must be the default export of a javascript file which is specified in the (client) config JSON passed to auspice at build time (auspice build or auspice develop).
+
Splash component
+
Build config property:
+
{
+ "splashComponent": "<javascript file>"
+}
+
+
Available Props:
+
+
isMobile boolean
+
available available datasets and narratives
+
browserDimensions broswer width & height
+
dispatch callback
+
errorMessage callback
+
changePage callback
+
+
Nav-bar component
+
Build config property:
+
{
+ "navbarComponent": "<javascript file>"
+}
+
+
Available props:
+
+
narrativeTitle string
+
sidebar boolean. Is it to be displayed in the sidebar?
+
+
The navbar also receives the (possibly customised) sidebar theme which can be used to style components.
\ No newline at end of file
diff --git a/docs/customisations/client/sidebarTheme.html b/docs/customisations/client/sidebarTheme.html
new file mode 100644
index 000000000..cfb336cb1
--- /dev/null
+++ b/docs/customisations/client/sidebarTheme.html
@@ -0,0 +1,47 @@
+Sidebar theming · Auspice
The appearence of the sidebar can be customised by specifing a theme in the config JSON used to build auspice.
+This theme is then available (via styled-components) to the components rendered in the sidebar.
+It is also passed to the nav bar component as the theme prop.
\ No newline at end of file
diff --git a/docs/customisations/client/sidebarTheme/index.html b/docs/customisations/client/sidebarTheme/index.html
new file mode 100644
index 000000000..cfb336cb1
--- /dev/null
+++ b/docs/customisations/client/sidebarTheme/index.html
@@ -0,0 +1,47 @@
+Sidebar theming · Auspice
The appearence of the sidebar can be customised by specifing a theme in the config JSON used to build auspice.
+This theme is then available (via styled-components) to the components rendered in the sidebar.
+It is also passed to the nav bar component as the theme prop.
\ No newline at end of file
diff --git a/docs/customisations/introduction.html b/docs/customisations/introduction.html
new file mode 100644
index 000000000..102ff0734
--- /dev/null
+++ b/docs/customisations/introduction.html
@@ -0,0 +1,67 @@
+Extending Auspice · Auspice
It's possible to "extend" auspice and change the aesthetics and/or functionality.
+This allows custom builds of auspice each with their own appearence.
+nextstrain.org is one such custom build.
+
Developing and building auspice with extensions.
+
Auspice has two forms of extensions:
+
Client extensions
+
Customising the appearence and functionality of the client is achieved through code injection at build time.
+The available customisations are accessed through a <clientConfig> JSON with the following properties:
"hardcodedDataPaths" -- not yet documented, see these docs.
+
+
Server extensions
+
The client makes a number of requests which can be dynamically handled.
+Alternativly, the files can defined at build time such that no server is needed.
+See these docs for how to define the <serverHandlers> javascript file.
+
Developing & Building custom auspice versions
+
While it's possible to run these commands from the auspice source directory (using node auspice.js ...), it's preferable to run them from the repo containing the client / server customisations.
+This requires auspice to be installed globally (see above).
\ No newline at end of file
diff --git a/docs/customisations/introduction/index.html b/docs/customisations/introduction/index.html
new file mode 100644
index 000000000..102ff0734
--- /dev/null
+++ b/docs/customisations/introduction/index.html
@@ -0,0 +1,67 @@
+Extending Auspice · Auspice
It's possible to "extend" auspice and change the aesthetics and/or functionality.
+This allows custom builds of auspice each with their own appearence.
+nextstrain.org is one such custom build.
+
Developing and building auspice with extensions.
+
Auspice has two forms of extensions:
+
Client extensions
+
Customising the appearence and functionality of the client is achieved through code injection at build time.
+The available customisations are accessed through a <clientConfig> JSON with the following properties:
"hardcodedDataPaths" -- not yet documented, see these docs.
+
+
Server extensions
+
The client makes a number of requests which can be dynamically handled.
+Alternativly, the files can defined at build time such that no server is needed.
+See these docs for how to define the <serverHandlers> javascript file.
+
Developing & Building custom auspice versions
+
While it's possible to run these commands from the auspice source directory (using node auspice.js ...), it's preferable to run them from the repo containing the client / server customisations.
+This requires auspice to be installed globally (see above).
\ No newline at end of file
diff --git a/docs/customisations/server/charonAPI.html b/docs/customisations/server/charonAPI.html
new file mode 100644
index 000000000..02e93f3d5
--- /dev/null
+++ b/docs/customisations/server/charonAPI.html
@@ -0,0 +1,117 @@
+Auspice Server API · Auspice
This API is largely based off the interface used by nextstrain.
+Most probably it will change dramatically over the coming weeks.
+
+
The client (i.e. the auspice web page) makes requests to a server, for instance requesting a dataset file or requesting a listing of available datasets.
+The server is referred to as "charon".
+Currently the server needs to handle three requests (detailed below), which are made to the same domain as the client (this may be changeable in the future).
+
Auspice by itself includes handlers for these requests.
+These handlers source data from the local filesystem so that running auspice without extensions can view locally available datasets.
+
Customisations of auspice can provide their own handlers, allowing for multiple different use cases.
+For instance, auspice.us (currently located as a subdirectory of auspice) contains handlers to fetch datasets from github repos ("community" builds). The handlers used in nextstrain.org fetch datasets from S3 buckets.
+
Where are these "handlers" used?
+
During development of auspice, the dev-server needs access to these handlers in order to make process requests.
+Building of the auspice client (auspice build ...) doesn't need to know about these handlers, as the client will simply make requests to the API detailed below. (Currently this is different for serverless builds, see github.com/blab/ZEBOV for an example).
+Serving the auspice client (auspice view ...), or whatever custom server implementation you design, will need to use these handlers.
+
Providing these handlers to auspice build and auspice view
+
The handlers should be defined in a javascript file provided to those commands via the --handlers argument. This file should export three functions via:
Here's a pseudocode example of one of these functions.
+
const getAvailable = (req, res) => {
+ try {
+ /* collect available data */
+ res.json(data);
+ } catch (err) {
+ res.statusMessage = `error message to display in client`;
+ console.log(res.statusMessage); /* printed by the server */
+ return res.status(500).end();
+ }
+};
+
+
API description
+
Currently the client makes three requests:
+
+
/charon/getAvailable -- return a list of available datasets and narratives
+
/charon/getDataset -- return the requested dataset
+
/charon/getNarrative -- return the requested narrative
+
+
You can choose to handle these in your own server, or provide handlers to the auspice (dev-)server which are called whenever these requests are received (see above).
+
get available datasets: /charon/getAvailable
+
Query arguments:
+
+
prefix (optional) - the pathname of the requesting page in auspice.
+
+
Response shape:
+
{
+ "datasets": [
+ {"request": "URL of a dataset. Will become the prefix in a getDataset request"},
+ ...
+ ],
+ "narratives": [
+ {"request": "URL of a narrative. Will become the prefix in a getNarrative request"},
+ ...
+ ]
+}
+
+
get a dataset: /charon/getDataset
+
Query arguments:
+
+
prefix (required) - the pathname of the requesting page in auspice. Use this to determine which dataset to return.
+
deprecatedSecondTree (optional) - deprecated.
+
type (optional) -- if specified, then the request is for an additional file (e.g. "tip-frequencies"), not the main dataset.
+
+
Response shape:
+
+
This needs to be updated to schema 2.0. These docs should point to the schema definitions (currently in the augur repo).
+
+
The current main dataset response shape is:
+
{
+ "meta": "the schema 1.0 metadata json object",
+ "tree": "the schema 1.0 tree json object",
+ "_source": "the source (e.g. live, staging, github). Only used by the sidebar dataset selector",
+ "_url": "the URL to which auspice should update. Allows flu to redirect silently to flu/seasonal/..."
+}
+
\ No newline at end of file
diff --git a/docs/customisations/server/charonAPI/index.html b/docs/customisations/server/charonAPI/index.html
new file mode 100644
index 000000000..02e93f3d5
--- /dev/null
+++ b/docs/customisations/server/charonAPI/index.html
@@ -0,0 +1,117 @@
+Auspice Server API · Auspice
This API is largely based off the interface used by nextstrain.
+Most probably it will change dramatically over the coming weeks.
+
+
The client (i.e. the auspice web page) makes requests to a server, for instance requesting a dataset file or requesting a listing of available datasets.
+The server is referred to as "charon".
+Currently the server needs to handle three requests (detailed below), which are made to the same domain as the client (this may be changeable in the future).
+
Auspice by itself includes handlers for these requests.
+These handlers source data from the local filesystem so that running auspice without extensions can view locally available datasets.
+
Customisations of auspice can provide their own handlers, allowing for multiple different use cases.
+For instance, auspice.us (currently located as a subdirectory of auspice) contains handlers to fetch datasets from github repos ("community" builds). The handlers used in nextstrain.org fetch datasets from S3 buckets.
+
Where are these "handlers" used?
+
During development of auspice, the dev-server needs access to these handlers in order to make process requests.
+Building of the auspice client (auspice build ...) doesn't need to know about these handlers, as the client will simply make requests to the API detailed below. (Currently this is different for serverless builds, see github.com/blab/ZEBOV for an example).
+Serving the auspice client (auspice view ...), or whatever custom server implementation you design, will need to use these handlers.
+
Providing these handlers to auspice build and auspice view
+
The handlers should be defined in a javascript file provided to those commands via the --handlers argument. This file should export three functions via:
Here's a pseudocode example of one of these functions.
+
const getAvailable = (req, res) => {
+ try {
+ /* collect available data */
+ res.json(data);
+ } catch (err) {
+ res.statusMessage = `error message to display in client`;
+ console.log(res.statusMessage); /* printed by the server */
+ return res.status(500).end();
+ }
+};
+
+
API description
+
Currently the client makes three requests:
+
+
/charon/getAvailable -- return a list of available datasets and narratives
+
/charon/getDataset -- return the requested dataset
+
/charon/getNarrative -- return the requested narrative
+
+
You can choose to handle these in your own server, or provide handlers to the auspice (dev-)server which are called whenever these requests are received (see above).
+
get available datasets: /charon/getAvailable
+
Query arguments:
+
+
prefix (optional) - the pathname of the requesting page in auspice.
+
+
Response shape:
+
{
+ "datasets": [
+ {"request": "URL of a dataset. Will become the prefix in a getDataset request"},
+ ...
+ ],
+ "narratives": [
+ {"request": "URL of a narrative. Will become the prefix in a getNarrative request"},
+ ...
+ ]
+}
+
+
get a dataset: /charon/getDataset
+
Query arguments:
+
+
prefix (required) - the pathname of the requesting page in auspice. Use this to determine which dataset to return.
+
deprecatedSecondTree (optional) - deprecated.
+
type (optional) -- if specified, then the request is for an additional file (e.g. "tip-frequencies"), not the main dataset.
+
+
Response shape:
+
+
This needs to be updated to schema 2.0. These docs should point to the schema definitions (currently in the augur repo).
+
+
The current main dataset response shape is:
+
{
+ "meta": "the schema 1.0 metadata json object",
+ "tree": "the schema 1.0 tree json object",
+ "_source": "the source (e.g. live, staging, github). Only used by the sidebar dataset selector",
+ "_url": "the URL to which auspice should update. Allows flu to redirect silently to flu/seasonal/..."
+}
+
\ No newline at end of file
diff --git a/docs/customisations/server/serverless.html b/docs/customisations/server/serverless.html
new file mode 100644
index 000000000..f297411cd
--- /dev/null
+++ b/docs/customisations/server/serverless.html
@@ -0,0 +1,40 @@
+Deploying auspice without a server · Auspice
This API is experimental. Most probably it will change dramatically over the coming weeks.
+
+
Serverless builds
+
You may also choose to forego the server and hardcode the paths to the datasets.
+For an example of this see github.com/blab/ZEBOV -- specifically this part of the auspice config.
\ No newline at end of file
diff --git a/docs/customisations/server/serverless/index.html b/docs/customisations/server/serverless/index.html
new file mode 100644
index 000000000..f297411cd
--- /dev/null
+++ b/docs/customisations/server/serverless/index.html
@@ -0,0 +1,40 @@
+Deploying auspice without a server · Auspice
This API is experimental. Most probably it will change dramatically over the coming weeks.
+
+
Serverless builds
+
You may also choose to forego the server and hardcode the paths to the datasets.
+For an example of this see github.com/blab/ZEBOV -- specifically this part of the auspice config.
\ No newline at end of file
diff --git a/docs/en/index.html b/docs/en/index.html
new file mode 100644
index 000000000..5cb315136
--- /dev/null
+++ b/docs/en/index.html
@@ -0,0 +1,4 @@
+Auspice · Interactive exploration of phylodynamic & phylogenomic data.
AuspiceInteractive exploration of phylodynamic & phylogenomic data.
Communicating scientific results while also allowing interrogation of the underlying data is an integral part of the scientific process. Current scientific publishing practices hinder both the rapid dissemination of epidemiologically relevant results and the ability to easily interact with the data which was used to draw the inferences. Initially developed as part of the nextstrain project, it is a more general tool for building different websites to support these aims.
+
Interactive visualisation
Visualisation of bioinformatics results is an integral part of current phylodynamics, both for data exploration and communication. We wanted to build a tool that was highly interactive, versatile and customisable.
Auspice is a communication platform to quickly disseminate results to the wider community. Use it to generate server-backed or serverless websites to display your own datasets, with as many customisations as you desire.
Augur is a seperate toolkit for phylodynamic analysis with a focus on pathgen and outbreak tracking. It's designed to work seamlessly with auspice. See the nextstrain documentation to find out more.
+
Status: In Development
We're actively developing auspice to be more versatile and able to power many different websites. As such, the current API's are in flux while we develop this functionality. If you are interested in helping us develop these ideas and would like to use auspice to build your website then please contact us via email or twitter.
AuspiceInteractive exploration of phylodynamic & phylogenomic data.
Communicating scientific results while also allowing interrogation of the underlying data is an integral part of the scientific process. Current scientific publishing practices hinder both the rapid dissemination of epidemiologically relevant results and the ability to easily interact with the data which was used to draw the inferences. Initially developed as part of the nextstrain project, it is a more general tool for building different websites to support these aims.
+
Interactive visualisation
Visualisation of bioinformatics results is an integral part of current phylodynamics, both for data exploration and communication. We wanted to build a tool that was highly interactive, versatile and customisable.
Auspice is a communication platform to quickly disseminate results to the wider community. Use it to generate server-backed or serverless websites to display your own datasets, with as many customisations as you desire.
Augur is a seperate toolkit for phylodynamic analysis with a focus on pathgen and outbreak tracking. It's designed to work seamlessly with auspice. See the nextstrain documentation to find out more.
+
Status: In Development
We're actively developing auspice to be more versatile and able to power many different websites. As such, the current API's are in flux while we develop this functionality. If you are interested in helping us develop these ideas and would like to use auspice to build your website then please contact us via email or twitter.
\ No newline at end of file
diff --git a/docs/inputs.html b/docs/inputs.html
new file mode 100644
index 000000000..595c597b4
--- /dev/null
+++ b/docs/inputs.html
@@ -0,0 +1,44 @@
+Input file formats · Auspice
This page defines the format of the dataset JSONs which auspice visualises.
+If you are running auspice locally, these are the only files you need to worry about.
+For the format of the server reponses (if you are customising auspice) see here.
+
+
Please note that we also build bioinformatic tooling (augur) which produces JSONs specifically for visualisation in Auspice.
+However any compatible JSONs can be visualised by auspice.
+The data doesn’t have to be viral genomes, or real-time, or generated in Augur!
+We’re working on adding tutorials on how to convert BEAST results etc into the formats used by Auspice.
+
+
+
The current format of JSONs is in flux.
+When this branch is released it will require a unified JSON (schema v2.0) which you can see here.
+Helper functions will be available to convert between version 1.0 schemas and version 2.0.
\ No newline at end of file
diff --git a/docs/inputs/index.html b/docs/inputs/index.html
new file mode 100644
index 000000000..595c597b4
--- /dev/null
+++ b/docs/inputs/index.html
@@ -0,0 +1,44 @@
+Input file formats · Auspice
This page defines the format of the dataset JSONs which auspice visualises.
+If you are running auspice locally, these are the only files you need to worry about.
+For the format of the server reponses (if you are customising auspice) see here.
+
+
Please note that we also build bioinformatic tooling (augur) which produces JSONs specifically for visualisation in Auspice.
+However any compatible JSONs can be visualised by auspice.
+The data doesn’t have to be viral genomes, or real-time, or generated in Augur!
+We’re working on adding tutorials on how to convert BEAST results etc into the formats used by Auspice.
+
+
+
The current format of JSONs is in flux.
+When this branch is released it will require a unified JSON (schema v2.0) which you can see here.
+Helper functions will be available to convert between version 1.0 schemas and version 2.0.
\ No newline at end of file
diff --git a/docs/installation.html b/docs/installation.html
new file mode 100644
index 000000000..cea4cb4da
--- /dev/null
+++ b/docs/installation.html
@@ -0,0 +1,69 @@
+Installing auspice · Auspice
Auspice is written in Javascript and will require nodejs and npm (the node package manager) to install.
+If you are comfortable using conda these may be easily installed in your environment (see here).
+If you are on Linux or MacOS, you could also use nvm to insall these (see here).
+
Global NPM install
+
Auspice is avaliable as a npm package and can be installed simply via:
+
npm install --global auspice
+
+
Auspice is now available as a command-line program -- check by running auspice -h.
+Documentation for how to run auspice locally is available here.
+
Installing as a project's dependency
+
If you are building a customised version of auspice, you may want to include it as a dependency of that project.
+This allows you to pin the version, use continuous integration tooling and simplifies any code imports you may wish to use.
+
npm install --save auspice
+
+
+
Note that auspice is not available as a command line tool this way, but can be accessed from within the repo via npx auspice.
+See customising auspice for more information.
+
+
Installing from source
+
git clone git@github.com:nextstrain/auspice.git
+cd auspice
+npm install # install dependencies
+npm install -g . # make "auspice" available globally
+
+
Note that (at least on MacOS) this symlinks the source directory into the global node_modules folder so that changes to source code are automatically reflected in the globally available auspice command.
+We have had good success using a conda environment for development.
+
Developing
+
Install auspice from source (see above).
+Running auspice in development mode will automatically update as you change the source code:
\ No newline at end of file
diff --git a/docs/installation/index.html b/docs/installation/index.html
new file mode 100644
index 000000000..cea4cb4da
--- /dev/null
+++ b/docs/installation/index.html
@@ -0,0 +1,69 @@
+Installing auspice · Auspice
Auspice is written in Javascript and will require nodejs and npm (the node package manager) to install.
+If you are comfortable using conda these may be easily installed in your environment (see here).
+If you are on Linux or MacOS, you could also use nvm to insall these (see here).
+
Global NPM install
+
Auspice is avaliable as a npm package and can be installed simply via:
+
npm install --global auspice
+
+
Auspice is now available as a command-line program -- check by running auspice -h.
+Documentation for how to run auspice locally is available here.
+
Installing as a project's dependency
+
If you are building a customised version of auspice, you may want to include it as a dependency of that project.
+This allows you to pin the version, use continuous integration tooling and simplifies any code imports you may wish to use.
+
npm install --save auspice
+
+
+
Note that auspice is not available as a command line tool this way, but can be accessed from within the repo via npx auspice.
+See customising auspice for more information.
+
+
Installing from source
+
git clone git@github.com:nextstrain/auspice.git
+cd auspice
+npm install # install dependencies
+npm install -g . # make "auspice" available globally
+
+
Note that (at least on MacOS) this symlinks the source directory into the global node_modules folder so that changes to source code are automatically reflected in the globally available auspice command.
+We have had good success using a conda environment for development.
+
Developing
+
Install auspice from source (see above).
+Running auspice in development mode will automatically update as you change the source code:
\ No newline at end of file
diff --git a/docs/overview.html b/docs/overview.html
new file mode 100644
index 000000000..10523d676
--- /dev/null
+++ b/docs/overview.html
@@ -0,0 +1,67 @@
+Overview · Auspice
Auspice: an open-source interactive tool for visualising phylogenomic data
+
+
Please not that these docs describe the newest version of auspice (versions 1.35+).
+The new APIs are in flux and we expect they will change before version 2.0 is released.
+If you use these versions of auspice we would love to hear about your experiences! (Contact links at the bottom of the page).
+
+
Auspice is an interactive visualisation platform for phylogenomic and other other datasets related to evolution.
+It was originally designed for nextstrain.org, which aims to aims to provide a continually-updated view of publicly available pathogen genome data.
+Auspice can be used locally to view datasets, or deployed to server- or serverless-websites.
+It allows easy customisation of aesthetics and functionality, and powers the visualisations on nextstrain.org.
Auspice by itself is a visualisation tool for local datasets.
+It runs a local server to deliver the files the the visualisation to localhost:4000.
+After installing, you can access datasets in the current directory by running
+
auspice view
+
+
Please see auspice view -h for all available options.
+
The provided server (node auspice.js view or auspice view) could be used as a production server, perhaps with custom handlers provided (see these docs).
+
Building Auspice Locally
+
+
Building auspice shouldn't be necessary if you have installed it as a npm dependency.
+Building auspice is necessary if you have installed it from source, or if you would like to extend it with your customisations.
+
+
From the auspice source direcory:
+node auspice.js build --verbose
+
If auspice is installed globally:
+auspice build --verbose
Source code to Nextstrain is made available under the terms of the GNU Affero General Public License (AGPL). Nextstrain is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.
\ No newline at end of file
diff --git a/docs/overview/index.html b/docs/overview/index.html
new file mode 100644
index 000000000..10523d676
--- /dev/null
+++ b/docs/overview/index.html
@@ -0,0 +1,67 @@
+Overview · Auspice
Auspice: an open-source interactive tool for visualising phylogenomic data
+
+
Please not that these docs describe the newest version of auspice (versions 1.35+).
+The new APIs are in flux and we expect they will change before version 2.0 is released.
+If you use these versions of auspice we would love to hear about your experiences! (Contact links at the bottom of the page).
+
+
Auspice is an interactive visualisation platform for phylogenomic and other other datasets related to evolution.
+It was originally designed for nextstrain.org, which aims to aims to provide a continually-updated view of publicly available pathogen genome data.
+Auspice can be used locally to view datasets, or deployed to server- or serverless-websites.
+It allows easy customisation of aesthetics and functionality, and powers the visualisations on nextstrain.org.
Auspice by itself is a visualisation tool for local datasets.
+It runs a local server to deliver the files the the visualisation to localhost:4000.
+After installing, you can access datasets in the current directory by running
+
auspice view
+
+
Please see auspice view -h for all available options.
+
The provided server (node auspice.js view or auspice view) could be used as a production server, perhaps with custom handlers provided (see these docs).
+
Building Auspice Locally
+
+
Building auspice shouldn't be necessary if you have installed it as a npm dependency.
+Building auspice is necessary if you have installed it from source, or if you would like to extend it with your customisations.
+
+
From the auspice source direcory:
+node auspice.js build --verbose
+
If auspice is installed globally:
+auspice build --verbose
Source code to Nextstrain is made available under the terms of the GNU Affero General Public License (AGPL). Nextstrain is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.
\ No newline at end of file
diff --git a/docs/releasing.html b/docs/releasing.html
new file mode 100644
index 000000000..e9da2afd5
--- /dev/null
+++ b/docs/releasing.html
@@ -0,0 +1,22 @@
+Releasing auspice · Auspice
This page is a stub. It will contain instructions on how to publish auspice to npm.
+
+
Releasing new versions.
+
You will need push access to github.com/nextstrain/auspice, and local master must be up-to-date.
+Releasing should then be as simple as running ./releaseNewVersion and following the prompts.
+
Deploying to npm
+
This should be handled automatically when releases happen (assuming that the TravisCI build passes).
+To do this manually:
\ No newline at end of file
diff --git a/docs/releasing/index.html b/docs/releasing/index.html
new file mode 100644
index 000000000..e9da2afd5
--- /dev/null
+++ b/docs/releasing/index.html
@@ -0,0 +1,22 @@
+Releasing auspice · Auspice
This page is a stub. It will contain instructions on how to publish auspice to npm.
+
+
Releasing new versions.
+
You will need push access to github.com/nextstrain/auspice, and local master must be up-to-date.
+Releasing should then be as simple as running ./releaseNewVersion and following the prompts.
+
Deploying to npm
+
This should be handled automatically when releases happen (assuming that the TravisCI build passes).
+To do this manually:
\ No newline at end of file
diff --git a/docs/tutorial/overview/index.html b/docs/tutorial/overview/index.html
new file mode 100644
index 000000000..a44bf402b
--- /dev/null
+++ b/docs/tutorial/overview/index.html
@@ -0,0 +1,37 @@
+Auspice functionality · Auspice
