Word based rich placeholders

[yesil]

The merch squad(GWP) several times expressed the need to have custom placeholders to manage certain scenarios such as promotions.
In Excel, we don't have good capabilities for formatting, nor possibility to have regular inline or merch links.
Similar to Dexter's XF based placeholder, I propose to support placeholders authored in a word document, but as a table where GWP can use formatted rich text as placeholder value.

e.g:,

key	value
after-effect-catalog-description	Cinematic visual effects and motion graphics.
photoshop-catalog-description	Edit, composite, and create beautiful images, graphics, and art on desktop and iPad.
illustrator-catalog-description	Create beautiful vector art and illustrations on desktop and iPad
premiere-catalog-description	Industry-standard pro video and film editing
creativecloud-catalog-description	Get 20+ apps plus fonts, storage, templates, and tutorials for less than the price of {{acrobat-pro}}, {{photoshop}}, and {{premiere-pro}} sold separately. ({{substance-3d}} apps not included.)

A placeholder fragment with such a value could be referenced from Word as follows:

href="/cc-shared/placeholders/merch/catalog#ph=after-effect-catalog-description"
href="/cc-shared/placeholders/merch/catalog#ph=photoshop-catalog-description"

and so on.

The advantage is that a single fragment can be leveraged to provide all the placeholders to a page or set of pages.

Also, when the fragment is previewed separately, we can display it as a nice table and a button to copy each key so that GWP can simply copy the placeholder keys with a click and paste in their documents.

[geri-w]

Thanks @yesil for raising this discussion. The one concern that I would have with this approach is that we would find ourselves in a similar situation that we have now with the current Placeholder Excel file for terms such as "Buy now", VAT labels, product names, discount percentages, etc., where we can not easily localize and rollout that file. We are not able to control overwriting custom updates to the geo versions of the Placeholder files from being overwritten on a new rollout. So currently it's a very manual process to add new rows to the placeholder Excel file. New content rows have to be localized in a separate sheet and then manually added to the Geo central placeholder file.

With the Dexter placeholder model, the content was in fragments and there was one placeholder rule file that was updated with a new placeholder key that referenced the fragments. With that model the content was separate from the Placeholder rule file and could be updated, localized, and rolled out independent of the central placeholder rule file.

[yesil]

Because the placeholders were assembled on the server side, Dexter was able to store each PH value in a separate XF. However, with Milo, this method results in a linear penalty as the number of fragments to be loaded onto the page increases.

[geri-w]

Thanks @yesil understood.

There is a discussion regarding the need to be able to merge regional edits in Excel, so if this can be solved: https://jira.corp.adobe.com/browse/MWPW-147530 (https://github.com/orgs/adobecom/discussions/2768) then I think your proposal for word based rich placeholders would be helpful.

[yesil]

Actually our approach to catalog cards with the index file might be a good fit to this problem.
GWP would author/publish individual fragments and they would be indexed in an Excel file and all the data would be served from there.
I'll discuss it with the team.

[mokimo]

Another consideration is performance. We already don't particularly endorse placeholders, given the negative performance impact that they carry. If we add another level, block->placeholder table fragment->embedded placeholders, we create a longer chain of events that can easily get mis-used and hurt performance.

On top of that, there is a certain SEO cost to using placeholders and having critical descriptions, phrases or text should ideally not live in placeholders or fragments, but the initial response of a document.