Pools UX: Switching between, side-by-side, opening new views

[philrz]

When @mccanne was giving some recorded UX feedback after his experience preparing for Sharkfest-21, he remarked on the difficulties he had working with multiple pools. Here's some of his own words, though I've tried to fill in the parts that describe where he was clicking:

I find myself wanting to move back & forth a lot. My muscle memory goes [to the pools list] to move back and forth, but that's not what I want [because it replaces whatever is currently in the main events panel, replacing whatever queries/output I might have been looking at]. To get the other view next to it, I need to [click to a new blank tab, then click on the pool I want to work with, then click back to the prior tab]. It feels like if I was here [in the original view and there wasn't already a tab for the pool I clicked on] I would get a new tab [with the pool I just clicked in it.]

(For UX Brim team members, here's a link to the spot in the recording https://www.youtube.com/watch?v=qSim8spmYZw&t=36s)

[jameskerr]

There is precedence for this type of interaction in text editors. In my editor, I have my list of files in the side bar. If I click on a file for the first time, it opens a new tab for that file. If I click on a file that I've already clicked on, it takes me back to that tab.

I wonder if this is makes sense for our app though. I think it would work now because we are still very pool centric. But when we move away from the concept of "being in a pool" then the similarity of "being in a file" (as in the text editor example), won't exist anymore.

But, the goal of make it easy to move around different pools quickly is a worthy one.

[philrz]

@jameskerr: Maybe this is subject to change, but I have the sense that "being in a pool" is not something we're going to move away from. That is, multi-pool queries should be doable (indeed, they already are!) but the convenience of having a single pool clicked and knowing all queries you enter without explicit from will be executed against the currently-selected pool seems like a great convenience to maintain, particularly for the newer users.

This is just brainstorming, but here's a thought I'll add to the pile. We could start from your editor's approach that you described in your first paragraph. But then if the user has multiple tabs open that are already clicked to that same pool, clicking on the name of that pool in yet another tab would bring the user to the "left most" tab that's open for that pool. We could also add right-click options on the pools list for "Open in new tab" and "Open in current tab".

[jameskerr]

I'm thinking that we make the current pool a part of the search bar area like the time picker. In early brim days this was where it was located. When clicked, we can select a new pool or select multiple pools.

Maybe we have a section in the side bar called "Open Tabs" with the titles of each tab listed. My text editor has an "Open Editors" section that does just that. Then Steve could switch back and forth between tabs using the sidebar.

If we do make the current pool into the search bar area, then the pool list would need to change. For example, when you click on a pool what should happen? Maybe if you have a tab open with that pool selected, it bounces you there. Maybe clicking a pool takes you to the pool info page which includes the git log, a summary of the data in there, the shapes, with an option to "Search this pool". Part of me does think it should change the current tab you're on though. We should have an option to open in a new tab if you want. Maybe like a command click opens it in a new tab.

[philrz]

Nice thoughts @jameskerr. I also checked in with a very active community member and pointed them at this issue and they offered this take.

Yeah I think it was one of the things that's kind of annoying but I keep forgetting to mention it.  I end up jumping around a lot and looking in one pool then another and I've been trying to keep them in tabs to keep it all separate but forget sometimes.  What I did notice is that a search history is kept for each pool, so maybe the fix is if a new pool is clicked for the first time then a new tab is opened or maybe you don't even have to open a new tab.  But, if the pool has been clicked already or at least has one search in the history then it will automatically used the last search in the history.  That way it's like saving the point where it was left off of.

I've been using the history to pretty much fix that issue.  If I click on a pool and come back I select the latest in the history

May not work exactly as planned when you start doing multiple tabs with the same pool though

[mccanne]

With our work on the new query editor and sync'd UI elements, I think this issue will get revisited in that context. So I don't think we need to solve this in isolation... putting in icebox for now.

[mccanne]

We will revisit this in Dec planning and figure what if anything to do here...

[mccanne]

This relates to the what the new query editor model all entails...