Web application enabling users and software to browse, upload, and share synthetic biology designs. This repository is a redesign of the original SynBioHub using React and Spring Boot.
BSD 2-Clause "Simplified" License
11
stars
1
forks
source link
SBOL too exposed in Standard Search and too many unclear options within filter types #632
On the Standard Search in dev2.synbiohub.org (https://dev2.synbiohub.org/search), the options for each filter, for example in “Select Role Type”, are not presented in a very user-friendly fashion. Having a long list of options makes it difficult to pin down which ones are relevant, and it might not be clear what each type represents just from their short name (users shouldn’t necessarily have to discern between igem:partType/Coding and so:CDS). Here’s a screenshot of the current way things are shown.
Proposal 1: It would be useful, at an instance management level, to assign custom names for each option, or be able to remove them from the filter altogether if they’re not considered relevant.
If possible, an automated method of grouping related types together under a standard/defined term would be preferable to manual custom name assignments,
e.g. igem:partType/Coding and so:CDS would be grouped under the term “CDS”, and a user search of “coding”, “CDS”, “coding sequence”, etc. will return to the umbrella grouped term.
Proposal 2: Other solutions to make the options more informative are having tooltips for each filter explaining what a user will find there.
Proposal 3: Having a count number in front of each option to show how many parts are contained by that option (like showing “CDS (1234 parts)”).
On the Standard Search in dev2.synbiohub.org (https://dev2.synbiohub.org/search), the options for each filter, for example in “Select Role Type”, are not presented in a very user-friendly fashion. Having a long list of options makes it difficult to pin down which ones are relevant, and it might not be clear what each type represents just from their short name (users shouldn’t necessarily have to discern between igem:partType/Coding and so:CDS). Here’s a screenshot of the current way things are shown.
Proposal 1: It would be useful, at an instance management level, to assign custom names for each option, or be able to remove them from the filter altogether if they’re not considered relevant. If possible, an automated method of grouping related types together under a standard/defined term would be preferable to manual custom name assignments, e.g. igem:partType/Coding and so:CDS would be grouped under the term “CDS”, and a user search of “coding”, “CDS”, “coding sequence”, etc. will return to the umbrella grouped term.
Proposal 2: Other solutions to make the options more informative are having tooltips for each filter explaining what a user will find there.
Proposal 3: Having a count number in front of each option to show how many parts are contained by that option (like showing “CDS (1234 parts)”).