search

iris-hep / as-user-facing

Collecting information on the user-facing interface to the analysis system
5 stars 1 forks source link

User story: quick plot #2

Open jpivarski opened 5 years ago

jpivarski commented 5 years ago

A physicist has a thought about a possible analysis (or sub-analysis, part of a systematics study, for instance) and doesn't know if it's realistic. It depends on the spectrum of X. This X is a frequently studied column of the data, so it's likely to be in the query system's cache. The physicist opens a JSFiddle-style web interface and types in the variable name (with tab-completion, or finds it in a menu on the page) and immediately gets the plot.

As it turns out, the analysis is totally unrealistic (swamped in background) and after about an hour of optimistically applying cuts, the physicist eventually gives up and starts thinking about a different approach. In the end, this saved 3 weeks of making skims to do the doomed analysis formally, only to come to the same conclusion.

jpivarski commented 5 years ago

Full analysis cases are also important. I wanted to include this one in contrast to those real analyses.

gordonwatts commented 5 years ago

@jpivarski - I wonder if we could make this a bit more linear? There are actually lots of steps in here - what data sets they look at, for example. The tool (tools?) have to support that too, yes?

cranmer commented 5 years ago

These should go into individual .md files that the README links to.

gordonwatts commented 5 years ago

Ok. Just as long as we don't get lost in the "simple plot" - there is a bunch of context that makes it "not simple" even when the actual plotting is simple. I wonder if this is begging us to reimagine everything, which we should clearly steer clear from here.

jpivarski commented 5 years ago

You're right that "simple" and "easy" are supposed to refer to the user experience, not the difficulty of implementation, which is harder for this case than the others we've considered. But that's exactly why I'm proposing it as a user story: it probably wouldn't be made possible if not explicitly addressed and there's a real reason to want it—the story describes new capabilities that would positively impact analysis.

In the next round, after collecting all of these stories, we could weigh it against everything else we have to do and say, "That's too hard—we're going to explicitly reject this story because we're defining the scope of our work and we don't have resources to go that far." Then users who were hoping for it aren't left with the misunderstanding that it's coming, and other projects with a different focus might want to try to attack it.

But at least specifying the story in this round of brainstorming has value.