Proposal for a "Jobs view" in the history

[neoformit]

After receiving feedback from a number of Galaxy users (and through my own use) I wonder if there could be a more intuitive layout for the history UI. I have spend some time fleshing out this concept (as requested by @bgruening) but there may be areas of the UI where I haven't considered the implications of this layout - feedback please :)

I think something like this could lead to a much more intuitive, cleaner experience for the history.

Current implementation:

• A job produces any (potentially unknown) number of datasets in the history
• Dataset names often become opaque and confusing with long histories
• The state/logic of the job and the dataset are merged into one element
• There is no UI structure to distinguish the output of different jobs
• Histories become long very quickly, and navigation suffers as a result
• The above problems are reflected in the tool form when selecting an input dataset (unclear which is which)
• Per-job operations can be error-prone and tedious (especially with many outputs per-job)
• Renaming of job outputs has to be done retrospectively, one-by-one (again, tedious)

Proposed implementation:

• The history lists jobs as the primary element, with datasets nested beneath them (as though a job's outputs are a list collection)
• Job-related state/logic are located in the job element
• Dataset-related state/logic are located in the dataset element
• The history length is identical to the number of jobs that have been run
• The jobs-view allows simple navigation by job - separation of outputs is inherent in the design
• Clicking on a job element displays the output datasets of that job (much like clicking on a collection)
• Per-job operations are clear and quick - one can "delete a job" instead of selecting all datasets one-by-one
• Dataset selection in the tool form is clarified by semantic naming of outputs e.g. job xyz > dataset 1
• The job can be named prospectively in the tool form (before the Run button)
• Finally, this UI layout might be implemented as a "View" that the user can toggle on/off (or select from multiple). The conventional dataset view may still be preferred in some situations.

Screenshots/wireframes:

Current implementation

First, an example to demonstrate where the current history layout gets real confusing. Here is a history where I repeated a job on the same dataset with different parameters. It's not clear where one job's outputs end and the next one starts:

Now, a second example I manufactured as a use-case. A user has uploaded 6 raw read files, cleaned them with Trimmomatic and then assembled with Trinity. For comparison, they have also assembled the raw reads. With the current implementation the result is a history spanning multiple pages. To confirm what the final Trinity jobs entail, we have to manually cross-reference data 1 and data 7.

Proposed implementation

A similar history to the above, but with the proposed "jobs-view" (blue traces follow a click). With a glance at this history, the logic of the analysis is immediately clear:

Viewing job/dataset information:

Selecting a dataset and naming a job in the tool form:

[nsoranzo]

I remember discussing ideas along these lines during the hackathon of probably GCC2016, it would be really nice to have!

Finally, this UI layout might be implemented as a "View" that the user can toggle on/off (or select from multiple). The conventional dataset view may still be preferred in some situations.

This would be key, especially to not disrupt existing user expectations.

[mvdbeek]

I completely agree, this to me seems like a very good and simple enhancement, and was always my first alternative Proposition to a graph view for histories.

[jmchilton]

Not a replacement for this idea (which I love) but related is #15237 / #13893 - I wanted to generalize the jobs grids so they have parity with invocations and we can put a list of jobs in the user menu. If we had a handle on jobs in the UI we could do some really great filtering and such outside the context of histories - the way we do with invocations. Using both jobs and invocations to tame large histories is also a great idea though - and like @mvdbeek I always bring this up as my alternative to graph view.