Use sans serif font instead of monospaced font for Discover table.

[cjcenizal]

Supplants #9798

Keep in mind that the original reason behind the monospaced font (#1716) was to make it easier to compare certain types of fields, e.g. IP addresses. If we decide that the sans serif font is more readable in general, then we will need to complement this change with the ability to specify a monospaced font for certain types of fields.

Before

After

[cjcenizal]

@tbragin @lukasolson @Bargs @weltenwort @uboness What do you think? Personally I find this much easier to read. It also allows each row to show about 20% more content.

[cjcenizal]

Though we may want to format things like time stamps, IP address, and numerical data in monospaced font. For example, comparing the time values in the Time column seems easier when they're monospaced.

[tbragin]

@cjcenizal If you don't mind, you show screenshots comparing what the fonts look like in a table view with different types of data (strings, numbers, IPs, etc..)?

[lukasolson]

Did you intend to keep the field names in monospace? If so, what's the reasoning?

[Bargs]

I'm not sure if either one looks significantly more readable to me in this context.

I don't totally buy the argument that non-monospace saves space, since most users will be selecting individual columns anyway. I fear that we might be trading a small problem (a few lost pixels) for a larger one (additional complexity in formatting only specific fields with monospace, which is also a breaking change).

[tbragin]

@cjcenizal Given the feedback from the team, should we stick to the current fonts and close this PR without merging? What's the reasoning for targeting it to 5.4?

[cjcenizal]

@tbragin I'd still like to pursue merging this at some point. I updated the label because if it gets merged now, it will go into 5.4. Should I remove that?

[tbragin]

@Bargs @lukasolson Are you guys comfortable with keeping this PR open? The way I interpreted your feedback was that you were not excited about the idea.

@cjcenizal for me, I'd still like to see screenshots comparing what the fonts look like in a table view with different types of data (strings, numbers, IPs, etc..)?

[Bargs]

It doesn't hurt to keep it open if CJ wants to keep experimenting. It feels like high fruit/low priority to me though. If we want to switch the default font we'll need to do it in a way that's not disruptive to people who currently rely on the monospace font. But I feel like that leads us into the much larger discussion of view specific field formatters.

[cjcenizal]

Thanks @Bargs and @tbragin. I'll leave this open so I can experiment on it some more someday (it's at the bottom of my priority list). I've removed the version labels for now, to avoid any confusion.

[lukasolson]

@tbragin Here are a couple screenshots comparing table view:

[lukasolson]

I'd just like to add that I'm in favor of this change. I believe most fonts (including the one we're using) have fixed-width numerals... is that correct? So if the argument is that the user wants to compare numbers top to bottom in fixed width, then that seems superfluous.

Now, I do buy that there may be an argument that someone wants to compare textual data top to bottom in a fixed-width font, but I am of the opinion that that should be the exception, not the rule.

[cjcenizal]

Closing this, as I believe we'll be addressing it as part of our redesign.