Nav Unification: Show a modal to customers the first time they log in

[cpapazoglou]

What

If a user is logging in for the first time since the nav unification project is enabled, show them a modal explaining the recent changes.

Why

We need to help customers orient themselves to the change by explaining what has changed, the reasons behind it and how it will benefit them.

Acceptance criteria

• Should a user login for the first time since the nav unification change. They will see a modal which explains the recent changes to them.
• Should a user close the modal, they will not be presented with this again upon future logins.

Resources

For any design improvements, adding some animated GIFs would be preferred see #47049 (comment)

Design i1 JPGs:

• Desktop.zip
• Mobile.zip

Design i2 GIFs, JPGs + mp4 walkthrough videos:

• Desktop.zip
• Mobile.zip

Design files:

• Figma designs

Related to #47047

[cpapazoglou]

@davemart-in could you please elaborate more on this? Do we have any designs, user journey?

[davemart-in]

I'll cc @sfougnier on this one.

[ghost]

I have been exploring using a stepped approach that allows us to showcase the updated features. The intention of this is to introduce the unified nav and tell a brief story of how it works in an attempt to cut down on any confusion.

A few things:

• The copy is not final but I wanted to get the design out in the world.
• Is there potential to use animated gifs in lieu of static imagery? It could help tell the story and show off specific interactions.

Desktop

Mobile

Figma link

[cpapazoglou]

Thanks @sfougnier for working on this! This stepped approach seems very good and makes sense!

The copy is not final but I wanted to get the design out in the world.

I understand that the copy is not final, but is the wp-admin wording something that may confuse most of the simple users? Many of them may not even know its existence. A usp for all the users would be "Faster navigation" cause we have surfaced the most used links (Posts, Pages) and we have also used the flyouts.

Is there potential to use animated gifs in lieu of static imagery? It could help tell the story and show off specific interactions.

I don't see a blocker here, go for it! We just need to make sure that we create images / gifs for the variation that we will launch (currently we have developed only i1).

[ghost]

is the wp-admin wording something that may confuse most of the simple users?

Agreed, I definitely don't think we would want to include that jargon here. I imagine that can be cut, but I am not the best wordsmith and wanted to express intent here.

I don't see a blocker here, go for it! We just need to make sure that we create images / gifs for the variation that we will launch (currently we have developed only i1).

Awesome! I can work on creating those.

[ghost]

For pairing this modal with the sidebar design that's currently being tested, let's use static designs:

For any design improvements, adding some animated GIFs would be preferred:

Design i1 JPGs
Desktop.zip
Mobile.zip

Design i2 GIFs, JPGs + mp4 walkthrough videos
Desktop.zip
Mobile.zip

Design files
Figma designs

[obenland]

@davemart-in Priority-wise, should this still go into next iteration or should we focus on alpha feedback first?

[cpapazoglou]

@sfougnier I am afraid you have created visuals with the new designs (i2) that are not developed. Should we create the visuals with i1? Or is it something I am missing?

[cpapazoglou]

@davemart-in , sorry for the double ping ❤️ ! In which environments / cases should this modal be shown:

• Calypso Screens
• Calypso block editor
• wp-admin

Also, are we showing it only once?

[davemart-in]

should this still go into next iteration or should we focus on alpha feedback first?

@obenland Up to you. We'll need both before launch.

In which environments / cases should this modal be shown:

@cpapazoglou I'd say we could keep it to Calypso Screens to reduce scope.

Also, are we showing it only once?

Yes, users should only ever see this modal once.

[ghost]

Should we create the visuals with i1? Or is it something I am missing?

@cpapazoglou I added i1 visuals to my comment above. Let's keep anything i1 static for now and reserve the fancy GIFs for any design improvements.

[getdave]

Scope and designs look to have been confirmed.

This now requires investigation and quick research into how much effort is required so we have a handle on scope.

[frontdevde]

Note: there's a WP.com What’s New Product Announcements feature (pbBQWj-AH-p2) that will do something similar in Calypso. They are using the core Guide component and it was suggested we consider this as well.

[tjcafferkey]

Couple of questions:

• Should we only be showing this to existing users, or new users as well?
• To avoid any dependency on Calypso should we create this in /packages/[announcements / nav-unification] in case scope increases in future and this does end up getting rolled out to other environments? (E.g. WPCOM Block Editor, WP Admin)

[cpapazoglou]

Should we only be showing this to existing users, or new users as well?

That's a good question. Current plans, include enabling nav-unification for specific segments ( eg all users with User IDs ending in 3 ) and then ramping up. With that in mind, new users should also be shown that modal when their User ID is included to the launched segment. On the other hand, since we are not a/b testing at all it could make sense enabling nav-unification for all new users and thus not needing to show that modal. But again, showing that modal doesn't do any harm in any case. So, for the sake of this issue, I lean to yes.

[tjcafferkey]

Thanks @cpapazoglou, I guess it will be based on the following criteria then:

• User is an existing user, or a new user.
• User falls into the segment which nav unification is enabled for.
• User has not seen this modal before.

On this last point. How do we want to track this state? The obvious answer would be localStorage however we know that if the user:

• Clears browser data
• Uses a different browser
• Uses a different device

Then they will be shown the modal repeatedly which could become annoying/frustrating over time. For the Block Editor NUX modal this value is sent to a specific endpoint when dismissed. For comparison the Whats New modal isn't tracked at all, since it's accessible via the menu in the editor.

Any ideas/preference around this aspect of the functionality?

[cpapazoglou]

I guess it will be based on the following criteria then: ...

