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

Importers: Move action buttons to the bottom of each screen #31364

Merged

Conversation

spen
Copy link
Contributor

@spen spen commented Mar 11, 2019

This PR addresses issues with buttons in both the importers that expect the user to upload a file and the ones that expect them to input a URL, namely:

  • Inconsistencies in button positioning.
  • Unclear button text.
  • Clashing button colours.

At the moment, buttons appear in different places in the importer pane, depending on the type of importer and stage of the import. @dezzie's Issues #31092 and #30564 propose a more consistent placement of all buttons in the bottom left corner of the importer pane. They also recommend some small changes to button text, and suggest removing the "scary" style from some buttons whose colour seems to clash with the magenta of the new Muriel primary style buttons.

Testing

Run through the whole importing flow with both a Wix import and a file-based import (WordPress).
Try cancelling at various points in the flow - does the button do what you expected in each place? Does the copy best represent the action?
Take the the flows through to completion - did the loading states look right? Did you get stuck at any point?

Note

The approach used here isn't perfect - because of limitations around state and certain actions being baked in to components (rather than abstracted in to the state layer) I've had to place the ActionButtons wherever they have access to to the actions they need to trigger: In the AuthorMappingPane, SiteImporterInputPane , SiteImporterSitePreview , ImportingPane and UploadingPane components.
The alternative would be to properly move out various pieces of state and state-changing actions from the components and in to redux but that has proven tricky in the past and wouldn't be worthwhile at this point.

Suggestion for extra work:

Between entering a URL & hitting enter, and the site-preview being generated there are essentially 2 loading states: The continue button shows it's 'busy' state (while we check the URL's validity), then there's just a spinner (while we generate the mShot preview).
It would be a smoother experience if we could have the busy state of the button represent both the validation and the mShot call.

These screenshots show how the UI of the file upload importers would look with this PR applied.

Import start

image

