Modal Frank

/images/_ab144e57-595f-4a1a-981f-c0f93fad5543.jpeg

I’ve been wading through the refactoring swamp on a couple of other projects lately, and it appears to be contagious. Today I decided to pull Frankie’s CLI reader apart and put it back together again. All in service of the new lesson layout.

◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇

When I first wrote the CLI reader, I wasn’t really sure how the sentence DB would get used, so I kind of threw all the strings in one basket and wove a spaghetti blanket from the strands. What emerged was a reader that treats a lesson as a sequence of sentences in one particular format, to be used for one specific purpose: as reading practice with text, for example. If I want to study the same list of sentences in audio mode, I have to generate audio variants for each sentence, place those into an audio lesson wrapper, and then study them using the audio player.

It works, but if I get bored and want to stop reading my book and try listening to it instead, I have to switch to the audio version of the document, and then spend time paging through that version to find the place I’d reached in the text version, before I can get back to the task at hand.

The new plan is that I’m going to generate all 5 variants of a document when I first ingest it - L2-TX, L2-AR, L2-AS, L1-TX and L1-AR - but only surface the ones designated by the mode for the prompt, hint, and answer. Having them all inside the one doc though, means I’ll be able to switch modes on the fly and just keep going. The new mode handler will just present different variants, which lets me work on different skills while still making forward progress in the same book.

I probably could have reworked the existing reader to add the idea of modes, but calling your code a “spaghetti blanket” is a good indication that it’s time for an overhaul.

Rewriting the CLI might seem like a waste of time, especially because I don’t actually use that interface very much, but it’s my rapid prototyping playground. I can experiment with dozens of variations quickly and efficiently, zeroing in on the features and workflow that will serve me best before I invest in building a more costly UI on top of it.

The code rewrite itself is mostly complete. I can now switch modes on the fly and I’m already loving it.

The real challenge, though, isn’t the app code. The hurdle facing me now is that I have to integrate translation features so I can process a document at ingest time and generate the missing sentence variants.


Read More


/images/_e1b23d38-68ca-45eb-bf1b-56bd12ad0ce3.jpeg

Obsidian-fu

Refactoring the shadowmaker has become a bigger headache than I had originally anticipated, but it’s for the long-term health of the system, so I’m sticking to my guns. This weekend added further drama when I finally stopped running away from frontmatter and embraced it for all my metadata. Sure, scattering #ch-command directives throughout the body of the notes was insane, but fixing it is going to mean more than just adding a few metadata fields. I may have to completely change the way I use Obsidian.

/images/_58320e76-9140-4048-804e-b8dd45e25c5a.jpeg

A Deeper Think On Lesson Layout

As I continue to use Frankie in more ways and with different types of content, I’m beginning to see some friction points. Some are just a function of the limited graphics of the TUI interface I’m using at this phase of the project, but some are about the actual information layout itself. Before I start tinkering with it, I want to talk my way through it. And that means: It’s rubber duckie time again!

/images/_afb96080-dcb3-4d43-93e4-3fc8dafd1dc1.jpeg

Packaging Lesson Plans

As mentioned here, I recently got some exciting features working in console mode, but now I have to get them working on my phone. Getting the new code there should be easy enough - I can just pull the git repo - but delivering the lesson content is going to be a bit more complicated.