[Upgrade Assistant] Improve loading/error states for deprecation toggle

[alisonelizabeth]

This PR improves the loading and error states for the deprecation toggle on the Overview page in Upgrade Assistant.

Fixes #73211

Skipping release note since UA will be disabled in 7.13.

To test, you will need to enable UA by setting UA_READONLY_MODE in common/constants.ts to false. You can more easily view the spinner by enabling network throttling in your browser's dev tools.

Expected behavior:

• When fetching the current logging state, a loading icon will appear. The switch will not display.

• If there is a fetch error, a callout will display with a reload button. The switch will not display.

• When updating the logging state, a loading icon will appear. The switch will not display.

• If there is an error updating the loading state, a callout will appear. The switch will remain, with the previous (not updated) value.

[alisonelizabeth]

@elasticmachine merge upstream

[elasticmachine]

Pinging @elastic/es-ui (Team:Elasticsearch UI)

[cjcenizal]

Nice UX enhancement! Took a quick look at the screenshots and had a couple thoughts on ways to provide the user with a bit more info.

[cjcenizal]

How about adding a description with some error details, like status code and message?

[cjcenizal]

Can we add some more information so the user understands why they'd want to bother reloading? For example, we could change the button text to "Reload to configure deprecation logging".

[yuliacech]

Great improvements to the UI, @alisonelizabeth!
I think loading state and loading error both look good, but I'm curious if there is a pattern for updating state of a switch. I was trying to find anything similar in Kibana or EUI but saw nothing. I'm mostly concerned about the content jump in both updating and updating error states. I'm thinking if moving updating error below the input would work? And for the updating state: not replacing the switch but rather disabling it and adding the loading indicator with 'Updating logging state...' below the input. WDYT?

[alisonelizabeth]

Thanks for the feedback @cjcenizal and @yuliacech! I will follow up with design and report back. I'm also going to move this from 7.13 to 7.14 since it's not necessary to get in for the next release and tomorrow is FF.

[alisonelizabeth]

I think loading state and loading error both look good, but I'm curious if there is a pattern for updating state of a switch. I was trying to find anything similar in Kibana or EUI but saw nothing. I'm mostly concerned about the content jump in both updating and updating error states.

@mdefazio / @dborodyansky do you have thoughts on this? For loading and error states, should the toggle remain visible but disabled? The one problem I foresee is it might be confusing since there would also be a value associated with it (on/off) even though it is disabled.

[dborodyansky]

Circling back from offline conversation with @mdefazio and @alisonelizabeth.

Disabling a switch due to error does seem problematic since selection (on/off) remains visible. Replacing an entire switch with a loading indicator is also uncommon. Propose using a toggle-button instead of a switch as it affords an expected loading state. A button can also display a disabled (unavailable) label state to better support errors.

Also suggesting we consider reintroducing some informational cues to help users gain more context around deprecation logging. Framing the control with a title, explanation, and a status badge could reinforce context and comprehension.

UI flow:

Display states:

Loading button label would ideally be conditional, depending on trigger (retrieve state, enable, disable).

Alternate consideration: If callout feels too heavy for this case, could error-text provide more subtle display?

High fidelity mockups and alternate iteration deferring to use of switch in this Figma file.

Thoughts, corrections, and feedback very welcome.

[alisonelizabeth]

Great work @dborodyansky! I really like the idea of using the toggle button here.

I had a couple other questions come to mind after looking these over again with CJ.

• Do you foresee any issues that the user has to potentially look at two separate areas for state (the badge and button label)?
• Also, can you verify with Michael/design if it's OK to have the callout inline with the button? I don't have any particular concerns about it, but I think it is a little uncommon. I've typically seen it presented above.

[dborodyansky]

Thank you for bearing with me as I get up to speed on EUI and Kibana patterns. I checked in with design group and indeed the Callout is expected to be full width, which I think may be excessive in this case. Error text seems would be more appropriate inline. A badge to show unavailability may also be unnecessary since we label the button and provide error information.

Separation of the state indicator from the control is great feedback, and a tension I fell as well. An alternative CJ brought up is displaying the state in the button label and icon. However what seems to get lost is an explicit call-to-action affordance, outside of a changing the label in a hover state. Feels like there is a thread here to keep pulling though, and would be interested if it spurs additional feedback.

I am updating the Figma file to keep track of alternate explorations and trade offs as we iterate.

I'd love to zoom out a bit to consider the overall (Upgrade Assistant / Deprecation) UX comprehensively in order to iterate further as we progress the project. Would that be ok?

[alisonelizabeth]

Thanks for the update, @dborodyansky!

However what seems to get lost is an explicit call-to-action affordance

I agree. How important do you feel it is to explicitly call out the state? I'm wondering if it's sufficient for now to not use a badge, and also keep the button text to Enable/Disable.

Feels like there is a thread here to keep pulling though, and would be interested if it spurs additional feedback.

I'd love to zoom out a bit to consider the overall (Upgrade Assistant / Deprecation) UX comprehensively in order to iterate further as we progress the project. Would that be ok?

I agree there's probably more here we can continue to discuss. However, I think overall your changes provide an improved experience than what we had previously and is enough to move forward.

