Skip to content
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

Open
mvdbeek opened this issue Aug 2, 2019 · 8 comments

Comments

@mvdbeek
Copy link
Member

commented Aug 2, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 2, 2019

@mmiladi

This comment has been minimized.

Copy link
Contributor

commented Aug 2, 2019

  • collection is not well scalable. My browser has difficulties with opening and searching collections of large size.
  • takes too much (twice? unnecessary?) hidden entries. histories in the "show hidden" mode are super lengthy & unmanageable. A "show hidden but not the collection single entries" button would be great! :)
  • restart an entry from an output collection: There seems to be no way to automatically switch between restarting single entry to restarting the whole collection (at least idk)
  • Different tags for different entries of a collection are not shown.
  • A sustainable and reliable way to make collection out of a zipped input would be great!
@erasche

This comment has been minimized.

Copy link
Member

commented Aug 2, 2019

  • failed collections which contain no datasets do not offer a way to view or report errors
@ThomasWollmann

This comment has been minimized.

Copy link
Contributor

commented Aug 2, 2019

  • 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

This comment has been minimized.

Copy link
Contributor

commented Aug 6, 2019

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:

#7467
#7392

Problems are at least documented now:

galaxyproject/planemo#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

This comment has been minimized.

Copy link
Contributor

commented Aug 6, 2019

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

This comment has been minimized.

Copy link

commented Aug 12, 2019

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.

@erasche

This comment has been minimized.

Copy link
Member

commented Aug 15, 2019

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

@erasche erasche added status/planning and removed planning labels Aug 22, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.