Hmm, now that I read my comment, my answer "yes" doesn't make sense. What I meant is, show the modal regardless of whether the user is new or existing. Just use config.isEnabled( 'nav-unification' ) and whether the modal hasn't been shown before.

How do we want to track this state

Not sure how this pbBQWj-AH-p2 will work, I suppose it should already have a tracking mechanism. FWIW though, Banner already has a tracking mechanism

wp-calypso/client/components/banner/README.md

Line 33 in ba85297

tracksDismissName="calypso_banner_upgrade_dismiss"

[tjcafferkey]

Sorry, I think I miscommunicated what I meant by tracking the state. The tracking you mention above is tracking events, whereas I meant how we want to keep track of the state of the modal so that we know it has been shown (e.g. persistent storage).

I'll move towards a localStorage solution for now and we can update that if required.

[cpapazoglou]

I think I miscommunicated what I meant by tracking the state ...

Nope, you did pretty well! I have probably guided you to the wrong line. Here you are

wp-calypso/client/components/banner/index.jsx

Lines 49 to 50 in ed3e915

	dismissPreferenceName: PropTypes.string,
	dismissTemporary: PropTypes.bool,

with dismissTemporary = false

You can better understand how it works here

wp-calypso/client/blocks/dismissible-card/index.jsx

Lines 82 to 88 in 2b8a9b4

	dismissCard: () => {
	const preference = `${ PREFERENCE_PREFIX }${ ownProps.preferenceName }`;
	if ( ownProps.temporary ) {
	return setPreference( preference, true );
	}
	return savePreference( preference, true );
	},

[tjcafferkey]

By the look of things the <Guide /> component does not achieve 100% design parity by default unless some we start overriding the component markup & styles. The guide component renders the image and text on top of each other rather than side-by-side as per the designs.

(Ignore the placeholder image)

The way around this would be to use a <GuidePage /> component but as you can see here this isn't recommended as it's deprecated. (Note: This is what was done for the Whats New modal).

It seems like there are two obvious options here:

1. Use the <Guide /> component how it's recommended, which will render the image and text on top of each other rather than side-by-side.
2. Use the (deprecated) <GuidePage /> component with <Guide /> and using additional markup and styles (overriding the core components styles) achieve design parity.

cc: @sfougnier @getdave

[getdave]

Thanks for checking in @tjcafferkey and for the nice research into this.

Using the deprecated component would seem like it could cause maintenance issues down the line. As you say it looks like the pages prop of <Guide /> is the right direction.

The Issue appears to be that by default there is no built in mechanism for a "side-by-side" layout.

How about we spin up Storybook locally and test to see if it's possible to provide markup + style overides to achieve a side-by-side layout using the <Guide>?

Failing that, we should check whether @sfougnier is ok to adjust the design for the sake of expediency. If (as I suspect) it turns out that the side-by-side layout is a critical piece of the design, then we should get some context from the team that implemented the welcome modal as to why they decided it was ok to use the GuidePage and what their upgrade/maintenance plans are for the future.

I'd like to avoid Ajax getting sidetracked with developing an entirely new component if possible.

[ghost]

What's the reason we can't follow the same side-by-side layout that's in the What's new modal?
This design was meant to reuse that component. It seems like the stacked approach deviates from that.

[tjcafferkey]

This design was meant to reuse that component

@sfougnier sorry for not updating this issue yesterday. The good news is we are able to make it look like the What's New modal by overriding the <Guide /> core CSS (which is what was done in the case of What's New).

However, we may need to deviate from the mobile designs (which look different to the What's New modal) because the markup doesn't allow for certain aspects of it, mainly around the pagination and its position.

This PR should be ready for review today so it would be great if you could also cast your eye over it if you have time 😄

[mmtr]

I think there are a couple of things to follow up:

• Images contain English texts. Should we display them to users with a different language set?
• We need to make sure that new users don't get this modal, only existing users.

[tjcafferkey]

@mmtr yes you're right. I'll be creating separate issues for these to follow up.

[cpapazoglou]

I think there are a couple of things to follow up:

• Images contain English texts. Should we display them to users with a different language set?
• We need to make sure that new users don't get this modal, only existing users.

We would need to iterate on the "new users" condition the day we actually launch to customers.

[davemart-in]

Images contain English texts. Should we display them to users with a different language set?

I don't think this is necessary. The text in the screenshot is UI based, not informational. User's don't need to be able to read the text within the image to understand what is going on.

[mmtr]

We would need to iterate on the "new users" condition the day we actually launch to customers.

Right, the rollout will be gradual, so we have to handle that. The modal should show up if the nav unification has been enabled for the current logged user after they signed up.

• For the beta launch that is: is_a11n && registered_date <= January 21, 2021.
• For the first rollout (5% of single site users) that is: site_count == 1 && user_id % 100 < 5 && registered_date <= <first_rollout_date>
• Etc.

EDIT: I guess this can be simplified to:

function shouldDisplayNavUnificationModal() {
  if ( hasDismissedModal() ) {
    return false;
  }

  if ( isNavUnificationDisabled() ) {
    return false;
  }

  return getCurrentUserRegisteredDate() <= <LAST_ROLLOUT_DATE>;
}

And then update <LAST_ROLLOUT_DATE> every time we do a partial rollout.

[ghost]

Looks like the modal that accidentally debuted earlier was using the wrong image asset. We should be using these since there's no current plan to implement the visual changes:
IMG.zip

[Aurorum]

Looks like the modal that accidentally debuted earlier was using the wrong image asset. We should be using these since there's no current plan to implement the visual changes:
IMG.zip

PR in #49827 to update those image assets. :)