Content centralisation strategy

[overmyheadandbody]

Challenge

It's becoming clear that we need a consistent approach for centralised content. Not just for navigation fragments, but also for placeholders, 404 pages and possibly commerce [1].

Federated content should be consistent. Currently, we're using a development/QA environment, milo.adobe.com, to store certain pieces of production content. Not only is this not safe from a content perspective, but it also comes with additional DNS lookup tax for our consumers.

Proposal

Based on recent discussions with @auniverseaway, we're thinking of starting a new project for federated content. Let's call it federal for now, name TBD. It would have its own repo within the adobecom org, using the Milo College project. It would have its own folder in Sharepoint [2], at the same level as DC/BACOM/Milo/etc. We'd also need to set up the localisation flow and authentication.

This would create a new https://main--federal--adobecom.hlx.live/ FQDN. We would ask WebPS to proxy https://(www|business).adobe.com/<locale>/federal/<path-to-content> to https://main--federal--adobecom.hlx.live/<locale>/<path-to-content>.

Questions

• Does anyone see potential blocking issues for this approach?
• Are other projects interested in using centralised content on top of what we're describing here?

---

On navigation centralisation

TL;DR: nothing changes for our consumers, no new onboarding or additional steps are needed.

We're not planing on centralising whole navigations, just shared content, such as cloud menu dropdowns (like the content of the 4 dropdowns on the homepage), footers and, eventually, promos.

Consumers will maintain the ability to define their navigations within their own Sharepoint and use it as they do today. Only if they need access to shared content will they need to update certain paths in their own, self-hosted, navigation documents.

---

[1] https://github.com/orgs/adobecom/discussions/1093
[2] Proposed folder structure:

root
|__ placeholders.xlsx
|__ cc-sections
|____ cc-cloud.docx
|____ ...
|__ dc-sections
|____ dc-cloud.docx
|____ ...
|__ 404.docx (in the future)
|__ ch_de
|____ placeholders.xlsx
|____ cc-sections
|______ cc-cloud.docx
|______ ...
|____ 404.docx (in the future)
|__ ro
|____ ...

[mokimo]

Would be great to see a new home for any sort of content that needs to be centralised, without teams producing their own hacky solutions for shared content but authors being able to just point to /<locale>/federal/<path-to-content> (so including a link) in a natural way.

That would turn the milo Sharepoint folder back into a purely milo.adobe.com documentation & QA playground again and having a separate folder for production content with stricter rules around moving/deleting/publishing content.

With the new project, milo would continue to be centered around specific projects and their own content.
On the same hand, provide a solution for any content that should be shared across consumers.

[narcis-radu]

I like the idea of setting up a new project to handle centralised content, this way we ensure everything is in one place and there's no threat of content being accidentally removed by developers. This will also reduce the complexity in logic; all existing use-cases and content would not have to suffer.
We need some content structure and governance to ensure content is not randomly dropped in Sharepoint. The content structure proposed by @overmyheadandbody is good, we might need to think about fragments as well.

[honstar]

The ability to share content across adobe.com boundaries has been a challenge and requirement for a decade. We've seen various solutions along the way with varying degrees of success.

From my perspective, @narcis-radu has already mentioned a crucial point: content structure and governance! We need to be very clear about the intent of a central content storage and its real-world application. Ultimately, it's bound to a client-side mechanism where an additional HTTP request needs to be made to fetch content.

[overmyheadandbody]

Totally agree. For our initial purposes, the content to be centralised belonged to sections that were loaded async anyway, so we weren't expecting much overhead. Using centralised content should definitely not come with performance toll.

[honstar]

Another use-case for centralized content is tags: for adobe.com, it would be great if we could host tags that are common across business units in a central location. The existing tag-selector block already allows for defining multiple tag sources.

[npeltier]

for taxonomy, i guess one file per BU still makes sense, as it's very likely

1. it makes it more difficult to get people to agree on wording,
2. there is less overlap across BUs and make less sense meeting around intersections

[honstar]

Caas was already a good foundation for common and more importantly, reusable tags. But yes, having one spreadsheet per BU probably makes sense.

[yesil]

I understand that we aim to keep Milo's sharepoint folder as the sole source for documentation and QA tasks.

