[Security Solution] Suggestion: remove dead space in the header of the Alerts section #120287
Assignees
Labels
8.2 candidate
considered, but not committed, for 8.2 release
enhancement
New value added to drive a business result
Team: SecuritySolution
Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc.
Team:Threat Hunting:Investigations
Security Solution Investigations Team
Team:Threat Hunting
Security Solution Threat Hunting Team
UX: UI/UX Designs
Requires design mocks before development and UX lead approval on PR before merge.
Comments
snide
added
bug
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
snide
removed
bug
25 tasks
michaelolo24
added
Team:Threat Hunting:Investigations
adamwdraper
added
8.2 candidate
|
@yiyangliu9286 let's set up some time to talk through this. Like @snide mentioned, I think we should take this opportunity to remove extraneous UI and re-focus this page to make sure it is optimized for its purpose which is triaging alerts. |
Figma mockup: https://ela.st/dead-space-removal
Note: "Extended toolbar" is based on exploration for hide/show actions from #120291
Note: Page preview based on updateas from #120282 and #120291
cc @snide @paulewing |
|
Pinging @elastic/security-threat-hunting (Team:Threat Hunting) |
|
Wanted to document all the elements that may make up a page header so we have them accounted for: Page title (this will not be redundant for details pages, for example) buttons |
|
also wondering how removing a title affects accessibility, particularly on screenreaders. I do think our title is quite big, but I'm a little worried about the ramifications of taking it out entirely. |
|
Here are mockups to reduce dead space in headings across the rest of the security pages: https://ela.st/mockups
|
andrew-goldstein
added a commit
to andrew-goldstein/kibana
that referenced
this issue
Jul 12, 2022
…ity-team#3221) to the Alerts page:  _Above: The new `Alerts by risk score` treemap_ - Alerts are colored by risk score - Clicking on a cell instantly filters the alerts page - Users may specify custom fields to group by, or quick-select from our curated sets of fields that pair well together The features in this PR are enabled via the following feature flag in [experimental_features.ts](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/common/experimental_features.ts): ```ts alertsTreemapEnabled: true, ``` When the feature flag is **disabled**, the alerts page looks like `main` today:  _Above: This branch, when the feature flag is disabled_ When the feature flag is enabled, the layout of the Alerts page incorporates the design detailed in <elastic#120287>, which eliminates unusable space at the top of the Alerts page, and enables users to quickly hide and show the charts. Users are introduced to the new `Hide charts` feature of the layout via `Step 1` of an [EUI Tour](https://elastic.github.io/eui/#/display/tour):  _Above: `Step 1` of the tour introduces the `Hide charts` feature_ Users may (optionally) try the `Hide charts` feature as part of the tour, per the video below: <https://user-images.githubusercontent.com/4459398/156709026-ac16c97b-167e-4fce-b0e0-fd16077027b1.mov> _Above: (video) The interactive tour let's users experience the new `Hide charts` feature_ `Step 2`, the final step of the tour, introduces the view selector:  _Above: `Step 2` of the tour introduces the view selector_ Per the screenshot and video below, view selection toggles between the default `Trend view` and the new `Alerts by risk score view`:  _Above: View selection_ <https://user-images.githubusercontent.com/4459398/156710378-3b9461c1-9779-4d66-8f12-21709d6f25fc.mov> _Above: (video) View selection toggles between the `Trend view` and the `Alerts by risk score view`_ We store the user's chart visibility and view preferences in local storage. When users navigate to other views in Kibana or close the browser, their chart visibility and view preferences are restored the next time they visit the Alerts page. Every rule, including prebuilt Elastic rules and custom rules created by users, must specify a risk score at rule creation time, per the screenshot below:  _Above: Every rule has a risk score specified when it's created_ The colors of the alerts displayed in the treemap are determined by the rule's risk score. This makes it easy to quickly filter the entire alerts page by clicking on the riskiest alerts, per the video below: <https://user-images.githubusercontent.com/4459398/156714075-75112515-a247-4aa4-bc58-52fd17ce6fa0.mov> _Above: (video) Users click on the riskiest alerts to filter the page_ Clicking on a cell in the treemap adds two filters, one for each group by field:  _Above: Two filters, (one for each group by field), are added to the page when a cell is clicked_ In the screenshot below, the 2nd filter was removed to reveal all the hosts in `mimikatz process started` alerts:  _Above: Removing the 2nd filter, `host.name`, revealed all the hosts in the `mimikatz process started` alerts_ We can instantly answer questions like "Did this host trigger alerts for other rules?", and at a glance, grok the severity of those alerts, by removing the first of the two filters:  _Above: Removing the first filter, `kibana.alert.rule.name`, revealed other alerts (from different rules) triggered for a specific host_ Users may customize the group by criteria: <https://user-images.githubusercontent.com/4459398/156720911-8ed26b24-658f-4cc3-85b2-f317e15c430c.mov> _Above: (video) Entering custom group by criteria_ When users navigate to other views in Kibana or close the browser, the previously-selected group by fields are restored from local storage the next time they visit the Alerts page. Clicking on the first menu item in the settings gear, `Reset group by fields`, restores the default group by fields, per the video below: <https://user-images.githubusercontent.com/4459398/156722389-2927d4e4-f8e8-4113-88d7-274a7c1e4bbe.mov> _Above: (video) Restoring the default group by fields_ Users may quick-select from Elastic-curated sets of fields that pair well together, like parent and child processes, or process and file name:  _Above: Quick-select from Elastic-curated sets of fiels_ Previous versions of the `Count` table were limited to grouping by one field. This PR enhances it to support grouping by two fields, per the screenshot below:  _Above: The `Count` table now supports two group by fields_ The group by criteria of the `Count` and `Alerts by risk score` widgets are linked together, making it easy to toggle between the two views, per the video below: <https://user-images.githubusercontent.com/4459398/156727296-59fc1f29-e7a2-45eb-a549-5317100ab68a.mov> _Above: (video) The `Count` and `Alerts by risk score` group by criteria are linked_ The `Trend` chart's legend has been enhanced to display counts, per the design detailed in issue <elastic#120282>  _Above: The `Trend` chart legend, enhanced to display counts_ Note: The original intention of adding counts to the `Trend` chart legend, as documented in <elastic#120282>, was to combine the `Trend` and `Count` widgets into a single view via the legend. In this PR, the `Trend` and `Count` widget queries have diverged; (the latter now supports multiple group by fields). This prevents the `Trend` and `Count` widgets from being combined into a single view. This PR adds persistence of the `Trend` chart Stack by field to local storage. When users navigate to other views in Kibana or close the browser, the previously-selected field is restored the next time they visit the Alerts page.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is likely a larger conversation that needs to happen in the @elastic/security-design team, but we're losing a lot of space to titling and extra padding. It's most felt in the Alerts section of the application. Similar to Discover, I would focus on the essential actions, leaving the IA to the breadcrumbs and navigation.
The text was updated successfully, but these errors were encountered: