galaxyproject / galaxy

Data intensive science for everyone.
https://galaxyproject.org
Other
1.38k stars 996 forks source link

What limits usability of collections? #8403

Open mvdbeek opened 5 years ago

mvdbeek commented 5 years ago

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!

ThomasWollmann commented 5 years ago
mmiladi commented 5 years ago
hexylena commented 5 years ago
ThomasWollmann commented 5 years ago
  • A sustainable and reliable way to make collection out of a zipped input would be great!

Checkout: https://toolshed.g2.bx.psu.edu/repository/view_repository?sort=name&operation=view_or_manage_repository&id=c30c030673c90378

bernt-matthias commented 5 years ago

For me its often the automatic naming of data sets, which mainly comes from the fact that with multiple="true" collections are not treated as collections but as a bag of data sets. Take for instance the following history that I created in the (short) mothur tutorial from the GTN.

Screenshot from 2019-08-06 11-30-37

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 Collapse collection on data set 171 which is hidden in the history. So the connection of the steps is obfuscated.

This has been raised here:

https://github.com/galaxyproject/galaxy/issues/7467 https://github.com/galaxyproject/galaxy/issues/7392

Problems are at least documented now:

https://github.com/galaxyproject/planemo/pull/930

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).

bernt-matthias commented 5 years ago

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.

birnbera commented 5 years ago

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.

hexylena commented 5 years ago

Some UX bugs during my trawl through old issues, mostly around "missing the standard edit/view/bug icons of normal datasets"

nsoranzo commented 4 years ago
simonbray commented 4 years ago

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.

simonbray commented 4 years ago

Downloading all files in a collection (can be done with bioblend).

bernt-matthias commented 4 years ago

Downloading all files in a collection (can be done with bioblend).

This is already possible in the web UI. Open the collection. Then you see a little download symbol at the top.

simonbray commented 4 years ago

Thanks @bernt-matthias, you are right. I wish it was more visible, though.

simonbray commented 4 years ago

Collections cannot be published in the same way that datasets can. Published datasets can be downloaded via /datasets/{id}/download; this doesn't work for collections.

(The download button mentioned in the comments above points to /api/dataset_collections/{id}/download (/api/histories/{hid}/contents/dataset_collections/{id}/download seems to work fine too) but these require API authentication so are not helpful. Yes, you can probably log in, import the history and download, but IMO 'public' means 'available to everyone, not just people with Galaxy accounts'.)

If I missed something here, please let me know, it would be very helpful.