Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Uptime] Move uptime actions to Header Actions Menu #100298

Conversation

justinkambic
Copy link
Contributor

@justinkambic justinkambic commented May 18, 2021

Summary

Resolves #89556.

Moves the header actions from the uptime app content into the stacked actions header provided by Kibana.

Before

image

After

May-20-2021 13-35-19

Author checklist

  • Accessibility has been considered, relevant aria tags and other accessibility features implemented
  • Telemetry has been added where relevant
  • Docs have been added to this PR covering any new, changed, or removed features
    I did make changes to the app that make the Overview page image out of date in the docs. Should I create a replacement image?
  • Testing for expected behavior is in place
    • Automated tests exist to cover expected and edge case conditions
    • User acceptance testing has been carried out to ensure the feature functions as expected within the context of how it will be used
    • [ ] Any special/edge cases that need to be manually tested must be documented
    • Ensure the new layout works responsively (including down to small phone widths, where makes sense for the user flow, e.g. the error page when reacting to an alert)

Reviewer checklist

  • Accessibility has been considered, relevant aria tags and other accessibility features implemented
  • Telemetry has been added where relevant
  • Docs have been added to this PR covering any new, changed, or removed features
  • Testing for expected behavior is in place
    • Automated tests exist to cover expected and edge case conditions
    • User acceptance testing has been carried out to ensure the feature functions as expected within the context of how it will be used
    • Any special/edge cases that need to be manually tested must be documented
    • Ensure the new layout works responsively (including down to small phone widths, where makes sense for the user flow, e.g. the error page when reacting to an alert)

@justinkambic justinkambic self-assigned this May 18, 2021
@justinkambic justinkambic added release_note:enhancement Team:Uptime - DEPRECATED Synthetics & RUM sub-team of Application Observability v7.14.0 v8.0.0 auto-backport Deprecated - use backport:version if exact versions are needed labels May 18, 2021
@justinkambic justinkambic force-pushed the 89556/move-header-actions-to-HeaderActionsMenu branch from 6f53c56 to 54d981b Compare May 19, 2021 19:23
@justinkambic justinkambic force-pushed the 89556/move-header-actions-to-HeaderActionsMenu branch from 54d981b to c6f4e54 Compare May 20, 2021 17:36
@justinkambic justinkambic marked this pull request as ready for review May 20, 2021 17:42
@justinkambic justinkambic requested a review from a team as a code owner May 20, 2021 17:42
@elasticmachine
Copy link
Contributor

