-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What limits usability of collections? #8403
Comments
|
|
|
|
For me its often the automatic naming of data sets, which mainly comes from the fact that with Here the list 168 sub.sample shared has been the chosen as input to 179 collapse collection, but the name of the data set says This has been raised here: Problems are at least documented now: In addition I don't see a way to find out which data sets are contained in a collection. For instance the single member of 179 has the name "0.03", which is data set 171. If this data set number would be shown in the collection display the connection would be clear(er). |
But for sure collections are a good step in the right direction. The alternative of having a flat history with no structure (apart from the linear structure corresponding to creation time). Maybe collections just should be used more -- in particular nested collections. For instance, the output of each tool could be a collection containing all the other outputs. The tools of the stacks suite do something in this direction, but without nesting. On the other hand the user then needs to click more to get to the desired information. |
At the moment, it seems collections are primarily for grouping inputs and outputs vis a vis a mapped workflow situation. I am more interested in using collections to group outputs together for easy download as a single unit. Currently, it doesn't seem like you can apply data filters to elements of a collection (as opposed to the whole collection itself), which makes sense for a mapped workflow situation, but not so much for simply grouping outputs. Also, the documentation on filtering output collections vs output data appears to have mistakenly duplicated the docs for filtering data outputs only. |
Some UX bugs during my trawl through old issues, mostly around "missing the standard edit/view/bug icons of normal datasets" |
|
Not being able to change the datatype for all datasets in a collection. It's not even possible to write a script with the API, which would be an acceptable second option. This is just torture, please focus on fixing these bread-and-butter issues because it really affects usability. |
|
This is already possible in the web UI. Open the collection. Then you see a little download symbol at the top. |
Thanks @bernt-matthias, you are right. I wish it was more visible, though. |
Collections cannot be published in the same way that datasets can. Published datasets can be downloaded via (The download button mentioned in the comments above points to If I missed something here, please let me know, it would be very helpful. |
I would like to see wider adoption of collections among Galaxy users, and I'm trying to understand how we can improve collections (or the documentation surrounding collections) to reach that goal. So if you've tried them recently and were stuck at any point and felt that going back to regular datasets was the better option please let us know!
The text was updated successfully, but these errors were encountered: