[Ingest Node Pipelines] Start Test Data List at the First Document

[cuff-links]

Summary

This is a suggestion that I came up with that just makes the UX feel a bit more natural to me. While testing #74964, I added 10 or so documents of test data to test the pipeline by following the steps in the issue. I noticed that when I got to the point of verifying each processor's output, the dropdown that displays the test data persists the last document chosen even when you move to another processor. So when I got to document 10 on the first processor and wanted to verify the second processor, it started at document 10 in the test data. I would think that the dropdown would always start at the first document.

[elasticmachine]

Pinging @elastic/es-ui (Team:Elasticsearch UI)

[jloleysens]

This is an interesting one @cuff-links ! As I understand it the idea with the document dropdown is that it is scoped to the entire pipeline, not per processor. So even though the drop down is inside of the flyout, when the selected document changes it changes for the entire pipeline.

I'd be interested to hear @alisonelizabeth thoughts here, perhaps removing the document selector in the flyout would "solve" the UX problem that @cuff-links is describing.

[alisonelizabeth]

Thanks for bringing this up @cuff-links! This is interesting. @jloleysens is correct; the document is scoped to the entire pipeline. I'm not sure if removing the selector from the flyout would be beneficial either, as then you would only be able to change it from the main processors view. At least now, in your case, you could manually change it back to the first document.

One suggestion I received from user testing was to have something like a "previous" and "next" option in the flyout for the processor output. That way you could easily jump to the next processor to see how the output changes. I realize as I'm typing this, this solves a different problem than the one you're mentioning 😄. But I think a more common flow would be to verify document 1 as it passes through each processor in the pipeline. Then, change to document 2, and repeat the process, and so on.

[cuff-links]

Thanks for clarifying the use case for me, @alisonelizabeth and @jloleysens! That definitely helps me understand what I should have been doing. I truly believe that most users would have already known what they were doing and not have bumped into the issues that I did. But one thing we can do to be a little more explicit is perhaps make the header for the section a little more descriptive. Currently, in the fly-out the header states Preview changes to the test document. I think we could maybe have a header that says something like Watch Your Data Move Through The Pipeline or Watch A Document Move Through The Pipeline. Using that in conjunction with the previous and next options that @alisonelizabeth mentioned above may make it so that there's less possibility for confusion or misunderstanding the feature, like I did.

[alisonelizabeth]

I'm going to close this issue for now. If we get more feedback that the copy or general UX of testing a pipeline is confusing we can open another issue.