The way deprecation logging is presented in UA will likely become more sophisticated as we continue iterating on this project, so I don't think it's worth spending too much more time on the toggle button specifically until we flesh out more details around the overall vision. I'd like to spend some time thinking through this myself and collecting more information from a technical standpoint. I'll plan to schedule a meeting with you after this - probably not for another week or so until I'll be ready.

[dborodyansky]

I'm wondering if it's sufficient for now to not use a badge, and also keep the button text to Enable/Disable.

The way deprecation logging is presented in UA will likely become more sophisticated as we continue iterating on this project, so I don't think it's worth spending too much more time on the toggle button specifically until we flesh out more details around the overall vision.

I agree. Sufficient for this PR, and plan to work on enhancing design comprehensively as we gather more information around deprecation logging and the overall vision.

[alisonelizabeth]

Thanks again @dborodyansky for the help on this! I've implemented your suggestions. One thing I still have a question on is the inline error message. I did not yet add specifics from the error message itself, as I worry we don't have control over this content and it could become more than one line. A couple thoughts I had: (1) remove the static copy and only show the error message received from the response, (2) show the static copy with the error status code, or (3) make the error message full width either above or below the button. Let me know what you think! /cc @debadair if you have any thoughts here too.

Updated screenshots:

// Logging not enabled

// Logging enabled

// Error fetching logging information

// Error updating logging: Button stays enabled with the state unchanged. A user can "try again" by clicking the button, no need for a "try again" link.

@yuliacech Would you mind taking another look when you get a chance?

[dborodyansky]

@alisonelizabeth, Option 3 does not compromise providing useful information, so I believe that would be preferred.

[alisonelizabeth]

@elasticmachine merge upstream

[alisonelizabeth]

@elasticmachine merge upstream

[yuliacech]

The new button looks great, @alisonelizabeth and @dborodyansky!
I tested all loading and error states and the button and error messages are all very clear.
Just one question, @alisonelizabeth, was the copy already reviewed?
For me it took just an extra time to understand want the current state of the logging was here

As soon as the logging information is loaded, would it be useful to add the state to the text? For example, 'Deprecation logging is enabled, disable to not log ...' and the button will have 'disable' label. The reverse for the 'disabled' state. WDYT?

[alisonelizabeth]

Thanks for the feedback @yuliacech!

For me it took just an extra time to understand want the current state of the logging was here

We've had some back-and-forth around this. The original design was to also have a badge in the title to indicate the status. CJ also suggested having an indicator in the button label itself along with updating the button label text. Both of these have tradeoffs - adding the badge means a user has to potentially look at 2 different places for state (the badge in the title, and the button label); and changing the button label copy makes it less clear the button is actionable. We concluded to leave as-is, since we plan to iterate on how deprecation logging is presented in UA.

As soon as the logging information is loaded, would it be useful to add the state to the text? For example, 'Deprecation logging is enabled, disable to not log ...' and the button will have 'disable' label. The reverse for the 'disabled' state. WDYT?

Can you clarify what you mean by "...would it be useful to add the state to the text?" Are you suggesting this be next to the button, or as part of the description under the section title (or something else)?

[yuliacech]

I see @alisonelizabeth, that's a tricky one ;) So what I meant is the text under the title, could we consider it for an explicit state description?
Currently the actual state is only described implicitly, it's derived from the button being active for disabling, so it must be enabled, right?
So I would change the text under the title to 'Deprecation logging is enabled. Disable deprecation logging if you don't want to collect information about deprecations etc ...' or 'Deprecation logging is disabled. Enable deprecation logging if you want etc ...' and leave the button as is currently (i.e describing the action of changing the state 'Disable/Enable')

[dborodyansky]

@yuliacech Does this represent what you are describing? I think it does help add useful context, though would require a bit more conditional copy to handle the "unknown/unavailable" state as well.

[alisonelizabeth]

I almost think if we were to add dynamic text, I'd prefer to go back to the badge option. As @dborodyansky pointed out, it would require more complexity to handle the unavailable/loading states.

I'd also like to iterate that the UX around deprecation logging in Upgrade Assistant is going to change. In retrospect, I probably should have held off on opening this PR. To move forward, I'd like to propose one of the following:

1. Close this PR and incorporate the feedback here as part of the design enhancements planned for deprecation logging
2. If we think that this PR provides some interim value, leave as-is and merge (pending code review), with the acknowledgement there are some shortcomings that will be addressed in future work.

I tend to lean toward 2, but open to either. @yuliacech let me know what you think!

[yuliacech]

@dborodyansky Yes, those look great, Dmitry! I agree that it's not straightforward how to handle the loading/error state though.
@alisonelizabeth Thanks a lot for considering my comments! I'm good with merging this PR and leaving the copy/text work for a future PR 👍

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: f39c1ce
• Storybooks Preview

Metrics [docs]

Async chunks

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

id	before	after	diff
upgradeAssistant	146.4KB	150.4KB	+4.1KB

History

• 💚 Build #122868 succeeded 54186a8
• 💔 Build #122687 failed 971004e
• 💔 Build #122567 failed 596de0e
• 💔 Build #122496 failed 5ce3ae0
• 💚 Build #120406 succeeded 5808cb9

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