This is the first post in a three part series on using Google Sheets as the database for a blogging CMS. In this post, I’ll explain the motivations for building the system. In the second post, I’ll walk you through the Google Sheet itself and the Google scripts (their version of js) that drive it. In the third post, I’ll share the website that displays the blog, and the code behind it. My guess is that interest in the three pieces will vary for different audiences, so I wanted to encapsulate the descriptions.
I generally like where John is taking this idea and the fact that he’s actively experimenting and documenting what he’s coming up with as potential solutions. While I do like some of the low-tech angle that he’s taking, I’m not sure, based on what he’s written, how some of it will come out within the broader spectrum of DoOO or IndieWeb-related technologies.
For example:
- How easy/hard will it be for students to own/export their data after the class?
- How might they interact if they’re already within the DoOO cohort or already self-hosting their own space?
- What are the implications for students of maintaining multiple spaces with a variety of technologies and therefor overhead?
- I’ve never had a lot of luck with Disqus, which I find to be heavy and often has problems with auto-marking all of my content as spam. I’ve definitely found it to be an issue with using for POSSE workflows. Worse, with the introduction of specifications like Webmention to the DoOO space, students could be writing their responses to classmates and teachers on their own sites and thereby owning all of that content too, but with Disqus, this just isn’t possible.
I’ll reserve judgement for once I’ve seen some of the code and further ideas in parts II and III as I suspect he’s likely taken some of these issues into account.
We’ve played with this concept of front-end blogging for a while now. Alan Levine has built an open sourced tool called TRU Writer that even provides this type of front end interface on a WordPress site. ❧
I’m curious if John, Alan Levine, or others have yet come across the concept of Micropub? It generalizes the idea of a posting client and interface so that it could work with almost any CMS-related back end. I could see people building custom micropub clients for the education space, or even using some of the pre-existing ones like Quill, InkStone, or Micropublish.net. Many of them also use JSON or form encoded data that they could also be using with platforms like the one John describes here. The other nice part about them is that they’re flexible and relatively open in more ways than one, so they don’t necessarily need to be rebuilt from scratch for each new CMS out there.
Syndicated copies to:
John Stewart