Hover-over field help dialog (aka "column meta data")

[showipintbri]

Describe the solution you'd like
In the main table there are fields that I can't remember what they are used for or what their contents are telling me. It would be helpful to implement a "hover-over" help feature that throws an integrated popup with a brief explanation of the field and it's possible values for the main table not just in the details pop-out.

One simple example is the 'history' field and the meaning of "D" and/or "Dd"

[philrz]

@showipintbri: That's a clever idea. Will discuss with the Dev team and see what's possible. Thanks for your interest in Brim!

[jameskerr]

@showipintbri there is a feature in the app today that provides the information you want. If you click on that log then open the Right Pane which shows the log details, then hover over the word "history" in the fields list, you'll get the description of the field. It includes the meaning of the mysterious letters. Hope that helps!

We'll need to improve the discoverability of this. Maybe we can also add this hover info to the column header.

[philrz]

@jameskerr: Thanks for pointing that out. I was going to bring up this topic with the Dev team at our Tuesday session next week because the way the inquiry was phrased made me think of something a bit more sophisticated than what we have today. But since you've taken an interest sooner, I'll dump out some preliminary thoughts now.

As you and I both know, the contents of that hover text is static stuff we bring over from Zeek. Using this specific example of the Zeek History field, indeed the information needed to decide the meaning of a Dd is in that help text. However, we also know from the Zeek community that there's specific combinations of letters in that field that have significant meeting, such as SAD that's indicative of Zeek having only seen one half of a connection (e.g. presence of asymmetric routing). This makes me think of a couple diffs vs. what we do today:

1. The hover could be tied to the value (i.e. hover over SAD and it tells you "Zeek is likely only seeing one half of a connection") rather than the field name. That would save the user the cost of having to "parse" the meaning of the characters in the value each time.

2. The text that's shown could be something that's populated/modified by the user, such as if they had their own unique interpretations of field values (either for something like Zeek, or for some custom proprietary data source.)

Much like how we talk about our plans to have join-able additional data sources in a Lake (threat intel, etc.) this could perhaps be yet another such data source, with the "hover" action being what triggers querying it.

If we went that route, I can think of a couple follow-on enhancements, such as config that determines when the hover applies, e.g. maybe only show SAD if the record being examined also has _path=conn since that identifies a Zeek record where the history field is known to exist and have significance, whereas SAD as a value in some other log source might have a completely different meaning.

Yet another enhancement would be to allow users to load these configs easily from GitHub/Gists like we talked about doing with Query Library entries (#1421). Once again going with the Zeek community example, maybe someone who publishes a Zeek package that creates a new log type could include the "dictionary" of field value meanings to go with it, and this would make it easy for the user to load/update it in the app.

Speaking of dictionaries, I then thought of a wholly non-technical use case. For instance, imagine someone who doesn't speak English as a first language is looking at English language logs. If we gave them the ability to load an English language dictionary, they could hover over fields and get immediate translations of unfamiliar words.

I don't know how much of this the original requester had in mind, but that's what all came to mind when I said it sounded clever. [😄 ] I'll be sure to bring it up with the team next week and see if others like the ideas or have other tweaks.

[showipintbri]

@jameskerr Thanks for the reply. I am aware of the hover-over dialog in the 'details pane'. I was specifically looking for it in the table view.

I also like the idea @philrz brought up of, providing contextual information based on the fields contents. 👍 You have my vote!

[philrz]

@showipintbri: We were talking about this one more as a team today. I'd be helpful if you could clarify what you meant by "looking for it in the table view". Going back to your original screenshot, are you saying that it's also be helpful if the existing field-describing text came up when hovering over the column header of a table? I see that's not activating currently, but I just want to make sure we're talking about the same thing.

As for hover text based on field contents, the team all seemed to like the idea. Just to set expectations, it may be a while before we get to implementing this one, but it's on our list. 😄

[philrz]

We also noted how some apps have visual cues to indicate that additional detail might be available via hover. For example, in Google Sheets, if a cell has a comment attached to it, there's a little triangle visible in the cell.

@jameskerr also cited Wikipedia hover text as a good model to follow.

[showipintbri]

Sure Phil, thanks for giving it some extra consideration. I'll try to explain what I was hoping for.

In keeping with the 'history' field theme, I was hoping to be able to hover over a field in the main table (I'm not sure what you actually call this pane) and have it produce a pop-up similar to the tool tip in common windows tools.

I do know this hover over pop-up is available in the "details" pane but it doesn't pop-up in the table view.

Secondly, it would be helpful if the pop-up gave specific contextual help based on the contents of the field rather than general information.

[philrz]

This topic came up again recently. When working on #2981 I noticed that the hover text we had working in the Detail pane for Zeek data stopped working when #2895 merged. I checked with @jameskerr and he acknowledged that we should probably remove that code for now since it was only ever a sort of intro proof-of-concept step. When we have the time we agreed it'd probably be worth bringing it back in a smarter form that uses the plugin API and implements some of the ideas in the comments above, e.g., letting users easily add descriptions for their own custom data sources, having help text change based on field values, etc.