Host applications

The Tree Illustrator provides a friendly, browser-based app for building and managing a single tree illustration. This is only part of the picture, since we also need to support

• storage of illustration JSON, source data files (if unpublished), images and other ornaments
• user authentication and permissions (important for private work and collaboration)
• sharing and access control for collaborators

For example, our primary goal is to integrate the Tree Illustrator into the existing Open Tree curation app, to encourage submission and cleanup of new phylogenetic trees. This means we would gather trees and store them in the existing OpenTree phylesystem-* repos; re-use GitHub's user accounts and authentication; store supporting data (and ornament) files using the existing (temporary, filesystem-based) storage; and possibly embed the Tree Illustrator UI in the curation app.

NOTE that this implies that we can store pre-published tree data, since normally we only store and share published studies and their trees in phylesystem. This means we would probably create empty studies and isolate them on private shards that are not pushed to GitHub!

Other "host applications" (typically these are web frameworks) will support users with different tools and workflows. Here are some of the apps on our current wish list:

• iPython/Jupyter notebooks for interactive exploration and dynamic visualization
• Arbor Workflows for analysis and exploration
• a "big tree" server (proposed) to explore trees too large for client-side memory

Tree Illustrator makes certain demands of any host application:

• distinct users and authentication (unless only for private/offline use, or anon-only sharing);
• private, flexible storage for large files, and some means of "bundling" files together for a single illustration;
• support for modern markup and browser features required for the Tree Illustrator GUI.

The sharing and storage aspects should be handled using adaptors in our Javascript code, so we can use common APIs and avoid messy conditional logic to handle the quirks of each host application. At the moment, this is a circular exploration, as the capabilities of our target hosts will influence the API and expected features.

Assessment of difficulty for desired host applications

This is based on preliminary "scouting" of each project's code, integration machinery, etc.

Open Tree curation app

The current (Jan 2017) Tree Illustrator is a single-page web app that can be embedded in any domain. As a result, it can be integrated into the Open Tree apps, since the real connection is via a storage adaptor that uses the OpenTree APIs. This supports easy sharing of illustrations and access from any browser.

Offline (private) storage

It looks like newer HTML5 storage APIs (e.g. File and Blob) are widely supported now, so we should be able to support truly private work by saving full illustration documents as ZIP archives, directly from the browser to a user's desktop. They can then be shared with collaborators via email, etc.

Jupyter notebooks (aka IPython notebooks)

Preliminary assessment: Pretty tricky, may force refactoring

It looks like we're doing something MUCH bigger than typical widgets (single inputs, the usual stuff), see

• https://www.youtube.com/watch?v=wxVx54ax47s
• http://nbviewer.ipython.org/github/twistedhardware/mltutorial/blob/master/notebooks/IPython-Tutorial/6%20-%20IPython%20Widgets.ipynb

Is there a smarter way to integrate bigger stuff like this? Can/should we host Tree Illustrator separately and use IFRAMEs to provide Tree Illustrator "instances"?

• a Bokeh visualization in an IFRAME in an IPython notebook
• use IPython.lib.display.FileLinks to embed "local" files, incl. internal to notebook?
• use IPython.lib.display.IFrame to embed remote (or complex) web pages. N.B. this takes arguments, which might include full tree+spec data or local URLs. Hm, looks like this uses strictly GET params on the query string. Perhaps a smarter display.TreeIllustrator subclass?
• here's a notebook of interesting demos of using Plotly to share and host data and viz, embedded in IFRAMEs using the Plotly API, e.g. plotly.iplot_mpl.

Requirement: distinct users and authentication

This should be moot. These notebooks are generally shared or held on a private server, so we should be able to "follow suit" by allowing free access from within the notebook.

Requirement: private, flexible storage

You can save state for a widget, presumably in the notebook document itself. This should be manageable with just a few (JSON) variables.

But we expect to be able to save illustration "bundles" with trees, vega specs, supplemental data, and ornaments (PhyloPic and others). This is possible, but IPython will stash everything in the notebook document itself as base64 data. This seems likely to cause massive bloat if binary data is added.

Requirement: support for modern markup

I think we're OK here, since notebooks are served as HTML5. Does IPython/Jupyter restrict what JS/etc. code we can include? I see that popups are highly discouraged...

Basically, we'd insert an "instance" of Tree Illustrator in a code cell, as shown in this video and its demo notebook. This implies support for multiple instances in the same web page, which could force a more careful rewrite of our jQuery selectors, etc.

It looks like most interactive notebook widgets assume a live IPython kernel on the server, which is not true for static notebook views. It's possible to build "static interactive" widgets that will run independent of a server, but these generally stash pre-rendered results (as base64) in the notebook. A Tree Illustrator instance would instead generate its output on-the-fly, as all logic is client-side.

Arbor workflows

TODO

--