Table truncation / wrap audit in the Security app

[yiyangliu9286]

Aligned UX Guideline / Decision [November 2 2021]:

After in discussion with the Security design team; here are the agreed design decision for long text table cells and date format guidance for the Security app:

• If a column's text is too long, use Truncated (w/ tooltips) is the direction to go
  • If we use truncation character limit: suggested to be max length 79 (average is 39 see resource)
• For the general guidance for Date format in Security app's tables (unless there are exceptions for specific request for displaying accurate Timestamp to milliseconds like the Alerts table), we do:
  • If less than 24 hours, display relative dates (i.e. “5 minutes ago) with a more detailed hover tooltip up until 24 hours
  • If more than 24 hours, we write the default format (xx.xx.xx), where is taken from Kibana settings, field dateFormat + a more detailed hover tooltip

Context:

This audit exercise examines how we treat an overflow of long text being displayed in different Tables within the Security app.

Goal:

• Identify different behaviours for long text usage in Tables
• Mainly if truncated vs. hover tooltip
• Discuss and decide if we should align or not align on the behaviours
• Next step is to collaborate with developers for further fixes if needed

Design contact: Yiyang Liu
Engineer: Vitalii Dmyterko, Georgii Gorbachev
Team: Security D&R, Security Design

Resources:

Please view full audit in this doc
Info about name characters (quoted by Dima's conversation here): the Eden XDR project, the average rule name length is 39, max length 79

Some highlights from the full audit docs are:

Rules

1. Rules tab

• Behaviour:
  • After 7.15 Truncated (w/o tooltips) for scannability
  • Before 7.15 Wrapped
• Screenshot (for truncated w/o tooltips):

• Screenshot (for wrapped):

Suggested next step [need to fix now]:

• For readability, we should make Rule and Last updated columns as truncated + tooltip format (similar to Endpoints table)

• For readability, we should redesign the Tags column (to something like 2 tags max + a number with Popover to show all the tags) [needs design]

2. Rule monitoring tab

• Behaviour: Truncated (w/o tooltips) for scannability
• Screenshot:

Suggested next step [need to fix now]:

• For readability, we should make Rule column as truncated + tooltip format (similar to Endpoints table)

3. Exceptions

• Behaviour: Truncated (w/o tooltips) (e.g. Rules assigned to column) + Tooltips

• Screenshot:

Suggested next step [need to fix now]:

• For readability, we should make Rule assigned to and Last edited columns as truncated + tooltip format

[yiyangliu9286]

Possible next step:

• Gather some feedback from the Security design team (the team was suggested to use Truncated + tooltip to solve some low hanging fruits, I have concluded in the suggested next step section above).
• Group existing / new issues for any table UI enhancements with the delivery team.
• Discuss and align the decision with delivery team and PM what are the priorities for making these UI enhancements changes.

Long-term question:

• Based on some current behaviour + quick fixes after we align on some decisions, do we need to come up with some general guidance and suggested behaviour for how to treat long text column in Tables across the Security app? (open for discussion and suggestions for that 👍)

[bfishel]

I have more thoughts on this than I realized 😂 -- jotted them down below:

I’m super curious to hear the collective opinion on this. This occurs a TON — in many of our tables and sometimes on multiple columns within tables. I haven’t done any formal documentation, but when I worked more extensively with observability and Fleet I remember thinking this occurred lot more rarely there. When it did occur, it was generally isolated to one column — usually a description column. At that time, the designers dedicated more room to that column and truncated w tooltip when it overflowed.

And I think reason this issues affects security so much more than other solutions is multivariable:

1. We generally have way more columns per table than tables in other solutions.

In conversations I’ve had in the past with designers outside security, this the first thing that comes up. I’ve gotten feedback from Elastic designers that we need to audit our tables and remove columns, and perhaps but the extra info into a details page or flyout. Coming to a consensus on what stays and what goes though is something I’ve found much easier said than done.

The other piece of feedback I’ve received in response to this is that maybe tables aren’t always the right component to use given the data we have. I think this potentially makes sense for datasets where the cell input is generally long for multiple columns (more on that below), like trusted apps which was originally a table. If the problem is simply that we have many columns with limited characters per cell (say an average of ~12 characters or less), I still think a table/data grid is right and we need to audit content. 


2. We often display dates very, very specifically. 


This takes up a lot of space and makes it so that column and other columns are more likely to be truncated. My recommendation here is that we display relative dates (i.e. “5 minutes ago) with a more detailed hover tooltip up until 24 hours. At that point, we write the date (xx.xx.xx) again with a more detailed hover tooltip.


Furthermore, we have a lot of columns where the input is likely to be long. I mentally separate this point into a few different categories.



One is multi-word input (i.e a description). These can sometimes be a phrase. And sometimes they can be a sentence plus. For ones where the description is generally a phrase. I think it makes sense to give more space to that column and then truncate+tooltip the excess. If the input is generally more than a sentence, first I’d consider seeing if we can put a character limit on that input field (I wonder something similar for long names I.e. policy/trusted app names). If that doesn’t make sense, I could see dedicating two rows to that text input across the board (I.e. making every row in that table taller).







Another is a set of elements tied together. This can be multiple tags (repeated elements), a status + revision # + out of date tag (combined elements). I’m still not sure how to address repeated elements. For combined elements, my immediate thought is that we separate them and then audit table columns. In my experience, we combine elements into one column to avoid adding an additional column when what we should be doing is being more selective about what columns are necessary.







The last is long strings of text, like IP addresses, sensor versions, etc. My thought on these is that we truncate the middle and add a hover tooltip, (I.e. abc…xyz)

Again, just my take and I would love to know how others see this.

[gavinwye]

This is a bit of a brain dump. I feel like we could have a very long conversation about this.

1. Tables are hard! Generally, I've avoided using tables to display content for the last few years. Getting them to work well on mobile devices is really hard. And there are some big issues that I only have a rough understanding of.
2. let's make everything consistent, it doesn't matter if it's wrong. Consistently wrong is better than occasionally right. From there we can make a list of all the places this occurs and work towards a good fix. I'd go for wrapping because it makes it easier to see everything in one place.
3. @yiyangliu9286 you talk about two concepts - 'readability' and 'scanability' - so we're all on the same page are you able to define what you mean by these and how they are important in a given context?
4. I'd like to know what the possible worst/best case is and if we know how often it will appear. For example, is 80% of the data that we show in these columns over x chars long, what's the average. How often is this a problem?
5. have we considered a multivariate test for this? personally, I prefer the wrapping version because it's easier to see all of the content.
6. What is the point of the table? Do we want people to interact with individual elements? If we know we want people to take a specific action we can measure this in a multivariate test and measure which design works best for that outcome.
7. Is this a content design problem? In the Alerts screen > Rule column, the content is RDP (Remote Desktop Prot...) can we simplify that by removing the acronym? Are rules named by users? 🤔 What could we do to help users pick sensible/workable names?
8. personally I don't like tooltips. For these reasons:

• people need to understand that they can get a tooltip by hovering, not everyone gets this
• they don't work for people who don't use a mouse to navigate
• they don't work for people who use a mouse but have a motor impairment for instance Parkinsons (our text size is very small making our target small)
• they don't work for people using a screen magnifier
• we're deciding what content to hide, can we always make that decision reliably

9. I don't like truncating because we're hiding information, if the information is important enough to be displayed we should display it fully.

@bfishel

1. We generally have way more columns per table than tables in other solutions...

I agree the number of columns is large. I'd be up for removing this complexity. In my experience, this kind of complexity comes from not really understanding users needs around the interface. How opinionated are we in taking things away? A really good way to find out if users need a thing is to remove it and see how much they complain about its loss? We can do that in a controlled way.

2. We often display dates very, very specifically. 


Yes!, GitHub doesn't this I think.

I agree about making the rows taller for things like descriptions. We should work out what we need to show people and then work out the best way to present that content. A table may not be the best way.

A few final thoughts

• we need to understand what people are trying to do with these tables (the need)
• we need to understand the purpose of the content and how it serves that need
• when we know those things we can show people the content that they need and we will be meeting that need

I'd love to hear others thoughts too...

[banderror]

@yiyangliu9286 Thank you for the write up, I went through this discussion ticket and the doc.

Regarding "Truncated (w/o tooltips)" vs "Truncated (w/ tooltips)" vs "Wrapped":

• [Security Solution][Detections] Fix truncated values in columns for rules table kibana#115825 made all columns of the Rule Management table "Wrapped". It targets 7.16.
• Do you think the overflow problem for table cells still needs to be revisited? I think the UI is still inconsistent between Rule Management and Exceptions table, and probably other tables in Security app?

I also created a few new tickets for table UI enhancements, please take a look and let me know what you think. I hope we could finalize at least one of them soon if you agree with the ideas in general.

• [Security Solution][Detections] Table UI: consistent "See all" buttons kibana#117029
• [Security Solution][Detections] Table UI: sizing columns efficiently kibana#117030
• [Security Solution][Detections] Table UI: consistent dates kibana#117034
• [Security Solution][Detections] Table UI: consistent tooltips (Rejected) kibana#117042

[yiyangliu9286]

Thanks for all the design consideration input @bfishel @gavinwye!

@banderror Thanks for adding all the issues below. I will address the design considerations for those items on how to address those in those issues.

Do you think the overflow problem for table cells still needs to be revisited? I think the UI is still inconsistent between Rule Management and Exceptions table, and probably other tables in Security app?

@banderror @vitaliidm Yes I agree, the wrap behaviour is a short-term fix for 7.16, and we should address the consistency problem for Rules and Rules monitoring tables going forward in the future. See below the general guidance.

After in discussion with the Security design team; here are the agreed design decision for long text table cells and date format guidance for the Security app:

• If a column's text is too long, use Truncated (w/ tooltips) is the direction to go
• For the general guidance for Date format in Security app's tables, we do:
  • If less than 24 hours, display relative dates (i.e. “5 minutes ago) with a more detailed hover tooltip up until 24 hours
  • If more than 24 hours, we write the date (xx.xx.xx) again with a more detailed hover tooltip