Seeking Advice on Headless CMS for KGC Community Website Rebuild

·Jul 07, 2021 06:56 PM

Hi everyone, KGC is looking to rebuild its web site to focus on community activities. There is a lot we want to build but we want to start small and set up the infrastructure that will allow us to further develop. Because we believe in dissociating data from it's display, we have recently turned our head towards headless CMS frameworks. We are looking for some advice on where to start and that also to a developer to help us implement the vision. We have talent in this community such as Larry S. Andy F. and many others and would love hear your advice.

👍3

🙌3

10 comments

· Sorted by Oldest

Aaron B.
·
Great to hear that KGC is on the road to intelligent content! Where to start? Before jumping straight into some headless CMS (though I think that's definitely the route you should be going in, technologically) you might consider stepping back and taking stock of just what type of content is important to visitors to your "website"[1], which is in turn informed by what sort of information is important to the community you hope to nurture and cultivate. Two initial activities along these lines might include:
An enumeration of use cases around community needs and wants (e.g. "as a KGC visitor, I want to be able to find out about upcoming events" / "... to ask questions about semantic technologies" / "... to find a job", etc., etc.)
Enumerating and ranking the different content types that are most important to fulfilling these user needs (e.g., per above "events" / "questions and answers/articles" / "linked job summaries")
Armed with these answers you'll have a better idea of what sort of content you should be providing to your visitors, and how you'll need to provide it. All of this, in turn, will enable you to say something like, "cool, let's start out by building an article and a simple event content model in our headless CMS" (here I've skipped the step of, you know, choosing such a CMS, and have ignored the possibility of building conceptual models prior to building those logical models). [1] The quotes just to indicate that with this you have joined the ranks of truly omnichannel content, where the "w" word can be poison. 🙂
👏3
🙌3
Andy F.
·
I’ll second that this is great to hear. The KGC site could be an excellent place to showcase elements of what can be done with forward thinking ideas of content as communication (vs. content as “pages” — akin to the perils of the “w” word Aaron mentions). I’ll also second Aaron B.’s needs-based activities. As a couple reference points, Carrie Hane and Mike Atherton’s Designing Connected Content lays out a very lucid structured content design process—and uses “designing a conference website” example throughout (which feels like cheating … but I don’t think it is). The second edition of Coleen Jones’s Clout/The Content Advantage also has some truly inspired approaches for designing from content/content need out (i.e. as opposed to fetishizing over tech). And with that said (and meant!), here’s some fetishization over tech: I’ve been working with a client in the healthcare space since the beginning of the year and one of the things we’ve done is build a structured content pilot on the Sanity headless CMS. I did some research on a few of the other options available, and Sanity ended up with a lot to recommend itself. (They also recently raised $39M for their series B, so I’m even less worried about them going up in smoke any time soon). The things I like about it:
a display agnostic open source encoded content API
complete control over the structure of content
a customizable React-base open source editor
a growing collection of plugins
well supported integrations with other CMSs, including static site generators (we’re using Gatsby)
The challenges:
There’s a new query language to learn (GROQ — though I’m able to find a lot of similarities to SPARQL, so it’s not hard to get started)
It’s all React-based. One can install and run it without knowing React, but you’d want to get into the code to take advantage of the places Sanity really shines. That said, React’s not that hard to learn—and all that knowledge spills over to what one can then do on the front end.
Sanity (the company) hosts the API, so for high volume sites (or lots of editors), there are fees involved. Their free tier is super generous, though, and even once you start to get into supporting multiple contributors (editors), their pricing model is quite reasonable. AND THEN! There are all the other things I haven’t played with yet, but am itching to get into:
supporting user submitted content (which could play into an “events” focus for KGC),
using semantic content structure to support rich, expressive JSON-LD on the front end, and
using feedback loops between well structured content and Google Analytics/Tag Manager to generate “Content Intelligence” (in Colleen Jones’s phrasing).
</ TechFetishization > All that said, the way in which KGC would like the site to support community activities may present some use cases/needs that could require a closer evaluation of the other options available. I’m clearly really enjoying Sanity at the moment, but one size never does fit all. Larry S., I believe you’ve dabbled in Sanity a bit yourself, no? I’d be interested to hear your take. (No, the “Sanity” jokes never get old). Hope that helps — and happy to chat more!
Larry S.
·
Yeah, I tried sanity once, but it wasn't a good fit . . . :) Oh, wait! The CMS. Yes, I'm also a big fan. </SanityJokes> Sanity's content-as-data approach and developer focus makes it a powerful, if nerdy, choice. You have to do all of your own content modeling up front, but I see that as more of a benefit than a problem. Aligns nicely with the kind of user-centered, content-first approach that Aaron and Andy talk about above. You also need to be mindful of the engineering and design staffing needs that come with a decoupled approach, as well as the need to educate content authors about the unique needs of writing for this kind of system. But I think those might be easier lifts in a community like this. +1 to everything else that Aaron and Andy have said, in particular 1) the idea of enumerating needs and modeling first independent of content presentation, 2) Carrie and Mike's approach to modeling, and 3) the idea of showcasing the advanced thinking in this group around how to organize and structure stuff. I would love to see this conversation be the starting point for a state-of-the-art expression of the awesome content in this community. I'm just starting a new client project and have some other irons in the fire, so it's hard to say exactly how much time I could allocate to work on this, but I can definitely carve out some time. How are your schedules looking Aaron B. and Andy F. and others?
François S.
·
Thank you all for your input!
François S.
·
So where is that modern headless CMS that consumes RDF and works with the thenewfancyfrontendframework?
🙏1
Aaron B.
·
Well (though perhaps not all that comprehensible without the talk track).... https://docs.google.com/presentation/d/16gtBIo6Yun0eBfKnXfMuT1EJnvJXBRoAQDAbPKXuPUY/edit#slide=id.gdb6c12cc37_0_9
🙌2
Larry S.
·
Also https://www.uxmethods.org/about/
François S.
·
Nice presentation Aaron B. Thanks for sharing
✔️1
Andy F.
·
Nice preso, Aaron B.! And thanks for sharing UX Methods, Larry S.. François S., UX Methods is a “CMS” driven entirely from RDF (using Jekyll-RDF as a generator—I did a write up on that a while back you can find here). That project has actually lent some perspective on how I think about data and content-as-data: my current hypothesis is that there’s a middle ground between relational and graph content/data that might be best summed up as “narrative.” It’s the humans-in-all-their-linguistic-eccentricity place where a specific linear order of content is meaning-rich. It can be represented in graph (or relational) structures, but doing that in, say, Protégé, is in effect fighting with the tool (and the data format). That’s where I think something like Sanity—or even just simple Markdown—lends itself to how we frame this kind of content to begin with. Then a well structured model (as Carrie and Mike so brilliantly lay out) helps to translate that into something useful that can be mixed with relational and graph data. All of which is no surprise to you all, of course — I realize I’m preaching the choir! I mention it only as background and context for UX Methods. At the end of the day, that project’s biggest weakness, I think, is that it’s not easy enough to update, evolve, and add to. It’s not hard, but it’s not easy enough. The next iteration of that (maybe soon??) will be based on Sanity (for narrative content), and backed by an ontology in (probably) Fuseki to coordinate the “semantic reasoning” step that’s currently being handled by a couple shell scripts that have to be run manually.
François S.
·
Thank you for sharing Andy!
🙏2

Aaron B.
·
Great to hear that KGC is on the road to intelligent content! Where to start? Before jumping straight into some headless CMS (though I think that's definitely the route you should be going in, technologically) you might consider stepping back and taking stock of just what type of content is important to visitors to your "website"[1], which is in turn informed by what sort of information is important to the community you hope to nurture and cultivate. Two initial activities along these lines might include:
An enumeration of use cases around community needs and wants (e.g. "as a KGC visitor, I want to be able to find out about upcoming events" / "... to ask questions about semantic technologies" / "... to find a job", etc., etc.)
Enumerating and ranking the different content types that are most important to fulfilling these user needs (e.g., per above "events" / "questions and answers/articles" / "linked job summaries")
Armed with these answers you'll have a better idea of what sort of content you should be providing to your visitors, and how you'll need to provide it. All of this, in turn, will enable you to say something like, "cool, let's start out by building an article and a simple event content model in our headless CMS" (here I've skipped the step of, you know, choosing such a CMS, and have ignored the possibility of building conceptual models prior to building those logical models). [1] The quotes just to indicate that with this you have joined the ranks of truly omnichannel content, where the "w" word can be poison. 🙂
👏3
🙌3
Andy F.
·
I’ll second that this is great to hear. The KGC site could be an excellent place to showcase elements of what can be done with forward thinking ideas of content as communication (vs. content as “pages” — akin to the perils of the “w” word Aaron mentions). I’ll also second Aaron B.’s needs-based activities. As a couple reference points, Carrie Hane and Mike Atherton’s Designing Connected Content lays out a very lucid structured content design process—and uses “designing a conference website” example throughout (which feels like cheating … but I don’t think it is). The second edition of Coleen Jones’s Clout/The Content Advantage also has some truly inspired approaches for designing from content/content need out (i.e. as opposed to fetishizing over tech). And with that said (and meant!), here’s some fetishization over tech: I’ve been working with a client in the healthcare space since the beginning of the year and one of the things we’ve done is build a structured content pilot on the Sanity headless CMS. I did some research on a few of the other options available, and Sanity ended up with a lot to recommend itself. (They also recently raised $39M for their series B, so I’m even less worried about them going up in smoke any time soon). The things I like about it:
a display agnostic open source encoded content API
complete control over the structure of content
a customizable React-base open source editor
a growing collection of plugins
well supported integrations with other CMSs, including static site generators (we’re using Gatsby)
The challenges:
There’s a new query language to learn (GROQ — though I’m able to find a lot of similarities to SPARQL, so it’s not hard to get started)
It’s all React-based. One can install and run it without knowing React, but you’d want to get into the code to take advantage of the places Sanity really shines. That said, React’s not that hard to learn—and all that knowledge spills over to what one can then do on the front end.
Sanity (the company) hosts the API, so for high volume sites (or lots of editors), there are fees involved. Their free tier is super generous, though, and even once you start to get into supporting multiple contributors (editors), their pricing model is quite reasonable. AND THEN! There are all the other things I haven’t played with yet, but am itching to get into:
supporting user submitted content (which could play into an “events” focus for KGC),
using semantic content structure to support rich, expressive JSON-LD on the front end, and
using feedback loops between well structured content and Google Analytics/Tag Manager to generate “Content Intelligence” (in Colleen Jones’s phrasing).
</ TechFetishization > All that said, the way in which KGC would like the site to support community activities may present some use cases/needs that could require a closer evaluation of the other options available. I’m clearly really enjoying Sanity at the moment, but one size never does fit all. Larry S., I believe you’ve dabbled in Sanity a bit yourself, no? I’d be interested to hear your take. (No, the “Sanity” jokes never get old). Hope that helps — and happy to chat more!
Larry S.
·
Yeah, I tried sanity once, but it wasn't a good fit . . . :) Oh, wait! The CMS. Yes, I'm also a big fan. </SanityJokes> Sanity's content-as-data approach and developer focus makes it a powerful, if nerdy, choice. You have to do all of your own content modeling up front, but I see that as more of a benefit than a problem. Aligns nicely with the kind of user-centered, content-first approach that Aaron and Andy talk about above. You also need to be mindful of the engineering and design staffing needs that come with a decoupled approach, as well as the need to educate content authors about the unique needs of writing for this kind of system. But I think those might be easier lifts in a community like this. +1 to everything else that Aaron and Andy have said, in particular 1) the idea of enumerating needs and modeling first independent of content presentation, 2) Carrie and Mike's approach to modeling, and 3) the idea of showcasing the advanced thinking in this group around how to organize and structure stuff. I would love to see this conversation be the starting point for a state-of-the-art expression of the awesome content in this community. I'm just starting a new client project and have some other irons in the fire, so it's hard to say exactly how much time I could allocate to work on this, but I can definitely carve out some time. How are your schedules looking Aaron B. and Andy F. and others?
François S.
·
Thank you all for your input!
François S.
·
So where is that modern headless CMS that consumes RDF and works with the thenewfancyfrontendframework?
🙏1
Aaron B.
·
Well (though perhaps not all that comprehensible without the talk track).... https://docs.google.com/presentation/d/16gtBIo6Yun0eBfKnXfMuT1EJnvJXBRoAQDAbPKXuPUY/edit#slide=id.gdb6c12cc37_0_9
🙌2
Larry S.
·
Also https://www.uxmethods.org/about/
François S.
·
Nice presentation Aaron B. Thanks for sharing
✔️1
Andy F.
·
Nice preso, Aaron B.! And thanks for sharing UX Methods, Larry S.. François S., UX Methods is a “CMS” driven entirely from RDF (using Jekyll-RDF as a generator—I did a write up on that a while back you can find here). That project has actually lent some perspective on how I think about data and content-as-data: my current hypothesis is that there’s a middle ground between relational and graph content/data that might be best summed up as “narrative.” It’s the humans-in-all-their-linguistic-eccentricity place where a specific linear order of content is meaning-rich. It can be represented in graph (or relational) structures, but doing that in, say, Protégé, is in effect fighting with the tool (and the data format). That’s where I think something like Sanity—or even just simple Markdown—lends itself to how we frame this kind of content to begin with. Then a well structured model (as Carrie and Mike so brilliantly lay out) helps to translate that into something useful that can be mixed with relational and graph data. All of which is no surprise to you all, of course — I realize I’m preaching the choir! I mention it only as background and context for UX Methods. At the end of the day, that project’s biggest weakness, I think, is that it’s not easy enough to update, evolve, and add to. It’s not hard, but it’s not easy enough. The next iteration of that (maybe soon??) will be based on Sanity (for narrative content), and backed by an ontology in (probably) Fuseki to coordinate the “semantic reasoning” step that’s currently being handled by a couple shell scripts that have to be run manually.
François S.
·
Thank you for sharing Andy!
🙏2