Import file uploading
(Ignore the excessive width of the progress bar in these screenshots - we'll fix that in a separate PR.)

image

Import file uploaded

image

Author mapping

image

Import started

image

Importing resources progress

image

Import done

image

@matticbot
Copy link
Contributor

@spen spen force-pushed the fix/importer-ui-fixes-for-clashing-buttons--try-render-props--2 branch 3 times, most recently from 97dc9ab to b6e86b8 Compare March 12, 2019 18:33
@andfinally andfinally force-pushed the fix/importer-ui-fixes-for-clashing-buttons--try-render-props--2 branch from e38a2ef to a6beaba Compare March 13, 2019 11:14
@spen spen force-pushed the fix/importer-ui-fixes-for-clashing-buttons--try-render-props--2 branch 4 times, most recently from f6f98c6 to fa3e55c Compare March 13, 2019 13:53
@spen spen marked this pull request as ready for review March 13, 2019 14:22
@spen spen changed the title Fix/importer ui fixes for clashing buttons try render props 2 Importers: Move action buttons to the bottom of each screen Mar 13, 2019
@spen spen requested a review from a team March 13, 2019 14:22
@spen spen added [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. Import Site Importer Site Importer related issues labels Mar 13, 2019
@andfinally
Copy link
Contributor

The code looks good to me - I did run into a weird state issue locally with my Wix import though, so I'd like to give this some more testing tomorrow. I'm not sure if the issue was related to these changes or if it was a pre-existing glitch.

WP import

  • Start import opens importer
  • Cancel closes importer
  • Cancel is greyed out during upload
  • Cancel after successful upload clears uploaded file from file pane
  • Upload pane successfully uploads new file after Chrome file upload error interrupts big upload
  • Continue after upload goes to author mapping view
  • Cancel leaves author mapping view and returns to importers list
  • Start Import starts import - button changes to Importing with busy state
  • Done after import finished returns to importers list.

Wix Import

  • Start import opens importer, Continue is greyed out
  • Cancel closes importer
  • Continue starts processing
  • Cancel during processing returns to importers list
  • Cancel on preview pane returns to URL input pane
  • Yes! Start import on preview pane starts import
  • Importing with busy state appears (shortly after spinner) during import
  • Cancel on importer failure goes to importers list

Wix weirdness

  • My Wix import got stuck. It seemed to be taking a long time. When I eventually refreshed the page, I got the importers list with all importers greyed out - the ImporterStatus for all of them was importer-disabled.
  • On refreshing again I got just the "stuck" view of the active Wix importer again with the status importer-importing.
  • I reset the importer state in my blog RC and started a new import with a different URL.
  • I got through the preview pane and started the import.
  • The view jumped back to the URL input pane.
  • Eventually it changed again to the empty importer with the cancel button. (Status was importer-import-failure.) This was the kind of error state I came across earlier today.

{ translate( 'Close', { context: 'verb, to Close a dialog' } ) }
</Button>
<ActionButton disabled={ disabled } onClick={ this.handleClick }>
{ translate( 'Cancel', { context: 'verb, to Close a dialog' } ) }
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe the context here should be like to Cancel an operation.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1

const { importerStatus, icon, isEnabled, title, description } = this.props;
const ButtonComponent = this.getButtonComponent();
const { importerStatus, icon, title, description, site } = this.props;
const { importerState } = this.props.importerStatus;
Copy link
Contributor

Choose a reason for hiding this comment

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

Would this be simpler?

const { importerState } = importerStatus;

@@ -121,6 +118,8 @@ class UploadingPane extends React.PureComponent {
};

render() {
const { importerStatus, site, isEnabled } = this.props;
const { importerState, importerId } = this.props.importerStatus;
Copy link
Contributor

Choose a reason for hiding this comment

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

This could be simplified too.

const { importerState, importerId } = importerStatus;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good spotting on these! Copy pasta I swear!
Those should be handled in 7617ce8 :)

Copy link
Contributor

@creativecoder creativecoder left a comment

Choose a reason for hiding this comment

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

First, very nice work making these changes within this tangled part of our code base and not making it any worse... thank you!

I tested Wix and WordPress imports and everything worked as expected in terms of cancel buttons and stepping through the import. I left a comment about component naming to consider--your call if you think that's worth doing and whether it's worth doing now.

import ActionButtonContainer from 'my-sites/importer/importer-action-buttons/container';
import ActionButton from 'my-sites/importer/importer-action-buttons/action-button';
import CloseButton from 'my-sites/importer/importer-action-buttons/close-button';

Copy link
Contributor

Choose a reason for hiding this comment

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

These components seem odd to me, in that they have generic names but are importing specific. Could we have more descriptive names, like ImportActionContainer, ImportActionButton, ImportCancelButton, etc?

(I know this issue isn't new to this PR)

{ translate( 'Close', { context: 'verb, to Close a dialog' } ) }
</Button>
<ActionButton disabled={ disabled } onClick={ this.handleClick }>
{ translate( 'Cancel', { context: 'verb, to Close a dialog' } ) }
Copy link
Contributor

Choose a reason for hiding this comment

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

+1

@creativecoder
Copy link
Contributor

Pinging @dezzie for a design review.

@andfinally
Copy link
Contributor

I don't know if it's just me, but it seems like one effect of the change in the upload pane is to make it less apparent when a file has successfully uploaded - previously, a magenta button popped into view in the middle of the pane, making it very clear the upload had completed. I think the upload success is less obvious now.

image

image

image

@andfinally
Copy link
Contributor

I've done a bunch of imports - several Wix, an Importer 6, a Medium - and all went well, so I reckon we're good to go. I'll hold off approving for now in case Spen wants to push any changes.

@spen
Copy link
Contributor Author

spen commented Mar 14, 2019

The code looks good to me - I did run into a weird state issue locally with my Wix import though, so I'd like to give this some more testing tomorrow. I'm not sure if the issue was related to these changes or if it was a pre-existing glitch.

Sadly, this is all existing weirdness, the only remedy would be to properly address the weird state set up we have there :/

I don't know if it's just me, but it seems like one effect of the change in the upload pane is to make it less apparent when a file has successfully uploaded...

I see what you're saying. I wonder if a nice ✅ icon or similar would be a good indicator here?
Another improvement I can see would be to have the continue button present throughout the upload process, but have it disabled until the file is uploaded, similar to how it is in the URL input pane before it has a value.

@dezzie
Copy link
Contributor

dezzie commented Mar 14, 2019

@spen, @andfinally, @creativecoder, yay! I took a look, and ran some imports, and I think we are good to merge. I hear you on:

  • Having something that indicates a successful file upload has taken place in the upload area. The text message is better than nothing, so I would go with what we have now if doing something new would hold us up a few days.
  • @spen's note about the suggested extra work to smooth out the progress indicators.
  • that progress bar is a little wide :) but we can address this later since it's visible for only a small amount of time.
  • Removing the "Back" affordance from the secondary navigation once an import has started, to prevent user errors. for this one, if you'd be comfortable doing it in a separate PR, maybe that'd be smarter, in the event that we get pushback for doing that and we have to undo work.

If we can follow-up on those things and put them in a separate PR for efficiency that'd be great. That also gives me time to run this stuff by the Muriel team without holding stuff up.

@spen
Copy link
Contributor Author

spen commented Mar 14, 2019

I'll hold off approving for now in case Spen wants to push any changes.

All planned changes are up - the component naming and destructuring fixes, so ready for another 👀!
Thanks a bunch for the thorough reviews @andfinally :)

@spen spen force-pushed the fix/importer-ui-fixes-for-clashing-buttons--try-render-props--2 branch from 7617ce8 to b7e4705 Compare March 15, 2019 00:01
Copy link
Contributor

@andfinally andfinally 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 having a look @dezzie and thanks for the changes Spen! This looks good to me - I've done a couple more successful imports with the latest version and experienced no hiccups. I get what you mean about the tangled state being the cause of occasional weirdness!

@andfinally andfinally removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Mar 15, 2019
@spen
Copy link
Contributor Author

spen commented Mar 15, 2019

I've created #31481 for the file upload success UI.

Awesome, thanks @andfinally :) And thanks for testing again! 🙏

@spen spen merged commit 0b72c8c into master Mar 15, 2019
@bsessions85
Copy link
Contributor

@spen It looks like this change broke an e2e test. Can you take a shot at updating the Import a site while signing up test? I would guess it is probably just a change in a css selector

@spen
Copy link
Contributor Author

spen commented Mar 15, 2019

Thanks for the heads up @bsessions85 - I'll get on this right away :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Import Site Importer Site Importer related issues
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants