Frontend v2

[davenquinn]

The Sparrow web interface is currently quite functional, but it is primarily built for basic demos of the project and needs a redesign focused on usage. Additionally, several functional pieces are currently non-existent or underbuilt.

Site design

The site's layout is currently designed around a descriptive website view, with a single column of content and minimal header (e.g. this thermochronology demo). This works fairly well for demos but does not make good use of large screens to show data; it also fits poorly with map-based views.

Ongoing frontend work will move towards redesigning the frontend into an "admin panel" type view. This gallery can provide some web-design inspiration. It is possible that a more "narrative" layout will be maintained on public-facing pages.

Improved technical underpinnings

The robustness and usability of the frontend is subject to technical limitations that must be addressed. This will be increasingly important as large datasets are accessed through the system.

• The codebase is currently written in Coffeescript, but this is no longer a widely used language. Shifting to Typescript will align us with current standards, improve tooling, and increase accessibility to Javascript developers. This is a one-time fix enabled by the decaffeinate project. Since code changes will be difficult to trace through this event in version control, it should be done before any further changes.
• Break up single-page application: all frontend code is currently imported at initial page load. Blocking to load several megabytes of Javascript (~10 in development mode) is wasteful and not user-friendly. Better dynamic loading of code is one way to address this; adding "server rendering" of Javascript is a complimentary, but more difficult, approach. This is a required part of Production mode #15.
• Pagination and filtering of results sets need to be improved for performance and usability. We can potentially add virtualized scrolling solution used in the COSMOS frontend.
• More "slots" for including custom content and documentation on how to use them.
• Integrate the new schema-based interfaces in the backend
  • Standardize project editing functionality to also encompass editing for samples and metadata (the code is currently far to ad-hoc to be maintainable, but new schemas can allow us to auto-generate more of this).
  • Potentially, use the new schemas to define a GraphQL API (it may be complicated to maintain this alongside the basic REST endpoints).

New features

Many new features are desired in the Sparrow web interface; we include a list here to allow continued tracking.

• Views for new "audit trail" functionality
• Imports initiated through web interface (rather than command line)
• Interface for defining how data appears in API (field-mapping)
• Interface for bulk editing data
• Improved map interface, with clickable data points etc.
• Metadata linking interface (e.g. suggested geologic formation)
• Comments and tags on data
• ORCID login

[davenquinn]

The "Tasks" interface (#195) is a major advance for imports in the web interface.