App Banner

[puruadobe]

At DC we have a requirement [0] to migrate the app banner feature to DC/Milo. Currently this feature is set up in AEM using branch.io third party integration. PoC for the integration with branch.io and DC/Milo for your reference [1]

Branch.io setup steps:

• Add branch.io script and initialize.
• Use Branch.io dashboard [2] for
  • Authoring the app banner related journeys (experience)
  • Scheduling and targeting selective pages

Pros:

• Reusing existing journeys (authored content) and related setup in Branch.io

Cons:

• Third party cost
• Somewhat limited authoring capabilities

Another option is to use Milo personalization (MEP) [3]

Steps:

• Create a app banner block for the authoring of journeys (experience).
• Create fragments with variations of the journeys.
• Use MEP manifest to target the mobile/tablet devices to show the app banner.
• Needs scheduling requirements and MEP support for the same (ongoing discussion: https://github.com/orgs/adobecom/discussions/1048#discussion-5464612 )

Pros:

• In house set up for authoring and managing app banner
• More flexible authoring options can be provided

Cons:

• We have to discard the branch.io set up and journeys already created
• Some of the dashboard features may not be fully available via MEP (tracking, conversion, ads, redirects, scheduling etc. )

[0] https://jira.corp.adobe.com/browse/MWPW-123236
[1] https://mwpw-123236--dc--puruadobe.hlx.page/drafts/doreswam/word-to-pdf?_branch_view_id=1224075380893961221
[2] https://adobe.dashboard.branch.io/journeys/manager
[3] https://milo.adobe.com/docs/authoring/features/personalization

Suggestions/comments/guidance are welcome.

cc: @chrischrischris , @vivgoodrich , @Blainegunn , @auniverseaway

[auniverseaway]

I would probably avoid doing a branch.io integration in Milo. You're welcome to do it in your project. Last I heard, branch.io was de-commissioned from a Send-A-Link perspective. I think the same is for App Banner, but not 100% sure.

I think the app banner is just a block in a fragment. You have some CLS concerns, but I think it should be mostly straight-forward. You can look at how breadcrumb is done to see prior art.

[honstar]

I agree with @auniverseaway to not pursue branch.io any longer. Despite the fact that existing journeys would be "lost" somehow, it'd be good to talk numbers how many journeys already exist today and if a potential scripted migration from branch.io to franklin might be something to consider. Or have authors recreate them from scratch which I feel might be more realistic since I don't think we're talking large volume of content.

@puruadobe , can you elaborate on the scheduling requirements you called out?

[puruadobe]

Sure @honstar. Thanks for your thoughts and guidance.

• Scheduling: It is just the start and end date for a banner and on which pages it should run.
• AB testing: branch.io have AB testing capability with % of audience setting for a journey.
• Tracking conversions for each journey etc.

I am checking with the product managers on which of these features are a 'must' and 'good to have' etc. For MVP, all they want is to just be able to author the app banner, create variations as fragment and also localize and use on selected pages.

[puruadobe]

@auniverseaway I looked at the breadcrumbs which is in the global navigation, with the CLS angle, but I may need some more pointers on how a consumer block trying to place some elements above GNAV can resolve potential issues, please.

[puruadobe]

Hi @narcis-radu, @overmyheadandbody, @mokimo

Thanks for the excellent session on GNAV deep dive. I am trying to still catch up with the recording from where I left the meeting.

This is the app banner I am building for DC which I was talking about during the GNAV presentation/QA. I understand that you are still working on some strategy for consumers to mitigate such CLS issues when they want to push their block above GNAV etc. Please let me know if I can try out any ideas.

cc: @Blainegunn

[puruadobe]

This is my first block in DC using Milo :), though I am still working on the unit tests and potential CLS issue, but may I request everyone to provide your valuable feedback esp. CSS styling and performance, please ?

https://github.com/adobecom/dc/compare/stage...puruadobe:dc:puru/MWPW-123236?expand=1

https://puru-mwpw-123236--dc--puruadobe.hlx.page/drafts/doreswam/acrobat-banner --> banner visible only on mobile devices

cc: @Blainegunn

[puruadobe]

With regards to CLS concerns, currently on my local I see a CLS score of 0.042, for this page https://puru-mwpw-123236--dc--puruadobe.hlx.page/drafts/doreswam/acrobat-banner, which seems to be not bad.

[overmyheadandbody]

Hi @puruadobe! 0.042 might seem like a small value, but in reality it's almost 50% of the total allowance of an entire page in order to get a Godd score for CLS - https://web.dev/cls/#what-is-a-good-cls-score.

Ideally the app banner would have a predefined height regardless of its content. Is that the case? As @auniverseaway was mentioning, a breadcrumb-like strategy might come in handy here - https://github.com/adobecom/milo/blob/main/libs/styles/styles.css#L71-L72. Assuming the App Banner is a block on the page and has a predetermined height (or maybe 2 variants between mobile and desktop), we could potentially define a new height for a header.global-navigation.has-appBanner selector that accounts for both Gnav and the App Banner.

[puruadobe]

It has fixed height but also other things to note is that the banner is only visible on mobile and disposed when clicked.

[puruadobe]

@overmyheadandbody

For now, I made the default franklin elements to hide and only show the final decorated banner on top of the gnav (prepend to body, but not prepend to the gnav header - need to work with you on adjusting height). Surprisingly this alone resulted in 80% improvement (previously it was 0.048 and now 0.008) :).

[npeltier]

As per mep based on scheduling, we plan exact same setup for promotion use case, stay tuned!