Design

An experienced designer who provided feedback on all the different pages and components would be immensely valuable at this point. A deliverable for such work would involve them taking screenshots of each page, loading those screenshots into photoshop, and then updating spacing/sizes/colors and providing the output as a reference to do further tweaks on the site.

Home page

• Might be nice to include some news/articles below the map. Worth looking at 'featured datasets', showing the sarva collections, pulling relevant SAEON newsletter articles, etc. etc.

Search

• Date filter should allow for ranges
• Provide UI controls for specifying synonyms/search terms (currently done in source code)
• Update index and search to use synonyms at query time rather than at index time so that changes to synonyms don't require a complete index rebuild
• Add the ability to sort results - via download count / popularity / data type / etc. etc
• Remove pagination in favor of infinite scroll
• Fix/remove the system for identifying 'data type'. This was previously an external script that is no longer run, so all data types coming in a 'UNKNOWN'. this should be implemented directly, it will involve iterating through the datasets, downloading and extracting the data, checking file extensions, and then updating the record in the ES index
• Update the map on the filter page to include domains of all the found datasets. To do this is necessary to 'deduplicate' data, this was implemented as a home page effect but removed. The API call is still up - here is a reference on how to use it: https://github.com/SAEON/data-portal/blob/next/clients/src/modules/home/map/_domains.jsx

Update Elasticsearch/search implementation

The current implementation uses only a tiny fraction of Elasticsearch's capabilities, and could instead be implemented directly in Mongo (or PostGIS) as these databases support full text search/text indices (more or less). Either the site should be refactored to do this, which would reduce the scope of the catalogue work to be less complex, and fewer moving parts, and to use much! fewer resources. Alternatively it could be worthwhile doing a deeper dive into the Elasticsearch technology to greatly improve the search results. The latter approach is probably more worthwhile

List features

• Extend the curated lists concept to be for all logged in users. There could be 3 list types (public, user, created)
• Allow for customizing lists - logos/titles/keywords/theme/etc.
• Allow for defining or conditions. i.e. filter to select author 1 or author 2
• If users can create/share their own lists with their referrers, it would be worth expanding the usage dashboard to filter for data specific to individuals - i.e. only one referrer, or only one list

Data previews

• Tiny boxes should still be visible when zoomed out
• Extend the map viewer on the /records page to allow for viewing multiple layers at the same time
• The work on somisana.ac.za includes automated pipelines for viewing / exploring netcdf / raster data. It's already straightforward to view vector / table data. In the future it might be worth updating the /records/:id page (that doi.org points to) to include data visualizations of the raw data.

Site analytics

• Add a 'pageRender' log that tracks the order that users visit page in a single session, this would be useful to see where traffic is originating from and which pages are used (and how)
• Add a UI component on the /users page to show this

Customer engagement

• Users are voluntarily submitting feedback when downloading forms and often say they don't mind being contacted. There is a lot of opportunity here in terms of marketing/business development/and general service follow up. It would be nice if it were possible to log into the catalogue, and and engage with the users who have indicated that we can contact them. Such a feature would include updating the catalogue app to serve emails on behalf of a logged in user (currently only catalogue admins can see these form responses). These emails (and responses) would appear as message threads belonging to a particular user form.

API development

• It may be worthwhile to publish API endpoints on top of the search that allow for programmatic querying. That IS how it is currently done, but it's in a bespoke GraphQL format that is only suitable for the client (UI) to use easily. It would be easy to publish a STAC-compliant endpoint, or possibly to publish an RDF compliant API that allows for searching via SPARQL such as ICOS does

SEO

Work in milestone 4 allows for specifying sitemaps. I think canonical URLs are important for SEO (and certainly for humans). In this way the data lists feature should support bespoke URLs for different data collections. This is possible as Cloudflare could allow for automated updates to the *..saeon.ac.za domain, certbot allows for dynamically assigning ssl certs, and our nginx setup is easy to automate (or alternatively implement URL rewriting in the app itself similar to how CouchDB does).

Deployment

• Update the docker stack configuration for 0-downtime deployments. I think this is simply specifying 2 replicas and changing the start order in the .yml file
• Update the deployment to run tests prior to deployment, this should just be a simple 'hello world' to start. But then fill in tests as mentioned below

Automated test development

This is probably worth implementing at this point, both for UI and server code, as there are enough features now that it's possible to break one without noticing.

• Specify a comprehensive list of features in a testable way (don't forget sitemaps! and robots.txt)
• UI tests
• API tests