sshoc-marketplace-frontend issueshttps://gitlab.gwdg.de/sshoc/sshoc-marketplace-frontend/-/issues2020-12-23T09:18:20Zhttps://gitlab.gwdg.de/sshoc/sshoc-marketplace-frontend/-/issues/14Implement autocomplete in search2020-12-23T09:18:20ZMatej DurcoImplement autocomplete in searchWe need to define the source of autocompleteWe need to define the source of autocompleteBeta release (M24)Stefan ProbstStefan Probst2020-08-27https://gitlab.gwdg.de/sshoc/sshoc-marketplace-frontend/-/issues/84Highlight changes in fields of suggested items2022-07-22T09:46:35ZKlaus IllmayerHighlight changes in fields of suggested itemsFirst of all: the notion of fields in this issue includes attributes (like the description of an item) as well as dynamic properties.
## Problem description
Contributors suggest a new version of an item. Such suggestions are approved b...First of all: the notion of fields in this issue includes attributes (like the description of an item) as well as dynamic properties.
## Problem description
Contributors suggest a new version of an item. Such suggestions are approved by moderators. For this we have the curation dashboard `Items to moderate` where all suggested versions are collected. By editing and publishing such a suggestion this version becomes the new approved version. Curators scroll through the edit form of the suggested item and look, if this item can be approved.
Now the problem: there is currently no (visual) clue which fields changed compared to the current approved item. Therefore it is not easy for moderators to spot, which fields to look for moderation. It would be very helpful, if there is something like a visual highlighting (like an icon and/or a background color) for all fields that are different to the current approved item. Moderators can then focus on this changes which would simplify the approval workflow.
Current workaround: Open a second browser tab with the current approved item and compare it with the content of the suggested version in the first browser tab. This needs a very focused approach and is by no means error-free.
## Solution discussion
I've had already a discussion with @stefan.probst on this and a further discussion round with @lbarbot and @buddenbohm, summing up the current information.
Frontend solution: Finding a good and easy solution is not that easy if frontend should solve this alone. First of all we do not have an UX/design proposal that we could use. Questions are:
* what is a usability-conform way to show the differences between two fields (color alone - which color? - is not accessibility conform)?
* how to show deleted fields? (more easier: how to highlight added fields)
* to which detail should changes of fields be shown: have a diff of a text field (showing which letters where added/deleted/changed)
* how to process the API results of the items to be compared: there is probably no coherent way to do this automatically, as we do have different field structures based on the difference between attributes/properties, the different data types (a concept is expressed in a very different way as a string field), foreign keys to e.g. actors, sources identified by id
* would that imply a way to revert the value of a field by clicking on a button?
* connected to the last point: should changes by moderators be shown in a different highlighting?
* what should be compared when there are more then one suggestions of an item?
Backend solution: It could be possible that backend does such comparision and delivers a meta-information on changed fields at an suggested item. Disadvantage: coding effort at backend, solves only some questions for frontend.
Curation notebooks solution: The easiest way could be to delegate comparisions between versions of an item to a notebook, which could GET the different versions of an item from the API, do a [diff](https://en.wikipedia.org/wiki/Diff) and show the result. Disadvantage: no integration in the curation dashboard, moderators need to be sensitive and aware about the curation notebook.
## Solution proposal
The mentioned discussions already gave some proposals:
* It is expected that the highlighting of changes is part of the frontend/curation dashboard.
* Comparision should be always based on the current approved item. If there are more suggested versions it is up to curators to decide which to take. The highlighting of a suggested version should always and only be compared against the current approved item (if there is no approved item available, this could be expressed in an information message).
* Highlighting should be very basic, details are not necessary, it is only about telling curators that one field is different to the one of the current approved item (not telling what is different).
* UX/Design proposal is necessary, could @wytrazek create a mockup for this?
There is also another discussion about this issue, where there is a proposal to have the two versions next to it in one screen, allowing moderators to approve/reject changes. It is also mentioned in this disucssion, that this may be the best solution but also the most tricky one to implement. Thus I propose to go with the simplier version (only highlighting changes) and leave it up to the moderators to decide if they approve all changes. If moderators identify revisable changes, then further inquiry should be done manually (giving a workflow document on how to do this: looking for the current approved item in a second tab and comparing it).
I also think that a solution for this issue is not necessary for the release in December but it should be solved until the end of the project when a new curation team takes over.
Summing up:
* @lbarbot @matej.durco @edward.gray @buddenbohm Please give advise about how sophisticated this issue should be solved
* Based on this a mockup should be created, keeping in mind UX/design issues
* Afterwards @stefan.probst can implement the proposals of the mockupNow or neverStefan ProbstStefan Probsthttps://gitlab.gwdg.de/sshoc/sshoc-marketplace-frontend/-/issues/71Some externalIds are not shown in detail page2021-10-27T15:28:25ZKlaus IllmayerSome externalIds are not shown in detail page# 🐛 Bug Report
We do have different `externalIds` for actors, e.g. `ORCID` but also `Twitter` and `GitHub` (see `GET api/actor-sources`). The ORCID is shown in the detail page but not Twitter, GitHub and the others.
## 🤔 Expected Behav...# 🐛 Bug Report
We do have different `externalIds` for actors, e.g. `ORCID` but also `Twitter` and `GitHub` (see `GET api/actor-sources`). The ORCID is shown in the detail page but not Twitter, GitHub and the others.
## 🤔 Expected Behavior
Every `externalId` of an actor/contributor should be shown.
## 😯 Current Behavior
Only the `ORCID` is currently shown as an icon. See as example on stage the item `training-material/ljss6D`. In `api/training-materials/ljss6D` you will see that the actor `James Baker` does not only have an ORCID but also a Twitter and a GitHub identifier. In the frontend only the ORCID is visible.
## Remarks
I guess this is related to the currently not implemented feature of having `urlTemplates` for the `externalIds`: https://gitlab.gwdg.de/sshoc/sshoc-marketplace/-/issues/80 (could be implemented today). But nevertheless, is there an idea how to show many externalIdentifiers for users? Should there be also an icon and if so, should that icon be part of the `api/actor-sources`-call?
---Now or neverStefan ProbstStefan Probsthttps://gitlab.gwdg.de/sshoc/sshoc-marketplace-frontend/-/issues/114Indicators missing how to interpret category icons2022-07-22T14:09:26ZKlaus IllmayerIndicators missing how to interpret category iconsFeedback by a first time user: there is no clear indication how to identify the category of items in the "all categories" search result list.
The use of the icons for the different categories is not described on the start page/search res...Feedback by a first time user: there is no clear indication how to identify the category of items in the "all categories" search result list.
The use of the icons for the different categories is not described on the start page/search result, e.g. clearly indicating the mapping of the icons to the categories.
Additionally: in the autocomplete such an indicator could be helpful (especially if there are items with the same name but different categories).
Looking deeper you will find out - especially when hovering over such an icon - but there is no immediately indication.
Comments, ideas? @lbarbot @edward.gray @stefan.probsthttps://gitlab.gwdg.de/sshoc/sshoc-marketplace-frontend/-/issues/104Dispatch email to contributors on approval/rejection2022-11-18T14:54:47ZStefan ProbstDispatch email to contributors on approval/rejectioncontributors should receive an email if their suggested version has been approved or rejected by a moderatorcontributors should receive an email if their suggested version has been approved or rejected by a moderatorStefan ProbstStefan Probsthttps://gitlab.gwdg.de/sshoc/sshoc-marketplace-frontend/-/issues/29Check for browser compatibility2021-03-17T13:32:19ZKlaus IllmayerCheck for browser compatibilityWe like to have a list of browsers and versions that we officially support and where we do checks on the browser compatibility. One feedback of the reviewers was on compatibility with the Safari browser: "[Safari] version requires change...We like to have a list of browsers and versions that we officially support and where we do checks on the browser compatibility. One feedback of the reviewers was on compatibility with the Safari browser: "[Safari] version requires changes in CSS probably (to small search engine field, blank image icon etc.)"Stefan ProbstStefan Probst