Are you looking for low stakes ways to store and display data? Welp, here’s Google Sheets. Do you want to automate all of the boring parts of your job and sip a drink on a beach somewhere? Looks like you owe Google Sheets a beer. Have you ever wanted to build a lightweight full stack application without spinning up an orchestrated Docker container cluster running on AWS using Typescript that has 90% unit test coverage. Well, hold on to your hats, cause Google Sheets is about to hit 88 MPH while keeping your molecular structure intact.
There’s some low-level stuff here that could be dovetailed with IFTTT.com to do some simple automation for maybe doing Snarfed’s backfeed problem.
In order to make it easier to track activity in Hypothes.is, I created a program called Hypothes.is Collector. The idea is that you can type in user name, a URL, a tag, or a group ID and click the button to see all of the related annotations. The program will create a new sheet with an archive of up to 200 annotations based on the search terms. It will then create a third sheet that will count how many of these annotations were made on each URL in the set by each user.
This seems like it could be an interesting tool for annotations in a classroom setting and is related to some of the broader Hypothes.is API tools.
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.
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.