Authoring tools

[honstar]

With the emergence of more and more authoring tools for milo, I was wondering if we have some blueprint pattern or guardrails/constraints in place for such things? Currently, looks like we have CaaS and FaaS live, built with preact I believe. OTOH, there's OST in the works (https://ost--milo--adobecom.hlx.page/tools/ost) that looks totally different.

Ideally, we should come up with guardrails to answer questions like what are the prerequisites before I can actually build a custom authoring tool, which frameworks to use etc.

Love to get your input on this!

[vhargrave]

I think it's hard to answer because of tools coming from so many different places. We can't really expect these tools to be rewritten right away, but we need them.
In my opinion if the tool is

1. being used for authoring only (so it's not meant for end users)
2. being used on a completely separate page and not affecting the site speed of pages that are visible to end users
3. can be added without having to add a build step in our CI/CD pipeline
4. Is an existing tool
   ...then it should be ok to add the tool

If you want to build a new tool, then I believe the developer should stick to the best practices that we attempt to uphold for all milo code. (Vanilla Javascript if possible, Lighthouse of 100, only using a lightweight state framework like preact if you really need it, etc.)

[auniverseaway]

@honstar you'll notice there's an outlier in your list: FaaS, CaaS, OST. 🤔

OST was built 100% separate from Milo and was ported over 1:1. We provided guidance many months ago to use the tools we were using and the team opted not to. We could have asked it to be re-built to our standards, but we opted not to.

Here is our (current) guidelines:

1. Reach out to the community to decide the best approach to solving an authoring challenge. Leverage seasoned Franklin engineers who have worked closely w/ authoring in the past. Recommended: also get authors involved.
2. Only use a configurator if you absolutely have to: when the authoring is so complex it cannot be solved with a table-based approach.
3. If you are building a configurator, use Preact & Milo UI components to avoid performance issues and to ensure a consistent look and feel.
4. Maybe obvious with item 3, but do not use React, Spectrum, or anything that would require a build step.
5. Also maybe obvious with item 3, but UIs should fit the Milo aesthetic: CQ5 green and 90s cyberpunk vibes only. If you use Milo UI components, this will be free.

[honstar]

That's great @auniverseaway 👍 Can we somehow formalize these guidelines and make them more available/accessible for future needs?

Without having seen any code yet, are there reusable UI field elements to allow one to quickly put together a dialog-type widget for key/value pair configs?

[auniverseaway]

OST was built 100% separate from Milo and was ported over 1:1. We provided guidance many months ago to use the tools we were using and the team opted not to. We could have asked it to be re-built to our standards, but we opted not to.

Bonus points to anyone who re-builds OST using Milo conventions. 😄

[sukamat]

For Milo Localization and Floodgate, we are currently discussing the UX which will be built in Preact.
@JingleH - some guidelines above as you explore the options.