a better authoring experience of inline commerce items in word documents?

[npeltier]

For getting prices and CTAs in our documents, we are for now using links for now that contain all needed information to be rewritten as price when rendered, and hold logic to get to edition mode when clicked, being links.

Problems here are

1. feedback loop: we'd need dynamic owned js executed on the word document to show current price in place of the inserted item, and information about that price after a first "gesture" about it (click or hover). The link giving us the price at the last time it has been input, and information later on (on click), while being close, is not considered to be good enough yet.
2. context data: a non neglectable amount of data used for doing final render of the commerce item (price or CTA) is not specific to the item itself but rather to the section / page / page tree it sits in. Typical data is country/language for prices, but it could be more, especially for CTAs. Keeping the link paradigm would force us to dub any of that data to the link which in addition of being inefficient will add work on localization side.

Question after that long introduction is can we do better? Inserting "objects" we could have custom js working with, that we also be able to render easily.
Talking this offline with @vladen, he gave me a few tracks for investigation:
word embeds: https://support.microsoft.com/en-us/office/embed-web-content-in-word-for-the-web-41b2968b-3b0f-40c9-a6c9-8f3173610037
word add-ins: https://learn.microsoft.com/en-us/javascript/api/requirement-sets?view=powerpoint-js-preview#word
excel scripts: https://learn.microsoft.com/en-us/office/dev/scripts/

that look promising, but i was wondering if in a wider world (franklin) that question of using object tied to custom logic had been raised, and if there is a preferred way to follow here.

[yesil]

Actually with word addins, we could generate a resolved comment for each merch block with additional metadata where we can render/update prices, render link to OST in order to update it etc.

[npeltier]

looks great! one thing i would still dislike is the "room" the link takes, we could just have something like [[price]] as text or [[49.99]], with the risk of having [[49.99]] in text and 49.89 if price changes

[yesil]

by the "room" the link takes, are you referring to the merch block and the space it occupies?
I agree that leveraging links should allow to optimize the space and whenever authors open the document, prices could be refreshed automatically.

[npeltier]

btw not sure we should call that a "merch block" :) rather a commerce item (price or cta)? or better name, but not a block ..
yes, being able to see quickly how a price in the middle of a text, and that text look together seems like a good thing to me (to be proven though :))

[auniverseaway]

Problem here is feedback loop: we'd need dynamic owned js executed on the word document to show current price in place of the inserted item, and information about that price after a first "gesture" about it (click or hover).

I think calling this a need is too strong. The people asking for this feature have never authored a real-world page. Why would we immediately jump so investing the (significant) engineering resources to build this? If someone had never authored in AEM and asked for a Wordpress feature, would we immediate jump to giving them exactly what they want?

Also important to remember: if a solution requires Desktop Word, it is not a solution. I know this proposal is not saying it requires desktop, but everyone needs to know this constraint when approaching solutions.

[npeltier]

Sure, we go with mentioned temporary solution for now anyway. The usage of wording need as well as temporary here comes from business asking for more :). We can pause this discussion and efforts related to it for now, or we can go on searching when/if time allows

[chrischrischris]

I think that instead of trying to engineer a specific solution to displaying latest prices, we should instead look into optimizing the author / save / preview loop. My ideal setup for this would be to have the word doc open in one window, and the preview open in another window side-by-side. When you hit save in word, the preview would auto-update. I believe this might be doable via the sidekick and polling the document last edited timestamp.

For offer prices specifically, integration into the library may be enough: Provide a way for authors to search for offer prices, which then displays a list and the current price. When the author copys the offer into the doc you'd get the {{ price - hash - product }} pasted in. However an author could still copy the hash and paste that in the library and they'd be able to see the latest price there again. That probably would be easier to implement than an addin.

[yesil]

The purpose of an add-in is to provide additional context to the price that authors may need during authoring such as offer id, product arrangement code, plan type, offer type, customer segment, etc... Technically add-in development seems to be pretty straightforward.
We should check the strictly minimum set of price metadata needed during authoring with authors.

[npeltier]

well, we could have metadata as first popup on click, that then offers an "edit" button linking to OST. i like @chrischrischris's idea, i'll propose that to the authors

[npeltier]

added another aspect of it (.2 above) that live preview will not fix any other ideas @chrischrischris :D ?