[Logs UI] Proposal: Make column widths configurable

[weltenwort]

Summary

With #34916 gained the ability to add additional columns to the Logs UI. One big limitation is the lack of control over the column width. The naive ratio-based sizing it currently implements is not ideal for many use cases.

Rationale

Auto-sizing the columns is not really a feasible option due to the incremental nature of the log loading process. It's impossible to know the size of not-yet-loaded log entries that will be fetched when scrolling. At the same time changing the column widths whenever new data come in has the effect of causing sudden and unexpected jumps in the layout, which would cause the user and the browser to lose track of scroll position.

As an alternative, the user could be given the ability to explicitly configure the size of the columns to match their best estimate of what width would be useful to their use-case.

Mockups

⚠️ preliminary work, needs more thought

[elasticmachine]

Pinging @elastic/infra-logs-ui

[OrangeDog]

Being able to drag to resize (and for the UI to remember the size) would be ideal.
The message column (if present) should always take all remaining space.

[alvaromarithompson]

I would mirror what @OrangeDog has stated, having a few fields within the log view automatically squashes the message field, with the "other" fields taking up an equal spacing. This can make it awkward to read the content.

[weltenwort]

That is good feedback, thank you. While we're talking about it, do you have any opinions on the preferred way to display the value if the column is too small? Does wrapping by default make sense or would truncation (with an ellipsis) be best for your use-case?

[OrangeDog]

@weltenwort it should use the Line Wrapping that already exists under Customize.
On that subject, can the options in Customize please be remembered somewhere (e.g. localStorage)?

[weltenwort]

@OrangeDog yes, that makes sense

In regard to remembering the settings, they are already "persisted" in the url, so bookmarking and sharing should just work. We've been hesitant to introduce another layer of persistence (like localstorage), because it can be the cause of much confusion and makes debugging harder. Would adding the ability to set a "default" in the source configuration be an improvement if you consider your workflow?

[OrangeDog]

A default would be an improvement.
When I click the "logs" button on the side, I want the same configuration as when I last used it.

[cpmoore]

+1 For both ideals
Regarding column widths, its harder to debug issues if you're looking at the host.name and message field and both have the same width, even though the host.name is generally only around 15-20 characters.

As far as localStorage I agree with @OrangeDog when you go to the UI it should have the same customization as the last time you used it. Another thought would be the ability to save the configuration of the columns and load it back later. It would be handy with using different configurations for different datasets.

Also, the column order should be resortable, without having to delete and add back, but there's probably a separate issue for that.

[weltenwort]

Thanks for the additional input! Persisting the column widths with the rest of the source configuration is the most obvious first step to me.

I'm imagining giving the choice between two width values:

1. Fixed with the width given as a character count (which is what the timestamp column currently uses) or
2. Stretch with a weight that determines how much of the remaining space the column gets (which is all other columns currently do)

I'll create a mockup soon ™️

Also, the column order should be resortable, without having to delete and add back, but there's probably a separate issue for that.

Yes, we're tracking it in #35736 and work on it has already started.

[jasonrhodes]

I feel like the simplest solution for this problem is just to allow the columns to be resizable using click and drag in the log stream UI. Even if those changes don't persist, it'd be a good bit better than today where you can't change it at all.

As a parallel effort, we could allow percentage-based settings to be specified in the configuration so they can set their "default" widths that get loaded on every visit to the Logs UI. I think percentage may be plenty (defaults to "auto" or something to specify that we handle it, or a percent value if they want to control it).

How does timestamp currently do width based on character count?

[weltenwort]

I feel like the simplest solution for this problem is just to allow the columns to be resizable using click and drag

I would contend the simplicity of that in terms of clean UX, accessibility and technical implementation 😉 I'd be happy discuss that during the planning session.

How does timestamp currently do width based on character count?

1. the log view component measures the width of a monospace character

   kibana/x-pack/legacy/plugins/infra/public/components/logging/log_text_stream/text_styles.tsx

   Lines 42 to 73 in 13af340

   	export const useMeasuredCharacterDimensions = (scale: TextScale) => {
   	const [dimensions, setDimensions] = useState<CharacterDimensions>({
   	height: 0,
   	width: 0,
   	});
   	const measureElement = useCallback((element: Element | null) => {
   	if (!element) {
   	return;
   	}
   	const boundingBox = element.getBoundingClientRect();
   	setDimensions({
   	height: boundingBox.height,
   	width: boundingBox.width,
   	});
   	}, []);
   	const CharacterDimensionsProbe = useMemo(
   	() => () => (
   	<MonospaceCharacterDimensionsProbe scale={scale} innerRef={measureElement}>
   	X
   	</MonospaceCharacterDimensionsProbe>
   	),
   	[scale]
   	);
   	return {
   	CharacterDimensionsProbe,
   	dimensions,
   	};
   	};

2. it takes the current date formatted according to Kibana's settings

   kibana/x-pack/legacy/plugins/infra/public/components/logging/log_text_stream/scrollable_log_text_stream_view.tsx

   Lines 289 to 291 in 13af340

   	const { CharacterDimensionsProbe, dimensions } = useMeasuredCharacterDimensions(scale);
   	const referenceTime = useMemo(() => Date.now(), []);
   	const formattedCurrentDate = useFormattedTime(referenceTime);

3. and multiplies its length with a slack factor to accommodate slightly longer formatted date strings (and adds padding/margins, of course)

   kibana/x-pack/legacy/plugins/infra/public/components/logging/log_text_stream/log_entry_column.tsx

   Lines 64 to 71 in 13af340

   	[column.timestampColumn.id]: {
   	growWeight: 0,
   	shrinkWeight: 0,
   	baseWidth: `${Math.ceil(
   	characterWidth * formattedDateWidth * DATE_COLUMN_SLACK_FACTOR
   	) +
   	2 * COLUMN_PADDING}px`,
   	},

[jasonrhodes]

Suggestion coming out of our grooming session: let's work this ticket so that you can configure the proportional widths for all of the columns except timestamp, and leave timestamp as it is right now (auto-configured to be the number of characters in the timestamp, as styled based on the user's Kibana date format settings).

Give this comment a thumbs up if you're on board with that plan and we can re-work the ticket or create a new one to summarize that scope.

[jasonrhodes]

Implementation for this is now being tracked by #44327 (didn't want to edit this description and lose the conversation/research done here)

[raulvaldoleiros]

Is this already possible?