Milo Commerce - Prices & Buttons

[vhargrave]

I've been pondering how we want to set prices and buttons coming from M@S, once the OST branch is merged
With the OST we can now generate a link that contains the OSI for a product and the priceType. With these two pieces of information I can build a price in Milo.

I'm wondering if it makes sense to build a global approach for converting these OST links to prices. The approach would look like this - in the decorateLinks method of utils.js file, we're already doing things on every link in the document. I propose that we add an additional check for if the href contains something like "tools/ost?osi=". If they do , then we convert this link into a span containing the price. We'd use tacocat to do the conversion.

For the CTA buttons (Buy now for example) I'd take a similar approach. I need an OSI so that tacocat creates a link that points to the right location the user should be taken on a click.
To set the OSI, I'm wondering if it's too much to expect from an author to copy the OSI out of the link they'd have for a price, and place it as a param into the CTA link. So the link would be adobe.com/?osi=OSIFromThePriceLink
If we don't go for that, I'll need another way to mark the CTA buttons so that the "nearest" OSI is used by tacocat to calculate its href.

I've taken this approach here btw, just not changing the links on global level. Instead I'm doing it all in the cards block -
https://vhargrave-poc-usage-merch--milo--adobecom.hlx.page/fragments/vhargrave/commerce-carddemo-5/offer-card-photography
https://adobe.sharepoint.com/:w:/r/sites/adobecom/_layouts/15/Doc.aspx?sourcedoc=%7B4B5CA3E8-57C0-456C-A0B1-A2DCABDCFFE2%7D&file=offer-card-photography.docx&action=default&mobileredirect=true&cid=a047cc80-5d2b-40a9-8a0b-dc442466865e

Curious what you guys think .

[npeltier]

Is core idea here to have as content a link (that would get to OST when editing things up), that gets converted to appropriate placeholder once rendered?
i think that this is something we are getting at, yes, even though there are still some gaps to fill, mostly for inline prices, having at editing time a view of what is a price, and to what commerce properties it refers to (i.e. getting corresponding price view and commerce properties), which requires some heavy & deep hack of word view if possible at all.

[vhargrave]

Yes, that's the exact idea I'm thinking for the price, and on a global level. So instead of having to write code which transforms the link in every block that has a price, we'll write this piece of code once.

[geri-w]

Thanks @vhargrave Regarding this question:

"I'm wondering if it's too much to expect from an author to copy the OSI out of the link they'd have for a price, and place it as a param into the CTA link"

I think we should avoid copying and pasting OSIs if possible. We try to stay away from authoring any type of IDs, as it's error prone and can be time consuming

[vladen]

I think that copy-pasting step can be completely avoided if OST provides the following workflow:

1. find an offer by selecting product and entitlements
2. use price template, configure price display rules
3. click "copy" button for the resulting markup of Commerce placeholder
4. switch to the tab with document being edited and paste copied placeholder there as price
5. switch back to the OST tab and use cta template, enter Milo placeholder key for "Buy now" text (which is locale dependent and should be resolved dynamically in browser)
6. repeat steps 2-3 to paste copied placeholder as CTA
7. switch back to the OST tab and use price strikethrough template if needed to display price before discount

To simplify updates of already pasted Commerce placeholders, edit time link should open OST and preselect all the previously configured aspects of the placeholder. This should be true for both price and CTA placeholders.

Since OST should be able to generate any known type of Commerce placeholder, I'd recommend to rename priceType parameter in URL of an edit time link like https://ost--milo--adobecom.hlx.page/tools/ost?osi=0RwUma15VBOveHgpEz6cKCxATwVkUO8WO3QkI97f4Sg&priceType=price back to type. Tacocat already recognises placeholders with type= checkoutUrl as CTAs: https://git.corp.adobe.com/Dexter/tacocat.js/blob/develop/packages/wcs-client/src/wcsPlaceholderTemplates.js#L27

Conversion of Commerce placeholder links into CTA buttons (link type is checkoutUrl) or price spans (link type is price or priceOptical or priceStrikethrough) can be done by Tacocat.

One more note about CTA links...
The prototyped "Buy now" CTA link does not reflect now all important characteristics of the bound Commerce placeholder. For maximum clarity it could be useful for authors to see product name, plan type, customer segment, offer type, market segment etc. in the link text, similarly to how it was done in the prototyped price placeholder. IMO, this will help the authors to ensure that correct Commerce placeholder has been used in every particular place of Web page document without navigating to OST.

[vhargrave]

That's a fantastic proposal @vladen . The OST currently doesn't have CTA templates right? So I'm assuming this is something we'd have to add to it.

[vhargrave]

Maybe instead of making the user go through the whole OST workflow though to create a button, we could add an option for them to copy both the price and the button at the same time (so two links). They can then paste that into the word and move the links to where they need them. Thoughts?

[vladen]

Exactly, the latest step in OST: select a template - copy link markup, select another template - copy new markup.

[geri-w]

Thanks @vladen and @vhargrave - the idea of having the option to combine the button and price creation to save the steps of having to go back and forth with OST would be great for authoring efficiency

[auniverseaway]

I think a link block is the perfect solve for all pricing related features... inline, etc. For solves like cards, the layout and corresponding text should be an area of concern for the content surrounding the pricing bits (including terms, VAT, etc.)

Ideally, we should have a service that can get all price information (price, currency, vat, terms, etc.) for a given area in one go. This would mean that a single card would only need one request even though the pricing bits may be in different parts of the card.

[npeltier]

@auniverseaway there is a discussion we had offline here with regards to using link blocks, as there are here two existing pieces of code to and , with here being get necessary informations, and generate final commerce item (cta or price):

• either use link blocks, and hook tacocat (commerce internal library) logic into it,
• either have tacocat initiated to look for milo commerce links and do its stuff
  i think we'll have both approaches implemented quickly with code (@vhargrave has already almost the first one done, the second is mostly configuration and @vladen will start to work on it)

[Axelcureno]

If we go with second option (have tacocat look for commerce links on every milo page), wouldn't that mean having 2 separate threads looking for the same thing (links in this case)?
Also worth mentioning, it seems both options would trigger asynchronously when displaying prices so there wouldn't be a compromise to LCP (please keep me honest on this one) but initiating tacocat on every Milo page (not only commerce) doesn't sound like the most optimal thing to do in my opinion... I'm curious to hear what others think on this.