Finally! Back to my roots of language-based micromaterials!
During a perhaps unwise move to completely change stacks, deployment pipelines, and other fun technical stuff, my ability to work on new micromaterials like this slowed down for a bit, but I’m hoping to be back to adding to the growing list of examples available at grammarbuffet.org.
As a quick summary of the most important aspects of this shift, I’ve started deploying all the user-facing parts of the applications on to netlify. Definitely check them out if you’re interested in creating stuff that doesn’t necessarily need any database integrations.
Essentially, this is very much in keeping with the modular nature of the micromaterials approach, and allows the data and logic of a micromaterial to be separate from the user interface part. It’s been quite a shift from putting everything onto my own servers, but a welcome one, and a much more productive paradigm going forward.
…and now, back to the education part!
The basic structure of the app (which I borrowed heavily from this tutorial) is the user selects a word with the sound they want to practice rhyming:
after that, they see a grid of 12 squares with words on them (6 of them rhyme, 6 of them don’t). The user needs to find and tap all 6 of the rhyming words to win. If 3 of the non-rhyming words are tapped, the game is over. That’s it.
All of the data for the words comes from the new general service list, which itself covers around 90% of the words learners are likely to encounter in general English (eg, not academic or specialist domains).
It’s therefore an incredibly useful list in terms of deciding what to focus on first. It also has the happy byproduct of giving us shorter words with more obvious rhymes (I’m not even sure how useful rhyming something with “economy” would be).
Things I like about this approach
- It’s an easy way to get immediate feedback on predicted rhymes for many very high frequency words, particularly those with different spellings of the rhyming syllable (eg, “show”, “although”, and “go”).
- It’s very easy to figure out what to do, and there’s no need for reading complicated instructions.
- It involves an extremely small network request to load the entire app, and it even works offline (more on this below)!
Things that could be better
- Using reading skills to identify pronounced rhymes isn’t very authentic, and it would be better if users had to actually say the words to select the cards (much more difficult, if not impossible, with current voice recognition technology), or possibly listen to each word spoken.
- The current algorithm to select the rhymes only looks at the final syllable, and it should probably be updated so that there are more rhymes like “butter/stutter”, and fewer like “practice/purchase”.
- the words that don’t rhyme with the selected word could probably be randomized instead of all rhyming, so that the strategy of “find one non-rhyming word and don’t click any words that rhyme with it” is not a viable way to “win”.
Recently, there has been a growing appreciation that the entire world doesn’t benefit from unlimited data on a 4G connection. In a parallel to the movement towards creating mobile-first apps that target mobile screens and are then adapted to run on desktop screens, we now talk about offline first as a way to enhance the user experience in places with poor network connections and expensive data charges.
I’ve recently started auditing my existing micromaterials to see which can be upgraded to be offline first, and have had success with a few so far (both grammarbuffet.org and touchwords) are now fully available offline.
The short version of how we do this is using a technology called Service Workers to store copies of all the assets we need to download to run the app. Once that happens, and everything is stored, that Service Worker can just give us those instead of needing to download them again.
Using this paradigm, combined with user interfaces hosted on a service like netlify, the apps are extremely quick to download, and each usage after the first one doesn’t even need an internet connection.
The micromaterials approach
The real power in this kind of approach to building and deploying micromaterial web apps is when we start developing the server-side systems that need database connections and things like that.
A true static web app like rhyme-game (we’re still workshopping that name…) could easily make a network request to get data from an API somewhere (like this one returning sentences from reddit) and use that as the datasource for the page.
In this way, we could reuse a server-side micromaterial as a data source for any number of web apps that want to do something with it. For example, with the API I just mentioned, we could use it to…
- create a gap-fill activity, or…
- have students draw lines and circles on the screen to identify the subjects and predicates, or …
- show an in-depth dependency parse as a graph, or…
And once an ecosystem with different sources and consumers of micromaterials starts to grow, we’ll probably see stuff that’s much cooler than anything I could build on my own.