New User UX for viewing Artifacts and Visualizations

[ebolyen (Evan Bolyen)]

Hi @kastman!

Thanks for the great topic!

@kastman

Is there any reason for peek and view to be separate tool commands, at least from a UX perspective?

q2view definitely blurs the line between them so from a user standpoint answer is probably "no". However there is a mechanical difference. Peeking into an artifact or visualization does not require extracting anything. Instead an offset into the zip file to find the metadata.yaml file is done which is faster than extracting the entire archive which is necessary for view to work.

In that context, peek becomes useful for allowing other interfaces (like q2studio) or even users to perform type-checking ahead of time without needing to extract every artifact it may be looking at.

@kastman

These are just pickled objects, right, so deciding which processor should be easy. Is there a reason not to combine the commands, given that you’d alias one to avoid breaking? I’d imagine wanting to view both artifact and vis.

They are technically zip files with a specific directory layout.

@kastman

I want to get a view of the relevant raw components of an artifact (e.g. the first few header / [qual] / sequences of a fasta/fastq, or the first few rows of a feature table). Essentially cat sample.fastq | head. However, it seems like peek (and even the view.qiime2.org links from the tutorials) provide metadata, uuid, and provenance, but don’t actually tell me what the data is. Is there yet another viewer to do this? Is it something people aren’t doing right now? Especially since each semantic type is a first class citizen, this seems like a really necessary step for adoption.

There is a qiime tools export command which get's you half the way. The tricky part is there isn't necessarily a single file to look at (say with head). For example SampleData[SequencesWithQuality] is a directory of fastq.gz files with illumina naming convention and a manifest (for future proofing). The manifest is likely a good target for some kind of "head" command in the example, but how would the computer know that?

Right now, there isn't a generic way to tell the framework: "When you see this format (from metadata.yaml) you can summarize it with this code". It's something we've definitely talked about, but since you can also just export the data, it hasn't ever really become a critical priority for us.

I would expect that kind of registration to be done on the semantic type itself, and it could invoke the same transformer system that methods/visualizers use.