Add details to restore progress screen

[monsieur-z]

Changes proposed in this Pull Request

This PR adds more details to the restore progress screen, so that users have a better understanding of what's happening in real-time. See captures below.

Implementation notes

• @elliottprogrammer did the initial worked in Get In Progress Rewind API Entry Details #47071. I rebased the branch and updated the UI accordingly.
• The API doesn't return the type of the entry, so I needed to adjust the copy a little bit (Currently restoring: [entry]).

Note: the back-end returns Unknown for the entry while it's being finalized. This should never be the case once done.

Testing instructions

• Apply this patch D52234-code to your wpcom sandbox and point public-api.wordpress.com to it
• Run this PR in Calypso or Jetpack cloud
• Select a self-hosted Jetpack site that has a Backup product, and more than one backup
• Make sure you have set server credentials to enable restores
• Visit the Backup section, select a backup to restore, and click Restore to this point, the Confirm restore
• Check that you see the message and current entry returned by the API, respectively above and below the progress bar

Screenshots

Mockups

Before

After

Implementation

[matticbot]

Test live: https://calypso.live/?branch=improve/restore-progress-status

[monsieur-z]

@keoshi, as soon as the restore starts, we're seeing no message or entry for a couple of seconds (see capture below). How do you feel about this? Do we need to implement a loading state?

[keoshi]

@monsieur-z Thanks for the heads-up on this, Kev! Could we add some placeholders while the text isn't populated with real information? What about these two snippets, one for the top and one the for bottom portions:

Starting up the restore process

Loading...

I don't love the Loading... one, but can't think of anything else at the moment.

[ChaosExAnima]

I don't love the Loading... one, but can't think of anything else at the moment.

Maybe Initializing...? I've swear I've seen that on VP.

[keoshi]

Both sound more “tech-y” than I'd like, but yeah, Initializing... is a bit better than Loading....

[ChaosExAnima]

Maybe Starting then? At this point I'm just looking at a thesaurus 😆

[keoshi]

@ChaosExAnima Haha! I like Starting... better. Even if it duplicates the above, it's visible just for a couple of seconds as @monsieur-z mentioned, so I'd vote for that one.

[elliottprogrammer]

@keoshi , @ChaosExAnima , @monsieur-z ,

One thing to note here to go with your discussion above. The rewind API will be returning 2 separate fields: They are message and current_entry.

• message appears to be returning a string describing the action (or step in the backup process) taking place. It returns values such as, Starting, Parsing Manifest, Streaming files, Importing SQL dump, and Renaming tables.
• current_entry, I believe, will return the actual item being processed such as the actual filename (including path) or table name and or maybe others.

In this implementation, and in the Figma mockups we're not utilizing the message field. This brings me to ask, do we want to consider changing slightly what we are displaying during the backup process by utilizing the values returned in the message field also? Maybe something like, "Current action: Starting...", then "Currently restoring: [current_entry]". I just wanted to bring this to light and something to think about, anyway. 🙂

[elliottprogrammer]

Looks good! Looking forward to seeing it once the api is returning the right entry values (verses "Unknown"). Works as expected so far, code looks good!
LGTM! 👍

[monsieur-z]

In this implementation, and in the Figma mockups we're not utilizing the message field.

We display message just above the progress bar, @elliottprogrammer.

[elliottprogrammer]

We display message just above the progress bar, @elliottprogrammer.

Oh!! Oops! My bad.. 🤦 I didn't notice that! Disregard my previous comment then. 😂

[monsieur-z]

I integrated the loading state according to your proposition but then realized we used Starting a lot :) I tweaked a couple of things and here's a filmstrip of what it looks like (Unknown will be replaced by the entry).

API doesn't return any data just yet

Ok, here it goes

Some more details

Even more details, though we've reached 100% already

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~430 bytes added 📈 [gzipped])

name                    parsed_size           gzip_size
backup                       +832 B  (+0.2%)     +214 B  (+0.2%)
stats                         +79 B  (+0.0%)      +26 B  (+0.0%)
settings-security             +79 B  (+0.0%)      +26 B  (+0.0%)
settings-jetpack              +79 B  (+0.0%)      +26 B  (+0.0%)
settings                      +79 B  (+0.0%)      +28 B  (+0.0%)
scan                          +79 B  (+0.0%)      +26 B  (+0.0%)
plans                         +79 B  (+0.0%)      +30 B  (+0.0%)
jetpack-cloud-settings        +79 B  (+0.0%)      +26 B  (+0.0%)
activity                      +79 B  (+0.0%)      +28 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~221 bytes added 📈 [gzipped])

name                                       parsed_size           gzip_size
async-load-signup-steps-rewind-migrate           +79 B  (+0.3%)      +28 B  (+0.4%)
async-load-signup-steps-rewind-form-creds        +79 B  (+0.2%)      +26 B  (+0.2%)
async-load-signup-steps-creds-permission         +79 B  (+0.3%)      +24 B  (+0.3%)
async-load-signup-steps-creds-confirm            +79 B  (+0.3%)      +25 B  (+0.3%)
async-load-signup-steps-clone-ready              +79 B  (+0.3%)      +28 B  (+0.4%)
async-load-signup-steps-clone-point              +79 B  (+0.0%)      +28 B  (+0.1%)
async-load-signup-steps-clone-credentials        +79 B  (+0.1%)      +26 B  (+0.2%)
async-load-calypso-my-sites-sidebar              +79 B  (+0.1%)      +36 B  (+0.1%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[elliottprogrammer]

Love it!! I think it's a great improvement @monsieur-z! 👍 @keoshi , what do you think?

[keoshi]

That looks pretty dang cool! Thanks for making those adjustments @monsieur-z — ship it.

[rcanepa]

Awesome work folks. It looks really really nice!

[a8ci18n]

This Pull Request is now available for translation here: https://translate.wordpress.com/deliverables/5127361

Thank you @monsieur-z for including a screenshot in the description! This is really helpful for our translators.

[a8ci18n]

Translation for this Pull Request has now been finished.