Pinging @elastic/uptime (Team:uptime)

};
export const ActionMenu = ({ appMountParameters }: { appMountParameters: AppMountParameters }) => (
<HeaderMenuPortal setHeaderActionMenu={appMountParameters.setHeaderActionMenu}>
<ActionMenuContent />
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There weren't any test for these button controls, so I added some while I was in here. I extracted this content to a new component because we don't have much interest in testing the HeaderMenuPortal API.

@justinkambic
Copy link
Contributor Author

@elasticmachine merge upstream

Copy link
Contributor

@dominiqueclarke dominiqueclarke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great!
One thing I noticed, is that each one of the header options is wrapped in a button, but the actual action is nested inside and may be either a button or a link. This is causing some keyboard navigation and screenreader issues, as each option can be tabbed to twice.

imageWhen a button is nested inside a button, the first tab will read out the content, but when you attempt to use the keyboard for clicking it does nothing, since the wrapper button doesn't contain an onclick. Then on the second tab it rereads the content, and at that time you can use the keyboard to click the button.

For the Settings and Analyze data links however, the experience is even more difficult. The first tab once again reads the button content, but i clicking does nothing due to a lack of an onclick handler. Then once you tab again, you land on the link which is read out, but the button content and instructions for clicking the button are again read. However, since this is a link, the instructions for how to actually "press" the link are incorrect, and following the screenreader instructions will result in nothing happening. Instead, you have to press the enter key to access the link.

We may need to revisit wrapping each of these options in an empty button, and instead unnest the elements that contain the actual behavior and use some other component to maintain style consistency.

<EuiToolTip position="top" content={<p>{ANALYZE_MESSAGE}</p>}>
<EuiButtonEmpty
aria-label={i18n.translate('xpack.uptime.page_header.exploratoryLink.label', {
defaultMessage: 'Navigate to the exploratory view to visualize data',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the user facing name is current 'Analyze Data'.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had another pass at this, how is this looking? 1c9d3e7

@justinkambic
Copy link
Contributor Author

I've addressed the smaller items; working on the nested button issue now.

it('renders settings link', () => {
const { getByRole, getByText } = render(<ActionMenuContent />);

const settingsAnchor = getByRole('link', { name: 'Navigate to the Uptime settings page' });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i usually avoid getByRole they tends to be slow.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was added as a response to feedback.

})}
iconType="gear"
>
<FormattedMessage id="xpack.uptime.page_header.settingsLink" defaultMessage="Settings" />
Copy link
Contributor

@shahzad31 shahzad31 May 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@justinkambic @formgeist have we decided on the order of buttons? in APM settings comes before Alerts. Here alerts is before Settings, we should use same order for same kind of buttons.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shahzad31 @justinkambic The correct order is described in the latest issue that relates to the menu options #99902

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was following the screenshot in the issue. I prefer to not have settings be the first thing in the list because I tend to not think of Settings as the most important item in nav menus, but I agree we need to have uniformity here.

@formgeist should we follow the ordering of APM for this change, and then create a new issue to switch the buttons across Observability apps? Alternatively we can just keep settings in the front.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just pushed 452d11f which switches the settings and alerts options.

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@formgeist should we follow the ordering of APM for this change, and then create a new issue to switch the buttons across Observability apps? Alternatively we can just keep settings in the front.

We have separate issues that address this for the other Observability apps.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@formgeist so you want me to revert the change and have Alerts before Settings?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@justinkambic Sorry, I didn't make that clear. Settings will go in front of alerts like the design suggested.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, sounds like it's configured the way we want then.

@justinkambic
Copy link
Contributor Author

One thing I noticed, is that each one of the header options is wrapped in a button, but the actual action is nested inside and may be either a button or a link.

This was a great find and it's caused by a misuse of the API for EuiHeader. I've updated it to use EuiHeaderSectionItem, which wraps EuiHeaderLinks children but seems to not render a button/link around the child content. I was able to tab through each item and navigate with the keyboard.

@justinkambic
Copy link
Contributor Author

Thanks all for feedback, I think it's all been addressed so far.

Copy link
Contributor

@shahzad31 shahzad31 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My feedback is addressed !!

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
uptime 612 613 +1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
uptime 1.1MB 1.1MB +978.0B
Unknown metric groups

References to deprecated APIs

id before after diff
canvas 29 25 -4
crossClusterReplication 8 6 -2
fleet 22 20 -2
globalSearch 4 2 -2
indexManagement 12 7 -5
infra 261 149 -112
lens 67 45 -22
licensing 18 15 -3
lists 239 236 -3
maps 286 208 -78
ml 121 115 -6
monitoring 109 56 -53
securitySolution 386 342 -44
stackAlerts 101 95 -6
total -342

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @justinkambic

Copy link
Contributor

@dominiqueclarke dominiqueclarke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I created #100725 as I noticed some potential focus issues related to this but broader than this PR.

@justinkambic justinkambic merged commit b189d05 into elastic:master May 26, 2021
@justinkambic justinkambic deleted the 89556/move-header-actions-to-HeaderActionsMenu branch May 26, 2021 19:31
kibanamachine added a commit to kibanamachine/kibana that referenced this pull request May 26, 2021
* Move uptime actions to Kibana's HeaderActionsMenu.

* Delete a comment.

* Extract ActionMenu content to dedicated component to make testing easier.

* Add tests.

* Use `EuiHeaderLinks` instead of `EuiFlexItem`.

* Clean up tests.

* Prefer `getByRole` for a test.

* Fix copy mistake.

* Fix a test broken by the previous commit.

* Prefer `EuiHeaderSectionItem` over `EuiHeaderSectionLink` to avoid nesting `button`s within `buttons`.

* Reverse "Settings" and "Alerts" menu options to make them uniform with APM.

Co-authored-by: Kibana Machine <[email protected]>
@kibanamachine
Copy link
Contributor

💚 Backport successful

Status Branch Result
7.x

This backport PR will be merged automatically after passing CI.

kibanamachine added a commit that referenced this pull request May 26, 2021
* Move uptime actions to Kibana's HeaderActionsMenu.

* Delete a comment.

* Extract ActionMenu content to dedicated component to make testing easier.

* Add tests.

* Use `EuiHeaderLinks` instead of `EuiFlexItem`.

* Clean up tests.

* Prefer `getByRole` for a test.

* Fix copy mistake.

* Fix a test broken by the previous commit.

* Prefer `EuiHeaderSectionItem` over `EuiHeaderSectionLink` to avoid nesting `button`s within `buttons`.

* Reverse "Settings" and "Alerts" menu options to make them uniform with APM.

Co-authored-by: Kibana Machine <[email protected]>

Co-authored-by: Justin Kambic <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-backport Deprecated - use backport:version if exact versions are needed release_note:enhancement Team:Uptime - DEPRECATED Synthetics & RUM sub-team of Application Observability v7.14.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Uptime] Move header actions to the new HeaderActionsMenu in Kibana
6 participants