Mixed Content

Lets isolate the use-case for which you want to display on one page: blogs, campaigns, trendy brands (with icons), different product-slider recommendations, most-viewed categories, etc.

This page will identify the core elements and strategies to follow when designing a mixed-content Layout.

API REQUEST STRATEGIES (INTEGRATION)

Because of the different nature of the returned content, it is expected that different filters will work on a certain content type.

As a practice, the Integration Layer Guidelines (ex: for Shopware6, Magento2, etc) include samples for the default product filters.

The required filters for every content type (if any) is an integrator`s decision.
The filters have no impact on the optimization rules on the widget.
The filters are used to restrict the API response.

1. ONE API REQUEST

This is the desired use-case.

Why? Because it gets down to building a single narrative layout in Intelligence Admin (IA).

  • Easy to maintain & migrate

  • Transparent for debugging

STEPS

  1. Identify the content required (ex: a list of campaigns, a list of products, trending brands + icons slider, more products, some blogs)

    1. Identify the data-source (solr index, headless CMS, IA campaign/correlation, etc)

    2. Identify the default filters for each content (ex: status+stock+store for products, blog-status for blogs, etc)

  2. Identify the Layout Blocks to be used

    1. Review the Integration Guide with default Narratives

    2. (If it helps) Identify the already available JSON elements in the framework-specific integration guidelines

    3. Make sure the Layout Blocks that return a collection / list of elements:

      1. the parent has the bx-hits:accessor key-value property

      2. the child has the bx-hit:accessor key-value property

    4. Add the accessor property in your Layout Block JSON Schema

      1.  

  3. Create the Narrative Layout (linked to a single widget: home, for ex)

  4. Identify the widget for each content-source

    1. Each data source must be provided by an individual widget

    2. When building the narrative layout, the name will be set as a value for the accessor property

  5. Create the API request based on your Context

    1. Use the Narrative API - Technical Reference

    2. or check out the API Request view service https://boxalino-di-transformer-krceabfwya-ew.a.run.app/api/view

  6. Add the identified filters at step #1.a

    1. At the level of the content widget

    2. If your API request has some filters (ex: the ones for product), add Request Rule to remove those filters from other widgets

      1. Go to Merchandising >> Request Rules

      2. Add a new rule for a widget (or more) (ex: blog)

      3. Switch on tab “Effects” and add “Remove” rules for the API request filters

  7. Test he API request

 

The above sample is based on our demo web-shop layout https://demo.bx-cloud.com/

In the above example, the API response was rendered in a loop, all Layout Elements being sorted per design requirements.

If you need/want to access the API response in different page sections, use the position property (with a value) as instructed here Narrative API - Technical Reference | Use other positions than the main “blocks”

 

2. MULTIPLE API REQUESTS

This case is the easiest one to follow through.

It is assumed that steps #1-2-3 are known (content, data source, filters and Layout Blocks)

  1. Identify the content details (source, filters)

  2. Create the required Layout Blocks

  3. Create individual narrative layouts, linked to a single widget

    1. Use the Layout Blocks for your data content

  4. Identify the API request structure https://boxalino-di-transformer-krceabfwya-ew.a.run.app/api/view

  5. Add the filters on the API request, matching each widget & content particularity

  6. Make the API requests

 

Relevant Layout Blocks

 

You can use a wrapper-Layout Block in order to add Sub-Content blocks for the given position.

[ { "id": 2096, "uniqueKey": "rtux_wrapper_position", "parametersJsonScheme": "{\n \"title\": \"Content wrapper\",\n \"type\": \"object\",\n \"properties\": {\n\"position\": {\n \"type\": \"string\",\n \"description\": \"The value set will create an individual node in the API response\"\n },\n \"accessor\": {\n \"type\": \"string\",\n \"description\": \"hits accessor (typically leave empty)\"\n }\n }\n}", "format": null, "widgets": [], "parameters": [ { "name": "name", "values": [ "rtux_wrapper_position" ] }, { "name": "type", "values": [ "Boxalino\\RealTimeUserExperience\\Block\\Api\\Block" ] }, { "name": "template", "values": [ "rtux-wrapper-position" ] } ], "subRenderings": [], "route": "visual-elements", "reqParams": null, "$fromServer": true, "parentResource": null, "restangularCollection": false, "isSelected": true } ]

These Layout Blocks have the required “bx-hits”:”accessor” property-value. (Step #2.c)

[ { "id": 1981, "uniqueKey": "rtux_content_item", "parametersJsonScheme": "", "format": null, "widgets": [], "parameters": [ { "name": "bx-hit", "values": [ "accessor" ] }, { "name": "name", "values": [ "rtux_content_item" ] }, { "name": "template", "values": [ "rtux-content-item" ] } ], "subRenderings": [], "route": "visual-elements", "reqParams": null, "$fromServer": true, "parentResource": null, "restangularCollection": false, "isSelected": true }, { "id": 1982, "uniqueKey": "rtux_content_list", "parametersJsonScheme": "{\n \"title\": \"Content List(blog, product, etc)\",\n \"type\": \"object\",\n \"properties\": {\n \"content\": {\n \"type\": \"string\",\n \"description\": \"Content type\"\n },\n \"accessor\": {\n \"type\": \"string\",\n \"description\": \"accessor (for connection to other widgets)\"\n }\n }\n}", "format": null, "widgets": [], "parameters": [ { "name": "bx-hits", "values": [ "accessor" ] }, { "name": "name", "values": [ "rtux_content_list" ] }, { "name": "template", "values": [ "rtux-content-list" ] } ], "subRenderings": [], "route": "visual-elements", "reqParams": null, "$fromServer": true, "parentResource": null, "restangularCollection": false, "isSelected": true } ]