This issue was published on Wednesday, February 27, 2019.
Distributed CMS Post: I wrote something for Boye and Co. as part of the lead-up to the Brooklyn conference: The Future Might Be Distributed. This is going to be the topic of my Brooklyn talk.
What if inbound requests to the same web presence could be directed to a backend provider best equipped to service them? What if a single, integrated web presence could be serviced by an array of systems, each working independently, and providing content to a "last mile delivery system" which massaged and homogenized it, and provided a set of delivery services -- analytics, security, design systems, etc. -- to optimize it?
I'm waiting for a vendor to step up and say, "We realize we won't use us for all your content, but we embrace the idea of helping you bring your dispersed content together."
Deep Linking Into Content: We had a rollicking discussion at Blend the other day about automated, paragraph-level bookmarks into text content -- so, every paragraph in a page of text automatically gets a permalink.
For an example, look at this post from Dave Winer (it's not about the subject, but it's long enough to have them). See the # at the end of every paragraph? That's an automatic bookmark to allow deep-linking.
The NY Times has done this too, and they wrote about it some years ago.
There are two challenges: (1) making sure your automated bookmark is unique, and (2) correctly correlating the bookmarks between versions when large-scale edits happen (what happened to Paragraph #4 after someone rearranged everything?)
The former is a much easier fix than the latter. I'd be very interested in research around this problem, if you know of any.
(If you're interested in our "rollicking discussion" -- which was more of a monologue, really -- I've reprinted it in a txti.)
The CMS Trap: I enjoyed this essay about what we need to content manage and what we don't: The CMS Trap.
A CMS Trap is a state of a web-application in which the development of content management systems is obstructing the development of the content.
The author argues that as soon as we decide to provide management tools for something, we open up a huge nest of problems, and sometimes no management is the better answer. This echos what I wrote in my article for O'Reilly from our last issue.
A programming pragmatism is "YAGNI", which means "You aren't gonna need it." In CMS, should we have YAGMI -- "You aren't gonna manage it"?
CMS and Client-Rendered Content: CMSs are starting to evolve around the end of server-side rendering. No server-rendered HTML means the CMS can't inject markup.
- Here's a page of doc from Adobe that shows how to enable front-side editing when the DOM is built client-side. They call it "The SPA Editor."
txti: I enjoy weird, simple CMS. To that end, here's txti.
Enter Markdown, and some additional (optional) information, and get a page. You can also create a custom edit code, that you can use the edit the page later. It's kind of a content-focused PasteBin. Combine this with the MDX from last week, it's be fascinating what you could do.
I love seeing everything we can strip away and still say we have a CMS.