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

[Upgrade Assistant] Update UX for 7.17 #119798

Merged
merged 9 commits into from
Nov 30, 2021

Conversation

sabarasaba
Copy link
Member

@sabarasaba sabarasaba commented Nov 29, 2021

Fixes #119738

Summary

Given that we'll have another minor update before the next major, we need to tweak the UX of Upgrade Assistant to give the right message to our users. In order to achieve that, there is a few changes we'll have to do to the copy of the page to make it clearer that this is a preparation for the next major version:

  • Change the copy in the header, step 3(Review deprecated settings) and step 4(get ready for upgrade)
  • Change the copy in ES deprecation issue/logs and kibana deprecations
  • Change the URL link for "What's new in 8.x" (which now points to what's new in 7.16)

Also, a few UI elements were hidden from the UI:

  • Remove step 2(upgrade system indices) from the wizard
  • Remove both CTA (Cloud and on prem) in Step 4(get ready for upgrade)

About system indices migration

Initially the Upgrade Assistant in 7.16 was designed specifically for upgrading to the next major. But with the addition of the 7.17 release, we decided to only leave the necessary tools to the user to assist him with the upcoming minor upgrade. We then ended up removing the system indices migration from the UI since it was designed to assist users into major upgrades and not minors in an effort to align it more with some of the thoughts explained with #117220.

With these changes we expect users to upgrade to 7.17 before actually migrating to the next major, as we always guide them to do. Note that I removed the entry point for system indices management from the code and skipped the tests, the code wont get into the bundle since its not required anywhere.

Screenshots

Overview of changes

Screenshot 2021-11-30 at 09 14 58
Screenshot 2021-11-30 at 09 14 53
Screenshot 2021-11-30 at 09 14 47
Screenshot 2021-11-30 at 09 14 40

@sabarasaba sabarasaba self-assigned this Nov 29, 2021
@sabarasaba sabarasaba added enhancement New value added to drive a business result Feature:Upgrade Assistant release_note:skip Skip the PR/issue when compiling release notes Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more v7.16.1 labels Nov 29, 2021
@sabarasaba sabarasaba marked this pull request as ready for review November 29, 2021 10:52
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-stack-management (Team:Stack Management)

Copy link
Contributor

@sebelga sebelga 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 tested locally and works as expected.
I left a few note around using "to prepare for the upgrade" (which is the terminology our docs use).

src/core/public/doc_links/doc_links_service.ts Outdated Show resolved Hide resolved
@@ -38,7 +38,7 @@ const i18nTexts = {
apiCompatibilityNoteBody: (docLink: string) => (
<FormattedMessage
id="xpack.upgradeAssistant.overview.apiCompatibilityNoteBody"
defaultMessage="We recommend you resolve all deprecation issues before upgrading. If needed, you can apply API compatibility headers to requests that use deprecated features. {learnMoreLink}."
defaultMessage="You can start resolving deprecation issues before upgrading to the next major version of Elastic. If needed, you can apply API compatibility headers to requests that use deprecated features. {learnMoreLink}."
Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think of:

"You can start resolving deprecation issues to prepare the upgrade to the next major..."

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should leave this largely as is and just append "to the next major version of Elastic." We're trying to present the API compatibility headers as a less preferred safety mechanism. It doesn't really work without "We recommend..."

Suggested change
defaultMessage="You can start resolving deprecation issues before upgrading to the next major version of Elastic. If needed, you can apply API compatibility headers to requests that use deprecated features. {learnMoreLink}."
defaultMessage="We recommend you resolve all deprecation issues before upgrading to the next major version of Elastic. If needed, you can apply API compatibility headers to requests that use deprecated features. {learnMoreLink}."

Screen Shot 2021-11-29 at 10 12 17 AM

@@ -30,7 +30,8 @@ const i18nTexts = {
defaultMessage: 'Kibana deprecation issues',
}),
pageDescription: i18n.translate('xpack.upgradeAssistant.kibanaDeprecations.pageDescription', {
defaultMessage: 'Resolve all critical issues before upgrading.',
defaultMessage:
'Resolve all critical issues before upgrading to the next major version of Elastic.',
Copy link
Contributor

Choose a reason for hiding this comment

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

Again, but let's see what @debadair thinks, I'd put "to prepare the upgrade to"

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think "to prepare" is necessary. I think it's understood that you're preparing to upgrade.

@sabarasaba
Copy link
Member Author

Thanks for having a look @sebelga! I've addressed your feedback about the tests and docs link. I'll defer on the copy changes to the docs team 🚀

@sabarasaba
Copy link
Member Author

@elasticmachine merge upstream

Copy link
Contributor

@jrodewig jrodewig left a comment

Choose a reason for hiding this comment

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

Thanks for making these changes @sabarasaba. I noted some grammatical issues with a few bits of the copy. I also don't think we should go overboard with "to prepare," etc. here as long as it's clear that the steps are related to a major version upgrade.

My only large piece of feedback is related to step 3. I think we should update this step to advise users to come back to the page when they're ready to upgrade to 8.x. The current wording is kind of circular.

src/core/public/doc_links/doc_links_service.ts Outdated Show resolved Hide resolved
@@ -38,7 +38,7 @@ const i18nTexts = {
apiCompatibilityNoteBody: (docLink: string) => (
<FormattedMessage
id="xpack.upgradeAssistant.overview.apiCompatibilityNoteBody"
defaultMessage="We recommend you resolve all deprecation issues before upgrading. If needed, you can apply API compatibility headers to requests that use deprecated features. {learnMoreLink}."
defaultMessage="You can start resolving deprecation issues before upgrading to the next major version of Elastic. If needed, you can apply API compatibility headers to requests that use deprecated features. {learnMoreLink}."
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should leave this largely as is and just append "to the next major version of Elastic." We're trying to present the API compatibility headers as a less preferred safety mechanism. It doesn't really work without "We recommend..."

Suggested change
defaultMessage="You can start resolving deprecation issues before upgrading to the next major version of Elastic. If needed, you can apply API compatibility headers to requests that use deprecated features. {learnMoreLink}."
defaultMessage="We recommend you resolve all deprecation issues before upgrading to the next major version of Elastic. If needed, you can apply API compatibility headers to requests that use deprecated features. {learnMoreLink}."

Screen Shot 2021-11-29 at 10 12 17 AM

@@ -30,7 +30,8 @@ const i18nTexts = {
defaultMessage: 'Kibana deprecation issues',
}),
pageDescription: i18n.translate('xpack.upgradeAssistant.kibanaDeprecations.pageDescription', {
defaultMessage: 'Resolve all critical issues before upgrading.',
defaultMessage:
'Resolve all critical issues before upgrading to the next major version of Elastic.',
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think "to prepare" is necessary. I think it's understood that you're preparing to upgrade.

@sebelga
Copy link
Contributor

sebelga commented Nov 29, 2021

@sabarasaba I think this is going to 7.16.0 (for the label you put). @cjcenizal can you confirm?

@cjcenizal
Copy link
Contributor

@sebelga Correct, AFAIK we want this to ship with 7.16.0.

Copy link
Contributor

@cjcenizal cjcenizal left a comment

Choose a reason for hiding this comment

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

💥 These changes LGTM. My only concerns are addressed by James's suggestions. Thanks for the fast turnaround on this! We will cut a new BC on Thursday, so let's aim to merge this by Wednesday, 5PM Pacific.

@sabarasaba sabarasaba removed the request for review from debadair November 30, 2021 08:16
@sabarasaba
Copy link
Member Author

Thanks for having a look @jrodewig! I've addressed your feedback with 1b221d3 and also updated the screenshots from the PR description.

Copy link
Contributor

@jrodewig jrodewig left a comment

Choose a reason for hiding this comment

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

I didn't test locally, but this LGTM based on the screenshots and code. There was one suggestion that may have been overlooked, but it's not blocking either way: #119798 (comment)

Thanks for the fast work on this @sabarasaba! 🚀

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
upgradeAssistant 145 140 -5

Async chunks

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

id before after diff
upgradeAssistant 138.6KB 127.9KB -10.7KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
core 308.2KB 308.3KB +89.0B
upgradeAssistant 18.3KB 18.2KB -41.0B
total +48.0B

History

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

cc @sabarasaba

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New value added to drive a business result Feature:Upgrade Assistant release_note:skip Skip the PR/issue when compiling release notes Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more v7.16.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants