I finally got around to playing with Adobe Franklin – down to getting the sample configs into GitHub, content into Google Docs and starting to understand how blocks and styles work. (My version of this blog post hosted via Adobe Franklin can be found on my personal test site here: https://main–adobe-franklin–mdemeny.hlx.live/adobe-franklin)
At its core, the key value proposition of Franklin is the ability to use familiar tools for content creation; namely Google Drive and Docs or Sharepoint and Word. Configuration is done via a forked Github project and styling is done via “blocks” which are either managed by Adobe, or customized in your Github code via CSS and JavaScript.
It is all tied together via access to a GitHub app, sharing your docs to an email account (helix@adobe.com), a Chrome plug-in, and some default assumptions. For example, my Franklin “site” subdomain is my branch name, GitHub project and GitHub username. Navigation and Footers reference specifically named “nav” and “footer” documents.
Franklin is interesting to me as it echoes some of the use cases I have seen in the real world – namely the ability to use word processors for authoring content. When I was at Sitecore, and deep into some of the Adaptive Print Studio / InDesign functionality, I came to intimately know a very large project that Velir undertook to build a innovating authoring model for scientists using an MS-Word plugin for their client, Elsevier Business Intelligence.
The model was simple, yet clever; build a plug-in and a set style document within Word. These styles would map to specific fields, or even other content items. For example, a title style in the document might map to a Title field within Sitecore. A specific quote style might create a new sub-item and automatically put a visual component onto a page and reference that sub-item. This was all used for omnichannel print and web assembly from the same content and layout cues.
All-in-all, it was extremely clever stuff and Velir deservedly won a Sitecore Site of the Year Award – in 2012. And yet, this idea of using word processors for content, layout and formatting has not progressed significantly in the last decade since.
The obvious advantage here is the major advance in usability and training (or lack of it required) for casual contributors and the fact that add-ins such as grammar checking or generative AI for the two most popular word processors are likely to be far more numerous and well developed than even the largest of CMS communities such as WordPress or Drupal (let alone most commercial vendors).
However, the model that Velir implemented had some downsides as well – you needed to do a lot of mapping between styles, fields and other logic. If you chose the title style for two different chunks of text, which one got sent to the CMS? If the overall design of the print document changed, there was a great deal of work to update and keep the various models aligned.
Franklin similarly shares the potential and downsides of this model. The ability to author using nothing but a word processor (once someone reasonably tech savvy has set up the correct repos and configurations) is incredibly powerful in its simplicity, however there are a few key gaps in comparison to a “traditional” CMS:
- Block governance and usability
The biggest gap in authoring experience is how you actually use the block types available to you. Out of the box, there are a number of UX blocks – but there is no way for an author to know they are available, or what the format for using them is (this also applies to custom written blocks). Similarly, any custom blocks are not listed for use to the content author in any way. UPDATE – based on the latest announcement from Adobe, it looks like Sidekick now does link to assets and the library from AEM – https://business.adobe.com/products/experience-manager/sites/content-creation.html
However, the variety of typical formatting options for most visual components is generally fairly complex and any style changes have to be passed as parameters in a separate table – so the model quickly falls down once you get slightly beyond the boundaries of the design.
- Site management
Franklin basically creates URLs out of your doc names. Any linking in the docs are similarly done by hand and there is no validation, site structure, bulk publishing or timed deployments. That said, there are some elements such as search indexing or Forms where Franklin does have functionality here (which is interesting as many headless vendors lack even these). Workflow and scheduled publishing is non-existent.
- Customization
Currently Franklin relies on a lot of “black box” Adobe bots to tie the entire application together. I assume enterprises would rather have a greater sense of control for these tools – particularly when it comes to giving access to corporate code and document repositories. Similarly, they may want to inject custom functionality into the AEM Sidekick Chrome extension, or the webhook triggers themselves in order to customize some of the content transformation or rendering operations.
- Rendering fidelity
On the version of this content delivered by Franklin, you’ll notice this web page has numbered lists that each start at 1. In my Google doc, I have these set to continue numbering. Franklin has thrown out my override and also ignored some of my tab formatting during the conversion process (for what it’s worth the sub-standard LinkedIn articled editor has the same issue). Similarly for things like images, it tends to simply ignore the size, scaling and cropping that users indicate. Beyond the simplest of blocks and formatting options, the limitations of the model break down.
- Scale and structure
This is somewhat related to the overall lack of governance in the model, but it is also related to the fact that the model specifically ignores any attempt at structuring content. Each and every document will be starting from scratch as you create content and layout a page. Headless systems have a double-edged sword with regards to usability in that content creators are stuck entering content into forms (boo!) but done well, these act as guardrails clearly indicating what content can be created where, and how they relate to each other (yay!). Franklin has gone in entirely the opposite direction, which is great for some use cases, but a maintenance and governance nightmare for others.
I have questions…
All in all, Adobe has done a very interesting thing in how far they have managed to develop Franklin (and make it available to the world) – but for how long, and to what end?
Although the Franklin project site is branded as Adobe Experience Manager (which is confusing as heck), I am not actually seeing where Franklin may tie into what we would traditionally know as AEM/CQ5 – aside from re-using some of the page model naming and code conventions (such as blocks). The actual delivery and business model seems vastly different – and in a lot of ways, somewhat undercutting the value proposition of AEM. AEM has a lot of enterprise functions that Franklin lacks; a core repository – including for structured content, assets, workflow, governance/permissions, an extremely customizable model in how front-end applications are rendered, site management functions (URLs, redirects, etc.) and AEM is very expensive, while Franklin remains free (for now).
However it does look like Adobe is heading in the direction of having the in-document editing be a part of the core AEM offering potentially addressing my gaps and the larger question of “how to actually make money from this thing” by piggybacking off AEM for some of the larger “management” functions and leaving the current public iteration of Franklin as is in order to seed the community with some entry-level AEM folks.
Questions that Franklin raises for me:
- What is a CMS? How much can you trim away and still call yourself one? Franklin piggybacks off an entire vendor class (Word Processors) to handle almost all of the UX – from authoring to its somewhat limited site management. It also completely ignores some of the conventional wisdom around structured content (it does do it at all) and even page layout (entirely handled by front-end JS/CSS and not shown to authors at all – except in rendered preview).
But headless vendors also threw the rulebook out the window when they specifically (generally) ignored a lot of the typical CMS functions around site management or page layout management, so there is lots of room in the big “CMS” tent for vastly differing approaches.
- Is there a model for this? It is a bit of a truism that most content creators prefer not to do their initial writing in the CMS. I think that WordPress Gutenberg has always been an exception to this, and a model for demonstrating how content creators might be catered to by tools that are more driven by the need to enable the act of publishing, rather than creation. That said, unstructured content has some downsides and going further away from interfaces that are designed to help authors understand the context around them (where they exist in a site hierarchy, what visual components you can use and what they look like, etc.) might be more trouble than it’s worth. Ultimately, the best model would be the considered combination of something like a headless CMS and Franklin – with the two working seamlessly together.
- How does this model reconcile the gaps inherent in CMS use cases? Structured content is incredibly advantageous for so many scenarios, yet Franklin has no capabilities here, or even a good model for working alongside it. At the opposite end of the “structure vs. layout” spectrum, the fidelity of page layout is also very limited and simple – but what it does have is using word processors as a starting point and method for turning this into sites and pages. This model may have some incredible potential down the road if the Franklin “bots” can do more intelligent things such as mapping text to existing content models or component designs – perhaps even as authors are creating. I know this document you are reading could have probably benefited from some contextual suggestions and design updates – and this is the ultimate goal for any content creator. I focus on the content, somebody (or something) else can help handle what to do with it; where it goes, how it fits into my content landscape, etc.
- How to reconcile some ideal customer profile gaps? The type of customer that really loved the model of authoring web content directly in a word processor is typically a very large organization, with many hundreds/thousands of users they do not want to train and filled with subject matter experts who want to type and not think about pages or layout. However, they often have some particularly interesting and complex rendering, post-processing, workflow and governance needs – and Franklin has none of this functionality. So who is this thing actually for? It raises the next question —
- Just what is Adobe doing with this thing? I have no idea. It’s free, interesting, and competes with a lot of stuff out there – including their own DXP, I guess.
Concluding thoughts
I applaud Adobe for taking the time and significant effort to build something which disrupts the content creation paradigm. That said, without some significant advances in how Franklin enables some pretty enterprise-level needs (and how it fits with the rest of the Adobe portfolio), I think this will remain a cool lab project and not be viable for most scenarios.
However, I do see Adobe continuing to innovate on this model in the background – and Franklin may provide a window into how users start to work with Generative AI tooling. If the word processor becomes the default view for any content creation and helpful suggestions (grammar, writing structure, etc.) and Adobe can start to tie in more services around content and layout suggestion, they may have a significant advantage on their rivals if this model of piggybacking off other more ubiquitous content creation tools becomes more and more the norm. There are definitely use cases such as the EBI model built by Velir that are natural candidates for this model. In discussions with Cruce Saunders , as we were discussing the potential of this model could be, I lumped things into three boxes:
- Content acquisition – this is really where Franklin can excel. We have had CMS integrations with Word processors for quite some time (decades, in fact), but the true innovation is linking directly to cloud services to enable “in-place” editing to avoid that upload and sync problem. Noted gaps aside, this is really where the model is showing its usefulness.
- Page and site structuring – the model of blocks and even how different shared folders and how it relates to site structure and linking has some major usability challenges for now. Adobe can go one of two ways; either bring more and more block visibility and governance into the word processor directly, or…
- AI to the rescue – we are starting to see this in tools like Powerpoint where an intelligent assistant is looking at the content and making recommendations about other formatting options. If Franklin can start to do more work around formalizing block schemas and field relations (almost like a content model) and provide either the functionality or hooks for doing pattern detection for types of content it can truly provide some major advances to the state of content creation.
So it will be very interesting to see where Adobe takes this. Other CMS models for “word-processor-centric” approaches may also lend themselves to this approach. For example, I would be very curious to see how quickly WordPress would manage to get the Gutenberg blocks into a word processor (but many other vendors would struggle to adapt or incorporate this type of editing). Ditto for the Blocks Protocol.
Compared to other recent trends in CMS such as headless which were high-impact for developers – Franklin may represent the opposite; some actual, new innovation for content authors. The likelihood of this model gaining significant traction depends on the quality of the underlying services and applications to make it easier to create and be assisted by bots and generative AI – but the foundational elements are in place for Adobe to be experimenting and iterating unlike few other major vendors at the moment.
This article originally appeared on LinkedIn.