[Frontend, request] GUI requirements

[p1d1d1]

• [x] The search text should not be mandatory. By clicking on "Suche", all available datasets are returned, thus
• [ ] Pagination should be supported (see as example https://ilimodels.ch/)
• [x] The following info are provided: [ ] Title [ ] Abstract [ ] Service provider [ ] Service type
• [x] The GUI supports ordering ASC/DESC by Title and or Service provider
• [x] The GUI supports filtering by Service provider and or Service type
• [x] Entries in the result list are clickable and link to the detail page (see below)

• [ ] Kategorie(en): only if you'll be able to assign categories to the datasets
• [ ] Änlische Datensätze: this would be a very nice to have "killer feature"

[fionatiefenbacher]

details about entry either

• in a separate page (see image above)
• in a some kind of Accordion style and possibly in addition with a preview on the right side

link to GIS-files

• [ ] when clicking on the software icon, a specific layer file (.qlr / .lyrx) is downloaded to load the service directly in the software

feedback to provider

• [ ] to show the quality of the service information (metadata) a ranking (eg. 1% - 100%) will be shown next to each entry (to be discussed)

[FStriewski]

@p1d1d1 questions that came up during our internal meeting:

Clickable row opens in new page:

Advantage of this approach is to have more space for displaying results and additional download UI. Disadvantage is, that it makes comparisons between (similar) datasets very cumbersome. We might want to introduce some tooltip / preview feature so that allow users quick comparisons. Once we have pagination in place, there is no need to make a sepearate request (/datasetById/{id}) for the details of a given dataset. (It would also affect the UI smoothness in a negative way). Is that approach okay with you?

Filter

From the mockup we would conclude that you require single values for the filters, not selections. Meaning e.g. only one service type or Kanton, not multiple Kantons or types of services. Is this really the case? Dropdowns are easy to implement, selections require state handling in React and are more complex. I`d rather go with the latter right away (to avoid costly refactoring) unless selections are definetly not required or compatible with other services. Could you let us know if that is the case?

[p1d1d1]

@FStriewski I'm just giving functional requirements. The way you implement it is up to you.

For the filter I'd like to have the possibility to filter by Canton and/or Service. Only one canton and only one service would be enough for me but again, feel free to chose how to implement it.

[FStriewski]

github.com/FHNW-IVGI/Geoharvester/pull/42 implements sorting and expanding of details.

[fionatiefenbacher]

/pull/45 implements filter UI for servicetype and provider

[FStriewski]

I`ll close this issue as all points, except for finding similar datasets (see issue https://github.com/FHNW-IVGI/Geoharvester/issues/17) have been addressed.