Theme-ing: Enable different branded views / curated catalogues of the same TerriaMap

[AnaBelgun]

Background:

• From discussions with PacificMap and DroughtMap product owners, they are keen to have multiple views of the map accessible via http://pacificmap.terria.io/other_branding_view or https://map.drought.gov.au/other_branding_view which will make available: 1) a new view of the main map but with different branding (based on the collaborator or product owner) 2) curated view of the catalogue with different datasets either opened by default or shown in different groups /highlighted in different ways 3) combination of 1, 2 and a series of tabs in the catalogue with curated data by topic/custodian/other (similar to https://data.apps.fao.org/)

Action:

• together with UI designer investigate high level options and complexity of work - in next sprint to start investigation
• following investigation, create SoW draft and present to product owners

[soyarsauce]

@soyarsauce & @vicborgy to discuss

[soyarsauce]

Related https://github.com/TerriaJS/terriajs/issues/4687

[AnaBelgun]

Update 6 Oct 2020:

• DroughtMap product owner is suggesting to have the following workflow:
  1. Disclaimer / T&Cs on landing page
  2. In Disclaimer window, create a list with 4 types of users and invite users to click on one
  3. Depending on the user type, show a curated view of the data catalogue

[AnaBelgun]

USGS example: https://maps.usgs.gov/padus/

[AnaBelgun]

Update 25 Oct:

• this is a requirement for PacificMap to be developed and released by early December 2020 (i.e. enabling the product owner to create branded views with curated catalogues; to be accessed by users at master url and adding the relevant words to indicate the specific brand/field/curation e.g. pacificmap/environment e.g. pacificmap/sprep

[soyarsauce]

@soyarsauce to either of,

• do a quick prototype?
• sketch out the idea for a quick prototype

[soyarsauce]

~team~ NFS vote: prototype

[soyarsauce]

(maybe) - NFS vote above

[soyarsauce]

Pending Crispy's thoughts too

[soyarsauce]

@soyarsauce has whipped up a really quick prototype of this idea to demonstrate the idea: see PR for more details https://github.com/TerriaJS/terriajs/pull/4996

[AnaBelgun]

Link to PoC demo video

[AnaBelgun]

@philipgrimmett - This ticket should be in design thinking phase

[philipgrimmett]

I think this issue covers two seperate stories:

PacificMap:

As a map owner I want to provide a customised experience for users of sub-branded maps so they can easily find data that is relevant to their needs

DroughtMap:

As a policy researcher I want to access the most relevant / frequently used datasets for my work in one place so I don't have to waste time searching for them individually.

Re. pacificMap: Unless there is a requirement for users to navigate between parent/child maps, we can probably just think of each map as a standalone instance and leave the brand architecture to clients.

Re. droughtmap: the number of datasets proposed for each theme (Research/Policy, Academics etc.) is fairly small at this stage, so we might be able to support their use case with curated 'collections' (adding multiple related/relevant datasets with one click). Concept sketch attached below:

In some instances it might be fine to enable all datasets from a collection once they are added to the workbench (eg. one regional dataset underneath five relatively sparse point or line datasets) but in most cases it would be better to disable all but the top dataset by default to avoid information overload.

There will probably be some behavioural nuance required for removing and re-adding collections. I'm happy to walk through options with the team once we have a working prototype.

Ping @AnaBelgun for thoughts, feedback, clarification from client meetings ect.

[philipgrimmett]

Concept for simple sub-maps (different brand bar, reconfigured data catalogue): https://invis.io/CG104R6NYUPF#/444175901_pacificMap

[AnaBelgun]

Latest discussions re: PacificMap:

• decision to start with a PoC showing mainmap/theme and datasets relevant to the theme either highlighted in the catalogue or at the top @philipgrimmett what would be the best option for the end user (highlighted data or elevated at the top)?

[philipgrimmett]

Rough concept for navigating between parent and sibling maps, eg. pacificMap > pacificMap Fiji > PacificMap Kiribati https://invis.io/SN10JE9BPT74#/447866910_PacificMap_Countries_-_1

[AnaBelgun]

Next step:

• meeting reconvenes for finalising development approaches - set up on 14 Apr

[AnaBelgun]

14/04/2021 Refinement: Functionality expectation (v1.0)

• user goes to master map/child url (e.g. by domain - nationalmap/renewables; nationalmap/water; pacificmap/environment; by geography - pacificmap/fiji etc.)
• the view shows elements of the master map in combination with branding elements of the child map (sub-brand) (e.g. names, logos)
• the catalogue shows the data relevant to the child/sub branded map promoted at the top (the highest relevance at the top, the lowest, at the bottom); all datasets are preserved in the catalogue in v1.0, just re-ordered by relevance to the sub-brand
• the user has options to go between the master and child maps

Not in scope for v1.0:

• user going between child maps
• entirely solving the fundamental filtering problem (by tag, by geography etc);
• findings in experimentation with v1.0 will be used in filtering development

Options discussed: 1) Back end - combination of magda and saas implementation; server receives request for url ... 2) Front end - based on full single page load and routing to have different map configurations (and be able to change them)

Nest steps:

• plan to start with 1 week of experimentation in Sprint 27 Apr - 10 May
• finalise v1.0 by 30 Jun 21

[zoran995]

I would push as much as possible towards this approach (if I understood it correctly)

Options discussed:

1. Back end - combination of magda and saas implementation; server receives request for url ...
2. Front end - based on full single page load and routing to have different map configurations (and be able to change them)

From what I got, this is in basic terms a true multitenancy support on terriajs side, to have different config and init files for different URL paths on a single domain the basic structure (folder based) could be

• /base/config.json
• /app1/config.json
• /app1/init/...
• /app2/config.json
• /app2/init/...

The base config could be used as the foundation for all other implementations i.e. holding keys or other parameters that will be used with each app. When users access the application we would have to determine which app is accessed and present it with an appropriate configuration (combine app config with base config). With this approach, an administrator could easily create new versions of applications without putting additional stress on the server infrastructure