February 25, 2020

8: Indexes, Games, and Hyperlink.academy V2

Forgive me. If I were feeling better I would've written a shorter letter.

Hi y'all. I spent a chunk of last week sick, and I'm still finding myself recovering. So here are a bunch of little thoughts. I hope they find you well.

Indexes

I've been working on reorganizing my website, and the problem of index pages constantly turns up. I want to be able to just write, without too much consideration of "where" my writing should go, or how it should be presented in the future.

This is not a new problem. See this very long critique of operating systems for the same problem in the context of filesystems (i.e the structure of the lookup system being too rigid.)

It's even older than computers. Books have been using indexes for centuries (I assume?).

https://twitter.com/jrdprr/status/1231373217723539456

I wonder what different kinds of indexes could be cataloged. I'm sure there's huge diversity in tables of contents, let alone glossary's or back of book indexes. I can even imagine little end of chapter indexes pointing to other references to the chapter (backlinks!) or elaborations elsewhere.

a little learning game

I spent a couple hours last week hacking together this little ascii art "game engine" with a friend. Since October last year, we've been teaching a group of middle-schoolers to program. For a while now a bunch of them have been defecting from our planned "curriculum" ¹ to watch youtube videos on making games, and we can sense overall enthusiasm waning in the face of JS, so we decided to meet them where they were.

We plan to slowly build up this game with them, each time we meet setting up just a bit more scaffolding for them to work within. They're going to be the ones driving the design of the game (albiet with us helping them scope (down) appropriately) ², so we'll have to respond to whatever wild things they dream up.

Creating an program for learners to work in is a very different design problem than I usually deal with. It deeply challenges my notions of "clean code"³. When I make a program I want to build it in a way that will remain stable as I work with the program. It should be maintainable.

When I don't understand the problem domain very well, like with a game engine, this means a lot of constant refactoring. Ultimately this process results in an architecture that's well suited for the task at hand, but it might take some thinking to figure out exactly why something works the way it does.

This is (I think) the opposite trade-off to making an program for learners to build on. There you want things to be as easy to figure out as possible and you want the problem domain to be "frictional". i.e you want the learners to have to deal with the problems of the architecture, and ideally be empowered to do that refactoring themselves.

This is a very new area for me, so if anyone has any tips (whether on the dealing with children side, or the teaching people to program side) I'd love to hear from you!

looking forward

this week i'm working on the next version of hyperlink.academy. It was one of the most fun little experiments I did last year, and I'm really excited to get back into it.

Sadly, I think the core conceit of version 1 (that courses could live solely on individuals websites) will shift. This time I want to test what shared infrastructure could look like for these courses, and how I can integrate finances and forums.

If you want a sneak peek at what you can check out some fantastic wireframes/workflows Celine put together.

I'll be using the same software stack I used to make the writing app I talked about a couple weeks ago, so should be smooth sailing ⁴!