Improve Discover table preview usability.

[cjcenizal]

Changes

• Use sans serif font instead of monospaced.
• Break blob of text up into columns.
• Associate keys and values using whitespace.

Goals

• Regular fonts are superior to monospaced fonts for readability.
• Columns create a grid that improves scannability.
• Allow user to scroll horizontally to see more content in a row.

Caveats

☠️ I need to look through the source and make sure my changes don't adversely affect the UI anywhere else.

Screenshots

Before

After

Comments from UI Review

Highlighting

Searching for a value, e.g. MX, should pull the matching highlighted property to the beginning of the list, so the user doesn't need to scroll to it.

Performance

• Some users have documents with thousands of fields, so we should test the performance and the UX of this view with similar conditions.
• If performance is bad, maybe truncating the number of displayed fields is an option?
• Feature idea: allow the user to specify the order in which they'd like _source fields to be displayed. This will aid scanning for the things they are interested in.

Reporting

Test it and make sure the PDF looks correct.

Scrolling

It's a big usability boost if the horizontal scroll is locked for all the documents, so you can scroll them together.

Performance test

I tested this with documents that have 2000 fields each. The initial load and render is slower (to be expected) but actual performance when scrolling vertically and horizontally seems fine. However, locking the horizontal scroll on all items will be tricky to implement. It's not immediately clear where is the best place to implement that. So for now, I've removed horizontal scrolling and truncated the content instead.

[trevan]

Could fields with large values (>1000 characters) be a performance problem?

[Bargs]

Looks like a nice improvement!

The existing page already performs poorly. _source is only truncated with CSS so the entire document is still inserted into the DOM. I'd be surprised if this new design performs any worse. Though I haven't looked at the code.

Searching for a value, e.g. MX, should pull the matching highlighted property to the beginning of the list, so the user doesn't need to scroll to it.

What if the value appears in one document, but not another? It seems like it would be best to maintain the ordering of fields across documents. Perhaps I don't understand.

[uboness]

also, how does this play with different sets of data (not just your typical logs)?

[cjcenizal]

After discussion, we decided that this may beg for further features (e.g. the ability to scroll, to specify which fields are visible) which fall outside of this _source column's purpose: to give a simple preview of the content in the row (and imply that there is more than just what's visible).

So I'll close this PR and open a new one that specifically explores the font-face change.