Update - October 16, 2019:

The Science Gateways Roadmap is completed and is now hosted live on the Cornell Virtual Workshop at:

https://cvw.cac.cornell.edu/SciGateMap/

This version was recently presented as a poster at the SGCI Gateways Conference in San Diego, October 1-3, 2019.

Update - April 3, 2019:

Latest version is available for review here:

http://education.sdsc.edu/science_gateways/decide_on_gateway_v0.3.html

This version has been presented to the ESSGW group for their review and feedback before submitting a final public-facing version.

Update - January 23, 2019:

Final design specifications have been reviewed and are currently being implemented based on feedback from the Science Gateways team. Two versions will be created, one version with advanced responsivity for mobile devices and another version for standard web browsers on laptop or desktop systems.

Additional design improvements include:

The "Build Your Own Gateway" node now serves as the node for content combined from 3 nodes in the previous design.
Comment bubbles will be added for each node and different implementations will be needed for the two different target platforms, 1) mobile devices, and 2) laptop and desktop system browsers.
The decision tree flow was simplified and additional reference guides were added for clarity.

Content in HTML format is also being developed and all node content should be completed by the end of March, 2019, and an 'alpha' prototype should be ready for a first pass at implementation on an XSEDE instructional delivery platform such as the Cornell Virtual Workshop.

Update, November 28, 2018:

We are currently developing content for each node. The link below for Oct. 17 still applies to the updated version.

We decided to modify the network somewhat to make it more efficient and accurate. We are integrating the three nodes "New Gateway", "Technical Documentation", and "Build Own Gateway" into a single node and reworking some of the lower nodes. We are waiting on feedback and approval from some of the Gateways team to confirm this is the right direction.

Update - October 20, 2018:

Version II of the decision tree design has been developed and under review by the Science Gateways team. Additional features included floating message bubbles, mouseover effects, pan and zoom, and responsive design.

An interactive prototype is available for demonstration by clicking the image below:

Update, October 17, 2018:

We developed an interactive mock-up of how this decision tree might be used. The mock-up was developed by exporting the draw.io flow diagram as a .SVG format file. We imported that file into Adobe Animate and added some user-friendly interactivity and developed a series of HTML document 'placeholders'. We exported the animation as an HTML5/CSS3/JavaScript web page compatible with all current browsers. Here's a prototype:

http://education.sdsc.edu/science_gateways/decide_on_gateway.html

Update - June 29, 2018:

We are working on a flow chart which delineates the key steps in the decision-making process for deciding which path to choose for hosting a gateway.

Below is phase 1 of the chart (click to enlarge):

XSEDE Home > XSEDE Gateways Tutorial 2: "Deciding On A Science Gateway" > decide on gateway.jpg

Background For This Tutorial

Rationale

The gateways community is realizing that not many users want to install their own gateways, only the larger projects are considering this. There are numerous smaller projects coming on board XSEDE who have research or community code they want to make available to their community and they will get their own XSEDE startup allocation and then maybe they will get an XRAC or encourage their users to get their own allocations and expand accordingly.

There are a growing number of service providers who do not want to operate their own gateway. This has been a trend in the SG community including many of the popular frameworks such as Galaxy, Airavata, Agave, Hubzero. The focus should be on what the community needs rather than what we think they need.

Where would training help?

Training would help by providing a decision-making process to help guide the user to the appropriate gateway development scenarios for their specific needs. It won't focus on a particular software but rather on the process of identifying the framework and the implementation strategy.

Globus may serve as an example. Early on, users needed to install and run gridftp and work mainly at the command line. Now they work mainly through Globus Online. There is a shift from installing and running one's own software packages to using services hosted and maintained by others.

Our focus is on how to create a new gateway (as opposed to how to use a gateway), but it involves a somewhat different approach. Google may serve as another example. Users can create and host their own web sites and host their own email servers, etc. but Google helps make it alot easier by providing those services. Our users will be learning whether they want to host their own gateway or whether they want a hosted gateway, and if it's the latter then we help guide them down that path. If it's the former, then we point them to the existing CVW tutorial for gateway admins.

A growing number of XSEDE researchers have either developed or are using the same software and would benefit by gaining access to it via a community gateway. The general scenario is "I have this code and I want to build a gateway for it". What do I need to do? To do it themselves can be daunting. We propose providing a tutorial involving a step-by-step process for working with gateways service providers to simplify and expedite the process.

