Whitelabel changes (checkout)

Problem to solve: we can have multiple items in the "Your cart" section in a way that we'll have a "pollution" of information and also the information will be "detached"

• With the mentioned points above we'll need to change the UI to bring a better UX to the understanding of the available offers and free items relationship

Solutions

Option 1: free item inside the item that has the offer

Perhaps we can have the free item inside the item that has the offer

Problems:

• How to have this clear and not confusing?

• The free/paid item needs to be edited. We'll need to keep the buttons to open the modal as we have today

Technical availability/effort: N/A

Conclusion: we concluded that this will not be semantic for the user as the free/paid item doesn’t exist in the previous menu (customize your order) and will be strange to the user

Option 2: have the item that has the offer and the free item like a collapsable item

The main idea is to have a "collapsable" item (the item that has the offer) with the paid and free items inside this "group". This will help perhaps with the "multiple detached" information

Problems:

• Perhaps we'll need a loading/shimmer in the "Your cart" section because we'll need to process this data from the cart entries to show the information in the desired way

Technical availability/effort: N/A

Conclusion: this will bring more confusion and will not help with the pollution on the page. Besides that we should not hide important information for the users

Option 3: free/paid item as text information in the item that has an offer

Show the information of the paid/free item quantity in the item that is offering them (as text) and also have a button to open the Add extras modal to edit them

Problems:

• I do not see much problem with this approach. Perhaps will be the easiest one technically speaking

Technical availability/effort: N/A

Conclusion: we concluded that this will not be semantic for the user as the free/paid item doesn’t exist in the previous menu (customize your order) and will be strange to the user

Option 4: Tag on the item, indicating the quantity of free ketchup.

Add a tag to the cart item, indicating the quantity of available free ketchup for each item. With this, the user will know what's going on on the screen even if we have multiple offers at the same time

Problems:

• This will resolve our problem?

Advantages:

• Scalable and is a generic solution.

Disadvantages:

• We still have 2 items (one for free and other for the paid) as before

• If we have more than one offer active we’ll have multiples items as before

Technical availability/effort: 0.5 sprint

Option 5: have only one item as the original proposal

Keep the original Figma proposal to have only one item with dynamic quantity for the free/paid item

Problems:

• Debug and analyze the use of the existent feature for “quantity based PLU” and discover if the FE part will be able to calculate the price in the right way

• We’ll need refactor Sanity to have (see Sanity option 1 solution below)

  • New category field in items

  • New document for the promotional items

• We’ll not use the “AddOn section feature” anymore and we’ll need to delete/move the necessary code for that

Update related to the initial idea: the “quantity based PLU” will not resolve our problems. When this field is used the user needs to fill all the desired quantities. In our case, the paid/free item can have an “infinite” quantity (based on the combination) and this is broken for our solution and will not work or solve the client's desire for improvement. With that in mind, I (Vinicius) have an idea to variate the constantPLU information on the FE side to see if this can solve the problem without touching the backend and the mentioned “quantity based PLU” and I’m doing a POC to validate this.

Solution proposal

As we don't have an implementation that allows us to deal with a single item that can have free or paid value depending on the quantity the main idea of the solution is to variate/change the PLU that will be used to calculate the value of an item

How the item was in the “Your cart” section:

What the cart item will look like after this solution:

Obs: of course we’ll not need the “Ketchup Sachet Free” in the name… this could be just “Ketchup sachet” showing the description about the quantity of free items that we have for this offer. We’ll also hide the edit button as we not need this button for our free item feature.

Approach 1:

The main idea of this approach is to change the free item behavior with a low impact on the existent feature:

• Create a new hook with a function that will return the correct PLU (free or paid)

• Adjust the use-pricing-function hook

  • Call the new hook

  • Adjust pricingFunctionNoSelections and call the function returned from the new hook inside the condition that checks if the pluType is a constant. The function will return the correct PLU to be passed inside `getPriceForPlus`

    • We’ll also need to adjust the itemQuantity variable or the return. We can have a function that will return the correct quantity to be multiplied based on the offer

      • If the item quantity is less than the actual offer use the quantity from the item. If not we’ll use the item quantity minus the actual maximum offered

  • Perhaps we’ll need to adjust other functions too… need to analyze the full impact of this

• Adjust the cart page (src/pages/cart/index.tsx) cartEntries `updatedCartEntries` return to also have the logic to use the free or the paid PLU

  • This is important because this array will be sent to the priceOrder query and we can’t charge for the free ones for example

  • We’ll need to find inside this array the offered item (we can use the new hook created above for that)

  • If we find the item we’ll need to adjust the vendorConfigsproperty to change the PLU (paid or free based on the max offer counter logic)

• Adjust the addons-item-container

  • Remove the logic that will show the paid item as now we’ll have only one item

  • Use the same method used in the upsell component to add the item to the cart. We’ll not need the hook from the addOns feature anymore

    • Adjust the cart-item buttons + and - to be disabled based in the rules of the free item feature

    • Hide the “edit” button. This button will not be used for our free item feature

  • Analyze and adjust the useAddOnsItemContainer to not look at the paid item anymore. Here we can remove or reuse what’s needed

  • Now when the free item is added to the cart we’ll not need the modal for the edition anymore

• Remove unnecessary logic and code from the addOn feature

• We’ll not touch on Sanity now and this will happen in the next changes/improvements

• Advantages of this approach:

  • Change the use-pricing-function will make all this work correctly even in the cart-preview for example

  • Low-impact development for an initial improvement

  • No need to touch on BE or other integrations

• Disadvantages of this approach:

  • Changing the PLU on a logic hide in the FE code (this will not be a clear config like the vendor config for example) in this first version of the improvement. This will be improved when we change the Sanity part in the future

  • Without the addOn feature and using the cart-item as it is (with the + and - buttons) the page will suffer from re-render when we change the item quantity. Using the addOn feature the state was isolated inside the “Add extras” modal

• Challenge: how do we show the free item quantity on the receipt?

  • Some thoughts of the author (Vinicius):

    • Option 1: have a “hide” item on the cart entries to be the one representing the free item quantity (this can be made on the (src/pages/cart/index.tsx) cartEntries). Perhaps we’ll need to change the component that show the “Your cart” information to hide the item there too

    • Option 2: analyze and discover how we can add items to the receipt without touching the cart entries

Technical availability/effort: 1/1.5 sprint

Sanity changes

In the last meetings we discover that Iberia thinks that the UX in Sanity is complicated and we have to change different documents to have the feature working properly. They want to know if we can improve this part of the feature.

Solutions

Option 1: add categories in Sanity items and a new document to deal with offers

With categories in Sanity, we’ll have something similar to the concept of a “hot” item that Iberia showed to us in the air touch solution. We’ll have a new document for the promotional item solution where we’ll add the promotional items and which category they have an offer. For the items, we’ll just select the category in each one.

The solutions consist in:

• Remove the necessity of the creation of a paid and free item in Sanity that we have today

• Creation of a new document for the promotional items configuration, where we:

  • Select the items that will be considered promotional ones

  • Select the category that will receive that promotion

• Update/configure in Sanity the new category information for the items that will receive the offer

Technical availability/effort: to be analyzed