Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Current »

This is a template that should be used to document each feature. It’s meant to be easy, not prescriptive - change it at will!

Table of contents

Definition

Status

IN DEVELOPEMENT

RBIberia Owner

RBI Owner

❓ Open questions

We need to constantly make this section empty.

Requirements

Problem statement

The white-label application currently lacks the capability to allow users to purchase a different bag for carrying their food, similar to the functionality present in the AirTouch application's mobile buy process. The desired bag is a distinct model from the free bag, and when users choose to buy their own bag, it should come equipped with handles. Furthermore, the existing flow diagram of the AirTouch application needs to be replicated and implemented effectively within the white-label application to ensure a seamless and consistent user experience.

Acceptance criteria

  • Under RBI Sanity Studio > Marketing Content > Features there should be a new folder structure: Checkout > Pick Up > Add Bag with Handles

Sanity

  • The bag with handles should be set up as a distinct product within the Sanity application.

  • The product configuration should include necessary details such as name, price, and availability.

  • The bag with handles should be correctly categorized and labeled within the product management system.

  • Any changes or updates to the bag with handles product should be done by the Sanity application.

  • The functionality of bag will be activated by purchase channel like, dine in, take away, etc.

White-label

  • Provide users with the ability to purchase a different bag for carrying their food, similar to the functionality available in the AirTouch application's mobile buy process.

  • On the cart screen of the white-label application, a dedicated section should be available to display the bag with handles and its corresponding cost.

  • Within this section, users should have the option to add the bag to their cart for purchase.

  • Users should be able to edit the quantity of the bags they wish to buy, and the cost should update accordingly to reflect the changes.

  • The cart screen should provide a clear overview of the total cost of the bags added, taking into account the quantity and individual prices.

  • Once the user has finished adding bags to the cart, the flow to complete the order should follow the same process as the current implementation.

  • The cart screen and the entire order-buying process should be mobile-responsive, ensuring a seamless experience on different device sizes.

  • Quantity editing functionality should allow users to increase or decrease the number of bags in their cart as per their requirements.

  • The cost calculations for the bags and the total cost should be accurate, considering any applicable.

  • The cart screen and the associated functionality should be thoroughly tested to ensure its proper functioning, usability, and responsiveness.

  • The bag purchase functionality should be well-documented for future reference and maintenance purposes.

  • There is no quantity limitation to add any quantity of the same product to the cart.

Success metrics

🤔 Assumptions

Solution

Scenarios

Note: these are high-level scenarios that must pass testing before we can release the feature. They should also be used to drive design. Note that we do not specify user interface details in these steps - that is deliberate so that we focus on the process and not on the UI since the UI can change throughout design and development.

General (independent of the Scenario/solution)

Position for the new Bag section with the button:

  • Desktop: Bag on top of "Add to Order"

  • Mobile: below total info

OBS: to make this work we’ll need to adjust the javascript logic that generates the positions for the template grid CSS (I’ll give more details in the tech refinement).

Scenario 1: Use the useCartAddOns method and all the addOn extras feature that already exists in the application (validating)

Add extras feature: /wiki/spaces/FE/pages/3497590902

  • Create a new section above the “Add to Order” as in Figma

  • Create a new specific component to deal with the bag item in the cart

  • Create a hook to get data from Sanity and perhaps hold the logic to consume the other hooks that we need for the addOn extras (update the quantity in the cart, etc)

  • Adjust the CSS grid logic to deal with these new items on the screen

Advantages

  • The feature is complete and will deal with all the cart, reordering, receipts, and so on for us in a free way. (prevent bugs or missing things in the flow)

  • The development will be faster as the method is already generic to receive more than one section

Disadvantages

  • Only the edit part will be different from what we have on Figma (editing through the Extras modal and etc)

Sanity

The Sanity part is already made for the proposed Solution

This is the vision of the created Add On Section for the bag example. We can click on the “+ Add item” and find the bag in the list (after register the item in MDS)

Important points:

  • When we added your item through the useCartAddOns we cant edit the extra item quantity directly (more info about this on the Extras documentation). For this, we’ll need to click on the “edit” button to edit the quantity through the Extras modal.

Questions

  • Extras items limit can be affected when the bag is added?

    • R: No. The AddOn feature has the ability to create exclusive sections that have your own limit for the items that will hold on.

      Extras sections.mp4
  • Can we think of something more generic? To not be looking at a specific item from Sanity

    • R:

Scenario 2: Transform the Upsell component into something generic to be reusable

Today we have an Upsell feature which is a section to add extra items to the Order.

Add order example.mp4

The idea here is:

  • Transform this specific component to be something generic and with this, the component can be used in the specific Upsell section in Sanity (as is today) but will also be possible to use this component for other desired sections (today this component is not generic)

  • Create a new document/section in Sanity for the bag

  • Implement the new UI in the Whitelabel (as proposed in Figma) where the new generic Upsell will be used with the data from the bag section

Advantages

  • The edit is free and we can have the “-” and “+” to control the item inside the “Your cart section”

  • If the component is generic we’ll be using the original idea but in an adapted way. Perhaps this will not cause many bugs and the generic new Upsel will work as the original (inheriting your bugs and features)

Disadvantages

  • The complexity to understand how the component works and transform all the mechanics and sub-components into something generic that will need to accept any section from Sanity.

Questions

  • Today from what I saw until now if we click on the “edit” when using the Upsell feature this will send us to the menu item page. Do we’ll have a page for the bag item? (with info and etc.)

    • R:

Design

Figma design here: [insert link]

Development

Release

  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.