However, I'm uncertain about the necessity of having numerous sharepoint folders for distinct projects.
Introducing yet another repository for shared content would likely amplify the complexity of content authoring/governance.

Can we please clarify the primary obstacle preventing us from consolidating CC, DC and EC content within a single sharepoint folder?
How and why we ruled out this option at the first place?

[mokimo]

That's exactly the goal we currently have. We propose to move away from sharepoint/milo and instead have sharepoint/federal as the single source of truth for shared content.

This would also provide clarity that sharepoint/milo is documentation + development + QA.
sharepoint/federal would be shared production content for CC, DC, EC, etc.

The milo sharepoint folder has some limitations, we are only able to work within sharepoint/milo/libs - especially in regard to localisation throwing everything into sharepoint/milo/libs/{locale} could become a major pain point in the future. There was a discussion with @auniverseaway around it here: https://adobe-mwp.slack.com/archives/C24DVBDFS/p1696279335667499

[yesil]

I'm not talking about shared content but the actual pages. What do we need to use different folders at the first place?

[overmyheadandbody]

GWP is asking for updates on the final approach, so we'll need to reach a conclusion soon and start implementation.

Until now, there haven't been any major red flags as to why we shouldn't be going this direction. More and more consumers and pages are being onboarded to Milo and it's not sustainable to ask them to duplicate content in multiple locations, since this will lead to discrepancies along the way and also increases authoring effort significantly.

Performance should also be considered - using the /libs approach would address concerns, but it lacks localisation support. There's no /de/libs support, /libs always leads to US content; which in turn can't be localised with the current setup (we'd end up having [us]/libs/de, which doesn't make much sense). Such an example is the centralised 404 page. It's nested under /libs, thus available through an adobe.com/libs proxy, but it lacks localisation flow support, authors need to add content manually for other locales, now and in the future.

So the question is: are there any major concerns around our proposal?

[narcis-radu]

I don't see any objections, just a couple of suggestions:

• need strict content structure and governance - for this we need to work with authors, provide clear documentation and instructions.
• centralised content can (and maybe will) be used for tags - we should think about this when creating the content structure.
• speaking about tags (but can be discussed in a general manner) - we should allow each BU to have their own strategy or taxonomy files so we don't overlap or overpopulate a single document / file.

[gabr1ela]

Great discussion, my only opinion is to find the one way of centralizing content, future proof it and make it stick.

We already have use cases to leverage placeholders, but I'm also wondering, what if we wanted to leverage merch cards across CC and DC?, would that also fit in this content structure?

[yesil]

In this regard, I wonder what is the technical limitation if any for not consuming a CC fragment from DC directly.
Also same for MEP manifests for promotions, which in their turn can load different fragments.

[overmyheadandbody]

It's relativisation from the Franklin side, there are multiple cases where we never get the host, we just get the path, which doesn't provide enough context.

[yesil]

Are you aware of any ticket or discussion that can be referred on this subject?

[mokimo]

We need to add another folder to the structure, otherwise we could run into authoring mistakes when someone copy/pastes previewed links from the central project.

root
|__ federal
|____ placeholders.xlsx
|____ cc-sections
|______ cc-cloud.docx
|______ ...
|____ dc-sections
|______ dc-cloud.docx
|______ ...
|____ 404.docx (in the future)
|__ ch_de
|____ federal
|______ placeholders.xlsx
|______ cc-sections
|________ cc-cloud.docx
|________ ...
|______ 404.docx (in the future)
|__ ro
|____ federal
|______ placeholders.xlsx
|______
|______ ...

Running through this example

Error-prone example without nesting everything within a "federal" folder

1. Author publishes on the federal project https://main--federal--adobecom.hlx.page/drafts/osahin/gnav-1
2. Author uses that link in normal project
3. Link gets turned to /drafts/osahin/gnav-1 (<-- author now manually needs to add /federal/drafts/osahin/gnav-1)

What we want

1. Author publishes https://main--federal--adobecom.hlx.page/fr/federal/drafts/osahin/gnav-1
2. Author uses that link in the normal project
3. Link gets turned to /fr/federal/drafts/osahin/gnav-1 which then gets pulled from the correct project on the consuming projects.