Here are thoughts on the high-level design for the InfoMapper builder application. Other specific issues will need to be split out with more detail.
The goal is to create a web application that can quickly build an InfoMapper configuration, for users that want to do a smaller application or that don't have the skills to do back-end automation. For example, someone might create an InfoMapper with a relatively small number of maps, dashboards, and/or stories. This will allow OWF to provide the solution as a hosted software as a service.
Application Name
The application name will be the "InfoMapper Builder".
Use of Web Services
Unlike the InfoMapper, which just displays content based on deployed files, the InfoMapper Builder will need to interact with AWS to manage organizations, users, and deployments. For example:
Use the Organizations service to create an organization to save files and be billed for InfoMapper services.
Use the Cognito service to create and manage users in an organization.
Use S3 to manage files for InfoMapper deployments (need to decide how to handle public/private content in buckets).
Use CloudFront to handle https, caching, etc., similar to other sides.
Code will need to be written to integrate the Builder with services. Elizabeth at TriLynx has done this and is a resource.
Use Case
The following is a high level use case.
User visits the OWF landing page for InfoMapper (also own infomapper.org). They read about the tool. For example, we could implement one or more stories to explain how InfoMapper works, with live data.
User decides to sign up for a trial period. They first add an organization (can be a personal organization). An S3 folder is created for the organization.
User adds themselves as a user under the organization. Cognito is used for the account. Similar to other systems, use their email for the account name.
User starts a new InfoMapper - requires picking a name that will be used for the S3 folder under the organization (also need an internal identifier or automatically slugify to something without spaces that can be used in paths). The version is preview or similar. User can pick which version of InfoMapper to deploy, and the files get copied to the preview folder as if deployed.
User uses the Builder to the configuration using the site map (next section) and uses the preview InfoMapper to view.
When happy, user saves the configuration to a version number and has option to deploy to latest.
If happy, they sign up for a paid hosted application.
Proposed Design
Creating a highly-interactive application with "what you see is what you get" user interface can take a lot of effort. Creating the features in the existing InfoMapper can add a lot of complexity and risk. Creating a new application that includes a lot of the InfoMapper features may also result in a lot of work. The following design attempts to leverage previous work as a compromise so that a product can be quickly created and concepts tested.
Ultimately, the builder is creating JSON configuration files for the application, maps, dashboards, stories, etc. The application configuration file references configuration files for each major component.
Builder UI Design
I propose that the Builder provide an outline-based organization that matches the InfoMapper menus. The builder would allow modifying the outline and when a specific component is selected for editing, such as a map, a form-based editor would be shown to fill out necessary data. Some level of graphics could be used, such as to help with layer symbology (similar to ArcGIS and QGIS symbology editors), but the initial functionality could be perhaps mostly form-based. The configuration outline (which is essentially a site map) would look something like the following and could be expandable like a file system.
Application: Poudre Basin Information
Menu: Dashboards
Submenu: Main Dashboard
Dashboard:
Properties:
Widget:
Widget:
Menu: Basin Entities
Submenu: Administration - CO DWR Water Districts
Map: CO DWR Water Districts
GeoLayerGroup: CO DWR Division Offices
GeoLayer: ...
The above outline would be the primary way that the user would make menu changes and dig into editors for each component/widget, etc. Each editor can be modular and we can focus on some editors enough to demonstrate the concept. Then it will be a matter of filling out the different editors.
Workflow
The editor will modify in-memory objects. When those objects are saved (or allow auto-save?), the JSON configuration files and other files will be saved to the preview/assets/app folders using a standard convention. For example, use a maps folder for all maps, dashboards, stories, etc.
In a separate window, the preview InfoMapper can be run and refreshed to reflect the edits. This will allow the existing application to be leveraged and will ensure that what was edited works in the production application (no surprises later). It may be possible to have the InfoMapper auto-refresh like Angular does in the development environment but this may require writing code to interface with S3 and check modification times.
When satisfied with the results, the Builder will allow deploying to latest and 1.2.3 version folders, etc. at which point the updates become live via CloudFront invalidation.
To be determined is how to monetize the solution by billing for AWS services and fee for OWF resources.
The application files could also be saved to a GitHub repository by using its API, for example to save the assets files and any Builder files in a simple folder structure matching the InfoMapper deployment.
Here are thoughts on the high-level design for the InfoMapper builder application. Other specific issues will need to be split out with more detail.
The goal is to create a web application that can quickly build an InfoMapper configuration, for users that want to do a smaller application or that don't have the skills to do back-end automation. For example, someone might create an InfoMapper with a relatively small number of maps, dashboards, and/or stories. This will allow OWF to provide the solution as a hosted software as a service.
Application Name
The application name will be the "InfoMapper Builder".
Use of Web Services
Unlike the InfoMapper, which just displays content based on deployed files, the InfoMapper Builder will need to interact with AWS to manage organizations, users, and deployments. For example:
https, caching, etc., similar to other sides.Code will need to be written to integrate the Builder with services. Elizabeth at TriLynx has done this and is a resource.
Use Case
The following is a high level use case.
infomapper.org). They read about the tool. For example, we could implement one or more stories to explain how InfoMapper works, with live data.previewor similar. User can pick which version of InfoMapper to deploy, and the files get copied to thepreviewfolder as if deployed.latest.Proposed Design
Creating a highly-interactive application with "what you see is what you get" user interface can take a lot of effort. Creating the features in the existing InfoMapper can add a lot of complexity and risk. Creating a new application that includes a lot of the InfoMapper features may also result in a lot of work. The following design attempts to leverage previous work as a compromise so that a product can be quickly created and concepts tested.
Ultimately, the builder is creating JSON configuration files for the application, maps, dashboards, stories, etc. The application configuration file references configuration files for each major component.
Builder UI Design
I propose that the Builder provide an outline-based organization that matches the InfoMapper menus. The builder would allow modifying the outline and when a specific component is selected for editing, such as a map, a form-based editor would be shown to fill out necessary data. Some level of graphics could be used, such as to help with layer symbology (similar to ArcGIS and QGIS symbology editors), but the initial functionality could be perhaps mostly form-based. The configuration outline (which is essentially a site map) would look something like the following and could be expandable like a file system.
The above outline would be the primary way that the user would make menu changes and dig into editors for each component/widget, etc. Each editor can be modular and we can focus on some editors enough to demonstrate the concept. Then it will be a matter of filling out the different editors.
Workflow
The editor will modify in-memory objects. When those objects are saved (or allow auto-save?), the JSON configuration files and other files will be saved to the
preview/assets/appfolders using a standard convention. For example, use amapsfolder for all maps,dashboards,stories, etc.In a separate window, the
previewInfoMapper can be run and refreshed to reflect the edits. This will allow the existing application to be leveraged and will ensure that what was edited works in the production application (no surprises later). It may be possible to have the InfoMapper auto-refresh like Angular does in the development environment but this may require writing code to interface with S3 and check modification times.When satisfied with the results, the Builder will allow deploying to
latestand1.2.3version folders, etc. at which point the updates become live via CloudFront invalidation.To be determined is how to monetize the solution by billing for AWS services and fee for OWF resources.
The application files could also be saved to a GitHub repository by using its API, for example to save the
assetsfiles and any Builder files in a simple folder structure matching the InfoMapper deployment.