Poking around in the new Visual Builder and the SaaS CMS

Overall, it's been pleasant work and spending more time working with GraphQL queries and getting data from Optimizely Graph has been interesting.

The following notes are where I, probably preliminary as a lot this is quite new, stand now after some early findings.

NOTE: The areas where I touch on Visual Builder are probably equally relevant for the upcoming CMS 13.

Where to start?

If you don't have a customer who ordered SaaS CMS, it should be possible to go into the Partner Center site and request a Saas CMS sandbox for evaluation.

This will get you a full service set up with three environments: Test1, Test2 and Production.

Each environment has a CMS instance and a connected Graph service.

Documentation has blank spots

There is documentation and it is quite thorough but for certain things there are gaps, especially on the more dynamic structures of the REST API JSON bodies used to create or update data.

I found that the best way for me was to do manual Settings Mode edits with the wanted specifications, and then read that item from the REST API.

Then just copy bits of the response to my source-controlled JSON request bodies.

The response models are almost identical to the body format used when writing data.

Hide the BlankExperience content type

I think most sites will need to hold extra properties on all Experience pages. To use for values that goes in to META-elements and similar.

Since I found that it looks like properties cannot be added to the BlankExperience type it makes sense to have it hidden in edit mode, I set this manually in Settings Mode.

Goodbye to the ContentArea and to dropping blocks in TinyMCE

I don't really see a place for ContentArea-properties going forward, except maybe for some smaller collection type use cases. I will solve things with Visual Builder grid concepts instead.

The same stands for dropping blocks into rich text fields (which seems to be blocked in SaaS CMS anyway) where I would instead ask the editors to stack sections.

Something like this:

• Section
  • Row
    • Column
      • Heading1 component
      • Rich text component #1
• Section
  • Row
    • Column
      • Some more complex component composition in this section
• Section
  • Row
    • Column
      • Rich text component #2 (text continues)

Environments and work flow

I think we could manage most cases fully just using the three included environments.

Test1 works from agreed upon localhost-URL.

Test2 acts as UAT-environment, content types update by build process step (that calls the REST API) and that also deploys the corresponding Head App to a network/internet URL.

Production uses same type of build steps.

With Test1/2 team learns what will break stuff and avoids such actions (or collaborates closely if breaking data updates must be done).

What's next?

These are just some early findings and I aim to summarize more of my work in this area with more blog posts and also publish at least one of the tools I've put together as open source.

As a little teaser; building a server-rendered .NET head app using Strawberry Shake for Optimizely Graph calls seems to work quite well.