site-kit-wp: Tag Manager setup/settings blocks user while container data is loading without loading indicator
Bug Description
It takes a long time (10 seconds plus) for Site Kit to recognize a non Site Kit placed GTM snippet and populate the account and container fields with that manually inserted information. While this may be in relation to a lookup of all Tag Manager accounts during the wait users there are a couple of issues:
- Users may be uncertain on how to proceed, do they wait or do they exit (there is no loading indicator and the “Confirm and Continue” buttons are greyed out
- The pre-populated GTM account and container are not necessarily the correct GTM account and container (this should be addressed once #4209 is has been resolved)
- It only changes to the correct pre-populate data after the wait/lookup
https://recordit.co/IW511jun1l
An improvement for this would be for the field to be not pre-populated and ideally a loading indicator would appear.
Steps to reproduce
- Insert GTM manually with the code snippet in the head and body of your site
- Connect GTM within Site Kit. It takes some time for GTM to populate with the correct GTM already connected, in the meantime showing possibly incorrect data
Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance criteria
- The primary loading indicator shown while loading Tag Manager setup or settings-edit views should continue to be shown under the following conditions:
- The presence of an existing tag is not yet finished resolving
- An existing tag is present and its permissions check has not finished resolving
- A new loading indicator should be shown to the right of the container selects in the Tag Manager setup and settings views when the live container version is loading
- It should use the same type of mini progress bar that is used for the compatibility checks which happen on the splash screen, i.e. next to the disabled CTA button. The small text above it should say:
Checking tags
- Only a single loading indicator should be shown for this which should show regardless of which container(s) the version data is being fetched for
- It should use the same type of mini progress bar that is used for the compatibility checks which happen on the splash screen, i.e. next to the disabled CTA button. The small text above it should say:
Implementation Brief
- In
assets/js/modules/tagmanager/components/setup/SetupMain.js: andassets/js/modules/tagmanager/components/settings/SettingsEdit.jscomponents:- Continue showing the progress bar when
hasExistingTagandhasExistingTagPermisionis undetermined by expanding the logic that sets theProgressBarasviewComponent. ie.if ( ... || hasExistingTag === undefined || hasExistingTagPermission === undefined ) { ...
- Continue showing the progress bar when
- In
assets/js/modules/tagmanager/components/setup/SetupForm.jsandassets/js/modules/tagmanager/components/settings/SettingsForm.js:- Get the
accountID,internalContainerIDandinternalAMPContainerIDusing thegetAccountID,getInternalContainerIDandgetInternalAMPContainerIDselectors from theMODULES_TAGMANAGERstore. - Define
isResolvingWebGetLiveContainerVersionandisResolvingAMPGetLiveContainerVersionusing theisResolvingwithgetLiveContainerVersionas the first argument and array ofaccountIDandinternalContainerID/internalAMPContainerIDas the second argument of theisResolvingselectors respectively. ie.
- Get the
const isResolvingWebGetLiveContainerVersion = useSelect( ( select ) =>
select( MODULES_TAGMANAGER ).isResolving( 'getLiveContainerVersion', [
accountID,
internalContainerID,
] )
);
- Conditionally render a
ProgressBarinside thegooglesitekit-setup-module__inputsdiv either of theisResolvingWebGetLiveContainerVersionorisResolvingAMPGetLiveContainerVersionistrue. * It should be something like this: https://github.com/google/site-kit-wp/blob/f8b423e14e8e0878db86e4530b11cb8d414d6c1a/assets/js/components/setup/CompatibilityChecks/index.js#L84-L89- Use the text from the AC as the label.
Test Coverage
- No changes needed.
QA Brief
QA:Eng
- Create a Google Tag Manager account manually
- Open
wp-content/themes/twentytwentyone/header.phpfile. Make sure you’re on theTwenty Twenty Onetheme. If not add the scripts respectively. - Copy the scripts and add it to the
<head>and<body>tags respectively - Go to the Site Kit settings page and connect/setup Tag Manager
- Verify the new loading animation with the text
Checking tags…along with the smallProgressBarwhile the container is loading data. Please refer to the screenshot attached in the PR description. - Once connected, go the settings connected services and edit the Tag Manager and refresh the page
- Verify the new loading animation with the text
Checking tags…along with the smallProgressBarwhile the container is loading data. (The loader might be visible only on the first time in the setting page) - Verify the same loading behaviour without an existing tag
Changelog entry
- Update Tag Manager setup and settings edit views with loading indicator while tags are being checked.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 23 (3 by maintainers)
@wpdarren – in this case, because the container it is checking the tags for is known during the initial load (ie it’s initially set via settings), the check may finish before the main loader is done so it appears as though it doesn’t happen, but it just starts earlier. This actually only happens if there is no existing tag because it takes extra time to determine the account ID if there is an existing tag, but if settings are saved it’s already known.
In this case, you should be able to see it by:
Give that a try and let me know if that does it for you. It’s not entirely required that it’s always seen in all cases. The important thing here is that the user is not blocked from proceeding (disabled submit button) due to these checks which are in progress which weren’t visible before. The submit button can be disabled for various reasons, but this was the only one where everything in the form appeared valid and the submit button could be “stuck” disabled for a second or two without any indication as to why.
@hussain-t regarding the QAB, this issue is not specific to an existing tag case (at least for the “Checking tags” indicator). Tags are checked both for an existing tag but also any time the user chooses a specific container under normal circumstances.
Would you please update the QAB to clarify?
@felixarntz the best placement would be next to the submit button IMO (as with compatibility checks) as it is providing more context as to why the button is disabled. That doesn’t work in both places without more substantial changes so I think putting the progress bar next to the selects is the next best place. We should make it clear though that only one progress bar should be added regardless of which containers are fetching versions (rather than one per container). I’ll update the ACs.
@aaemnnosttv Shouldn’t the small progress bar display on the right of the dropdown instead? That would be closer to how we have on the splash screen for the compatibility checks and IMO would look better. I think the mock you have above is a bit odd as it makes me think this dropdown is an autocomplete that is loading, but what we’re loading here doesn’t really affect the content of that dropdown.
Regarding the ACs, should we finalize the copy as “Checking tags”? That would work for me.
@aaemnnosttv
Sgtm! I’ve added a note to the ACs.
@felixarntz mostly LGTM, my only suggestion would be to maybe make the messaging more generic (like “Checking configuration/containers”) or have it without a label (just a progress bar). We can probably start on this and finalize the exact wording later though. I’ll add this to the AC so we can move it forward to IB.
@aaemnnosttv Using the mini progress bar like we do in the compatibility checks sounds good to me. I’ve defined this in the ACs. If that looks good to you, let’s move this to IB.
@jamesozzie I’ve noticed this one as well although I’ve never seen it take longer than a few seconds. I can imagine for some users this could take a bit longer and makes for a confusing experience.
@felixarntz I’ve added preliminary ACs but let’s define how the loading state should look as it’s a bit different than other modules where the progress bar would replace the select for example. Here we could maybe add a spinner next to the submit button which is disabled. Alternatively, we could show the mini progress bar with a message similar to the compatibility checks we do during initial set up. Thoughts?