Training, Not Documentation

We classify this as a training effort rather than a documentation effort. There already is alot of documentation but it is not well-organized. We propose adding some order to the chaos. Susan expressed her interest in screencasts for some of the more complex steps in the process. We also felt that it may help to use something similar to a case study approach by identify some exemplar gateways which embody the type of gateway development scenarios we plan to cover.

There may be only 4 or 5 popular gateway frameworks and services. We want to focus on creating a tutorial which encompasses these most popular options while still keeping the tutorial as general as possible. Jetstream can hopefully serve as a way of making gateway hosting and administration somewhat of a 'cookie-cutter' approach. There may also be existing XSEDE users who could help by working with us to provide insights into the process as they went through it or are going through it. Suresh singled out dReg and Simvascular as examples of 'typical' gateways hosted for the community.

Update, May 7, 2018:

Suresh, Susan, and Jeff met to discuss first steps towards this tutorial. The growing demand for hosted gateways (as opposed to installing a standalone gateway) suggests the need for a different tutorial designed to help them with this process. Here are notes from that meeting:

Suresh helped lay out a sequence of steps users might typically follow in order to implement their own hosted gateway. Some resources already exist for this process but they are lacking sufficient details and are somewhat disconnected. The primary goal of this tutorial would be to integrate these resources into a coherent whole. Screencasts may play a bigger role in this tutorial. Options for hosting include Jetstream which is nice because tutorials already exist for obtaining a Jetstream allocation and getting started with Jetstream. There may be some existing gateways which could serve as exemplars or used for simple case studies.

The gateways community is realizing that not many users want to install their own gateways, only the larger projects are considering this. There are lots of smaller projects coming on board XSEDE who have research or community code they want to make available to their community and they will get their own XSEDE startup allocation and then maybe they will get an XRAC or encourage their users to get their own allocations and expand accordingly.

There are a growing number of service providers who do not want to operate their own gateway. This has been a trend in the SG community including many of the popular frameworks such as Galaxy, Airavata, Agave, Hubzero. The focus should be on what the community needs rather than what we think they need.

Where would training help? In providing a decision-making process to help guide the user to the appropriate gateway development scenarios for their specific needs. It won't focus on a particular software but rather on the process of identifying the framework and the implementation strategy.

Suresh used Globus as an example. Early on, users needed to install and run gridftp and work mainly at the command line. Now they work mainly through Globus Online. There is a shift from installing and running one's own software packages to using services hosted and maintained by others.

We are still talking about how to create a new gateway, but it involves a different approach. Suresh used Google as another example. Users can create and host their own web sites and host their own email servers, etc. but Google helps make it alot easier by providing those services. Our users will be learning whether they want to host their own gateway or whether they want a hosted gateway, and if it's the latter then we help guide them down that path. If it's the former, then we point them to the existing CVW tutorial for gateway admins.

At this point Suresh shared his screen and walked Susan through the same series of pages on the XSEDE web site which you and I walked through last week, including Simvascular. He also mentioned a scenario involving Cornell faculty Charles Danko who has software and wants to avoid making everyone download the software by offering a gateway.

The general scenario is "I have this code and I want to build a gateway for it". What do I need to do? To do it themselves can be daunting. We propose providing a tutorial involving a step-by-step process for working with gateways service providers to simplify and expedite the process.

We classify this as a training effort rather than a documentation effort. There already is alot of documentation but it is not well-organized. We propose adding some order to the chaos. Susan expressed her interest in screencasts for some of the more complex steps in the process. We also felt that it may help to use something similar to a case study approach by identify some exemplar gateways which embody the type of gateway development scenarios we plan to cover.

There may be only 4 or 5 popular gateway frameworks and services. We want to focus on creating a tutorial which encompasses these most popular options while still keeping the tutorial as general as possible.

Jetstream serves as a way of making gateway hosting and administration somewhat of a 'cookie-cutter' approach.

Suresh felt there may be existing XSEDE users who could help by working with us to provide insights into the process as they went through it or are going through it. Suresh singled out dReg and Simvascular as examples of 'typical' gateways hosted for the community.

We discussed more specifics and set priorities during our bi-weekly meeting on May 17 2018.